Mike H. - Another Geek In Need...

WebLog

  Home  |   Contact  |   Syndication    |   Login
  68 Posts | 6 Stories | 642 Comments | 287 Trackbacks

News

Archives

Post Categories

Image Galleries

Development

Favorite Blogs

Hosting

User Groups

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.
  • Share This Post:
  • Share on Twitter
  • Share on Facebook
  • Share on Technorati
posted on Sunday, May 01, 2005 1:17 PM

Feedback

# re: Clustered Enterprise Single Sign-On Deployment 6/7/2005 3:49 PM jp
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!!

# re: Clustered Enterprise Single Sign-On Deployment 6/20/2005 9:45 AM Michael J. Hamilton, Sr.
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.

:-)

# re: Clustered Enterprise Single Sign-On Deployment 3/7/2007 1:24 AM saurabhd
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?

# re: Clustered Enterprise Single Sign-On Deployment 3/7/2007 7:25 AM MikeH
Hi Saurabhd,

The VIRTUALSSO is a cluster group name that you created in your custer admin.

# re: Clustered Enterprise Single Sign-On Deployment 3/12/2007 12:01 AM saurabhd
Hi Mike,
I am clear now. Good work!
thanks

# re: Clustered Enterprise Single Sign-On Deployment 12/3/2008 2:18 PM AC
Would these steps being still applicable if I do not use Host Integration Server .....I want to go with the BTS provided SSO

# re: Clustered Enterprise Single Sign-On Deployment 12/4/2008 5:25 PM hung
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

# re: Clustered Enterprise Single Sign-On Deployment 12/6/2008 11:04 AM MikeH
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...

# re: Clustered Enterprise Single Sign-On Deployment 12/6/2008 11:10 AM MikeH
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...



# re: Clustered Enterprise Single Sign-On Deployment 12/13/2008 11:32 AM ACorrea
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

# re: Clustered Enterprise Single Sign-On Deployment 12/16/2008 2:35 AM AC
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

# re: Clustered Enterprise Single Sign-On Deployment 2/25/2009 2:42 PM Sam
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

# re: Clustered Enterprise Single Sign-On Deployment 3/3/2009 8:26 AM MikeH
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...

Post A Comment
Title:
Name:
Email:
Website:
Comment:
Verification: