BizTalk Production Application Deployment Issues Encountered

This past weekend our company did it’s first significant BizTalk application deployment into a production environment. I encountered a few issues along the way, and I thought I’d list the problem and resolution.

In order of annoyance to me (from least to greatest):

• Transport does not have read/write privileges for receive location … We had a network share set up to poll for files, but as soon as we’d turn the port on, we’d get the “privileges” error. We confirmed that the BizTalk service account had read/modify/delete rights on the folder/share. After reviewing some KB articles, I found the answer in Tom’s blog post. Basically, I also needed to assign “delete subfolders and files” rights as well.
• The identity of application pool ‘BizTalkAppPool’ is invalid … the application pool is disabled. After first installing the HTTPReceive virtual directory on one of our servers, I got this error. After a quick search, I was reminded that the application pool service account needs to be in the IIS_WPG group on the box.
• The outbound transport could not be resolved because a matching transport protocol prefix could not be derived from the URL . This one killed me for a couple hours. Since my orchestration dynamically assigns a file name for a SharePoint site, I also dynamically assign the SharePoint URL. The WSS URL sits in the btsntsvc.exe.config file and is read at run-time. However, the first orchestrations that executed triggered this error. It implied that my “wss://” prefix for the dynamic send port was wrong. After looking at every possible technical solution, I finally realized that there was a “space” before the ” wss://” address in the configuration file. So, the error made sense, but damn.
• Failed to decode the S/MIME message.The S/MIME message may not be valid. Our application starts by receiving an email containing formatted text. In the orchestration we parse the text we want and throw away the rest. However, messages were getting suspended at the adapter layer with this error. After reviewing the email message header, I noticed that it was missing any MIME declarations (MIME-Version, Content-Type). So, I deduced that the POP3 adapter’s default parsing behavior was failing because it couldn’t determine MIME encoding of the inbound mail. Ignoring that fact that MIME is a freakin’ standard encoding that any email sender should include, we need(ed) to figure out a way to parse these messages with the POP3 adapter. The solution I’ve put together involves turning off the Apply MIME Decoding flag in the POP3 receive location, then parsing the inbound email string and looking for the “from:” address (since turning off MIME decoding at the receive location means no POP3 promoted values). I think it’ll work.

Good times.

Technorati Tags: BizTalk