Windows Tip Sheet

Decommissioning Domain Controllers

Even after removing your old DCs, the event logs might be lying about. Here's how to kick them out.

I've been working with a company that's redoing their infrastructure. As part of the redesign, they're doing away with a lot of old domain controllers (DCs) and putting new ones online (and they just realized they'll do this again when Windows Longhorn Server comes out, because they plan to deploy all domain controllers under Server Core...but that's late next year at best, so on with the show...).

However, many of the old DCs were performing other functions, too, so the computers won't be going away. After running Dcpromo to remove Active Directory (why can't that tool be called Dcdemo, as in "demote?"), and removing the DNS Server software (which several of the DCs run), they realized the computers still had the old DnsEvent, NTDS and NtFrs event logs. They weren't doing any technical harm by leaving the logs there, but it was confusing their auditors, who kept trying to treat the machines as DCs just because those logs were present.


The first step to removing those logs is to stop the EventLog service...which, er, you can't stop. So the first thing to do is modify the registry (be careful!) by changing HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\EventLog. Change the DWORD value named Start to have a value of 4. Restart the computer (it'll complain mightily about service failures; ignore ‘em). Now you can delete the event logs: They're under \Windows\System32\Config, named DnsEvent.evt, NTDS.evt and NtFrs.evt. Delete their registry keys, too: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\EventLog; delete the subkeys named Directory Service, DNS Server and File Replication Service.

Finally, go back to that original registry key and change the Start value back to 2, and reboot. That should do the trick. Of course, be sure this action gets logged for the auditors: Messing about with event logs is the kind of thing that needs to be documented, especially if your organization is subject to security-related legislation or industry requirements.

About the Author

Don Jones has more than a decade of professional experience in the IT industry. He's the author of more than 30 IT books, including Windows PowerShell: TFM; VBScript, WMI, and ADSI Unleashed; Managing Windows with VBScript and WMI; and many more. He's a top-rated and in-demand speaker at conferences such as Microsoft TechEd and TechMentor, and writes the monthly Windows PowerShell column for Microsoft TechNet Magazine. Don is a multiple-year recipient of Microsoft's Most Valuable Professional (MVP) Award with a specialization in Windows PowerShell. Don's broad IT experience includes work in the financial, telecommunications, software, manufacturing, consulting, training, and retail industries and he's one of the rare IT professionals who can not only "cross the line" between administration and software development, but also between IT workers and IT management.

Reader Comments:

Fri, Jul 7, 2006 congthai vietnam

who is that?

Wed, Jul 5, 2006 Anonymous Denver

Thanks Don. M$ didn't fix this even in SP1 ? Wow - I guess leaving the DC-related event logs on a member server after the demotion makes perfect sense to devlopers in Redmond !

Wed, Jul 5, 2006 Anthony Work

You can do the Jedi mind trick of running at at command to start a task. The task could be a batch file that stops the services service. Sure this is a hack, but it is a way to prevent having to shut down the server. You can then do the hack to restart it. I have done this in the past when I had a service I needed to stop but couldn't because it required me to be running as system.

Add Your Comment Now:

Your Name:(optional)
Your Email:(optional)
Your Location:(optional)
Comment:
Please type the letters/numbers you see above