All posts by Jeffery Hicks

Set Local User Account with PowerShell

halfuser The other day I received an email from a student asking for some help in using PowerShell to take care of a user account on a local computer. He not only wanted to be able to set the password, which he had already figured out, but also how to enable or disable the account, which is not obvious or intuitive without experience using ADSI and the WinNT provider. I sent him some suggestions to get him started down the right path. But I realized, I should wrap up this functionality in a PowerShell tool since his task is something I assume many of you need and there are no cmdlets from Microsoft for managing local user accounts.

First, let me point out that it is actually quite easy to manage local user accounts on remote computers using PowerShell. All you need to do is learn how to use the NET USER command and execute it using Invoke-Command.



The LocalAdmin account on CHI-CORE01 is currently disabled (account active is equal to no). But it is pretty easy to enable and set a new password.

However, this doesn’t scale well and the capabilities of the NET USER command might vary by operating system. So here is a PowerShell function that utilizes ADSI to do the same thing.

This function should work in PowerShell 2.0 and later. The help content includes some usage examples. You can use this command to simply change the user password, or change the password while enabling or disabling the account. Enabling and disabling is accomplished with a bitwise operation with the userflags value and a constant flag that indicates the account is disabled.

There is probably more that could be added to the command such as setting the comment property and when the account expires. But I’ll leave those changes to you for now.

Save the PowerShell Children

PowerShell Deep Dives I just received the royalty statement for Q4 2013 on the PowerShell Deep Dives book. While I appreciate every sale, I know the community can do better. In case you didn’t know, this book is a compilation of PowerShell nuggets you won’t find anywhere else. Chapters were contributed by MVPs, leaders in the PowerShell community as well as Microsoft specialists. Nobody received any financial compensation for this project. All proceeds go to Save the Children. For Q4 2013 they received a check for $1,848.

Net sales for Q4 were 257 copies. Since I’ve never returned a purchased book I have no idea why there are any returns. Since publication we’ve sold 1733 copies. I have to believe there are more than 1700 people in the PowerShell community who would enjoy this book. Perhaps they simply don’t know about it.

If you don’t have your own copy you can get it from Amazon or Manning. If you are after a digital copy, you will need to get those from Manning. And if you already own a copy, please consider leaving a review on Amazon and encourage your friends and colleagues to get their own copies. They will pick up some great PowerShell knowledge and make the world a better place.

Friday Fun: Create All PowerShell Profile Scripts

talkbubbleWhenever I train on PowerShell I inevitably get around to discussing PowerShell profile scripts. For those of you new to PowerShell, a profile script is where you put all the commands you want to run that will define your PowerShell session just the way you need it. You might load some snapins, create some PSDrives or define some variables. There are actually several profile scripts that can be run, depending on whether you are in the PowerShell console, the PowerShell ISE or some other PowerShell host.

The profile paths are hard-coded. You can see all of them by looking at the built-in $profile variable.

You can also look at just $profile which will show you the script for the current user on the current host. If you look at this in the ISE you’ll see some things are different.


This variable is a bit tricky. Even though you can see properties here, if you pipe $profile to Get-Member all you get is a string definition. Here’s another way you can discover these.

Although I don’t really care about the length so let’s filter it out.

Now for the fun part. That value is a path so I can use Test-Path to see if it exists. If not, I can create the profile and at least indicate that is isn’t being used. Because most of these files don’t exist by default and in fact the WindowsPowerShell folder doesn’t exist under Documents until you create it, you might have to create the parent folder first. So I came up with a little script called Create-AllProfiles.ps1.

The script takes advantage of a feature in PowerShell 3 that will automatically enumerate properties. In PowerShell 2.0 I would need to do this:

But now in v3 and later I can do this:

The value property would show all of the values, including the length so because I’m getting an array, I can use a range of index numbers to select just the ones I want. In my script each value is tested and those that don’t exist are passed on to Foreach-Object.

For each path, I first split it so I can test if the parent path exists. If not, it is created. Then I create some text that will be inserted into each new profile script. The script supports -WhatIf so you can see what it would do before you run it for real.


I end up with a profile script that looks like this:


Ideally, I would recommend you digitally sign the profile scripts, assuming you are using an AllSigned execution policy, so that no changes can be made to these scripts without your knowledge. Just don’t forget to run this in the PowerShell ISE as well. If you have profiles already created, they will be ignored. And should you decide later to take advantage of any of the profile scripts, they are ready for you to edit.

Learn, enjoy and have a great weekend.