Moving a Windows Server 2012 Domain Controller

If domain B is being tossed out and does not have any use, you should be able to decommison the AD and DC aspects as you would normally.  Once that is done, the server will be just a computer, then you should be able to join it to the new one.

The amount of work and time though, I would be hard pressed to say you are saving any time by doing it this way vs. just re-installing the OS and your application being served.  Also, because it requires several reboots to fully remove AD, your users will still have to be either kicked out or just randomly get dropped when you restart.

I still recommend taking a weekend, have all staff commit any changes on a friday afternoon, make a back up of your application DB (most will have some sort of utility to easily do this if it is not actually a DB like SQL or Oracle), blow it out, re-install, update windows, let that run overnight, then come back Sat. and install/restore your application.

Thanks tsaico,

If I decommission the AD/DC aspects and it becomes "just a computer", then I assume it lives on the peer to peer workgroup?

I guess then getting it back to the original (proper) domain is just a reverse of above; but I'll also find out whatever challenges the ex-admin had in the process.

I can't (really) do a full re-install, since a 3rd party has spent resources getting their enterprise (accounting) s/w running on it to-date...

http://technet.microsoft.com/en-us/library/cc771839(v=ws.10).aspx
for removing the last domain

You will treat it like the last domain controller since it technically is.  

You may still be in a line of trouble though, depending on how the security/Application/DB was set up.  Since there are no local admins/users on a DC, the services and such may be tied to the user accounts of domainb\admin, which is different than domaina\admin.

What accounting software was set up?

It would help if we had the full citation of "issues" your ex-admin experienced.
Had he prepared the forest A for WS2012?
Had he prepared the domain A for WS2012?
(ADPREP.EXE ?)

If you cannot get through the "issues" then you might be looking at MIGRATION over to domain B.
The tool in this case is called "ADMT 3" - it can move users, groups, computers.
http://www.microsoft.com/en-us/download/details.aspx?id=8377

There's a guide available for ADMT migration, that you should read, understand and TEST before proceeding with Production migration.
http://technet.microsoft.com/en-us/library/cc974332(v=WS.10).aspx

On the issue of ADPREP.EXE, it no longer need be run before the first 2012 server is promoted in the environment... if it's needed, it will run as part of the AD DS configuration.  (That said, running it ahead of time isn't wrong or bad.  It used to be a necessary separate step.  It need not be now.)

Are domains A and B in the same forest or different forests?  If I had to take a guess, either the new computer wasn't able to talk to Domain A (could have been ports blocked, or the new server wasn't pointed to the old DC for DNS), or the administrator didn't have sufficient permissions to update the AD schema.  As has already been said, you'll very likely need to figure out what the cause was and fix it before you can integrate the parts back together.

And to answer the can you do it 'without much fanfare'?  Probably not.  I'd normally strongly suggest not running 3rd party software on the domain controller... and one of the reasons why not is that the domain controller doesn't have a 'normal' security system.  Any other server or workstation has local accounts and local groups on the system itself.  For normal operations, the DC doesn't have those, and relies exclusively on domain accounts and domain groups.  Without evidence to the contrary, I'd strongly suspect that is one of the reasons the 3rd party package may have been more complicated to get set up on the DC, and will break when it's DC configuration is changed.  :-(

Thanks for feedback all.  I don't know the "issues" the previous admin had; just a note that he had problems and was unable to introduce the new server into the existing domain.

The accounting s/w is Sage Timberline (I'm trying to find the services and extent of its needs throughout all this).

I'll digest above and try a few attempts to see what it does in the next week or so.  Will report back.

Much appreciated for feedback to-date.

Hehe, Good old Timberline, though they re-badged a bunch of their familiar products to Sage 100, Sage Contractor, Sage 300, etc.  Personally I wish they had stayed with the old naming convention, Peachtree, Masterbuilder, Timberline, etc.  I get why they did it, but I don't remember products well when they are just a number.  I have a bunch of construction groups that use this.  For the most part, it won't be too much to migrate it to a different server.  Mainly your actual database, your macros, your reports, and your attachments.

If you have some extra hardware to run a temporary VM, I have also made my Physical box a VM using VMware, ran it virtually for a few days, while I wiped the old box.  Then from the VM made my backup and subsequent migration.

Timberline (300 version?) is actually just recently setup/installed on the new 2012 server, so it's not being migrated anywhere to be clear; just the server membership itself should be moved back to the original domain A.

Yes, I think that was clear, but you still want to treat everything like a migration in case things do not go according to plan.  Also, since the services were installed to a DC, there are no local users, so security settings, what the services started might be gone, so it still won't start up correctly.

Not to mention you also are running the risk of hitting whatever the previous guy hit that prevented him from updating the old AD to accommodate W2012.  (though I am not sure what that would be if it is just a member server vs a DC.)

Because of the unknowns, I try to treat it as worst case scenario on something like this.

If you had another Windows Server 2012 then I would like to see if it can join domain B.
You may try it in a VM say, deployed in a Hyper-V somewhere.
If not...
Backup the new server,
then demote it, destroying the domain B.
Try to join the domain A, post the issue with screenshots.
Time to find out what the issue was.

Sorry no other server h/w to "experiment" with here.  While I haven't got my hands on this quite yet, I did get some feedback from the past admin (3rd hand) on what the original issues he had:

"2012 Essentials will not work  on an existing network... could not get it to join a domain with 2K3 DC... 2012 Essentials needs to be the only DC on the network... It will not allow you to make it a secondary DC and then upgrade it to primary. 2012 R2 that either just came out or is coming out (was in BETA in October) does allow you to have it as a secondary DC, but not sure if it will recognize Windows 2003."

Any comment on this?  I think he implied the solo 2K3 DC in the original domain was an issue to allow the new 2012 server to join, but anyone have comment or experiences here?

Thanks again everyone.

Hi all.  Finally got in to check it out, here's a few tidbits.  Original W2K3 server is:

- fine for domain/forest functional levels set to 2003.
- fine for netdom, dcdiag, and repadmin command line results.
- valid DNS.

So it would appear the new W2K12 server should be able to join this (while I have yet to removed the AD-related membership roles in its own domain), I did notice that new box's DNS did point to itself (vs. to the original server) so not sure if that might have been a misstep that caused this path to begin with.

Otherwise, I'll be using the new W2K12 server manager to remove the roles in the next few days, so let you know where it stands then.  Thanks for any feedback at this point.

J.

When using DCPROMO to make a server 1st DC in a new domain, it is setting DNS resolver to itself to make sure this part is right.
The server's DNS resolver must be pointed to a server that can resolve all records in the domain you're trying to join. If you insist on pointing to own DNS then few alternatives exist for proper DNS integration (forwarders, delegations, secondaries).
In your case it had to be a forwarder, since demoting a DC does not remove DNS server component and does not change DNS resolver settings (of course).

As of now, first demote the W2012 server, destroying the new unneeded domain,
then just retarget W2012's DNS resolver to your existing DCs in your valid domain.
Joining old domain should work like a charm :)

I think it is time to check AD health of your W2008 domain (is it separate from the WS2003 you mentioned in your first post?).

On both WS2008 and W2012 , try running

c:\> repadmin /replsummary

c:\> dcdiag

What domain and forest level it is running at?
Any peculiar errors in the Directory Service log?
Have you checked if the DNS records were properly created in _msdcs and _sites containers?

OK

Base on all feedback to-date.