Instead of working, I blog.

OK, I'm also changing this in the original post, but in case you don't think to go back and check.
When I sent my admin password solution to a buddy at MS, he tried it and it didn't work. After a fairly short discovery, I discovered that it worked for me because I had a drive mapped to the admin share on my DC. So PSExec was using that IPC to connect. So unless you're lucky enough to have something like that, you prob won't be able to use this solution. However, it's a good backdoor so it may be a good idea just to setup a mapped share on your box anyway just in case something happens and you get shut out of your DC.

On that note. This is a really excellent reason why you never want to run SQL under an admin acount and especially not under a domain admin acct. I've seen that more than I care to and it always comes out bad eventually. It only takes a very basic knowledge of SQL to discover that someone with regular user rights can setup a SQL job to promote their user acct to admin because the job will run under the context of the agent acct at the OS level. And if you're running your services under an admin acct they'll have full rights to do whatever they like. And if you're running it under a domain admin acct, then they can promote themselves to domain admin pretty easily by running a .vbs or prob even powershell. Pretty much any scripting language will prob do, huh...
And that goes for running SQL on a DC under local system. That's the same as domain admin as far as the DC is concerned. So be smart and run your SQL accts with non-admin accts and just remove that from the equation. There are enough ways for internal and external hackers to elevate rights. Don't help them.