Moving OU structures out of the test network

Designing an Active Directory in a test environment is a good thing. However, doing so requires you to think through some extra steps. When the design is complete, then what? How do you move the setup from the test system into the live environment? One option would be to turn your test environment into your live environment. Another would be to do a backup and restore of Active Directory. The safest way is to manually recreate each item in the soon-to-be-live system. To me, these methods seem clunky and sometimes dangerous. I like clean and simple (why do I have to do all of the work instead of the computer?).

I ran across a situation like this recently. Over the course of several meetings we developed the “perfect” OU structure for our new AD. The old structure was not configured properly (no, OUs are not just folders and they aren’t the same as security groups). Once we got the new structure set up on a VM, I had a dilemma. I decided there must be an easier way. Enter PowerShell.
I used the PowerShell AD cmdlets from Quest (have I said how awesome these tools are recently?) to export all of my OUs from the test network into a CSV file. Since I like clean, I only took what I needed which was the DN and the Name. Here is the code:

get-qadobject -type 'organizationalUnit' select 'dn','name' export-csv 'c:\NewOUs.csv'

From there, I had a CSV that listed every OU my new domain would need. You would think I could just import the file into PowerShell and loop through it, but noooo. That would be too easy. You see, we need to know what the distinguished name is for the parent container. Some of you may be saying that I forgot to include that in my original query. There is a property called ParentContainer that you can get for an OU. It sounds good until you try to use it. That is when everything breaks. It seems that the ParentContainer property stores the data in path format (domain name\ou\ou\etc.) not Distinguished Name format. Not to worry, I had a plan. See if you can figure it out:

import-csv 'c:\ NewOUs.csv' foreach-object {new-qadobject -parentcontainer $_.dn.substring($_.dn.indexof(",")+1) -type 'organizationalUnit' -NamingProperty 'ou' -name $_.name}

What I did was I took the DN of the OU (which includes the OU itself in the name), and stripped off the first OU (which would be…the OU itself). I found where the first comma was then did a substring of the DN starting from the first character after the comma through the end of the string.

Every OU now populates into the fresh new domain controller. If you run this in a test environment (please don’t do it in live until you do – if you mess something up, don’t mention my name), you may see some errors as the script runs (if it is a fresh AD you are importing the structure to, you should see one error only). These errors can be ignored. What is happening is the system is detecting duplicate OUs and it errors out instead of overwriting an OU. That is a good thing. In a fresh system, the duplicate OU it finds is the “Domain Controllers” OU that ships by default.

Now that these commands have been set up properly, you will notice the added benefits they provide. What if you wanted to play around with changing your OU structure? No problem. Just export your current structure and import it into a test environment. Combine this with a user and group export through PowerShell and you could move over your entire AD easily without bringing over the baggage that sometimes comes with a backup and restore.

Automating Active Directory User Creation

I have been learning to use Powershell over the past few months. Every script I write, I write in Powershell so I can improve my skills. It has become aparent to me that the name is very appropriate. With very simple commands that even a (gasp) non-programmer can do, you can automate just about anything. Today, I automated a way to create users in Active Directory. The script (if I can call it that since it could all be done from one line) pulls in a CSV file that has been prepopulated with users, assigns the fields to AD attributes, and creates the users. It can put them in different OUs, assign an expiration date, and much more.

I did not tackle every user property, just what I thought was important for our organization. I'll probably even add a couple fields for us. The point, however, is that this is a more robust and fully-functional example of how to add multiple users to the domain easily. From here you could set up a script to pull information from your HR system and either dump it into the CSV file for processing or have it run the import directly.

Here is a link to the script.

Network Computer Inventory Script - Rough Draft

OK, so who hasn't seen a script or program that takes an inventory of your local computer (Belarc Advisor is a good example) or an entire network of computers (Newt works well)? Well, I like both of these options, but I wanted more control (and less cost) over the inventory. I did a little searching for a solution that utilized Powershell. I came across a solution from Peter Stone. I took his script, ripped it apart, and put it back together a little differently. His solution was designed to output the information to a html file and to the screen for the local computer only. It utilized WMI, which was perfect for my purposes.

My goal was to create a script that scanned a list of computers from one central computer, get a full inventory of computer features, and store them in an easy to access format for later use. I ended up using a free snap-in from Quest for accessing my Active Directory to get a computer list (I didn't feel like doing a recursive ADSI query when the tool from Quest was so easy to use).

The way this script works is that the AD is scanned for a complete list of computers. Each computer is pinged to see if it is online. If it is, a complete WMI scan is done to gather all of the values desired. The entire scan is written to an XML file with the computer's name as the file name.

This script is in (very) rough draft format. It works, it does the job fairly well, and it doesn't have any major bugs. However, the code isn't clean, some attributes are missing (like CD-ROM information), and some things could be done better (capture a list of computers that were missed for the next scan, etc.). I also am starting to develop a wish list of other ideas that I could do with this script (optional scanning of categories, optionally add all of the computers to one XML file instead of one per computer, etc.).

I am posting this script now so you can see it and dream with me. I will post the final version sometime next month, hopefully. Here it is.

Winter Scripting Games

This year I tried something new this year. I entered the Winter Scripting Games. I began by entering the VBScript contests (beginner and advanced) since I have had quite a bit of experience with VBScript. Within the first couple days, I had completed most of the contests. I decided to have some real fun with the competition. I didn't know Powershell or Perl when the contest started, so I challenged myself to learn Powershell and complete both the beginner and advanced contests for that scripting language before the deadlines. It was close a couple times, but I did it. I got a perfect score in all four categories (and the promise of a Dr. Scripto bobblehead to come).

The competition was a blast and I highly recommend it to any person who like to or wants to script. Check out the site (and the nice list of prizes). The Scriping Guys do a great job every year.