Recently I painted a few rooms in my house; the hardest part was the
preparation, washing the walls, filling the holes and putting on the
undercoat. It is the same when scripting Active Directory with PowerShell,
preparation is the key. You need to download PowerShell, install the
QAD snap-ins and set the execution policy. Once you have completed
this one-off preparation, the QAD cmdlets make scripting Active Directory
so much easier than using VBScript.
My ultimate goal is to reset passwords for a bunch of users using
PowerShell with the QAD snap-in.
However, as the saying goes, 'There is many slip between cup and lip'.
What I mean is if my readers aren't prepared, or misunderstand an
instruction then I can see them creating a PowerShell script that changes
the password for ALL their users. This would result in serious
embarrassment on a production network, especially if the network
administrator cannot remember the new password!
I hope that you now understand why my mission will be a two stage process.
These are my objectives for this week, firstly to install the QAD snap-ins.
Secondly, to create 'safe' scripts which merely get information
about the users, or set values only
in the insignificant 'Description' field.
Readers will be at different stage in their PowerShell career, I want
provide a checklist for the complete beginner, those with experience could
skip the first step(s).
a) Download, then install both PowerShell and .Net Framework (from
Microsoft's site) Note: XP, Vista, and Windows Server 200x each
requires a different version of PowerShell.
This week's featured command is Get-QADUser. Let us assume that you
have achieved objective 1, now this all you need to do before running my
script:
a) Connect to Active Directory, best would be to logon at a domain controller
in a test network. (Virtual PC?)
b) Find the variable $OU in my script; then amend its value to reflect
your domain and your Organizational Unit. You many need a little
extra work in creating an OU and a handful of users.
Example 1 - List Users in a Named OU
# PowerShell script to list
Active Directory users in a named OU # Author: Guy Thomas # Version 1.4
July 2008 tested on PowerShell v 1.0
Note 1: -SearchRoot is the key parameter which
connects to Active Directory.
Note 2: You did change the value of $OU -
didn't you? Also Remember that these QAD cmdlets don't exist in the initial PowerShell
install, they are only available after you successfully run: add-PSSnapin
quest.activeroles.admanagement. If your script does not work refer
back to Objective 1.
Example 2a - How to Discover the Names of a User Properties
These QAD cmdlets are designed to fit seamlessly into PowerShell, for
example we can apply our trusty interrogation techniques such as, get-help
get-QADUser.
# PowerShell script to list a User's
Properties # Author: Guy Thomas # Version 1.1 July 2008 tested on PowerShell v 1.0
get-Help get-QADUser
Note 1: I suggest you try my parallel learning
technique and match the user properties revealed by QADUser, with the
property sheet that you see in Active Directory Users and Computers.
Example 2b - How to List a User's Property (Corrected version)
As with many of my scripts, there are two learning threads in this example, a real-life
objective (Listing user properties) and also learning PowerShell
techniques
(Piping and word-wrap).
# PowerShell script to list users
and their descriptions # Author: Guy Thomas # Version 1.1 July 2008 tested on PowerShell v 1.0
Note 1: The unusual backtick symbol (`) means, wrap the
command to the next line.
Note 2: The pipe symbol (|) is PowerShell's
signature tune; it means push the output of the first clause (get-QADUser) into this
next command (format-Table).
Challenges: If I were you I would take a timeout to add
values to your user's property sheet, e.g. LastName, Description, also
manager and location.
The second part of my challenge is to put into practice what we learned with get-help QADUser,
namely to add different fields from my example 2b, for example, Company or Office.
My objectives here are two fold, firstly, to practice scripting Active
Directory in a relatively harmless fashion. Changing a user's
property called 'Description' is less intrusive than changing their password.
Secondly, if we add a known description to just a few test users then we
have a handle to filter Active Directory. Just to emphasise that the benefit of having a description is that we have an extra control to prevent a rogue script changing everybody's
password. Next week I want to create a script which says, 'If
Description = xyz, then change the password'.
# PowerShell script to change a
user's description # Author: Guy Thomas # Version 1.1
July 2008 tested on PowerShell v 1.0
Note 1: Never miss a chance to learn a PowerShell
verb, mostly you employ, 'get', but observe that here we also employ the more
useful 'set'.
Note 2: See how I reinforce the idea of piping (|)
the output of 'set' becomes the input of FT, which stands for
format-Table.
Note 3: Clear-Host is both optional and cosmetic,
it merely clears the screen.
Challenge: You could try changing two, or more properties with the
same set command, for example, set-QADUser -Description "Supremo"
-Company "Our Company"
If you are looking for handy network utilities, try some of the free downloads at
Tools4Ever
Summary of Preparing PowerShell to Script Active Directory
Before you can manipulate Active Directory objects such as users, you must
prepare the ground by downloading and installing the QAD snap-ins.
Once you have completed this one-off task scripting Active Directory with
PowerShell becomes incredibly easy.
Please write in if you see errors of any kind. Please report any factual mistakes, grammatical errors or broken links, I will be happy to not only to correct the fault, but also to give you credit.
Guy
Recommends: Orion's NPM - Network Performance Monitor
Orion's performance monitor is designed for detecting network outages.
A network-centric
view make it easy to see what's working, and what needs your attention.
This utility guides you through troubleshooting by indicating whether the
root cause is faulty equipment or resource overload.