Exchange Internals

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 nonExchange 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 Exchangespecific 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 Exchangespecific 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. Schema2.ldf

Includes schema extensions for Internet access protocols, directory 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). Schema6.ldf

Includes schema extensions for protocol virtual servers, administrative groups, messaging connectors, and the Exchange store.

Schema7.ldf

Includes schema extensions for messaging databases and mailbox 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 nonExchange 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 reevaluated 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

Description

Sets the time-out value for DSAccess initialization in seconds, such as 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 Description

If the registry key does not exist or is not set to 0, DSAccess uses the PING 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 Description

If the registry key does not exist or is not set to 0, DSAccess performs the 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.