2

I have somewhat of a unique challenge, I'm trying to migrate a old legacy server from a locally installed version of Active Directory Domain Service to a centrally managed AWS Directory Service. As part of this migration I will be replicating the user accounts over from this same server to this new service (via a series of powershell scripts). While this process won't bring over the users passwords, most of the structures will be brought over automatically (Users/Groups/OU's/etc...) via the scripts.

I'd like to integrate this migration into my DevOps framework (this includes the need to create a automated rollback script). However as part of the migration process via a powershell script I will need to remove the locally installed version of AD and join the server to the new centrally managed service. As part of that process, I believe that I will lose any information currently stored in the AD's (preventing me from rolling back).

Is there any way to save this information (including passwords) short of imaging the whole server, or this complicated process involving other servers and ADMT etc.., so that if I wanted to undo my migration to the new service I could simply run some sort of script and have the server restored to the pre-migrated version, with the local AD server still installed and my credentials still preserved.

I feel that this should be possible, what I'd really like is to somehow disable (but not uninstall) the AD service on the local server, then join it to my centralized domain service, then if I need to rollback, re-enable my AD service and rejoin to it locally.

Searching around doesn't appear to generate any leads on "disabling" the "Active Directory Domain Services" Role, however there is certainly allot of discussion around the uninstallation process. Maybe one of these options will preserve the AD's configuration somewhere (so that if I reinstall it, it will still be there)?

David Rogers
  • 215
  • 1
  • 11
  • 1
    Side note: if this is a unique challenge, why do you want to automate it? It's quite unlikely you'll need to repeat the process on another server. And even if that happens, there would surely be several details that would require you to revise and tweak the process. Automating something that's inherently non-repeatable doesn't really make much sense, IMHO. – Massimo Jun 11 '20 at 19:38
  • @Massimo Because I have many servers I want to roll the same change out to each of them, they're basically all copies of the same image, but they each have there own AD instances and set of credentials that they manage, I rather have my DevOps process run one testable repeatable script then attempt to perform this by hand on many different servers (time saved alone would justify the automation in my mind, architecture and testing considerations aside). – David Rogers Jun 11 '20 at 20:06
  • 1
    In my experience this scenario is quite unusual... but if you really have several instances of it, then of course it makes sense to look to automation. Unfortunately, what you wish to achieve is not "a change" that you can roll out... it's a full-fledged domain migration project. – Massimo Jun 11 '20 at 20:17

1 Answers1

3

You can't join a Domain Controller to a different Active Directory domain.

The whole Raison d'être of a DC is managing a domain, it's simply not possible to remove it from the domain it manages and/or join it to a different one. This is so critical for a DC that if AD services can't start properly, the server will simply blue screen.

In order to be able to move the server to a different domain you need to demote it, and in doing this you'll destroy the Active Directory database (which is not something you can simply copy somewhere else, the only way to take a backup of a DC is to perform a system state backup).

If you had more than one DCs (which you should), then you could demote and move one of them and, after testing that everything works, demote and move the other one (destroying the original domain in the process, because a domain exists only as long as there is at least one DC managing it).

But if you only have a single DC, as soon as you demote it the domain is gone, for good.

That said, if you have a single DC you are not concerned about replication issues; thus you can safely image it and restore the image if anything goes wrong.

Massimo
  • 68,714
  • 56
  • 196
  • 319