Thursday 9 June 2016

Setting Windows PowerShell path variable

Hello Folks,

To find the current environment PATH variable use the following cmdlet.

$env:Path



Some time during a PowerShell session, you need to modify the PATH environment variable temporarily, you can do it this way.



$env:Path = $env:Path + ";C:\java\bin"

$env:Path = $env:Path + ";C:\java\lib"



Or a much easier way is as below.


$env:Path += ";C:\java\lib" or $env:Path += ";C:\java\bin"



Please note the ";"  before the path, this is necessary so that the path would have

the right syntax and wouldn't break anything.


There are ways to make environment settings permanent but if you are only using them from PowerShell, it's probably a lot better to use your profile to initiate the settings.

Determine installed PowerShell version on system.

Hello Folks,

How can I find what version of Windows PowerShell my computer is running.
Use the automatic $PSVersionTable variable, and check the PSVersion property,


 for example:
                           $PSVersionTable.PSVersion



There may be other ways to get this but by far use only this approach to get this information as it is the most reliable option to get the correct information.

Happy Scripting..

Set-AutoLogon and execute Script on next reboot. RUNONCE AUTOLOGON

Introduction

This is an extended write up on the Script that allows users to enable Auto Logon at the next boot of Windows OS using PowerShell.

This idea started with image preparation for Windows and the requirements after it. Apart from gathering requirements for the image, the post installation steps and validation checks should also be considered. When PowerShell could deliver all this, all that is needed was a simple module that reboots the system when needed and proceed with the workflows after it. So, we needed a script that could Auto Logon and also execute something after boot up!

A Word of Caution: Editing the registry is risky! Always backup, test thoroughly, and execute.

This topic describes how to setup the script and the required settings:
  • The Registry entries at these locations would allow us to modify which user could connect and what script / task to execute post boot.
#Registry path declaration
$RegPath = "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon"
$RegROPath = "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnce"
  • We have four parameters that this script could read from console out of which two are mandatory.
  • The "DefaultUsername" and "DefaultPassword" are the Mandatory fields while the Number of "Auto Logon Count" and the "Script" to execute are optional. By just defining the mandatory parameters, the Auto Logon Count would be set to 1 and would allow one-time boot into the OS with the supplied credentials.
[CmdletBinding()]
Param(
     
    [Parameter(Mandatory=$True,ValueFromPipeline=$true,ValueFromPipelineByPropertyName=$true)]
    [String[]]$DefaultUsername,
    [Parameter(Mandatory=$True,ValueFromPipeline=$true,ValueFromPipelineByPropertyName=$true)]
    [String[]]$DefaultPassword,
    [Parameter(Mandatory=$False,ValueFromPipeline=$true,ValueFromPipelineByPropertyName=$true)]
    [AllowEmptyString()]
    [String[]]$AutoLogonCount,
    [Parameter(Mandatory=$False,ValueFromPipeline=$true,ValueFromPipelineByPropertyName=$true)]
    [AllowEmptyString()]
    [String[]]$Script
             
)

           Yes, there is a lot of "clear text" concerns here, but this could be edited a bit to accommodate the -credential if needed. The purpose here was different and we just wanted it to show it working by keeping it simple. Once the post configurations are done, we could just delete this account which is more like a disposable account that had done its work. Sorry "account".

            Now, we would go and set the parameters that we have got from the console with the below snippet.

Set-ItemProperty $RegPath "AutoAdminLogon" -Value "1" -type String 
Set-ItemProperty $RegPath "DefaultUsername" -Value "$DefaultUsername" -type String 
Set-ItemProperty $RegPath "DefaultPassword" -Value "$DefaultPassword" -type String

           This would set the DefaultUsername key and the DefaultPassword key with the values needed.

Some more gotchas:
  • Password here would be in clear text.
  • If, using a domain account provide the complete "DOMAIN\USR" format or extend a bit and use the Registry key "DefaultDomainName" at the same level.
  • And, the below snippet would take care of the parameters "Auto Logon Count" and "Script" if they are defined at console.
if($AutoLogonCount)
{
     
    Set-ItemProperty $RegPath "AutoLogonCount" -Value "$AutoLogonCount" -type DWord
}
else
{
    Set-ItemProperty $RegPath "AutoLogonCount" -Value "1" -type DWord
}
if($Script)
{
     
    Set-ItemProperty $RegROPath "(Default)" -Value "$Script" -type String
}
else
{
    Set-ItemProperty $RegROPath "(Default)" -Value "" -type String
}

So, this is the simplest way to do some automation work for you when you are not at desk rebooting.

Remoting

To share the 'Remoting' options for this script in a way editing registry remotely and before we go any further, we would assume that remoting is enabled and working and would like not to script it completely as it's not always the same thing for all requirements. This would help to tweak it in your own way.

Before we start we have to do the copy/paste again the line below.

A Word of Caution: Editing registry is risky, always backup, test thoroughly, and execute.

This is the command that does it all. We could explain it in step by step and this would only set one attribute in Registry i.e., the "DefaultUsername" as "Administrator".

Invoke-Command -cn ($Servers) -cred $cred {Push-Location ;Set-Location 'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon'; Set-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon' "DefaultUsername" -Value "Administrator" -type String ; Pop-Location}
  • Getting the servers $Servers (from a file "get-content filepath")
  • We use Invoke-Command to all servers
  • Convert the DefaultUserName/DefaultPassword  to Credential store, or you could totally use new credentials and call it from console
  • On remote, our locally declared variables are obsolete and if you see path not found errors check code again and also if the registry really had those values
  • Why to use Push-Location and Pop-Location ?
So we could edit the remote registry in the above manner and enable something to start after a boot.

Gotcha: A big one. If the "LegalNoticeCaption" and "LegalNoticeText" are defined, we are no good after reboot. It just waits there for someone to read it and agree. Yes, we could empty those values unless they are not controlled by the AD guys.

The keys we are dealing with:



Script

The Script can be found in the Gallery at https://gallery.technet.microsoft.com/Set-AutoLogon-and-execute-19ec3879
Currently supported options:
-DefaultUsername:
Provide the username that the system would use to login.
-DefaultPassword:
Provide the Password for the DefaultUser provided.
-AutoLogonCount:
Sets the number of times the system would reboot without asking for credentials. Default is 1.
-Script:
Provide full path of the script for execution after server reboot. Example : c:\test\run.bat

Mandatory Parameters:
-DefaultUsername
-DefaultPassword

Some Examples:

Example to set Autologon:
Set-AutoLogon -DefaultUsername "win\admin" -DefaultPassword "password123"

Example to set Autologon with 3 times retention for passwordless logon:
Set-AutoLogon -DefaultUsername "win\admin" -DefaultPassword "password123" -AutoLogonCount "3"

Example to run a script after a reboot:
Set-AutoLogon -DefaultUsername "win\admin" -DefaultPassword "password123" -Script "c:\test.bat"

Conclusion

Yes, there are so many other ways to achieve this and this is one of the way. We are working on Windows technology close to 10 years now, and we could only relate as "BP & AP" (Before PowerShell & After PowerShell.