I dealt with an interesting, if arcane, issue today at a client's site. The client is in the process of deploying an early version of a BizTalk application to their test environment for the first time. The test environment is hosted by another company, and BizTalk Server 2006 R2 had been installed and configured by that company. They are using the 64 bit version on Windows 2003 R2 with SP2. The BizTalk application publishes a WCF endpoint, hosted in IIS6.
The hosting company has quite correctly created a set of domain accounts and groups and configured BizTalk to use these. Unfortunately, when doing the initial deployment yesterday, we didn't have, and couldn't get, the password for the configured BizTalk Isolated Host user account. We did, however, have the password for another domain account, and we were able to add that account to the BizTalk Isolated Host Users domain group. So, having done that, we configured this second account as the identity of the app pool.
To begin with, nothing worked. Every time we tried to access the WCF endpoint, IIS returned a 404 - Service unavailable message. However, at some point, the whole thing started working OK. I forget, now, the exact sequence of steps, but that is not important.
At some point yesterday, the BizTalk developer created a local account called 'BizTalk Isolated Host Users'. I can't remember, now, why we thought this would be a good idea. Our BizTalk Server is configured to use a domain group of the same name, and is not aware of the local group. The important point, though, is that this group was not deleted.
Roll forward to today. Everything was working nicely until the BizTalk developer decided, very sensibly, to tidy things up by removing the unneeded local group. Shortly after removing this group, we noticed that the dreaded 404 response had returned. The only change we had made was the removal of the local group, so we recreated it. We didn't add any accounts to it. After an IIS restart, the endpoint sprang back into life. We deleted the group, and everything stopped working. We recreated it again, checked that the endpoint was working, renamed the group and tested. Sure enough, we got a 404. We changed the name back, and the endpoint worked.
At this point, I felt very confused at several levels. We checked the configuration of BizTalk carefully, and satisfied ourselves that it had indeed been configured to use only domain accounts and groups. The only thing that was unusual about our environment was that, while the BizTalk isolated host instance we were using was configured to use one domain account for its logon credentials, the IIS app pool was configured to use another, set up with equivalent group membership and permissions.
I have always, as a natural path of least resistance, configured app pools to use the same identity as the corresponding isolated host instance. I realised that I have never consciously asked the question about what happens if you use different accounts. I phoned a colleague who has far more practical experience of deploying BizTalk than I do, and discussed this with him. He confirmed that he also always uses the same account, and like me, he had never stopped to wonder what happens if you use different accounts. So, I turned to the Internet and did some searching. Eventually, I discovered, embedded half-way through a BizTalk help page on MSDN (see http://65.55.11.235/en-us/library/aa561505.aspx), an explicit statement that the app pool should always be configured with the same account as the isolated host instance. In the grand tradition of BizTalk documentation there was, of course, absolutely no effort expended on explaining why. However, the help page also stated mysteriously that if you change the password on the account in the app pool configuration, there is no need to make a corresponding change to the credentials configured on BizTalk's isolated host instance. Bizarre. This seems to imply that the credentials you configure in BizTalk are not actually used for any kind of authentication.
We talked to the hosting company, and managed to get the password we needed. We re-configured the IIS app pool to use the same account configured for the BizTalk isolated host instance. Having deleted the local group, we restarted IIS and...success...everything worked OK.
So, the moral of the story is that you really need to ensure that your app pool identity is the same as the account you configure on the BizTalk isolated host instance. Don't worry about keeping the password up to date in BizTalk. I strongly recommend you always use this approach. If you really, really , really have to live with different accounts, create an empty local group on you BizTalk box with an identical name to the domain group you are using as BizTalk isolated host users group, and by some magic, everything will work. Avoid this weird 'work-around' at all costs in production.
Maybe this is some strange side-effect of Windows pass-through authentication (I don't really think that is the case), or maybe it is the result of some undocumented logic deep in the message agent or transport layer. I can't say. I do remember that when BTS 2004 first shipped, there was a suggestion that MS might at some point extend the isolated host feature to support additional hosts, and not just IIS. This has never happened, but it may be the explanation for what you configure an account and password on your isolated host instances even if, in the case of IIS, it is the app pool configuration which is all-important.