Before long, though, you’re going to start getting used to it, and then you’ll want to start saving your work so you can reuse it.  You can do that by saving a text file with a .ps1 extension.  A ps1 is just a PowerShell script.  You don’t have to have anything else in it other than the same commands you use when you’re typing in to the PowerShell console.  In fact, anything that you can type into the console can be typed into a .ps1 file exactly the same way, and then run.

So this is for my PowerShell people that are just getting to know their way around, and need to start either working with PowerShell profiles or start running PS1 files.  Once you’ve gotten the script doing what you want, you can also run a PowerShell script as a scheduled task.

Here are some things you can (and should) do to work with ps1 files, including your profile:

Tip 1:  Set the Execution Policy on One Machine (Use Group Policy for a Domain)

PowerShell takes security seriously.  By default, you cannot run scripts at all, not even your profile.  The execution policy defines what scripts you can run. 

There are four settings for the execution policy.  You can set this to whatever you like, but it may have already been set for you in your environment via group policy.  Here are the different settings you can set the execution policy to, from most restrictive to least

An execution policy is applied to a scope.  There are three scopes you can apply the policy setting to:  LocalMachine (the computer), CurrentUser (the user), or Process (the currently running PowerShell session and the policy goes away once the window is closed.)  If you don’t specify a scope, you’re setting the LocalMachine policy.  Also, there is a preference in applying scopes:  Process overrides CurrentUser, which in turn overrides LocalMachine.

• Undefined – If all scopes are undefined then it is set to the default, which is restricted.
• Restricted – No scripts may run at all.
• AllSigned – All scripts that have a digital signature may run.
• RemoteSigned – Local scripts may run.  Scripts executed from the network must be digitally signed.
• Unrestricted – All scripts may run.
• Bypass – All scripts may run, and all warnings and prompts are disabled.

Which execution policy you set is up to you.  Usually a prudent choice is RemoteSigned.  Here’s how you set it

Set-ExecutionPolicy  RemoteSigned

Easy, right?  Well without setting the execution policy, all of your scripts, even your own profile, won’t run at all.

Tip 2: Save Work You Will Use Again in a Script

If you’re not already using the Integrated Scripting Environment (ISE), you should really get to know it.

When you go to start PowerShell, instead look for the option to start PowerShell ISE.  Using the ISE gives you an opportunity to save the work that you’ve been doing often, and you can run bits and pieces of your script as you’re writing it to make sure it’s working as you intend.

Tip 3: Use a PowerShell Profile

If you are starting to get into writing down the things you do, you should look at creating a profile.  The profiles (there are multiples actually) are very useful for defining functions, mapping PSDrives, and importing modules.  If you haven’t setup your profile yet, I’ve written a post outlining how to setup your PowerShell profile

Tip 4: Use Comments, Even For Scripts Only You Will Use

When typing out your scripts into a ps1 file, it’s a great idea to use comments liberally.  Even if you think you will not be sharing this script with others, you will likely be sharing it with yourself 6 months after you wrote it.  The things that you thought would always be obvious suddenly are not.  You can save yourself a lot of frustration and time decoding your own scripts if you just add some comments throughout the script describing what you’re attempting to do with it.

The comment character for PowerShell is the Number Sign (Pound Sign, or #).  Anything written after a # in a PowerShell script file (ps1), or even in the console, are not processed but instead passed over. 

You can easily comment out a single line of your script by placing a “#” at the beginning of it, like this:

# Write-Host “This Line is a comment.  It won’t write anything”
# This is a comment too. 

# Comments can be used at the end of a single line to describe what is happening

$myVariable = 2 + 4    # This should set $myVariable to 6.

You can also comment with a comment block.  Anything written (even on multiple lines) is commented out.  A comment block starts with <#, and then anything after that is a comment until the comment block ends with a #>

<# This is a comment block

Still a comment

This is the last comment line #>

Write-host “Uncommented now”

I hope this is a help to those of you just starting out with PowerShell, and that it helps move you from just starting out, to taking the next steps towards automating with Windows PowerShell.

gal | select definition –unique

# “Gal” is an alias for Get-Alias. “Select” is an alias for Select-Object 

If you want to speed up your time at the console, you should consider finding ways to type less.  That can be done by creating aliases.  There are already a lot of aliases, but here’s how to find all the cmdlets that do not yet have an alias.

Get-Command –commandtype cmdlet | Where-Object { !(Get-Alias –Definition $_.name –erroraction silentlycontinue) }

# or, the same thing using aliases

gcm –commandtype cmdlet | ? { !(gal –definition $_.name –ea silentlycontinue)}

If you store the results in an array called $noAlias we can easily do things like “find how many cmdlets have no alias”

$noAlias.length
133

That’s 133 cmdlets with no alias.  Ripe for the picking. How about the 3 cmdlets with no alias that are the longest to type?  Here they are:

$noAlias | sort –des {$_.name.length} | select name –first 3

Name
—-
Unregister-PSSessionConfiguration
Register-PSSessionConfiguration
Disable-PSSessionConfiguration

Or instead of the longest names, here are the types of objects to perform actions on (the nouns) that may benefit from having more aliases.

$noAlias | group noun | sort –des count | select count, name –first 5

Count Name
—– —-
    7 EventLog
    6 PSSessionConfiguration
    6 Computer
    5 Transaction
    5 Event

So there you have it.  You now can see lots of places where you can further streamline your console commands by creating aliases for cmdlets that don’t have them.

FIND OUT:  Which Cmdlet’s Don’t Have An Alias Already?

When you’re ready to make an alias, it’s really easy to add it.  But you might want to consider some of the common conventions in use for aliases if you’re going to keep your alias in use for multiple sessions.

Get To Know The New-Alias Cmdlet:

The New-Alias cmdlet takes these parameters

Notice that there are two required parameters: Name and Value.  All we have to do to create an alias is populate those:

New-Alias –name ip –value ipconfig

But there is still an easier way.

Creating an Alias in PowerShell with Shortcuts

First, there is an alias for the New-Alias cmdlet:  “nal”

Second, the required “name” and “value” are positional, which means they don’t have to be named.  They can be assigned to the right parameter by putting them in their correct order.  This makes creating our alias even easier:

nal ip ipconfig

Save Your Aliases Between PowerShell Sessions

If you want to save your aliases, you’ve got two options: Either write the alias into your profile, or export the aliases using Export-Alias.

In situations like an I.T. department wants to all use the same custom aliases, or you’ve got want to use the same custom aliases on all of your machines, you should export the aliases.

Either way, you will need to create a profile before you can either define aliases or import them into new sessions

These are the default aliases that come with PowerShell version 2.  You can add to this list by creating your own alias.

Name	Definition
%	Foreach-Object
?	Where-Object
ac	Add-Content
asnp	Add-PSSnapIn
cat	Get-Content
cd	Set-Location
chdir	Set-Location
clc	Clear-Content
clear	Clear-Host
clhy	Clear-History
cli	Clear-Item
clp	Clear-ItemProperty
cls	Clear-Host
clv	Clear-Variable
compare	Compare-Object
copy	Copy-Item
cp	Copy-Item
cpi	Copy-Item
cpp	Copy-ItemProperty
cvpa	Convert-Path
dbp	Disable-PSBreakpoint
del	Remove-Item
diff	Compare-Object
dir	Get-ChildItem
ebp	Enable-PSBreakpoint
echo	Write-Output
epal	Export-Alias
epcsv	Export-Csv
epsn	Export-PSSession
erase	Remove-Item
etsn	Enter-PSSession
exsn	Exit-PSSession
fc	Format-Custom
fl	Format-List
foreach	Foreach-Object
ft	Format-Table
fw	Format-Wide
gal	Get-Alias
gbp	Get-PSBreakpoint
gc	Get-Content
gci	Get-ChildItem
gcm	Get-Command
gcs	Get-PSCallStack
gdr	Get-PSDrive
ghy	Get-History
gi	Get-Item
gjb	Get-Job
gl	Get-Location
gm	Get-Member
gmo	Get-Module
gp	Get-ItemProperty
gps	Get-Process
group	Group-Object
gsn	Get-PSSession
gsnp	Get-PSSnapIn
gsv	Get-Service
gu	Get-Unique
gv	Get-Variable
gwmi	Get-WmiObject
h	Get-History
history	Get-History
icm	Invoke-Command
iex	Invoke-Expression
ih	Invoke-History
ii	Invoke-Item
ipal	Import-Alias
ipcsv	Import-Csv
ipmo	Import-Module
ipsn	Import-PSSession
ise	powershell_ise.exe
iwmi	Invoke-WMIMethod
kill	Stop-Process
lp	Out-Printer
ls	Get-ChildItem
man	help
md	mkdir
measure	Measure-Object
mi	Move-Item
mount	New-PSDrive
move	Move-Item
mp	Move-ItemProperty
mv	Move-Item
nal	New-Alias
ndr	New-PSDrive
ni	New-Item
nmo	New-Module
nsn	New-PSSession
nv	New-Variable
ogv	Out-GridView
oh	Out-Host
popd	Pop-Location
ps	Get-Process
pushd	Push-Location
pwd	Get-Location
r	Invoke-History
rbp	Remove-Breakpoint
rcjb	Receive-Job
rd	Remove-Item
rdr	Remove-PSDrive
ren	Rename-Item
rjb	Remove-Job
rm	Remove-Item
rmdir	Remove-Item
rmo	Remove-Module
rni	Rename-Item
rnp	Rename-ItemProperty
rp	Remove-ItemProperty
rsn	Remove-PSSession
rsnp	Remove-PSSnapin
rv	Remove-Variable
rvpa	Resolve-Path
rwmi	Remove-WMIObject
sajb	Start-Job
sal	Set-Alias
saps	Start-Process
sasv	Start-Service
sbp	Set-PSBreakpoint
sc	Set-Content
select	Select-Object
set	Set-Variable
si	Set-Item
sl	Set-Location
sleep	Start-Sleep
sort	Sort-Object
sp	Set-Property
spcb	Stop-Job
spps	Stop-Process
spsv	Stop-Service
start	Start-Process
sv	Set-Variable
swmi	Set-WMIInstance
tee	Tee-Object
type	Get-Content
where	Where-Object
wjb	Wait-Job
write	Write-Output

If you’ve not started streamlining your typing at the console by using these PowerShell aliases, you can get more done per keystroke. 

A good thing to keep in mind is that while aliases can help a lot by letting you get your commands and pipelines completed quicker, aliases are not as easy to read.   So us aliases as much as you can when you’re typing at the PowerShell console, but if you’re writing a function, script, or module (or a blog post) you’re doing your readers a favor by using the complete command names.

This assumes that you’ve got SCCM running, and installed on the client.  I found this problem hanging around on our machines after a migration from an old domain into the new domain.  Each domain had Microsoft Configuration Manager installed on it, and each domain had a different site code.  A domain wide group policy was used to install the client in each domain, but I had problems with the site code for the old domain still on the Configuration Manager client after domain migration was complete.

Luckily, we can use PowerShell to change the site code, and we can even use PowerShell to discover published site codes. 

First we need to grab hold of our SMS client.  In PowerShell, it couldn’t be easier:

$sms = new-object –comobject “Microsoft.SMS.Client”

We can use the methods of the Microsoft.SMS.Client class by using PowerShell to directly work with the SMS client object:

$sms.SetAssignedSite(“ABC”)

or find out what the site code is currently set to:

$sms.GetAssignedSite()       # This returns a string value

Since the GetAssignedSite() method returns a string, it can be used in scripts to verify the site code is correct.  I use this on scripts (pushed via Group Policy on the domain roots) to verify the site code is correct, and correct the site code automatically if it is wrong.

Since I know the site code, let’s say “ABC” is the new domain and “XYZ” is the old domain, I would use this:

$sms = new-object –comobject “Microsoft.SMS.Client”

if ($sms.GetAssignedSite() –ne “ABC”) { $sms.SetAssignedSite(“ABC”) }

Finally, I’ll call attention to another method of the SMS Client object:  AutoDiscoverSite()

AutoDiscoverSite returns a site code for the Active Directory Domain (if published)

$sms = new-object –comobject “Microsoft.SMS.Client”

if ($sms.GetAssignedSite() –ne $sms.AutoDiscoverSite() ) { $sms.SetAssignedSite($sms.AutoDiscoverSite()) }

Now just a little clean up here…

Write-host “Thanks for reading.  Subscribe! Or, connect via Twitter  or Facebook.  Ask questions to twitter using #poshhelp or #powershell to get q’s answered fast!”

$null = $thisBlogPost

Ouch!  That hurt to type!

Truthfully, it could have been said of Firefox if I used it as much as I use IE.  And to be fair, Internet Explorer might not lock up as much if I didn’t abuse it by keeping 25 windows open all the time, and continue to upgrade to the most recent beta version I can get my PowerShell-scripting hands on.

So when I get stuck, I dropped this One-Liner out there.  It works great, even if the IE window is not responding to close requests through the taskbar, or through the close button on the application itself.  This kills every Internet Explorer window

get-process iexplore | stop-process

You can exercise more surgical precision by going for only the top processor intensive process (or processes if you change “–First 1” to “-First 2”)

get-process iexplore | sort –descending cpu | select –First 1 | stop-process

Or by going for only the Internet Explorer windows with active threads

get-process iexplore | ? {$_.threads | ? {$_.threadstate –eq “Running”} } | stop-process

I really like this method the most.  The thing that gives it an extra edge over the other methods is that if it kills open tabs but not all the tabs on a window, then the tab is reopened automatically.  Hopefully it’s enough of a kick in the pants to get the window open.

Have I overlooked something?  How can it be done better?