Infrastructure snapshots : SQL

Clustering SQL 2005 and Administrative shares

mbaher@microsoft.com — Fri, 23 Mar 2007 21:13:05 GMT

One of our partners was installing SQL 2005 64 bit cluster and while he was in the components selection page he faced this error "The drive specified cannot be used for program location. Program files must be installed on a valid local disk available on all cluster nodes". One of my colleagues was onsite and they gave me a call to help, looking to the KB articles we found that we must use an account with Administrative privilege on the nodes, another article highlighted that the installation shouldn't be on the root of the drive. Looking to the situation we are in we found that we are using the Administrator account and that we are not installing to the root of the drive!!!

After further investigations I found that the Administrative shares "C$, D$, etc..." are disabled using registry that is applied by domain security policies using group policy, since SQL installation will require connectivity to the administrative shares we deleted the key, excluded the servers from the policy, restarted both nodes and restarted the installation and it works smoothly with no problems.

Summary is if you faced this error in SQL cluster installation, make sure that you can access the Administrative hidden shares on both nodes...

Upgrading Reporting Services farm? Check the IP Address binding

mbaher@microsoft.com — Tue, 19 Dec 2006 18:48:00 GMT

Doing an upgrade from SQL 2000 Reporting Services to SQL 2005 Reporting Services in a scale-out deployment is not that tough task however while I was doing an upgrade in a Scale-Out deployment where the nodes are configured in a Network Load Balance farm I faced a problem where the setup generates an error in the middle of the reporting services 2005 installation and refused to continue, no worries; aborting the upgrade in this phase was not dangerous as the existing reporting services is not yet replaced... Digging more I found that the Default Web Site is bind to the NLB IP Address and in order for the setup to run without problems the Default Web Site IP Address should be set to "All Unassigned" and not to the NLB IP, sounds logic the reporting services setup will try to read the site configuration by binding to the local server IP however the website is configured to listen only to the NLB IP address which will confuse the setup wizard, setting the IP Address to all unassigned will make the setup to read the site configuration with no problems.

Note: You can change it back again after the upgrade process

Enabling SSL in SQL 2005 cluster

mbaher@microsoft.com — Sun, 17 Dec 2006 00:20:00 GMT

Did you tried to enable SQL encryption between the client and your SQL instance? I thought that configuring SQL 2005 cluster to encrypt its traffic is simple however I discovered that it is not that straight forward and you always get this error “The server could not load the certificate it needs to initiate an SSL connection. It returned the following error: 0x8009030d. Check certificates to make sure they are valid” to understand more about SSL in SQL 2005 & how to configure it read below.

Microsoft SQL Server 2005 can use Secure Sockets Layer (SSL) to encrypt data that is transmitted across a network between an instance of SQL Server and a client application. The SSL encryption is performed within the protocol layer and is available to all SQL Server clients except DB Library and MDAC 2.53 clients.

SSL can be used for server validation when a client connection requests encryption. If the instance of SQL Server is running on a computer that has been assigned a certificate from a public certification authority, identity of the computer and the instance of SQL Server is vouched for by the chain of certificates that lead to the trusted root authority. Such server validation requires that the computer on which the client application is running be configured to trust the root authority of the certificate that is used by the server. Encryption with a self-signed certificate is possible as the Credentials (in the login packet) that are transmitted when a client application connects to SQL Server 2005 are always encrypted. SQL Server will use a certificate from a trusted certification authority if available. If a trusted certificate is not installed, SQL Server will generate a self-signed certificate when the instance is started, and use the self-signed certificate to encrypt the credentials. This self-signed certificate helps increase security but it does not provide authentication or nonrepudiation. If the self-signed certificate is used, and the value of the ForceEncryption option is set to Yes, all data transmitted across a network between SQL Server and the client application will be encrypted using the self-signed certificate. Note that SSL connections that are encrypted by using a self-signed certificate do not provide strong security. They are susceptible to man-in-the-middle attacks. You should not rely on SSL using self-signed certificates in a production environment or on servers that are connected to the Internet.

Note: Enabling SSL encryption increases the security of data transmitted across networks between instances of SQL Server and applications. However, enabling encryption does slow performance. When all traffic between SQL Server and a client application is encrypted using SSL, the following additional processing is required:

An extra network roundtrip is required at connect time.
Packets sent from the application to the instance of SQL Server must be encrypted by the client Net-Library and decrypted by the server Net-Library.
Packets sent from the instance of SQL Server to the application must be encrypted by the server Net-Library and decrypted by the client Net-Library.

To configure SSL encryption to work with a certificate from a public certification authority follow the below steps:

Generate a certificate with the following requirements

Certificate CSP should be “Microsoft RSA SChannel Cryptographic Provider”
The certificate must be meant for server authentication. This requires the Enhanced Key Usage property of the certificate to specify Server Authentication (1.3.6.1.5.5.7.3.1)
The Subject property of the certificate must indicate that the common name (CN) is the same as the host name or fully qualified domain name (FQDN) of the server computer. If SQL Server is running on a failover cluster, the common name must match the host name or FQDN of the virtual server and the certificates must be provisioned on all nodes in the failover cluster

Import the same certificate on both nodes into the following locations

Computer container
SQL services account personal container

Add the SQL service account into the local administrator group of both cluster nodes
Open the registry editor and add the thumbprint of the certificate into the following string key “Certificate” under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\MSSQL.x\MSSQLServer\SuperSocketNetLib”

Using Certificate Mgr (MMC), double-click on the Certificate.
Select the Details tab
Scroll down to Thumbprint and highlight
Copy the Thumbprint numbers and paste into Notepad
Remove all the spaces from the string
Copy the string and paste in Registry in the value for Certificate string at:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\MSSQL.1\MSSQLServer\SuperSocketNetLib
Restart the cluster node

Note that after doing all of the above steps you will notice that the certificates is not listed in the SQL Server configuration manager - > Protocols for the instance. However the SSL is working & you can check by looking into the SQL logs. To get to know that your certificate loaded successfully try to search SQL Server Error log (in SSMS) for

Source: Server

Message contains: certificate

Note: When Microsoft SQL Server 2005 is running under the Network Service account, you cannot enable encryption by using a certificate. If you provision a certificate for use in encryption, SQL Server will not start. Additionally, you may notice an error message in the SQL Server error log. To solve this problem compile the code in KB 900495 http://support.microsoft.com/?kbid=900495

SQL 2000 scale out reporting services upgrade

mbaher@microsoft.com — Sun, 17 Dec 2006 00:10:00 GMT

I was doing an upgrade for a scale out deployment for SQL Reporting Services 2000 and the servers were having only 1 NIC. After the upgrade finished I found that the reporting services is not working as it was not initialized. Here are the details:

Symptom:

Reporting services is not initialized on both nodes with an error "can't connect to the database server" in the event viewer, accordingly the report generation stopped.

Cause:

The encryption keys was corrupted on the reporting databases accordingly the nodes initialization can't succeed

Resolution:

From node1 delete the encryption key
Go to initialization page and make sure that node1 is listed as initialized and that no other nodes are listed
From node2 connect to the database source to create a new id in the database
Go back again to node 1 "physical server"
In the initialization page you should find the second node listed now
Select node2 and click initialize
If no errors displayed, make sure that both nodes are checked as initialized and the icon for the page is green and that the error is no longer appear in the event viewer

Note: to be able to initialize the second node from the first node while NLB is enabled we have to create the below registry key to enable the InterHost communication while NLB is enabled and configured as Unicast KB898867.

Click Start, click Run, type regedit, and then click OK.
Locate and then click the following registry subkey: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\WLBS\Parameters\Interface\{GUID}Note The {GUID} placeholder represents the GUID of the particular NLB instance. You can use the ClusterIPAddress subkey in this hive to identify different NLB clusters.
On the Edit menu, click New, click DWord Value, and then add the following value data. Value name UnicastInterHostCommSupport Value 1
Note If you set the UnicastInterHostCommSupport registry entry to any non-zero value, Unicast InterHost Communication Support will be enabled.
Quit Registry Editor.
Open a command prompt, and then type the following command "NLB RELOAD"