Creating bulk user accounts in AD via PowerShell

Introduction

Today, we’re going to talk about little tricks on automating one of the most routine duties of an AD admin, namely creating multiple user accounts. Literally, every single one admin sooner or later meets the necessity to develop and activate several user accounts. If it’s a one-time activity and you don’t need more than 10 accounts, you better stop right here. However, if you have a large domain at your responsibility, or just have to create multiple accounts too often, there are ways to make your life much more comfortable.

Speaking from personal experience, I can tell that at the end of the day, almost every time it all narrows down to two primary goals:

1. Bulk account creation with one-type names and same parameters (User1, User2, etc.) that is often required for enabling users with temporary access or testing purposes.
2. Bulk account creation for AD users. Possibilities of potential use are diverse, whether it would be the establishment of a new company division or adding a lot of new employees.

In both cases, you’ll require extreme attentiveness because domain security policies are no joke. At the same time, temporary expenses on work of the same type are real. You want to avoid them or limit the amount of wasted time and effort to a minimum? Well, let’s take a look then.

Nevertheless, before moving directly to the subject at hand, there should be a little theoretical excursus. All the actions listed forward are composed of the standard PowerShell cmdlets for AD. New-ADUser is the main one you’ll need, its responsible for creating and editing AD user objects, both as individuals and as a group, you can find more info here. Remove-ADUser, as the name is hinting, allows deleting the user objects in AD, and it’s all described here. Get-ADUser cmdlet enables you to get a specific user object or multiple user objects, here is the all information you need. The Export-CSV cmdlet converts objects in the AD database to CSV files, look how exactly this works. On the contrary, with the Import-Csv cmdlet, you can create table-like custom objects, look at details. You’ll need a spreadsheet as well, like Excel 2016 (which I use), but really it can be any other option until it’s capable of importing and editing text files entered in cells of a table. Finally, you can’t do much without the main ingredient, namely AD, explicitly configured for testing purposes on Windows Server 2016.

Now, please, be very attentive. All these actions were conducted in my environment, so if you miss the point of the whole process, you may damage your domain, so it’s better to have a backup for your AD! I can give pieces of advice, but the responsibility on how you are going to follow them or not is yours!

Creating bulk AD accounts with typical settings

As I already told you, this option is up for grabs if your case is creating multiple AD user accounts of the same type. Creating or deleting them takes too many time and resources if done manually. What’s the catch, you may ask? There isn’t one. The New-ADUser cmdlet is quite a powerful tool, and now its all-sufficient and has a lot more functions. Today, you can create and activate a fully-configured user account with this cmdlet.

You probably know by now that the New-ADUser has a lot of parameters for the account fine-tuning, so it may scare off those of you who don’t usually deal with creating bulk AD accounts regularly. Let’s take a closer look so that you understand there is no need to worry about complications or anything.

So, our goal here is creating users with minimal parameters, just enough for creation, activation, or identification of an account if anything were to happen. I mean, you hardly need such fields as the home number or e-mail address when this user account exists for testing purposes exclusively. All you have to do is establish rules according to which the user objects will be created, tailored to the specifics of a task. Such factors are, say, common object name with a number (Client1, Client2, etc), setting a password, perhaps, with changing a few symbols as well (Password1, Password2, etc). To create a user AD account object in PowerShell, you just have to set a distinguished name, albeit you’ll need a password or passwordless login to make it work. The necessity to change the initial password and activating an account upon creation can also be established along with the other parameters. Have a hard time deciding which is which? Official information on the New-ADUser cmdlet up higher contains the complete list of its parameters with their purposes explained in full. Keep in mind, please, that this article is only covering the basics! If you need to set additional parameters, choose them in that list and add them to my script.

Now, let’s move onto creating user objects. In DC, where we will be covering further settings, start PowerShell. Then, enter the command to check if there any other user accounts with the same name (Client), filtered as (‘name -Like “Client*”‘):

Empty field speaks for itself, confirming that in this AD user objects with such names are absent.

Now, create 15 user AD accounts with the same names and passwords, distinguished only by serial number (Client1/Password1, Client2/Password2, etc).

As you can see, I used the short writing of the Foreach command with increment step 1 and maximum value 15. Inside this cycle works the command creating user AD account with the variable «$_» of numerical value, which allows setting unique names and passwords. We set the location of creating accounts in the “Users_New” Organizational Unit at the Test.local domain. The “Enabled” parameter, as “true”, is responsible for activating the account upon its creation.

Use the command to check other user objects again, but this time with additional filters to check different accounts following only specifically set parameters:

Now we can see created user account objects.

After finishing work, you can delete these objects either all together or individually. Use Remove-ADUser cmdlet; you can find the description in the introduction.

Command format:

In the “Confirm” parameter, “false” allows ignoring the request for confirmation to delete each separate object.

Creating bulk AD accounts with individual settings

Now, with experience in the area of creating bulk AD accounts with typical settings, it’s time to move onto automating the process of creating bulk AD accounts with individual settings. Since in this case, unfortunately, it’s impossible to avoid manual work altogether, let’s try to minimize spent time and resources.

How does it work, and what for? Well, I already showed you how a few minor adjustments and cmdlets could make your system complete tedious manual tasks for you. However, what if you were to improve this combination with a file that has listed all the parameters for creating user objects? Correct, if everything works the way it is supposed to, you’ll be able to create user AD account objects with completed parameters. Let’s figure out how this works!

First of all, we need a template (*.csv file) to create user account objects. It’ll be your lifeboat in case of mistakes in the names of parameters or inconsistencies of parameters. To get this file, first, you need to create a template user object with required fields that already have entered information. Or, perhaps, you could use an existing user account object for the same goal, it doesn’t matter. I, for one, used the test user John Doe with necessary fields already filled. Please, note that I didn’t enter information in all the fields there are! I just picked some of them.

With this line, I exported all configured settings of John Doe user account object into that file c:\Temp\exp.csv. For this I used the Export-CSV cmdlet.

If the command works as it should, you’ll get an empty space as a result. Otherwise, you’ll have to fix an error.

Get the file and check its content.

The content isn’t very informative, but don’t worry: this is just a standard text file with settings and parameter names with a heading delimited with the commas.

You’ll need MS Excel. It’ll spare you some effort. Start MS Excel. Import the contents of your text file.

Pick up your file from the directory where you saved it. (c:\Temp\exp.csv).

Choose import settings. Specifically, note that the data in this file is delimited (comma) and start importing at the second row.

Remove tab and add comma as a delimiter.

In the next step, you can either remove unnecessary columns or set the format. I did not remove them cause it’s better to edit the table in the editor.

Choose where do you want to put the data. I left it in the existing worksheet and did not change a thing.

Well, now I can remove the unnecessary columns. There are dozens of them; I just showed very few. Deciding which columns are useless, though, is entirely up to you.

After editing the table structure, I add the user objects with the filled parameters that I need. My new version of the table looks like this.

Now, save the result. Pick a place where do you want to keep it, file format, and a new name. Mine is c:\Temp\imp.csv

Agree to keep using that format.

Check the final file with PowerShell.

As you can see below, it became smaller, structured, and now has more users, which means you’re doing everything just fine.

Furthermore, create a new script for PowerShell and fill it with the following lines of the code:

This script will serve you well in importing the most important, in my opinion, parameters from your file. It wasn’t my goal to add all the parameters there are and check whether they will be imported or not, but I can assure you it will work. For the script to work correctly, you must choose where do you want to import the file and select your domain name and the name for the organizational unit where you keep it (in my case, its «OU=Users_new,DC=Test,DC=local»). Now, a quick word on the script.

It works almost the exact same way as the previous one. The only exception is that it changes the value of each line from the beginning to the end of the «imp.csv» file. Every value of the New-ADUser cmdlet is matched with the corresponding value from the «Rec» variable. Parameters with the «Boolean» variable («Enabled,» «ChangePasswordAtLogon» in this case) are set with the type change. Otherwise, it wouldn’t be working. The same goes for the «AccountPassword.» Also, don’t forget to save the script for further use! For example, I saved it as Import.ps1.

Start the script. If it works right, you’ll get empty space and no notifications about errors. I didn’t want to create a fully-fledged script that deals with errors as well since AD and PowerShell are quite efficient on their own in this regard.

Check the presence and state of your objects:

Your filter value will differ and depend on the domain and organizational unit names.

Today we took a closer look at two options that can make it a lot easier for you. You can agree that with the proper approach, it may spare you some time. I don’t pretend that this is a groundbreaking material, but I hope it will be useful.