![\"Hey,](\"https:\/\/devblogs.microsoft.com\/wp-content\/uploads\/sites\/29\/2019\/02\/q-for-powertip.jpg\" "\\"Hey,")
Hey, Scripting Guy! I need to enable local user accounts on my Windows Server 2008 servers. I have to use Windows PowerShell 1.0 because we are not going to upgrade to Windows Server 2008 R2 until April of next year. Because the end of the year is rapidly approaching, we are going into IT lockdown and will not make any changes until after the end of January. At that time, we will begin evaluating our new projects, and server upgrades are on tap for Q2 next year. I know you have been writing about Windows PowerShell 2.0<\/a> a lot here lately, but I am wondering if you can do a retro thing for me? <\/p>\n— GB<\/p>\n
<\/p>\n
Portions of today’s post are excerpted from Ed Wilson’s Windows PowerShell Scripting Guide<\/i>, Microsoft Press, 2008. <\/p>\n Unlike domain accounts, it is not very often that we will create a disabled user account. Local user accounts are primarily created to provide access to local resources<\/a>, or for local service accounts. They are not often used, except in workgroup settings, for actual logon user accounts. This does not mean they are obsolete. To the contrary, with the enhanced peer-to-peer capabilities of Windows Vista<\/a> and above, as well as the new features of Windows Server 2008 and Windows Server 2008 R2, local user accounts are even more important today than they were even five years ago. <\/p>\n It is also true, that when Windows Vista and above are installed the local administrator account is disabled. This is seen in the figure below. You may want to enable that account to perform certain management tasks. <\/p>\n <\/p>\n To enable the admin account, you can use the EnableDisableUser.ps1<\/b> script to enable the account, perform the requisite activities, and then use the EnableDisableUser.ps1<\/b> script to disable the local admin account. You can also use this script to change the local admin password as well. To do this, you would just “pretend” you were going to enable the local admin account, and run the script with enable option specified. <\/p>\n In the EnableDisableUser.ps1<\/b> script, we begin with the param<\/i> statement. We specify five parameters. The first one is -computer<\/i>, which determines where the script will execute. By default, the -computer<\/i> parameter is set to run on the local machine. The -a<\/i> parameter determines the action to perform when the script is run. The -user<\/i> parameter and -password<\/i> parameter are used for working with the local user. The -help<\/i> parameter will display help. This line of code is seen here.<\/p>\n param($computer=”localhost”, $a, $user, $password, $help)<\/span><\/p>\n <\/p>\n The funhelp<\/b> function displays help when the script is run with the -help<\/i> parameter specified. The funhelp<\/b> function is similar to the other ones that I have used in other articles. It uses a here-string, and stores the information in the $helpText<\/b> variable. Once the description, parameters, and syntax are detailed, the contents of the $helpText<\/b> variable are displayed and the script exits. This function is seen here. <\/p>\n function funHelp()<\/span><\/p>\n {<\/span><\/p>\n $helpText=@”<\/span><\/p>\n DESCRIPTION:<\/span><\/p>\n NAME: EnableDisableUser.ps1 <\/span><\/p>\n Enables or Disables a local user on either a local or remote machine.<\/span><\/p>\n <\/span><\/p>\n PARAMETERS: <\/span><\/p>\n -computer Specifies the name of the computer upon which to run the script<\/span><\/p>\n -a(ction) Action to perform < e(nable) d(isable) ><\/span><\/p>\n -user Name of user to create<\/span><\/p>\n -help prints help file<\/span><\/p>\n <\/span><\/p>\n SYNTAX:<\/span><\/p>\n EnableDisableUser.ps1<\/span><\/p>\n Generates an error. You must supply a user name<\/span><\/p>\n <\/span><\/p>\n EnableDisableUser.ps1 -computer MunichServer -user myUser <\/span><\/p>\n -password Passw0rd^&! -a e<\/span><\/p>\n <\/span><\/p>\n Enables a local user called myUser on a computer named MunichServer<\/span><\/p>\n with a password of Passw0rd^&!<\/span><\/p>\n <\/span><\/p>\n EnableDisableUser.ps1 -user myUser -a d<\/span><\/p>\n Disables a local user called myUser on the local machine<\/span><\/p>\n <\/span><\/p>\n EnableDisableUser.ps1 -help ?<\/span><\/p>\n <\/span><\/p>\n Displays the help topic for the script<\/span><\/p>\n <\/span><\/p>\n “@<\/span><\/p>\n $helpText<\/span><\/p>\n exit<\/span><\/p>\n }<\/span><\/p>\n <\/p>\n Following the funhelp function, we declare two variables. These variables contain ADS_USER_FLAG_ENUM<\/b> enumeration values which were retrieved from the Windows SDK. These values will be used to either enable a user, or to disable the user account. <\/p>\n $EnableUser = 512 <\/span><\/p>\n $DisableUser = 2 <\/span><\/p>\n <\/p>\n While the ADS_USER_FLAG_ENUM<\/b> enumeration values are documented in the Windows SDK, their use as described here are not documented. Since we do not have direct support for the IadsUser<\/b> interface in Windows PowerShell this means we do not have access to the accountdisabled<\/b> Boolean property that was available in VBScript. This makes the EnableDisableUser.ps1<\/b> script an important example as “re-branded” VBScripts simply will not work using the WinNT provider. <\/p>\n After we define the two variables, now we test to see if we need to display the help string by checking for the presence of the $help<\/b> variable. To be honest, we could have moved this line up two spaces, and checked prior to setting the $EnableUser<\/b> and the $DisableUser<\/b> variables as it makes no difference in performance of the script, we decided to define these variables earlier in the script. We now use code to see if help needs to be displayed. It looks for the presence of the $help<\/b> variable, prints out a string, and calls the funhelp<\/b> function if the $help<\/b> variable is found. <\/p>\n if($help){ “Obtaining help …” ; funhelp }<\/span><\/p>\n <\/p>\n Now we check to see if the $user<\/b> variable is present. If the $user<\/b> variable is not present, then we use the throw<\/a> statement to generate an error. <\/p>\n The throw statement is not documented in the Windows PowerShell documentation, although it shows up in one piece of sample syntax (when talking about code signing). It is easier to use than the syntax: if(xxx) { xxx ; exit }. The disadvantage is that the output is not very pretty.<\/p>\n In the error text we mention that a user name is required, and we print out the syntax for obtaining help. This section of the script is seen here. <\/p>\n![\"Hey,](\"https:\/\/devblogs.microsoft.com\/wp-content\/uploads\/sites\/29\/2019\/02\/a-for-powertip.jpg\" "\\"Hey,")
Hello GB, Microsoft Scripting Guy Ed Wilson here. It is interesting that you mention Windows PowerShell 1.0. I have actually run across two other companies like yours this week, GB. I decided to take a look at the Windows PowerShell Scripting Guide<\/a> book that I wrote for Microsoft Press, and excerpt a portion of one of the chapters in that most excellent book. <\/p>\n![](\"https:\/\/devblogs.microsoft.com\/wp-content\/uploads\/sites\/29\/2019\/02\/1512.HSG-11-22-10-01.jpg\")
<\/p>\n