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


Altiris Error 1326

One of those beautifully informative error codes. I must be getting slow, this one took an hour to figure out….

I have changed all the jobs on a customers site to use a UNC for the sofitware source. The customer has a disaster recovery site with full functionality so it was logical to replicate all the software source there (and keep it in sync with DFS-R). This source is also a share on the Altiris DS deployment share.

Right – time to create a new package. I’m probably a bit old fashioned but I copy the source files from the share to the target and then execute an install. Like most admins, my workstation is the usual “guinea pig” for most jobs but I kept getting “Error 1326”. About an hour later, after trawling the net – here was the answer.

I use a special account to execute the install job but I already had a connection to the deployment server. Once the job began, the special account tried to connect and failed, with Error 1326. You can’t have 2 different accounts connecting to the same target from the one workstation. Basic you say… basic enough to get me!

As soon as I took the blinkers of and executed somewhere else then BINGO! job executes.