PRB: Application Center Displays the "Class Not Registered" Error When You Are Adding BizTalk Server Resources (320827)


The information in this article applies to:

  • Microsoft BizTalk Server 2002
This article was previously published under Q320827

SYMPTOMS

You may experience one or both of the following problems:
  • When you create a new application in Microsoft Application Center, if you click BizTalk resources, and then click Add, a list of high-level objects, such as BiztalkCustomCounters, BiztalkPorts, BiztalkPortGroups, and BiztalkReceiveFunctions, is displayed. If you then double-click a particular object to enumerate it, you receive the following error message:
    An Error occurred while trying to load the resource list

    Could not connect to the server.

    Verify that the server has a full installation of Application Center on it. You cannot connect to a computer with only the Administration Client installed on it.

    Class not Registered (0X80040154)
  • An Application Center deployment of an application that is made up of Microsoft BizTalk Server objects cannot synchronize with the destination computer that is running BizTalk Server and you receive an error message that is similar to the following in the application log of the source server:
    Event Type:	Error
Event Source:	Application Center
Event Category:	Replication
Event ID:	5049
Date:		10/23/2003
Time:		5:10:51 PM
User:		N/A
Computer:	BIZTALKSERVER
Description:
__CLASS: MicrosoftAC_Replication_Session_DriverEvents_IHave_EnumObjFailed_Event__
SERVER: BIZTALKSERVER
ServerGUID: {8C069646-9A0F-41FA-B381-3C16F68554E9}
DriverID: 
BTSEventId: 5049
GUID: {F89F820A-A9D0-4A1B-8B7E-83DCEB2FAC86}
Path: BizTalkPorts
ReplicationID: Cluster1Replication
JobID: BIZTALKSERVERX1064351358X134909X11dc068
Status: 0x80004005
StatusMessage: Unspecified error
TimeGenerated: 10/23/2003 9:10:51 
PMType: 1
DisplayName: Replication Session DriverEvents IHave EnumObjFailed
    When this error occurs, a corresponding error message that is similar to the following may appear in the Application Center Administrator list of Events:
    10/23/2003   5:10:51 PM    BIZTALKSERVER	5049 
 
Application Center 
Source:  Replication  Session 
The objects store located at BizTalkPorts could be opened but not enumerated 
during session Cluster1 and job BIZTALKSERVERX1064351358X134909X11dc068. 
Status is 0x80004005 Unspecified error
When these errors occur, a SQL Profiler trace run against the InterchangeBTM database on the SQL Server that houses the destination BizTalk Server databases may reveal one of the following authentication failures:
Login failed for user '(null)'. Reason: Not associated with a trusted SQL Server connection'
-or-
Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON'

CAUSE

The Application Center service does not have the required credentials to access the BizTalk Messaging Management database (InterchangeBTM).

RESOLUTION

Give the LocalSystem account for the computer on which Application Center is installed appropriate rights to the Microsoft BizTalk Server Messaging Management database on Microsoft SQL Server. You have to do this because the Application Center service must run under the context of the LocalSystem account on the computer on which it is installed.

Note If the SQL Server computer that hosts the BizTalk Server Messaging Management database is remote to the BizTalk/Application Center Server, follow these steps:
  1. Click Start, click Programs, and then click Microsoft SQL Server and Enterprise Manager.
  2. Navigate to Security: Expand Microsoft SQL Servers, expand SQL Server Group, expand the server to which you want to add a SQL Server logon account, and then double-click Security.
  3. Right-click Logins, and then click New Login.
  4. On the General tab, type the computer name of the Application Server computer in the following format:

    Domain Name\Computer Name$

  5. On the Server Roles tab, click to select System Administrators in the Server Role list.
  6. On the Database Access tab, click to select InterchangeBTM.

    NOTE: The account name that you specify will appear as a user for this database.
  7. Under Permit in Database Role, select the db_owner role for the InterchangeBTM database.
  8. Click OK.
  9. Repeat steps 3 through 8 on the other computer that is running BizTalk Server and Application Center and that is participating in the replication of the application that is made up of BizTalk Server objects.
If this does not resolve the issue, verify the account name in your SQL Profiler that Application Center uses. If it is NTLM/Anonymous or '(null)', do the following:
  1. Install the Setspn utility. For more information, visit the following Microsoft Web site:

    http://www.microsoft.com/downloads/details.aspx?FamilyID=4e3a58be-29f6-49f6-85be-e866af8e7a88&displaylang=en

  2. Log on to a domain controller in the domain or log on to a member server in the domain. Log on as a domain administrator, and then run the following command:

    setspn -A MSSQLSvc/<servername>.<FQDN> <SQL_service_account>

  3. Verify that each computer that is running BizTalk Server has a Kerberos ticket from the computer that is running SQL Server that houses its databases. The Kerberos ticket must be in the following format:

    MSSQLSvc/computername.fqdn:1433

    You can use the Kerbtray tool to verify the Kerberos ticket. The following file is available for download from the Microsoft Download Center:
    DownloadDownload the Kerbtray.exe package now. For additional information about how to download Microsoft Support files, click the following article number to view the article in the Microsoft Knowledge Base:

    119591 How to Obtain Microsoft Support Files from Online Services

    Microsoft scanned this file for viruses. Microsoft used the most current virus-detection software that was available on the date that the file was posted. The file is stored on security-enhanced servers that help to prevent any unauthorized changes to the file.
  4. If the computers that are running BizTalk Server do not have a Kerberos ticket from the computer that is running SQL Server that houses their databases, you must follow the steps that appear in the "Security Account Delegation" topic that appears in SQL Books Online for Microsoft SQL Server 2000. You can also view this topic on MSDN, the Microsoft Developer Network. To view this topic, visit the following MSDN Web site:

    http://msdn.microsoft.com/library/default.asp?url=/library/en-us/adminsql/ad_security_2gmm.asp

STATUS

This behavior is by design.

MORE INFORMATION

Note Application Center deployment of BizTalk Server objects is not supported when either of the BizTalk Server Messaging Management databases is housed on a SQL Server cluster. This configuration can create specific permissions issues. The BizTalk Server product team has not tested this configuration.

If SQL Server is installed on the same server as BizTalk Server and Application Center server, you may not have to give the computer account rights to the InterchangeBTM database because the local computer account should already have System Administrator permissions.

Technical Explanation

Kerberos uses an identifier named Service Principle Name (SPN). Consider an SPN as a domain or forest unique identifier of some instance in a network server resource. You can have an SPN for a Web service, for an SQL service, or for an SMTP service.

When the SQL Server driver on a client uses integrated security to connect to SQL Server, the driver code on the client tries to resolve the fully qualified DNS of the computer running SQL Server by using the WinSock networking APIs. To perform this operation, the driver code calls the gethostbyname and gethostbyaddr WinSock APIs. Regardless of whether an IP address or host name is passed as the name of the computer that is running SQL Server, the SQL Server driver tries to resolve the fully qualified DNS of the computer if it is using integrated security.

When the SQL Server driver on the client resolves the fully qualified DNS of the SQL Server, the corresponding DNS is used to form the SPN for this computer. Therefore, any issues related to how the IP address or host name is resolved to the fully qualified DNS by WinSock may cause the SQL Server driver to create an invalid SPN for the computer that is running SQL Server.

When the SQL Server driver forms an SPN that is not valid, authentication may still work because the SSPI interface tries to look up the SPN in Active Directory and does not find the SPN. If the SPN is not found, Kerberos authentication is not performed. At that point, SSPI interface switches to NTLM authentication mode. NTLM authentication does not resolve the SPN.

The key factor that makes Kerberos authentication successful is the valid DNS functionality on the network. Typically, if you run the SQL Server service under the LocalSystem account, the SPN is registered and Kerberos interacts successfully with the computer that is running SQL Server. However, if you run the SQL Server service under a domain account or a local account, typically, the SPN may not be created.

When the SPN creation is not successful, no SPN is set up for the computer that is running SQL Server. If you test by using a domain administrator account as the SQL Server service account, the SPN is successfully created because the domain administrator-level credentials that you must have to create an SPN are present. Because you might not use a domain administrator account to run the SQL Server service (to prevent a security risk), the computer that is running SQL Server cannot create its own SPN. Therefore, you must manually create an SPN for your SQL Server when you use the Kerberos protocol.

REFERENCES

For additional information about Kerberos, click the following article numbers to view the articles in the Microsoft Knowledge Base:

217098 Basic Overview of Kerberos User Authentication Protocol in Windows 2000

266080 Answers to Frequently Asked Kerberos Questions

176377 INFO: Accessing SQL Server with Integrated Security from ASP

176379 HOWTO: IIS and SQL Server on Separate Machines with Trusted Connection

248350 Kerberos Authentication Fails after Upgrading from IIS 4.0 to IIS 5.0

262177 HOW TO: Enable Kerberos Event Logging

279490 FIX: Analysis Services 2000 Does Not Support Security Account Delegation

294382 Authentication May Fail with "401.3" Error If Web Site's "Host Header" Differs from Server's NetBIOS Name

299838 Unable to Negotiate Kerberos Authentication After Upgrading to Internet Explorer 6

326985 HOW TO: Troubleshoot Kerberos-Related Issues in IIS

Modification Type:MajorLast Reviewed:7/31/2006
Keywords:kbdownload kbprb KB320827
©2004 Microsoft Corporation. All rights reserved.