Don't DCPROMO your BizTalk database server

When you have a bunch of Virtual PCs on your machine for testing, you do find that they get used for a lot of tests unrelated to the initial reason you set them up (BizTalk in this case).

So I had a problem I wanted to look into that required two domain controllers. Obvious choice was the SQL server as all I used it for was hosting the BizTalk databases. Bad choice.

When I later came round to doing some BizTalk testing, the Admin console complained that it could not contact the local SSO server because there were "no more endpoints available from the endpoint mapper". RPC troubleshooting is not fun - the errors never seem to be helpful.

Looking in the event log I could see that the ESSO Service had failed to start (Srrvice Control Manager event 7023). Being unable to contact the SSO database was my first useful lead:

Reviewing the security on the database stored on the remote SQL server, I can see that the group for deciding access is an old pre-promotion one.

When you promote a server to a domain controller, the local Security Accounts Manager (SAM) database is replaced by a domain-wide repository instead. Unfortunately, SQL Server is unaware of this change so keeps the now invalid "SSO Administrators" entry.

Deciding that I didn't want to go through SQL Server Management creating replacement security settings by hand, I decided to reconfigure ESSO from scratch. Or tried. Looked like I also had problems with AD as well so I removed the domain controller role before removing/adding the SQL server back into the domain. Brute force techniques for when time is at a premium.