Article ID: 177308
Article Last Modified on 10/28/2006
APPLIES TO
- Microsoft Exchange Server 4.0 Standard Edition
- Microsoft Exchange Server 5.0 Standard Edition
- Microsoft Exchange Server 5.5 Standard Edition
This article was previously published under Q177308
SYMPTOMS
The following are symptoms of this issue:
Slow client logons (up to 10 minutes or more) during peak logon hours or even relatively slow logons for solitary or small group logons.
In the Windows NT Performance Monitor (PerfMon), Process, % CPU utilization, DSAMAIN.EXE (DS) will sustain a very high CPU utilization percentage (75% or more) throughout the peak logon periods. In addition, the DS may jump up high for relatively long times (1-4 minutes) for solitary or small group logons (~5).
Enabling the Directory Service logging, ExDS interface logging to maximum will log numerous "ds_read entered" and "ds_read completed" events (1136 and 1137, respectively). Also, enabling maximum MAPI interface, logs NspiBind events (1136 - client and otherwise).
A network trace between the Exchange client and server may show that a long time elapses between when the first RPC OpNum2 request to the store's GUID is issued, and when the server actually returns an RPC response to this request.
CAUSE
When the client logs on, a comparison between the existence of one-off address templates in the directory, and the Address-Types in the ODI cache of the store is performed. If an address-type exists in the ODI cache, but a corresponding address template does not exist in the DS, a flag is set to reload the ODI cache. The cache is reloaded, but the flag is never reset, so a cache reload is continually signaled.
The logon process is serialized behind this cache reload.
This can noticeably impact logon if:
- There are many non-native Exchange address-types, or if a particular non-native Exchange address type has many entries in the Microsoft Exchange Administrator program under:
<org>/<local-sitename>/Configuration/Site Addressing/Routing tab
- No address template is installed in the site for this address-type.
WORKAROUND
To work around this problem, do the following:
- Make sure that there is a one-off addressing template installed within the site for any non-native Exchange address-type.
- Examine \exchsrvr\mtadata\GWART0.MTA to derive a list of unique address types.
- View the list of installed one-off address templates under:
<org>/<local-sitename>/Configuration/Addressing/One-off Address Templates/<language>
STATUS
Microsoft has confirmed this to be a problem in Microsoft Exchange Server version 4.0. This problem has been corrected in the latest U.S. Service Pack for Microsoft Exchange Server version 4.0. For information on obtaining the Service Pack, query on the following word in the Microsoft Knowledge Base (without the spaces):
S E R V P A C K
Microsoft has confirmed this to be a problem in Microsoft Exchange Server version 5.0. This problem has been corrected in the latest U.S. Service Pack for Microsoft Exchange Server version 5.0. For information on obtaining the Service Pack, query on the following word in the Microsoft Knowledge Base (without the spaces):
S E R V P A C K
Microsoft has confirmed this to be a problem in Microsoft Exchange Server version 5.5. This problem has been corrected in the latest U.S. Service Pack for Microsoft Exchange Server version 5.5. For information on obtaining the Service Pack, query on the following word in the Microsoft Knowledge Base (without the spaces):
S E R V P A C K
MORE INFORMATION
A code change has been implemented to discriminate between the cases when an address template is "not found" versus the case when "an error occurred looking for an address template". The reload flag is no longer signaled for the former case.
This case involved a single-server Exchange version 4.0 site that had replicated with the rest of the organization, which included a mix of Exchange 4.0 and 5.0 sites and servers. One of the 5.0 sites had implemented a CCMAIL connector to an extensive cc:Mail installation. This resulted in many CCMAIL routes being added into the routing table (GWART). These routing entries were replicated throughout the organization.
Exchange 5.0 supports the CCMAIL address-type as a native Exchange address- type, and includes a One-off Address template for this address-type. Exchange 4.0 does not support the CCMAIL address-type as a native Exchange address-type. The solitary Exchange 4.0 Site did not have a CCMAIL One-off Address template installed, thus logons within this site experienced this inefficiency.
Keywords: kbbug kbfix KB177308
