Creating Local Accounts with Windows PowerShell

Posted on May 10, 2012 by Jeff Hicks in PowerShell with

Way back in the day, all we had were local accounts on stand alone or workgroup-based computers, and in some ways, nothing has really changed. We still have computers that have local user accounts. Most of the time the local Administrator account is all that matters, but you may have situations where you want or need additional local user accounts.

Today, I will show you how easy it is to set up these accounts remotely, using Windows PowerShell.

Now, if you only need to do this on a single machine on a rare occasion, by all means use the Computer Management console. However, if you are looking to create a number of local accounts across multiple machines, PowerShell will make this much easier.

Leveraging PowerShell to Create Local Accounts across Multiple Machines

I’m going to demonstrate in a domain environment from a Windows 7 desktop running PowerShell 2.0, creating local accounts on other domain members. I’m logged on with an account that has admin rights on the remote computers. With this approach, I don’t need PowerShell installed anywhere else.

If you need to create accounts on non-domain members, I think the best approach is to use PowerShell remoting. You can run the same commands I’m going to show you, but in a remote session or using Invoke-Command. The advantage is that you can specify the credentials you need. Setting up remoting for non-domain members is a bit tricky, and I don’t have space to cover it here, so I’ll assume if you have to go this route you have it worked out.

The first step is to connect to the remote computer. Unfortunately, there are no cmdlets for what we are about to do. Instead, we’ll rely on some .NET and PowerShell tricks using ADSI, which is the same technology we used in VBScript.

This command creates a variable, $server, which will be an ADSI object. The string on the right side of the expression is the “path” to the remote computer. The WinNT moniker is case sensitive, but the result is an object as you can see in Figure 1.

ADSI Computer Object
Figure 1 An ADSI Computer ObjectTo create a simple local account, we invoke the ADSI object’s Create() method, specifying what type of object we’re creating and giving it a name. Save the results to a variable because we’ll need it in a moment.

Next, we need to define the new account’s password with the SetPassword() method.

Finally, we need to commit the change to the local directory service by calling the SetInfo() method. If we fail to do this, the account won’t be created.

If you’d like, you can set additional properties for the account, calling SetInfo() at the very end to save all the changes.

The other step I took here was to define a new value for the userflags property. This is a bitmask value that indicates things such as if the password never expires or if the account is disabled. I set a new value so that the password never expires. You can see the result in Figure 2.

New Local Account
Figure 2 A New Local AccountTo see our results from PowerShell, we can query the server’s “children,” filtering by object class.

Object properties are stored as arrays, which is why the output might look a little odd.


The last step is to add this account to an appropriate local group. I’m going to add the HelpDesk account to the Power Users local group. First we need to get the local group using ADSI.

To add a group member I need to specify the path to the user object.


The change is immediate and there is no need to run SetInfo(). At this point, my new local user account is ready to go.

Next time we’ll look at managing this account including changing the password, modifying group membership, disabling the account and deleting it.

Tagged with

Register for this Webinar

How Replication Supports Your Company’s RTOs & RPOs
Join us for this free webinar

Can you have your workloads running within the agreed RTOs? Join this webinar with expert speakers from Veeam to exceed business objectives with an RPTO<15 min for ALL of your application and data.

Thursday, December 14, 2017 at 11 a.m EST