Troubleshooting « Wade Wegner

Now that we can get our hands on the Windows Developer Preview of Windows 8, I’m sure everyone is excited to start building applications! For many of us, this means that we’ll want to install all of the great Windows Azure tools on our Windows Developer Preview machine – especially if we plan to take advantage of the new Windows Azure Toolkit for Windows 8. However, there are a few things we’ll need to do in order to get things to work.

Quickly let me explain the three challenges you’ll run into:

The current Windows Azure Tools for Visual Studio do not yet support Dev11 – you’ll have to install Visual Studio 2010.
There are a few quirks getting dependencies for IIS installed on Windows 8 using the Web Platform Installer.
After Visual Studio 2010 and the Windows Azure Tools for Visual Studio are installed on a machine with Dev11, the Windows Azure tools will grab an environmental path variable that points to 11.0 instead of 10.0.

Fortunately, these things are pretty easy to resolve and will certainly get addressed in later builds.

Here’s what you’ll have to do to get the tools and SDK working with the Windows Developer Preview:

Install Microsoft .NET Framework 3.5.1. Easiest way is to type “Windows Features”, select Settings, and select Turn Windows features on or off. Then simply check the checkbox. Click OK to install.
Next we need to correctly configure IIS. Typically we’d do this through the Web Platform Installer, but this doesn’t work correctly on Windows 8. From Turn Windows features on or off you’ll need to do the following, then click OK to install.
- Check Internet Information Services.
- Expand Internet Information Services and World Wide Web Services.
- Expand Application Development Features and check ASP.NET 2.0, ASP.NET 4.5, and CGI.
- Expand Common HTTP Features and check HTTP Redirection.
- Expand Health and Diagnostics and check Logging Tools, Request Monitor, and Tracing.
Install the Web Platform Installer (WebPI).
Install Visual Web Developer 2010 Express through WebPI. (You can use a different version of Visual Studio 2010, so long as it’s supported by the Windows Azure Tools for Visual Studio.)
Install Windows Azure Tools for Microsoft Visual Studio 2010 – September 2011 through WebPI.

Okay, now you have everything installed. However, before you trying running Visual Studio, you have to create a script to launch Visual Studio 2010. This is because the Windows Azure tools use an environmental variable that’s incorrectly pointing to version 11.0, and we’ll need to change it right before we launch to version 10.0 (for Visual Studio 2010).

@ECHO OFF

SET VisualStudioVersion=10.0

SET VisualStudioPath="%ProgramFiles(x86)%\Microsoft Visual Studio 10.0\Common7\IDE"
IF NOT EXIST %WINDIR%\SysWow64 SET VisualStudioPath="%ProgramFiles%\Microsoft Visual Studio 10.0\Common7\IDE"

CD /D %VisualStudioPath%

VWDExpress.exe

As you can see, the script changes the VisualStudioVersion to 10.0 then launches Visual Web Developer Express (there’s a little extra code to set the path correctly regardless of 32- or 64-bit versions of Windows).

Save the above script as a CMD file (i.e. OpenVisualStudio2010.cmd) and then make sure to right-click and Run as administrator! If you forget to run the script as administrator then Visual Studio won’t have the permissions needed to run the Windows Azure tools correctly.

Look, it’s working!

NOTE: I found myself having to reboot Windows 8 in order to resolve a problem where the debugger wouldn’t attach. Not sure if this occurs every time, but in case you have a similar issue just try rebooting.

I hope this helps!

A neat trick to help you diagnose troublesome security problems. Modify your the audit settings for process tracking, so that successes and failures are logged in your Security log.

Go to Start -> Run.
Type: gpedit.msc
Expand Local Computer Policy -> Computer Configuration -> Windows Settings -> Security Settings -> Local Policies -> Audit Policy.
Review the “Audit process tracking” policy.
Right-click the “Audit process tracking” policy, and select Properties.
On the Local Security Setting folder, check the “Success” and “Failure” checkboxes under “Audit these attempts”.
Click OK to continue.

If you define this policy setting, you can specify whether to audit successes, audit failures, or not audit the event type at all. Success audits generate an audit entry when the process being tracked succeeds. Failure audits generate an audit entry when the process being tracked fails.

These audits are now tracked in the Security log in the Event Viewer. Here’s an example of a “Detailed Tracking” event.

Some additional details can be found on TechNet.

Pretty easy to configure, and very useful when you’re trying to figure out why applications are not running appropriately and you think it might be related to security issues.

I was able to use the XML sample documents that come with eConnect (C:Program FilesMicrosoft Great PlainseConnect9XML Sample DocumentsIncoming) to write some test data into my GP database using the eConnect 9.0 adapters for BizTalk Server 2006. I setup a test environment using the TWO database for Great Plains, and through the adapter was able to insert data. Feeling that I had made some good progress, I shutdown my machine (they are all virtualized environments) and went home for the night.

When I started everything up the next day I tried to reproduce this behavior so that I could move on with my integration. However, every time I tried to write the document into GP through the adapter, I got the following error:

Event Type:    Error
Event Source:  BizTalk DW Reporting
Event ID:      1000
Description:   Faulting application btsntsvc.exe, version 3.5.1602.0, stamp 4410e6b9, faulting module kernel32.dll, version 5.2.3790.4062, stamp 46264680, debug? 0, fault address 0x0000bee7.

This had me stumped for a little while. I decided to use a useful tool I received from Microsoft called the Direct Document Sender.NET (I’ve attached the file at the bottom of this post) to try and diagnose the problem. This tool allows you to post an XML document directly to eConnect so that you can test out the functionality without any 3rd party application (e.g. BizTalk Server).

Using this application, I tried to post the XML file again. This time I received a much more useful error:

System.Runtime.InteropServices.COMException (0x8000401A): The server process could not be started because the configured identity is incorrect. Check the username and password.

Aha! This was a much more useful error!

I opened up Component Services (Start –> Administrative Tools –> Component Services), and browsed to Computers –> My Computer –> COM+ Applications –> eConnect 9 for Great Plains. The Microsoft Great Plains eConnect Version 9 COM Plus Package has a tab entitled Identity which allows you to define the user account under which the application runs. Turns out that somehow my account was switched from the user I specified at installation to the interactive user system account:

And this was the root cause of my problem. eConnect requires integrated security and uses the user specified in this identity tab to access the GP database. Consequently, the user specified must have access to the appropriate database on the GP server and also be a part of the DYNGRP role.

So, I went ahead and added my user to the DYNGRP role, made sure it had the appropriate access, and then updated account used by the COM+ package:

Having made these changes, I tested with the Document Sender.NET application – worked the first time! Confidently I tested with BizTalk, and sure enough everything started to work!

I’m not sure why it initially worked and then stopped working after I restarted the machines. I’m not sure if the account credentials changed or if something else was happening the first time. All I know is that you have to use an appropriate user that has access to the database and is a member of the appropriate role, otherwise you’ll get the errors I listed above.

I hope this helps!

DirectDoc9.zip (7.42 KB)

Lately it seems that I have had to acquire a lot of hotfixes for Microsoft products. Unfortunately, most of the KB articles don’t provide a link to the hotfix, but instead ask you to contact Microsoft Support (via phone) to acquire the hotfix. Kind of a pain!

Fortunately, my friend Rich Finn just passed along this useful link:

Hotfix Request Web Submission Form

Very useful … no longer will I have to reach out an contact individual escalation engineers I’ve worked with in the past. <sheepish grin>

I came across a ~~frustrating~~ interesting problem today where the BizTalk Server 2006 Configuration wizard would fail every time I applied a new configuration.

Unlike a typical BizTalk developer environment (which usually consists of BizTalk and SQL Server on the same machine), this environment consisted of two separate machines: one BizTalk Server 2006 and one SQL Server 2005 (i.e. the BizTalk databases are stored on the SQL Server). Additionally, this is a virtual environment and both machines were cloned from the same base Windows Server 2003 R2 template.

I was installing the following components …

Enterprise Single Sign-On (SSO)
Group
BizTalk Runtime
MSMQT

It would successfully install ENTSSO, but would fail when installing the group. The log file reported the following error:

Failed to configure with error message [Exception of type 'System.EnterpriseServices.TransactionProxyException' was thrown.]

The following Google search suggested to me that the underlying problem was with MSDTC (aren’t all BizTalk problems?). I checked, and double-checked, the MSDTC properties on both servers and couldn’t find anything wrong with the configuration. So, I had to pull out the big guns.

I downloaded DTCPing (a very handy tool for debugging DTC issues) and ran it on both machines (make sure to read the instructions on how to use DTCPing as it is not straightforward). In the generated log file I noticed the following warning:

WARNING: the CID values for both test machines are the same while this problem won’t stop DTCping test, MSDTC will fail for this …

A Google search on this warning helped me to understand that the underlying problem is that the CID values stored for MSDTC were not changed during the cloning process. But of course!

If you’re experiencing this problem, check the following registry key on both of your machines. Are the keys identical?

HKEY_CLASSES_ROOTCID

Mine were. Here’s the steps I took successfully reinstall MSDTC so that the CID values were unique. Run this procedure on both machines:

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_ROOTCID (if they’re still there).
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

After running this on both servers I was able to confirm that the CID values were unique. And, sure enough, when I next applied my configuration to BizTalk Server 2006 everything worked perfectly.

I hope this helps!

Wade Wegner

From the whiteboard to the keyboard

Category Archives: Troubleshooting

Running the Windows Azure Tools & SDK on the Windows Developer Preview

Using the Audit Policy to diagnose security problems

BizTalk process crashing with eConnect 9 adapter

Microsoft Hotfix Request Web Submission Form

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