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

On a computer that is running Exchange Server 2003 or Exchange 2000 Server, the following event is logged in the Application log every 25 minutes:

Event Type: Error
Event Source: MSExchangeFBPublish
Event Category: General
Event ID: 8197
Computer: ServerName
Description: Error initializing session for virtual machine ComputerName. The error number is 0x80040111. Make sure Microsoft Exchange Store is running.

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

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 uses the Windows referral mechanism to locate a global catalog server.

The method that the Windows referral mechanism uses to locate a global catalog server differs slightly from the method that the DSAccess component uses. Therefore, the free/busy polling task may not use the same global catalog server that most other Exchange Server tasks use. 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: Event 8197 may be generated when at least one of the following conditions is true:

• Exchange Server is not restarted after the domain controllers and the global catalog servers in the organization are restarted.
• In a Microsoft Windows NT 4.0 environment, 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.
• There is a connectivity problem 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.
• The Exchange 2000 server validates against a global catalog server in a domain that does not have a correct trust relationship established to a Microsoft Windows NT Server 4.0 domain. Additionally, the Microsoft Exchange Server 5.5 service account cannot log on to the System Attendant mailbox.

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:

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

Method 2: Verify the LAN Manager authentication settings

Important This section, method, or task contains steps that tell you how to modify the registry. However, serious problems might occur if you modify the registry incorrectly. Therefore, make sure that you follow these steps carefully. For added protection, back up the registry before you modify it. Then, you can restore the registry if a problem occurs. For more information about how to back up and restore the registry, click the following article number to view the article in the Microsoft Knowledge Base:

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 Windows NT 4.0 domain use an LMCompatibilityLevel setting of 1. View the LMCompatibilityLevel registry entry to determine whether the value of this setting is larger than 1. To do this, follow these steps:

1. Click Start, click Run, type regedit, and then click OK.
2. Locate and then click the following registry subkey:
   HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa
3. In the right pane, notice the data value of the LMCompatibilityLevel registry entry.

If this value is larger than 1, you must change it to 1. To do this, modify the registry entry directly.

This setting may 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.

1. On a domain controller, click Start, click Run, type dsa.msc in the Open box, and then click OK.
2. 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.
3. Click the Group Policy tab, and then click the Group Policy object in which the policy is set.
4. Click Edit.
5. Expand Computer Configuration, expand Windows Settings, expand Security Settings, expand Local Policies, and then click Security Options.
6. 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:

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

1. Click Start, click Run, type regedit, and then click OK.
2. Locate the following registry subkey:
   HKEY_USERS\.DEFAULT\Software\Microsoft\Windows NT\CurrentVersion\Windows Messaging Subsystem\Profiles\ExchangeAdmin<server name><GUID>
   Note For this registry subkey to be present, the Microsoft Exchange System Attendant service must be running. Use the first ExchangeAdmin<server name><GUID> subkey that appears under Profiles.
3. Under ExchangeAdmin <server name><GUID>, click dca740c8c042101ab4b908002b2fe182.
4. 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 subkey differs from the following registry subkey. You can use the following registry subkey to configure the DSAccess component to use only one directory server or one global catalog server: 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, troubleshoot general network connectivity. In this manner you can make sure that the global catalog server is responsive and that it is operating correctly.

Step 2: Verify the trust relationship between domains

Verify that a trust relationship exists between the following domains:

• The domain in which Exchange Server is running
• The domain that contains the global catalog server to which the free/busy polling task tries to bind

For example, 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 example, you have one server that is running Exchange Server 5.5 and a second server that is running Exchange 2000 Server. Or, the second server is running Exchange Server 2003. For free/busy compatibility to exist between these two servers, 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 directory service 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 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. However, the global catalog server that is in the root domain may not have a trust relationship with the Windows NT 4.0 domain that contains the Exchange 5.5 servers. If there is no trust relationship, 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:

1. Move the global catalog server from the root domain to its own site.
2. Add the global catalog server's subnet to the new site.
3. Give some time for the changes to replicate among the servers that are in your organization. Then, restart the global catalog server that you moved.
4. Restart the global catalog server in the child domain in which Exchange Server is located.
5. Restart the Exchange server.
6. 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.
7. View the Application log to determine whether Event 8197 continues to be logged.

Note The Windows referral mechanism only distinguishes global catalog servers by site membership and not by domain membership. For example, two global catalog servers may be from different domains. However, if these global catalog servers are in the same site, they have an equal chance that the free/busy polling task in that site will use them.

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

If the particular global catalog server that experiences this issue is responsive and appears to function correctly, an incorrect global catalog server entry may be located in Active Directory. Incorrect global catalog server entries can also cause Event 8197 errors.

To verify whether incorrect entries exist, type the following query at a command prompt: 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: In this sample output, the global catalog server entry is incorrect. This following entry incorrectly appears in the Computers container: A valid global catalog server must have an entry in the Domain Controllers container. This is shown in the following sample output: 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, when the free/busy polling task tries to bind to the global catalog server, the task 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. Then, flush the DNS resolver cache on the computer that is running Exchange Server. To do this, follow these steps:

1. 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.
2. Expand the domain, and then expand the container in which the incorrect global catalog server entry is located. For example, expand Computers.
3. Right-click the incorrect global catalog server entry, and then click Delete.
4. Click Yes.
5. Log on to the Exchange server that is experiencing this issue, and then open a command prompt.
6. 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 of the following files and the Outlook versions of the following files:

• Mapi32.dll
• Emsabp32.dll
• Emsmdb32.dll

The Outlook versions of the files come from a MAPI implementation that differs from the implementation that is used in Exchange Server. Outlook has different MAPI requirements than Exchange Server has. Each product's MAPI implementation has been optimized to meet the product's 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 performs 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.

The Exchange 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.