Powershell Scripting Environments, Part I

Earlier this year, I said I would give some information regarding some of the many scripting tools you can use for creating Powershell scripts.  Here are just a couple of those tools that I currently use or have used in order to create my scripts:

 

1. PS Shell

This is equivalent to the Command Prompt.  When the shell is started, you will see PS C:\

 

 



           

  You can initialize variables within the shell.  Let's set the variable $messsage to 'This is a test'

 





We can see what is in the variable by running $message



The variable and contents are keep in memory and can be used with further cmdlets.

 

The drawback, for me, is that making changes involves either typing in a command again, or using the arrow keys to bring back a command you ran.  It may not be a problem if there are only a couple of lines to the script.  But, if you want to create a script with a lot of code, you going to want to use an integrated scripting tool.

 

 

2. Integrated Scripting Environment (ISE)

The ISE is provided by the Windows OS.  You can start the ISE by typing ISE in the Powershell shell

 

 

 

The ISE will appear

 

This environment allows you to create and run a script in the right panel.  When you run the script the output will appear in the left panel.

 

Here are a couple of tool bar items you should know how to use:

 Click this if you want to run the entire script.  The keyboard equivolent is F5

 

 

This allows you to run a specific line or group of lines in the script.  For example

By clicking on the

 

You will only run the $users line of the code.  You can then check what is in the $users variable by typing $users in the left panel.

 

 

 

 

This is equivolent to CLS, it clears the output panel.

 

I like using the ISE because a) it comes with Windows, and b) it allows you to create, update, and run individual lines of a script.

 

I hope you find this information helpful.  Next week, I will show you some popular free or pay tools that add some additional functionality to the scripting environment.





Adding Security to Invoke-Command Script

Last week, I posted a script to gather user information from a different domain.  In that script the -Credential parameter was set to a specific account name.  When running the script, a prompt would ask for the password.  Although it worked it isn't the most secure way of getting the information. 

This week, let's add some additional security and eliminate the need for any additional information. 

First, you need a way to store an encrypted password.  The following script will do just that:

$credfilepath = "c:\scripts\password_file.txt"

$cred = read-host -AsSecureString "`nPlease enter the new password "

$cred | ConvertFrom-SecureString | Set-Content $credfilepath 

The first line sets the $credfilepath variable to where you want the credential file to reside.

The second line is what will prompt you for the password of the account you will be using to run the Get-ADUser statement in the main script.

The third line reads the $cred variable, converts the $cred information from a secured string to an encrypted string, and stores the information in the file assigned to the $credfilepath variable. 

Once you have the password in an encrypted format, we can make the following changes to the original script:  

$pwd = get-content C:\scripts\password_file.txt | ConvertTo-SecureString

$EXTUser = '<domain>\<user name.'

$cred = New-Object System.Management.Automation.PSCredential $EXTUser, $pwd

invoke-command -ComputerName server1.mydomain.net -Credential $cred -ScriptBlock { get-aduser -filter * -Properties * -SearchBase 'OU=Titles,DC=MyDomain,DC=Net' | Select-Object DisplayName,sAMAccountName,ObjectSid | FL } 

The first line variable converts the encrypted information in password_file.txt to a secured string.

The second line variable holds the account that has permissions to run the script.

The third line variable gets the credential information using the System.Management.Automation.PSCredential class.

Change the -Credential value, in the Invoke-Command line, to -Credential $Cred. 

Now, when you run the script, you will not be prompted for a password. 

I use this type of security method a lot at my real job.  In my opinion, it is a easy way to add a level of security to scripts. 

Please let me know if you have any questions about this script.

Using Invoke-Command on a Remote Domain Server

Greetings everybody!

Sorry for the long delay.  I was busy fishing and visiting family.  Now that summer is over I have some great stuff to post regarding things I have learned with PowerShell.

Just last week I was asked to get a list of user information from one of our external domains.  The easy path would have been to RDP to the remote domain controller and run a PS script.  However, I try to make my scripts usable by other people who don't, necessarily, have the same permissions as myself.

For me, the easiest way is to use Invoke-Command...here is the script:
invoke-command -ComputerName <FQDN> -Credential <domain\username> -ScriptBlock { get-aduser -filter * -Properties * -SearchBase 'OU=People,DC=MyDomain,DC=Net' | Select-Object DisplayName,sAMAccountName,ObjectSid | FL }

The -ComputerName must use the fully qualified domain name (i.e., tstserver.mydomain.net).

The -Credential must be an account that has sufficient permissions to run the script on the remote server.  For example, Mydomain\Administrator

You can narrow down your search by specifying the -SearchBase.  This helps keep out any clutter from Active Directory.

The output will look like this:
DisplayName          : Bob Johnson
sAMAccountName : bJohnson
ObjectSID:              : S-1-1-11-11111111-1111111111111-11111111111-1111

Next week: I will show how to use encrypted variables so you don't have to enter in a password.