Announcement

Collapse
No announcement yet.

Domain Controller redundancy

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • Domain Controller redundancy

    Hi all,

    I have a few queries regarding redundancy.

    We have a setup comprising of the following:

    Domain Controller DC 1 – Win 2003 std
    • Global Catalog
    • AD, DNS and DHCP


    All Files Servers – Win 2000

    Backup – Symantec Backup Exec 11d

    All Servers have Backup Agents installed and we backup the System State and all the data folders.

    For redundancy we have setup another Domain Controller as follows:
    Domain Controller DC 2 working as a Replication partner– Win 2003 on Dell Hardware
    • Global Catalog
    • AD and DNS



    In the event of DC1 failure -

    Since DC 2 is working as a replication partner, will DC 2 automatically take over the function of a normal DC ?

    Will the users have any problem related to login and access to FIles Servers ?

    What about FSMO roles ?.

    Is there a way to have a redundant DHCP services ?

    Kindly give your valued suggestions.

    Cheers,

    Pankajb

  • #2
    Re: Domain Controller redundancy

    The second domain controller provides redundanticy in case the first should go down. Meaning that the authentication process will not be disrupted.
    As the second DC is also a dns server, it will ensure that DNS resolution will still be done in case if DC1 goes down.
    Regarding the FSMO roles, these roles do not fit in a Multi master operation model and must therefore only exist on a single server in any single time. As DC1 was probably the fiorst domain controller in your forest domain, this will hold all FSMO roles.

    "Wiki:
    By default AD assigns all operations master roles to the first DC created in a forest. If new domains are created in the forest, the first DC in a new domain holds all of the domain-wide FSMO roles. This is not a satisfactory position. Microsoft recommends the careful division of FSMO roles, with standby DCs ready to take over each role. When an FSMO role is transferred to a different DC, the original FSMO holder and the new FSMO holder communicate to ensure no data is lost during the transfer. If the original FSMO holder experienced an unrecoverable failure, you can force another DC to seize the lost roles; however, there is a risk of data loss because of the lack of communications. If you seize an FSMO role instead of transferring the role, that domain controller can never be allowed to host that FSMO role again. Corruption can occur within Active Directory. FSMO roles can be easily moved between DCs using the AD snap-ins to the MMC or using ntdsutil which is a command line based tool.

    Certain FSMO roles depend on the DC being a Global Catalog (GC) server as well. For example, the Infrastructure Master role must not be housed on a domain controller which also houses a copy of the global catalog in a multi-domain forest (unless all domain controllers in the domain are also global catalog servers), while the Domain Name Master role should be housed on a DC which is also a GC. When a Forest is initially created, the first Domain Controller is a Global Catalog server by default. The Global Catalog provides several functions. The GC stores object data information, manages queries of these data objects and their attributes as well as provides data to allow network logon.

    The PDC emulator and the RID master should be on the same DC, if possible. The Schema Master and Domain Name Master should also be on the same DC. To provide fault tolerance, there should be at least 2 domain controllers available within each domain of the Forest. Furthermore, the Infrastructure Master role holder should not also be a Global Catalog Server, as the combination of these two roles on the same host will cause unexpected (and potentially damaging) behaviour in a multi-domain environment.(see "Phantoms, Tombstones and the Infrastructure Master", 248047)"

    So if your first DC goes down, and can not be brought online again (distroyed, burned out, whatever). You should seize the FSMO roles usssing NTDSutil. If the server can be restored, recovered tha, do not seize the FSMO roles.

    Regarding DHCP:
    If your set your lease periode to the default of seven days, you will have a minimum of Three and a half days before clients might run out of IP's. This means that you have three and a half day to setup up or recover your DHCP server, before clients are forced to release there IP address.
    This because a client will try to renew its leased IP when 50% of the lease periode has expired, if no DHCP server is available, it will keep its IP. It will keep trying to renew it lease untill the lease periode expires. If the lease periode expires, it will drop its IP and use an APIPA address instead (169.XXX.XXX.XXX).
    [Powershell]
    Start-DayDream
    Set-Location Malibu Beach
    Get-Drink
    Lay-Back
    Start-Sleep
    ....
    Wake-Up!
    Resume-Service
    Write-Warning
    [/Powershell]

    BLOG: Therealshrimp.blogspot.com

    Comment


    • #3
      Re: Domain Controller redundancy

      Hey Killerbe,
      Many thanks for the reply with great explanation on FSMO role.


      Killerbe quoted:
      The second domain controller provides redundanticy in case the first should go down. Meaning that the authentication process will not be disrupted.
      As the second DC is also a dns server, it will ensure that DNS resolution will still be done in case if DC1 goes down.
      I am quite happy to know this.

      Killerbe quoted:
      So if your first DC goes down, and can not be brought online again (distroyed, burned out, whatever). You should seize the FSMO roles usssing NTDSutil. If the server can be restored, recovered tha, do not seize the FSMO roles.
      I haven't had the misforture yet , however, I am a bit confused about how to sieze FSMO role if the DC 1 decides to commit suicide and cannot be brought back.
      What I mean is that, can you seize roles from a dead DC ? Sorry, if I am being stupid to ask such a question

      Killerbe quoted
      Regarding DHCP:
      If your set your lease periode to the default of seven days, you will have a minimum of Three and a half days before clients might run out of IP's. This means that you have three and a half day to setup up or recover your DHCP server, before clients are forced to release there IP address.
      This because a client will try to renew its leased IP when 50% of the lease periode has expired, if no DHCP server is available, it will keep its IP. It will keep trying to renew it lease untill the lease periode expires. If the lease periode expires, it will drop its IP and use an APIPA address instead (169.XXX.XXX.XXX).
      My default lease period is setup for 7 days so I have a week to bring up my DC 1.


      However, if disaster strikes and I am unable to bring the DC 1, kindly advise me on the steps to be taken ?

      My understanding are as follows but would like to have experts opinion.
      • Seize all FSMO roles on DC 2
      • Install a new Server and call it DC 3
      • Promote DC 3 as a Domain Controller and convert it to replication partner.
      • Re-install DHCP and restore DHCP database
      • Rename DC 2 to DC 1


      Would be helpful if anyone in the forum has gone through such misfortune and share the experience.

      Cheers,

      Pankajb

      Comment


      • #4
        Re: Domain Controller redundancy

        You don't need to go through all that exactly as you've described it. As far as seizing the FSMO roles is concerned, yes you can do it even if DC1 is dead. In fact, you would typically only seize the roles if the DC is dead. If it isn't dead you wouldn't seize the roles you would transfer them. For specifics on seizing the FSMO roles follow this article:

        http://support.microsoft.com/kb/255504

        If DC1 can be recovered you can still have DC2 seize the roles without any problem. There's no rule that says any particular DC has to have the roles, any DC can have the roles.

        As for DHCP, the default lease period is 8 days unless you changed it. You can do a couple of things:

        1. Install DHCP on DC2 and configure it like DC1 then set the DHCP service to the manual startup state and stop the service. IF DC1 fails, then set the DHCP service on DC2 to the automatic startup state and start the service.

        2. Restore the DHCP database from DC1 to DC2. Note that this will not restore the DHCP configuration settings. To do that you should do a google search for "moving or restoring DHCP to another server".

        As for "converting" DC3 to a replication partner, you don't need to do anything manually, the DC's will take care of themselves as far as replication is concerned. You should make sure that if you are in a single domain forest that all of your DC's are also GC's.

        As for renaming DC2 to DC1 there's no need to do this as far as AD is concerned. As long as you seize the FSMO roles to DC2 or DC3 there's no need for DC1 to exist anymore. The only reason you might need to do this is if DC1 was also a file server or provided some other "service" that relies on being able to find a computer named DC1. If that's the case there a several things you can do to make DC2 impersonate DC1.

        Comment


        • #5
          Re: Domain Controller redundancy

          "If DC1 can be recovered you can still have DC2 seize the roles without any problem. There's no rule that says any particular DC has to have the roles, any DC can have the roles."

          Correction:

          If DC1 goes offline, and you seize the FSMO roles to DC2. DC1 cannot be brought online again. If the server does seem salvagable afterall, you can only format it and reinstall the OS/Roles.
          [Powershell]
          Start-DayDream
          Set-Location Malibu Beach
          Get-Drink
          Lay-Back
          Start-Sleep
          ....
          Wake-Up!
          Resume-Service
          Write-Warning
          [/Powershell]

          BLOG: Therealshrimp.blogspot.com

          Comment


          • #6
            Re: Domain Controller redundancy

            Originally posted by pankajb View Post
            Is there a way to have a redundant DHCP services ?
            You might want to look into the 80 / 20 rule for DHCP:

            http://www.microsoft.com/technet/pro....mspx?mfr=true

            Michael
            Michael Armstrong
            www.m80arm.co.uk
            MCITP: EA, MCTS, MCSE 2003, MCSA 2003: Messaging, CCA, VCP 3.5, 4, 5, VCAP5-DCD, VCAP5-DCA, ITIL, MCP, PGP Certified Technician

            ** Remember to give credit where credit is due and leave reputation points sigpic where appropriate **

            Comment


            • #7
              Re: Domain Controller redundancy

              Hi Everyone,

              I consider myself extremely fortunate to be able to post my query in the forum last week and get such awesome replies with suggestions and wealth of information.

              Sometime strange and peculiar incidents happen and I thought I would post this and thank you all.

              While in the process of communicating on Domain Controller Redundancy for last few days, due to some unforeseen reason our Blade Server crashed during the weekend and therefore making our DC1 go offline for the first time since installation.

              This is a real life situation and as you’ll have mentioned my Replication partner ie DC2 would take care of the disaster.

              It indeed took care and following are my observations:
              • Login took quite sometime
              • While I was checking NTFS permission on the File Server, it took quite some time to display the users names.
              • No issue with IP address as the lease duration was still valid.


              Had it been earlier, I would have panicked and stressed myself beyond limits while driving to office. But with the latest knowledge acquired from the posting, I gained enough confidence and knew what to do.

              Credit goes to you all.

              Thanks a million.

              Cheers,

              Pankajb

              Comment

              Working...
              X