TJ-RAV

You are not able to install SQL server 2008 standard on a VISTA machine

TechNet Archive — Sat, 21 Feb 2009 01:00:00 GMT

I got to know that many of the techies and dev's are affected due to this issue and as it is a known issue and also not documneted, we definitely should post this to help you guys further with your deployment, thanks to Manikandan who got this case and drew our attention toward the problem

Problem:
========

You are not able to install SQL Server 2008 standard on a VISTA machine

Error Message:

=============

02/04/2009 14:33:20.418

02/04/2009 14:33:20.419 Setup launched

02/04/2009 14:33:20.420 Attempting to determine media source

02/04/2009 14:33:20.421 Media source value not specified on command line argument.

02/04/2009 14:33:20.421 Setup is launched from media directly so default the value to the current folder.

02/04/2009 14:33:20.422 Media source: C:\Users\Alan\Desktop\SQL2008\

02/04/2009 14:33:20.423 Attempt to determine media layout based on file 'C:\Users\Alan\Desktop\SQL2008\mediainfo.xml'.

02/04/2009 14:33:20.550 Media layout is detected as: Full

02/04/2009 14:33:20.550 Media LCID is detected as: 1033

02/04/2009 14:33:20.551 Local setup.exe not found, so continuing to run setup.exe from media.

02/04/2009 14:33:20.552 /? or /HELP or /ACTION=HELP specified: false

02/04/2009 14:33:20.553 Help display: false

02/04/2009 14:33:20.553 Checking to see if we need to install .Net version 3.5

02/04/2009 14:33:20.554 Determining the cluster status of the local machine.

02/04/2009 14:33:20.560 The local machine is not configured as a cluster node.

02/04/2009 14:33:20.561 Attempting to find media for .Net version 3.5

02/04/2009 14:33:20.609 .Net version 3.5 is installed

02/04/2009 14:33:20.610 RedistMSI::GetExpectedBuildRevision - Setup expects MSI 4.5.6001.22159 at the minimum

02/04/2009 14:33:20.611 Attempting to get Windows Installer version

02/04/2009 14:33:20.612 Setup closed with exit code: 0x80070002

02/04/2009 14:33:20.612

======================================================================

TROUBLESHOOTING/ RESOLUTION

***************************

Environment details :

OS : Vista Ultimate SP1 6001

SQLBuild : sql server 2008 as a (std edn X86)

ü When we click the sql server 2008 setup file we get the above error and the setup aborts.

ü Generally this error doesn't even create any in setup bootstrap folder as it is not even reaching to invoke the setup.

How we resolved this issue:

ü Verify that if these 2 registry keys exist and what their values are, if they dont exist please create them

Registry hive under:

HKLM: Software\Microsoft\Windows\CurrentVersion\Installer

Registry value name: InstallerLocation

LPCWSTR lpSubKey = L"Software\\Microsoft\\Windows\\CurrentVersion\\Installer";

LPCWSTR lpValueName = L"InstallerLocation";

ü The value in that key is supposed to point to system32 directory (C:\WINDOWS\system32\). If the value is there then check if msi.dll is in the location where the registry value points to.

ü If the InstallerLocation Registry Key is missing - we should create it and set it to the System32 directory. {In most of the cases we find this}

ü We should be able to install SQL Server after this on Vista.

Checklist for Double Hop issues {IIS and SQL Server}

TechNet Archive — Thu, 29 Jan 2009 17:23:06 GMT

Checklist for Double Hop issues and the tasks to be done to create the right set of Delegations for this Problem

NOTE: We have to set the IIS Server and SQL Server both Trusted for Delegation and the details are right below

1. Check for DNS Resolution. Of course J but you need to make sure that SRV Records ldp and Kerberos are registered

2. Verify that is using TCP

If you find issues with UDP fragmentation follow.

How to force Kerberos to use TCP instead of UDP in Windows Server 2003, in Windows XP, and in Windows 2000

http://support.microsoft.com/?id=244474

3. Make sure that “Account is sensitive and cannot be delegated” is unchecked

This option “Allows control over a user account, such as for a guest or temporary account. This option can be used if this account cannot be assigned for delegation by another account.” Customer’s do it for some user accounts, required for some of their legacy applications which does not support Kerberos.

4. Check if it is constrained delegation (windows 2003 domain functional level required) or unconstrained delegation.

Middle tier server configured to delegate to all the services or it is selected for specified services only (constrained delegation)

è Go to properties of machine account of middle tier server in active directory users and computers and delegation tab.

è To configure the account to use constrained delegation without protocol transition, select Use Kerberos Only.

è If the service runs under a domain user account, then you will need to configure the service account for delegation

Note: If running on the default port like 80 for http, leave the port field empty otherwise specify it exclusively.

5. Add any accounts that will need to delegate credentials (such as the IIS account) to Impersonate a client after authentication and Act as part of the operating system under User Rights Assignment.( middle tier service should be configured for impersonation)

6. Verify SPNs for Back-end Service Accounts

To List the SPN’s use setspn –L Account

è Verify that the server which is in middle tier (receiving user credentials and passing them to third tier) has the SPN for the service it is running registered.

Note: Verify that these two SPNs for the service account are present:

• One for ServiceClass/Host:Port

• One for ServiceClass/FQDN

è Verify that the server which is the backend (the ultimate destination for which the middle one is delegated) has the SPN for the service it is running registered) {This is for SQL Server see below for the SQL Server account SPN creation)

SQL SERVER RELATED SETTINGS FOR THE DELEGATION ISSUE

7. Verify that the user is authorized to access the back-end server’s resources.

8. All communication for the delegation scenario from user to middle tier to back end server is using TCP/IP.

9. If using IIS as middle tier server verify that the client operating system connecting to it has the Integrated Windows Authentication option selected.

SQL SERVER RELATED SETTINGS FOR DELEGATION

1) If you do not select the Enable Kerberos Authentication option on the Network Name resource and a computer object does not exist in Active Directory, refer to the following Microsoft Knowledge Base article for information about how to troubleshoot the Network Name resource:

257903 Cluster network name may not come online with event ID 1052

http://support.microsoft.com/?id=257903

2) Once the above is done, go ahead and check in AD whether the Virtual SQL Server Name is showing up {Set the Computer Object “Trusted for Delegation”}

3) Set the Right set of SPN’s which only a Domain Admin Should do

Create an SPN for SQL Server

Caution:

SQL Server only uses Kerberos if the client uses the TCP/IP protocol to connect to SQL Server. For example, if a client uses the Named Pipes protocol, Kerberos is not used. If you have multiple instances of SQL Server on a computer, you must configure a Server Principal Name (SPN) for each instance of SQL Server because each instance of SQL Server uses a unique TCP-IP port.

Important:

If the SQL Server service is running under the LocalSystem account, you do not have to manually configure an SPN for SQL Server. The SPN is created automatically when the SQL Server service starts. If the SQL Server service runs under a domain user account, you must manually configure an SPN. To do so, follow these steps.

To configure an SPN for SQL Server, use the SETSPN utility in the Microsoft Windows Resource Kit. To download the SETSPN utility, visit the following Microsoft Web site.

Before you run SETSPN, consider the following information:

è You must run setspn.exe under a logon account with permissions to register the SPN.

è Note the domain user account that the instance of SQL Server is running under. In the following examples, this account is named <SQL_Service_Account>.

è Important: If the instance of SQL Server is running under the LocalSystem account, you do not have to run the SETSPN utility.

è You must have the fully qualified domain name (FQDN) of the computer that is running SQL Server. To determine the FQDN of the computer that is running SQL Server, use the ping utility.

è Ping the virtual SQL Server name to obtain the IP address, and then run ping -a to make sure that the FQDN is correctly returned by the DNS.

Note:

If you are using SQL Server failover clustering, you use the FQDN for the virtual SQL Server. Note the exact TCP/IP port that the instance of SQL Server uses. To determine this information, open SQL Server Configuration Manager on the computer that is running SQL Server, click the instance of SQL Server, and then view the properties for the TCP/IP protocol (default port).

After you determine the domain user account that the SQL Server service is running under, the FQDN of the computer that is running SQL Server, and the TCP/IP port that the instance of SQL Server is using, follow these steps to create the SPN for SQL Server.

Note:

You must be a member of the Domain Administrators group to run the SETSPN command.

1) If you are using SQL Server failover clustering, run the following SETSPN command:

setspn -A MSSQLSvc/<FQDN> <SQL_Service_Account>

For example, if MySQLServer.MyDomain.com is running under the domain user account SQLSVC, where MySQLServer.MyDomain.com is the name of the instance of SQL Server 2005 that is clustered, run the following command:

setspn -A MSSQLSvc/MySQLServer.MyDomain.com SQLSVC

2) For both clustered and non-clustered computers that are running SQL Server, run the following SETSPN command to register an SPN for the port that the computer that is running SQL Server is using:

setspn -A MSSQLSvc/<FQDN>:<Port> <SQL_Service_Account>

For example, if MySQLServer.MyDomain.com is running under the domain user account SQLSVC on port 1433, run the following SETSPN command:

setspn -A MSSQLSvc/MySQLServer.MyDomain.com:1433 SQLSVC

After the SPN is registered, verify that it is correctly registered by using the LIST feature (-L switch) of the SETSPN utility. Run SETSPN -L <SQL_Service_Account> to list all the SPNs that are registered to the domain user account that the instance of SQL Server is running under:

setspn -L <SQL_Service_Account>

For example, if MySQLServer.MyDomain.com is running under the domain user account SQLSVC on port 1433, run the following command:

setspn -A SQLSVC

The SPN that you created in step 1 (if SQL Server is clustered) and step 2 (if SQL Server is not clustered) is shown in the following output:

C:\>setspn -l SQLSVC

Registered ServicePrincipalNames for CN=SQLSVC,CN=Users,DC=MyDomain,DC=com:

MSSQLSvc/MySQLServer.MyDomain.com

MSSQLSvc/MySQLServer.MyDomain.com:1433

Note:

If you are using SQL Server failover clustering, you must register a SPN without the port number and another SPN with the port number. With a typical, non-clustered computer that is running SQL Server, you only have to register the SPN with the port number. However, if you have an additional SPN without the port number, it will not cause any problems with non-clustered computers.

Delegation Is Not Supported an Example:

SQL Server 2005 Integration Services (SSIS) does not support the delegation of credentials, sometimes referred to as a double hop. In this scenario, you are working on a client computer, Integration Services is installed on a second computer, and SQL Server is installed on a third computer. Although SQL Server Management Studio successfully passes your credentials from the client computer to the second computer on which Integration Services is running, Integration Services cannot pass your credentials on from the second computer to the third computer on which SQL Server is running.

http://msdn.microsoft.com/en-us/library/aa337083(SQL.90).aspx

Note:

If a middle tier service is using NTLM to authenticate to the next service, you typically receive errors such as:

Logon failed for null user

Logon failed for NT AUTHORITY\ANONYMOUS user

If you have verified that each computer uses the Kerberos protocol, a likely cause of the authentication problem is that the middle tier services are not properly configured for delegation. Follow the steps mentioned above.

xp_sendmail query failing with Msg 17925, Level 16, State 1, Line 0

TechNet Archive — Wed, 21 Jan 2009 15:32:00 GMT

Problem Description

Xp_sendmail task in SQL Serevr 2005 might not work on a cluster after upgrading the Exchange to 2007 from Exchange 2003
SQL 2000 SQL mail works with same Exchange 2007 MAPI Profile without any issues
Though as a SQL agent jobs the emails are sent fine for SQL MAIL feature without any issues with the same MAPI profile as a JOb alert, the problem is with only the xp_sendmail funtionality

Cause:

Issues with the Default MAil profile called Outlook which might be corrupt

Error Message

Msg 17925, Level 16, State 1, Line 0
xp_sendmail: failed with mail error 0x80004005

Resolutin Section

-> Try to restart the SQL Server service and see if that taks care of the problem or not.

-> Test whether from the Box where the Outlook Exchange been upgraded can send emails to users or not?

-> Check the SQL server service Startup account credentials used for sending the email using xp_sendmail has got sysadmin privileges. Also make sure that the MAPI outlook profile is been created with same account as well the MAPI profile been using the same account as that off the SQL Server startup account

Check the Pre-requisite list again
=========================

-> For SQL Mail to work we need to configure the mail profile with the SQL Server service account.

-> Running the xp_sendmail under the SQL Server service account which is another requisite {and this account is a Sysadmin}

-> No shared MAPI profile there enabled

-> Fire xp_stopmail and then fire xp_starmail and see if that helps

-> If none of the above ones work follow the process:

1) Go ahead and close Outlook

2) Then got to Control Panel-> Look for Adminitrative tools-> MAIL-> create a New Profile then delete the default Profile Outlook

3) Change the setting on SQLMAIL properties from SSMS and changed it to use NEW MAPI profile and also changethe SQL Server agent Jobs alert system to use the new profile

4) Once the above was done we went ahead and fire

xp_stopmail and xp_startmail

-> After that fired xp_sendmail and that worked.

-> On a cluster please do the same steps on every node and for standalone on the same box.

Could not find any IP address that this SQL Server instance depends upon

TechNet Archive — Wed, 07 Jan 2009 21:38:00 GMT

Problem Description:

After a NIC change of the Server there were issues with starting the SQL Server services and it was failing to start. The error it was throwing was:

Error:
Could not find any IP address that this SQL Server instance depends upon. Make sure that the cluster service is running, that the dependency relationship between SQL Server and Network Name resources is correct, and that the IP addresses on which this SQL Server instance depends are available. Error code: 0x6d9

Environment
SQL Server 2005 (Enterprise Edition) SP2 64 bit
Windows 2003 Enterprise Server SP 2
NO CLUSTER

Resolution:

Ø The error message looked like the SQL Cluster Name’s IP address was not found
Ø But surprisingly we got to know that the SQL is not on a Cluster
Ø Checked the Cluster Services”: Not present. Cluster admin not configured
Ø Question is So how are we picking the Cluster Information for SQL then..
Ø I went ahead and checked the registry and there was it, we had the Cluster key present with a Virtual SQL Server Name {which is the same as the name of the windows machine}, this key should be only present if you have a Cluster not in a Standalone Machine
HKLM\Software\Microsoft\Microsoft SQL Server\MSSQL.1\Cluster {this key was existing}
Ø This can be because of someone might have tried to install SQL as a Cluster resource
Ø We deleted the Cluster key and then we were able to start the SQL Server Services from the Services.msc without any issues.

"Microsoft document explorer" "cannot find one or more components. please reinstall the application"

TechNet Archive — Wed, 07 Jan 2009 12:21:00 GMT

Microsoft SQL Server 2005: Some issues with Installations and Service packs

Problem Description
================
You are trying to install Client tools on a standalone machine and it fails with the following errors:While configuring the Work Station components:

"Microsoft document explorer" "cannot find one or more components. please reinstall the application"Click Ok and then you get

"Microsoft Visual Studio Macros" ""cannot find one or more components. please reinstall the application"

Click OK and then you get:

---------------------------Microsoft SQL Server 2005 Setup---------------------------

There is a problem with this Windows Installer package. A program run as part of the setup did not finish as expected. Contact your support personnel or package vendor.

---------------------------OK ---------------------------

After this the complete Setup Rolls back and it fails going further

SOLUTION
========

Here are the steps we followed to get this resolved

1) Error in the Summary.txt

Sumary.txt shows {under 90/Setupbootstrap}===========================================Machine : E-CONTESTProduct : Workstation Components, Books Online and Development ToolsError : There is a problem with this Windows Installer package. A program run as part of the setup did not finish as expected. Contact your support personnel or package vendor. --------------------------------------------------------------------------------Machine : E-CONTEST Product : Microsoft SQL Server 2005 Tools Product Version : 9.00.1399.06 Install : Failed Log File : C:\Program Files\Microsoft SQL Server\90\Setup Bootstrap\LOG\Files\SQLSetup0011_E-CONTEST_Tools.log Error Number : 1603 --------------------------------------------------------------------------------
SQL Server Setup failed. For more information, review the Setup log file in %ProgramFiles%\Microsoft SQL Server\90\Setup Bootstrap\LOG\Summary.txt.
Also looked at the Tools log to figure out the actual cause==============================================Set_CommitFlag called successfully.CommittedPerfTime Stop: Set_CommitFlag : Tue Mar 25 23:51:42 2008MSI (s) (2C:A8) [23:51:43:033]: Note: 1: 1722 2: SqlWbSetup.5F46584E_060D_4BCB_ADEE_BD15A7BFCC2A 3: D:\Program Files\Microsoft SQL Server\90\Tools\Binn\VSShell\Common7\IDE\SqlWb.exe 4: /setup MSI (s) (2C:A8) [23:52:06:242]: Product: Microsoft SQL Server 2005 Tools -- Error 1722. There is a problem with this Windows Installer package. A program run as part of the setup did not finish as expected. Contact your support personnel or package vendor. Action SqlWbSetup.5F46584E_060D_4BCB_ADEE_BD15A7BFCC2A, location: D:\Program Files\Microsoft SQL Server\90\Tools\Binn\VSShell\Common7\IDE\SqlWb.exe, command: /setup
Error 1722. There is a problem with this Windows Installer package. A program run as part of the setup did not finish as expected. Contact your support personnel or package vendor. Action SqlWbSetup.5F46584E_060D_4BCB_ADEE_BD15A7BFCC2A, location: D:\Program Files\Microsoft SQL Server\90\Tools\Binn\VSShell\Common7\IDE\SqlWb.exe, command: /setup MSI (s) (2C:A8) [23:52:06:398]: Executing op: Header(Signature=1397708873,Version=301,Timestamp=947502671,LangId=1033,Platform=0,ScriptType=2,ScriptMajorVersion=21,ScriptMinorVersion=4,ScriptAttributes=3)MSI (s) (2C:A8) [23:52:06:398]: Executing op: DialogInfo(Type=0,Argument=1033)

Conclude
=======

**************************************************************************************************

The Error message is very clear, while firing the Sqlwb.exe /setup the issue occurred
**************************************************************************************************

2) The error kept on coming and based on the Tools log we went ahead and tried to run the .MSI package directly from the Tools Setup

%Tools\Setup\SQLrun_tools.msi and this time also the setup failed and the pop ups were the same, we decided to do the following:

3) Run the setup from SQLrun_tools.msi and when the pop-up mentioned below comes up

Microsoft SQL Server 2005 Setup
---------------------------
There is a problem with this Windows Installer package. A program run as part of the setup did not finish as expected. Contact your support personnel or package vendor.
---------------------------

OK
***********************DONT CLICK OK***********************

4) Go to CMD prompt and then browse till the IDE folder in the Drive where you are installing {\Program Files\Microsoft SQL Server\90\Tools\Binn\VSShell\Common7\IDE} and tried to manually start Sqlwb.exe /Setup along with a Filemon on the background but it failed with a different value
{Filemon is important here}
0xc0000135

You can download a Filemon from sysinternals Site

5) Then we opened the File mon and saw the following which we collected
=========================================================
304 1:45:44 AM cmd.exe:5716 QUERY INFORMATION D:\Program Files\Microsoft SQL Server\90\Tools\Binn\VSShell\Common7\IDE\SqlWb.exe SUCCESS Attributes: A 306 1:45:44 AM cmd.exe:5716 DIRECTORY D:\Program Files\Microsoft SQL Server\90\Tools\Binn\VSShell\Common7\IDE\ SUCCESS FileBothDirectoryInformation: SqlWb.exe 308 1:45:44 AM cmd.exe:5716 OPEN D:\Program Files\Microsoft SQL Server\90\Tools\Binn\VSShell\Common7\IDE\SqlWb.exe SUCCESS Options: Open Access: 001000A1 309 1:45:44 AM cmd.exe:5716 QUERY INFORMATION D:\Program Files\Microsoft SQL Server\90\Tools\Binn\VSShell\Common7\IDE\SqlWb.exe SUCCESS Attributes: A 310 1:45:44 AM cmd.exe:5716 QUERY INFORMATION D:\Program Files\Microsoft SQL Server\90\Tools\Binn\VSShell\Common7\IDE\SqlWb.exe SUCCESS Length: 819928 311 1:45:44 AM SqlWb.exe:5716 QUERY INFORMATION D:\Program Files\Microsoft SQL Server\90\Tools\Binn\VSShell\Common7\IDE\SqlWb.exe BUFFER OVERFLOW FileNameInformation 312 1:45:44 AM SqlWb.exe:5716 QUERY INFORMATION D:\Program Files\Microsoft SQL Server\90\Tools\Binn\VSShell\Common7\IDE\SqlWb.exe SUCCESS FileNameInformation 313 1:45:44 AM cmd.exe:5716 OPEN D:\Program Files\Microsoft SQL Server\90\Tools\Binn\VSShell\Common7\IDE\SqlWb.exe.Manifest SUCCESS Options: Open Access: 001200A9 314 1:45:44 AM cmd.exe:5716 QUERY INFORMATION D:\Program Files\Microsoft SQL Server\90\Tools\Binn\VSShell\Common7\IDE\SqlWb.exe.Manifest SUCCESS Length: 1076 315 1:45:44 AM cmd.exe:5716 QUERY INFORMATION D:\Program Files\Microsoft SQL Server\90\Tools\Binn\VSShell\Common7\IDE\SqlWb.exe.Manifest SUCCESS Length: 1076 316 1:45:44 AM cmd.exe:5716 OPEN D:\Program Files\Microsoft SQL Server\90\Tools\Binn\VSShell\Common7\IDE\SqlWb.exe.Config SUCCESS Options: Open Access: 001200A9 317 1:45:44 AM cmd.exe:5716 QUERY INFORMATION D:\Program Files\Microsoft SQL Server\90\Tools\Binn\VSShell\Common7\IDE\SqlWb.exe.Config SUCCESS Length: 337 318 1:45:44 AM cmd.exe:5716 QUERY INFORMATION D:\Program Files\Microsoft SQL Server\90\Tools\Binn\VSShell\Common7\IDE\SqlWb.exe.Config SUCCESS Length: 337 322 1:45:44 AM csrss.exe:1260 QUERY INFORMATION D:\Program Files\Microsoft SQL Server\90\Tools\Binn\VSShell\Common7\IDE\SqlWb.exe.Manifest SUCCESS Attributes: A 323 1:45:44 AM csrss.exe:1260 QUERY INFORMATION D:\Program Files\Microsoft SQL Server\90\Tools\Binn\VSShell\Common7\IDE\SqlWb.exe.Config SUCCESS Attributes: A 324 1:45:44 AM csrss.exe:1260 QUERY INFORMATION D:\Program Files\Microsoft SQL Server\90\Tools\Binn\VSShell\Common7\IDE\SqlWb.exe.Manifest SUCCESS Attributes: A 436 1:45:44 AM cmd.exe:5716 CLOSE D:\Program Files\Microsoft SQL Server\90\Tools\Binn\VSShell\Common7\IDE\SqlWb.exe.Manifest SUCCESS 437 1:45:44 AM cmd.exe:5716 CLOSE D:\Program Files\Microsoft SQL Server\90\Tools\Binn\VSShell\Common7\IDE\SqlWb.exe.Config SUCCESS 438 1:45:44 AM cmd.exe:5716 CLOSE D:\Program Files\Microsoft SQL Server\90\Tools\Binn\VSShell\Common7\IDE\SqlWb.exe SUCCESS 439 1:45:44 AM SqlWb.exe:5452 OPEN D:\Program Files\Microsoft SQL Server\90\Tools\Binn\VSShell\Common7\IDE SUCCESS Options: Open Directory Access: 00100020 440 1:45:44 AM SqlWb.exe:5452 QUERY INFORMATION D:\Program Files\Microsoft SQL Server\90\Tools\Binn\VSShell\Common7\IDE\SqlWb.exe.Local\ NOT FOUND Attributes: Error 441 1:45:44 AM SqlWb.exe:5452 QUERY INFORMATION C:\WINDOWS\WinSxS\x86_Microsoft.VC80.ATL_1fc8b3b9a1e18e3b_8.0.50727.762_x-ww_CBB27474 SUCCESS Attributes: D 442 1:45:44 AM SqlWb.exe:5452 OPEN C:\WINDOWS\WinSxS\x86_Microsoft.VC80.ATL_1fc8b3b9a1e18e3b_8.0.50727.762_x-ww_CBB27474 SUCCESS Options: Open Directory Access: 00100020 443 1:45:44 AM SqlWb.exe:5452 OPEN C:\WINDOWS\WinSxS\x86_Microsoft.VC80.ATL_1fc8b3b9a1e18e3b_8.0.50727.762_x-ww_CBB27474\ATL80.DLL NOT FOUND Options: Open Access: 00100021 444 1:45:44 AM SqlWb.exe:5452 OPEN C:\WINDOWS\WinSxS\x86_Microsoft.VC80.ATL_1fc8b3b9a1e18e3b_8.0.50727.762_x-ww_CBB27474\ATL80.DLL NOT FOUND Options: Open Access: 00100020 488 1:45:48 AM SqlWb.exe:5452 CLOSE C:\WINDOWS\WinSxS\x86_Microsoft.VC80.ATL_1fc8b3b9a1e18e3b_8.0.50727.762_x-ww_CBB27474 SUCCESS 489 1:45:48 AM SqlWb.exe:5452 CLOSE D:\Program Files\Microsoft SQL Server\90\Tools\Binn\VSShell\Common7\IDE SUCCESS

Here is the problem
===================
443 1:45:44
AM SqlWb.exe:5452 OPEN C:\WINDOWS\WinSxS\x86_Microsoft.VC80.ATL_1fc8b3b9a1e18e3b_8.0.50727.762_x-ww_CBB27474\ATL80.DLL NOT FOUND Options: Open Access: 00100021 444 1:45:44 AM SqlWb.exe:5452 OPEN C:\WINDOWS\WinSxS\x86_Microsoft.VC80.ATL_1fc8b3b9a1e18e3b_8.0.50727.762_x-ww_CBB27474\ATL80.DLL NOT FOUND

4) The sqlwb needs this dll called ATL80.dll under WinSxS folder, looks like the DLL is not found

5) We Clicked on search and tried to find the DLL at customers end it gave the following location:

C:\WINDOWS\WinSxS\x86_Microsoft.VC80.ATL_1fc8b3b9a1e18e3b_8.0.50727.42_x-ww_6e805841

6)We then checked with the one where its unable to find the DLL:

C:\WINDOWS\WinSxS\x86_Microsoft.VC80.ATL_1fc8b3b9a1e18e3b_8.0.50727.762_x-ww_CBB27474\ATL80.DLL NOT FOUND

Cause
=====
Here is the problem, the DLL when searched by sqlwb.exe is been searched at

C:\WINDOWS\WinSxS\x86_Microsoft.VC80.ATL_1fc8b3b9a1e18e3b_8.0.50727.762_x-ww_CBB27474
And when we got to this folder the ATL80.dll is not present

But the DLL is present at the following place: C:\WINDOWS\WinSxS\x86_Microsoft.VC80.ATL_1fc8b3b9a1e18e3b_8.0.50727.42_x-ww_6e805841
But this is not refrenced by SQlwb.exe and if you closely look the version is also different

Folder where the DLL is currently present is:
===================================
Folder:C:\WINDOWS\WinSxS\x86_Microsoft.VC80.ATL_1fc8b3b9a1e18e3b_8.0.50727.42_x-ww_6e805841 and DLL version: 8.0.50727.42 DLL name ATL80.DLL

Folder looked when SQLwb runs is:
============================
Folder: C:\WINDOWS\WinSxS\x86_Microsoft.VC80.ATL_1fc8b3b9a1e18e3b_8.0.50727.762_x-ww_CBB27474: and Dll version: 8.0.50727.762 DLL name ATL80.DLL

Checked in the Folder the folder is empty

We then went into another box and searched for the same version of DLL for ATL80.dll that is 8.0.50727.762

We got it from one different working box and we replaced the ATL80.dll from there to this

Problematic box in the following folder:
C:\WINDOWS\WinSxS\x86_Microsoft.VC80.ATL_1fc8b3b9a1e18e3b_8.0.50727.762_x-ww_CBB27474

Things started to work after that..........

SSL Security error [DBNETLIB]ConnectionOpen (SECDoClientHandshake())

TechNet Archive — Wed, 07 Jan 2009 12:05:00 GMT

SSL Security error [DBNETLIB]ConnectionOpen (SECDoClientHandshake())

This particular resolution is one of its own kind their could have been other possibilites for his error message to raise, generally it comes if you have Expired Certificates or invalid Certificates on the Server for the user account or the computer account, delete the unwanted Certificates on the server and then try to start SQL or Connect should work

Other times this message comes if you had encryption enabled for the Server sometime but no more now, but then internally we are still finding the certificate somehow, though you anyways dont need the SSL certificate, so go to the following Registry and check for the Certificate value it should be EMPTY, but if it has ThumbPrint value of the Certifcate it is a problem, go ahead and make the change for Certificate value set to 0

HKLM\SOFTWARE\Microsoft\MSSQLServer\MSSQLServer\SuperSocketNetLib REG_SZ Certificate=0

Coming back to this unique problem:

Problem Description:
=================
Trying to enable SSL encryption for sql server connections on server
Went through the steps detailed in article 276553 (http://support.microsoft.com/?id=276553).

From one client we were unable to connect to the SQL Server 2000 using encrypted connections {forced encryption from the Client configuration, this client box where its working is a Windows 2003 SP1 box}. From our own desktop workstation {Windows XP sp2}, along with that of one of the other Clients box {Windows 2000} they are unable to connect to the SQL Server through encrypted connections.

Consistently receive the following error:
[DBNETLIB]SSL Security error[DBNETLIB]ConnectionOpen (SECDoClientHandshake()).

We have checked and re-checked and re-re-checked that his local workstation trusts the same root certificate authority (plus all intermediary issuing authorities) as does the SQL Server

The certificate chains are identical on both machines.

We Enabled odbc tracing and attempted to login again from his local box. The log of that attempt is enclosed. It contains the following information:

osql -Sact-dd01 2764-1a88 EXIT SQLDriverConnectW with return code -1 (SQL_ERROR) HDBC 009A1830 HWND 00000000 WCHAR * 0x74329A38 [ -3] "******\ 0" SWORD -3 WCHAR * 0x74329A38 SWORD 2 SWORD * 0x00000000 UWORD 0
DIAG [08001] [Microsoft][ODBC SQL Server Driver][DBNETLIB]SSL Security error (18)
DIAG [01000] [Microsoft][ODBC SQL Server Driver][DBNETLIB]ConnectionOpen (SECDoClientHandshake()). (271)
Operating System:Windows 2003 : where the Encrypted Client connections are working
Operating System: Windows XP Sp2 and Windows 2000 SP4 where the Client connections are not working using Encryption, though if the encryption is not enabled the connections will flow fine

Cause
=====
The cause is a DBNETLIB.DLL {Remember this is not a COM DLL}, the version compatibility of this DLL on the XP and Windows 2000 is the possible culprit, i dont think it is a BUG

Resolution
========

1) Check the for the following DLL's version on the Windows 2003 SP1 or SP2 Box

C:\WINDOWS\system32\DBNETLIB.DLL
Version: 2000.86.1830.0 {Windows 2003 SP1}

2) Now Check the Version for the same DLL on the Windows XP Sp2 and Windows 2000 Sp4 box

In My case the Windows XP SP2 had the following version of the DBNETLIB.DLL
Version: 2000.85.1117.0

3)

The Windows 2000 SP4 box had the follwoing DLL version in my case
Version: 2000.85.1064.0

4) So what i did was, i copied the DLL Version: 2000.86.1830.0 from the Windows 2003 SP1 box to the Windows Xp SP2 box and also to the Windows 2000 SP4 Box

Went to the following location on the Windows XP Sp2 box:

C:\windows\system32 and renamed the existing DBNETLIB.DLL to DBNETLIB.DLL.OLD
After that pasted the copied DLL version 2000.86.1830.0 on the XP Sp2 box in the following location c:\windows\system32\DBNETLIB.DLL {2000.86.1830.0} after that did a refresh and saw that the Version got back to the older version that is 2000.85.1117.0. Made a check in the DLLCACHE {c:\windows\system32\DLLCACHE} and saw that the DBNETLIB.DLL was present there and was having the Version 2000.85.1117.0 {so whenever the connection was made, this DLL from the cache was picked}, hence First paste the DBNETLIB.DLL {with version 2000.86.1830.0} in the DLLCACHE and then replace the actual DLL inside the c:\windows\system32.

Do a refresh and see if the DLL version is Showing as 2000.86.1830.0 on the XP Sp2 Box.

After this again try to connect to the SQL Server from this Client box {Make sure that Force Encryption is Checked in the Client Configuration}

The above resolved the issue with the SSL encryption errors, and the Secured channel is established

5) Repeat the above Steps for a Windows 2000 SP4 box, and this should help in getting past through the problem

NOTE: Never try to Register this DLL, also it wont let you as well, as it is not a COM DLL, also replacing this DLL will never break anything as it is a System DLL and the version is upgraded through MDAC