Exchange, Active Directory, and WINS

[LEFT][CODE]http://theessentialexchange.com/blogs/michael/archive/2008/01/16/exchange-active-directory-and-wins.aspx[/CODE]

[B]Exchange, Active Directory, and WINS[/B]

In other words - name and attribute resolution.
Exchange Server stores almost all of its non-store-related information in Active Directory. This includes configuration for each individual Exchange server, each Virtual Server for each Exchange server, etc. Exchange places all of this information beginning at the following Active Directory location (this for example): CN=First Organization, CN=Microsoft Exchange, CN=Services, CN=Configuration, DC=TheEssentialExchange, DC=com. For your Exchange organization the first node (CN=First Organization) may be different and the last nodes (DC=TheEssentialExchange,DC=com) will definitely be different.
The Exchange information will be located in the root domain of any forest where Exchange Server is installed. The information is part of the Configuration naming context and thus will reside on every domain controller.
If you use any LDAP (Lightweight Directory Access Protocol) query tool (ADSI Edit and LDP are both included as part of the Windows Server Support Tools, and Softerra's LDAP Browser is another really good tool), you will see that the structure of the information for the Exchange organization matches closely to that of the information as presented in Exchange System Manager (in Exchange 2003; less so in Exchange 2007).
The other types of information that Exchange uses is stored within Exchange-aware objects. Users, groups, contacts, InetOrgPerson objects, etc. - each of these has attributes that Exchange is extremely interested in, plus there are many other standard attributes that Exchange will use as well (for example, a user's display name and the user's password).
[B]Global Catalog Servers[/B]

The global catalog (GC) is an excerpt from the full Active Directory database that contains a partial copy of every single object in all domains that exist in an Active Directory forest. Included in that partial copy are a few pieces of information about each one of those objects that allow applications, such as Exchange, to make fast queries on objects, without being weighed down by the full content normally contained within the database where the objects are stored.
Since Exchange is a per-forest application, Exchange information needs to be available not only for the forest root domain, but also for every child domain that may exist. As part of the Exchange forestprep process, Exchange specific attributes were added to various objects, but quite a few attributes were also modified to add those attributes into what is called "the partial attribute set". In layman's terms, this means that those attributes are available for search and retrieval in the global catalog.
A GC server is a domain controller (DC) that has been configured to host the global catalog. Indicating that a DC should be a GC is a simple checkbox on the NTDS settings object for the server (this setting is normally configured by using the Active Directory Sites and Services tool).
GC information is made available on TCP port 3268. DC information is made available on TCP port 389. Information requested from, and updated to, GCs and DCs is done using LDAP. Exchange makes heavy use of GC servers.
[B]DSAccess [/B]

Exchange Server uses DCs (and thus, Active Directory in general) in three distinct ways. The process known as DSAccess prepares a list of DCs and GCs that Exchange will use (this list can be manually configured in the registry, but this is not recommended - for more information on this topic, see [URL="http://support.microsoft.com/?id=250570"]Microsoft KB 250570[/URL] - Directory service server detection and DSAccess usage). Most requests made by Exchange services are cached by DSAccess for a period of time in order to improve performance and end-user experience. How to modify that cache timeframe will be shown in the next blog post.
All Exchange services that need access to Active Directory do so (directly or indirectly) via DSAccess. They may contact Active Directory independently, but they will receive the list of DCs and GCs to use from DSAccess. Other services will use DSAccess directly.
[INDENT] [B]Global Catalog[/B]
Almost all user-initiated requests made by Exchange or by an email program communicating with Exchange, such as Outlook, target global catalog servers to obtain their information. This is typically user names, email addresses, aliases, home Exchange servers, etc. Some information is first retrieved via a GC and then by contacting an appropriate DC to gather data not held in the global catalog.
[B]Domain Controller[/B]
If the service requesting information via DSAccess has enough information to direct an information request to a specific domain, some requests may be shortcut and not be directed first through a GC server. In certain situations (such as the expansion of group membership in domain local groups), this can represent a performance improvement.
[B]Configuration Controller[/B]
While all DCs have a copy of the configuration naming context, because of replication latency all copies of the configuration naming context may not be precisely the same within a certain period of time. Therefore, DSAccess refers all configuration naming context updates and queries to a single DC, to ensure that the data returned and updated is consistent. If Exchange needs to update Active Directory, it will always use that configuration DC.[/INDENT]DSAccess scans through all DCs and GCs known by Active Directory, and preferentially uses servers that are in the same Active Directory site and that respond quickly (that is, in less than two seconds). DSAccess repeats the discovery process every 15 minutes. More information on the DSAccess topology discovery process is available in the Exchange Server 2003 Technical Reference Guide, available at [URL]http://microsoft.com/downloads[/URL] via [URL="http://www.microsoft.com/downloads/details.aspx?FamilyID=3768246D-C9ED-45D8-BECE-A666143CBA4E&displaylang=en"]this download link[/URL].
If Exchange Server is installed on a domain controller, all three types of Active Directory access mediated by DSAccess will go to a single DC - the DC that Exchange is installed upon. If Exchange Server is installed on a member server, the list of DCs chosen is somewhat random, dependent upon the number of DCs and GCs in a given site.
[B]DSProxy and the Name Service Provider Interface (NSPI)[/B]

DSProxy is primarily used to support old versions of Outlook (versions that were out before Active Directory was released). Versions of Outlook that old presume that the Exchange Server is running all of the LDAP directory services as well, since for Exchange Server 5.5 and all prior releases of Exchange Server, that was true. DSProxy runs on the Exchange Server and forwards any directory service requests from client computers to NSPI on an appropriate GC server.
Newer versions of Outlook will usually connect to DSProxy only once - in order to receive a referral to a GC that Exchange uses. This happens during the creation of a user's profile. Once that information is received, Outlook stores the information in the user's profile and that GC is used for future requests. New versions of Outlook will also connect to DSProxy if they attempt to connect to a GC and it doesn't respond. In that case, Outlook will ask DSProxy for a new referral (to identify the current global catalog being used, refer to [URL="http://support.microsoft.com/?id=317209"]Microsoft KB 317209[/URL] - How to Identify your Global Catalog Server Using Outlook 2000 and Outlook 2002 - and note that this also applies to Outlook 2003).
NSPI always runs on a global catalog server and is a function of a GC, independent of Exchange Server. That is, NSPI exists on a GC even if Exchange is not installed in a domain or in a forest. NSPI is the client-focused mechanism for returning information to any MAPI request about names - both user names and address book names, as well as the contents thereof. It could reasonably be stated that NSPI is the MAPI mechanism for making LDAP queries to Active Directory. NSPI is used when configuring a user's profile and when making any address book query.
Prior to Windows 2000 Server Service Pack 3, after you made a DC a GC, you had to reboot the server in order for NSPI to begin operation. As of that service pack level, the reboot is no longer required.
[B]Windows Internet Name Service (WINS)[/B]

WINS significantly predates Active Directory, and has its roots in MS-DOS and Windows for Workgroups. It is not a part of Active Directory. WINS operates completely separate and apart from Active Directory. However, for many current Microsoft products, such as Exchange Server 2003, WINS is still an important part of the operational and functional environment.
It is worth reminding you at this point of the number one difference between WINS and DNS - WINS supports a flat namespace and DNS supports a hierarchical namespace.
For example: in any given WINS environment, there can only be one computer named bill. In any given DNS environment, there can be many computers named bill. To wit: bill.domain1.com, bill.domain2.com, etc. ad infinitum.
WINS is based on NetBIOS, and continues several (many) of the limitations of NetBIOS, perhaps most importantly that computer names must be less than 16 characters and that all computer names must be unique within those characters.
For NetBIOS, this is true within a broadcast domain (basically, a LAN). However, WINS is a mechanism of interconnecting multiple NetBIOS broadcast domains together to have unified name resolution across all of those broadcast domains. Thus, all computer names must be unique in a WINS environment.
Exchange Server 2003 (and before) stores server names (and other things, but the server names are arguably the most important) in the configuration naming context (i.e., Active Directory) based on their short name (i.e., their WINS or NetBIOS name). This means that for Exchange 2003 to resolve (find the IP address for) those server names, it will use NetBIOS.
In some ways, using NetBIOS names was a good resolution to the particular problem of tracking down Exchange Servers, where there may be many versions of Exchange in the Exchange organization. In other ways, it has caused (and continues to cause) problems for many organizations.
What this means to you as an Exchange administrator is this: if you only have a LAN, you don't require WINS because NetBIOS broadcasts will likely handle all name resolution issues. In any larger environment using Exchange 2003 and/or clustering, Microsoft requires that WINS be installed and properly configured to deal with all name resolution issues.
Please refer to [URL="http://support.microsoft.com/?id=837391"]Microsoft KB 837391[/URL] (Exchange Server 2003 and Exchange 2000 Server require NetBIOS name resolution for full functionality) for more information on this issue. Also be aware that ESM (if there are multiple administrative groups) and the clustering functionality of Exchange also require WINS.
In regards to Exchange 2007, you only require WINS if you are running clustered servers on Windows Server 2003. According to pre-release documentation, WINS is not needed with Windows Server 2008 clustering.
Published Wednesday, January 16, 2008 8:17 AM by [URL="http://theessentialexchange.com/members/michael.aspx"]michael[/URL]

[/LEFT]