BizTalk Setup Error

Error 1928. error registering COM+ application. Contact your support personnel for more information.
Error 5003. Regsvcs failed for assembly c:\program files\Microsoft Biztalk Server 2004\Microsoft.Biztalk.Deployment.dll. Return code 1. (BizTalk SP1)

I ran into the above error while installing BizTalk 2004 dev/sdk components onto my windows xp/sp2 box and spent a few hours debugging the problem and managed to find a workaround. The problem stems from overly tight default permissions on keys created under HKLM\software\classes during the install. I have no clue [yet] why this happens, but the workaround is to run biztalk setup under the localsystem account rather than an administrator.

The easiest way you can do this by downloading one of the inimitable Mark Russinovich's tools called PsExec from and run the following command:

c:\> psexec -s -i d:setup

where d:setup in this case presumes your biztalk install CD (or path to SP1 installer) is in drive D: the -s param means run under localsystem, and -i allows setup to interact with the desktop. Yes, the other option might be to use XP's runas command, but I don't know of any easy way of finding localsystem's password ;-)

I've only tested this by installing the development and sdk components onto a windows xp sp2 machine with visual studio 2003, since my actual biztalk server & sql db runs in a virtual server windows 2003 instance on my development box.

Initial Research

After a few hours debugging, I'd narrowed the problem down to a registry permission problem which causes the MSI execution step in question to fail badly: the step "regsvr32 XLANGByotWrap.dll" fails with 0x80070005 which we all know is "access is denied."

I used regmon and filemon (again from sysinternals) to monitor the install process -- I chose minimum install of dev/sdk via custom install -- and noticed that at some point before the regsvr32 step in question is executed, the following two important keys are created:


...and this is the killer, because this happens BEFORE the regsvr32 command is executed. The MSI gives "Administrators" read perms only (but SYSTEM gets "full control") on these regkeys, which is why the subsequent regsvr32 step fails, which tries to register the com server XLANGByotWrap.dll under these keys. You can verify this yourself by leaving the error dialog open (if you close it, the MSI will roll everything back) and dropping to the install directory and typing:
regsvr32 XLANGByotWrap.dll
You'll see that it fails with 0x80070005. Go into regedit, change the perms for Adminstrators to "Full Control" and re-run the command: Success.

I have no idea why these keys are created pre-registration, and with the incorrect perms, but it's possible to work around this issue by creating the keys with the correct perms yourself BEFORE you run setup; export the keys to xlang.reg and reimport them (after you have finished running the failed setup attempt the first time) via regedit's File|Import. The next step is change the permissions on both keys so that your own account is replaced with "administrators" and with "full control."

So, great stuff. I fire up setup myself, and lo and behold, it successfully makes it past the previous failure point only to cough up:

Error 5003. Regsvcs failed for assembly Microsoft.BizTalk.Deployment.dll. Return code 1.

Argh. So, guessing that this is more of the same malarky, I drop to a cmd prompt and try to run the command manually (while leaving the error dialog open
again) to see what the problem is:

[E:\Applications\Microsoft BizTalk Server 2004] regsvcs Microsoft.BizTalk.Deployment.dll
Microsoft (R) .NET Framework Services Installation Utility Version 1.1.4322.573
Copyright (C) Microsoft Corporation 1998-2002. All rights reserved.

The following installation error occurred:
1: Failed to register assembly 'Microsoft.BizTalk.Deployment, Version=, Culture=neutral, PublicKeyToken=31bf3856ad364e35'.
2: Access to the registry key HKEY_CLASSES_ROOT\Microsoft.BizTalk.Log.LogException is denied.

Yep, it's the registry again. Bizarre. Again, the solution is to create the key yourself before you run setup. Since HKCR is a union of HKCU and HKLM, I had a look for the key under HKEY_LOCAL_MACHINE\Software\Classes where I found it. I also found a shedload of other keys, again with read-only perms for Adminstrators. I thought to myself, eh, I could just recreate the single key in question, but I figured I\'m probably going to get more than a couple of these errors, so I should export all Microsoft.Biztalk.* keys and recreate them with the proper perms before running setup again.

*** and at this point while I considered the pain of exporting a few hundred registry keys I had the idea of using PSEXEC to run the setup under the localsystem account ***

Anyway, I hope this was interesting to someone.

blog comments powered by Disqus

About the author

Irish, PowerShell MVP, .NET/ASP.NET/SharePoint Developer, Budding Architect. Developer. Montrealer. Opinionated. Montreal, Quebec.

Month List

Page List