EDIT 1/24/2008: Please see the Part 2 of this post which has additional information on how to resolve this problem.
After applying SP2 to an Exchange 2003 server, users may have problems updating Di...
Updated Jul 01, 2019
Version 2.0
Blog Post
12 MIN READ
Understanding multi-domain DL update and delegate issues after application of Exchange 2003 SP2
I've encountered a similar issue to the one described. Specifically, Outlook users are not directed to a GC they have access to. Because of the use of firewalls and a “flat” Sites & Services topology at my University, the behavior change introduced by E2K3 SP2 has caused some headaches for me since April 2006.
The forest is currently comprised of 8 domains including 1 root and 7 children. Schools and major administrative units on campus have deployed firewalls to segregate and control traffic to/from their network subnets and the campus enterprise network. The current topology of the Active Directory enterprise forest is “flat”; all domain controllers pass information and replicate with each other. The reason the topology was originally designed to be “flat” is because everyone is connected at high speed and are in the same geographic location.
Immediately after upgrading to E2K3 SP2, when a Microsoft Outlook client computer connects to a Microsoft Exchange Server, the DSProxy service may not direct the client to the Global Catalog server that it should. Instead, the DSProxy service directs the client to a domain controller that is in a different domain. (e.g. a user in DOMAIN-A is directed to a GC in DOMAIN-B) Since individual workstation access is being denied by most firewalls on the campus, an Outlook user may experience a timeout when attempting to attach to an Exchange server because it cannot contact a GC server in another domain.
We have contacted Microsoft PSS multiple time and each time they state that we need to deploy a Site & Services (S&S) topology. I agree with the S&S setup but my frustration is in understanding exactly how DSAcess and DSProxy actually work in a Post E2K3 SP2 implementation with Outlook 2002/2003 clients:
It is my understanding that DSAccess on each Exchange server 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 to minimize the load on AD by reducing the number of LDAP requests. DSProxy is an Exchange 2003 component that provides an address book server to Outlook clients. In Outlook 2002/2003 clients, DSProxy refers the Outlook clients to a Global Catalog (GC) server. These clients connect to the user’s home Exchange server and send a request to the RFR service on the Exchange server. RFS works with DSAcess to determine the name of a qualified GC server and returns that name to the Outlook client. The Outlook client then sends its NSPI requests directly to the selected GC.
If the above is true, then DSAccess through automatic discovery will know about all the GCs in the environment (no firewall blocks between DCs and Exchange). When DSProxy works with DSAccess for Outlook GC discover, it will pick a GC that a client might not have access to (e.g., a DOMAIN-A Outlook user can not access a DOMAIN-B GC because of a firewall block). So, my question still remains; will Sites and Services fix the root issue since individual workstation access to DCs in different domains is being denied by most firewalls on campus?
Joe Mancuso
Univ. Of Md, Baltimore
The forest is currently comprised of 8 domains including 1 root and 7 children. Schools and major administrative units on campus have deployed firewalls to segregate and control traffic to/from their network subnets and the campus enterprise network. The current topology of the Active Directory enterprise forest is “flat”; all domain controllers pass information and replicate with each other. The reason the topology was originally designed to be “flat” is because everyone is connected at high speed and are in the same geographic location.
Immediately after upgrading to E2K3 SP2, when a Microsoft Outlook client computer connects to a Microsoft Exchange Server, the DSProxy service may not direct the client to the Global Catalog server that it should. Instead, the DSProxy service directs the client to a domain controller that is in a different domain. (e.g. a user in DOMAIN-A is directed to a GC in DOMAIN-B) Since individual workstation access is being denied by most firewalls on the campus, an Outlook user may experience a timeout when attempting to attach to an Exchange server because it cannot contact a GC server in another domain.
We have contacted Microsoft PSS multiple time and each time they state that we need to deploy a Site & Services (S&S) topology. I agree with the S&S setup but my frustration is in understanding exactly how DSAcess and DSProxy actually work in a Post E2K3 SP2 implementation with Outlook 2002/2003 clients:
It is my understanding that DSAccess on each Exchange server 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 to minimize the load on AD by reducing the number of LDAP requests. DSProxy is an Exchange 2003 component that provides an address book server to Outlook clients. In Outlook 2002/2003 clients, DSProxy refers the Outlook clients to a Global Catalog (GC) server. These clients connect to the user’s home Exchange server and send a request to the RFR service on the Exchange server. RFS works with DSAcess to determine the name of a qualified GC server and returns that name to the Outlook client. The Outlook client then sends its NSPI requests directly to the selected GC.
If the above is true, then DSAccess through automatic discovery will know about all the GCs in the environment (no firewall blocks between DCs and Exchange). When DSProxy works with DSAccess for Outlook GC discover, it will pick a GC that a client might not have access to (e.g., a DOMAIN-A Outlook user can not access a DOMAIN-B GC because of a firewall block). So, my question still remains; will Sites and Services fix the root issue since individual workstation access to DCs in different domains is being denied by most firewalls on campus?
Joe Mancuso
Univ. Of Md, Baltimore