BizTalk 2004, XP SP2 and being Google-challenged
A few days ago I upraded my tablet to XP SP2 RC1 because I was really itching to try out the new input panel (yup, it rocks!).
Today I got back to working on my BizTalk project after doing something else last week only to find out that I could no longer install an orchestration from an msi installation package based on the BTSInstaller sample in the SDK I had built before I went to TechEd.
The log file generated by the msi installation read:
Unspecified exception: Could not retrieve transport type data for Receive Location 'Receive Location2' from config store. Access is denied.
So I start digging around on my computer ... what's wrong with the config store? At this point I am very confident that BizTalk Exlorer in VS. NET will tell me. Nope, Wrong! When I try to look at my Receive Locations, I get an Access Denied message from the IDE. I try the Send Ports node ... same message. I am getting a little nervous now ... did I fall victim to premature OS installation? Did one of these horror stories that end with spending a weekend rebuilding a machine from scratch happen to me? It can't happen to me, I tell myself. I ran Windows 2003 since 2001 without a problem. It's just some configuration issue ... I try the BizTalk Admin Tool -- SAME ERROR. This time the error message hints at the WMI provider being the culprit.
No big deal ... I wrote plenty of WMI providers on a previous project. I defeated DCOM in the past, I can fix this! I open the handy CIM Studio from the WMITools download and I confirm that the WMI provider is indeed the culprit. Now if I would just figure out what's causing it.
It's definitely time to google for an explanation. Google, the trusted guide of so many developers out there will prove it's value again. Finally, with some help from Peter Provost, supreme Google master, and kirke (pronounced kirk-eeee) I finally came across this posting on ScottWoo's blog, which correctly states the problem, but isn't quite accurate about the solution.
The fix is not another registry key. It's a REG_DWORD value, EnableAuthEpResolution, under the \\HKLM\SOFTWARE\Policies\Microsoft\Windows NT\RPC key. Setting the value to 1 *and* a swift miracle cure (aka reboot) fixes the problem. The new registry setting is explained on the Microsoft web site as part of the Network Protection Technologies new in XPSP2.
Probably the easiest way to enter the missing value is to paste the few lines below into a file with a .reg extension and then double clicking the file into the registry:
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\RPC]
"EnableAuthEpResolution"=dword:00000001