Moving the ENTSSO service to a new cluster in an existing BizTalk server environment

Recently I came across a requirement to move master secret to a separate cluster where one of the BizTalk servers are presently acting as the master secret server.

Most of the articles available over internet talk about creating a new ENTSSO environment which compelled me to create a step by step guide to achieve this requirement.

Current Environment setup:

BTSNODE1 and BTSNODE2 are the existing BizTalk nodes in the environment.

Let’s call the new clustered nodes as Node1 and Node2.

Currently BTSNODE1 is the master secret server in this BizTalk group.

Steps to be done before the downtime window (assuming that the windows nodes are clustered):

  1. Determine if MSDTC CID values for new nodes are unique, check the values for the entries under the HKEY_CLASSES_ROOT\CID registry key on both computers. If these values are not unique for each computer then uninstall and reinstall MSDTC using the below commands from an elevated command prompt:
                msdtc -uninstall
                msdtc –install
  1. Make sure the MSDTC settings are properly set as on the existing BizTalk nodes. Refer, How to Enable MSDTC on the BizTalk Server :
  2. Install BizTalk Server 2010 on each cluster node. In the Component Installation dialog box of the Microsoft BizTalk Server Installation Wizard, select to install the Enterprise Single Sign-On Administration Module and Enterprise Single Sign-On Master Secret Server components. After installation has completed successfully you have the option to run the BizTalk Server 2010 Configuration program but do not do so at this time.
  3. Designate a domain account that is a member of the SSO Administrators domain group. The Enterprise SSO service on each node will be configured to log on as this domain account. This account must have the Log on as a service right on each node in the cluster.
  4. Start the BizTalk Server 2010 Configuration program. Click Start, point to Programs, point to Microsoft BizTalk Server 2010, and then click BizTalk Server Configuration to display the Microsoft BizTalk Server 2010 Configuration dialog box.
  5. Choose the Custom Configuration option and enter the appropriate values for the Database server name, User name and Password fields. After entering these values click the Configure button to continue.
  6. Since you will be moving the existing master secret server to the cluster do not choose the option to Create a new SSO system when configuring Enterprise SSO on the cluster nodes. When configuring each cluster node, set the following options for the Enterprise SSO feature in the BizTalk Server Configuration screen

    Check the box next to Enable Enterprise Single Sign-On on this computer.
    Click the option to Join an existing SSO system.
    Enter values for the existing SSO Database Server Name and Database Name.
    Enter the existing SSO Service account when specifying the account to use for the Enterprise Single Sign-On Service.

  1. Click the Apply      Configuration option to display the Microsoft BizTalk Server 2010 Configuration Wizard Summary dialog box.
  2. Click Next to apply the configuration.
  3. Click Finish to close the Microsoft BizTalk Server 2010 Configuration Wizard.
  4. Close the Microsoft      BizTalk Server 2010 Configuration program.
  5. Copy the existing master      secret backup file from BTSNODE1 to the \Enterprise Single Sign-On folder on each cluster node.
  6. Create a clustered MSDTC resource.
  7. Right-click the clustered service or application, point to Add a resource, and click Generic Service to display the New Resource Wizard dialog
  8. In the Generic Service Parameters dialog box, if you do not click to select the Use Network Name for computer name check box, SSO client computers will generate the following error when they try to contact this clustered instance of the Enterprise SSO service.
    ERROR: 0xC0002A0F : Could not contact the SSO server 'XXXXXX'. Check that SSO is configured and that the SSO service is running on that server. (RPC: 0x800706D9: There are no more endpoints available from the endpoint mapper.)
  9. Continue with the steps and add the dependency for the name and disk.
  10.  Failover the service from Node 1 to Node2 and back to make sure the service is coming online on both the nodes.

Steps to be performed during downtime

     18.   To update the master secret server name in the SSO database
             Type the following commands from a command prompt on the active cluster node to stop and restart the Enterprise SSO service:|

               net stop ENTSSO
               net start ENTSSO

             Change the master secret server name in the SSO database to the cluster name by following these steps:

            The cluster name is the name defined for the network name resource that you have created in the cluster group / clustered service or application that will contain the clustered Enterprise SSO service.
            For example, the name may be BIZTALKCLUSTER. BIZTALKCLUSTER is a placeholder for the actual network name resource that is created in the cluster group / clustered service or application.

            Paste the following code in a text editor :

          Save the file as an .xml file. For example, save the file as SSOCLUSTER.xml.
19.   At a command prompt, change to the Enterprise SSO installation folder. By default, the installation folder is <drive>:\Program Files\Common Files\Enterprise Single Sign-On. Type the following command at the command prompt to update the master secret server name in the database:
         ssomanage -updatedb SSOCLUSTER.xml

20.   Restore the master secret on the active node :
       From an elevated  command prompt, go to the Enterprise Single Sign-On installation directory. The default installation directory is <drive>:\Program Files\Common Files\Enterprise Single Sign-On.
       Type ssoconfig –restoreSecret <restore file>, where <restore file> is the path and name of the file where the master secret is stored.

22.   Failover the cluster and peform step 20 on the current active node.
21.   Failover the cluster resource to make sure the service is coming online on both the servers.
22.   Restart the DTC services(local and\or clustered) on all the concerned nodes
23.   Restart ENTSSO service on BTSNODE1 and BTSNODE2.
24.   From the BTSNODE1 and BTSNODE2, make sure we are able to create a receive port and send port successfully. If yes, we are good.

 Hope this helps!!!

Written by
Jainath Ramanathan

Reviewed by
Chirag Pavecha

Microsoft India GTSC


Comments (2)
  1. IPOG NAVLES says:


    So looks like the clustered nodes – NODE1 and NODE2 also need BizTalk Server installed. Will that also be considered for licensing (even though we use only SSO functionality).


  2. Jacob J says:

    Dear All,

    My concern is different but couldnt find a thread related to the same. So sharing the details here.

    This with regards to Biztalk 2010 application ( Two nodes in a cluster and one Database instance)

    We have two BizTalk nodes in a cluster pointing to one Database instance where the BizTalkMsgBox database lies. Now to explain further scenario. We have application that has the BTS HTTP Receive Location (two way) where the client would be hitting the request to this receive location and the particular orchestration would pick up the message through Direct Binding.( message hit to receive location would reside in MsgBox for subscription to pick it up based on messagetype). During this course , we track the messages and orchestration flow through Logs (.txt files) that we have written in a particular location. The Logs generated is through an external class  library called in the orchestration just to write the sequence of events taking place. This library is added to global assembly cache in both nodes. So far the request that is entered and processed before it hits  the destination is written to the Logs in one specific node. Now the crazy part starts. The destination is SOAP service ,so once the orchestration sends out the processed request to this send port( two way) where the SOAP service URL is provided, we would expect the response  to hit back to same BizTalk node from where send port has sent a request, but funny thing is the response from SOAP service hits back to the other BizTalk node in the cluster and external class library in that node generates the log starting with response received. Now another thing is the HTTP receive location which had send the request would be waiting for the response ,but it has gone to the other node and neither way the HTTP receive location at other node could send back to the client. (What I understand, one website hosted in IIS in one node and pushes the request would expect response on the same node rather than going to other website hosted on IIS on the other node). I am unable to figure out this behavior

    I presume the scenario is understood and si I hope I get a response.Please push this concern in another  thread where ever applicable, if it doesnt fit in current  context, since I pretty much concerned for a response.

    -Jacob J

Comments are closed.

Skip to main content