When setting up a BizTalk application/service in a multi server configuration implementing a well locked down security policy within Active Directory you will find yourself spending a considerable amount of time debugging a variety of security related issues.
Yes, that is an interesting statement to make, but nevertheless quite true and I am certainly not the only person that believes this. I would even go so far to say that 90% if the initial issues that I have encountered during my time deploying a variety of messaging patterns utilising various adapters have related to security.
I guess that is partly due to the nature of the project that I am working on whereby there is a considerable amount of configuration and reconfiguration, where BizTalk 2004 is being utilised as a piece of infrastructure supplying a service. It also does not help having security policy definitions moving numerous times where you would have everything set-up in one domain one week and then this changing the next.
After extensive experience in this domain, I would suggest the main tip in diagnosing such errors is to turn on auditing of failures in your security policy for each machine in the BizTalk configuration. Some people may have this configured to do so already, but for others it is not and can be invaluable when determining obscure errors.
Whenever I receive an error now that I do not know the cause of immediately, the first place I check is the security event log to determine whether there have been any failures. Believe me; some errors you receive from BizTalk can indicate a fault with an orchestration, a test harness application, IIS, the format of the XML message - pretty much anything sometimes except the often real cause - a security problem.
