Installing BizTalk on cloned Virtual Machines

Subtitled: The dangers of virtualization and how I stepped in deep DTC doo

I was doing a BizTalk installation this week.  I’ve done hundreds of them and they normally well.  There are almost always problems, but I’ve seen most of them so I know how to work around them.  Common issues are DTC or security related.  I’ve worked through tons of those.  The SQL install went well.  I was using Windows Server 2008 R2 Enterprise all around and SQL 2008 Server 2008 R2 Standard.  I was trying to install BizTalk 2010 Standard.  Both servers, SQL and BizTalk, were VMs.  When I tried to configure BizTalk to blew up on the BizTalk Group.  Digging into the error log I found this gem buried in the trace:

AdminLib GetBTSMessage: hrErr=80070002; Msg=The system cannot find the file specified.;

The install would also fail to delete the BizTalkMgmtDb, which was a hassle as I had to manually delete it every time. 

Now this isn’t my first rodeo so I already know MSDTC problems are extremely common in distributed BizTalk installations.  I broke out DTCPing and it passed fine.  I also saw this blog explaining exactly the same issue:

http://serverchronicle.blogspot.com/2011/02/adminlib-getbtsmessage-hrerr80070002.html

This too pointed to a DTC issue, but the DTCPing passed.  I tried all the possibilities listed in

Troubleshooting Problems with MSDTC but still had no luck.  Because I wasn’t using a domain admin account (a common request from customers) I had pre-provisioned all the users and groups.  I decided I’d break our subinacls.exe to try to explicitly grant Network Service the access needed for DTC.  To my surprise I received an access denied error when running this. 

I eventually decided try the install with a domain admin account.  That also failed, with the same error.  Now I was getting frustrated.  I reran DTCPing and noticed a warning in the output:

WARNING: the CID values for both test machines are the same

This told me a little something I had overlooked.  I asked the administrator who provisioned the boxes if they’d been sysprepped and if they were from the same image.  The answer to the second question was yes, the answer to the first was no; these machines had not been sysprepped.  I wasn’t sure how important this was because Mark Russinovich had pointed out three years ago that NewSID wasn’t really necessary anymore.  But now I had something concrete.  SIDs might be able to be duplicated, but I didn’t know about CIDs, which are Computer IDs. 

On the advice of another senior architect at West Monroe Partners I uninstalled MSDTC from the command line: msdtc –uninstall.  I also deleted most of the MSDTC registry keys I could find.  I then rebooted and reinstalled MSDTC.  Like magic, the configuration worked.  Amazing!

Advertisements