I have 3 DC's (DC1, DC2 and DC3) in SiteA and multiple remote Sites(n), and all 3 of the DC's have the Global Catalog service enabled. Our Exchange 07 server is in SiteA. I have been slowly removing roles (FSMO) and services from DC1. When I disabled the GC service from DC1, folks were not able to add new Mail Profiles when setting up new PC's. When we did a check name, the new mail profile service couldn't resolve the name. After re-enabling the GC on DC1, resolving names when creating new mail profiles started to work again. Any ideas why disabling GC on DC1 prevented folks from adding new mail profiles? Thanks Ron

Hi, This is because Exchage Server is still using this DC as GC. You must have wait for some long time and see effect. Also i will suggest you to reboot Exchange mailbox server (Plan according to your business hour) and thec check. Also we can set GC for exchange 2007 sevrer using cmdlet set-exchange server. http://technet.microsoft.com/en-us/library/bb123716(EXCHG.80).aspxAnil

Can you post the DSACCESS 2080 event logs? They should show what DCs the Exchange Servers are using and for what roles.

I work on the simple basis that when I remove a GC/DC, I need to at least restart the System Attendant Service on the Exchange server. That ensure that Exchange recognises the DC has gone. Users who have problems with domain functionality should be asked to reboot, so that their machine uses another DC. While both Exchange and workstations should use another DC automatically, in practise I find this can take some time before it occurs. Exchange in particular can take 35 minutes or more before it looks for another GC and in that time it will be pretty much dead. Simon.Simon Butler, Exchange MVP. http://blog.sembee.co.uk , http://exbpa.com/

On Sat, 7 Aug 2010 15:54:50 +0000, TrojansBaby wrote: > > >I have 3 DC's (DC1, DC2 and DC3) in SiteA and multiple remote Sites(n), and all 3 of the DC's have the Global Catalog service enabled. Our Exchange 07 server is in SiteA. > >I have been slowly removing roles (FSMO) and services from DC1. When I disabled the GC service from DC1, folks were not able to add new Mail Profiles when setting up new PC's. When we did a check name, the new mail profile service couldn't resolve the name. After re-enabling the GC on DC1, resolving names when creating new mail profiles started to work again. > >Any ideas why disabling GC on DC1 prevented folks from adding new mail profiles? The Exchange toppology service runs periodically and should have discovered the GC was no longer present somewhere between a few minutes and thirty minutes after it was removed. If you haven't already, follow this KB article to see what your server thinks about the DCs and GCs: http://support.microsoft.com/kb/316300 --- Rich Matheisen MCSE+I, Exchange MVP --- Rich Matheisen MCSE+I, Exchange MVP

As others have pointed out this stuff gets cached in Exchange and unfortunately the behavior is not very predictable. The approach I take when I'm going to pull an Exchange facing GC out of the mix is to define a new AD site and move the DC in to that site. I'll then wait a few days to let it clear out of the system, so to speak and then I'll unhost the GC on it.Active Directory, 4th Edition - www.briandesmond.com/ad4/

In terms of waiting, it was a couple of weeks. I never did restart the Ex07 server. When I did remove the GC from DC1, the insite properties did change for DC1 in the 2080 event. ADAccess runs every 15 minutes. When I heard about the problems with creating new mail profiles, I re-enabled GC and DC1, and the issue was resolved. With as many DC's with GC enabled that I have, why didn't the workstations see and resolve against the Ex07 server? If one goes down (by manual disable or just unreachable), I would think that the workstations would eventually find the EX07 server especially since the Ex07 server recognizes all of the DC's and their roles. The current 2080 event shows Exchange Active Directory Provider has discovered the following servers with the following characteristics: (Server name | Roles | Enabled | Reachability | Synchronized | GC capable | PDC | SACL right | Critical Data | Netlogon | OS Version) In-site: dc1.abc.NET CDG 1 7 7 1 0 1 1 7 1 dc2.abc.NET CDG 1 7 7 1 0 1 1 7 1 dc3.abc.net CDG 1 7 7 1 0 1 1 7 1 Out-of-site: dc4.abc.NET CDG 1 7 7 1 0 1 1 7 1 dc5.abc.NET CDG 1 7 7 1 0 1 1 7 BTW, I do appreciate your responses. It's great knowing that folks will help out. Thanks Ron

So, Did you restart you exchange server or system attendant service now. What is result after it. An inactive network connection is first on the binding list:: http://technet.microsoft.com/en-us/library/dd789571(EXCHG.80).aspxAnil

Last night, I removed DC1 from the domain, and everything looked great until I tried updating an account from the Exchange 2007 console. I got a MSExchangeAL LDAP Operations error, event 8026 which is legit of cource since it is looking for DC1. I did a search and the suggestions were for Exchange 2000/2003 and running the Recipient Update service. Anyway to update the LDAP pointer on the Exchange 2007 server without impacting users during the day? Thanks Ron

What you should have done is restart at least System Attendant shortly after removing the domain controller. That would force Exchange to look for another DC. Otherwise it begins to look like something has been hard coded somewhere. Was this an Exchange 2003 domain before? Was it removed correctly? Run the Best Practises tool from the Toolbox and see what has to say. Simon.Simon Butler, Exchange MVP. http://blog.sembee.co.uk , http://exbpa.com/

Hi, DSAccess is a shared API that is used by multiple components in Exchange 2007 to query Active Directory and obtain both configuration and recipient information. 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. DSAccess will perform a complete new topology redetection every 15 minutes. Did you test this issue after 15 minutes? Was the DC1 still avaiable in the 2008 event after 15 minutes? Did you configure the registry to specify the DC or GC statically? http://support.microsoft.com/kb/250570 To clear the cache and make others GC work, you should restart the Microsoft Exchange System Attendant service. 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 server Thanks Allen

Thanks Ron