We have separate domains where I work. What I mean by that is, the development domain is a sandbox so to speak. Where developers can play all they want, do what they want without causing issues on SQA, Pre-Production or Production servers.
Situation
This past week a project development server was moved out of the development domain and into the main domain. This was all done without my knowledge by system admins. How I found out about it was a developer pinged my in Instant messenger saying he couldn’t log into the server with his old domain username and password.
After asking the build manager if this was in fact the case and receiving confirmation it was and then failing to log into the sever with my super account we had a problem.
Assessment
The VM was moved from one domain to another before I was notified. Had I been notified I could have added an account with elevated privileges or enabled the SA account (we disable by default) in order to add the new domain user accounts. That would have made things much easier. As it was, there were no accounts with permissions to add users. We did have SQL accounts for the application but they were not useful since they have minimal permissions to run the application.
After several different attempts using various things such as different super accounts, IP address and even a little FM nothing worked. I started to search on Google and found this post.
It turns out there is a tool that works very nicely and very quickly I might add. PsExec from Windows Sysinternals is the tool you need and can be downloaded from here (http://technet.microsoft.com/en-us/sysinternals/bb897553)
Shawn Melton blog | twitter is the one pointing out the tip in the previously mentioned link. Now following on twitter. Thanks Shawn
Using the tool is just as simple. Open a command prompt and execute the following command
PsExec – i – s SSMS.exe
-i runs the program the program so it interacts with the desktop of the specified session on the remote system. If there isn’t a session specified the process runs in the console session.
-s Runs the remote process in the System account.
SQL Server Management Studio will open with elevated permissions and allow you to add the accounts needed in order to manage the server properly.
Conclusion
While the fix for this particular situation was a fast and easy one it does not diminish the fact that things were done by a system administrator with one of my SQL Servers and without my knowledge. Had I been properly looped into the conversation I could have prevented any of this from happening. Hopefully others will learn from this. I have even written this up and posted internally on the SAs best practice list.
Cheers!
SQLAJ 