Category Archives: Active Directory

Powershell – the 3 line quicky

I needed to change the profile path for a fair number of users in AD a go. Thought I’d give PowerShell a go. Talk about easy…. here it is.

Change the Profile Path for all users in an OU – the easy way

$users = Get-ADUser -filter * -SearchBase “ou=<yourOu>,dc=<yourDC>,dc=<yourDC>”

ForEach( $u in $users )


$ProfilePath = “\\<yourProfileServer>\<yourProfileShare>\” + $u.sAMAccountName

set-ADUser -Identity $uDistinguishedname -Profilepath $ProfilePath


Well – I lied – there are 4 lines of code. Talk about easy


Monitoring your Active Directory

Another interesting week. Client has 8 DCs distributed over 4 sites for AD management. Most of the time it works well – well enough so you don’t feel the need to be taking the pulse of the patient 24/7… BUT…. every so often, you have issues.

So… How to monitor. You are a small(ish) shop so there isn’t enough IT Operations bandwidth to monitor everything all the time. You can do several things.

– Invest in some COTS tools – Quest comes to mind – however there is a both an initial costs and these things need care and feeding as well. Often there are backend databases, specialist knowledge etc. Some of these things are more fragile than AD itself. If they break then often the solution is to completely re-install.

– Write something yourself – this is obviously where I’m going with this. WMI, Command line tools, vbscript, Powershell, performance monitor – there a is a stack of choices.

I’ve found something that seems to do the trick for me. Its “timesync” – MS DC’s rely on syncronised time for authentication. If your time between workstations, servers and DCs drifts out by more than 5 minutes the kerberos, GP etc all seem to stop.  The command you need to get to grips with is

W32tm  specifically the “/monitor /domain:<yourdom.dom>”  option. Give it a try in your domain and see – it will show you which DCs are syncronids

So I’ve written a simple HTML page in vbscript that parses the output – code to follow


Error 5871, ForestDNSZones and Top Level Domains

I hate this….

Ahh the life of a systems engineer.

You go to the trouble of fixing an error and 18 months later you are chasing down the same error again but forgetting that you fixed it before.

A customer of mine is running a classic root and child domain AD model. Issue was (and is) that the root domain only uses a “single label” top level domain (Imagine calling your internal root domain .com and you will get the idea.

Well MS – for good reasons – decided that AD will not, by default, update a SLTLD. Problem is that when you upgrade to 2003 and decide to store your DNS in a forest wide application partition then the partition name becomes “” which is a zone stored in a SLTLD.

OK issue is then the DCs in the child “” then try to update into partition which is inaccesible so hence stuff like the _MSDCS records (essential for cross site replication) don’t get updated.  The DCs then start to register Error 5871 messages.

Here’s where I hate this…

There is a Group Policy HKLM\Softtware\Policies\Network\DNSCLient (don’t quote me on this – its 12:47AM) which is supposed to be applied but mysteriously didn’t


I looked back at some notes and found I’d fixed this in the past.

Problem I have is that this link doesn’t come up in a search for “error 5871” until about page 14 (actually it doesn’t) so you would never find it.

After consulting a mate he said “remember the TLD issue”…… DOH.  The lights came on. Still don’t know why this one DC hasn’t updated from the Default DC GP (which has the entry) but the problem is fixed, the errors have dissappeared and I can stop worrying.

New data to hand, Windows 2008 R2 also will not update a SLTLD. There are 2 registry entries you need – they are (Conveniently in REGEDIT 5.0 Format)





Again – this fixes Event Error 4513