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
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
- 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
When this error occurs, a corresponding error message that is similar to
the following may appear in the Application Center Administrator list of
Event Type: Error
Event Source: Application Center
Event Category: Replication
Event ID: 5049
Time: 5:10:51 PM
StatusMessage: Unspecified error
TimeGenerated: 10/23/2003 9:10:51
DisplayName: Replication Session DriverEvents IHave EnumObjFailed
10/23/2003 5:10:51 PM BIZTALKSERVER 5049
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
Login failed for user '(null)'. Reason: Not associated with a trusted SQL Server connection'
Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON'
The Application Center service does not have the required
credentials to access the BizTalk Messaging Management database
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:
- Click Start, click Programs, and then click Microsoft SQL Server and Enterprise Manager.
- 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
- Right-click Logins, and then click New Login.
- On the General tab, type the computer name of the Application Server computer in
the following format:
Domain Name\Computer Name$
- On the Server Roles tab, click to select System Administrators in the Server Role list.
- On the Database Access tab, click to select InterchangeBTM.
NOTE: The account name that you specify will appear as a user for this
- Under Permit in Database Role, select the
db_owner role for the InterchangeBTM database.
- Click OK.
- 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:
- Install the Setspn utility. For more information, visit the
following Microsoft Web site:
- 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>
- 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
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:
Collapse this imageExpand this image
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.
How to Obtain Microsoft Support Files from Online Services
- 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:
behavior is by design.
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.
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
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
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:
Basic Overview of Kerberos User Authentication Protocol in Windows 2000
Answers to Frequently Asked Kerberos Questions
INFO: Accessing SQL Server with Integrated Security from ASP
Kerberos Authentication Fails after Upgrading from IIS 4.0 to IIS 5.0
HOW TO: Enable Kerberos Event Logging
FIX: Analysis Services 2000 Does Not Support Security Account Delegation
Authentication May Fail with "401.3" Error If Web Site's "Host Header" Differs from Server's NetBIOS Name
Unable to Negotiate Kerberos Authentication After Upgrading to Internet Explorer 6
HOW TO: Troubleshoot Kerberos-Related Issues in IIS