AD restores

So i got an email from a client this morning saying “dont ask – but i have lost all of our staff users in AD – Help”

to cut a long story short, the guys had gone into exchange 2010 EMC – and tried to remove staff mailboxes (for another reason i wont go into) and actually removed everything, including the AD account. They claim the exchange right-click isnt clear – and i agree to an extent…. instead of “disable” and “remove” – which need to be interpreted…. how about “remove mailbox” and “remove user + mailbox” – much clearer…. anyhoo – thats off topic – and its not going to change anyway.

On to AD…. so these guys had done most of the right things – they had located a system state restore for a DC from the night before – a DC that wasn’t a CA or anything else that might be intefered with from a restore – and they had run a restore – but had no success.

Anyhoo – here is an official MS article that helps you out –

For the abridged version specifically for this client (they asked for this blog post)

First – Try ADRestore.Net and/or ADRestore…… nice article about those here…. –

At this client site – we found that using either of these tools bought the object back – but no group memerbships, or other details such as department, address etc. So that was really no good…. next option, an auth restore….

Restart your DC of choice in directory services restore mode (press F8 on boot up to see this option)

Run windows server backup… as appropriate…. now this screen is the one that got these guys confused

For some reason “perform an authortive restore of active directory files” does not perform an auth restore…. hey, maybe were doing something wrong – or maybe its just bad terminology again by MS and it means something else….. but i dont really care in this situation – so lets move on…

once the restore is complete – do not reboot

Open a command prompt and use ntdsutil….


activate server ntds

authoritative restore

if its a specific object you want to restore: restore object <object DN path>

if its an entire OU you want tro restore: restore object <OU DN path>

Reboot – done.

Domain controller snapshots

This has come up twice in the last few months – and amazed me each time…. i just always thought it was commonly knowledge that taking snapshot of a DC is jsut something you dont do…. but apparently not.

So – in order to point out that its not just me – here’s a couple of links!–heres-why-137306

If your wondering why all these people are saying dont do it… well your probably need to brush up on your AD understanding a little. Its to do with USN’s and computer password expiry in particular and some of the above articles can assist with that understanding.

Anyhoo – what i wanted to address was the reasons i hear for using a snapshot:

Q1) What if AD becomes corrupt?

A1) If a specific DC database becomes corrupt, then the result is that the directory services will not be able to start. I have never had, heard of, nor been able to find on google an instance of a corrupt AD database replicating to other DC’s. So demote the corrupt DC and then repromote it… ta-da! DC that now isnt corrupt. No need for a snapshot there.

Q2) But i only have 1 DC!?

A2) If your using virtualisation, its a fair bet that your of a reasonable size – hence why you have virtualisation in the first place, therefore, why the fuck would you only have one DC? You’d have to be insanely stupid… “give all our posessions away because some religious nutcase said the world is going to end” level stupid…

Q3) What if our site burns down?

A3) Well, firstly, is your primary concern going to be your AD? Anyhoo…. for those with a Hot/live/active (choose your favourite term) DR site, the obvious answer is to place a DC at your DR site. If you do not have a DR site or it is a cold DR site, then your best bet is system state backups. why? simply because using system state to perform a directory restore is a supported method of restoring your AD – a snapshot is not. So if you do get into trouble, you can call on us or MS or who-ever and know that you can get your AD back.

Q4) Im going to snapshot all 3 (or 7 or whatever) of my DCs!

A4) that sounds useful….. 3 copies of the same information!


In short – as per all the other articles…. no, do not snapshot your DC’s – no its not useful in any way, shape or form.

AD 2008 R2 – Recycle Bin

So i moved our domain up to 2008 R2 domain and forest functional level – all so i could have the excitment of enabling AD recycle bin.

Enabling AD recycle bin – powershell or LDP… not the friendliest, but fair enough…

But actually recovering the objects, LDP or powershell aswell… thats just not very user friendly! not when you want to be giving that type of task to helpdesk level staff.

*sigh* another feature of 2008 R2 which is a good idea but, in its current iteration, useless (just like Direct Access and its complete lack of meaningful logging)

Moving from 2000 FRS to 2003 R2 DFS-R

Today, i did my first ever gig migrating a Windows 2000 AD based DFS with FRS environment into a 2003 R2 DFS-R environment (should also be the same for a 2008/2008 R2 DFS environment). These ofcourse should be few and far between, because, well, if your still running 2000 and dont have a good reason (such as a contract with the federal government that stipulates you will deliver on win2000) – you have issues and shouldnt be spending time reading blogs.

Anyhoo, i found this method effective for moving a domain based root and its sub-folders across:

1) Leave the existing DFS namespaces intact

2) Add the new folder targets to the namespaces, but ensure that FRS replication is disabled (do this via the windows 2000 DFS admin tool), and referrals are disabled (for the time being)

3) Create the new folder structure on your hub (if your using hub and spoke)

4) Create your replication groups, schedules etc and allow appropriate time to replicate

5) After replication has completed, enable referrals for the now populated folder targets

6) Remove your old-school windows 2000 targets

All done.

AD Sites – a common misconfiguration

Over the past few weeks, i’ve been disturbed to run into a number of corporates that have configured their AD sites in strange ways… 

an example – Multiple sites around the country, DC’s in 10 locations, therefore 10 AD sites are defined and all subnets made a member of those 10 AD sites (irrelevant of if their LAN connected or not) – even though they cover 50+ physical sites.

First up – lets consider what AD Sites are used for

1) Replication between DC’s

2) Client location of DC’s

3) Applying group policy

4) Exchange 2007 (and probably 2010) routing

5) SCCM Boundaries (optional, but preferable IMO)

All geographical sites in your organisation should have their own AD site defined (even if there is no DC or other server at that site), this allows us to control AD and exchange traffic (via site link cost), apply group policy to specific locations (common location based policies are IE settings or WSUS policy) and setup SCCM boundaries which are updated centrally (via AD sites).

On a side note to this – applying GPO via AD Site is massively underused. All to often, admins go through the process of creating OU’s to put computer objects in based on location, all to apply WSUS settings. Not only does this require constant admin, but when a roaming user goes to office B for the week, they still pull their updates from office A!

AD Sites are there for a good reason – use them appropriately to reduce your network bandwidth usage.