I think in the past I told that do not try to configure anything in BizTalk Server if you are tired. My advice, go to sleep for one hour and come back… unless the client is eager and demands or request things to be done… then the error happens. This was one of these errors in which I usually say that the problem was between the chair and the keyboard. This week I returned to work, after my little honeymoon leave, that I spent part of it working and another part of it with my little kid a little sick (I need to compensate my wife with a proper vacation for being so understanding). So, as you can imagine I return a little tired and the first day was one of those days that I had several clients requiring my presence for several small things at the same time.
One of them was configuring correctly, according to best practices and security the IIS application pools that were being used to run Web Sites with some orchestrations exposed as Web Services that initial was running with BizTalk Server Administration account.
Once I finished configuring the applications pools, I started receiving the following error:
The Messaging Engine failed to register the adapter for “WCF-WebHttp” for the receive location “/ModifyOperationStatus/ModifyOperationStatus.svc”. Please verify that the receive location exists, and that the isolated adapter runs under an account that has access to the BizTalk databases~
Usually, this can happen for two reasons:
- There isn’t a receive location created and enabled listening to this web service;
- Or this is a permission issue! And is typically related by the fact that the account or service account specified on the application pool that the web service is running is not… a member of the BizTalk Isolated Host Users group.
In my case, and because the names of the service accounts were very identical, I improperly configured the application pool to run with the service account that was a member of the BizTalk Host Users group (btsapphostsrv) instead of the service account member of the BizTalk Isolated Host Users group (btsiapphostsrv).
To solve this issue, you first should check and double-check if the IIS Application Pool Identities are correctly configured.
If yes, guarantee that the user or service account is part of the BizTalk Isolated Host Users group. If not:
- Make sure you add that user or service account into the BizTalk Isolated Host Users group.
- Or change the IIS Application Pool Identity for an account that is already a member of the BizTalk Isolated Host Users Group.
And then make sure that there is a receive location configured and to listen to this web service and if it is enabled.
In my case, changing to the BizTalk Isolated Host Instance Account that is, of course, a member of BizTalk Isolated Host Users group solved my issue.