BizTalk Send Handlers/SSO Bug?

My good friend Carlos ran into a situation while working with one of his clients that seems to be triggering what looks like a bug in BizTalk Server 2010. The specific case came up when changing the Windows User Group associated with a BizTalk Host when that host is already associated as a Send Handler for an adapter.

Apparently, when doing the change, BizTalk will correctly update the information stored in the Enterprise Single Sign-On (ENTSSO) database (SSODB) for Receive Handlers, but not with Send Handlers, which leaves the system generating errors when the host later tries to access the SSODB to access the stored adapter settings.

Here’s  the repro instructions:

1. Create a new BizTalk Host for the test. Let’s name it BTTestHost. Assign to it the default BizTalk Application Users group, and then create a new Host instance.
2. Add the BTTestHost as a send handler for an adapter; we’ll use the FILE adapter in this example.
3. At this point, if you' check the ssodb.dbo.SSOX_ApplicationInfo table, you should see an entry associated with FILE_TL_BTTestHost, so that’s our newly created send handler. You’ll notice that the ai_admin_group_name column has the value ”BizTalk Application Users”, as expected.
4. Now create a send port associated to the new Send Handler and test to verify everything is working correctly.
5. Stop and delete the existing host instance.
6. Now let’s create a new Windows Users Group, let’s name it “BizTalk Test Group”. We’ll also create a new windows user we’ll use to create a new host instance in a bit; and we’ll make that user a member of BizTalk Test Group. Make sure the user is not a member of “BizTalk Application Users”.
7. Open the properties for BTTestHost and change the associated Windows User Group, to the new “BizTalk Test Group”.
8. Go ahead and create a new Host Instance, add a new Send Port associated with our Send Handler and run a test. You’ll notice you’ll get an error with something like “Access denied. The client user must be a member of one of the following accounts to perform this function.” (followed by a list of windows user groups).
9. At this point, if you go back and check the SSOX_ApplicationInfo table again, you’ll notice that the row FILE_TL_BTTestHost still has the same value on the ai_admin_group_name column referencing the original group associated with the host, not the new group we assigned to it. This causes the access denied error for the host instance, because the host user is not considered to have access to the SSODB to read the adapter settings.

The ugly part is that working around this problem requires you to delete the original Send Handler and recreating it, which requires you to move all send ports already associated with it one by one.