Exchange Internals – How the Exchange

Core Components work together

Let’s begin
Exchange Server 2003 is a complex messaging system with several Exchange core
components and services which work together to provide an efficient email system.
Exchange Server 2003 highly depends on Microsoft Active Directory and a correctly
functioning DNS system but this is out of the scope of this article.

The following figure shows the Exchange Server 2003 core services, but there are more
Exchange related services like:

• WWW Publishing Service

• SMTP Service
• IIS Admin Service
• Windows Management Instrumentation...

Figure 1: Exchange core services

Please note:
The Microsoft Exchange Quota Service, the Microsoft Identity Integration Server and the
Microsoft iSCSI Initiator Service in Figure 1 are not Exchange related.

Service dependencies
Most of the Exchange services have dependencies from other Exchange services. We are
talking here about other services that depend on this specific service and about other
services from which this service is dependent. You can see the dependencies in the
properties of the specific service or in the Registry under
HKEY_LOCAL_MACHINESystemCurrentControlSet\Services\Servicename.

The following figure shows the Dependencies of the Microsoft Exchange System
Attendant Service, one of the Exchange Server core services. The Microsoft Exchange
System Attendant Services depends on the Services shown in Figure 2 and two other
services – Microsoft Exchange Information Store and Microsoft Exchange MTA Stacks.

Figure 2: Exchange Service Dependencies

Web Services and Exchange 2003

Exchange 2003 uses the Windows Server 2003 Internet Information Services
Infrastructure for several Exchange Services like Outlook Web Access (OWA), Outlook
Mobile Access (OMA) and services like POP3, IMAP4 and SMTP and extends several
services and functions with special Exchange functions.

As you can see in Figure 3, Exchange uses some IIS Application pools and messaging
services like SMTPSVC and IMAPSVC under control of INETINFO.EXE. All services
are controlled by HTTP.SYS, a kernel Mode component which is new for IIS 6.0.
Figure 3: Web Services in Exchange Server 2003 (Source: Microsoft)

As you can see in Figure 4 there are several dependencies between Exchange Services
and Windows Services. As an example, the Microsoft Exchange System Attendant
depends on several Windows Services but also some Exchange Services are dependant on
the Exchange System Attendant Service.

Figure 4: Exchange and Windows Service Dependencies (Source: Microsoft)

The big picture – All Exchange Services working

together
The following figure gives you a good overview of all Exchange Services and how they
work together. As you can see there are layered services, all under the control of IIS 6.0
which traffic flows through the Exchange Store Driver (DRVIIS.DLL) and the Exchange
Epoxy Service – explained later in this article. The Exchange Store (Store.exe) then gives
these clients and services Access to the Exchange Databases through the ESE (Extensible
Storage Engine).

Figure 5: Exchange Services working together (Source: Microsoft)

EXIFS
The Exchange Server 2003 installable file system is a kernel-mode driver, implemented
in ExIFS.sys, which IIS can use to read and write items from and to Exchange databases.
The ExIFS file system driver communicates with the Exchange Server store. This is
accomplished through a store extension (ExWin32.Dll) and a user-mode wrapper
(Ifsproxy.dll). The Exchange Server store uses ESE to access the Exchange Database
(ESE and STM files).

Please note:
ExIFS is the only kernel-mode component in Exchange Server 2003.
Figure 6: ExIFS in Exchange 2003 (Source: Microsoft)

The biggest Picture – How they all work together

The following figure is too complex to explain every service and it’s dependencies in this
article but it is a great figure to show you how all of these services wok together. You
should spend some time to understand this figure.

Figure 7: All Exchange and Windows Services Hand in Hand

System Attendant
The Microsoft Exchange Server System Attendant is the Exchange Server core service
which controls several other Exchange services. These components are:

• DSAccess (DSAccess.dll) – Provides Exchange Active Directory Access

• DSProxy (DSProxy.dll) – Provides Directory Service Lookup for older Outlook
clients
• Server Monitor Component - Monitoring server resources
• Free/Busy Component (Madfb.dll) – Manages Free/Busy information
• Mailbox Manager Component - Managing mailboxes
• metabase
• Metabase update service - Replicating settings from Active Directory to the IIS
metabase
• Metabase update service - Replicating settings from Active Directory to the IIS
• Recipient Update Service - Applying recipient policies and generating proxy
addresses
• System Attendant Component - Verifies computer account configuration

DSProxy
The Directory Service Proxy (DSProxy) is the Exchange Server 2003 component that
provides an address book service to Microsoft Outlook clients. DSProxy is implemented
in DSProxy.dll. DSProxy has two functions:

• Emulate a MAPI address book service

• Proxy requests to an Active Directory server

DSProxy provides both proxy and referral services. MAPI clients running Outlook 2002
Service Release 1 and earlier versions use the proxy functionality because these clients
were designed to use Exchange Server as its Directory Service. This was true for
Microsoft Exchange Server from 4.0 to 5.5 but beginning with Exchange Server 2000,
Microsoft Active Directory takes the part of the Exchange Directory services. Therefore,
DSProxy emulates a directory service, so that earlier clients can function.
Exchange Server 2003 server forwards the requests to Active Directory.

Later versions of Outlook, such as Outlook 2000 with SR-2 and Outlook 2002/2003, are
designed with the assumption that Exchange Server 2003 does not have its own directory
service. After DSProxy refers one of these later clients to a global catalog server, the
client communicates directly with Active Directory.

DSProxy obtains its list of working global catalog servers from DSAccess. DSAccess
handles only LDAP queries. However, DSProxy fully relies on DSAccess to provide
global catalog failover support.

DSProxy Operations
DSProxy performs the following operations:

It collects a list of working global catalog Servers from DSAccess and selects only global
catalog Servers that are in the Server's local Active Directory site.

It proxies MAPI queries from earlier Outlook clients to the remaining global catalog
Servers. The mechanism used to direct Outlook clients to one of the remaining global
catalog Servers is a round robin mechanism.

DSProxy initially runs single threaded and can support up to 512 client connections.
DSProxy automatically creates an additional thread for every 512 client connections.
Unlike DSAccess, DSProxy has no caching mechanism. Every MAPI query processed
through DSProxy is sent to a Global Catalog Server.

DSAccess
Exchange 2003 services access information that is stored in Active Directory and write
information to Active Directory. If this communication occurred directly between each
service and Active Directory, Exchange 2003 could overwhelm an Active Directory
domain controller with communication requests. DSAccess is the component which
controls the interaction between Exchange requests and Active Directory.

DSAccess is a shared API that is used by multiple components in Exchange 2003 to

query Active Directory and obtain both configuration and recipient information.
DSAccess is implemented in DSAccess.dll, which is loaded by both Exchange and non-
Exchange components. The components are:

• System Attendant
• Message Transfer Agent (MTA)
• Microsoft Exchange Information Store
• Exchange Management Service
• Internet Information Services (IIS)
• Windows Management Instrumentation (WMI)

DSAccess discovers the Active Directory topology, detects domain controllers and
Global Catalog servers, and maintains a list of valid directory servers that are suitable for
use by Exchange components. In addition, DSAccess maintains a cache that is used to
minimize the load on Active Directory by reducing the number of Lightweight Directory
Access Protocol (LDAP) requests that individual components send to Active Directory
servers. The DSAccess Cache is configurable through several Registry Keys.

RUS – Recipient Update Service

The Exchange Recipient Update Service is the Exchange component which is responsible
for managing the Exchange Server Proxy E-Mail addresses and for creating and updating
e-mail addresses for Exchange Server recipients and Exchange core components. There is
one RUS service in every domain where Exchange is installed and one Exchange
Recipient Update Service for the Enterprise Configuration (the whole Exchange
Organization).

DS2MB – Directory Service to Metabase

The function of DS2MB is to replicate configuration information from Active Directory
to the local IIS metabase.

DS2MB is implemented as a process in DS2MB.dll and the primary function is to

synchronize several Exchange configuration settings in Active Directory with its
counterpart settings in the IIS metabase. The DS2MB is a unidirectional process. Only
from Active Directory to the IIS Metabase. You can view the IIS Metabase with the
Metabase Explorer from the IIS 6 Resource Kit and some other tools.

The metabase update is a subprocess that is launched when the System Attendant is
started. The operation of SMTP, POP3, IMAP4, Outlook Web Access and OMA are all
dependent on the replication by DS2MB. DS2MB registers with the config domain
controller after startup, enabling the config domain controller to notify DS2MB of any
changes that are made to the Exchange configuration. This notification occurs within 15
seconds of the change.

Microsoft Exchange MTA Stacks service

(EMSMTA.exe)
The Microsoft Exchange MTA Stacks service (MTA) routes messages through X.400 and
gateway connectors to non-Exchange messaging systems. In a mixed environment with
servers running Exchange Server 5.5 in the local routing group, the MTA is also used to
transfer messages between Exchange Server 2003 and Exchange Server 5.5. This occurs
because Exchange Server 5.5 MTAs communicate with each other in the local site
directly through RPCs. Exchange Server 2003 must rely on this communication method
for backward compatibility.

The executable file of the Microsoft Exchange MTA Stacks service is EMSMTA.exe,
which is located in the \Program Files\Exchsrvr\bin directory. This service depends on
System Attendant and maintains its own specific message queues outside the Exchange
store in the \Program Files\Exchsrvr\Mtadata directory.

The registry key is HKEY_LOCAL_MACHINE

\System\CurrentControlSet\Services\MSExchangeMTA

Routing Engine (RESvc.dll)

The Exchange Routing Engine service provides topology and routing information to
servers running Exchange Server 2003. The advanced queuing engine (AQE) within the
SMTP transport subsystem uses this service to provide next-hop information when
routing messages within the Exchange organization. The Exchange Routing Engine
service depends on the IIS Admin service and runs within the Inetinfo.exe process. This
service is implemented in a file called RESvc.dll, which is palced in the \Program
Files\Exchsrvr\Bin directory.

The registry key is

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\RESvc

IIS Admin service

The IIS Admin service (IIS Admin) manages the IIS Metabase and updates the registry
for the following services:

• WWW service
• FTP service
• SMTP service
• POP3 service
• IMAP4 service
• NNTP service

The IIS Admin service also provides access to the IIS configuration information to other
applications, such as to the metabase update service, which is an internal component of
System Attendant.

The registry key for the IIS Admin service is

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\IISAdmin.

The IIS Admin service depends on the Remote Procedure Call (RPC) service and
Security Accounts Manager (SAM) service.

Conclusion
In this article I have tried to give you some helpful information about the Exchange
Server core services and how they work together. This article can’t give you all
the information about the “Big Picture” from Exchange Server and all its components.
There are quite more dependencies and Services in Exchange Server 2003 and the
dependency from Exchange Server 2003 on Windows Server Active Directory and DNS
(Domain Name System) which I don’t explain in my article.

What is Forestprep and Domainprep

Before installing Microsoft Exchange 2003 Server, you must prepare your Windows
2003 forest. The Microsoft Active Directory Schema must be extended to save Exchange
2003 attributes and claases and permissions must be granted to the user or group who will
be installing the first Exchange 2003 server in the forest. In every domain that will host
either an Exchange 2003 server or mail-enabled users, two security groups must be
created.

These security groups are used to perform administrative functions when the Exchange
team members are different from the Windows team member – which is normal in larger
enterprises – but later.

The Exchange 2003 Server CD contains two Setup Switches to accomplish these tasks:

• ForestPrep and
• DomainPrep.

When you use the /ForestPrep option, the Exchange Setup program extends the Active
Directory schema to add Exchange-specific classes and attributes.

ForestPrep also creates the container object for the Exchange 2003 organization in the
domain naming context of Active Directory, and it assigns, to the account that you
specify, Exchange Full Administrative permissions to the organization object.

This account now has the authority to install and manage Exchange 2003 throughout the
forest, along with the authority to assign other administrators Exchange Full
Administrative permissions after the first Exchange server is installed.

Requirements

• Forest wide permissions to manage Active Directory

• Member of the Enterprise Administrators and Schema Administrators groups
• Member of the local Administrators group

Why Do You Need ForestPrep and DomainPrep?

Larger organizations do not want their messaging administrator team to have high-level
domain or enterprise rights because these tasks will be done by experienced Windows
Administrators

It is common for Exchange administrators to be in a separate team from the Windows /

Active Directory Administration team.

For organizations that don’t have a structure like this stated, ForestPrep and DomainPrep
separates the Exchange 2003 setup tasks that require high-level network permissions
from those that do not.
For example, Windows 2003 administrators with EnterpriseAdmin and SchemaAdmin
permissions run ForestPrep, during which they designate an account as the Exchange
2003 administrator. This Exchange administrator will have enough rights (after both
utilities are run) to perform the actual Exchange 2003 installation.

Note:
If the user who installs Exchange is a member of the EnterpriseAdmin and
SchemaAdmin groups, Forestprep and Domainprep will be automatically executed.

Most deployment scenarios require you to run ForestPrep for successful Exchange 2003
installation. As a general formula keep in mind that when the administrator doesn’t have
EnterpriseAdmin and SchemaAdmin permissions, you must run ForestPrep.

When you install Exchange 2003 in a child domain, you must first run ForestPrep in the
parent domain. If you don’t do this, Setup will prompt you to do so when you attempt to
install in the child domain.

ForestPrep in detail
ForestPrep performs all Exchange 2003 setup tasks that require EnterpriseAdmin and
SchemaAdmin permissions, as it makes changes in the configuration naming container in
Active Directory. ForestPrep extends your Active Directory schema to include Exchange-
specific information. ForestPrep also creates objects in Active Directory and gives
permissions on those objects to the account designated as the Exchange 2003
administrator. This administrator will have enough permission to install the first
Exchange 2003 server in your organization.

ForestPrep also creates the Exchange organization name and object in Active Directory.
New in Exchange 2003 Forestprep is the creation of a placeholder Organization object.
Setup will create a “temporary” organization with a hard-coded name. (That name is a
GUID: “{335A1087-5131-4D45-BE3E-3C6C7F76F5EC}”.) Setup can delegate the first
Exchange administrator on this object; create the Exchange configuration underneath it,
and so on. Later, when setup is run to install the first server in the organization – by
someone who is an Exchange administrator – setup can rename the existing placeholder
object, either to a user-specified name or to match the name of an Exchange 5.5
organization. The final naming is decided by the answer to the “Installation Type” screen.

You need to run ForestPrep only once per Windows 2003 forest.

Be sure to type the command exactly as in Figure1 because a wrong typed command will
start a normal Exchange setup without the /Forestprep option.
Figure 1: SETUP /FORESTPREP

Important
After ForestPrep and DomainPrep are run, the designated Exchange administrator has
only enough permission to install Exchange. By default, this account is not able to create
accounts or give users mailboxes unless this account is also a member of the Account
Operators group.

You can grant administrators permissions to create and administer Windows accounts
within your Exchange organization by making them Account Operators or by using the
following two methods. Both methods use the Active Directory Users and Computers
snap-in. The first is to run the Windows 2003 Delegation of Control Wizard and grant
your Exchange administrator control of the Users container. The second is to create a
new group specifically for Exchange users within the Users container and grant the
Exchange administrator full control of that new group.

You need to gather the following information before running this utility. ForestPrep
prompts for different information depending on whether you are installing a new
Exchange 2003 organization or joining an existing Exchange 5.5 organization.

New Installation

For a new installation of Exchange 2003 Server, the network administrator needs to have
the following information before running ForestPrep:

• The name of the Exchange 2003 organization

• The account of the person or group who will install the first Exchange 2003 server
in your organization

Note:
Once Exchange is installed, this person or group is able to create other Exchange
administrators by using the Exchange Administration Delegation Wizard.

Graphical Setup mode of Forestprep

Figure 2: Graphical Forestprep option

When Is It Unnecessary to Run ForestPrep?

You should run ForestPrep before installing your first Exchange 2003 server—regardless
of your organization’s topology. However, there are some scenarios (such as in a small
business) in which ForestPrep might not be required.

ForestPrep and DomainPrep both run automatically during Setup, but only if the
Exchange administrator account is a member of the SchemaAdmin and EnterpriseAdmin
groups and if the first Exchange 2003 server installation takes place in the same domain
as the Schema Master.

When this is the case, you do not need to manually execute either utility. By default, the
account with which you have logged on becomes the designated Exchange 2003
administrator.

Allow Time for Replication

After you run ForestPrep, be sure to allow enough time for the schema extensions to
replicate throughout all the domains and sub-domains in your organization. Depending on
the geography of your organization and the speed of your network connections between
Windows 2003 sites or domains, this could take some time. You should run DomainPrep
only after you’re sure that the Exchange-specific information has been replicated across
your organization.

DomainPrep in detail
The DomainPrep utility performs the Exchange setup tasks that require DomainAdmin
permissions; it should be run by a member of the DomainAdmin group. You need to run
DomainPrep once in each domain that contains an Exchange 2003 server and in any
domain that hosts Exchange users. These are domains without Exchange servers but with
mail enabled users. Domainprep is necessary for the recipient update service (RUS) and
to create the groups and permissions necessary for Exchange servers to read and modify
user attributes.

DomainPrep creates two new domain groups: Exchange Domain Servers (a Windows
2003 global security group) and Exchange Enterprise Servers (a Windows 2003 domain
local security group).

DomainPrep also creates the Public Folder proxy container in Active Directory. While
ForestPrep works in the forest-wide configuration naming container, the Public Folder
object (a Microsoft Exchange System Object) exists outside this container (this is the
reason why you can’t see public folders with ADSIEDIT, LDP or other LDAP tools).
DomainPrep creates this object on a per-domain basis, under the domain container.

Exchange Domain Servers Group

The Exchange Domain Servers global security group contains the computer accounts of
all Exchange servers in the domain. Though it is created by DomainPrep, the Exchange
Domain Servers group is not populated until the actual installation of Exchange 2003.

The Exchange Domain Servers group is necessary for the Recipient Update Service,
which is needed in every domain of your Exchange organization. This includes user
domains, which do not contain Exchange servers but do have mail-enabled users.
Recipient Update Service is used by Exchange to generate and update default and
customized address lists and to process changes made to recipient policies.

Exchange Enterprise Servers Group

The Exchange Enterprise Servers group (a domain local group type) contains every
Exchange Domain Servers group (a domain local group type) in your organization. In
other words, every domain with an Exchange server, along with every domain in which
DomainPrep has been run and that has an active Recipient Update Service, belongs to the
Exchange Enterprise Servers group.

This group is populated immediately when DomainPrep adds the Exchange Domain
Servers group from the current domain to it. Recipient Update Service adds the Exchange
Domain Servers groups from all other domains that have an active Recipient Update
Service.

You must meet the following requirements before you run DomainPrep:
 • The account that runs DomainPrep must belong to the domain’s DomainAdmin
group.
• ForestPrep must have already been run in your Windows 2003 forest.
• The schema extensions made by ForestPrep to Active Directory must have
already replicated throughout your organization.

When is it unnecessary to Run DomainPrep?

DomainPrep should be executed before installing the first Exchange 2003 server.
DomainPrep is not necessary when:

• The account that is installing the first Exchange 2003 server in the domain is an
Exchange Full Administrator and a member of the DomainAdmins group
• The person who is installing Exchange has EnterpriseAdmin permissions.

In both scenarios, DomainPrep runs automatically as a hidden process during the

Exchange 2003 setup.

When must you Run DomainPrep?

For DomainPrep to work correctly, you must run it:

• After running ForestPrep, and after all ForestPrep changes are replicated
throughout the forest.
• Before the through Forestprep designated Exchange 2003 administrator can install
the first Exchange 2003 server in the domain.
• Whenever you must create a Recipient Update Service (RUS) for a domain with
mail-enabled users.
• It is also necessary to run Domainprep in an empty Forest Root Domain because
RUS must use it.

Active Directory Connector (ADC)

ADC, first introduced in Exchange 2003, updates the Active Directory Schema during
installation, regardless if the Active Directory was updated through the Exchange 2003
Forestprep and Domainprep process.

The Exchange 2003 version of ADC uses the same schema extensions as Exchange 2003.
So if you install ADC, the setup process updates the Active Directory Schema so you
don’t need to update the Schema with Exchange 2003 Forestprep and vica verse.

How to see if FORESTPREP and DOMAINPREP were

successful
In Exchange 2000 you have to use tools like ADSIEDIT to see if FORESTPREP and
DOMAINPREP were successfully.

With Exchange 2003 you can use the ORGPREPCHECK switch from the EXDEPLOY
tools.

ORGPREPCHECK

Run ORGPREPCHECK at a command prompt

CD-ROM_Drive_Letter:\support\exdeploy\exdeploy.exe /gc:global catalog server name

/t:orgprepcheck

View the EXDEPLOY.LOG file in C:\EXDEPLOY LOGS to see if the setup /forestprep
command and the setup /domainprep command have completed successfully.

Figure 3: EXDEPLOY /ORGPREPCHK Switch

ORGPREPCHECK verifies the Exchange extensions to the Active Directory Schema, the
existence and membership of the Exchange Domain Servers group and Exchange
Enterprise Servers Group and checks that a global catalog Server is available in a domain
in which DOMAINPREP has been run. The result is displayed in the EXDEPLOY.LOG
file.
Figure 4: EXDEPLOY.LOG file

Conclusion
As you have seen in this article, FORESTPREP and DOMAINPREP are not so mystical
when you understand the basics. FORESTPREP and DOMAINPREP are necessary
components to update the Active Directory Schema to support Exchange 2000 / 2003.

Please keep in mind that Forestprep updates the Windows 2003 Active Directory Schema
and ALL this information must be replicated to all Domain Controllers in the Forest.

What is the ADC?

The task of the ADC is to replicate directory information (such as mailboxes, users and
groups) between the Exchange 5.5 directory and Active Directory.

The ADC service itself relies on the administrator to define connection agreements.
These agreements name the servers involved in the replication cycle, which direction to
replicate, which objects to replicate, and when to replicate the data.

The ADC uses LDAP to contact both the Exchange 5.5 and Active Directory. LDAP
works efficiently over all types of network links, regardless of whether the connection is
fast, slow, or high latency.
Figure 1: ADC wizard

With the help of the ADC, you can create the following CA (Connection Agreement):

• Recipient Connection Agreement

• Public Folder Connection Agreement

Recipient Connection Agreement

The Recipient Connection Agreement creates a connector to replicate mailbox

information, distribution lists and custom recipients from Exchange 5.5 to Active
Directory.

Public Folder Connection Agreement

The Public Folder Connection Agreement creates a connector to replicate Public Folder
information (not the content of Public Folders) from Exchange 5.5 to Active Directory.

It is important to know that the Recipient Connection Agreement and Public Folder
Connection Agreement don’t replicate the content of Public Folders and Mailboxes.

Organizations deploy Active Directory Connector (ADC) for four main reasons:

• To replicate Microsoft Exchange directory information (from DIR.EDB) to

Microsoft Active Directory (NTDS)
• To replicate existing Microsoft Exchange Server version 5.5 directory data to
Active Directory so that third-party applications can take advantage of it.
• To replicate directory information between Active Directory and the Exchange
directory for coexistence from one management application.
• To deploy Exchange 2003 Server in an existing Exchange 5.5 environment for
consolidation and migration purposes.

Versions of ADC
The basic replication functionality of ADC is included with Windows 2000. However,
when you install Exchange 2000, an update is installed.

Windows 2000 ADC

The Windows 2000 ADC, which is included with Windows 2000, replicates directory
information in Exchange 5.5 to Active Directory and vice versa. Through
synchronization, the administrator can perform basic management functions for
Exchange 5.5 users. The Windows 2000 ADC can only replicate the site naming context.
It will synchronize additions or modifications on Exchange 5.5 mailboxes, distributions
lists, and custom recipients.

Exchange 2000 Server ADC Update

The Exchange 2000 Server ADC update is an enhanced connector included with
Exchange 2000. The Windows 2000 ADC replicates objects in the Exchange site-naming
context to Active Directory, the Exchange 2000 ADC also replicates data from the
configuration naming context,

Exchange 2000 ADC Service Packs

Exchange 2000 Service Pack 1 and Service Pack 2 include an update to Active Directory
Connector. Both Updates includes basic functionality as the RTM version but have some
additional features.

Exchange Server 2003 ADC

The Exchange 2003 ADC is included on the Exchange 2003 CD. It has many
improvments from his predecessor. The most used features are the ADC tools which
gives an Administrator a grahically Wizard for every Step in the ADC deployment
process. I will explain the ADC tools later in this article.

Exchange Server 2003 SP1 ADC

Microsoft Exchange Server 2003 Service Pack 1 (SP1) introduces changes to ADC
Tools. These changes provide better control over the Connection Agreements. These
changes include the ability to start initial replication after you have reviewed the
Connection Agreements.

In the updated ADC Tools, there are two new files that you can use to control Connection
Agreement settings. The files are named …

• Ca_defaults.xml and
• Activate_cas.vbs.
The new ADC Tools functionality is especially useful for large, complicated Exchange
environments. With the Ca_defaults.xml file, you can configure the default settings that
the Connection Agreement Wizard will use when it creates the Connection Agreements.
This gives you the chance to review the new Connection Agreements before they are in
use. After you confirm that the settings are correct, you can use the Activate_cas.vbs file
to change the Connection Agreement schedule to "Always."

The Ca_defaults.xml file and the Activate_cas.vbs file are located in the folder where you
installed the Exchange Server 2003 SP1 ADC.

Initial ADC Installation

When you first install an ADC in a Windows 2003 forest, the ADC Setup program
extends the Active Directory schema with the Exchange 2003 schema extensions.

To do this, the account that you are running Setup from must belong to a member of the
Schema Administrators group or otherwise have permissions to extend the schema.

Note:
Microsoft has changed the Active Directory Schema expansion in Exchange 2003 / ADC
so that both versions use the same Schema. This reduces the replication workload
because the schema has to be extended once.

The ADC Setup creates objects in the Active Directory Configuration container. This
requires that the Administrator who installs ADC belongs to the Enterprise
Administrators group. This permission is a prerequisite of the ADC installation process
and Setup cannot succeed without it.

ADC Setup creates two security groups in the local domain called "Exchange Services".
This requires that the account you are running Setup from belongs to a member of the
Domain Administrators Group or has permissions to create objects in the Users container.
If you delete these groups, you have to reinstall ADC.

If you install additional ADC instances, the schema doesn’t need to be extended and so
the account must not be a member of the Schema Administrator group.

Subsequent installations do require either Domain Administrator permissions or other

specific permissions that allow you to create new objects under the Sites and Services
containers in the configuration naming context.

Additional installations in the same domain do not require the creation of either the
Exchange Services or the Exchange Administrators groups. The first ADC installation
into any other Windows 2003 Server domain requires the creation of these groups and
subsequently the proper permissions.
ADC Tools
ADC Tools are available in the Active Directory Connector Services console. ADC Tools
help you correct resource mailbox problems, create connection agreements, and verify
replication between the Exchange 5.5 directory and Active Directory. ADC Tools consist
of the following tools and wizards:

Step 1:
Tool Settings allows you to set the Exchange 5.5 server, LDAP port, and log file path for
ADC Tools. The account you use to run this step must have the View Only Admin role
assigned at the local Exchange 5.5 site level.

Step 2:
Data Collection scans your Exchange 5.5 directory and Active Directory and gathers data
for use in subsequent steps. The account you use to run this step must be a member of the
Domain Administrators group in Active Directory. In addition, the account must have the
View Only Admin role assigned at the local Exchange 5.5 site level.

Step 3:
Resource Mailbox Wizard allows you to match Active Directory accounts to the
appropriate primary mailboxes and stamp other mailboxes with the NTDSNoMatch
attribute, which designates the mailboxes as resource mailboxes. The account you use to
run this step must have the Admin role assigned at the Exchange 5.5 site level for all
Exchange 5.5 sites that contain resource mailboxes.

Step 4:
Connection Agreement Wizard recommends connection agreements based on object
matching data collected in step 1. You can review the list of recommended connection
agreements and select those you want the wizard to create. The account you use to run
this step must be a member of the Domain Administrators group in Active Directory.
Figure 2: ADC Tools

Important
To check the version of your ADC server, open the Active Directory Connector
Microsoft Management Console MMC. Click 'About Active Directory Connector' under
the Help menu on each Active Directory Connector Management Console. This will
show you the version of the ADC on the machine.

To check the version of all the Active Directory Connectors (ADC) in your organization,
use either the LDP tool or the ADSI tool to find the "versionNumber" attribute on the
ADC servers in Active Directory. The versionNumber attribute should be 16973843 or
greater for Exchange 2003 Service Pack 1.

Exchange 2003 Deployment Wizard

Exchange 2003 has a nice Deployment Wizard to deploy Exchange 2003 into an existing
Exchange 5.5 organization. The wizards guides you through every step (includes ADC
creation) which is neccessary to deploy Exchange 2003.
Figure 3: Exchange Deployment Tools wizard

ADC Tools Log File

ADC creates a log file called ADCTOOLS.LOG for advanced troubleshooting purposes.

The ADCTOOLS.LOG file is generated when you run ADC Tools in Active Directory
Connector. The ADCTOOLS.LOG file is saved in the directory you specify when you
run the ADC Tools.

Most of the messages that appear in the ADCTOOLS.LOG file also displays in the
Information box in ADC Tools.

Connection Agreements
Installing ADC on a server defines a service within Windows 2003. To create a
replication agreement between an existing Exchange 5.5 site (named Routing Group in
Exchange 2000/2003) and Active Directory, you must configure a connection agreement.
The connection agreement holds information, such as the server names to contact for
replication (Windows 2003 and Exchnage 5.5), object classes to replicate, target
containers in Active Directory, and the replication schedule.

It is possible to define multiple connection agreements on a single ADC server, each of

which can go from Active Directory to a single Exchange site or to multiple Exchange
sites. For optimal performance, it is recommended that each ADC server manages no
more than 50 to 75 connection agreements, depending on the specifications of the
computer and the number of objects in each directory.

In large environments it is possible to deploy multiple ADC servers to improve

performance and to optimize replication traffic through the placement of ADC servers
near the location of Exchange servers and domain controllers.
Figure 4: One Way ADC connection agreement

Figure 5: One example of the ADC wizard

Deactivated Users in the Active Directory Users and

Computers SnapIn (MSExchangeMasterAccountSID)
ADC creates disabled Active Directory users. If the account is disabled, the Exchange
information store will look for an msExchangeMasterAccountSid attribute. If it sees that
attribute, it will use that SID (the NT4 account SID) as the account that it will verify,
authenticate the user, and grant them access.

Sometimes when users are unable to get into their mailboxes after their mailboxes have
been migrated, administrators will notice that there is a disabled mailbox-enabled user in
the Active Directory. When they activate this account the
msExchangeUserAccountControl value will be set to 0, which means that that user has
been enabled, and that it should not look at the msExchangeMasterAccountSid - it looks
for an Active Directory SID. Because this users belong to an NT4 domain (the object in
AD is only a place holder object), they don't have an Active Directory SID. Therefore,
when they try to access their mailbox on Exchange 5.5 the access will be denied.
ADCGlobalName and msExchADCGlobalNames
The ADC uses the ADCGlobalName mechanism to keep track of which objects in
Microsoft Exchange Server 5.5 are matched to which objects in Active Directory. The
ADC marks objects with ADCGlobalNames so that when the ADC wants to replicate
changes from a source object to its target object, it can faster determine which object
should be replicated to the target directory.

The ADCGlobalNames attribute has multiple values and contains a unique name for the
object in each directory. For Exchange Server 5.5 directory, this name is the DN of the
object combined with the object's objectclass attribute. For Active Directory, ADC uses
the ObjectGUID attribute. The ADCGlobalNames attribute also contains a value that
uniquely identifies the Exchange organization or Active Directory Forest that the object
comes from.

The LDAP attribute that is used in the Exchange Server 5.5 directory and Active
Directory is the msExchADCGlobalNames attribute. If you use the Exchange 5.5
Administrator program in Raw mode (Admin.exe /r) to view the Exchange Server 5.5
directory, the attribute is displayed as ADC-Global-Names.

Inter-Organization Connection Agreement

You can set the inter-organization connection agreement option on the Advanced tab of a
ADC connection agreement properties sheet. This option allows Microsoft Exchange
Server version 5.5 and Microsoft Exchange 2003 servers that are in two separate
Exchange organizations to replicate directory information. The inter-organization option
doesn't handle how objects are created; it only handles how proxies are generated. If the
inter-organization option is not selected, ADC does not:

• Match Custom Recipients to a mailbox enabled user.

• Stamp msExchMasterAccountSID or legacyExchangeDN.
• Matches a mailbox to a user that is only mail enabled.
Figure 6: Checkbox to make this ADC connection to an Inter-Organizational Connection
Agreement

Server Resources Consumed by ADC

Depending on the replication time set and the number of objects changed, the server on
which ADC is running and the other directory servers it interacts with may need to
process large amounts of data.

For network connectivity it is recommended to deploy ADC in a LAN environment and

not over slow WAN links.

When the ADC is working the Threads consume roughly 50 percent of the CPU. This
consumption level is constant until all replication is complete. However, the load placed
on the CPUs of the computers running the directories is relatively low by comparison.

The memory consumption of ADC is about 6 MB + 2 MB per connection agreement.

Conclusion
The ADC is a powerful tool to implement a directory connector to replicate directory
information between Exchange 5.5 and Exchange 2003. The ADC is a must have when
you want to migrate from Exchange 5.5 to Exchange 2003.

The ADC is a complex process that requires a deep knowledge of the functions by the
Exchange and Windows administrators.
Exchange Server 2003 Active Directory Integration

Topic Last Modified: 2006-03-09

This article provides a brief description of Active Directory® directory service

integration in Microsoft® Exchange Server. The source for the content of this article is
the Microsoft Exchange Server 2003 Technical Reference Guide.

• Exchange Classes and Attributes in Active Directory

• Directory Service Access
o Domain Controllers, Global Catalogs, and Configuration Domain
Controllers
o LDAP Connection Load Balancing and Failover
o DSAccess Topology Discovery
o Initial Discovery and Ongoing Rediscovery Suitability Tests
• For More Information

Exchange Classes and Attributes in Active Directory

The Active Directory schema defines the object classes that can be created in the
directory and the attributes that can be assigned to each instantiation of an object. During
installation of the first server running Exchange Server 2003 in an Active Directory
forest, Exchange must modify this schema so that Active Directory can store Exchange-
specific recipient and configuration information. The ForestPrep process in the Exchange
Setup program extends the Active Directory schema. You can also run this process
explicitly by typing Setup /ForestPrep at a command prompt to add Exchange-specific
classes and attributes to the Active Directory schema, without actually installing a server.
This extra step is required if the person installing Exchange Server 2003 does not have
schema administrator rights.

The Exchange Server 2003 Setup program extends the Active Directory schema by
importing a series of .ldf files into Active Directory. With the exception of Exschema.ldf,
all .ldf files are in the \Setup\i386\Exchange directory on the product CD. Exschema.ldf
is in the \Setup\i386\Exchange\Bin directory.

The following table lists the Exchange Server 2003 installation files with Active
Directory schema extensions with their descriptions.

File name Description

Includes schema extensions for recipient objects, such as the definition of
Exchange extension attributes, which you can use to assign information,
Schema0.ldf
which is not covered by any one of the standard attributes, to recipient
objects.
Schema1.ldf Includes schema extensions for Active Directory Connector, which you
 can use to integrate an Exchange Server version 5.5 organization with
Active Directory.
Includes schema extensions for Internet access protocols, directory
Schema2.ldf
synchronization, and Exchange store configuration objects.
Includes schema extensions for system monitoring, Connector for Lotus
Schema3.ldf Notes configuration objects, offline address book settings, and settings that
belong to X.400 connectors.
Includes schema extensions for routing groups, bridgehead servers,
Schema4.ldf protocol containers, messaging databases, address list services, and
Microsoft Exchange message transfer agent (MTA) configuration objects.
Includes schema extensions for protocol containers, routing group
Schema5.ldf connectors, and parameters that pertain to Extensible Storage Engine
(ESE).
Includes schema extensions for protocol virtual servers, administrative
Schema6.ldf
groups, messaging connectors, and the Exchange store.
Includes schema extensions for messaging databases and mailbox
Schema7.ldf
manager.
Includes schema extensions for mailbox manager, system monitoring,
Schema8.ldf public folders, and Simple Mail Transfer Protocol (SMTP) transport
configuration objects.
Includes schema extensions for Calendar Connector, Connector for Novell
GroupWise, dynamic distribution lists, messaging folders, and Microsoft
Outlook® Mobile Access.

Schema9.ldf Note:
Schema1.ldf through Schema8.ldf are identical for Exchange Server 2003
and Exchange 2000 Server. Schema9.ldf contains the schema extensions
that are new in Exchange Server 2003.
Adds the Object-GUID, Replication-Signature, Unmerged-Attributes, and
ADC-Global-Names attributes to the schema to update a schema for
Exschema.ldf
versions of Exchange earlier than Exchange 2000 Server Service Pack 1
with the information required for Exchange Server 2003.
Directory Service Access

Exchange Server 2003 services access information that is stored in Active Directory and
write information to Active Directory. If this communication occurred directly between
each service and Active Directory, Exchange Server 2003 could overwhelm an Active
Directory domain controller with communication requests. A central component is
required to streamline communication with Active Directory. This component is the
Directory Service Access (DSAccess) module.
DSAccess is a shared API that is used by multiple components in Exchange Server 2003
to query Active Directory and obtain both configuration and recipient information.
DSAccess is implemented in DSAccess.dll, which is loaded by both Exchange and non-
Exchange components, including system attendant, message transfer agent, Microsoft
Exchange Information Store service, Exchange Management Service, Internet
Information Services (IIS) and Microsoft Windows® Management Instrumentation
(WMI). DSAccess discovers the Active Directory topology, detects domain controllers
and global catalog servers, and maintains a list of valid directory servers that are suitable
for use by Exchange components. In addition, DSAccess maintains a cache that is used to
minimize the load on Active Directory by reducing the number of Lightweight Directory
Access Protocol (LDAP) requests that individual components send to Active Directory
servers.

Important:
DSAccess.dll is the primary DLL that implements DSAccess. To operate properly, the
DSAccess.dll version must match the version of its companion DLLs. The companion
DLLs, Dscmgs.dll and Dscperf.dll, store event log message strings and performance
object providers, respectively.

Domain Controllers, Global Catalogs, and Configuration Domain

Controllers

DSAccess partitions the available directory service servers into the following three
(possibly overlapping) categories:

• Global catalog servers Exchange Server 2003 must access global catalog
servers to obtain complete address information for all recipient objects in the
forest. Only global catalog servers contain a complete replica of all objects in the
domain and a partial replica of all objects in the forest. Global catalog servers that
an Exchange server currently uses are called working global catalog servers.
Almost all Exchange Server 2003 user-context directory service transactions
target global catalogs. Regardless of how many global catalog servers are located
in the local Active Directory site, a maximum of 10 global catalog servers can be
added to the working global catalog list. If there are no global catalog servers in
the local site, or if none of the global catalog servers in the local site pass the
suitability tests, DSAccess uses a maximum of 200 offsite global catalog servers
with the lowest costs. Because the directory service server used for a global
catalog is also itself a domain controller, this server may be used as both types of
directories.
• Domain controllers Domain controllers are used for user-context requests when
the requesting service has sufficient knowledge of the location of the requested
user object in the issued search. These domain controllers are also called working
domain controllers. Working domain controllers are domain controllers in the
local domain that can accept domain naming-context queries. Regardless of how
many domain controllers are located in the local Active Directory site, a
maximum of 10 domain controllers can be added to the working domain
 controller list. If there are no domain controllers in the local site, or if none of the
domain controllers in the local site pass the suitability tests, DSAccess uses offsite
domain controllers with the lowest costs.
Queries to working domain controllers are load balanced on a round robin basis to
avoid overloading a single domain controller. If the working domain controllers
are not hard-coded in the registry, the list of working domain controllers is re-
evaluated and regenerated every 15 minutes using the topology discovery process
and suitability tests.
• Configuration domain controllers Exchange Server 2003 can read from
multiple domain controllers. To avoid conflicts when applying configuration
changes to Active Directory, Exchange Server 2003 writes its configuration
information to a single domain controller, called the config domain controller.
When selecting a config domain controller from the list of working domain
controllers, DSAccess gives preference to a domain controller over a global
catalog server. In addition, DSAccess gives preference to a directory server in the
local site before using a directory server in a secondary site.
If the config domain controller becomes unavailable to Exchange Server 2003 for
any reason, DSAccess selects another working domain controller as its config
domain controller. Every eight hours, DSAccess re-evaluates the config domain
controller role by running a set of suitability tests. If the tests are successful,
DSAccess continues to use the same config domain controller. If the tests fail,
DSAccess chooses another domain controller from the list of working domain
controllers as the config domain controller.

The core components of Exchange Server 2003 rely on DSAccess to provide a current list
of Active Directory servers. For example, the MTA routes LDAP queries through the
DSAccess layer to Active Directory. To connect to databases, the store process uses
DSAccess to obtain configuration information from Active Directory. To route messages,
the transport process uses DSAccess to obtain information about the connector
arrangement.

DSAccess updates the list of available global catalogs and domain controllers as changes
in the state of the directory service are detected. This list can be shared with other
directory consumers that do not use DSAccess as their gateway for accessing the
directory service, for example, DSProxy and other components in system attendant. The
service that is requesting this list is responsible for the detection of subsequent directory
service state changes.

Note:
Unless domain controllers and global catalog servers are hard-coded in the registry, the
list of global catalog servers and domain controllers is re-evaluated and regenerated every
15 minutes using a topology discovery process and suitability tests.
LDAP Connection Load Balancing and Failover

In Exchange Server 2003, DSAccess determines the Active Directory topology, opens the
appropriate LDAP connections, and works around server failures. For each available
directory service server, DSAccess opens LDAP connections solely dedicated to each
process that uses DSAccess. DSAccess updates these LDAP connections with directory
service state information (Up, Slow, or Down) that it detects. DSAccess uses this state
information to decide which LDAP connection to use to forward requests to Active
Directory. The set of LDAP connections to available domain controllers and global
catalog servers and their associated states forms the DSAccess profile.

DSAccess supports a load-balancing mechanism that distributes user context directory

service requests in a round robin fashion among the LDAP connections in the DSAccess
profile. Load balancing helps ensure reliability and scalability. You can statically
configure all profiles in the registry to use only a specific set of directory service servers.
However, the actual state and load balancing of these connections may differ from
process to process or profile to profile. This is not the case for configuration context
requests.

Note:
Because all Exchange Server 2003 and IIS services use the same security context (the
LocalSystem account), it is possible for DSAccess to reuse the LDAP connections from
one request to another. At startup or a topology change, DSAccess opens LDAP
connections to all suitable domain controllers and global catalog servers in the topology.

When the Microsoft Windows-based implementation of LDAP (WLDAP) returns an

error on an LDAP operation, DSAccess analyzes it and determines if it indicates that the
directory server is experiencing problems. If so, the directory server is immediately
marked as unsuitable, and the user operation is automatically retried on a different server.
If there is at least one working domain controller in the topology, DSAccess can continue
with flawless operation.

To verify the suitability of a domain controller or global catalog server, DSAccess

determines that the server is reachable over port 389 for a domain controller and
port 3268 for a global catalog server, and that it resides in a domain that was prepared
with DomainPrep. DomainPrep ensures that the group policy system access control list
(ACL) is configured correctly to grant Exchange Server 2003 services access to Active
Directory. Server suitability checks are covered later in this article.

Note:
To obtain suitability reports in the application event log, you can enable diagnostics
logging for the topology category of the DSAccess service in Exchange System Manager.

The DSAccess topology always contains two lists, the in-site list and the out-of-site list.
The in-site list contains servers from the local Active Directory site of the Exchange
server. The out-of-site list contains servers from other Active Directory sites. Initially,
DSAccess uses only servers from the local site, but when all local servers from a certain
category, for example, global catalog servers, are not suitable, DSAccess immediately
starts using the out-of-site list. DSAccess then keeps checking the local site every five
minutes and fails back as soon as it is possible. User requests are retried on the out-of-site
servers immediately and seamlessly for users.

Some Exchange Server 2003 components, such as the Microsoft Exchange Routing
Engine service, also register with Active Directory to be automatically informed by
Active Directory of any changes to configuration information. This notification
mechanism eliminates polling, but the event registration is per target server. If DSAccess
marks the target server as down, it reissues the event registration and informs the client
process, such as the Routing Engine service, of a change, because the monitored values
could have changed during the process of selecting a new domain controller or global
catalog server.

DSAccess Topology Discovery

At startup, DSAccess uses a discovery process to identify the Active Directory topology
and assess the availability of domain controllers and global catalog servers. After startup
is complete, and every 15 minutes thereafter, DSAccess uses an almost identical process
to rediscover the topology and to check for any changes in server availability.

Note:
If you hard code the directory servers that are used by DSAccess, DSAccess bypasses the
discovery process and checks for server suitability only.

The following sequential list outlines the discovery process and indicates differences
between initial discovery and rediscovery:

1. The system attendant process (Mad.exe) instantiates and initializes DSAccess.dll

during startup.
2. From the local domain, DSAccess opens an LDAP connection to a randomly
chosen domain controller. This server is referred to as the bootstrap server.
3. DSAccess reads the local registry to determine if the topology is hard coded. If
the topology is hard coded, the discovery process stops. If no hard coding is
detected, DSAccess continues the discovery process.
4. DSAccess queries the bootstrap server to identify local domain controllers and
global catalog servers. DSAccess then determines server suitability and assigns
server roles.
5. DSAccess queries the bootstrap server to determine if one or more secondary sites
are connected to the local site. If secondary sites exist, DSAccess sorts the
siteLink objects for each site from lowest cost to highest cost. DSAccess places
the lowest cost sites in a secondary topology list.
6. DSAccess queries the bootstrap server to identify the domain controllers and
global catalog servers that are located in the secondary topology sites.
 7. DSAccess identifies the full topology and compiles a list of working domain
controllers, and a list of working global catalog servers.

By default, DSAccess initialization during startup must finish within one minute.
Otherwise, DSAccess stops. One minute is usually long enough for DSAccess to
initialize. If initialization takes longer than one minute, this might indicate a problem
with the network or topology configuration. Although you can extend the time-out
parameter by setting a registry key, you should first determine why initialization takes
longer than expected. To configure the time-out, use the registry setting shown in the
following table.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet
Location
\Services\MSExchangeDSAccess
Value TopoCreateTimeoutSecs
Type REG_DWORD
Sets the time-out value for DSAccess initialization in seconds, such as
Description
0x200. The default is 0x3C seconds (1 minute).
Note:
If you set the diagnostics logging level for all categories of the MSExchangeDSAccess
service to Maximum, Exchange System Manager automatically obtains detailed
information about the initialization of DSAccess and places that information in the
application event log.

Initial Discovery and Ongoing Rediscovery Suitability Tests

After DSAccess discovers the Active Directory topology, it determines whether the
discovered list of working domain controllers and global catalog servers is suitable for
use. During initial discovery and ongoing rediscovery, DSAccess determines server
suitability by running a series of suitability tests. Suitability tests fall into two categories:
hard tests and soft tests. Hard tests determine whether the domain controller or global
catalog is a viable candidate for use. If the server fails the hard tests, it is considered
unusable, removed from the list of discovered servers, and the soft tests are not run.

DSAccess runs the following hard suitability tests:

• Global catalog capabilities DSAccess determines if the directory server is

specifying itself as a global catalog server by determining if the
isGlobalCatalogReady attribute on the RootDSE object of the server is set to
TRUE. If the attribute is set to TRUE, the directory server is determined to be a
valid and usable global controller.
• Reachability DSAccess uses Internet Control Message Protocol (ICMP) to
contact each server to verify that the server is available. DSAccess also verifies
that the directory server is reachable over port 389 for domain controllers and
 port 3268 for global catalog servers.
If you use ICMP to determine if a server is available, you might create a problem
if all connections in your network do not support ICMP. For example, an
Exchange server might reside in a perimeter network, which has no ICMP
connectivity between the Exchange server and the domain controllers. In this
situation, you should disable the ICMP check and set registry parameter in the
following table to zero.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet
Location
\Services\MSExchangeDSAccess
Value LdapKeepAliveSecs
Type REG_DWORD
Value Data 0x0
If the registry key does not exist or is not set to 0, DSAccess uses the PING
Description
protocol.

• For more information about the LdapKeepAliveSecs registry key, see Microsoft
Knowledge Base article 320529, "XADM: Using DSAccess in a Perimeter
Network Firewall Scenario Requires a Registry Key Setting."

• Group policy SACL permission Together with the regular access control list
(ACL) permissions, Setup grants all servers running Exchange Server 2003
security access control list (SACL) permission to view ntSecurityDescriptor
attributes. Permission is granted through the SeSecurityPrivilege privilege.
DSAccess reads the security descriptor of the configuration directory partition
object on the server, to verify that the SACL is readable. If the SACL cannot be
read, DSAccess considers the server not suitable.
• Critical data The directory server must be located in a domain in which
DomainPrep was run. The domain must contain the Exchange Server 2003 server
object in the Exchange configuration container.
• Synchronization DSAccess verifies that the server is synchronized by
determining if the isSynchronized attribute on the rootDSE object of the server
is set to TRUE.
• Netlogon DSAccess sends a DSGetDcName remote procedure call (RPC) to the
directory server to test its general suitability. If the directory server is not
synchronized, is out of disk space, or is experiencing other problems, it will not
identify itself as a directory server.
In a perimeter network, in which RPC traffic is not allowed, the Netlogon check
cannot occur. However, the Netlogon check continues to issue RPCs until it fails,
which can take a long time. Because repeated Netlogon checks decrease
performance, you should stop DSAccess from issuing Netlogon checks by
creating the following registry key.
 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet
Location
\Services\MSExchangeDSAccess
Value DisableNetLogonCheck
Type REG_DWORD
Value Data 0x0
If the registry key does not exist or is not set to 0, DSAccess performs the
Description
Netlogon check.

For more information, see Microsoft Knowledge Base article 320228, "XGEN: The
"DisableNetLogonCheck" Registry Value and How to Use It."

• Version of the operating system Exchange Server 2003 can use only domain
controllers and global catalog servers running Microsoft Windows Server™ 2003
or Windows 2000 Server Service Pack 3 or later. DSAccess determines whether
the directory server meets these requirements.
After hard tests are complete, DSAccess runs a series of soft tests to determine
which directory servers can accommodate the additional load placed on them by
Exchange Server 2003. To make this determination, DSAccess runs the following
soft suitability tests:
o DNS weight DSAccess uses the weight value of the domain controllers
and global catalog servers, as specified in each server's (SRV) resource
records in Domain Name System (DNS) to determine which server the
client should prefer. A higher weight results in a higher probability that
DSAccess will choose a server. If DSAccess cannot read the weight, it
uses a default weight of 100.
o FSMO primary domain controller role owner If your topology
contains servers running Windows NT® Server 4.0, the directory server
with the Flexible Single Master Operations (FSMO) primary domain
controller (PDC) role will experience heavy loads, making it a less than
ideal candidate for use by Exchange Server 2003. For this reason,
DSAccess performs a soft suitability test to locate the PDC FSMO role
owner, so that it can remove it from the list of suitable directory servers.
o Response time DSAccess performs an LDAP query against the directory
server to check its response time. Response time greater than two seconds
is considered a soft suitability test failure.