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

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.


Module 7: Exchange Directory Components 1


Overview


For this module, we will discuss the new deployment features available with
Exchange Server 2003 and differentiate the deployment process from Exchange
2000.
Topic 1 Changes to the Active Directory Connector (ADC)
Topic 2 DSAccess Usage and Troubleshooting

Topic 3 DSAccess Changes
Topic 4 Other Directory Changes
Prerequisites
 Experience with troubleshooting ADC and DSAccess.
 Understanding of the ADCTools/Deployment Tools module
2 Module 7: Exchange Directory Components


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.
Module 7: Exchange Directory Components 3


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

4 Module 7: Exchange Directory Components


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.
Module 7: Exchange Directory Components 5


Exchange 2003 ADC upgrades “versionNumber” on connection
agreements


When the ADC is upgraded to the Exchange 2003 version, the ADC setup
program will not only upgrade the ADC binaries; it will also modify the
“versionNumber” attribute on any connection agreements owned by that ADC
service.
(To determine what connection agreements are owned by an ADC service, use
the Active Directory Connector Services snap-in, and highlight the ADC server
indicated by the name “Active Directory Connector (servername)” on the left-
hand pane. Its owned connection agreements will be viewable on the right hand
pane)
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:

6 Module 7: Exchange Directory Components


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.

Module 7: Exchange Directory Components 7


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 “-
8 Module 7: Exchange Directory Components


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
Module 7: Exchange Directory Components 9


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.
10 Module 7: Exchange Directory Components



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.

Module 7: Exchange Directory Components 11


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.
12 Module 7: Exchange Directory Components


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.

Module 7: Exchange Directory Components 13


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.)

14 Module 7: Exchange Directory Components


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.

Module 7: Exchange Directory Components 15



16 Module 7: Exchange Directory Components


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.
Module 7: Exchange Directory Components 17


What is DSAccess?


DSAccess is a common Exchange component used for interactions with Active
Directory. DSAccess is loaded by most Exchange processes:
 inetinfo.exe (or IIS worker processes in Exchange 2003)
 mad.exe
 store.exe
 winmgmt.exe
 emsmta.exe
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.
18 Module 7: Exchange Directory Components


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
Director
y
servers used
Topology

Module 7: Exchange Directory Components 19


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:
Property Value Meaning

Server name String DNS name of the domain controller
Roles 3 characters:

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
Reachability Bitmask 0-7 If bit 1 is set, then the server
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.
Synchronized Bitmask 0-7 Bitmask values are the same as
reachability, but it reports the
synchronization status of a server.
GC capable Boolean Value is 1 if the server is a valid
global catalog. Invalid if global
catalog is unreachable, in which case
value would be 0.
PDC Boolean Value is 1 if the server acts in the
primary domain controller (PDC)
20 Module 7: Exchange Directory Components

role (only if MinUserDCs regkey is
set)
SACL right Boolean Value is 1 if the Exchange server has
permission to read SACL on the
domain controller.
Critical Data Boolean Value is 1 if the domain
controllerhas the Exchange server
name in the “Microsoft Exchange”
container
Netlogon Bitmask 0-7 Bitmask values are the same as
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)
OS Version Boolean 1 if the operating system build is
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
Module 7: Exchange Directory Components 21


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.
22 Module 7: Exchange Directory Components

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).

Troubleshootin
g
Tip
Module 7: Exchange Directory Components 23


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
Try to correlate these errors in the log or other network events. 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,