Generally speaking, if you remove a server from a domain the computer account is disabled. That's all. You've ALWAYS gotta clean it up.
Also generally speaking, I've commonly seen artifacts remain in AD and DNS when demoting DCs and removing Exchange and removing Lync/SfB servers. -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Kurt Buff Sent: Tuesday, October 17, 2017 1:24 AM To: ntsysadm Subject: Re: [NTSysADM] Pro tip for you: free... You might say that. This happened on Saturday the 8th. When you log into the target DC, and issue the Posh commands to demote and remove the computer from the domain, it does. (https://technet.microsoft.com/en-us/library/hh974714(v=wps.630).aspx). The DC ends up in a workgroup with the same name as the domain. But, if the computer account is protected from accidental deletion, it doesn't kill the account in the domain, so you have to go back and clean up. This was our physical 2012R2 DC - the others (one in HQ and one in each office overseas, all 2012R2) are VMs. I can't say for sure what caused it, but somewhere during this process about 10 out of the 70+/- GPOs got fubared, and I had to recover them - something I've never had to do before. Thank all the gods (and decent planning!) that I had snapshot backups of the DC holding all of the FSMO roles, and could mount the VMDK and pull out the sysvol directory and copy them back from the Friday night backup. Among other things, the damaged/empty/screwed up GPOs were applied to our DirectAccess server, which promptly decided it wasn't one anymore, and to a fair number of the DirectAccess clients, when then couldn't connect again, even after the DA server was put back together. We had to walk a number of people in the field through connecting to our SSL VPN and doing a 'gpupdate /force' to get them going again. There was also a mishmash of other problems, including drive mapping oddities, printer sharing oddities and other weird crap that had to be sorted. It was not a good time last week. One or more of the following could have caused the problem: - Maybe because I replaced the DC by formatting the disk and re-installing with the same name and IP address (doubtful) - Perhaps it was because during this process I replaced the old 2012R2 DC with a 2016 DC. (maybe - seems unlikely) - Perhaps it was when I tried to introduce the new 2016 machine into the domain and I discovered that the old account was still there (more likely than the first two) - Perhaps it happened during the cleanup after the failed domain account deletion during the demotion process (this seems most likely to me) - Or some combination thereof. - Or the phase of the moon and a lack of chicken blood. Kurt On Mon, Oct 16, 2017 at 7:09 PM, Micheal Espinola Jr <[email protected]> wrote: > Interesting... did something odd happen? > > -- > Espi > > > On Mon, Oct 16, 2017 at 4:25 PM, Kurt Buff <[email protected]> wrote: >> >> When you demote a DC, you really should make sure that the computer >> account in the domain isn't protected against accidental deletion. >> >> Further deponent sayeth not. >> >> Kurt >> >> >
