Wade Wegner

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.

1. Go to Start -> Run.
2. Type: gpedit.msc
3. Expand Local Computer Policy -> Computer Configuration -> Windows Settings -> Security Settings -> Local Policies -> Audit Policy.
   
   
   
4. Review the "Audit process tracking" policy.
5. Right-click the "Audit process tracking" policy, and select Properties.
6. On the Local Security Setting folder, check the "Success" and "Failure" checkboxes under "Audit these attempts".

   

7. 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 Files\Microsoft Great Plains\eConnect9\XML Sample Documents\Incoming) 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_ROOT\CID

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

1. Use Add Windows Components, and remove Network DTC.
2. Go to the command line and run: MSDTC -uninstall
3. 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 (if they're still there).
4. Reboot
5. Go to the command line and run: MSDTC -install
6. Use Add Windows Components, and add Network DTC.
7. 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!

I encountered an error today while setting up a project within the Commerce Server Staging.  I haven't encountered it before, which leads me to believe that I must have done something abnormal on my development virtual machine.

Commerce Server Staging (CSS) is a service that allows you to synchronize content and data between many separate environments. Utilizing CSS, you can reliably update both Web content and business data from the source to one or more destinations.

Using the CSS MMC, I created a simple project that stages my StarterSite content from my local directory (e.g. C:\Inetpub\wwwroot\StarterSite) to a temporary folder (e.g. C:\Temp\Destination).  It was meant to be the start of a proof-of-concept for a more complex network topology.  However, I almost immediately received an error when I attempted to start replication:

I just love errors like this!  Gives me something to research and figure out ...

Fortunately, more valuable information was added to the application log:

Event Type:    Error
Event Source:    Commerce Server Staging
Event Category:    None
Event ID:    61208
Computer:    CS2007
Description:
Error occurred with the database StagingLog.mdb.  Error is: System.Data.OleDb.OleDbException: Operation must use an updateable query.
   at System.Data.OleDb.OleDbCommand.ExecuteCommandTextForSingleResult(tagDBPARAMS dbParams, Object& executeResult)
   at System.Data.OleDb.OleDbCommand.ExecuteCommandText(Object& executeResult)
   at System.Data.OleDb.OleDbCommand.ExecuteCommand(CommandBehavior behavior, Object& executeResult)
   at System.Data.OleDb.OleDbCommand.ExecuteReaderInternal(CommandBehavior behavior, String method)
   at System.Data.OleDb.OleDbCommand.ExecuteNonQuery()
   at Microsoft.CommerceServer.Staging.Internal.ProjectDeploymentLog.ModifyLog(String projectName, String status).

While this isn't the most explicit error, it provided enough information to track down the problem.

You might be surprised to see that this error refers to an Access database.  CSS makes use of Access database files to store events and information it audits during the staging process.  Specifically, there are these two Access database files:

• StagingLog.mdb
  • Found here: C:\Program Files\Microsoft Commerce Server 2007\Staging\Data
  • Stores internal replication information used by CSS
• events.mdb
  • Found here: C:\Program Files\Microsoft Commerce Server 2007\Staging\Events
  • Stores staging information that is made available to reports

Searching on the keywords "mdb operation must use an updateable query" led me to KB article 175168.  This article indicated that the problem is most likely caused by a user not having the proper permissions to open the StagingLog.mdb file.

In comes File Monitor (aka FileMon), by SysInternals, to the rescue.  Seriously folks, save yourself the agony and get to know the tools available from Microsoft and SysInternals.

I was able to capture the following "Access Denied" message via File Monitor:

Solution: Turns out that the NT AUTHORITY\NETWORK SERVICE has been attempting to open the StagingLog.mdb file to no avail.  After giving the NT AUTHORITY\NETWORK SERVICE the rights to Modify the StagingLog.mdb file ...

... I am now able to successfully start my CSS project and stage my StarterSite data to a separate folder.

UPDATE: Rather than only giving access to the StagingLog.mdb file, give the NETWORK SERVICE account access to the entire Data folder where the MDB file is located.  Otherwise it will have issues trying to write out an LDF (Access log file) file when updates are made.

Hopefully this not only helps someone resolve this particular problem, but also shows how useful it is to equip yourself with good debugging tools!

Good luck!

As a consultant, I often have to spend a great deal of time diagnosing issues that are confronting my clients.  Over the years I've used some of the tools available from Sysinternals, but I honestly never put a lot of energy or time into really learning to use them.  On my most recent project, however, I've found them to be tremendously helpful, and I'm now a confirmed believer!

There are a number of useful tools available, and I don't profess to have used or mastered them all.  There are a few, however, that I strongly encourage you to familiarize yourself with:

• Process Monitor - This montioring tool monitors the file system, Registry, processes, threads, and DLL activity in real-time.  Ever need to track down where data is getting written?  Ever wonder why you try to write or read from the Registry and receive errors?  This utility will help you track that down.  Process monitor is a combination of two older tools (Filemon and Regmon), and adds a whole slew of additional features such as rich and non-destructive filtering, comprehensive event properties such session IDs and user names, reliable process information, full thread stacks with integrated symbol support for each operation, simultaneous logging to a file, and more.

• Process Explorer - Find out what files, registry keys and other objects processes have open, which DLLs they have loaded, and more. This utility will even show you who owns each process.  This tool is excellent for tracking down programs or processes that have locked files and directories.  It also has some powerful search capability that shows you which processes have handles opened or DLLs loaded.

• BlueScreen Screen Saver - Okay, so this isn't a monitoring tool, but it's part of the Sysinternals suite and it's great!  Just load this up as the screen saver for your favorite person at work, sit back, and enjoy the show!

Take the time to explore the various tools that are available on the Sysinternals Web site.  There are a lot of tools that will make debugging and problem solving less of a hassle.

Best of luck!