White Paper: Troubleshoot Why Exchange Server Cannot Copy the Outlook Address Book to the CAS

Letztes Änderungsdatum des Themas: 2016-11-28

Todd Maxey, SR Support Escalation Engineer

April 2011

Summary

This white paper describes how to troubleshoot problems that prevent the Offline Address Book (OAB) from being copied to a Client Access server (CAS).

Applies To

Microsoft Exchange Server 2010

Microsoft Exchange Server 2007

Contents

• Introduction

• How Exchange OAB Files are Replicated to a Client Access Server

• Errors

• Potential Causes

• Name Resolution

• Named Pipes Access

• Potential Causes

• Understanding SMB and the Cause of Access Denied

Introduction

The File Distribution Service (FDS) is a component on the CAS that is responsible for the replication of OAB files from the OAB Generation server to the CAS. However, an issue that affects this process may cause the OAB not to be copied to the CAS. The main troubleshooting tool discussed in this white paper is Microsoft Network Monitor 3. You can use Network Monitor 3 to gather information about the Microsoft Windows Server 2008-based network on the CAS when you reproduce the problem.

For more information, see Information about Network Monitor 3.

How Exchange OAB Files are Replicated to a Client Access Server

Before we examine problems that may prevent the OAB from being copied to the CAS, let us review how the OAB files are replicated to the CAS. The process is as follows:

• The OAB Generation Server generates a Version 4 Offline Address List.

• At the end of the generation, the files reside in the System Attendant Mailbox, which is the master location. The files are then copied from the System Attendant Mailbox to the local distribution share on the OAB Generation Server.

• At this point, the files can be downloaded from the OAB Generation Server by a Microsoft Outlook client.

• A notification is sent to the FDS service on the Client Access Server files are waiting to be replicated.

• The FDS starts replication of the files to the remote distribution points.

When an OAB has been successfully replicated to the CAS, the following event is recorded.

Errors

If a problem prevents the OAB from being copied to a CAS, the following common events are recorded in the event log.

Potential Causes

Typically, problems that prevent the OAB from being copied to the CAS are caused by errors in the following items:

• Name resolution

• Share permissions

• NT File System (NTFS) Permissions

In the following sections, we will explore how to troubleshoot each of these possible causes.

Name Resolution

To determine whether name resolution is causing the problem, use the Ping command and a network trace in Network Monitor 3 to locate indicators of this cause.

At a command prompt, run the command PING –a from the CAS to the OAB server. The –a parameter specifies that reverse name resolution is performed on the destination IP address. If this search is successful, ping displays the corresponding host name. The results should show the correct fully qualified domain name (FQDN) of the OAB server for the domain in which the OAB server is joined.

Use Netsh Trace in Network Monitor 3 to capture a network trace. For more information about how to do this, view Using Netsh Trace to Manage Traces. In the network trace, you can see the CAS trying to access the OAB server. You can also see that the CAS is authenticating with NT LAN Manager (NTLM) by using NULL credentials, and that it is receiving a STATUS_ACCESS_DENIED error message.

The reason that this error occurs is that Domain Name System (DNS) is used during the creation of the Service Principal Name (SPN), and the information that is returned in the DNS query for the OAB server is incorrect.

This error may occur for any of the following reasons.

Using WINS lookup in DNS

If the OAB server and the CAS are in different domains, and if these domains have a common Windows Internet Name Service (WINS) structure, a query to the forward lookup zone (FLZ) of the CAS domain that has the host name of the OAB server should not resolve. However, if the FLZ for the CAS domain is set to use WINS forward lookup, it will query WINS, find the record, and return a false FQDN to the CAS. The resulting host/OABServer.CASDomain.com SPN does not actually exist. Therefore, the Key Distribution Center (KDC) returns an S_PRINCIPAL_UNKNOWN error code. This can be seen in a network trace. This error causes a failover to NTLM authentication.

DNS Search order and non-AD FLZs

If the DNS suffix search order for a server starts with or includes FLZs that have mirrored records from the Active Directory FLZ, this can cause DNS to return the FQDN for a domain in which the OAB server is not a member. Remember that you should always search first for the suffix of the domain that your server has joined.

HOSTS and LMHOSTS file

Note that invalid entries in the machines HOSTS or LMHOSTS file can also cause this failure.

Understanding SMB and the Cause of Access Denied

To address problems that may occur because of Share permissions and NTFS permissions, we will examine Server Message Blocks (SMB) and the common cause of the access-denied error. The best way to troubleshoot SMB access-denied problems is by using Network Monitor 3 to capture network data.

Using Network Monitor 3 to capture data can consume a lot of system resources. Therefore, if you want to minimize the effect on system resources that may occur when you use Network Monitor 3, use the Nmcap.exe command-line tool to capture data.

Network Monitor 3 enables you to collect network data and to view the network data in real time as the data is captured. To start a capture session in Network Monitor 3, click the Start Page tab, click Create a new capture tab, and then either click the Start Capture button or press F10.

The following items or situations can cause an access denied error:

• SMB signing

• "Access this computer from the network" message generated

• Share permissions

• NTFS Permissions

• File in use

• Named Pipes NULL session authentication

• SMB share NULL session authentication

• Licensing being set for per connection and exceeding the number of stated connections

To understand these operations and effectively troubleshoot the problem, we must examine the File access and Named Pipes access methods.

File access

Use Netsh Trace in Network Monitor 3 to capture a network trace. In the network trace, you see the following distinct stages that occur when accessing a Common Internet File System (CIFS)/SMB share:

• The establishment of a Transmission Control Protocol (TCP) connection to ports 445 and 139

• The SMB dialect negotiation

• The connection to IPC$ (this may not exist because it is not required in all circumstances)

• The connection to the share

• A query for the existence on an autorun.inf file (this behavior is specific to Explorer)

• The findfirst \* command to the remote file system (this behavior is specific to Explorer)

To analyze the network trace, follow these steps.

Step 1

You should see the initiation of the TCP connection. This is known as the three-way handshake. This will consist of a Sync packet from the client, an Ack Sync packet from the server, and an Ack packet from the client.

If you can establish a connection on port 445, the connection on port 139 is reset by the client (the CAS, in this case).

If ports 139 and 445 are being blocked, the client receives the following error message:

This is the same message that you receive if the Server service is disabled. You also see the target server reset ports 139 and 445 directly after the SYN from the client.

Step 2

This is the SMB dialect negotiation. The client passes to the server a list of SMB dialects that it supports, and the server selects an SMB dialect from that list.

If a user is denied the Access permission to this computer from the network, the final R session setup frame displays STATUS_LOGON_TYPE_NOT_GRANTED.

The client may receive the following message:

This may occur because the Server service on the target computer is not running. In this case, both the share and IPC$ are unavailable.

In a network trace, if you see that the connection is being reset after the first two frames of the SMB dialect negotiation, this is most likely caused by an SMB Signing issue in which SMB signing is disabled on the server and set to Always on the client.

For more information about SMB Signing related errors, see Overview of Server Message Block signing.

Step 3

In this step, the client performs a tree connection to IPC$. During the Tree Connect AndX response to the IPC$ share, a STATUS_ACCESS_DENIED error message is generated. This indicates an SMB signing issue in which the client is not using SMB signing and the server is always using SMB signing.

For example, the following graphic illustrates a normal IPC$ connection.

And the next graphic illustrates the SMB signing issue.

Step 4

The client establishes the connection to the file share. An Access Denied error at this point indicates that NULL credentials are being used in NTLM authentication. If the process accessing the share is running under the System account, and if you use NTLM authentication, you see NULL credentials.

If you see NTLM instead of Kerberos, and if the client and server are in the same forest, you should investigate why Kerberos is failing.

If the error message is STATUS_REQUEST_NOT_ACCEPTED, this could be an indication that the server was configured for Per Connection Licensing and that you are exceeding the number of configured connections allowed.

Step 5

The client queries for the existence of an autorun.inf file. If the share permissions do not allow access for the user, then you see an Access Denied error message on the client. In the trace, you see several STATUS_ACCESS_DENIED frames from the server.

For more information about the autorun.inf file and about how it can be used, see the following Microsoft Knowledge Base article: HOW TO: Create an Autorun CD-ROM for Applications That You Create by Using Microsoft Visual Studio .NET.

Step 6

This is the enumeration of the remote file system. In this example, we map directly to the share. When we connect, the directory contents are displayed. This is accomplished by the findfirst \* SMB command. If there are any NTFS permissions issues, they will appear on the client as an Access Denied message and in the trace as STATUS_ACCESS_DENIED.

Named Pipes Access

Microsoft Exchange does not use Named Pipes for the OAB operations or for MAPI client connectivity. The following information is provided for reference.

In a trace, the following distinct stages occur during the access of a named pipe:

• The establishment of a TCP connection to ports 445 and 139

• The SMB dialect negotiation

• The connection to IPC$

• The connection to the named pipe

Stages 1 through 3 are the same as those mentioned earlier for a CIFS connection.

Stage 4 passes the named pipe to the target server that it wants to access. If you do this by using NULL session authentication, and if the named pipe does not allow a NULL session, you receive a STATUS_ACCESS_DENIED error message.

Additional Resources

Information about Network Monitor 3

Overview of Server Message Block signing

Understanding Offline Address Books

Troubleshooting Kerberos

How to capture network traffic with Network Monitor