How many Global Catalog Servers are needed?

Discussion in 'Active Directory' started by SEgerton, Jul 30, 2006.

  1. SEgerton

    SEgerton Guest

    I’m new to Active Directory; and I just started testing a new domain I’ve
    been working on. On one particular test, I started having issues that I
    believe are related to Global Catalogs. Let me first give an overview of the
    structure of the domain, and the test that I was trying to perform. Then I
    will give the errors that I came across.

    I have two offices. Office 1 is our production office. Office 2 is for our
    Disaster Recovery. In office 1 we have 3 servers. 2 servers are Active
    Directory Domain Controllers, and the third server is a member server used as
    a File Server. Both Domain Controllers are both Active Directory Integrated
    DNS Servers. There is a T1 line that connects both Office1 and Office2. In
    Office 2, I have the same setup. I joined the first two servers to the same
    domain in Office 1 as Active Directory Domain Controllers. These two servers
    are also Active Directory Integrated DNS servers. The third server in Office
    2 is also a member server used as a File Server. The File Server in Office 2
    is only used at the moment for replication of the File Server in Office 1.
    For this we are using a third party replication software. This setup was put
    together this way in the event of a disaster and office 1 goes down, users
    can go to Office 2 and work.

    Here is the test I tried. I turned off both server 1 and server 2 in Office
    1, hoping that Active Directory would still work because of Server 1 and
    Server 2 in Office 2. The redundancy is there for the Domain Controllers and
    for DNS. But after the server were down. I tried logging into the domain on a
    pc as a user, and the logon took a long time. At the same time, he got into
    his profile, but I don’t think his Group Policies were in affect. Then I got
    an error. I forget what I was doing to generate it, but here it is.

    "A Global Catalog cannot be located to retrieve the icons for the
    member list. Some icons may not be shown."

    Then in Office 2, I went into Users and Computers on Server 1 and tried to
    open a Group Policy Object and got this error.

    "Domain controller not found for domain.local" The Domain Controller for
    Group Policy operations is not available. You may cancel this operation for
    this session or retry using one of the following Domain Controller choices.
    Here are the choices:
    -The one with the Operations Master token for the PDC emulator.
    -The one used by the Active Directory Snap-ins.
    -Use any available Domain Controller.
    OK or Cancel.
    I Canceled.

    Due to these messages, I believe the problem is due to a Redundancy of
    Global Catalog Servers. I don't fully understand them. But my understanding
    is that by default, Global Catalog is installed on the first Domain
    Controller of a domain. Therefore I didn't install any additional and only
    have one. How many should I have for redundancy?

    Thanks in advance.

    SEgerton, Jul 30, 2006
    1. Advertisements

  2. SEgerton

    Jorge Silva Guest

    - First: The GC enables finding directory information regardless of which
    domain in the forest contains the data, and provides Universal Group
    Membership Information. Applications also use the first (any object in the
    forest) Exchange is the prototypical example of this. (Windows 2003 has the
    UGMC (Universal Group Membership caching which isn't the same thing as the
    - Second: The GC is only needed when you have DFL (Domain Functional Mode)
    in Native Mode or later where Universal security groups are allowed, more
    than one domain or if you use any app that needs to contact the GC (Exchange
    is an example), if you need to logon with a UPN.

    - Third: There's a registry setting "IgnoreGCFailures" that you can use in
    particular scenarios to force a particular DC NOT TO CONTACT a GC for
    authentication process. If you don't use Universal groups for securing
    things then you can enable IgnoreGCFailures which will allow you to log on
    even if a GC isn't abailable in a Native mode domain. However, if you have a
    single domain there is no reason not to make every DC a GC. Note that even
    with IgnoreGCFailures enabled, you could run into cases where a GC is needed
    say when trying to logon with a UPN, etc.

    - Fourth: Good practices are to have at least one GC per site, even in a
    single domain forest, every DC ALREADY holds ALL of the info so making a DC
    a GC costs practically nothing.
    The above is also true in a SMALL forest with multiple domains.
    As forest size increases the penalty for creating a GC (increase
    replication, increased storage) increases.

    - When Open a GPO console you received that error because by default the
    console tries to contact the PDCe.

    I hope that the information above helps you

    Good Luck
    Jorge Silva
    Systems Administrator
    Jorge Silva, Jul 30, 2006
    1. Advertisements

  3. SEgerton

    Al Mulnick Guest

    Let me add to this a comment or two.
    What it sounds like you're trying to do is come up with a hot site recovery
    plan. It sounds like you want the goal to be seamless operation in the
    event of a domain controller failure. If that's the case, you're in luck
    because Active Directory is a fabric type of authentication mechanism that
    also can host your name resolution information and replicate it all over the

    The part you seem to be missing is the name resolution settings on the
    clients, site definition, and fsmo role holders recovery.

    I suggest some research into the sites and fsmo concepts but the short
    answer here is to go ahead and configure two sites: production and recovery.
    Place a DC/GC in each site. Have a plan to deal with the loss of fsmo role
    holders. To do that, you'll need to better understand what they do for you
    and what happens if you lose one at a given point in time. Some things can
    continue while other things might require intervention on your part to pick
    up that behavior. The criticality of each role varies by company and
    depends largely on how you conduct business.

    Since DNS is integrated, you'll want to be sure that your clients are
    configured to be aware of both DNS hosts. i.e. member server 1 should be
    configured to use either DNS server for name resolution + authentication. To
    do this, you would configure the client settings to use the DNS host in it's
    site as the primary dns server and the DNS host in the alternate site as the
    secondary name resolution server. I think you may have missed this
    configuration in your testing.

    Al Mulnick, Jul 30, 2006
  4. SEgerton

    SEgerton Guest

    Guys, Thanks for all the replys!!

    I have another question. When i was building the domain, I was advised by a
    Microsoft Tech when i called for support to use the .local extension. I
    posted my last post in another room other then this one and a person replying
    mentioned that it is not recommended to use .local. Do you guys have any
    comments on this. He did send me a link that mentioned it is not recommended;
    but why would a Microsoft Tech then tell me to do so? I don't know if this is
    useful, but we aren't using exchange and not concerned about linking our
    outside network with our internal. Here is the link he sent me.

    Under Note...

    ... Using single label names or unregistered suffixes, such as .local, is not
    Thanks again!!
    SEgerton, Jul 31, 2006
  5. SEgerton

    Al Mulnick Guest

    ..local domain names are in use without issue in all kinds of places. It's
    kind of a private domain if you will. Along with that privacy, you cannot
    guarantee that you're not using a domain name that's already in use. It's
    not registered.

    When AD first hit the streets, it was advisable to use .local domain names.
    It was considered acceptable to use single label names as well. Both are
    supported last I checked, but it's best practice to use a domain name that
    you can register. You cannot register a .local name last I checked.

    The documentation will last longer than the Microsoft tech most likely. :)
    Al Mulnick, Aug 1, 2006
  6. There are multiple schools of thoughts here. This topic has been highly
    hashed out over the years. It comes down to YOUR preference based on the
    features and limitations of a name that you would choose. Read the compiled
    passage below to see what I mean...

    What's in a Name?
    "Same name AD DNS domain name and external name (split-zone)"
    I must say this is a classic question that stems back to the beginning days
    of AD. Naming your internal domain name can be based on a number of things,
    whether technical or political, or previous administrative experience. This
    has been highly discussed (not debated) in the past. Whatever decision you
    make for an AD DNS FQDN domain name, just understand the ramifications.
    Actually I'm not going to try to get into any sort of debate, for there is
    really nothing to debate, nor help someone decide on what is 'right' or
    'wrong' but rather just state the implications and how to get around them,
    no matter what the decision was based on.

    The passage below is a compilation of a discussion between myself and Todd
    J. Heron, MVP, from exactly one year ago to this date.
    Classic question:
    "Which are the advantages of naming my domain with rather than
    domain.local? I have a registered for my Company that i use for
    my e-mail and Site Internet."

    There are different answers to this classic question and while these answers
    ultimately depend upon company preference, much of the direction will be
    based upon administrator experience. The three basic scenarios outlined
    below are the most commonly given answers to the question, sometimes
    altogether and sometimes not. Some company networks use a combination of
    these scenarios. When explaining it to a relative beginner asking the
    question, many responses omit explanatory detail about all the scenarios,
    for fear of causing more confusion.

    All three approaches will have to take both security and the end-user
    experience into perspective. This perspective is colored by company size,
    budget, and experience of personnel running Active Directory and the network
    infrastructure (mostly with respect to DNS and VPN). No one approach should
    be considered the best solution under all circumstances. For any host name
    that you wish to have access from both your internal network and from the
    external Internet you need scenario 1, although it is the most DNS-intensive
    over time. If you do not select this option and go with scenario 2 or 3
    only, consideration will have to be given to the fact that company end-users
    will need to be trained on using different names under different
    circumstances (based on where they are (at work, on the road or at home).

    Scenario 1.
    Choosing the same name internal/external (spilt-zone, or split-brain,
    whatever you want to call it) has the most administrative overhead. Why
    chosen? Either because a misunderstanding of the pros/cons, political, or
    for ease of use.

    1. Their email address is their logon name. Easier to remember.

    2. Security. Each DNS zone is authoritative for the zone of that name so
    therefore the external DNS zone and internal AD/DNS zone will NOT replicate
    with each other thereby prevent internal company records to be visible to
    the outside Internet.

    3. Short namespace. Users don't have to type in (or see) a long domain
    name when accessing company resources either internally or externally.
    Names are "pretty".

    1. Administrative overhead. If trying to get to your externally hosted
    website, it won't resolve because a DNS server will not forward or resolve
    outside for what a zone that it hosts. You can overcome resolving the dilemma by using a delegation. Rt-click your zone, new
    delegation, type in 'www' and provide the public SOAs for the nameserver(s).
    This way it will send the resolution request to the SOA and resolve that
    way. As for, that is difficult and would instruct all
    users to only use This is because of the LdapIpAddress, the
    record that shows up as (same as parent), which EACH domain controller
    registers. So if you type, you will round robin between
    the DCs. To overcome that, on EACH DC, install IIS, then under the default
    website properties, redirect it to and let the delegation
    handle it. Now if you were to be using Sharepoint services, or something
    else that connects to the default website (no sub folders or virtual
    directories), then it becomes a problem. I know numerous installations setup
    with this and have operated fine for years.

    2. Security. Each DNS zone is authoritative for the zone of that name so
    therefore the external DNS zone and internal AD/DNS zone will NOT replicate
    with each other thereby prevent internal company records to be visible to
    the outside Internet.

    3. Any changes made to the public DNS zone (such as the addition or removal
    of an important IP host such as a web server, mail server, or VPN server)
    must added manually to the internal AD/DNS zone if internal users will be
    accessing these hosts from inside the network perimeter (a common

    4. VPN resolution is problematic at best. Company users accessing the
    network from the Internet will easily be able to reach IP hosts in the
    public DNS zone but will not easily reach internal company resources inside
    the network perimeter without special (and manual) workarounds such as
    maintaining hosts files on their machines (which must be manually updated as
    well everytime there is a change to an important IP host in the public
    zone), entering internal host data on the public zone (such as for printers,
    SRV records for DCs, member server hosts, etc), which exposes what internal
    hosts exist, or they must use special VPN software (usually expensive), such
    as Cisco, Netscreen, etc, which is more secure and reliable anyway.

    For further reading on this scenario:

    Scenario 2.
    Choosing a child name or delegated sub domain name of the public zone. This
    is one recommendation. Name such as '', or
    ''. The AD DNS domain name namespace starts at and has nothing to do with the zone.

    1. Mimimal administrative overhead.

    2. Forwarding will work.

    3. The NetBIOS name will be 'AD' or 'CORP', depending on what you chose and
    what the users will see in the three-line legacy security logon box.

    4. Like Scenario 1, this method also isolates the internal company network
    but note this at the same time is also a disadvantage (see below).

    5. Better than Scenario 1, internal company (Active Directory) clients can
    resolve external resources in the public DNS zone easily, once proper DNS
    name resolution mechanism such as forwarding, secondary zones, or delegation
    zones are set up.

    6. Better than Scenario 1, DNS records for the public DNS zone do not need
    to be manually duplicated into the internal AD/DNS zone.

    7. Better than Scenario 1, VPN clients accessing the internal company
    network from the Internet can easily navigate into the internal subdomain.
    It is very reliable as long as the VPN stays connected.

    1. Confusion on users if they decide on using their UPN.

    2. While there is security in an isolated subdomain, there is potential for
    exposure to outside attack. The potential for exposure of internal company
    resources to the outside world, lies mainly in the fact that because when
    the public zone DNS servers receives a query for, they will return the addresses of the
    internal DNS servers which will then provide answers to that query.

    3. Longer DNS namespace. This may not look appealing (or "pretty") to the

    4. Security. We are assuming that we can only access the internal servers
    thru a VPN and assuming they are in a private subnet, they won;'t be
    accessible. Also assuming to secure the VPN with an L2TP/IPSec solution and
    not just a quick PPTP connection. If this is all so, we can assume it is
    secure and not accessible from the outside world.

    The scenario is the recommendation from the Windows Server 2003 Deployment
    Guide. It states to the external registered name and take a sub zone from
    that as the DNS name for the Forest Root Domain:


    Scenario 3. Choosing a different TLD: Choosing a different TLD, such as
    domain.local, domain.corp,, etc. This option is usually best for
    either beginners or the expert, because it's the easiest to implement
    primarily because it prevents name space conflicts from the very beginning
    with the public domain and requires no further action on your part with
    respect to that.

    But this option does makes VPN resolution difficult (like option 1) and
    Exchange headers when examined closely will show the company internal AD
    name which looks unprofessional. You can use any extension you want here
    such as .ad, .int, .lan, etc...

    1. Easy to implement with minimal administrative overhead. Requires minimal
    action on administrators.

    2. Prevents name space conflicts with external domain name.

    3. Forwarding works.

    1. Domain name may look unprofessional.

    2. VPN resolution difficult (like option 1). That can be a sticky issue and
    depending on the VPN client will dictate whether it will work or not. I know
    one of the other MVPs (Dean Wells) created a little script to populate a
    user's laptop or home PC's hosts file with the necessary resources and would
    remove them once the VPN is dissolved.

    3. Exchange HELO name must be altered (to accomodate anti-spam, SPF, and RBL
    software), via MetaEdit, Metabase Explorer and thru the SMTP VS properties.

    For a broad overview of this entire topic, see below.

    DNS Namespace Planning;en-us;254680

    Assigning the Forest Root Domain Name:

    I hope that helps

    Innovative IT Concepts, Inc
    Willow Grove, PA

    This posting is provided "AS-IS" with no warranties or guarantees and
    confers no rights.

    Ace Fekay, MCSE 2003 & 2000, MCSA 2003 & 2000, MCSE+I, MCT, MVP
    Microsoft MVP - Directory Services
    Microsoft Certified Trainer

    Having difficulty reading or finding responses to your post?
    Instead of the website you're using, I suggest to use OEx (Outlook Express
    or any other newsreader), and configure a news account, pointing to This is a direct link to the Microsoft Public
    Newsgroups. It is FREE and requires NO ISP's Usenet account. OEx allows you
    to easily find, track threads, cross-post, sort by date, poster's name,
    watched threads or subject.
    It's easy:

    How to Configure OEx for Internet News

    Infinite Diversities in Infinite Combinations
    Assimilation Imminent. Resistance is Futile
    "Very funny Scotty. Now, beam down my clothes."

    The only constant in life is change...
    Ace Fekay [MVP], Aug 1, 2006
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.