EDIT: I had two scenarios like this. The one written about here worked. The other one failed. The actual solution came from sql-ution.com. The solution is to fix the registry with the new value. And just in case his website comes offline before mine does, I'll post the code:
The trusty "sp_who2" is a quick way to look at what's happening on your SQL instance, but you can't put a WHERE clause on that thing! You have to manually sift through the results and there could be hundreds of results.
SSMS Boost is an add-on for SQL Server Management Studio. I used it for quite some time but I got tired of using it as freeware. The reason SSMSBoost as freeware didn't work for me was because they require that you continually re-download the new version and re-register every 120 days, otherwise it renders your existing version useless. That process gets tedious, at least I think it does. I want my tools to serve me, not the other way around.
When a High Availability (HA) environment failed over, on the node that became Secondary, the backup jobs did not gracefully handle the change. The Maintenance Plans are supposed to intelligently determine whether each database is Primary or Secondary in an HA environment, and skip the backup if it is not Primary. This check actually fails (practically speaking) if you have "Verify backup integrity" checked.
Here is a situation I just came across (boiled down and simplified). An end user was having to manually find a user id, navigate to an image folder, and then search through hundreds of images to find the one corresponding with that user. Sure, they were in numerical order, but still, what a pain! He wanted to generate an excel file with links to files to quickly access the corresponding image.
When using AlwaysOn, you must connect using your listener name, not your node name. If you connect with the node name, it will only work until there is a failover, which would defeat the purpose of your High Availability setup, right?