Knowledge Base

Event 8197 is repeatedly logged in the Application log on a server that is running Exchange Server 2003 or Exchange 2000 Server

Article ID: 918006

Article Last Modified on 10/25/2007

APPLIES TO

Microsoft Exchange Server 2003 Enterprise Edition
Microsoft Exchange Server 2003 Standard Edition
Microsoft Exchange 2000 Server Standard Edition
Microsoft Exchange 2000 Enterprise Server

SUMMARY

Event 8197 may be logged in the Application log every 25 minutes on a server that is running Microsoft Exchange Server 2003 or Microsoft Exchange 2000 Server.

This issue occurs when the Exchange Server background task that polls the free/busy system folder is not able to bind to a global catalog server. This free/busy polling task uses the Microsoft Windows referral mechanism to locate a global catalog server instead of using the Exchange Server DSAccess component. Therefore, Event 8197 may be repeatedly logged even if Exchange Server appears to be running correctly.

To resolve this issue, use one or more of the following methods:

Method 1: Restart the Exchange Server services
Method 2: Verify the LAN Manager Authentication settings
Method 3: Troubleshoot connectivity to the global catalog server to which the free/busy polling task tries to bind
Method 4: Verify whether Microsoft Outlook is installed on the Exchange server

This article contains step-by-step instructions for these methods. Additionally, this article contains more information about why Event 8197 may be repeatedly logged in the Application log.

Important This article contains information about how to modify the registry. Make sure to back up the registry before you modify it. Make sure that you know how to restore the registry if a problem occurs. For more information about how to back up, restore, and modify the registry, click the following article number to view the article in the Microsoft Knowledge Base:

256986 Description of the Microsoft Windows registry

SYMPTOMS

On a computer that is running Exchange Server 2003 or Exchange 2000 Server, the following event may be logged in the Application log every 25 minutes: Event Type: Error
Event Source: MSExchangeFBPublish
Event Category: General
Event ID: 8197
User: N/A
Computer: ServerName
Description: Error initializing session for virtual machine computerName. The error number is 0x80040111. Make sure Microsoft Exchange Store is running.

Additionally, when you experience this issue, other events may also be repeatedly logged in the Application log.

CAUSE

The most common reason that Event 8197 is logged is that the free/busy polling task is not able to bind to a global catalog server.

Most Exchange Server tasks use the DSAccess component to locate global catalog servers. However, the free/busy polling task relies on the Windows referral mechanism to locate a global catalog server.

The method that the Windows referral mechanism uses to select a global catalog server differs slightly from the method that is used by the DSAccess component.Therefore, the free/busy polling task may not use the same global catalog server as most other Exchange Server tasks. Therefore, the free/busy polling task may be unsuccessful even when other tasks on the Exchange server run correctly.

The "Description" line in the event message indicates that the error number is 0x80040111. This error number corresponds to Error -2147221231. Error -2147221231 has the following definition:

ecLoginFailure-MAPI_E_LOGON_FAILED

Event 8197 may be generated when one or more of the following conditions are true:

Exchange Server was not restarted after the domain controllers and the global catalog servers in the organization were restarted.
In a Microsoft Windows NT 4.0 environment, asecurity template that restricts the authentication methods that Exchange Server can use is applied. Alternatively, you modify security policy settings that modify the LMCompatibilityLevel registry entry on the Exchange server.
A connectivity problem exists with the global catalog server to which the free/busy polling task tries to bind.
Microsoft Outlook is installed on the computer that is running Exchange Server.

RESOLUTION

To resolve this issue, use one or more of the following methods.

Method 1: Restart the Exchange Server services

If Exchange Server was not restarted after the domain controllers and the global catalog servers in the organization were restarted, you must restart the Exchange Server services. To do this, follow these steps:

Stop the Microsoft Exchange System Attendant service, and then set all Exchange Server services to the Manual startup type.
Restart the computer that is running Exchange Server.
Start all the Exchange Server-related services manually.
Restore all the Exchange Server-related services to their original startup types.

Method 2: Verify the LAN Manager authentication settings

Warning Serious problems might occur if you modify the registry incorrectly by using Registry Editor or by using another method. These problems might require that you reinstall your operating system. Microsoft cannot guarantee that these problems can be solved. Modify the registry at your own risk.

You may experience the issue that is described in the "Symptoms" section when the following conditions are true:

You have a Windows NT 4.0 domain in your organization.
You apply a security template that restricts the authentication methods that Exchange Server can use. Alternatively, you modify security policy settings that modify the LMCompatibilityLevel registry entry on the Exchange server.

We recommend that member servers in a Window NT 4.0 domain use a LMCompatibilityLevel setting of 1. View the LMCompatibilityLevel registry entry to determine whether the value of this setting is greater than 1. To do this, follow these steps:

Click Start, click Run, type regedit, and then click OK.
Locate and then click the following registry subkey:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa
In the right pane, notice the data value of the LMCompatibilityLevel registry entry.

If this value is greater than one, you must change it to 1. You can do this by directly modifying the registry entry.

This setting might also be modified by a Group Policy. To verify whether the setting is modified by a Group Policy, view the LAN Manager Authentication Level Group Policy object. To do this, follow these steps.

Note Because there are several versions of Microsoft Windows, the following steps may be different on your computer. If they are, see your product documentation to complete these steps.

On a domain controller, click Start, click Run, type dsa.msc in the Open box, and then click OK.
In the Active Directory Users and Computers snap-in that appears, right-click the container in which the Group Policy is configured, and then click Properties. For example, right-click the domain container or right-click the organizational unit that contains the Exchange server.
Click the Group Policy tab, and then click the Group Policy object in which the policy is set.
Click Edit.
Expand Computer Configuration, expand Windows Settings, expand Security Settings, expand Local Policies, and then click Security Options.
In the right pane, double-click LAN Manager Authentication Level.

For more information about LAN Manager authentication levels, click the following article numbers to view the articles in the Microsoft Knowledge Base:

823659 Client, service, and program incompatibilities that may occur when you modify security settings and user rights assignments

305379 Authentication Problems in Windows 2000 with NTLM 2 Levels Above 2 in a Windows NT 4.0 Domain

239869 How to enable NTLM 2 authentication

Method 3: Troubleshoot connectivity to the global catalog server to which the free/busy polling task tries to bind

Step 1: Determine the global catalog server to which the free/busy polling task tries to bind

Click Start, click Run, type regedit, and then click OK.
Locate the following registry subkey:

HKEY_USERS\.DEFAULT\Software\Microsoft\Windows NT\CurrentVersion\Windows Messaging Subsystem\Profiles\ExchangeAdmin<server name><GUID>

Note The Microsoft Exchange System Attendant service must be running for this registry subkey to be present. Use the first ExchangeAdmin<server name><GUID> subkey that appears under Profiles.
Under ExchangeAdmin<server name><GUID>, click dca740c8c042101ab4b908002b2fe182.
In the right pane, view the Data values for the 001e6602 registry entry. The Data values resemble the following values:

Value name: 001e6602
Value type: REG_SZ
Value data: SERVERNAME

In this registry entry, SERVERNAME represents the name of the global catalog server to which the free/busy polling task tries to bind.

Note This registry entry differs from the following registry entry. You can use the following entry registry to configure the DSAccess component to use only one directory server or global catalog server:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Exchange\Exchange Provider\DS

Note This registry entry is intended for use on client computers only. This registry entry should not be present on the server computer. If the registry entry is present, a problem occurs..

Note The directory server registry subkey pertains only to directory access that involves the DSAccess component.

After you determine the global catalog server to which the free/busy polling task tries to bind, perform general network connectivity troubleshooting steps to make sure that the global catalog server is responsive and is operating correctly.

Step 2: Verify the trust relationship between domains

Verify that a trust relationship exists between the domain in which Exchange Server is running and the domain that contains the global catalog server to which the free/busy polling task tries to bind.

If you have a mixed-mode environment that has Exchange Server 5.5 running in a Windows NT 4.0 domain, the issue might be caused by a missing trust relationship between the Windows NT 4.0 domain and the domain that contains the global catalog server.

For free/busy compatibility between a server that is running Exchange Server 5.5 and a server that is running Exchange 2000 Server or Exchange Server 2003, the free/busy polling task must impersonate the Exchange Server 5.5 service account. If no trust relationship exists between the Windows NT 4.0 domain and the domain that contains the global catalog server, Exchange Server generates Event 8197. This occurs when the free/busy polling task unsuccessfully tries to bind to the global catalog server by using the Exchange Server 5.5 service account.

This scenario is more likely to occur when a global catalog server is in a root domain and Exchange Server is in a child domain in the same Active Directory site. The Windows referral mechanism ignores domain membership when the mechanism tries to locate a global catalog server. Consider the following sample scenario:

A global catalog server is in the root domain of an Active Directory directory service site.
A global catalog server is in a child domain of the same Active Directory site.
An Exchange server is in the child domain of the same Active Directory site.

In this scenario, each global catalog server has the same chance of being used by the free/busy polling task. Therefore, if the global catalog server that is in the root domain does not have a trust relationship with a Windows NT 4.0 domain that contains servers that are running Exchange Server 5.5, the following symptoms may occur:

The free/busy polling task impersonates the Exchange Server 5.5 service account. Additionally, the task tries to bind to the global catalog server that is in the root domain.
Because no trust relationship exists between the root domain and the Windows NT 4.0 domain that contains the Exchange Server 5.5 service account, authentication is unsuccessful.

In this situation, Exchange Server generates Event 8197.

To work around this issue, follow these steps:

Move the global catalog server from the root domain to its own site.
Add the global catalog server's subnet to the new site.
Allow time for the changes to replicate among the servers in your organization, and then restart the global catalog server that you moved.
Restart the global catalog server in the child domain in which Exchange Server is located.
Restart the Exchange server.
View the registry entry that is described in "Step 1: Determine the global catalog server to which the free/busy polling task tries to bind." Do this to verify whether the free/busy polling task uses the global catalog server from the child domain that contains the Exchange server. You may have to wait until the profiles are created before you can view this registry entry.
View the Application log to determine whether Event 8197 continues to be logged.

Note The Windows referral mechanism only distinguishes global catalog servers based on site membership and not on domain membership. Therefore, two global catalog servers that are from different domains but that are in the same site have an equal chance of being used by the free/busy polling task in that site.

For more information, click the following article number to view the article in the Microsoft Knowledge Base:

828764 "Event 8197" error message is logged repeatedly in the Application event log

Step 3: Verify whether an incorrect global catalog server entry is in Active Directory

If the particular global catalog server with which you experience this issue is responsive and appears to function correctly, verify whether an incorrect global catalog server entry is located in Active Directory. Incorrect global catalog server entries may also cause Event 8197 errors.

To verify whether these entries exist, enter the following query at a command prompt:

ldifde -f output.ldf -d "dc=mydomain,dc=com" -t 3268 -p subtree -r "(&(objectclass=*)(name=SERVERNAME))"

In this command, replace mydomain and com with the corresponding names of your domain. Also, replace SERVERNAME with the name of the global catalog server to which the free/busy polling task tries to bind. After you run this command, view the contents of the Output.ldf file to determine whether entries exist that resemble the following output:

dn: CN=SERVERNAME,CN=Computers,DC=mysubdomain,DC=mydomain,DC=com

distinguishedName:
CN=SERVERNAME,CN=Computers,DC=na,DC=mydomain,DC=com

In this sample output, the global catalog server entry is incorrect. This entry incorrectly appears in the Computers container as follows:

CN=Computers

A valid global catalog server must have an entry in the Domain Controllers container, as shown in the following sample output:

dn: CN=SERVERNAME,OU=Domain Controllers,DC=mydomain,DC=com

distinguishedName:
CN=SERVERNAME,OU=Domain Controllers,DC=mydomain,DC=com

When both correct and incorrect global catalog server entries appear in Active Directory, a DNS query for a global catalog server may return the incorrect global catalog server entry. Therefore, the free/busy polling task's attempt to bind to the global catalog server is unsuccessful.

An incorrect global catalog server entry may be created when the following conditions are true:

You configure a server as a member server in a domain, such as "subdomain.example.com."
You install Active Directory on this server to change the server's status to that of a domain controller for a different domain, such as "example.com." You then configure this new domain controller as a global catalog server.

To resolve this issue, remove the incorrect global catalog server entry from Active Directory, and then flush the DNS resolver cache on the computer that is running Exchange Server. To do this, follow these steps:

Start the Active Directory Users and Computers snap-in. To do this, click Start, click Run, type dsa.msc in the Open box, and then click OK.
Expand the domain, and then expand the container in which the incorrect global catalog server entry is located. For example, expand Computers.
Right-click the incorrect global catalog server entry, and then click Delete.
Click Yes.
Log on to the Exchange server with which you experience this issue, and then open a command prompt.
At the command prompt, type ipconfig /flushdns, and then press ENTER.

Method 4: Verify whether Outlook is installed on the Exchange server

We recommend that you do not install Outlook on the same computer that is running Exchange Server. This is because conflicts might occur between the Exchange Server versions and the Outlook versions of the following files:

Mapi32.dll
Emsabp32.dll
Emsmdb32.dll

The Mapi32.dll, Emsabp32.dll, and Emsmdb32.dll files that are included with Outlook come from a MAPI implementation that differs from the implementation that is used in Exchange Server. Because Outlook has different MAPI requirements than Exchange Server, each product's MAPI implementation has been optimized to meet the particular product requirements.

For example, Exchange Server uses the Emsabp32.dll file to pass credentials, to authenticate, and to perform an Nspbind operation to the global catalog server for address lookup operations. The Outlook version of this file prompts users for their credentials when it is used to perform these operations. The Exchange Server version of this file uses a different mechanism to pass the credentials for the local system account under which Exchange Server runs. Therefore, if you have Outlook installed on a computer that is running Exchange Server, you may experience authentication errors or other instability in the Exchange Server environment.

To resolve this issue, remove Outlook, and then reinstall Exchange Server.

MORE INFORMATION

The Exchange Server Mailbox Manager component also relies on the Windows referral mechanism to locate a global catalog server. Generally, when you experience Event 8197 errors that occur with the free/busy polling task, the Mailbox Manager also experiences failures. In this situation, both of the following events are logged in the Application log: Event Type: Error
Event Source: MSExchangeSA
Event ID: 9175
Description: The MAPI call 'OpenMsgStore' failed with the following error: The information store could not be opened. The logon to the Microsoft Exchange Server computer failed. MAPI 1.0 ID no: 80040111-0286-00000000

Event Type: Error
Event Source: MSExchangeSA
Event Category: Mailbox Management
Event ID: 9200
Description: Failed to perform MAPI logon.

Additional query words: XADM

Keywords: kbeventlog kbtshoot kbprb KB918006

Microsoft KB Archive/918006

Contents