BizTalk 2010 and Clustered Enterprise Single Sign-On Support for Multiple BizTalk Groups

My current company follows the traditional code promotion environments: Development, Test, and Production. These environments are fully integrated with other systems so we can test messaging of our Enterprise Service Bus (ESB).  Where things really start to get atypical is in the fact that we support three different development and test environments.  Wait, what???

Yeah, and since we have three different test environments, we have three different BizTalk groups which all mimic our production set up.  Which in turn means three clustered databases.  Here is one thing that is super nice, we leverage the same Master Secret Server database and Enterprise Single Sign-On Service (SSO) for all three BizTalk groups.  Wait, what???

That's right, when installing and configuring different BizTalk groups, you can configure these BizTalk groups to leverage the same Enterprise Single Sign-On Service (SSO), and in my case, that resides on the cluster.  So how did I set this up?  In my particular scenario, all of our test BizTalk databases reside on the same cluster server. When I start the Failover Cluster Manager application, I'm presented with all the database clusters (In my case, 1, BIZTALK2, and SQL Server):

The clustered  Enterprise Single Sign-On (SSO) Service resides on the cluster with the name of  "1", which houses the original BizTalk database I created.  If I click this cluster in the left hand pane, it shows me a summary of my resources, which includes the Enterprise Single Sign-On Service:

So knowing that the Enterprise SSO resides on the first cluster application, I can leverage this set up when configuring my second BizTalk group.  To do this, during the configuration of the second BizTalk group, I selected the Enterprise Single Sign-On feature.  Instead of creating a new SSO System, I selected the "Join an existing SSO system".  I then entered the server name and database of where the Master Secret server was originally created (on the first cluster named "1").  I also used the same domain account that the service runs under:

Configuration of the remaining BizTalk features can be set up to leverage the second cluster application labeled BIZTALK2.  This cluster has a SQL Server database that can be used when configuring the BizTalk group, BizTalk Runtime, Business Rules Engine, and Business Activity Monitoring (BAM).

I used the same process when configuring the third BizTalk group.  The only changes are during the configuration of BizTalk.  Instead of using the BIZTALK2 clustered application, I used the clustered application labeled "SQL Server".

So what do I gain in having three different BizTalk groups leveraging one Enterprise SSO?

• For starters, this minimizes the number of clustered servers.  Instead of having three different clustered servers, I have one, which means fewer servers to maintain and support.
• Reduce Total Cost of Ownership (TCO) which directly relates to the first point.
• Maintain only one Enterprise Single Sign-On Service.  If I had multiple clustered servers, each one would require it's own Master Secret Server and Enterprise SSO (which need to be clustered).
• Avoid multiple Master Secrets to backup and store for a non production environment.

As a side note, some may argue that I've altered my test environment in a way so that it no longer mirrors production.  In theory, I can agree with this, however in practice I'm willing to take the risk.  I don't think multiple BizTalk groups sharing the same Enterprise SSO creates a test environment that deviates in a meaningful way from the production environment.