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.
When your security gets unruly, it can get time consuming to figure out how a user is accessing a SQL instance. Sometimes you may know that a user is getting access via one certain AD group but you aren't sure if any other groups are granting access. Furthermore, a user might be in a group that's nested in another group, through which they are gaining access to your SQL instance.
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.
This is a bit of a scary task. Someone tells you about 87 databases that all need to be restored from the most recent FULL backups. You can either spend the rest of your day pointing and clicking, or you can use some PowerShell power to crank out the script and get on with your day. Here is the PowerShell way.
I don't like to fire-off the actual backups from PowerShell, rather I just use it to script out the restore script. So, this PowerShell script will output the T-SQL restore script: