Article ID: 832109
Article Last Modified on 11/7/2007
APPLIES TO
- Microsoft Systems Management Server 2003
SYMPTOMS
After you install and configure a new management point for Microsoft Systems Management Server (SMS) 2003, you may experience one or more of the following issues:
- Computers are discovered and appear in the SMS Administrator console as advanced clients, but the SMS client software is not installed on the client computers.
- Computers are discovered and appear in the SMS Administrator console as advanced clients, but the standard SMS client software is installed on the computer that is discovered.
- Existing clients do not report a status for advertisements.
- The following message is logged in the CAS.log on the SMS Advanced Client computer and in the SQLERROR log on SQL server:
- The IIS log on the management point may contain Error 401.
The following entries may appear on the management point in the MP_GetAuth.log file. Depending on whether the SMS client is also installed, this log file is located either in the \%windir%\system32\CCM\Logs\ folder or in the \SMS_CCM\Logs\ folder. (%windir% is the folder where the operating system is installed.)
<![LOG[CMPDBConnection::Init(): IDBInitialize::Initialize() failed with 0x80004005]LOG]!>
<![LOG[Raising event: [SMS_CodePage(437), SMS_LocaleID(1033)] instance of
MpEvent_ConnectDatabaseFailed {
ClientID = "GUID:F4AB9DD6-362A-44B4-BAFA-6797AD71C79F";
DatabaseName = "SMSDBname";
DateTime = "20030919053031.203000+000";
ErrorCode = "0x80004005";
MachineName = "MPcomputername";
ProcessID = 5124;
ServerName = "SMSservername";
SiteCode = "sitecode";
ThreadID = 3512;
Win32ErrorCode = 0;
};
]LOG]><time="00:30:31.219+000" date="09-19-2003" component="MP_GetAuth_ISAPI" context="Auth"
type="1" thread="3512" file="event.cpp:522">
CMPDBConnection::Init(): IDBInitialize::Initialize() failed with 0x80040e4d $$<MP_GetAuth_ISAPI><Wed Feb 4 17:19:29.240 2004 Eastern Standard Time><thread=2664 (0xA68)>
CAUSE
The management point may be prevented from connecting to the server that is running Microsoft SQL Server. These issues may occur for any one of the following reasons:
- The management point does not have correct permissions on the SQL server.
- Problems exist with SQL Service Principal Name (SPN) registration.
- Problems exist with Kerberos or the Domain Name System (DNS) protocol.
WORKAROUND
To work around this problem, switch from a TCP connection to a Named Pipes connection between the management point and the SQL server. This can also be used to test whether the issue is with Kerberos authentication, which TCP uses.
Named Pipes uses NTLM authentication. If switching from TCP to Named Pipes does not resolve the issue, run a Network Monitor trace to investigate possible network connectivity issues. If enabling Named Pipes on the management point resolves the issue, it indicates that Kerberos authentication is failing and the troubleshooting steps in this article will be helpful in diagnosing the cause.
To enable Named Pipes, do the following on the management point server. Click Start, click Run, type cliconfg, and then click OK. This starts the Client Network Utility. Add the SQL server NetBIOS name on the Alias tab with Named Pipes selected. This is the default setting.
On the SQL server, run the Server Network Utility and make sure Named Pipes is at the top of the protocol stack. The management point queries SQL every 10 minutes. A log entry will appear that indicates the number of management points in the site. This indicates a successful connection.
MORE INFORMATION
To troubleshoot these symptoms, follow the steps in the order in which they are presented.
Verify permissions
To start troubleshooting these symptoms, verify that the management point has the correct permissions to connect to the SQL database. To do this, follow these steps:
- At the management point server, click Start, click Run, type cmd, and then click OK. If your SMS site is running under the Standard security mode, go to step 4. If your SMS site is running in the Advanced security mode, go to step 2.
- If your SMS site is running Advanced security, start a new Command Prompt window that is running under the local system account. To do this, type the following at a command prompt, and then press ENTER:
AT
FutureTime/interactive cmdAt the time that you specify, a new Command Prompt window opens that is running under Svchost.exe.
Note
FutureTimecan be any time that is later than the current time, in 24-hour form. - At a command prompt, type the following, and then press ENTER:
osql -S
SQLServer-dSMSdbname-ENote
SQLServeris the name of the server that is running SQL Server, andSMSdbnameis the name of the SQL database for your SMS site.
If this command succeeds, your management point has the correct permissions to the SQL database. The command is successful if a 1> prompt is returned. Type exit, and then press ENTER to return to the command prompt. If you receive the following error message, go to step 4: - If you receive the "Login failed" error message that is described in step 3, repeat the command, but use the Fully Qualified Domain Name (FQDN). For example, type:
If the command does not succeed, view the DNS settings for the domain where the management point computer is located.
osql -S
SQLServer.europe.corp.microsoft.com-dSMSdbname-E - If the command still fails check to see whether the MSSQLServer Service is using a user account to log on with, change the service to use the Local System account on the Log On tab in the service properties and run the commands again. If you must run the service by using a user account, make sure that the user account is added to the Domain Administrator group. You will also have to follow the steps in the following article in the Microsoft Knowledge Base:
829868 Systems Management Server 2003 Advanced Security site with Remote SQL does not connect to SQL Server
Additional troubleshooting
The appropriate Service Principal Name (SPN) attributes may not be generated for the account that started the SQL services. To resolve this issue, you must manually create the fully qualified domain name (FQDN) and NetBIOS SPN entries. To do this, you can use the SetSPN utility from the Windows 2000 Server Resource Kit. To download the SetSPN utility, visit the following Microsoft Web site:
You must run the SetSPN utility on a computer that resides in the SQL Server's domain. You must use Domain Administrator credentials. Determine if the SQL services run as a domain account or as the local computer account. To use the SetSPN utility to manually create the appropriate SPNs, follow these steps:
When the SQL service is started with a user account- To create the FQDN SPN at a Command Prompt window, type the following command:
setspn -A MSSQLSvc/
SqlHostname.mydomain.com:1433SqlServiceAccount - To create the NetBIOS SPN at the command window, type the following command:
setspn -A MSSQLSvc/SqlHostname:1433 SqlServiceAccount
When the SQL service is started under the Local System account
If SQL Server runs under the local system account, you do not have to manually configure an SPN for SQL Server. The SPN is created automatically when SQL Server starts and is removed when the SQL service is stopped. If SQL Server runs under a domain user account, you must manually configure an SPN.SPN removal
A duplicate SPN for the computer that is running SQL Server may cause connectivity problems. The following procedure will remove any existing SPNs from SQL Server and add a new SPN:
- Stop the MSSQL service.
Run the SETSPN -L
computer namecommand to list all SPNs. The output typically resembles the following:MSSQLSvc/MySQLServer dasaccount1 MSSQLSvc/MySQLServer:1433 MSSQLSvc/MySQLServer.MyDomain.com dasaccount1 MSSQLSvc/MySQLServer.MyDomain.com:1433
For more information, click the following article number to view the article in the Microsoft Knowledge Base:
319723 How to use Kerberos authentication in SQL Server
If the MSSQL service runs under the Local System account, the SPN is removed when the MSSQL service is stopped. Therefore, if an SPN is listed in the output of the SETSPN -L command, it is a duplicate SPN. If the MSSQL service runs under a domain user account, the SPN is still listed when you run the SETSPN -L command. Therefore, you cannot determine whether the SPN is a duplicate. In both cases, to make sure that the SPN is not a duplicate, remove and replace the SPN as described in steps 1c through 1i.- If any entries that contain MSSQLSvc are listed, use the SETSPN -D command to remove those entries. For example, type the following:
SETSPN –D MSSQLSvc/MySQLServer
DAS accountSETSPN -D MSSQLSvc/MySQLServer.MyDomain.com <DAS account> - Run the SETSPN -L
computer namecommand again to make sure that no listings for MSSQLSvc appear. - If the MSSQL service runs under the Local System account, make sure that the SQL Server startup account is the Local System account. You can configure this setting on the Security tab in the Properties dialog box of the server in SQL Server Enterprise Manager.
- If the MSSQL service runs under a domain user account, register the SPN by using the SETSPN -A command as mentioned earlier.
- Restart the MSSQL service.
- After the replication updates the servicePrincipalName attribute on any domain accounts, verify that the SPNs are registered correctly. To do this, run the following command:
SETSPN -L
computer name - If the SPNs are registered correctly, test the SMS connection by using the methods in the "Verify permissions" section.
- To create the FQDN SPN at a Command Prompt window, type the following command:
- On each primary site, make sure that the SMS_SitetoSQLConnection security group contains the computer accounts or SMS service accounts for all the child servers that report to the primary site. Typically, these accounts are added to the SMS_SitetoSQLConnection security group when a site is installed. If the Setup program cannot add the account, the following site status message is logged in the SMS Administrator console:
- The Kerberos ticket cache may have to be reset. Use the Kerbtray tool from the Windows 2000 Server Resource Kit to clear the existing Kerberos ticket cache. To download the Kerbtray tool, visit the following Microsoft Web site:
For more information about how to use the Kerbtray tool, click the following article number to view the article in the Microsoft Knowledge Base:
232179 Kerberos administration in Windows 2000
- Make sure that the DNS server for the domain is listed first in the TCP/IP properties of the management point server.
- The FQDN for the target domain must be listed at the top of the suffix search list on the management point server. To change the suffix search list, follow these steps:
- Click Start, click Run, type ncpa.cpl, and then click OK.
- Right-click the connection that you want to change, and then click Properties.
- In the Connection Name Properties dialog box, select Internet Protocol (TCP/IP) under This connection uses the following items, and then click Properties.
- On the General tab, click Advanced, and then click the DNS tab.
- Click Append these DNS suffixes (in order), click the target domain, and then move the target domain to the top of the list by clicking the scroll arrow.
- Click OK two times, and then click Close.
REFERENCES
For more information about running in SMS Advanced security with a remote SQL server, click the following article number to view the article in the Microsoft Knowledge Base:
829868 Systems Management Server 2003 Advanced Security site with Remote SQL does not connect to SQL Server
For more information about retrieving SPNs from Active Directory, click the following article number to view the article in the Microsoft Knowledge Base:
298718 How to retrieve SPNs from the directory
For more information about Kerberos, click the following article numbers to view the articles in the Microsoft Knowledge Base:
266080 Answers to frequently asked Kerberos questions
326985 How to troubleshoot Kerberos-related issues in IIS
Additional query words: "Waiting for content" "No Status" legacy
Keywords: kbsoftwaredist kbclient kbsecurity kbinfo KB832109
