Is there a way to designate a preferred global catalog server?

15 pts.
Tags:
Microsoft Exchange
Microsoft Windows
We have three campuses with T1s connecting them. A microsoft consultant told us we have no need for multiple sites but I wanted to have a global catalog server at each campus so users can still log into their systems if the connection goes down. Our exchange server is at the main campus. We had users experiencing timeouts trying to connect to the exchange server. When I disabled global catalog on both remote campuses the problem went away. Is there a way to designate a preferred global catalog server so the main campus GC will be used under normal circumstances but systems can use the other GCs if there is a problem? Does anyone know the algorithm used to choose which GC is used? Thanks. rt
ASKED: March 13, 2006  11:52 AM
UPDATED: April 19, 2006  1:45 PM

Answer Wiki

Thanks. We'll let you know when a new response is added.

If the servers on the other sites are all DCs, then you should not have any issues with connections, as all servers maintain a copy of the GC that is updated periodically. Of course, since you only have one Exchange box, there would be no mail connectivity if you lost your T’s (I would therefore recommend running Outlook in Cached Exchange Mode).

Discuss This Question: 10  Replies

 
There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when members answer or reply to this question.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
  • Brucek
    Different answer - If your clients are Outlook 2003, have you considered "cached mode"? This would leave them able to access their e-mail and still "send" even if the connection or the Exchange server goes down.
    0 pointsBadges:
    report
  • Astronomer
    As I explained, when we had the remote campus DCs running as global catalog servers we experienced timeouts when client systems tried to connect to the exchange server. This was happening even to clients at the main campus. When we disabled the global catalog function on the remote campus DCs the exchange connection problem went away. I want to re-enable global catalogs on the remote DCs so the users at the remote campus can still log on if the T1s go down. I know they would not have access to the email server under these circumstances but they could still do the majority of their jobs. My problem could be rephrased as: How can I turn the global catalog function back on for the remote DCs without bringing back the exchange problem. rt
    15 pointsBadges:
    report
  • Serendipity
    There is a way to specify which Global Catalog server your Exchange server should use, but usually that isn't a good idea because you'd have a problem if that Global Catalog server isn't available. If DNS is working properly and replicating to all the domain controllers, then letting the Exchange server detect the GC automatically works best. It sounds like you may have a DNS configuration problem. Having said that, the place where you specify the specific GC is in Exchange System Manager, on the properties of the Exchange server. Go to the Directory Access tab. It will show all the servers functioning as domain controllers and global catalog servers, as well as the server it uses for information about the Exchange organization configuration. By default, the checkbox on the bottom, "Automatically discover servers" is checked. To be able to change that you have to click the down-arrow at the top where it says Show All Domain Controllers. If you select to show Global Catalog servers, you can un-check the autodetect box, and select a specific server. If that server becomes unavailable, without the autodetect on you would have to manually make the change to another GC. In that case you may have to restart your Exchange services or restart the Exchange server, I'm not sure.
    100 pointsBadges:
    report
  • Astronomer
    Thanks for the reply on selecting a GC from within exchange. We have already experienced what happens to exchange when its only GC server goes down. That is why I was hoping to just get the domain to prefer a specific server instead of having only one effective GC available. If we configured sites would that give a preference to a local GC server? The only other option I can see at this point is to ask for bigger pipes so they don't get saturated. rt
    15 pointsBadges:
    report
  • Swiftd
    Astronomer, Here's an interesting article on the relationship of the GC and Exchange 2003: http://www.computerperformance.co.uk/ezine/BestPractice/BestPractice63.htm. In it, Guy's "rule of thumb" is to "deploy two Global Catalog Servers at each Active Directory Site" or to use a 1:4 (GC:Exch Servers) ratio of GCs to Exchange servers. Personally, we have a similar setup as you are discussing: Two sites each connected via a T1 with one Exchange 2003 server in a 2003 Domain. We use a GC at each site and do not have any Exchange problems like you described. The only problem we've ever had with Exchange was related to a bug fix MS006-007. I don't recommend Outlooks Cached Exchange mode and I don't think it'll solve your problem. We tried that when we intially brought up the site, but I really don't like the Cached Exchange mode because it doesn't work in real time, so messages can be delayed while your users are unable to contact the Exchange server. Yes, it might cut down support calls with users saying the Exchange server is down, but on the other hand it might increase calls with users saying that the other party didn't receive the emails when they expected it. Personally, I'd rather hear from 40 users at once that the Exchange server was down than throughout the day that the distant end user didn't receive such and such email... A final note on Cached Exchange mode: once the initial connection with the Exchange server is made, there isn't that much traffic required to maintain it's connection to the Exchange server. I really don't think it's going to push your T1 utilization over the limit unless you have an extremely high number of users on the other end, in which case you'd have another Exchange server at each site anyway. Anyway, I really didn't answer your initial question about the algorithm used in choosing a GC. Truth is, I don't know the answer for that. I've always been under the impression that it worked in a manner similar to an all ones broadcast: whichever GC heard and responded to the request first was the one that you were designated to use. Therefore, if you're at a site with a GC and connected over a T1, the local GC will always answer first unless it's down. Good luck, Don
    0 pointsBadges:
    report
  • Astronomer
    Don: I don't know why the exchange server seems to want to authenticate using the remote DCs. One of the things we have noticed is more often than not, when we administer active directory from a workstation, the server we are listed as using is on a remote campus. The domain controllers at the remote campuses are bigger/faster boxes. They do multiple duties including file server and print server compared to the main campus DCs being 1U boxes dedicated to DC functions. I don't think there is an issue with the amount of traffic generated by authenticating over the T1s but these pipes ocassionally get congested when an instructor downloads a large file from the main campus. I suspect this is when the timeouts occur. We don't have a tracking resolution better than five minutes and the symptoms are clearly intermittent. I tried your link but it was broken. Thanks for the response. rt
    15 pointsBadges:
    report
  • Serendipity
    If you want the computers at a specific location to use the GC at that location then you have to set up a separate site for that location. It's the SRV records in DNS that tell computers which GCs are in their site. I'm assuming you are using Active Directory Integrated DNS, in which case each domain controller or global catalog server has a copy of DNS records. You can open up the tree under the forward lookup zone for your domain in DNS and you'll see a _sites folder. The folder under each site tells which domain controllers function as a gc for that site, which domain controllers do kerberos authentication, and which dcs can do ldap searches for the site. The computer's IP address determines which site the computer belongs to, so it knows which site's information in DNS to use. If all your campuses are in one site, then computers can be directed to any of the gcs in the site. A computer will only use dcs/gcs from another site if all the dcs and gcs in its own site are not available. The following article is old, but still has good information about this process and has information on how to check if your DNS SRV records are correct. http://support.microsoft.com/kb/247811 I hope this helps.
    100 pointsBadges:
    report
  • Astronomer
    The microsoft link explained it. Looks like I will be configuring sites this weekend. Thanks for all the responses. rt
    15 pointsBadges:
    report
  • Swiftd
    Astronomer, The link works if you remove the last period. From the sounds of your initial problem and follow ups, it sounded as if you had established different sites under one domain in the Site and Services applet. The establishment of the different sites will make a world of difference to your domain. Someone had accidentally put all of the servers under one site on our network and things went horribly wrong until we figured it out. People were authenticating to the remote server across the T1... You could establish the sites during normal duty hours as nothing requires a reboot and it will only improve performance. Don
    0 pointsBadges:
    report
  • Astronomer
    I finally discovered the real reason we had problems authenticating with our local domain controllers. We were using a Dell Gbit switch to connect the servers. This allowed Gbit network backups. We started with just the big servers on the Gbit switch but gradually moved nearly all of the servers to this switch. The first symptom was the off-site authentications but gradually we experienced more symptoms. Eventually outlook clients were reporting exchange offline for minutes at a time and some clients reported the domain as unavailable. All of these symptoms were intermittent. During this time there were no errors reported by any of the network devices. The log on the dell switch showed 0 errors on all ports. One day some customers reported the main DC unavailable and I was finally able to catch the problem before it went away again. I stuck my laptop on the Gbit switch and found I couldn't ping the router. Since the Gbit switch was directly connected to the router with a fiber connection I called dell with the question "How do we make sure this doesn't happen again?" They sent us a replacement switch under warranty. We installed it during spring break. The next monday problems started all over again. the symptoms were a little different so it took me a while to verify it was the switch again. When I called dell he wanted to know what new protocols we were running. The answer was none. The utilization during the day was insignificant. He had me set up a constant ping of the switch from my workstation. The pattern was interesting. There were no isolated failures or successes. They were all in groups. The intermittents were happening every few minutes. Near the end of the call when it was clear he didn't have an answer I realized that if I was failing from my workstation and I pinged the router from the switch, the pings from my workstation would start succeeding again. This happened every time I tried it. I suspected the CAM table. He had me look at the CAM table with the GUI but this wasn't very informative. I did notice one thing. The CAM table on the dell powerconnect 5224 is 1K in size. We have nearly 2000 nodes at our main campus. My conclusion was that the CAM table was getting over-run and the switch wasn't recovering gracefully. The support tech wasn't sure but asked me to let him know when I figured it out. Later that day when we started moving servers to a slower cisco switch the symptoms got better with every move. Now our backups are working, the problems with the IIS server are gone, and we have no more complaints about reaching the domain. I suggested we replace the dell switch with an HP but my manager had me call to extract a promise that we wouldn't have the same problem. When I called HP we had a long discussion about the problem. I was right, it was the CAM table. When it overflows there are no errors reported. He was surprised the dell CAM table was so small. The equivilant HP switch to our dell has a 16K CAM table. In retrospect the symptoms started some time ago and gradually got worse as we added more servers to the Gbit switch. The final straw that made the failures long enough to debug was moving our old slow HP student file server to the Gbit switch. At that point the CAM table was flooded by student MACs. After discussing what to do with the switch, (our backup tech offered to bring in his sledge hammer), we have decided to put it in a Macintosh lab at a campus with fewer than 500 nodes. This was a tough one for me. Intermittents tend to be. I appreciate the responses to my questions. It's too bad I was asking the wrong questions. I plan on asking for a class on ethereal, (I believe with more knowledge about analyzing packet captures I would have discovered it sooner). I wanted to share my experience in case someone else runs into something similar. rt
    15 pointsBadges:
    report

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

To follow this tag...

There was an error processing your information. Please try again later.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Thanks! We'll email you when relevant content is added and updated.

Following