Kevin Lam has decided to start his own blog. He’s been on the team for a while now and is one of the product team’s frontline guys. He is the guy out there working with the big customers, helping with their designs, getting there stuff into our labs, asking the questions and making sure we keep the customer focus. I recommend reading his blog.
Kevin Lam has decided to start his own blog. He’s been on the team for a while now and is one of the product team’s frontline guys. He is the guy out there working with the big customers, helping with their designs, getting there stuff into our labs, asking the questions and making sure we keep the customer focus. I recommend reading his blog.
I recently went through a really nast bout of troubleshooting with the client I currently
work with, related to MSMQT. Hopefully, my tale can save you similar pain.
The core issues was this: The BizTalk MSMQT adapter can be configured during installation
to integrate with Active Directory. The default is that it will not operate
in this fashion, but rather in “workgroup” mode. There are (at least) two reasons
why you might want to have MSMQT integrate with Active Directory: 1) you want to make
use of an MSMQ router in your environment or 2) you want to use certificate-based
authentication at a protocol level (where the public certificate is managed by AD.) (Note:
I know this now; I didn’t know it a couple weeks ago…)
We have been installing our servers in “workgroup” mode. To install in Active
Directory mode requires a special permission granted by the domain administrator.
Now, when you a configure a Send Port within BizTalk and select MSMQT as the transport,
the property pages in the BizTalk Explorer offer a checkbox that is labeled “Use MSMQ
Authentication”. If you hit the “Help” button on this dialog, the explanation
that is provided is this: “Identify whether BizTalk Message Queuing uses protocol
authentication every time it sends a message on this port.”
As it turns out, although it isn’t documented as such, a Send Port with this
option checked can only work if MSMQT has been installed in Active Directory-integrated
mode. If you have the “Use MSMQ Authentication” option checked on a Send Port
and you are not in Active Directory-integrated mode, then messages will not flow.
When we eventually discovered this discrepency and fixed our bindings files, the problem
was resolved. (Note: there is a similar option when configuring Receive Locations.)
This checkbox had been checked at the point our initial binding files were exported,
and became a part of our scripted deployment. What was worse, when we encountered
this problem a few weeks ago in QA, we began troubleshooting the BizTalk configuration
on the server directly and wound up “fixing” the problem by creating an additional
Send Port (subscribing to the same traffic as the original) that simply had the MSMQ
Auth checkbox off. But we didn’t realize that discrepancy at the time, so we
had to troubleshoot the same problem all over again a few weeks later. We definitely
got ourselves into the wrong troubleshooting mindset by assuming that Biztalk was
flaky in some way.
Key lesson: If you don’t get into a given environment (QA, production, whatever) with
your scripted deployment, then you really didn’t get there at all….
A few more notes. As I said above, if you have the “Use MSMQ Authentication”
option checked on a Send Port and you are not in Active Directory-integrated mode,
then messages will not flow. What you will see is:
IMHO, Biztalk 2004 should be more serviceable in this regard, and should give better
error information. And of course, the documentation for MSMQ Send Port configuration
should have mentioned that MSMQ Authentication would only work for Active Directory.
Microsoft Premier Support became involved, and after around 18 hours of analysis they
said “We see some certificate-related errors in the traces. Do you use MSMQ
authentication? Are you AD-integrated?”
We looked in our binding files (since the decision had long since been forgotten)
and saw this snippet:
…
<TransportType Name="MSMQT" Capabilities="16495"
ConfigurationClsid="9a7b0162-2cd5-4f61-b7eb-c40a3442a5f8"/>
<TransportTypeData><CustomProps>&
lt;Authenticated vt="11">-1</Authenticated></CustomProps>
</TransportTypeData>
<RetryCount>3</RetryCount>
<RetryInterval>5</RetryInterval>
…
See that in the escaped XML? Yup, that is a property called “Authenticated”
that is an old-fashioned Variant of type bool, where “-1” means “true”.
Leaps out at you, right? Determining if you are AD-integrated means looking
at
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\BTSSvc.3.0\MessageQueuing\MsmqtWorkgroupMode.
From all of this I (gently) conclude that the product instrumentation/tracing should
point out this condition more quickly to a support engineer. In addition, the
MSMQT adapter should warn you of a mismatch during configuration with the Biztalk
Explorer and, ideally, when you deploy/import bindings.
Hindsight being 20/20, the support engineer should have asked to see our binding file
– and should have compared it with one exported from a server that was indeed sending
messages (since we had one.) Of course, we should have made such a comparison,
too! (and much earlier…) The engineer did look at the Biztalk Admin Console,
but of course that doesn’t give any of the detailed port configuration information
– only Visual Studio/BT Explorer does.
Having said that, the support engineers were great to work with and were certainly
dedicated to getting to the bottom of our issue.
Key lesson: Diffing binding files will prove to be a key troubleshooting technique
with Biztalk…
BizTalk server relies on a config file to store certain application information. This config file is located in \Program Files\Microsoft BizTalk Server 2004 and is named BTSNTSvc.Exe.Config. View your file here (DO NOT CHANGE THIS FILE WITHOUT BACKING UP!!!).
Let’s say that you have some .NET components that you want to consume from your BizTalk solution. Let’s also assume that these components are possibly shared with another solution, and make use of a config file for things such as connection strings, directory locations, etc., a fairly common situation. Now, keep in mind when you call a component, and that component makes use of a config file, it uses the config file of the calling application (at least for EXE’s). So, we have a couple of options. We can take what’s in the shared components config file and paste it into the BTSNTSvc.Exe.Config file. But, this means we now have 2 places to maintain the information. What if we then have a multi server configuration, we now have 2 config files to maintain in more than one location. Not good. Wouldn’t it be nice if we could somehow have the BizTalk config file “point” to the components config file? Then, we could maintain the other applications config file as we normally would. Well, the good news is you can.!!!
Take a look at my sample config file to follow along. I’ll explain a couple of the sections. It is important to remember to always take a copy of you current BTSNTSvc.Exe.Config file before making any changes as changing it incorrectly will prevent BizTalk from running.
The key to making this work is the section. To make this section “available”, you will have to add the following under the section of your config file –
Now that we have this in the config file, we can add the section . I won’t copy it here to save space, so look at the example. This section is where all the magic happens. Some of the attributes like AssembliesPerDomain, etc you can find information about in the help documentation. The key sections to be aware of are the section, section, and the section.
This section defines a new domain for your particular situation to run in. *** define this a little better. You will give your domain a name, and then you will use this name later to correlate the calling piece of your BizTalk solution with the called components config file.
This section defines where the called components config file resides. You can use absolute paths, or I believe you can use relative paths also.
In this section you are going to link your AppDomain (which contains the ConfigurationFile section) to the part of you BizTalk solution that calls the shared component. Let me clarify “part of your BizTalk solution”. When you create your orchestrations, you give them a namespace. They probably run under the same namespace, or at least the same root namespace. So, in the example you see “Source.Test.Orchestrations.*” as the pattern assignment rule. What this is saying is that any orchestration that is under this namespace would be associated with that particular app domain, and would then be able to make use of the configuration file listed under that app domain.
Hopefully with the example and the explanation, this will make some sense. There is some information in the help file about adding the new sections, but they don’t go into much detail of how all the pieces fit together, and what the pattern assigment rule is really supposed to point to, etc.
DON’T FORGET…BACK UP YOUR CURRENT CONFIG FILE BEFORE MAKING CHANGES. This will save a lot of headaches.
One last point to remember…and I won’t go into a lot of detail, but remember that if you are calling components from BizTalk, they must be GAC’d. It is possible that the shared components you are calling didn’t require to be GAC’d prior to calling them from BizTalk. Now that they are in the GAC however, you will need to change your shared components config file slightly. When you are defining your section for that component, you will have to change the attributes a bit so that you are including the following –
<SECTION type=", Version=, Culture=, PublicKeyToken=” name=”” />
The values for component name, version, culture and token you can get out of .NET Framework Configuration admin tool. Just look for you component, and make note of the values listed. The only one that should change would be the version.
Have you seen an error that looks like the one below on your Send Pipelines?
I found out tonight that Delivery Notification set to Transmitted works differently for Send Groups. In the case of Send Groups, no NACK is returned if any of the Send Ports in the group fails.
This samples demonstrates how to promote and demote values inside an Xml message into the message context and back into the message again.
This sample will work with BizTalk 2004 and BizTalk 2006.
Get more information from the original blog post on this topic: https://www.biztalkgurus.com/biztalk_server/biztalk_blogs/b/biztalk/archive/2004/10/07/property-promotion-and-demotion-in-biztalk.aspx
I think most BizTalk users have some idea about what Property Promotion is. I would say Property Promotion is the process of taking message or system data and putting it into the message context. The tricky part is when and how properties get promoted.
Make sure you check out Todd Uhl’s Blog. He has a sample working with Role Links in BizTalk 2004. This is something I had not looked into yet but his sample makes it look easy and useful.
Here is another sample of a Sequential Convoy in BizTalk 2004. This is a little different then most, it contains a Parallel Action shape that allows for concurrent parallel processing of inbound messages.