On Tue, Oct 17, 2017 at 1:06 AM, Michael B. Smith <mich...@smithcons.com> wrote: > 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.
This hasn't been my experience with workstations - when I remove one from the domain via the GUI, the account is gone. I haven't done this via Posh before this, however, and this was a DC. I must say that I haven't manually removed DCs very often (haven't in about 3 years), so my memory is dim on that - and it's almost as rare that I need to decommission a server. And when I last demoted a DC, we surely didn't have any problems with the GPOs. > Also generally speaking, I've commonly seen artifacts remain in AD and DNS > when demoting DCs and removing Exchange and removing Lync/SfB servers. This was just a DC - nothing special about it, though we do run Exchange 2010 and SfB 2015. So, I'm still somewhat baffled, but it's all recovered, AFAICT. Kurt > -----Original Message----- > From: listsad...@lists.myitforum.com [mailto:listsad...@lists.myitforum.com] > 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 > <michealespin...@gmail.com> wrote: >> Interesting... did something odd happen? >> >> -- >> Espi >> >> >> On Mon, Oct 16, 2017 at 4:25 PM, Kurt Buff <kurt.b...@gmail.com> 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 >>> >>> >> > >
