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

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: -or-

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

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:
   
   Download 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:

This behavior is by design.

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.

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