Code in the head

While working on Group Policies over the last few months, I’ve had occasion to do a lot of work within the Active Directory (AD), especially the creation and deletion of user accounts, on a fairly regular basis. When I first started working on domains, I’d quickly realised that scripting was the way to go, but to be honest I was a Visual Basic (VB) developer and looking at the fields of C code, or whatever it was that populated the scripting area at Microsoft, left me fairly cold. I’d often write VB applications to carry out tasks that could have easily have been scripted, but it was quicker for me do it in VB. Over time, things improved in the scripting area at Microsoft, until you could easily be forgiven for wondering which script language to use from the many that had appeared. I still feel that’s the case today, but I’ve resolutely stuck to my VB roots and this has paid dividends over time as VBScript is, to my mind, the easiest way to get down and dirty with AD.

This came to mind recently while I was working on the Group Policy articles I’ve recently written, and came to the forefront when a colleague at another school asked for help with adding a huge number of items to a new AD schema. It’s one thing being an admin demon, but often quite another being a code king. I really struggle sometimes when faced with some of the application installation scripts, and I shamelessly copy stuff I find on the web just to get the job done. My colleague pointed out that he knew several admins who were comfortable with everything except for writing scripts, so I thought I’d devote a column to showing everyone who’s unsure just what can be achieved with a few lines of code, and perhaps inspire them to take their own first steps in this area. Bear in mind that scripts aren’t necessary for anything really – it can all be done by hand, but boy can a script make your life easier.

When I fiddle with Group Policies, I often create a ton of user accounts and then have to delete them. I need to create AD Groups, Organisational Units (OUs) and so on, then once they’re created I sometimes need to modify the attributes of a user account, and add items to it. If that sounds like your average day and you’ve been doing it by hand, eyes down for how to make the machine do the work for you. Let’s leap straight in at the deep end with a piece of code to create a new account for a user called ImaTest in an OU called TestUser in the stokecollege.co.uk domain, and then break it down into its component parts so you can see what’s going on:

Set objOU = GetObject(“LDAP://ou=TestUser,dc=stokecollege,dc=co,dc=uk”)

Set objUser = objOU.Create(“user”, “cn=ImaTest”)

objUser.Put “sAMAccountName”, “imatest”

objUser.SetInfo

This script perfectly illustrates the stages you have to go through to work with the Active Directory Scripting Interface (ADSI). It’s a four-step process (one of which is optional), and there’s no need for anonymity. The steps are:

1. Connect to an object (for example, an OU in a domain)

2. Carry out your task (for example, create a user in that OU)

3. Set any mandatory attributes required by the task (this is not always necessary)

4. Save what you’ve done

Step 1 equates to connecting to an OU called TestUser in the stokecollege.co.uk domain, Step 2 creates a user called ImaTest, while Step 3 sets the Security Accounts Name (sAMAccountName) attribute, and Step 4 saves the changes to Active Directory. I could write loads more about what’s going on here, but this isn’t a book on programming, it’s a quick and dirty look at scripting in AD. What’s even better is that you don’t actually have to learn a whole lot about scripting to be able to do many of the tasks you need, because a bunch of folk at Microsoft known as The Microsoft Scripting Guys have created a tool to write the code for you.