I Love Powershell

Okay, technically speaking Alaska is in America, so I was already “in America” – but there was no Jack in the Box or Arby’s in Fairbanks – so does it really count?

My PowerShell skills helped me get my new job, and I’m happy to say that it’s in a place that’s much easier to live in than Fairbanks.  My new job is with UC Santa Barbara.  It’s warm and sunny here a lot.

I’m also happy that in my new role as Senior System Engineer, I’ll be focusing on some Microsoft Implementations.  First up, I’ll be getting Forefront Identity Manager 2010 moved from development to production (by way of test) and then getting SharePoint off the ground.  Both of which will include plenty of scripting with PowerShell.

I wonder what they’ll have me do in the second week?

Seriously, it’s a great job in a great location.  I couldn’t be happier – and I owe it all to God and to PowerShell (but I did a little to help, too.)

If you’re new to PowerShell, some of the first things you’ll want to do are find your way around, find the commands, aliases.  Some of the concepts, like figuring out the pipe, and how to use it, can be a struggle.

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.

Finding cmdlets that already have aliases is really easy.  You can use the Get-Alias cmdlet to find them.

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.

Read the rest of this entry »

When you use a command often, you may want to be able to access that PowerShell cmdlet more quickly from the console.  There are many aliases that PowerShell recognizes by default, but if you want to create your own, you can save yourself a lot of keystrokes.

Read the rest of this entry »

Here’s a list of aliases you can use for PowerShell.  An alias is just a shortcut.  You can use an alias from the console or in a script, and it works just the same as the command that it references.

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

Read the rest of this entry »

Did you move domains recently or reconfigure your System Center Configuration Manager (SCCM)?  Maybe you’ve found your Config Manager site code broken.  Here’s a one-liner that shows you How to update a sitecode for SCCM with PowerShell.

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