Use PowerShell to Create Local User Accounts

Summary: Microsoft Scripting Guy, Ed Wilson, talks about using Windows PowerShell to create local user accounts.

Microsoft Scripting Guy, Ed Wilson, is here. As much as we might like to ignore it, or not do it, network administrators routinely need to create local user accounts on servers and on workstations. At times, these workstations or servers are even standalone, which means they are not joined to a domain.

As much as we might hate to admit it, there are still no Windows PowerShell cmdlets from Microsoft that permit creating local user accounts or local user groups. We finally have a Desired State Configuration (DSC ) provider that can do this—but to date, no cmdlets.

So what does this mean for a modern Windows PowerShell environment? It means that if I have Windows PowerShell 4.0, I can use the local user provider to create local user accounts, or I can go old school, and fall back on ADSI.

Note  I wrote a Local User Management Module that can be used to reduce the amount of code that needs to be created.

I wrote a blog post about creating local users several years ago, and I got comments like these:

• “It does not work.”
• “There is no method named Create.”

Keep in mind that this technique does work—but remember it is old school. This means that although the methods are there, they do not appear in the Windows PowerShell ISE or even show as available within the Windows PowerShell console. That is just some of the fun. One other thing to remember is that you must launch the Windows PowerShell console or the Windows PowerShell ISE with Admin rights if you expect this to work. Otherwise, you will get an “Access denied” error message.

Creating a local user account by using ADSI

To create a local user account, I can use the computer management console, go to Local Users and Groups, and navigate to Users. Then I can right-click the Users folder, select New User from the action menu, and fill out the following form:

This form is from my laptop running Windows 8.1, but the form has not changed very much in the last ten years. In fact, the type of users and groups that are created are similar to the users and groups that were created back in the Windows NT 4.0 days.

We get a little bit of help by using the ADSI type accelerator to create the user object—but this has remained unchanged since Windows PowerShell 1.0 came out. The following are the steps required to create a new user object:

1. Make a connection via ADSI to the local computer user account database. To do this, I specify that I am using WinNT, and I specify the name of the local computer.
   Note  WinNT must be capitalized exactly in this manner: WinNT, or the script will fail.
2. Call the Create method after the connection is made.
3. Specify that I am creating a user, and provide the name of the user.
4. Call the SetPassword method, and pass a password.
5. Call SetInfo method to create the actual user object.
6. Assign a description.
7. Call SetInfo method again.

Here is the script:

$cn = [ADSI]"WinNT://edlt"

$user = $cn.Create("User","mred")

$user.SetPassword("P@ssword1")

$user.setinfo()

$user.description = "Test user"

$user.SetInfo()

In the first line of the script, I specify the name of my local computer. Here it is named edlt. I use the [ADSI] type accelerator to make the connection, I specify WinNT, and I store the connection in a variable I call $cn.

Next, I call the Create method from the object stored in $cn. This method does not appear when using Tab expansion, or even in the lookup from within the ISE. With the first parameter of the Create method, I specify the type of object to create. Here I am creating a user. Next, I specify the name of the user object. I store the returned user object in the $user variable. This is shown here:

$user = $cn.Create("User","mred")

Now I specify a password by using the SetPassword method. The password must meet any complexity requirements set forth in the local security policy. This line is shown here:

$user.SetPassword("P@ssword1")

It is now time to write the user object to the local account database. To do this, I use the SetInfo method as shown here:

$user.setinfo()

Now I decide to add a description for the user. To do this, I write a value in the Description property of the user object. I once again call SetInfo. This is shown here:

$user.description = "Test user"

$user.SetInfo()

If I run this without Admin rights, I get an “Access denied” error message, as shown here:

On the other hand, if I run the script with Admin rights, after a few seconds, the script returns control to the Windows PowerShell ISE, and no output appears. This is shown here:

All the rest of this is plain, old, everyday Windows PowerShell. Some considerations include:

• Add variables so everything is not hard-coded.
• Pick up the name of the local computer.
• Check for Admin rights before I run the script.
• Don’t have the password in plain text in the script.
• Create local user accounts on remote computers.
• Put it into a function/module to make it easier to use.

All of these issues have been dealt with in other Hey, Scripting Guy! Blog posts. But I wanted to take today to focus specifically on the ADSI stuff. Better yet, upgrade to Windows PowerShell 4.0 and use DSC and the local user accounts provider, or use my Local User Management Module.

That is all there is to using Windows PowerShell to create local user accounts.  Join me tomorrow when I will explore more Windows PowerShell greatness.

I invite you to follow me on Twitter and Facebook. If you have any questions, send email to me at scripter@microsoft.com, or post your questions on the Official Scripting Guys Forum. See you tomorrow. Until then, peace.

Ed Wilson, Microsoft Scripting Guy