“You are making my point!”

All is not lost if you see the above error message when trying to connect to a remote desktop session. If you happen to have access to a command line window on a server that’s on the same network as the terminal server, you can try the following command line:

Look up session id:

C:\>query session /server:<server name or ip>

Terminate a session:

C:\>reset session [session Id] /server:<server name or ip>

Now you just freed up a connection for your remote desktop session.

I needed to do some custom pipeline work using CForwardOnlyEventingReadStream class. And I spent nearly 10 minutes searching for Microsoft.BizTalk.Streaming.dll. It is frustrating to see it seems changing location in GAC in every release. Why could we just put in the BizTalk installation directory as all the other DLLs are?

Anyways, here it is: “C:\ Windows\ assembly\ GAC_MSIL\ Microsoft.BizTalk.Streaming\ 3.0.1.0__31bf3856ad364e35″. Note that the only way to reference it is to fish it out of GAC using elevated command line as shown below.

BTW, if you are curious why I need this DLL, or if you haven’t used/heard of this DLL before, you need to do some digging. This is the single most important DLL when programing BizTalk pipeline components. See Optimizing Pipeline Performance.

Happy streaming in BizTalk Pipeline!

During a technology briefing session today I was speaking with customers about BizTalk Mapper capabilities in Visual Studio. And a question came up that was related to how to map multiple source schemas to a single destination schema, or even multiple destination schemas. It does not seem to be a well known fact that BizTalk can handle this so I figured it is worth blogging about it.

If you are already familiar with the BizTalk Mapper tool within Visual Studio, you probably already know that it is easy to create a .btm map file in the BizTalk project, select a single source schema and a single destination schema, and then create your map graphically. However, what if you have multiple schemas that you want to aggregate them into a single destination schema, or better yet, into multiple destination schemas. It is not obvious how you can accomplish this in the mapping tool since it doesn’t seem to allow you to select more than one schemas, either source or destination, when you create the map. Actually, this can be accomplished with the help of an helper orchestration.

Here are the steps as an example:

1. Create 4 schemas, name them source1, source2, destination1 and destination2 respectively.
2. Instead of creating a map file (.btm) directly, create a new orchestration (.odx) file. This will be your helper orchestration and you can discard it after you are done.
3. Inside the helper orchestration, create 4 messages, assigning them with the 4 schemas you create in step 1 respectively.
4. Grab an Transform shape and throw it onto the orchestration designer surface.
5. Double-click on the Transform shape, now you are in the Transformation Configuration dialog box.
6. Make sure “New Map” checkbox is selected, then type in the map name you’d like.
7. Add source1 and source2 messages as the Source of the Transformation.
8. Then add destination1 and destination2 messages as the Destination of the Transformation.
9. Make sure “When I click OK, launch the BizTalk Mapper” checkbox is selected.
10. Hit OK. A new map will be created for you with Source1 and Source2 as source schemas under a single root record, and destination1 and destination2 as destination schemas under a single root record as well. Now you can go ahead design this map to your heart’s content.
11. Optionally, again, you can delete the helper orchestration.

Unfortunately there is still no direct way to create this kind of maps in BizTalk Mapper. But with the help of an orchestration Transformation shape you can accomplish this as a work-around.

I am presenting on 10/14/2009 at the Boston .NET User Group. Check out the announcement here. We will be covering BizTalk and its ESB capabilities. Hope to see you there!

One of the steps for installing Microsoft ESB Toolkit 2.0 is to deploy the BAM definition for exception management. Essentially you need to run the following command line.

Bm.exe deploy-all -DefinitionFile: “C:\Program Files\Microsoft BizTalk ESB Toolkit 2.0\Bam\Microsoft.BizTalk.ESB.BAM.Exceptions.xml”

If you run into the following error (which I did), it is obvious that it is a permission issue.

It turns out that the service account you run your SQL Server needs to have read/write access to your BAMStarSchema database. In my case, since I am on a DEV box, I simply slapped “db_owner” role onto “Network Service” (which is my SQL Service Account) to the BAMStarSchema database and the BAM deployment went through without problems.

There are over 500 BizTalk hotfixes that have been released. So how do you quickly find the ones that apply to your specific version and service pack releases of BizTalk server? Well, Check out this great post by Michael Shea. I am also going to steal his keywords and list them down here.

http://support.microsoft.com/search/default.aspx?mode=r&query={keyword}

kbBizTalk2000SP1fix

kbBizTalk2000sp2fix

kbBizTalk2002preSP1fix

kbBizTalk2000preSP2fix

kbBizTalk2002SP1fix

kbbiztalk2004sp1fix

Kbbiztalk2004sp2fix

kbBizTalk2000SP1afix

Kbbiztalk2004presp3fix

Kbbiztalk2006presp1fix

Kbbiztalk2006r2presp1fix

kbbtsAdapters

kbBTSMessaging

kbBTSHat kbBTSPipeline

kbBTSOrchestration

kbBTSAdmin

kbBTSMapper

kbBTSBAM

If you are running Visual Studio 2008 developing BizTalk 2009 projects, and all of a sudden you find that your Visual Studio fails to create new BizTalk projects, don’t panic. This is a known issue. Apparently one of the recent Visual Studio patches (mostly likely automatically downloaded and applied to your machine) has a bug. It accidentally removes “.btproj” from the project extension setting in a Visual Studio registry key.

You can either fix this key manually (quick but you need to know what you are doing), or simply run the installation of BizTalk SDK in repair mode (less risky but takes a while). You can find the details here in BizTalk Customer Response Team’s blog.

If you have seen the above annoying error recently while installing some software packages (Azure SDK, BizTalk Adapter Pack, etc.) in a Virtual PC environment, you are not alone. This is due to an MSI bug, or so I was told. People have come up with all kinds of solutions, but the one that I have found out so far that consistenly works is the following.

Go to command line in elevated security mode, and type:

msiexec.exe -package MyPackage.msi -qr

This will basically run the installation package in quiet mode with reduced UI, and apparently circumvent the bug.

When configuring Windows Clustered BizTalk host, one very important resource that needs to be clustered as a prerequisite is the Microsoft Distributed Transaction Coordinator, or MSDTC. Here are a few links to help troubleshooting MSDTC.

Troubleshooting Problems with MSDTC

Troubleshooting MSDTC with DTCPing

How to use DTCTester Tool

One of the most common errors that I have seen can be linked to the proliferation of virtual machine technology. People simply copy the virtual hard disk (vhd) file containing the base Windows OS, boot it up, and then install BizTalk server on it. Well, the problem is that the System security identifier (SID) created by Windows OS in this case is also simply replicated in this case. And this ID happens to be the token MSDTC uses to identify cluster nodes. With these numbers replicated across the cluster nodes, MSDTC will get confused and your distributed transactions will stop working.

Hence, it is very important to remember using the SysPrep tool to reseal your Windows OS images before installing any software. Using NewSID utility to regenerate new SID after the fact may work but it requires you reinstalling MSDTC. In my opinion it is best to do SysPrep prior to installing anything to ensure that your new OS is truly unique. This could prevent a lot of head-scratching at 3 o’clock in the morning. J

Here is a good article covering the subject of creating and configuring a two-node W2K3 cluster on Virtual Server. Due to the limitation of no SCSI support on Virtual PC, this would not work on VPC.

Oh, one other thing. If you are using IE8, make sure you turn on the “Compatibility View” setting when accessing the Virtual Server admin page. Otherwise you will get all kinds of JavaScript errors that virtually renders the admin page useless.