Before I forget to do this I wanted to post about this issue because it cost me a 1/2 day of debugging and I hope to save you this agony. It actually turns out there's a nasty little issue when you use Virtual Server 2005 differencing disks to quickly stand up lab enviorments. In my new role with Microsoft support I'm constantly setting up 1, 2, 3, and sometimes 4 node lab environments so differencing disks are pretty much a must. Of course if you want to do this and still need the ability to join these servers to a test domain, then you have to make sure you rename / resid them. That's where I've always relied on newsid from the sysinternals tools.
I've always wondered if this was a hack (versus a full sysprep) and I wondered when it would jump up and bite me. I noticed in IIS that the anonymous user account does not get recreated to use the new computer name but that's never impacted me (I sort of figured a local account really isn't going to make much of a diff). Well, I have now finally found an issue that is ugly. It turns out that if you are going to build an app server / db server both from the same base OS image you are going to have some issues with MSDTC. I ran into this as I started to run through the BizTalk configuration tools. I kept getting the following error:
2008-07-08 17:44:58:0896 [ERR] WMI Failed in pAdmInst->Create() in CWMIInstProv::PutInstance(). HR=c0c025b3
2008-07-08 17:44:58:0906 [ERR] WMI WMI error description is generated: Exception of type 'System.EnterpriseServices.TransactionProxyException' was thrown.
2008-07-08 17:44:58:0936 [INFO] WMI CWMIInstProv::PutInstance() finished. HR=c0c025b3
[5:44:58 PM Error BtsCfg] d:\depot2300\mercury\private\mozart\source\setup\btscfg\btswmi.cpp(358): FAILED hr = c0c025b3
[5:44:58 PM Error BtsCfg] Exception of type 'System.EnterpriseServices.TransactionProxyException' was thrown.
At least this error helped me narrow down the root cause of the problem which is obviously System.EnterpriseServices. So I started looking at all my settings for MSDTC and nothing seemed out of the norm. All the right security settings and network dtc access settings were there. So it was time to do a quick search with live.com (that's right ... I said live.com ... google is so 5 years ago :)
It turns out the problem is with the underlying CID settings for MSDTC. It looks like newsid doesn't go in and take care of these. Fortunately I wasn't the first one to come across this because I don't know if I would have come up with these steps. A big bravo goes out to Wade Wegner who wrote a great overview of the problem and the steps to fix it. You can read the full description and steps to identify wether or not this is your issue here: http://blog.wadewegner.com/2007/08/13/quotWarningTheCIDValuesForBothTestMachinesAreTheSamequot.aspx.
If you just want the solution you can follow these quick steps on both machines. (taken from Wade's blog).
- Use Add Windows Components, and remove Network DTC.
- Go to the command line and run: MSDTC -uninstall
- Go to the registry and delete the MSDTC keys in HKLM/Software/Microsoft/Software/MSDTC, HKLM/System/CurrentControlSet/Services/MSDTC, and HKEY_CLASSES_ROOT\CID. *
- Reboot
- Go to the command line and run: MSDTC -install
- Use Add Windows Components, and add Network DTC.
- Go to the command line and run: net start msdtc **
* for me the CID settings were deleted when I did the -uninstall so you shouldn't need to remvoe the last ones. Also, this does mean you should delete the key at the top level and purge all the subkeys, that freaked me out a little at first but of course we're just talking about a test lab here so I figured why not try it. It worked like a champ.
** This step wasn't required for me as the service was already running following me adding the network DTC access from the windows components installer.