Partager via

AD Integration - from 2003 to 2007….

  • Article

 

So AD integration with Exchange 2003 was split into 2 components: DSAccess & DSProxy.

DSAccess.dll ran inside the System Attendant and was responsible for building a topology of the Domain Controllers available to the Exchange Server (increase diagnostics logging for MSExchangeDSAccess Service\Topology in the properties of your server in ESM and look at the 2080 events logged every 15 minutes in the application log) ; for querying AD to determine the destination of an email for example; and for maintaining a DSAccess cache.

DSProxy provided an address book service for earlier Outlook clients and referred Outlook 2003, which is ‘GC aware’, to AD. (Hold down the control key and right-click on the Outlook icon in the Taskbar; select Connection Status to see the connections to the ‘Directory’.)

As long as your GC’s were performing well; there were enough of them (4:1 – Exchange proc:GC proc); your AD site topology was designed well; and the automatic topology discovery process had not been overwritten, AD integration worked well with Exchange. To verify that Exchange was receiving timely responses to LDAP requests you could use performance monitor to gather MSExchangeDSAccess Domain Controllers\LDAP Search & Read Time counter data.

In Exchange 2007 DSAccess has been split into two parts: AD Provider & AD Driver. Ad Provider is responsible for maintaining the DSAccess cache and for passing LDAP queries to AD. AD Driver is a sub-component of the AD Provider and builds and maintains the DC topology. The remaining component here is ‘AutoDiscover’ which to some extent takes over from DSProxy and enables Outlook 2007 clients to determine the location of mailbox data, but is much more powerful and can be used to ease data recovery for example.

Ex2007 is still very much dependent on your AD site design. (Even more so from a routing perspective as linkstate becomes a thing of the past.) The new ad provider & driver run inside the ‘Active Directory Topology service’ which runs on all Exchange 2007 server roles. This service reads information from all Active Directory partitions. The data that is retrieved is cached and is used to discover the AD site location of all Exchange services in the organization. For example, what the AD site topology is and where therefore the closest or local Hub Transport role server is.

We need to be aware of how each different Ex2007 server role makes use of AD now. This will be important when we begin to troubleshoot issues involving AD and for capacity planning and performance monitoring. For example, the Hub Transport server role contacts AD when it performs message categorization. The categorizer uses the topology information that is cached by the Active Directory Topology service to discover the routing path for a message. The Hub Transport server uses AD site configuration information to determine the location of other servers and connectors in the topology and the location the mailbox store. If the mailbox store is in the same Active Directory site as the Hub Transport server, the message will be delivered directly to the user's mailbox. If the mailbox store is in a different Active Directory site the Hub Transport server delivers the message to a Hub Transport server in the remote AD site.

The Mailbox server role on the other hand stores the configuration for mailbox policies for example in AD. The Mailbox server uses AD therefore to retrieve this information to enforce mailbox policies.

Autodiscover is enabled by default and is used to gather configuration information in AD to enable Outlook 2007, OWA, and mobile e-mail clients to locate and connect to the appropriate Ex2007 Mailbox server that contains the user's mailbox. Autodiscover is also used to make configuring Outlook 2007 clients easier and to provision mobile devices that are used to connect to Exchange 2007. Essentially it means that you only need to know your proxyaddress for example to ensure a successful first synchronisation of your mailbox. (Provided you have the appropriate security access of course.)

(To get the global settings from the AutoDiscoverConfig object under the Global Settings object in AD use Get-OutlookProvider (Get-OutlookProvider [-Identity <OutlookProviderIdParameter>] [-DomainController <Fqdn>]))

When you install the Client Access server role; a requirement of the Autodiscover service, a new virtual directory named Autodiscover is created under the default Web site in IIS. This virtual directory handles the Autodiscover service requests.

A great new feature which complements the Autodiscover service is database portability. In Ex2007 a mailbox database (NOT PF database) can be mounted on any server in the same Organisation. This is of no use unless clients can be redirected to the mailbox data at the new location. With the Outlook 2007 and Ex2007 Autodiscover service, clients are redirected to the new server when they try to connect. This gives us a lot more options when it comes to Disaster Recovery planning.

I have not seen any figures so far but we can also expect much better scalability with Ex2007 and its integration with AD. If nothing else, with 64-bit Exchange Servers we can have much more RAM and will therefore be in a position to potentially be able to cache the entire AD database, thereby increasing lookup and response times.

Comments

  • Anonymous
    October 13, 2008
    W00t! Thanks for having posted this - good information I hadn't run across previously!

  • Anonymous
    November 09, 2011
    Truely....Good Inforamtion....Thanks