Tài liệu Module 7: Exchange Directory Components pdf

Configuration Domain Controller – a single server chosen from the list of domain controllers that is used to read and write configuration data.. controllerhas the Exchange server name in

Contents

Overview 1

Lesson 1: Changes to the ADC 2

Lab 7.1: Troubleshooting LDAP queries 12

Lesson 2: DSAccess Usage and troubleshooting 16

Lesson 3: Changes in DSAccess 28

Lab 7.2: Exomatic tool 37

Lesson 4: Other Directory Changes 38

Lab 7.3: Per-Attribute change troubleshooting 59

Lab 7.4: Post-Setup and SRS replication troubleshooting 59

Appendix A: Numeric registry keys used by DSAccess and their values 68

Appendix B: Answers to some of the Labs 69

Acknowledgments 70

Module 7: Exchange Directory Components

Information in this document, including URL and other Internet Web site references, is subject to change without notice Unless otherwise noted, the example companies, organizations, products, domain names, e-mail addresses, logos, people, places, and events depicted herein are fictitious, and no association with any real company, organization, product, domain name, e-mail address, logo, person, place or event is intended or should be inferred Complying with all applicable copyright laws is the responsibility of the user Without limiting the rights under copyright, no part of this document may be reproduced, stored in or introduced into a retrieval system, or transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or otherwise), or for any purpose, without the express written permission of Microsoft Corporation Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document Except as expressly provided in any written license agreement from Microsoft, the furnishing of this document does not give you any license to these patents, trademarks, copyrights, or other intellectual property

 2003 Microsoft Corporation All rights reserved

Microsoft, MS-DOS, Windows, Windows NT, Active Directory, ActiveX, Excel, Exchange Server 5.5, Exchange 2000 Server, Exchange Server 2003, Internet Explorer, Internet Information Server, Word are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries

The names of actual companies and products mentioned herein (Groupwise, Lotus cc:Mail, Lotus Notes) may be the trademarks of their respective owners

„ Experience with troubleshooting ADC and DSAccess

„ Understanding of the ADCTools/Deployment Tools module

Lesson 1: Changes to the ADC

This topic discusses changes to the Active Directory connector that are not covered in the Deployment and ADC Tools module

ADC Setup includes the entire Exchange Server 2003 schema

In Exchange 2000, the ADC schema files were a subset of the Exchange 2000 core schema files So although the ADC’s setup /schemaonly switch extended the schema, customers were required to perform further schema extensions using setup /forestprep This meant longer lockdown periods for larger customers whose custom applications were sensitive to schema extensions due

to the delayed nature of replications and resetting of indexed attributes (You may refer to KB article 230662 for more information on indexed attributes)

In Exchange 2003, the schema files imported during the installation or upgrade

of an Active Directory Connector service are identical to the core Exchange

2003 schema; therefore, the schema is only updated once So if the Exchange

2003 version of ADC setup detects the existence of the Exchange 2003 schema, then no further schema updates will be applied On the other hand, if ADC setup detects a schema version below 6870, the Exchange 2003 schema updates

will be applied ADC Setup detects the schema by examining the RangeUpper

attribute of this object in Active Directory:

cn=ms-Exch-Schema-Version-Pt,cn=schema,cn=configuration,dc=<DN-of-forest-root-domain>

If a domain controller does not show a value of 6870 for the RangeUpper attribute, the schema extension has not completed There are no more schema updates beyond RangeUpper, since it is the last entry added to the schema9.ldf file:

dn: CN=ms-Exch-Schema-Version-Pt,<SchemaContainerDN>

changetype: modify replace: rangeUpper rangeUpper: 6870

Note: Although Exchange 2003’s ADC setup includes the entire schema, it does not mean it is equal to a setup /forestprep This is because ADC Setup does not perform many of forestprep’s actions, such as importing the Outlook templates and set access control lists (ACLs) on some Active Directory containers Additionally, forestprep cleans up some address templates and display specifiers (The removed display specifiers were Exchange 5.5 classes that were never used nor shown in Active Directory.) Therefore, forestprep is still required if ADC’s setup executable is run first, but customers who follow change-control procedures within large environments will not need to plan for additional administrative lockdowns while waiting for schema changes to replicate, since schema extensions will be skipped upon running forestprep later

Exchange 2003 ADC upgrades “versionNumber” on connection

When ADC setup upgrades connection agreements’ versionNumber attribute, the values are set to 16973842 Older ADC management snap-ins (such as Windows ADC and Exchange 2000 Service Pack 3 (SP3) ADC snap-in versions) will not be able to administer these new Connection agreements because they expect the older Major version (versionNumber = 16908296) If

an Exchange 2000 or Windows 2000 ADC manager snap-in is used to administer an upgraded or new Exchange 2003 connection agreement, this warning is displayed:

Figure 1.1: Version-incompatibility message when using the Exchange 2000 ADC snap-in to administer an Exchange 2003 connection agreement

By the same token, whenever an Exchange 2003 ADC Services snap-in is used

to open the properties of an Exchange 2000 or Windows 2000 connection agreement, the same popup warning as in Figure 1.1 will appear

The reasons for increasing the major versions on Public Folder Connection agreements and Recipient Connection agreements are so that:

„ Windows 2000 ADC services will not be able to run any newer Connection agreements (Any public folder Controller Agreement re-homed to the Windows 2000 version of the ADC service caused corruption.)

„ The new connection agreements use Kerberos for authentication, which are not understood by Exchange 2000 ADC services

In summary, an Exchange 2000 ADC service cannot run a connection agreement whose version is incompatible with its own Conversely, an Exchange 2003 service cannot run a connection agreement whose version number is below 16973842

Eventually, all ADC services must be upgraded prior to the installation of the first Exchange 2003 server Otherwise, Exchange 2003 setup may not proceed Customers must in-place upgrade all pre-Exchange 2003 ADC services prior to installation, so that all legacy connection agreements are phased out

ADC randomizes user logon names (Integrated CleanSAM

functionality)

In the situation where an Exchange 5.5 object exists, but its primary Windows account (assoc-NT-account) resides in a Windows NT 4 domain or in a separate forest, a properly-configured connection agreement directs the ADC service to perform object-creation (By contrast, if the mailbox’s “Primary Windows NT Account” pre-existed within the forest, the ADC performs “object matching” and stamps pre-existing user accounts during the initial replication cycle.) In the object-creation case, a disabled account is created by the ADC service In the past, the Exchange 2000 ADC services would generate the disabled security principal (a.k.a “samaccountname” or “Pre-Windows 2000 logon name”) that matched the Exchange 5.5 object’s alias name This caused problems for a couple of reasons:

„ Customers often had the misunderstanding that ADC object creation was an easy way to migrate Windows NT 4 accounts to Active Directory Although

it was not proper, customers would simply enable these “placeholder” accounts that were generated by the ADC, not knowing that this will cause delegation problems, Public Folder ACL conversion problems, and other permissions problems that may prevent logon or mailbox moves (For more information regarding problems caused by enabling placeholder accounts, see Knowledge Base articles Q300346 and Q316047.)

„ ADC-generated objects conflict with the Active Directory Migration Tool’s (ADMT) ability to migrate user logon names from their source domains (This situation only applies if ADMT is used after initial ADC replication, and if aliasname=userlogonname of the source domain) So when ADMT attempts to create user objects in the target domain, it encounters conflicts with the ADC-generated accounts ADMT was designed to resolve these conflicts by appending “-1” to each samaccountname it generates – thus satisfying the samaccountname uniqueness within a domain Although ADMT is a proper and supported migration method for user accounts, the “-

1” object causes an issue for customers because their users prefer not to append a “-1” to their logon process One may believe that ADClean may be used to merge the two objects into a single account, thereby resolving this issue However, ADClean excludes transferring samaccountname when it merges the disabled objects’ attributes to the ADMT-generated account In the end, users are still stuck with different user logon names (i.e User was accustomed to logging onto source domain as “johnsmith,” but must now logon as “johnsmith-1”)

In Exchange 2003, by randomizing samaccountnames (a.k.a Pre-Windows

2000 logon name) whenever the ADC generates a placeholder object, both previous problem scenarios are resolved A typical user logon name for an ADC-generated account would be “ADC_BDZQOKNUIZDWPPHG” where the characters following the underscore are always randomized Since this random username is difficult to use for any logon prompt, it detracts administrators from improperly enabling the placeholder accounts generated by the ADC Secondly, the prepared random name will not cause naming conflicts when the future ADMT migrations try to create new users in the Exchange

2003 forest

Although the Exchange 2003 ADC corrects this issue upon object creation, any existing objects that were created prior to an ADC was upgraded may still need their account names renamed Cleansam.vbs, a script used by Microsoft Product Support Services to correct the above issues for Exchange

2000 topologies, may be used against accounts residing in Exchange 2003 environments that were upgraded from Exchange 2000 The script may be obtained from a Microsoft Product Support Services Professional CleanSAM also resolved the behavior where in some instances, ADMT would “match” with the disabled accounts and subsequently merge on top of them, thereby enabling the accounts but failing to clear the msExchMasterAccountSID attribute

Note

New ADC uses Kerberos and signed LDAP

Connection agreements no longer use the configurable option “Windows NT Challenge/Response” (which is essentially NTLM) for authentication to domain controllers Instead, the Exchange 2003 ADC uses Kerberos for authentication This change reflects our “more secure” initiative, since

„ The ADC contains many valuable passwords, such as domain admin or even enterprise admin-level of privileges

„ NTLM and unsigned LDAP are susceptible to replay attacks

This change only affects the ADC server during its communication with a Windows 2000 SP3 domain controller or later Figure 1.2 illustrates the hard-coded changes to the ADC manager

Figure 1.2: The Exchange 2003 ADC uses Kerberos against Windows 2000 SP3 or later domain controllers

Note that in the figure above, Exchange 5.5 LDAP communication remains at the down-level Windows NT Challenge/Response authentication mechanism Only Windows 2000 SP3 or Windows 2003 domain controllers support signed LDAP on connection agreements

Lesson 4 discusses how the ADC Microsoft Management Console (MMC) and other admin components use Kerberos with signing, and how to troubleshoot decrypt the data over the wire

Troubleshooting ADC Setup:

When extending the schema, the installation wizard will call SCRunLDIFScript, which is the wrapper function that invokes ldifde to import any LDF files from the ADC\i386 folder If ADC setup fails, the ldif.err or ldif.log file may report reasons or other diagnostic information and can be found in the “local settings\temp” folder of the installer’s profile If ldif.log/ldif.err cannot be found, another troubleshooting step is to manually execute the import process that ADC setup tries to run Even if you are not able

to find the specific schema ldif file to import, you can always test importing the trial.ldf file (ldifde –i –f trial.ldf), as it is a good test of permissions

If neither manual import nor examination of the ldif.err or ldif.log file leads you closer towards resolution, examine the Active Directory Connector Setup.log file, which is located on the root of the system drive This file will detail each step of the ADC installation process, such as from importing the 10 schema?.ldf files, to the registering of the ADC service into the registry hive

ADC Setup uses the same Backoffice setup engine as Exchange 2000 and Exchange 2003, to record the history of setup sessions to the “Active Directory Connector Setup.log” at the root of the system drive As such, the logparser.exe utility may be used to navigate through various ADC setup sessions

Lab 7.1: Troubleshooting LDAP queries

Importance:

You will learn how to view Lightweight Directory Access Protocol (LDAP) queries in Exchange 2003, since they are signed and encrypted by default

Lesson Objectives:

At the end of this lesson, students will be able to

„ Configure debug LDAP setting

„ Use network monitor to view packets over the wire

Make sure that all virtual machines are powered-off If prompted to commit/discard changes, PLEASE CHOOSE DISCARD!

If you have insufficient memory that requires the virtual machines to exist

on two host machines, connect a crossover cable with a partner’s machine, then on the left student machine, start Z2, then remote55 On the right student machine, power-on Z6 When Z2 has completely started, power on Z0 on the left machine and Z3 on the right machine You may then set each

of the machines’ virtual network interfaces to “External” so that virtual machines running on each student machine may communicate with one another Alternatively, you may run all virtual machines on a single host machine if you tune the memory settings for each virtual machine to a lower number For example, change Z3 to 160 MB of RAM usage instead

of 192 MB

Exercise 1: Creating a new admin account

1 Log onto Z2 as ms\administrator

2 Open Active Directory Users and Computers, and use the administrator account as a template to COPY another user Name the new user “Admin2”

3 Open Exchange System Manager, and delegate Admin2 Exchange Full Administrator at the Organization Level

4 Log onto Z3 (Exchange 2003) as “Admin2”

5 Verify that you can see the queues node of Z3

6 Then, highlight server object, and then switch back to Z2’s virtual machine

Exercise 2: Simulate customer problem: Incorrectly “Locking

down” Exchange

Sometimes, customers believe that securing their Active Directory involves restricting access directly on Active Directory objects This is not the recommended method, and we will see what happens when the modifying a single ACL can cause problems with applications such as Exchange Although the exact steps below have not been followed by a customer, the following scenario is sufficient to create a cryptic problem that may have been difficult to troubleshoot:

1 Open ADSIEdit.msc

2 Go to the properties of the “Routing Groups” container underneath hubsite

3 Select the “Security” tab

4 Add a Deny access control entry (ACE) under “Full Control” for Admin2 Apply changes and quit the dialog

Exercise 3: Troubleshooting using network monitor

1 Netmon is already installed, so go to Start -> Run, and type netmon, and then click OK

2 A netmon folder will appear, so double-click on netmon.exe

3 For the interface, choose the network whose linkspeed is not 0

4 Get ready to start the capture Timing is crucial if you want a clean netmon capture, so read the next three steps to see what you will be doing

5 Start netmon capture, then immediately switch to Z3 and have Admin2 click back onto the “Queues” node in Exchange System Manager

6 You should have received a popup error As soon as it appears, make sure ms\administrator stops the netmon capture on Z2

7 View the capture, and you should not be able to determine what calls are being made over TCP port 389 (Lesson 4 discusses how the admin components use kerberos with signing, and how to troubleshoot decrypt the data over the wire.)

Exercise 4: Setting debugLDAP regkey

1 On Z3, open the registry editor

2 Navigate to HKEY_LOCAL_MACHINE\Software\Microsoft\Exchange

3 Create a DWORD called DebugLDAP, and assign it a value of 1

4 Restart Exchange System Manager so that it can pick up the registry change

5 Start netmon capture, repeating steps 4-6 in the last exercise

6 When you’ve stopped the netmon capture, examine it The TCP traffic over port 389 should have readable data now

Lesson 2: DSAccess Usage and troubleshooting

This topic discusses DSAccess as it is applicable to both Exchange 2000 and Exchange 2003 The changes specific to Exchange 2003 are discussed in the next topic This topic is an attempt to put all DSAccess knowledge needed for everyday operation, support, fixing and troubleshooting

It is worth mentioning that DSAccess is not the only Active Directory interface

for Exchange Transport components use their own Active Directory access mechanism, but it uses the list of domain controllers/global catalogs that DSAccess discovers Setup and System Attendant typically use ADSI instead of DSAccess

Exchange components use DSAccess to store and retrieve user information as well as Exchange configuration data

How DSAccess works

In order to read, and especially write to the Active Directory, Exchange needs special permissions These permissions are given by setup during the forestprep and domainprep stage to the Exchange Enterprise Servers group and Exchange Domain Server group During the “Core” setup, the Exchange server’s machine account is made a member of Exchange Domain Servers group, and that group

is a member of Exchange Enterprise Servers group All Exchange services run

as localsystem (even the Exchange App Pool on IIS6 runs as localsystem) and thus they access to the Active Directory under the machine account

Along with the “regular” ACL permissions setup grants all Exchange boxes a

“SACL right” – a permission to view ntSecurityDescriptor attribute This is granted via “SeSecurityPrivilege” privilege

DSAccess recognizes three types of Active Directory servers:

1 Global catalogs

2 Domain controllers

3 Configuration Domain Controller – a single server (chosen from the list of domain controllers) that is used to read and write configuration data At any given moment all DSAccess processes use the same ConfigDC, so that the services do not have to wait for replication of the configuration data

All these types of servers can be located by DSAccess automatically or manually set in Exchange System Manager’s “Directory Access” tab

Every 15 minutes DSAccess discovers the Active Directory topology and refreshes the list of Active Directory servers and their properties DSAccess locates all domain controllers in the current site and the closest sites (in terms of the link cost) Then it applies some checks and determines domain controller properties The complete table of domain controller properties at a given point

in time is logged in the event 2080 Here is a sample event 2080:

Permissions

Types of Active

Directory servers used

Topology

Event Type: Information Event Source: MSExchangeDSAccess Event Category: Topology

Event ID: 2080 Date: 9/24/2002 Time: 9:57:31 AM User: N/A

Computer: TENERIFE01 Description:

Process STORE.EXE (PID=2072) DSAccess has discovered the following servers with the following characteristics:

(Server name | Roles | Reachability | Synchronized | GC capable | PDC | SACL right | Critical Data | Netlogon | OS Version)

In-site:

csimison201.cmsdom.extest.microsoft.com CDG 7 7 1 1 1 1 7 1 csimison202.cmsdom.extest.microsoft.com CDG 7 7 1 0 1 1 7 1 Out-of-site:

csimison200.cmsdom.extest.microsoft.com CDG 7 7 1 0 1 1 7 1 csimison204.cmsdom.extest.microsoft.com CD- 6 6 0 0 1 1 6 1

As you see, this event lists all domain controllers and global catalogs and their properties Let’s look at them one by one:

C means server is able to act as a

Configuration domain controller

D means that a server is able to act as

a domain controller

G means that the server is able to act

as a global catalog

responds to a TCP ping to the global catalog port 3268 If bits 2 and 3 are set then the server responds to a TCP ping to the domain controller port

389 Thus, if a server is a domain controller only the value will be 6, if

it is a domain controller and a global catalog, the value will be 7 If a server is disconnected from network, its reachability will be 0

reachability, but it reports the synchronization status of a server

global catalog Invalid if global catalog is unreachable, in which case value would be 0

primary domain controller (PDC)

role (only if MinUserDCs regkey is set)

permission to read SACL on the domain controller

controllerhas the Exchange server name in the “Microsoft Exchange” container

reachability, but they report the success or failure of the DsGetDcName doing the RPC directly to the domain controller (which tests Netlogon service on the domain controller)

good enough (DSAccess Exchange Server 2003 only talks to domain controller that have Windows 2000 SP3 and above)

If any of these properties is 0 (except PDC, which is optional), DSAccess will not use these domain controllers (If the appropriate bits in the bitmask are 0, DSAccess will not use the domain controller in certain role) For example, in the event above the server csimison204 is not a global catalog, and therefore its reachability is 6, not 7 (the last bit is set to 0) This means that it may be used as

a domain controller or Config DC, but cannot be used as a global catalog

Connection pool

Since all services use just one user account (localsystem), it is possible for DSAccess to reuse the LDAP connections from one request to another Upon the startup or topology change DSAccess opens LDAP connections to all suitable domain controllers/global catalogs in topology By default DSAccess will use up to ten domain controllers and up to ten global catalogs at the same time The registry parameter that dictates this behavior is ldapconnections (Appendix B)

Failover

Whenever WLDAP32 returns an error on an LDAP operation, DSAccess analyzes it and determines if it means that the domain controller is having problems If so, the domain controller is immediately marked as unsuitable and the user operation is automatically retried on a different server This way, as long as there is at least one working domain controller in the topology, DSAccess can continue flawless operation

DSAccess topology always contains two lists: in-site and out-of-site Initially DSAccess only uses servers from the local site, but when all local servers from certain category (for example, GCs) are not suitable, DSAccess immediately starts using the out-of-site list and logs event 2084 or 2085 After that it keeps checking the local site every five minutes and fails back as soon as it is possible The user requests are retried on the out-of-site servers immediately and seamlessly for the users

If a DSAccess caller placed a notification, and the target server was marked as

being down, the notification gets reissued and the client is notified of a change, because the monitored value could have changed while we were reissuing the search

Versioning

DSAccess.dll is the main DLL that implements DSAccess, but it has to have matching dscmsg.dll and dscperf.dll that store event messages and perfcounters respectively So whenever dsaccess.dll is replaced – either through a hotfix application or through a service pack - it’s better to replace all three DLLs at once Replacing dscperf.dll is optional but doing so requires a matching dscperf.ini and dscperf.h; in turn, a hotfix or service pack update will need to unload the existing counters by running “unlodctr MsExchangeDSAccess” and then “lodctr dscperf.ini”

: Do not replace these DLLs unless a hotfix package fails

to apply the new binaries, or if many DSaccess-related performance counter warnings/errors flood the application event log (such as when a service pack install could not properly unload counters)

Troubleshooting Tip

Troubleshooting sequence

Get and examine the eventlogs

The event log is the easiest and best way to troubleshoot DSAccess The system log may contain the information about the system-wide events, like being out of memory or not being able to contact domain controllers (which obviously causes DSAccess problems not apparent to customers) The application log often contains DSAccess events that explain exactly what went wrong By default only the most serious issues affecting the mail flow are logged If the issue is periodic, increase the logging level and try to reproduce it – eventlog will contain lots of details In a new deployment, or if a customer has any kind

of trouble that might be related to the Active Directory, it is suggested to run with diagnostic logging categories Topology, LDAP and Config at level

“Minimum” (or above) This way every 15 minutes you will get a report of the topology state, plus all the details for each server

See “Topology” section above for the details on the 2080 event It is the first

thing to look at when DSAccess has any problems

When analyzing topology event 2080 make sure that the Active Directory topology DSAccess is using corresponds to Customer expectations

When looking at the LDAP category events, looking for reports on LDAP protocol errors like 0x34, 0x51 and 0x52 (A list of these errors are referenced

at us/netdir/ldap/return_values.asp

http://msdn.microsoft.com/library/default.asp?url=/library/en-Try to correlate these errors in the log or other network events http://msdn.microsoft.com/library/default.asp?url=/library/en-Try to find out if they are periodic (i.e logged every x number of minutes)

If the logging is turned on and events 2080 are logged, check that all events are logged in 15 minute intervals If there is more than 15 minutes between two events 2080, it may mean a DNS or network issue during topology discovery,

for example, inability to get an IP address or ping certain domain controller Other events (and their time) should help to pinpoint the root cause

If the event 2080 is not logged, look for other events, like 2114 that prevented topology discovery from happening Look up the error in that event For example, error 0x80040920 is a DSAccess way to report LDAP error 0x20 – LDAP_NO_SUCH_OBJECT It means that DSAccess did not find any Active Directory servers in the local site or closest sites – probably due to the

permission problem or misconfiguration As with any failed searches, the best way to find out what is happening is to repeat the same search in the LDP utility (see next paragraph)

New in Exchange Server 2003, DSAccess also includes a set of DNS troubleshooting events

If there is a particular object that has these problems, check “inherit permission” flag on the object itself and all levels walking up

For Exchange 2003, check if the Exchange domain servers group has been removed from the Pre-Windows 2000 compatible Access group to ensure that Exchange 2003 servers have the cross-domain access they need (222420 and 226063), as customers might have removed the domain servers group from the pre-W2kcompat group membership after misinterpreting the domainprep warning as “unsecure.” If the domain servers group is missing, you can rerun domainprep

Dump the Windows NT Security Descriptor of the “broken” object and of the closest “working” object and compare them Look for an ACL that could have broken things Exchdump/Exchutil is a great utility that can dump ACLs on Active Directory objects

If this is Exchange 2000, run the policytest.exe tool that ships on the Exchange

2000 CD (in “Support Tools”) to verify that “Manage auditing and security logs” privilege is granted to the Exchange Enterprise Servers group and replicated to all domain controllers in the local domain If using Exchange

2003, policytest has been replaced by a deployment tool So on the Exchange

2003 CD, run exdeploy.exe /t:polcheck to achieve the same results The tool should find the policy that grants Exchange servers the ability to read SACL on all Domain Controllers that have been domainprep’ed

The ultimate permission test is to install the Windows support tools on the Exchange server console and launch LDP.exe using “at /interactive” command This way LDP will be running under localsystem account and the results will exactly match what Exchange services see While doing that, it is often helpful

to turn on auditing on a domain controller (HOW TO: Audit Active Directory Objects in Windows 2000, http://support.microsoft.com/?id=314955) Be sure

to use the same domain controller/global catalog as the one that DSAccess used

at the time of failure (this information is usually present in the events or traces relating to the specific object which could not be accessed)

The existing permission model for Exchange 2000 has some defects For example, you cannot read certain attributes for an object that lives in domain A from a global catalog that belongs to domain B Although most of the attributes are “public information” there are a few attributes that are not public and therefore not visible:

Check KB or existing bugs

It is possible that there is a known problem or maybe even a hotfix available

Get the traces (regtrace.exe)

Even though the eventlog is very informative, the traces contain the most detailed and precise information DSAccess uses regtrace – a common tracing mechanism used by multiple Exchange components You can turn it on and off without restarting a service See Appendix A for details on how to get useful traces

Note

DSAccess events

DSAccess has a rich eventing system designed for easy troubleshooting It should be possible to diagnose a problem by looking at the eventlog only The events are logged under the source name “MSExchangeDSAccess” and are divided into five categories:

“None”) It is easy to change the level for any category by launching Exchange System Manager, right-clicking on the server, selecting Properties and going to the “Diagnostics logging” tab When any Active Directory-related malfunction

is happening, it is a good idea to increase Configuration, Topology and LDAP

to Minimum or Maximum

Chart 3.1 contains a list of all new Exchange 2003 events

„ DSAccess reads updated registry values immediately, and then ignores all registry settings for 15 seconds It means that if you are inputting values slowly they may be partially read by DSAccess as you type, and the latest changes have been ignored (not forever, just for the next 15 seconds) However, if you wait 15 seconds before submitting the last change, you are guaranteed that all changes will be picked up immediately For this reason,

it is best to import a regfile, or even better: using the Directory Access tab

„ If Exchange System Manager cannot be launched (for example, if System Attendant service won’t start) logging levels can be changed directly in registry They are located in MsExchangeDSAccess\Diagnostics Logging regkey

Lesson 3: Changes in DSAccess

Although the behavior of DSAccess has not changed, its logging abilities have been greatly enhanced in Exchange 2003 This topic discusses the new event log entries logged by DSAccess, as well as its new performance monitor counters developed for Microsoft Operations Manager (MOM)

DSAccess includes the following new or modified eventlog entries A severity

“W” or “E” would indicate a warning or error event, respectively A level “7”

means that the event will only be logged if the highest diagnostics logging level

is set In contrast, a level “0” means that no diagnostics logging needs to be set before the event is written to the application event log There are three

categories in which new data appear:

General Category

Event ID Problem Event text: problem description and

actions required

Data in event Severity Level Periodic

2117 PID

Impersonated thread called into DSAccess

Impersonated account %3 is calling into DSAccess with the following callstack:

Callstack

W 7

New Events in DS

Access

Topology Category

Event ID Problem Event text: problem description and actions required Data in

event

Severity Level Periodic

DSC_EVENT_BAD_OS_VERSION The Domain Controller %3 is running %4 %5 DSAccess

requires that

Process name

2116 Domain Controllers that run Windows 2000 have at least

Service Pack 3 installed

is running Windows

The Configuration Domain Controller has been changed from … to …

New CDC name

2080 (Server name | Reachability | Synchronized | GC capable

| PDC | SACL right | Critical Data | Netlogon | OS Version)

PID

Every time DSAccess discovers servers, it dump the whole list

servers with suitabilities

Topology Discovery failed, error 0x%3

(0x%3) occurred when DNS was queried for the service

location (SRV) resource record used to locate a domain controller for domain %4%n%n

Error code

DNS server configured incorrectly

The query was for the SRV record for %5%n%n Domain

name

Common causes of this error include the following:%n%n DNS path

The DNS servers used by this computer contain incorrect

root hints

Addresses

of DNS servers used

This computer is configured to use DNS servers with

following IP addresses:%n%n%6%n

List of DNS zones

One or more of the following zones contains incorrect

DSC_EVENT_DNS_NAME_ERROR Error DNS_ERROR_RCODE_NAME_ERROR (0x%3)

occurred when DNS was queried for the service

Process name

2119 location (SRV) resource record used to locate a domain

controller for domain %4%n%n

PID

The query was for the SRV record for %5%n%n Error code

Common causes of this error include the following:%n%n Domain

name

The DNS SRV records required to locate a domain

controller for the domain are not registered in DNS

DNS path

These records are registered with a DNS server

automatically when a domain controller is added to a domain

Addresses

of DNS servers used

They are updated by the domain controller at set

intervals

List of DNS zones

This computer is configured to use DNS servers with

following IP addresses:%n%n%6%n

One or more of the following zones do not include

delegation to its child zone:%n%n%7%n%n

to DNS

hh tcpip.chm::/sag_DNS_tro_dcLocator_messageE.htm

DNS_EVENT_DNS_NO_ERROR DSAccess is unable to connect to any domain controller

in domain %3 although DNS was successfully queried for the service location

Process name

2121

DNS info for domain

is fine, but

we still can’t (SRV) resource record used to locate a domain controller PID

for that domain%n%n

The query was for the SRV record for %4%n%n Domain

name

The following domain controllers were identified by the

query:%n%n%5%n

DNS path

Common causes of this error include:%n%n List of DCs

Host (A) records that map the name of the domain

controller to its IP addresses are missing

or contain incorrect addresses.%n%n

Domain controllers registered in DNS are not connected

to the network, are not running or have Netlogon service stopped.%n%n

Process name

2123 The query was for the SRV record for %4%n%n PID

The following domain controllers were identified by the

query:%n%n%5%n

Error code

Common causes of this error include:%n%n DC name

- Host (A) records that map the name of the domain

controller to its IP addresses are missing or contain incorrect addresses.%n%n

DNS path

- Domain controllers registered in DNS are not connected

to the network, are not running, or have Netlogon service stopped %n%n

is in the DNS but

we can’t contact it

Process name

2124 The query was for the SRV record for %5%n%n PID

The following domain controllers were identified by the

is not in the DNS

Other domain controllers can be looked up - The DNS SRV records required to locate a domain DNS path

controller for the domain are not registered in DNS

These records are registered with a DNS server

automatically when a domain controller is added to a domain

This computer is configured to use DNS servers with

following IP addresses:%n%n%7%n

List of DNS zones

- One or more of the following zones do not include

delegation to its child zone:%n%n%8%n%n

2122 (SRV) resource record used to locate a domain controller

for domain %4%n%n

PID

The query was for the SRV record for %5%n%n Error code

For more information, type in the command line: Domain

name

DNS error occurred

hh tcpip.chm::/sag_DNS_tro_dcLocator_messageA.htm DNS path

DNS_EVENT_DNS_TIMEOUT Error ERROR_TIMEOUT (0x%3) occurred when DNS

was queried for the service location

Process name

2120 (SRV) resource record used to locate a domain controller

for domain %4%n%n

PID

The query was for the SRV record for %5%n%n Error code

The DNS servers used by this computer for name

resolution are not responding

Domain name

This computer is configured to use DNS servers with the

following IP addresses:%n%n%6%n

DNS path

Verify that this computer is connected to the network, that

these are the correct DNS server IP addresses,

Addresses

of DNS servers used

and that at least one of the DNS servers is

running.%n%n

List of DNS zones

DNS Query timed out

For more information on how to correct this problem, type

in the command line:

it previously didn’t have

2112 Domain Controller %4 This Domain Controller will not be

it previously had it)

Data in event Severity Level Periodic

DSC_EVENT_KERBEROS_TIMEOUT Received LDAP_SERVER_DOWN (0x51) from

Directory Server %3 due to

Process name

2111 Kerberos ticket timeout PID

Broken connection due to Kerberos ticket expiration (every 10 hours)

the connection needs to be closed and reopened;

does not necessarily mean that the target domain controller is having problems

W 3

Chart 3.1: DSAccess events new to Exchange 2003

Within the chart above, the only event log entries that are not new in Exchange

2003 are the 2080 and 2095 events The 2080 event is updated to show an additional field pertaining to the domain controller’s operating system version The updated 2095 now displays the previous “Config DC” name upon a change

DSADiag.exe tool no longer supported

The Exchange 2000 support tool, DSADiag, allowed Microsoft Product Support Services and customers to examine the list of suitable domain controllers chosen by DSAccess DSADiag no longer functions in Exchange 2003, as the global catalog and domain controller list will be empty What replaces this tool are the new monitoring and diagnostic events in the application event log, and the Directory Access tab that was introduced in the Exchange 2000 SP2 timeframe

To examine the list of working domain controllers and global catalogs and Config DC, one would use of the Directory Access tab in the System Manager snap-in

To examine the current suitability states, increase diagnostics logging for MSExchangeDSAccess (Toplogy Category), and examine the latest 2080 in the application event log Refer to chart 3.1’s “Topology” category section for details on these events

Customers may also utilize the exomatic.hta tool, which leverages the new WMI and monitoring providers in Exchange 2003 Although it doesn’t provide

as much information as the event logs out-of-the-box, it is very easy to execute the DSADiag-like WMI provider to obtain a quick glance of working domain controllers/global catalogs/Config DCs and their associated up/down/fast/in sync states fairly quickly

Although Exchange_DSAccessDC is the class to select within the exomatic.hta tool, the HTA also provides a complete list of other Exchange classes and properties that are new to Exchange 2003 Moreover, it has the added option to automatically generate scripts for you to integrate Exchange WMI access into your own programs Exomatic.hta is available from Microsoft Product Support Services

New DSAccess perfmon counters (207222)

New DSAccess counters allow Microsoft Operations Manager to monitor Active Directory domain controller health and Exchange topology changes The counters relevant to the directory topic are the new domain controller

latency/rate counters that may be used for domain controller troubleshooting These counter instances contain names of domain controllers for easy use Some of these counters present the information for the last minute, i.e this is per-minute-rate, and it is updated once a minute The sampling interval (1 minute by default) will be configurable in registry, so that we could tune granularity in place

DSAccess will allow monitoring of up to 64 domain controllers at a time

The domain controller name (as well as process name) is limited to 63 characters (it has to have fixed size) If the name is longer than that, it will be truncated

Note