Was this page helpful?
Your feedback about this content is important. Let us know what you think.
Additional feedback?
1500 characters remaining
Export (0) Print
Expand All

Troubleshooting BizTalk Server Administration

 

This section provides a centralized location for information about common problems encountered while using the BizTalk Server Administration console.

In addition to the following Known Issues, Common Issues and Resolutions With the BizTalk Server Administration Console provides additional information.

Rebooting your computer with DTC not set to automatic start-up may prevent the BizTalk Server service from starting.

This is because the ENTSSO service can take more time to start than is allowed by the BizTalk Server service timeout duration.

To resolve this issue, set DTC to automatic.

The following error may occur:

Transaction (Process ID 95) was deadlocked on lock resources with another process and has been chosen as the deadlock victim. Rerun the transaction.

This is a very rare situation in which administrative operations performed by one user result in another user being locked out of database administration.

The problem should remedy itself shortly. Try the operation again in a few minutes.

Users may be locked out of the SQL database. A number of different error messages may be returned.

In some cases one user writing to the database will effectively lock another user out of the database.

The problem should remedy itself shortly. Try the operation again in a few minutes.

Attempts to terminate multiple service instances from the BizTalk Server Administration console fail and an error similar to the following is displayed:

SQL Server blocked access to procedure 'sys.xp_sqlagent_enum_jobs' of component 'Agent XPs' because this component is turned off as part of the security configuration for this server.

System_CAPS_noteNote

This problem occurs in a multiple messagebox environment.

This problem can occur in a multiple messagebox environment if the SQL agent job 'Operations_OperateOnInstances_OnMaster_<dbName>' is not running on the secondary messagebox databases. This job must be running in order to propagate information from the secondary messagebox databases to the primary messagebox database. This job will fail to run if it is not enabled or if a logon failure occurs.

If you are using the BizTalk Administration console to perform operations on multiple service instances simultaneously and your BizTalk Server environment is configured with multiple messagebox databases, verify that the SQL Server Agent job named 'Operations_OperateOnInstances_OnMaster_<dbName>' is enabled on all secondary (non-master) messagebox databases. Additionally, the SQL Server Agent service on the SQL Server computer that hosts the secondary messagebox databases must run as an account that is included in the BTS_SQLAGENT_USER database role of the secondary messagebox database.

System_CAPS_noteNote

<dbname> is a placeholder for the actual name of the BizTalk messagebox database.

Follow these steps to add the SQL Server Agent service account to the BTS_SQLAGENT_USER database role of the secondary messagebox database

On SQL Server 2008

  1. Click Start, point to All Programs, point to Microsoft SQL Server 2008, and then click SQL Server Management Studio.

  2. When prompted choose the Server type of Database Engine and enter or select the Server name that hosts the secondary messagebox database.

  3. Click to expand Databases, click to expand the secondary messagebox database, click to expand Security, click to expand Roles, click to expand Database Roles, and then double-click the BTS_SQLAGENT_USER database role.

  4. Click the Add button.

  5. Click Browse, select a group that the SQL Server Agent service account is a member of, and then click OK.

System_CAPS_noteNote

If the SQL Server Agent service account is not a member of the specified group then you will need to add it to the group.

If multiple instances of the BizTalk Administration console are simultaneously connected to the same BizTalk Server group, changes made in one instance of the BizTalk Administration console are not automatically reflected in the other instance(s) of the BizTalk Administration console. This can cause concurrency violation errors when attempting to modify an artifact displayed in an instance of the BizTalk Administration console if the state of the artifact does not match the actual state of the artifact as stored in the BizTalk management database.

Each instance of the BizTalk Administration console maintains its own cache of the BizTalk group configuration and only reflects changes in the cache. The cache is only updated when the BizTalk Administration console view is refreshed.

If you receive concurrency violation errors in the BizTalk Administration console, update the cache for the instance of the BizTalk Administration console by clicking the Refresh button on the BizTalk Administration console toolbar or by pressing the F5 key.

When you attempt to stop an Orchestration in the BizTalk Administration console, an error message similar to the following is generated:

Failed to execute action 'Stop'.
------------------------------
ADDITIONAL INFORMATION:
A transport-level error has occurred when sending the request to the server. (provider: TCP Provider, error: 0 - An existing connection was forcibly closed by the remote host.) (Microsoft SQL Server, Error: 10054)

This problem may occur if the following conditions are true:

  • The BizTalk Administration console is open.

  • The BizTalk management database is installed on a clustered instance of SQL Server.

  • The clustered instance of SQL Server is failed over.

  • After the failover is complete, you attempt to stop a running instance of an orchestration using the BizTalk Administration console.

The BizTalk Administration console maintains a connection to the BizTalk Server management database. When the connection to BizTalk Server management database has been broken during the failover, some management tasks may return a "Failed to connect" or "Failed to execute" error until the BizTalk Administration console has been closed and reopened.

Close and reopen the BizTalk Administration console. When the BizTalk Administration console is reopened it creates a new connection to the specified BizTalk Server management database.

If, when reinstalling BizTalk Server, you use a Windows group name that was previously deleted, the Windows group will not have access to the BizTalk Server databases.

Deleting a Windows group and then creating a Windows group with the same name produces a new Security Identifier (SID) for the Windows group. However the old SID is still cached in SQL Server, so the new Windows group cannot log on to SQL Server.

When you delete the Windows group, you must also remove the SQL Server login for the Windows group.

A BizTalk Administrator (member of the BizTalk Administrators Windows group) may not be able to open the BizTalk Server Administration console if that user is not a member of the Windows Administrators group on the local computer.

This problem can occur if you have reinstalled or reconfigured BizTalk Server. This is because SQL Server used cached security IDs.

Temporarily add the BizTalk Administrator to the local Windows Administrators group on the local computer. After successfully opening the BizTalk Server Administration console, remove the BizTalk Administrator from the local Windows Administrators group on the local computer.

When you create a BizTalk Host instance on a remote computer, you may see the following error when you start the BizTalk Host instance: "Failed to start due to logon failure."

This error can occur if you entered invalid credentials for the service account under which the BizTalk Host instance is running, or the service account does not have logon as service rights.

Assign logon as a service right to the service account in the remote computer before you start the BizTalk Host instance. This is done automatically on a local computer, but must be done manually on a remote computer.

In the BizTalk Server Administration Console, creating a BizTalk Host instance on an X64 computer with the 32-bit only option selected (default) may fail.

In BizTalk Server Configuration Manager, when configuring the BizTalk Server Runtime on an X64 computer, creating an in-process or isolated host instance with the 32-bit only option selected can cause the service to fail to start.

Unknown

This issue is intermittent. Attempt to create or configure the host again or deselect the 32-bit only option.

If you are not an administrator on the local computer, when you delete an in-process or isolated host, an access denied error message appears. You can forcibly delete the host. However, deleting the host in this manner does not clear all of the related registry information.

Deletion of the registry information related to a host instance requires Administrator privileges.

Log on as a local Administrator account before deleting the host so that the related registry information is also removed.

You may not be able to delete a MessageBox database. If the deletion fails, one of the following issues may be responsible:

  • The cache refresh interval has not expired.

  • The MessageBox database contains incomplete instances.

If the cache refresh interval has not yet expired, the following error message appears when the deletion fails: "MessageBox cannot be deleted since there could be remaining work in the MessageBox. Please ensure that there are no more incomplete instances in the MessageBox, and try again."

The cache refresh interval must expire between the time you disable new message publication in the MessageBox database and the time you delete the database. By default, the cache refresh interval is 60 seconds.

To delete a MessageBox database, you must first disable new message publication for that MessageBox database, and then wait until the cache refresh interval expires, before you delete the MessageBox database.

If the MessageBox database contains incomplete service instances, the following error message appears: "The MessageBox cannot be deleted because it may still contain incomplete instances. Ensure that there are no incomplete instances in the MessageBox, and try again".

You can view incomplete service instances in the MessageBox database using the Group Hub page in the BizTalk Server Administration Console. For information about viewing the status of service instances in the Group Hub page, see How to Search for Tracked Service Instances.

Community Additions

ADD
Show:
© 2015 Microsoft