How to Cluster SSO and a BizTalk Host in the Same Cluster Group

With BizTalk Server 2006 you can cluster one or more BizTalk hosts and the Enterprise Single Sign-On (SSO) service on the same Windows Server cluster.

Note
Correct implementation of this strategy requires that you create any BizTalk host instances and the Enterprise SSO service as cluster resources in the same cluster group.

The use of a Windows failover cluster with one or more BizTalk hosts and Enterprise SSO typically falls into one of these categories:

Clustering the Enterprise SSO master secret server and one or more BizTalk hosts in the same cluster group.

In this scenario, the dependency between the clustered BizTalk hosts and the clustered Enterprise SSO service is maintained so that if the cluster group is failed over, all resources move with the group.

If the Enterprise SSO service is configured as a clustered resource on a BizTalk Server 2006 computer, you must create a clustered IIS web service in the same cluster group. This must be done to ensure that all Isolated host instances will run on the cluster node that the Enterprise SSO service is running on. This ensures that any adapters that run in an Isolated host instance will have access to the Enterprise SSO service since Isolated host instances run in IIS.

You cannot run the BizTalk Base EDI adapter on a BizTalk server that is running a clustered Enterprise SSO service. Clustering of the BizTalk Base EDI adapter is not supported, and running the Base EDI adapter on a server where the Enterprise SSO service is clustered is not a supported configuration.

Note
If an un-clustered instance of a BizTalk host is running on the same cluster node that a clustered instance of the Enterprise SSO service is running then the clustered instance of the Enterprise SSO service cannot be failed over unless the un-clustered instance of the BizTalk host is stopped. An un-clustered instance of the BizTalk host maintains a dependency upon the clustered instance of the Enterprise SSO service running on the cluster node and prevents the clustered instance of the Enterprise SSO service from failing over. For this reason, it is recommended that you do not create a non-clustered instance of a BizTalk host to run on the same cluster node that is running a clustered instance of the Enterprise SSO service.

Note

If an un-clustered instance of a BizTalk host is running on the same cluster node that a clustered instance of the Enterprise SSO service is running then the clustered instance of the Enterprise SSO service cannot be failed over unless the un-clustered instance of the BizTalk host is stopped. An un-clustered instance of the BizTalk host maintains a dependency upon the clustered instance of the Enterprise SSO service running on the cluster node and prevents the clustered instance of the Enterprise SSO service from failing over. For this reason, it is recommended that you do not create a non-clustered instance of a BizTalk host to run on the same cluster node that is running a clustered instance of the Enterprise SSO service.

Clustering the Enterprise SSO service (non master secret server) and one or more BizTalk hosts in the same cluster group. This scenario requires that a remote master secret server be available. In this scenario, the dependency between the clustered BizTalk hosts and the clustered Enterprise SSO service is maintained so if the cluster group is failed over, all resources move with the group.

If the Enterprise SSO service is configured as a clustered resource on a BizTalk Server computer, you must create a clustered IIS web service in the same cluster group. This must be done to ensure that all Isolated host instances will run on the cluster node that the Enterprise SSO service is running on. This ensures that any adapters that run in an Isolated host instance will have access to the Enterprise SSO service since Isolated host instances run in IIS.

You cannot run the BizTalk Server Base EDI adapter on a BizTalk server that is running a clustered Enterprise SSO service. Clustering of the BizTalk Server Base EDI adapter is not supported and running the Base EDI adapter on a server where the Enterprise SSO service is clustered is not supported.

Note
If an un-clustered instance of a BizTalk host is running on the same cluster node that a clustered instance of the Enterprise SSO service is running then the clustered instance of the Enterprise SSO service cannot be failed over unless the un-clustered instance of the BizTalk host is stopped. An un-clustered instance of the BizTalk host maintains a dependency upon the clustered instance of the Enterprise SSO service running on the cluster node and prevents the clustered instance of the Enterprise SSO service from failing over. For this reason, it is recommended that place the clustered Enterprise SSO service on the nodes with the clustered SQL Server instance.

Note

If an un-clustered instance of a BizTalk host is running on the same cluster node that a clustered instance of the Enterprise SSO service is running then the clustered instance of the Enterprise SSO service cannot be failed over unless the un-clustered instance of the BizTalk host is stopped. An un-clustered instance of the BizTalk host maintains a dependency upon the clustered instance of the Enterprise SSO service running on the cluster node and prevents the clustered instance of the Enterprise SSO service from failing over. For this reason, it is recommended that place the clustered Enterprise SSO service on the nodes with the clustered SQL Server instance.

Clustering one or more BizTalk hosts on a Windows Server cluster without clustering the Enterprise SSO service. In this scenario, one or more BizTalk hosts are configured as cluster resources but the Enterprise SSO service is not configured as a clustered resource. In this scenario you can run the BizTalk Server Base EDI adapter on each BizTalk server that is a member of the cluster since the Base EDI adapter can use the non-clustered instance of the Enterprise SSO service that is running on each node. This design provides high availability for the clustered BizTalk hosts but does not provide high availability for the Enterprise SSO service. In this scenario, if the Enterprise SSO service on a node fails then BizTalk Server components that depend on Enterprise SSO (including the Base EDI adapter) on that node will also fail.

The following procedures describe the steps that you should follow to cluster a BizTalk host and the Enterprise SSO service on the same Windows Server cluster.

To cluster a BizTalk host and the Enterprise SSO master secret server on the same Windows Server cluster

If the cluster is not configured with a clustered Distributed Transaction Coordinator (MSDTC) resource then follow the steps in the "Improving Fault Tolerance in BizTalk Server 2006 by Using a Windows Server Cluster" white paper at http://go.microsoft.com/fwlink/?LinkId=69207 to create a clustered MSDTC resource.
Install and configure the Enterprise SSO service on the Windows Server cluster by following the steps in How to Cluster the Master Secret Server. Since you will be running BizTalk Server on the Windows Server cluster, install all required BizTalk Server components even though you will only be configuring the Enterprise SSO components at this time.

Follow the steps documented in "Checklist: Creating a clustered IIS Web or FTP service" at http://go.microsoft.com/fwlink/?LinkId=75278 to cluster IIS on the BizTalk Server computer. Create the clustered IIS web service in the same cluster group as the clustered Enterprise SSO service. The script file that is referenced in this topic (clusweb.vbs) does not contain code to take the clustered IIS resource offline. Modify the Offline() function in the script with the following code:

Function Offline( )

    Dim objWmiProvider
    Dim objService
    Dim strServiceState

    ' Check to see if the service is stopped
    set objWmiProvider = GetObject("winmgmts:/root/cimv2")
    set objService = objWmiProvider.get("win32_service='w3svc'")
    strServiceState = objService.state

    If ucase(strServiceState) = "STOPPED" Then
        Offline = True
    Else

    ' If the service is running, try to stop it.  If it won't stop, log an error
        response = objService.StopService()
        
        ' response = 0  or 10 indicates that the request to stop was accepted
        If ( response <> 0 ) and ( response <> 10 ) Then
            Resource.LogInformation "The resource failed to go offline because the W3SVC service is still running."
            Offline = False
        Else
            Offline = True
        End If
    End If

End Function

Important
After making this change you must save the updated clusweb.vbs file with a different name (for example, clusIIS.vbs) and then reference the new file when you create the Generic Script Resource for the IIS Service. A new file name must be used because Windows File Protection will revert any changes that you make to the clusweb.vbs file back to the original file.

Move the cluster group that contains the clustered Enterprise SSO service to one of the cluster nodes and log on to this cluster node.
Start the BizTalk Server Configuration program and complete the configuration of BizTalk Server on this cluster node. Since this is the first BizTalk server in the group, choose the option to Create a new BizTalk Group when configuring the BizTalk Group component.
Once the BizTalk Server configuration has completed successfully, move the cluster group that contains the clustered Enterprise SSO service to the other cluster node and log on to this cluster node.
Start the BizTalk Server Configuration program and complete the configuration of BizTalk Server on this cluster node. Choose the option to Join an existing BizTalk Group when configuring the BizTalk Group component on this cluster node and specify the BizTalk group that you created on the first node.

Once the BizTalk Server configuration has completed successfully, follow the steps in How to Configure a BizTalk Host as a Cluster Resource to create one or more clustered BizTalk host instances

Note
In this scenario, all BizTalk hosts must be created as cluster resources in the same cluster group as the clustered Enterprise SSO service resource. Running a non-clustered BizTalk host instance on a Windows Server Cluster node where the Enterprise SSO service is clustered is not a supported configuration. This is because the non-clustered BizTalk host instance will fail when the clustered Enterprise SSO service is failed over to another node due to the dependency of a BizTalk host instance on the SSO service.

Note

In this scenario, all BizTalk hosts must be created as cluster resources in the same cluster group as the clustered Enterprise SSO service resource. Running a non-clustered BizTalk host instance on a Windows Server Cluster node where the Enterprise SSO service is clustered is not a supported configuration. This is because the non-clustered BizTalk host instance will fail when the clustered Enterprise SSO service is failed over to another node due to the dependency of a BizTalk host instance on the SSO service.

To cluster a BizTalk host and Enterprise SSO (non master secret server) on the same Windows Server cluster when the Enterprise SSO master secret server is remote

If the cluster is not configured with a clustered Distributed Transaction Coordinator (MSDTC) resource then follow the steps in the "Improving Fault Tolerance in BizTalk Server 2006 by Using a Windows Server Cluster" white paper at http://go.microsoft.com/fwlink/?LinkId=69207 to create a clustered MSDTC resource.
Create domain groups with the names SSO Administrators and SSO Affiliate Administrators. To create a clustered instance of the Enterprise SSO service, you must create the SSO Administrators and SSO Affiliate Administrators groups as domain groups.
Create or 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. This account must also be granted Full Control access to the cluster. To grant Full Control access to the cluster for this account, follow these steps:
1. Start the Cluster Administrator. To do this, click Start, point to Programs, point to Administrative Tools, and then click Cluster Administrator.
2. Select the cluster.
3. On the File menu, click Properties.
4. On the Security tab, grant the domain account Full Control access to the cluster.
Add the account that you are using to log on during the installation and configuration process to the domain SSO Administrators group.

Important
Configuration of the Enterprise SSO service will fail if steps 3 and 4 are not completed.
Log on to one of the cluster nodes and install BizTalk Server 2006. Select the option to start the configuration program when installation has completed successfully.
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.
Set the following options for the Enterprise SSO feature:
1. Select the check the box next to Enable Enterprise Single Sign-On on this computer.
2. Click the option to Join an existing SSO system.
3. Enter values for the existing SSO Database Server Name and Database Name.
4. Enter the existing Enterprise SSO service account when specifying the account to use for the Enterprise Single Sign-On service.
Since this is the first BizTalk Server in the group choose the option to Create a new BizTalk Group when configuring the BizTalk Group component.
Specify the remaining configuration options as needed and apply the BizTalk Server configuration to this node.
Once the BizTalk Server configuration has completed successfully on the first node, log on to the second node and install BizTalk Server 2006. Select the option to start the configuration program when installation has completed successfully.
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.
Set the following options for the Enterprise SSO feature:
1. Select the check the box next to Enable Enterprise Single Sign-On on this computer.
2. Click the option to Join an existing SSO system.
3. Enter values for the existing SSO Database Server Name and Database Name.
4. Enter the existing Enterprise SSO service account when specifying the account to use for the Enterprise Single Sign-On service.
Choose the option to Join an existing BizTalk Group when configuring the BizTalk Group component on this cluster node and specify the BizTalk group that you created on the first node.
Specify the remaining configuration options as needed and apply the BizTalk Server configuration to this node.

Important
Configuration of the Enterprise SSO service will fail if steps 3 and 4 are not completed.

After the BizTalk Server configuration has completed successfully, follow these steps to cluster the Enterprise SSO service:

Stop the Enterprise SSO service on each of the cluster nodes by typing the following command from a command:
```
net stop entsso
```
In the Cluster Administrator, move all cluster groups to one node and log on to this node.
Click to select a cluster group other than the quorum group that contains a Name, IP Address, and Disk resource.

Note
This group will contain the clustered Enterprise SSO service and the clustered BizTalk host.
On the File menu, point to New, and then click Resource.
Enter a value for the Name field of the New Resource dialog box, for example, ENTSSO.
In the Resource type drop-down list, click Generic Service.
Click Next.
In the Possible Owners dialog box, include each cluster node as a possible owner of the ENTSSO resource, and then click Next.
In the Dependencies dialog box, add a dependency to a Network Name resource that is created in this group, and then click Next.
In the Generic Service Parameters dialog box, type entsso for the Service name, leave Start parameters blank, click to select the Use Network Name for computer name check box, and then click Next.
In the Registry Replication dialog box, click Finish.

Note
This group will contain the clustered Enterprise SSO service and the clustered BizTalk host.

Click OK in the dialog box that indicates that the resource was created successfully.

Important
If you do not click to select the Use Network Name for computer name check box, SSO client computers will generate an error similar to the following when they try to contact this clustered instance of the Enterprise SSO service: Failed to retrieve master secrets. Verify that the master secret server name is correct and that it is available. Secret Server Name: ENTSSO Error Code: 0x800706D9, there are no more endpoints available from the endpoint mapper.

Important

If you do not click to select the Use Network Name for computer name check box, SSO client computers will generate an error similar to the following when they try to contact this clustered instance of the Enterprise SSO service:

Failed to retrieve master secrets.

Verify that the master secret server name is correct and that it is available. Secret Server Name: ENTSSO Error Code: 0x800706D9, there are no more endpoints available from the endpoint mapper.

Function Offline( )

    Dim objWmiProvider
    Dim objService
    Dim strServiceState

    ' Check to see if the service is stopped
    set objWmiProvider = GetObject("winmgmts:/root/cimv2")
    set objService = objWmiProvider.get("win32_service='w3svc'")
    strServiceState = objService.state

    If ucase(strServiceState) = "STOPPED" Then
        Offline = True
    Else

    ' If the service is running, try to stop it.  If it won't stop, log an error
        response = objService.StopService()
        
        ' response = 0  or 10 indicates that the request to stop was accepted
        If ( response <> 0 ) and ( response <> 10 ) Then
            Resource.LogInformation "The resource failed to go offline because the W3SVC service is still running."
            Offline = False
        Else
            Offline = True
        End If
    End If

End Function

Important
After making this change you must save the updated clusweb.vbs file with a different name (for example, clusIIS.vbs) and then reference the new file when you create the Generic Script Resource for the IIS Service. A new file name must be used because Windows File Protection will revert any changes that you make to the clusweb.vbs file back to the original file.

In Cluster Administrator, right-click the cluster group that contains the clustered Enterprise SSO service resource, and then click Bring Online to start all of the resources in the cluster group.
Move the cluster group that contains the clustered Enterprise SSO service from the active cluster node to the other cluster node to ensure failover functionality. Then move the cluster group back to verify fail-back functionality.
Set the SSO server name for all users to the clustered Enterprise SSO service with the ssomanage command line utility. This command should be run from the Enterprise SSO installation folder on each BizTalk server in the group. For example, the following command line will set the SSO server name for all users to the clustered Enterprise SSO service:
```
ssomanage -serverall SSOCLUSTER
```
Note
SSOCLUSTER is a placeholder for the actual network name resource that is created in the cluster group that contains the clustered Enterprise SSO service.
Update the SSO Server name accessible in the BizTalk Group Properties page to reference the clustered Enterprise SSO service. Open BizTalk Server Administration, right-click the BizTalk Group, select the Properties menu item, update the entry for SSO Server name, and then click OK.

Note
SSOCLUSTER is a placeholder for the actual network name resource that is created in the cluster group that contains the clustered Enterprise SSO service.

Follow the steps in How to Configure a BizTalk Host as a Cluster Resource to create one or more clustered BizTalk host instances in the same cluster group that you have created the clustered Enterprise SSO service.

Note
In this scenario, all BizTalk hosts must be created as cluster resources in the same cluster group as the clustered Enterprise SSO service resource. Running a non-clustered BizTalk host instance on a Windows Server Cluster node where the Enterprise SSO service is clustered is not a supported configuration. This is because the non-clustered BizTalk host instance will fail when the clustered Enterprise SSO service is failed over to another node due to the dependency of a BizTalk host instance on the SSO service.

Note