Geeks With Blogs

Mike H. - Another Geek In Need... WebLog

Clustered Enterprise Single Sign-On (ENTSSO) Setup

When you want to configure BizTalk Server on multiple NLB (network load balancing) nodes, you will have to install / configure the SSODB (Enterprise Single Sign-On – ENTSSO) service on a clustered SQL Server instance.

For this document, SQL Server runs clustered on a 2 node cluster – SERVERNODE1 and SERVERNODE2.

This document provides a real deployment – where the domain names are generic in this case. For example, I use / and then the BTS Group name – exactly as BTS ConfigFramework would create the group name when performing a default stand-alone installation. (i.e. The Domain is HAMILTON, so I created the group HAMILTON/HAM BizTalk Server Administrators. I followed this convention with all of the Groups. Below, I simply called the domain DOMAIN and abbreviated the name as DOM and then the Group name.

 

Finally, you do not need to know how to install SQL Server on a clustered server, but you will need to know the VIRTUALMACHINENAME and VIRTUALINSTANCENAME of the SQL Server we're deploying to.

  • If they do not already exist, create two domain level groups for DOM SSO Administrators and DOM  SSO Affiliate Administrators.
  • Add our domain DOMAIN\BtsService account to run as part of the operating system on each of the cluster nodes. (SERVERNODE1 and SERVERNODE2)1.
  • Add the DOMAIN\btsservice account to the DOM  SSO Administrators group.
  • Ensure that the service account has full control access to the cluster.
    • To ensure this, start the Cluster Administrator.
    • Select the cluster (on the left side, click the cluster – SQLCLUSTERNAME in this case).
    • Select FileàProperties.
    • On the Security tab, grant the DOM/BtsService domain account Full Control access to the cluster.

  • Ensure that our cluster has been configured before we install the ENTSSO.
    • Cluster resources are usually created by the network administrator(s).
    • We had 2 cluster resources created:
      • IP Resource (192.168.0.1)
      • Name Resource (VIRTUALSSO)
    • We created one cluster group, and this group name must match the Name Resource – or our ENTSSO will fail. We created a group called VIRTUALSSO.
    • During the creation of the Cluster Group (VIRTUALSSO) we include our Resource Name and IP Resource as dependencies of this new Group.
    • We are now ready to run the BTS installation.

  • From the primary / active node of the cluster (SERVERNODE1 was primary when we did this).
  • Run the Host Integration Server 2004 Installation.2
  • Select a custom installation.
  • Ensure that ONLY SSO and SSO Enterprise Manager are selected for installation.

Once the installation is complete, execute the ConfigFrameWork to setup our environment.

  • Ensure that Yes is set for Will this Single Sign-On server (SSO) hold the master secret key? Click next.
  • For the Windows Accounts, use the DOMAIN\BtsService account created earlier.
  • For the Database Configuration, point the setup to VIRTUALMACHINE\VIRTUALINSTANCENAME.

Once this is complete, backup the master secret on the active node.

  • Change to the C:\Program Files\Common Files\Enterprise Single Sign-On folder.
  • Type ssoconfig –generatesecret .  For the file name we named the file SSOINITDDMMMYY – where DD is the day, MMM is the month (i.e. JAN, FEB, MAR, etc.), and YY is the 2 digit year. Our first file may have been SSOINIT23APR05.BAK.

Now switch to the secondary node (SERVERNODE2) and execute the configframework.exe on this server.

  • Ensure that No is set for Will this Single Sign-On server (SSO) hold the master secret key? Click next.
  • For the Windows Accounts, use the DOMAIN\BtsService account created earlier.
  • For the Database Configuration, point the setup to VIRTUALMACHINE\VIRTUALINSTANCENAME.

Now switch back to the primary node (SERVERNODE1) and change to the ENTSSO folder (C:\Program Files\Common Files\Enterprise Single Sign-ON).

Create (or copy/paste) the following into a text file and save it in this folder (we named the file ssodb.xml).

            <sso>

                        <globalInfo>

                                    <secretServer>VIRTUALSSO</secretServer>

                        </globalInfo>

            </sso>

Once this file is saved, ensure that the ENTSSO server is running. Simply type net run entsso at the command prompt and it will start if it is not already running.

We now must configure ENTSSO to reference our new Secret Server name. To do this, type the following while in this folder (NOTE: replace with the filename you just created).

Type ssomanage –updatedb

If the command is successful, you will receive a response pretty quickly showing the new server name.

You could receive a runtime error regarding MSDTC – but we configured this prior to running this setup so we did not experience the error.

If you experience an error referencing the RPC server or no more endpoints available from the endpoint mapper then there is something invalid / incorrect in the Cluster Group configuration that was setup for this service. If you encounter this, review the Cluster Group configuration and ensure that 1) your Cluster Group name is the same as the Resource Name; 2) if the Cluster Resources / Group is correct, try simply restarting the ENTSSO from the Service Manager (StartàProgramsàAdministrative ToolsàServiceàEnterprise Single Sign-On).

The final stage is to configure the service and resource parameters for the cluster.

  • Start the Cluster Administrator
  • Click on our VIRTUALSSO cluster group
  • From the File menu select NewàResource
  • In the New Resource dialog enter:
    • ENTSSO for the Name of the resource
    • Select Generic Service for the resource type
    • Click Next
  • In the Possible Owners dialog, ensure that our two nodes appear as owners of the resource
  • In the Dependencies dialog, select our VIRTUALSSO Name Resource and click Next.
  • In the Generic Service Parameters dialog, type entsso for the service name, leave Start Parameters blank, and click (enable) Use Network Name for Computer name, then click Next.
  • At the Registry Replication dialog, simply click Finish.

Be sure to bring our Cluster Group (and resources) On-Line.

Now we’re ready to begin the BizTalk Server deployments.

NOTES

  1. We created a DOMAIN level account named BtsService (the name is not case-sensitive. I spell it that way to emphasize there are two ‘s’ characters in the name). For each server that this account will need access to, we must set the service to Act as part of the operating system. To do this (and this must be done on each server / host computer that BizTalk communicates with), follow these steps:
    1. At the server select StartàRun and type in gpedit.msc and press .
    2. Expand Computer ConfigurationàWindows SettingsàSecurity SettingsàLocal Policies and click on User Rights Assignment.
    3. On the right side locate Act as part of the operating system and double-click here (or right-click and select Properties).
    4. Click the Add User or Group option and add AUBURN/BtsService.
    5. Click OK and OK again, to close out.
    6. Now close the Group Policy MMC console.

  1. Host Integration Server installs a newer version of the Enterprise Single Sign-On service, so we use HIS to setup our clustered SSODB and related service. Otherwise the HIS remote servers will fail indicating that the database is an older version and must be upgraded before proceeding. To get around this issue, simply install ENTSSO from the HIS 04 CD.
Posted on Sunday, May 1, 2005 1:17 PM BizTalk | Back to top


Comments on this post: Clustered Enterprise Single Sign-On Deployment

# re: Clustered Enterprise Single Sign-On Deployment
Requesting Gravatar...
THIS IS AWESOME!!! I spent at least 10 hours trying to figure out how to get the Enterprise Single Sign-On clustered!! The MS docs SUCK compared to your notes!!
Left by jp on Jun 07, 2005 3:49 PM

# re: Clustered Enterprise Single Sign-On Deployment
Requesting Gravatar...
The post on the 20th of June regards the initial posting for Clustering the ENTSSO. I apologize for not noticing earlier - the XML header/tag components were actually stripped from the file.

That's what I get for traveling too much - I'm home one day a week, and with 7 children still home - well, I'm not as attentive to some things - as I'd like to be.

:-)
Left by Michael J. Hamilton, Sr. on Jun 20, 2005 9:45 AM

# re: Clustered Enterprise Single Sign-On Deployment
Requesting Gravatar...
Hello Mike,
I have a few clarifications:
I understand that the SSODB would reside on the cluster SQLCLUSTERNAME. SQLCLUSTERNAME comprises of SERVERNODE1 and SERVENODE2.

Do I need two additional computers for the cluster VIRTUALSSO?
Left by saurabhd on Mar 07, 2007 1:24 AM

# re: Clustered Enterprise Single Sign-On Deployment
Requesting Gravatar...
Hi Saurabhd,

The VIRTUALSSO is a cluster group name that you created in your custer admin.
Left by MikeH on Mar 07, 2007 7:25 AM

# re: Clustered Enterprise Single Sign-On Deployment
Requesting Gravatar...
Hi Mike,
I am clear now. Good work!
thanks
Left by saurabhd on Mar 12, 2007 12:01 AM

# re: Clustered Enterprise Single Sign-On Deployment
Requesting Gravatar...
Would these steps being still applicable if I do not use Host Integration Server .....I want to go with the BTS provided SSO
Left by AC on Dec 03, 2008 2:18 PM

# re: Clustered Enterprise Single Sign-On Deployment
Requesting Gravatar...
Hi,
Can you post or reply to my email how would you move an existing SSO in an existing Biztalk group to the cluster?

Like I have 2 Biztalk servers in a group installed already.

Now I have a new cluster SQL, then I need to "move" the SSO to the new cluster.

the SSO database have to move ,of course.

But how would you go about moving the "SSO service".

I bet you have to do a reconfiguration of biztalk right?
and restore all the msi
Left by hung on Dec 04, 2008 5:25 PM

# re: Clustered Enterprise Single Sign-On Deployment
Requesting Gravatar...
Hi AC / Hung,

Clustering the single sign on - and the use of the SSO service that shipped (back with BTS 2004) required us to upgrade to the SSO that shipped w/HIS 2004.

Today - this is no longer a requirement - unless you're still using BTS 2004. If you are using BTS 2006 - you can cluster the SSO service that ships out of the box with 2006.

Now, introducing a new SQL Server to the solution architecture, and if this is going to be clustered, then yes, I would recommend moving the SSO service to the clustered nodes of SQL Server, and reconfig the BTS hosts to use the new service - which is not a great deal of work actually. The key is getting the SSO service clustered properly on SQL Server.

HTH's...
Left by MikeH on Dec 06, 2008 11:04 AM

# re: Clustered Enterprise Single Sign-On Deployment
Requesting Gravatar...
Hung, my apologies for not going into 'how' to move the service.

To clarify a few things - we are not clustering just the SSO service that runs on the BTS hosts; we're clustering the Enterprise Single Sign-On (ENTSSO) service and database on the SQL Server nodes. The objective is to ensure that the ENTSSO service and SSODB are always available.

In your current BTS environment, you may or may not have configured SSO on one of the nodes, or even on the SQL Server host to be the Master Secret Server. You will uninstall this and configure the ENTSSO on the SQL Server nodes - as I described in the initial blog entry.

On each BTS hosts - there is the SSO Service that runs and will communicate with this ENTSSO Service running on the SQL Server cluster now. You will have to reconfig the BTS hosts so that the SSO Master Secret Server database is properly pointed to - yes. This should not be too difficult and does not require blowing away your current BTS hosts configurations - simply a reconfig and the SSODB will not be on a clustered SQL instance vs. the instance you previously had it pointing to.

HTH's...

Left by MikeH on Dec 06, 2008 11:10 AM

# re: Clustered Enterprise Single Sign-On Deployment
Requesting Gravatar...
Thanks Mike for the info.

For the prerequistes like .net 1.1 sp1 should we do a normal install or a failover install on each node

When I did the first time...it said it required MS XML 4.0 sp2...while if you look at the list MS provided it expected only .net 1.1 and MDAC 2.8

Even after installing all the above, the SSO installs fail, can BT SSO be installed on a Windows Server 2003 x64 machine that is clustered

i'm not sure if the BT installers are the issue here
Left by ACorrea on Dec 13, 2008 11:32 AM

# re: Clustered Enterprise Single Sign-On Deployment
Requesting Gravatar...
When we created two domain level groups for DOM SSO Administrators and DOM SSO Affiliate Admins, I presume these groups would be used in configuration wizard when the two windows account are asked for during second page asking for SSO and SSO affliate or should we let the default local machine group be created
Left by AC on Dec 16, 2008 2:35 AM

# re: Clustered Enterprise Single Sign-On Deployment
Requesting Gravatar...
Can anyone help? I am trying to deploy ENT SSO MSS to SQL cluster. I currently have two BizTalk Application servers (node1 & node 2) and Node 1 is the master secret server. The intent is to move the MSS to SQL cluster for high availability. Can I do this without having to blow up my existing BTS config with my applications? When I install ENT SSO MSS on the SQL Cluster and go over the configuration it requires new SSODB to be created which already exists. How can I reconfig the existing BizTAlk server to use it?

thanks,
Sam
Left by Sam on Feb 25, 2009 2:42 PM

# re: Clustered Enterprise Single Sign-On Deployment
Requesting Gravatar...
Hi Sam... Sorry for not being able to get back to you sooner.

In short - yes - you can move the ENTSSO/MSS to the SQL Cluster without blowing everything away - you 'will' have to run the configwiz again on the BTS hosts and point to the new ENTSSO service - otherwise it'll continue to look for it on the previous BTS host.

HTH's...
Left by MikeH on Mar 03, 2009 8:26 AM

Your comment:
 (will show your gravatar)


Copyright © Michael J. Hamilton, Sr. | Powered by: GeeksWithBlogs.net