Announcement

Collapse
No announcement yet.

AD Restore to different Hardware

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

  • AD Restore to different Hardware

    Hi,

    I have been charged with covering a DR plan for our organisation and the first task is to restore AD to totally different servers mimicking a total site loss.

    We have 2 DC's, one on HP and one on dell hardware with FSMO roles split across the 2. Also, only one is a GC.

    I have managed to do a non authoritative restore but when I reboot I am asked to activate windows, despite the original O/S on the recovery machine being a volume license version, this complicates matters as I am obviously doing this off the network without internet access - has anyone experienced this before?

    I am assuming I will be able to seize the FSMO roles to the newly restored DC if it builds and runs OK.....?

    Finally, Does anyone know of any documentation for performing this process on 2003 AD? I can find 2000, but would rather a more up to date version.

    Thanks,

    Neil.

  • #2
    Re: AD Restore to different Hardware

    oepss mistake sorry
    (i deleted a link because it was about Windows XP.
    Although even Windows server 2003 do also have a file in %windir%\system32 called 'wpa.dbl', may you can use it to re-activate?)

    The best way to make a DR backup is to use the ASR - Backup feature of NTBackup


    \Rem
    Last edited by Rems; 22nd January 2007, 19:27. Reason: deleteled wrong link

    This posting is provided "AS IS" with no warranties, and confers no rights.

    __________________

    ** Remember to give credit where credit's due **
    and leave Reputation Points for meaningful posts

    Comment


    • #3
      Re: AD Restore to different Hardware

      OK well I have managed to perform the authoritative restore and get the server activated. Everything looks pretty OK except I cannot log onto the domain from my client in the lab with any user ID other than domain admin.
      I can see all of the users are present in ADUAC and seized all of Roles.....well, nearly all I can't get the schema master due to a strange access denied error, but I'll address that later!
      I've also removed the references to the other DC, all trusts and dns records I didn't want, currently having issues removing a child domain but I'm sure I'll find the remedy to that.

      I'm wondering if it's going to be easier going forward to restore the 2 DC's - the only problem being, when I tried to do a non auth restore of the other DC, the lab machine wouldn't boot afterwards

      Any help will be greatly appreciated.

      Thanks

      Neil.

      Comment


      • #4
        Re: AD Restore to different Hardware

        Originally posted by NeilM View Post
        OK well I have managed to perform the authoritative restore and get the server activated. Everything looks pretty OK except I cannot log onto the domain from my client in the lab with any user ID other than domain admin.
        This is expected if there are no GCs available. Make sure that the DC you restore is also a GC.
        Guy Teverovsky
        "Smith & Wesson - the original point and click interface"

        Comment


        • #5
          Re: AD Restore to different Hardware

          Are your DCs on different sites or on the same one?

          I think you were going the right way originally with the non-authoritative restore. An authoritative restore is an aggressive procedure. If you've got full system state backups of each server, you should be able to bring them both back online without too much hassle. Even if you can only bring one up, you should be able to seize all the missing roles and have a working DC by the end of the process.

          Unless of course, I've missed something about what you're trying to do here
          I nerd therefore I am!

          Comment


          • #6
            Re: AD Restore to different Hardware

            Originally posted by apparition2553 View Post
            I think you were going the right way originally with the non-authoritative restore. An authoritative restore is an aggressive procedure.
            If you are restoring only one DC into the DRP site, it does not matter whether the restore is authoritative or not - the only difference between those two is the fact that during auth restore SYSVOL is marked as authoritative and all the objects get their version number increased to make sure the restored data is replicated out to all other DCs.
            In the case of single DC there is difference at all.
            Guy Teverovsky
            "Smith & Wesson - the original point and click interface"

            Comment


            • #7
              Re: AD Restore to different Hardware

              Absolutely, yes. In Neils case though, it's going to be easier and quicker to do a non-authoritative one.

              What I was most concerned about was if Neil projects to perform an authoritative restore with two DCs on different sites (or even when only one DC on a single site dies) then he might accidentally cause problems as the restored DCs objects will take precedence and overwrite changes the other DC had made.
              I nerd therefore I am!

              Comment


              • #8
                Re: AD Restore to different Hardware

                Thanks for the replies all.

                I'll try to clarify things a bit.

                The reason for trying this exercise is that our DR company cannot guarantee to give us identical hardware in the event of a failure or site loss.

                We currently have 2 DCs in one site, one on dell h/w and one on HP. Only one is a GC (The HP). The FSMO roles are split as such:

                Dell - PDC, Infrastructure
                HP - RID, Schema, Domain Naming Master (also GC as mentioned)

                There is a child domain (we are in Cardiff UK, the child is in Sydney, AUS) which also has one DC which is a GC.

                I have now built another server and put Virtual server onto it. I have created 2 Virtual Servers and performed non auth restores. When the HP has completed the restore and I restart, it just seems to hang at the grey screen saying it's going into DS restore mode.

                As this is the GC, I have encountered the problems I described before. Would it simply be enough to restore the Dell DC, make it a GC and seize the roles?
                Or would it be better to make the Dell a permanent GC as well as this one seems to be the one I can restore the easiest.

                I've spent a week on this so far, what with having to rebuild the lab servers and everything else!

                Thanks Again!

                Neil.

                Comment


                • #9
                  Re: AD Restore to different Hardware

                  Restoring the Dell and seizing the roles should be enough to get you back up and running, yes. If you do that, remember not to bring the HP back online before you've re-installed it, ever!! You also need to pull the HP out of Active Directory forcefully (bit scary IMHO).

                  So ideally, you'd want to find out why the issues with the HP are occuring. Are you trying to restore the entire file system or just the system state? I've had more luck when restoring by installing the OS first of all, then restoring the system state from a backup. I'm wondering if you're having trouble because you're restoring the file system (drivers and all) onto different hardware.
                  I nerd therefore I am!

                  Comment


                  • #10
                    Re: AD Restore to different Hardware

                    If you ask me, I'd attack the problem from another angle. You might want to take it either further and create a so called "leg site".
                    The idea is like this:

                    1) Create a new site/subnet in production AD
                    2) Configure replication window of one hour during night (non-working) hours so that the DCs placed in this site will replicate only during that timeframe
                    3) Install and promote a DC inside VS and place it in the "leg site"
                    4) Make the "Leg DC" a GC

                    What you get:
                    1) in the case of disaster you can easily restore the virtual DC to the same hardware (as a guest in VS) and seize all the FSMO roles to it.

                    2) If someone accidentally makes a mistake during work hours that requires a restore of an object, you can go to the leg site's DC and as the replication (the tombstone has not replicated to the leg DC) has not yet reached the leg DC (remember the replication windows from above), you can put the virtual DC in DS Restore Mode and authoritatively restore the object (will bump up the version number of the object and as a result of that the tombstone that will get to the leg DC will not delete the restored object).

                    This way you get a quick restore time in the case of disaster (no need to mess with storage drivers, etc...) and will provide you the means of dealing with some nasty mistakes that can happen.
                    Guy Teverovsky
                    "Smith & Wesson - the original point and click interface"

                    Comment


                    • #11
                      Re: AD Restore to different Hardware

                      Once again, thanks for the replies and suggestions guys.
                      Apologies in advance for the essay I am about to write.....

                      I have now sucessfully restored the "HP" to a dell box. I moved away from the virtual servers as there were issues with drivers and internet connectivity for activation.

                      I was hoping I would have some success as I couldn't believe that this scenario wasn't catered for.

                      For the record:
                      I have the System State backup from both DC's. I built a new server off the network and performed a non-authoritative restore to the box. I let it reboot a couple of times in safe mode to ensure that all of the drivers were in place then booted up normally.
                      It took about 30 minutes to go through the process, especially during the applying computer settings. Once in I remembered that I hadn't disabled the services that wouldn't run without network connectivity (AV, Auditing etc) and rebooted again. The first time I had a problem with the KDC service not starting so I went back in to DS restore mode to attempt an NTDSutil operation.

                      I had the error "DSBindw error 0x6d9 - there are no more endpoints available from the endpoint mapper" - so went and researched this.

                      Whilst trying to rectify the issue, I rebooted again and somehow it seemed to work this time - not the best end result, but a result nonetheless.

                      I seized the FSMO roles and have successfully logged a machine onto the restored domain.

                      All in all it has taken me over a week to achieve this so I think I'll be looking into tools that could help with the process.

                      Thanks again

                      Neil.

                      Comment

                      Working...
                      X