Script for Creating AD Test Accounts

Hey there again,

Now that I’ve gotten over the first post jitters, I figured I’d share a script that I created to provision AD Test Accounts. Feel free to use it or comment on improvements that can be made. :slight_smile:

Param (

      )#End Parameter Set

$EndNumber = $StartingNumber + $TotalUsers
$Range = $StartingNumber..$EndNumber
#End of PowerShell Maths

ForEach ($Num in $Range) 
    $NumID = "{0:0000}" -f $Num
    $userName = "$User$NumID"

    New-ADUser `
       -AccountPassword (ConvertTo-SecureString $Password -AsPlainText -Force) `
       -AccountExpirationDate $ExpiryDate `
       -Company "Company" `
       -Country "US" `
       -Description ($Description)`
       -DisplayName $userName `
       -Enabled $true `
       -GivenName $userName `
       -Manager $Manager `
       -Name $userName `
       -Path "OU=TestUsers,DC=company,DC=com" `
       -SamAccountName $userName `
       -Surname $userName `
       -UserPrincipalName "$"
 }#End ForEach

I designed it to provision user IDs in the format of ‘UserID0000’ and gave it the ability to create a range of users. Usually we get a request to stand up 2000+ users for a given load test, and often times we’ll get an additional request to create more. This script allows me to create the initial users (say UserID0001-UserID2000), and if I get an additional request, I just input my starting number at 2001 and add the requested number of users.

I’ve actually built this as an activity for Orchestrator, but I always build the code in ISE and test it in pure PowerShell before moving it to that environment.

I admit, I used Erich Karch’s ‘Powershell: Create 1000 Test User Accounts’ as the inspiration for this script, but I wanted something that would give me more flexibility when creating users, and then be able to build it into a runbook that I can put into a service offering through SM.

Let me know what you think!

Not bad! This is a style concern, rather than a problem with functionality, but you’ll find that the PowerShell community generally frowns on using the backtick as a line contiuation character. Some people (mainly book authors) will point out that it’s hard to see, particularly in print. Even worse, though, is the fact that unless the backtick is the very last character on a line, it doesn’t work as a line continuation character. Try typing a space after the backtick and you’ll see what I mean.

In general, when you want to break a long cmdlet across multiple lines, it’s preferable to create a hashtable and then use splatting to pass it to the cmdlet. Here’s what that would look like for your call to New-ADUser:

$newADUserParams = @{
    AccountPassword       = ConvertTo-SecureString $Password -AsPlainText -Force
    AccountExpirationDate = $ExpiryDate
    Company               = "Company"
    Country               = "US"
    Description           = ($Description)
    DisplayName           = $userName
    Enabled               = $true
    GivenName             = $userName
    Manager               = $Manager
    Name                  = $userName
    Path                  = "OU=TestUsers,DC=company,DC=com"
    SamAccountName        = $userName
    Surname               = $userName
    UserPrincipalName     = "$"

New-ADUser @newADUserParams

You don’t have to line up all the = signs in the hashtable like that, but I’m in the habit of doing so. I think it makes the code easier to read.

Thanks! I’ll make a copy of my script and play around with this. I recall seeing Don Jones using it during a demo at TechMentor too, but sometimes I have to see it in the context of something that I’m working with to get the wheels turning. I really appreciate the help!