Thursday, November 7, 2013

BizTalk 2010 Moving the Master Secret to a Windows Server Cluster

My company recently went through a Microsoft audit of our production BizTalk 2010 environment. The main area of improvement Microsoft recommended was where the Master Secret Server should reside. Instead of having the Master Secret Server on one of the BizTalk Servers, it was recommended to move this to the clustered SQL Server.  Having not done this in my past, there were two main articles I followed to move the Master Secret Server:
  1. How to Move the Master Secret Server
  2. How to Cluster the Master Secret Server
Following the guidelines set within the above two articles, here are the steps I followed:
  • I started with the first link above and navigated to the section of the article titled "To move the master secret from one server to a Windows Server Cluster".  This guided me to the second posted article above under the section "To install and configure Enterprise SSO on the cluster nodes (Windows Server 2008)".  As instructed, I ran the BizTalk install bits on both SQL Server boxes in the cluster and installed the required components for Enterprise SSO:
  • When configuring BizTalk in custom configuration, instead of creating a new SSO system, I selected "Join an existing SSO system":
  • After the installation and configuration of SSO, I followed the section entitled "To update the master secret server name in the SSO database".  Following the instructions  I created the xml file and ran the command "ssomanage -updatedb" from a command prompt with elevated permissions.  After updating the master secret server name, I ran the command "ssoconfig.exe -status" to ensure the name had been changed

  • I then followed the section entitled "To create the clustered Enterprise SSO resource (Windows Server 2008)".  The directions are pretty self explanatory, but here are a couple of screenshots of adding the new resource and setting it's properties:

  • After accomplishing this, I switched back to the article ""To move the master secret from one server to a Windows Server Cluster".  I copied the Master Secret backup file to each server in the cluster.  I brought the new "Enterprise Single Sign-On Service" (ESSO) on-line:

  • After bringing ESSO online for the cluster, I restarted the Enterprise Single Sign-On Service on each of the BizTalk Servers.  
  • Last step is to restore the Master Secret on the active node of the cluster.  Those directions can be found here: How to Restore the Master Secret Server.  Essentially, running the command "ssoconfig -restoreSecret [filename]" will restore the master secret on that server.  One thing to note is that you will need the password originally set-up when backing up the Master Secret to restore successfully.
  • One last talking point to this whole process.  I'm fortunate to work in a company with the foresight to invest in multiple environments.   Before implementing this in our production environment, I was able to test this process in our quality assurance environment.  I would highly recommend going that route to identify potential problematic areas.
  • One other talking point, if your looking to cluster your BizTalk hosts, check out this article by Kent Weare Clustering BizTalk Hosts.  A great article on not only the "how to" but why you would want to.

Post a Comment