GAPTHEGURU

Geek with special skills

Installation of SSO on SQL Failover Cluster

In this post I will tell a story of my experience with installation of SSO on SQL Cluster. Each BizTalk Server has an Enterprise Single Sign-On service (EntSSO.exe). Enterprise Single Sign-On is also referred as SSO or EntSSO. SSO serves two purposes. One is for data encryption, that is, port URI data. And the other is, as what the name indicates, Single Sign-On. Single Sign-On is about credential mapping. BizTalk Server SSO currently supports only Windows-initiated Single Sign-On. That means you can only map Windows users accounts to external application (affiliate application) user accounts. On the inbound side the sender is authenticated with Windows; on the outbound side, BizTalk Server automatically authenticates with the affiliate applications using the preconfigured credential mapping. Single Sign-On is a useful feature in business-to-business (B2B) scenarios.

Note: However the encryption function is mandatory for a BizTalk system. Single Sign-On for credential mapping can be solved with other tools like Oracle Wallet.

In addition to the SSO services running on each of the BizTalk Servers, there is a master secret server. The master secret server is a server with the SSO service running on it. The master secret server can be one of the SSO services running on one of the BizTalk Servers, or a dedicated master secret server.

It is the same executable called EntSSO.exe, but with an additional sub component responsible for maintain and supply the master secret key to the SSO services on the other BizTalk Servers. The other SSO services running on the BizTalk Servers check every 30 seconds to see whether the master secret has changed. If it has changed, they read it securely; otherwise, they continue to use the master secret they already have cached in memory.

Considering there is only one master secret server in your entire environment and the dependency of BizTalk Server, it is recommended that you use an active-passive cluster configuration for the master secret server. Because the master secret server doesn’t consume a lot of resources, it is very common to use the SQL Server failover cluster for clustering the master secret server.

On the first server cluster node where you run BizTalk Server Configuration, you choose to create a new SSO system. That makes the cluster node as the master secret server. The host name of the master secret server is the host name of the physical cluster node. The master secret key is automatically generated on that node. On the other cluster node, you choose to join the existing SSO system. To cluster the master secret server, you need to change the master secret server from the first cluster node host name to the virtual SQL Server failover cluster network name (NameSQL1), and create a SSO generic service cluster resource. At the end, you restore the master secret key to the other cluster nodes. So, when the cluster fails over to another node, that node has the master secret. These steps can be done using the domain admin account (usually a network senior administrator will perform these steps with this account i.e. as example I will name the account InstallBizTalk).

Clustering the master secret server service is a complicated process. You might find it confusing when and where you need to perform a step, and the order of the steps. Here are some general rules:

· You must install and configure SSO on each of the cluster nodes. When you create the new SSO system on the first cluster node, this node can be either an active cluster node or a passive cluster node.

· After you successfully installed and configured SSO on all of the cluster nodes, you must update the master secret server host name from a physical cluster node host name to the virtual cluster network name, and you must change the rename from an active node.

· After the master secret server host name is changed, you must restart the SSO service on the active node to refresh the cache by taking the SSO cluster resource offline and then online.

· You must create an SSO cluster resource before restoring the master secret key on the other cluster nodes.

· Before you restore the master secret key on a cluster node, you must make it the active node first.

Steps involved to successfully install and configure SSO on cluster will be outlined here.

There are several SSO user groups. Two of them are required when configuring the master secret server. SSO Administrators have the highest level user rights in the SSO system; and SSO Affiliate Administrators defines the affiliate applications that the SSO system contains.

To create a domain group account for the SQL Server service groups

1. If you haven’t already logged on or if you are logged on with a different credential, log on to Cluster Node A using domain admin account.

2. Click Start, and then click Run.

3. In the Run dialog box, enter dsa.msc, and then click OK.

4. From Active Directory Users and Computers, if the YourDomain domain is not already expanded, click the plus sign (+) to expand the YourDomain.com domain.

5. In the left pane, right-click Users, point to New, and then click Group.

6. From New Object – Group, enter the following values, and then click OK.

Name Value
Group name SSO Administrators
Group scope Global
Group type Security

7. Repeat steps 5 to 6 to create one more group:

Name Value
Group name SSO Affiliate Administrators
Group scope Global
Group type Security

To create a domain user account for the SSO Service

1. (continue from the previous procedure)

2. In the left pane, right-click Users, point to New, and then click User.

3. From New Object – User, enter the following values, and then click Next.

Name Value
First name SSO
Last name Service
User logon name SSOService

4. Enter or select the following values, and then click Next.

Name Value
Password TBD
Confirm password TBD
User must change password at next logon (clear)
User cannot change password (select)
Password never expires (select)
Account is disabled (clear)

5. Click Finish.

Both YourDomain\SSOSerivce and domain admin account need to be members of the YourDomain\SSO Administrators group. It is designated for installing and configuring the BizTalk Server system.

To make YourDomain\SSOService and domain admin account members of SSO Administrators

1. (continue from the previous procedure)

2. In the left pane, highlight Users.

3. In the right pane, right-click SSO Service, point to All Tasks, and then click Add to a group.

4. From Select Group, enter or select the following values, and then click OK.

Name Value
Select this object type Group or Built-in security principal
From this location YourDomain
Enter the object name to select SSO administrators

5. To acknowledge that the account was created, click OK.

6. Repeat steps 3 to 5 to add domain admin account into the same group.

Granting YourDomain\SSO Administrators Full Control on Cluster Node A

You need to grant YourDomain\SSOService or YourDomain\SSO Administrators with the full control privilege on the cluster administrator.

To grant YourDomain\SSO Administrators full control on the cluster

1. If you haven’t already logged on or if you are logged on with a different credential, log on to Cluster Node A as YourDomain\IInstallBizTalk.

2. Click Start, point to All Programs, point to Administrative Tools, and then click Cluster Administrator.

3. From Cluster Administrator, in the left pane, right-click CLUSTER NODE A, and then click Properties.

4. From CLUSTER NODE A Properties, click the Security tab, and then click Add.

5. From Select Users, Computers, or Groups, enter the following values, and then click OK.

Name Value
Select this object type Group or Built-in security principal
From this location YourDomain.com
Enter the object name to select SSO administrators

6. Verify the Allow box is selected, and then click OK.

Installing the SSO Components on Cluster Node A

With the accounts and permissions configured in the last step, you can now install the master secret server. BizTalk Server is not cluster aware as SQL Server is. You will need to install SSO on each of the cluster nodes. You will also need to create the SSO cluster resource manually.

BizTalk Server installation process has two parts. In this step, you will install the components. And the next step is configuring the master secret server.

To install the SSO components on Cluster Node A and Cluster Node B

1. If you haven’t logged on, log on to Cluster Node A as YourDomain\InstallBizTalk.

2. Run setup.exe to install BizTalk Server 2006 R2.

3. On the Start page, click Install Microsoft BizTalk Server 2006 R2 on this computer.

4. On the Customer Information page, enter information in the User name box, the Organization box, and the Product key box, and then click Next.

5. On the License Agreement page, read the license agreement, select yes, I accept the terms of the license agreement, and then click Next.

6. On the Component Installation page, clear all the check boxes, select Enterprise Single Sign-On Administration Module and Enterprise Single Sing-On Master Secret Server from the Additional Software group, and then click Next.

clip_image002

7. On the Summary page, click Install.

8. On the Installation Completed page, clear Launch BizTalk Server Configuration check box, and then click Finish.

Installing the SSO Components on Cluster Node B

Repeat the same steps to install the SSO components on Cluster Node B.

Configuring the Master Secret Server on Cluster Node A

Configuring the master secret server has three parts, creating SSO database, assigning SSO service account, and backing-up the master secret. Notice there are two options, create a new SSO system, and join an existing SSO system. On the first cluster nodes, you must choose to create a new SSO system. When you create a new SSO system, you must specify the database server name, and the database name. But you don’t need to specify the master secret server host name. The current host name, becomes the default master secret server. Later, you must change the master secret server from the physical cluster node host name to the virtual cluster host name, YourVirtualServerName.

It doesn’t matter whether Cluster Node A is the active node or a passive node when you go through this procedure.

To configure the master secret server on Cluster Node A

1. If you haven’t logged on, log on to Cluster Node A as YourDomain\InstallBizTalk.

2. Click Start, point to All Programs, point to Microsoft BizTalk Server 2006, and then click BizTalk Server Configuration.

3. On the Microsoft BizTalk Server 2006 Configuration page, choose Custom Configuration, enter the following values, and then click Configure.

Name Value
Database server name Database Name Cluster
User name YourDomain\SSOService
Password TBD

4. in the left pane, click Enterprise SSO.

5. In the right pane, enter or select the following values:

Name Value
Enable Enterprise Single Sign-On on this computer (checked)
Create a new SSO system (selected)
SSO Database: Server Name Database Name Cluster
SSO Database: Database Name SSODB
Enterprise Single Sign-On Service: Account YourDomain\SSOService
SSO Administrator(s): Windows Group YourDomain\SSO Administrators
SSO Affiliate Administrators(s): Windows Group YourDomain\SSO Affiliate Administrators

image

6. In the left pane, click Enterprise SSO Secret Backup. The Enterprise SSO secret is very critical. You must back it up to a file. It is a good practice to burn the key into a CD and store the CD in a safe place.

7. In the right pane, enter the following values:

Name Value
Secret back password TBD
Confirm password TBD
Password reminder TBD
Backup file location C:\Program Files\Common Files\Enterprise Single Sign-On\SSOSecret.bak)

8. Click Apply Configuration.

9. On the Summary page, to apply the configuration, click Next.

10. Verify that the Configuration Result is Success, and then click Finish.

11. Close Microsoft BizTalk Server 2006 Configuration.

1.1.4 Configuring SSO on Cluster Node B

On the second node, you choose to join the existing SSO system. When joining the existing SSO system, it shares the SSO database of the existing SSO system.

To configure the master secret server on Cluster Node B

1. If you haven’t logged on, log on to Cluster Node B as YourDomain\InstallBizTalk.

2. Click Start, point to All Programs, point to Microsoft BizTalk Server 2006, and then click BizTalk Server Configuration.

3. On the Microsoft BizTalk Server 2006 Configuration page, choose Custom Configuration, enter the following values, and then click Configure.

Name Value
Database server name ServerName Database Cluster
User name YourDomainSSOService
Password TBD

4. In the left pane, click Enterprise SSO.

5. In the right pane, enter or select the following values:

Name Value
Enable Enterprise Single Sign-On on this computer (checked)
Join an existing SSO system (selected)
Server Name ServerName Database Cluster
Database Name SSODB
Account YourDomain\SSOService

6. Click Apply Configuration.

7. On the Summary page, to apply the configuration, click Next.

8. Verify that the Configuration Result is Success, and then click Finish.

9. Close Microsoft BizTalk Server 2006 Configuration.

1.1.5 Updating the Master Secret Server Host Name

When SSO was configured on the first cluster node, it created a new SSO system. It used the host name of the physical cluster node as the master secret server host name that is Cluster Node A. You must change it to the server cluster virtual name, which is YourVirtualClusterName. This procedure must be carried out from the active cluster node. All it does is to update the master secret server field in the SSO database.

To configure the master secret server on Cluster Node B

1. If you haven’t already logged on, log on to Cluster Node A as YourDomain\InstallBizTalk.

<sso>
  <globalInfo>
    <secretServer> ServerName Database Cluster</secretServer>
  </globalInfo>
</sso>

2. Open a notepad.exe, create a file with the following content, and then save it as “C:\Program Files\Common Files\Enterprise Single Sign-On\SSOCluster.xml” (with the double quotes). The content is case sensitive.

clip_image002[5]

3. Open a command prompt, and then change directory to the C:\Program Files\ Common Files\Enterprise Single Sign-On\ folder.

4. From the command prompt, execute the following command:

ssomanage -updatedb SSOCluster.xml

5. Verify the master secrete server name has been changed to  as shown below:

C:\Program Files\Common Files\Enterprise Single Sign-On>ssomanage -updatedb ssocluster.xml
Using SSO server on this computer
 
Updated SSO global information with the following values -
 
SSO secret server name                  : ServerName Database Cluster
SSO Admin account name                  : NOT CHANGED
SSO Affiliate Admin account name        : NOT CHANGE

image

Creating SSO Cluster Resource

BizTalk Server is not cluster aware. So you must manually create the master secret server cluster resource. You can either create a dedicated virtual server (cluster group) for the SSO cluster resource, or use an existing cluster group. The instructions provided use the SQL Server Cluster Group. If you create a dedicated cluster group, you also need to create a network name cluster resource depended by the SSO cluster resource.

To Create SSO cluster resource

1. If you haven’t already logged on, log on to Cluster Node A as YourDomain\InstBizTalk.

2. Click Start, point to All Programs, point to Administrative Tools, and then click Cluster Administrator.

3. In the left pane, expand CLUSTER NODE A, expand Groups, and then expand SQL Server Cluster Group. If you get a prompt before it opens Cluster Administrator, choose Open Existing Cluster, and point it to CLUSTER NODE A.

4. Right-click SQL Server Cluster Group, click New, and then click Resource.

5. From New Resource, enter or select the following values, and then click Next.

clip_image002[9]

6. From Possible Owners, verify that CLUSTER NODE A and CLUSTER NODE B are in the Possible owners list, and then click Next.

7. From Dependencies, select SQL Network Name (Cluster Node A) and click Add. And then click Next.

8. From Generic Service Parameters, type or select the following values, and then click Next:

clip_image002[11]

9. From Registry Replication, click Finish.

clip_image001Note
Do not configure any registry keys for replication in the Registry Replication dialog box. Replication of registry keys is not a requirement when creating a SSO cluster resource and, in fact, may cause problems when failover of this cluster resource is attempted.

10. In the details pane, right-click ENTSSO, and click Bring Online. Verify that the state is changed to Online.

Restoring the Master Secret on Cluster Node B

Before restoring the master secret on Cluster Node B, you must make Cluster Node B as the active cluster node, and restart the cluster resource by taking the cluster resource offline and then online.

To make Cluster Node B the active cluster node

1. Log on to Cluster Node B as RBW-NL\InstBizTalk.

2. Click Start, point to All Programs, point to Administrative Tools, and then click Cluster Administrator.

3. From Cluster Administrator, expand CLUSTER NODE A in the left pane, expand Groups, and then expand SQL Server Cluster Group. In the details pane, the Owner column of the cluster resources shows the active cluster node

4. If Cluster Node B is not the active cluster node, in the left pane right-click SQL Server Cluster Group, and then click Move Group. Wait until all the cluster resources are online.

5. In the details pane, right-click ENTSSO, and then click Take Offline. Wait until all the cluster resources are offline.

6. In the details pane, right-click ENTSSO, and then click Bring Online. Wait until all the cluster resources are online.

To restore the master secret on the second cluster node

1. Copy the master secret backup file, C:\Program Files\Common Files\Enterprise Single Sign-On\SSOSecret.bak, on Cluster Node A to the same folder on Cluster Node B. SSOSecret.bak is how you named the file when you configured the master secret server on Cluster Node A.

2. Open a command prompt, and then change the directory to C:\Program Files\Common Files\Enterprise Single Sign-On.

3. Type and execute the following command in the command prompt:

ssoconfig -restoresecret SSOSecret.bak

image

Through following this procedure you will be successful in deploying SSO on SQLCluster and configure SSO. My experience is that in following this procedure with an senior administrator inside an organization works the best. This procedure us done with BizTalk Server 2006 R2, but is also suitable for BizTalk Server 2009.

Advertisements

02/28/2012 Posted by | Active Directory, Biztalk, Cluster Configuration, Sql Server, SSO, Windows Server | , , , | 1 Comment

Monitoring tempdb Transactions and Space usage

As the tempdb database is the common global resource for all the operations going on in SQL Server, so the DBA has to be bit cautious about the use of it. Because any unexpected operations by the applications running under the SQL Server instance or any adhoc query by the user can eat all the space available to the tempdb database resulting decrease in the performance of other applications running under the same instance. So it is necessary to keep track the usage of tempdb database by various applications and processes and to take necessary actions when the size falls down below the threshold limit. Monitoring tempdb over time will help in determining the optimal size of the tempdb

Use the below query to check the current tempdb size:

 

02/16/2012 Posted by | SQL Scripting, Sql Server, T-SQL | , , , | 1 Comment

Cleaning up TempDB

In many significantly large production environments, the TempDB can regularly grow with little or no thought towards maintaining some control over the lifespan of tables. In most situations, TempDB is not used heavily enough to be a problem, but occasionally due to non-ideal code, many tables are created and left with no regular cleanup.

While I am a proponent of using Table Variables over Temp Tables, the fact remains that many developers, and a significant number of DBAs use Temp Tables, and it is left in the hands of the DBA to deal with any complications caused by this.

The most obvious flaw in using Temp Tables in a 24/7 Productions Environment, is that if your SQL Server box never reboots, your TempDB never gets cleaned out (unless it’s by the code that created the Temp Tables, and that never happens. To deal with this issue, I have created a SP that runs once an hour, deleting Temp Tables that are more than 12 hours old (unless they reside in a Table (TempTableToKeep) that I use to store the names of tables I want to keep, and the date/time to finally delete them.

The code:
IF EXISTS (SELECT * FROM dbo.sysobjects WHERE id = object_id(N’[dbo].[TempTableToKeep]‘) AND OBJECTPROPERTY(id, N’IsUserTable’) = 1)
DROP TABLE [dbo].[TempTableToKeep]
GO
CREATE TABLE [dbo].[TempTableToKeep] (
[TempTable] [varchar] (100) COLLATE SQL_Latin1_General_CP1_CI_AS NOT NULL ,
[DateToDelete] [datetime] NOT NULL
) ON [PRIMARY]
GO

IF EXISTS (SELECT name FROM sysobjects WHERE  name = N’sp_DropTempTables’ AND type = ‘P’)
DROP PROCEDURE sp_DropTempTables
GO
CREATE PROCEDURE sp_DropTempTables
AS
DECLARE @Cursor AS CURSOR
DECLARE @Name AS VARCHAR(100)
DECLARE @TableName AS SYSNAME
DECLARE @Owner AS VARCHAR(100)
DECLARE @SQL AS NVARCHAR(200)
SET @Cursor = CURSOR SCROLL FOR
SELECT    tempdb.dbo.sysobjects.name, tempdb.dbo.sysobjects.*
FROM    TempTableToKeep
RIGHT OUTER JOIN tempdb.dbo.sysobjects ON TempTableToKeep.TempTable = tempdb.dbo.sysobjects.name
WHERE    ((tempdb.dbo.sysobjects.crdate < DATEADD(hh, -12, GETDATE())) AND (tempdb.dbo.sysobjects.type = ‘U’) AND (TempTableToKeep.DateToDelete < GETDATE())) OR
((tempdb.dbo.sysobjects.crdate < DATEADD(hh, -12, GETDATE())) AND (tempdb.dbo.sysobjects.type = ‘U’) AND (TempTableToKeep.DateToDelete IS NULL))
OPEN @Cursor
FETCH FIRST FROM @Cursor
INTO @Name, @Owner
WHILE (@@FETCH_STATUS = 0)
BEGIN
If (@@FETCH_STATUS = 0)
BEGIN
IF EXISTS(SELECT name FROM tempdb..sysobjects WHERE  name = @Name AND type = ‘U’)
BEGIN
SET @SQL = ‘DROP TABLE tempdb..’ + @Name
–PRINT @SQL
EXECUTE sp_executesql @SQL
END
FETCH NEXT FROM @Cursor
INTO @Name
END
END
CLOSE @Cursor
DEALLOCATE @Cursor
GO

02/16/2012 Posted by | SQL Scripting, Sql Server, T-SQL | , , , | 2 Comments

Max Memory Settings for SQL Server 2005/2008

It is pretty important to make sure you set the Max Server memory setting for SQL Server 2005/2008 to something besides the default setting (which allows SQL Server to use as much memory as it wants, subject to signals from the operating system that it is under memory pressure). This is especially important with larger, busier systems that may be under memory pressure.

This setting controls how much memory can be used by the SQL Server Buffer Pool.  If you don’t set an upper limit for this value, other parts of SQL Server, and the operating system can be starved for memory, which can cause instability and performance problems. It is even more important to set this correctly if you have “Lock Pages in Memory” enabled for the SQL Server service account (which I always do for x64 systems with more than 4GB of memory).

These settings are for x64, on a dedicated database server, only running the DB engine, (which is the ideal situation).

Physical RAM                        MaxServerMem Setting

2GB                                           1500

4GB                                           3200

6GB                                           4800

8GB                                           6400

12GB                                         10000

16GB                                         13500

24GB                                         21500

32GB                                         29000

48GB                                         44000

64GB                                         60000

72GB                                         68000

96GB                                         92000

128GB                                       124000

If you are running other SQL Server components, such as SSIS or Full Text Search, you will want to allocate less memory for the SQL Server Buffer Pool. You also want to pay close attention to how much memory is still available in Task Manager. This is how much RAM should be available in Task Manager while you are under load (on Windows Server 2003):

Physical RAM            Target Avail RAM in Task Manager

< 4GB                               512MB – 1GB

4-32GB                              1GB – 2GB

32-128GB                            2GB – 4GB

> 128GB                              > 4GB

You can use T-SQL to set your MaxServerMemory setting. The sample below sets it to 3500, which is the equivalent of 3.5GB. This setting is dynamic in SQL Server 2005/2008, which means that you can change it and it goes into effect immediately, without restarting SQL Server.

–Turn on advanced options

EXEC sp_configure ‘Show Advanced Options’ ,1;

GO

RECONFIGURE;

GO

–Set max server memory

EXEC sp_configure ‘max server memory (MB)’ ,10000;

GO

RECONFIGURE;

GO

–See what the current values are

EXEC sp_configure;

You can also change this setting in the SSMS GUI, as you see below:

02/13/2012 Posted by | SQL Scripting, Sql Server, SSAS, SSIS, T-SQL | | Leave a comment

   

%d bloggers like this: