Learn How to Create Custom Column Heads for PowerShell Out-GridView

One of my co-workers, who shall remain nameless (but it rhymes with Jalcolm Meffrey), asked a good question today-namely “How do I take this custom formatting from a “Format-Table” command and use it in the gridview control (Out-GridView). It took me a couple of minutes, but the internet bestowed her bounties upon me once again. And, no I’m not talking about going to the hoochie-mama sites.

I found this old posting from Ed Wilson, “The Scripting Guy”. Thank you Ed!

Learn How to Create Custom Column Heads for PowerShell Out-GridView – Hey, Scripting Guy! Blog – Site Home – TechNet Blogs.

For those of you who won’t/can’t be bothered to read it, basically it boiled down to “Don’t use format-table, use select-object, and build your columns using the -f operator syntax”.

With some minor modifications, you turn this:

Get-CimInstance -ClassName Win32_LogicalDisk  |
Where-Object DriveType -eq 3 |
Format-Table @{n=’DriveLetter’;e={$PSItem.DeviceID}},
             @{n=’FreeSpace(GB)’;e={$PSItem.FreeSpace / 1GB};formatString=’N2′},
             @{n=’Size(GB)’;e={$PSItem.Size / 1GB};formatString=’N2′},
             @{n=’Type’;e={$PSItem.Description};width=5} -AutoSize

Into this:

Get-CimInstance -ClassName Win32_LogicalDisk  |
Where-Object DriveType -eq 3 |
Select-Object -Property @{Label=’DriveLetter’;Expression={$PSItem.DeviceID}},
    @{Label=’FreeSpace(GB)’;Expression={“{0:N2}” -f ($PSItem.FreeSpace / 1GB)}},
    @{Label=’Size(GB)’;Expression={“{0:N2}” -f ($PSItem.Size / 1GB)}},
    @{Label=’Type’;Expression={$PSItem.Description}} |  Sort-object ‘FreeSpace(GB)’ | Out-Gridview


If you were so inclined, you could swap out “Out-Gridview” for “Format-Table” or whichever output command you needed.

Thanks Jalcolm (if that is your real name) for giving me something to dig into and solve!


PowerShell Pitfalls for Managing Multiple Azure Accounts

Or PPMMAA for short . . .

Many (Most?) of the PowerShell and scripting examples for Azure management via PowerShell start with a command sequence that looks like either this:


Or this:


In either case, when you are finished and you run


You get a result set that looks like this:

If you look closely at the output you’ll notice that in addition to the expected properties for each subscription, like “SubscriptionName” and “SubscriptionId” there are two unloved little properties near the bottom of the list for each subscription “IsCurrent” and “IsDefault”. These two are important to use when are using the Microsoft Azure PowerShell console for Azure Management.

Basically, anytime you run an Azure management cmdlet, unless it has a switch that allows you to manually set an account or subscription to run against, ANNNNNDDDDD you happen to use that switch to specify a subscription, any cmdlet you run will execute against the current subscription, i.e. the one that has “IsCurrent: True”. By default, the subscription that has the “IsDefault” property equal to “True” will be the current account. (Funny how that works out, eh?). Which is all well and groovy if you happen to be managing VMs, networks and services in that subscription.

But James, what if I don’t want to manage that subscription? I need to manage one of the others. What shall I do?

Fortunately, we have the means to change the current and default subscriptions. And it is fairly easy to do.

The basic syntax to change the focus to a particular subscription is as follows:

Select-AzureSubscription -Name <SubscriptionName> -Current

The focus for your Azure cmdlets will now be on that subscription until you change it by using the Select-AzureSubscription or until you close the PowerShell console you’re working in. A new console will load up the default subscription as the focus

If you would like a particular subscription to be one that is the defaults in the future, it would be this:

Select-AzureSubscription -Name <SubscriptionName> -Default

After you have ran these cmdlets, run the Get-AzureSubscription cmdlet again to verify that the subscription you identified has now been set as either the current or default subscription. Once it is you are now free to go ahead and manage away!


How to get the latest OS image in your Azure deployment scripts

Get-AzureVMImage | where-object { $_.Label -like "Windows*" } | where { $_.Location.Split(";") -contains "West US"} | Sort-Object -Property PublishedDate | Format-List PublishedDate, Label, ImageName


via How to make sure you always have the latest OS image in your Azure deployment scripts – The Windows HPC Team Blog – Site Home – TechNet Blogs. This is a trap for new players that can have you pulling your hair out!



Here’s a slightly different bit of code, especially helpful if you happen to know the OS you want.  This makes it a re-usable function, so for a complex script that needed to create multiple VMs, you could call this as needed, adjusting for what OS you needed each time. In the example below, the function is called to populate a variable, $winimage, that would be used somewhere else in the script to create an Azure VM.

function getLatestVMImage($imageFamily)
    $images = Get-AzureVMImage |
    where { $_.ImageFamily -eq $imageFamily } |
    Sort-Object -Descending -Property PublishedDate
    $latestImage = $images[0].ImageName
    return $latestimage

$winimage = getLatestVMImage(“Windows Server 2012 Datacenter”)

Very Slick! Thank you Enrique Lima for sending this around.

Using PowerShell to Register MOC VMs

A few weeks ago my friend Telmo blogged about a very elegant solution for handling the VMs that MOC courses use. I was really impressed with what he came up with.  If you are an MCT then I would definitely recommend reading that post. Thanks Telmo!

You can find it here: http://telmosampaio.wordpress.com/2013/09/01/bulk-import-vms-for-moc-classes

That made me think about some simpler scripts that I have written that may also be of use for registering VMs for any environment. I did make some tweaks to use it specifically for registering MOC VMs, but these scripts are easily portable for any environment where you want or need to bulk import VMs.

The code below gives you a script that will do two main tasks:

1. Create some standardized private virtual switches in Hyper-V. The names match the names that the vast majority of MOC VMs use. So there are more switches in there than you would likely need, but it is easily adjusted to modify the name and number of switches being created.

2. Enumerate and import all the VMs that are found in a given path. For this to work you need to feed the name of the parent folder path where all of the VMs reside. If you forget to specify a path when you run the script, there is a basic inline help that is triggered explaining the syntax.
I put a 5 second delay between each import. I have found that if I don’t then I sometimes get strange errors on the VM imports. It feels like the script is running faster than the Hyper-V administration services can process the requests. When I put in a 5 second delay, that problem basically disappears.

I’ve put the code in here twice, one version for Windows 2008 (& R2) Hyper-V servers and a version that will run on Windows Server 2012.

Windows Server 2008 Hyper-V
(requires that the Hyper-V PowerShell module from codeplex has been installed. I didn’t get fancy by doing a check, I just load it up in the first line.)

import-module HyperV
If (!$args){
” “
“Usage of the script is as follows:”
“<path>\importvm.ps1 <VM parent folder>”
” “
“<VM Parent folder> is the path to the directory that holds the Hyper-V virtual machine directories.”
“This script will automatically register all VMs that are in that path and create two private virtual switches if required.”
#Create the private network switches
“Create the ‘Private Network’ and ‘Private Network 2’ virtual switches if required”
$switchlist = get-vmswitch | where {$_.Name -ilike “Private Network*”}
If (!$switchlist){
new-vmprivateswitch “Private Network”
“Private Network has been created.”
new-vmprivateswitch “Private Network 2”
“Private Network 2 has been created”
new-vmprivateswitch “Private Network A”
“Private Network Ahas been created.”
new-vmprivateswitch “Private Network B”
“Private Network B has been created”
“Private Network switches may already exist. Confirm that the one you require is in the list below.”
“If it is not, you may need to create it manually.”
#List the folders in the Drives directory for the course and map them to an array.
$vms = get-childitem $args | where {$_.mode -eq “d—-“}
#Parse the array and import each VM
foreach ($vm in $vms){
import-vm -path $vm.FullName
start-sleep -Seconds 5
get-vm | format-table Name,State,Status -AutoSize


Windows Server 2012

If (!$args)
” “
“Usage of the script is as follows:”
“<path>\importvm.ps1 <VM parent folder>”
” “
“<VM Parent folder> is the path to the directory that holds the Hyper-V virtual machine directories.”
“This script will automatically register all VMs that are in that path and create two private virtual switches if required.”
#Create the private network switches
“Create the Microsoft Learning virtual switches if required”
$switchlist = get-vmswitch -SwitchType Private | where {$_.Name -ilike “Private Network*”}
If (!$switchlist)
new-vmswitch “Private Network” -SwitchType Private
“Private Network has been created.”
new-vmswitch “Private Network 2” -SwitchType Private
“Private Network 2 has been created.”
new-vmswitch “Private Network A” -SwitchType Private
“Private Network A has been created.”
new-vmswitch “Private Network B” -SwitchType Private
“Private Network B has been created.”
“Private Network switches may already exist. Confirm that the one you require is in the list below.”
“If it is not, you may need to create it manually.”
#List the folders in the Drives directory for the course and map them to an array.
$vms = Get-ChildItem $args -Recurse | where Name -ilike “*.exp”
#Parse the array and import each VM
foreach ($vm in $vms)
“`nImporting {0}” -f $VM.FullName
import-vm -path $vm.FullName
start-sleep -Seconds 5
get-vm | format-table Name,State,Status -AutoSize

Hopefully, this will get you started down the path to scripting more of your common Hyper-V tasks.



Enabling Data Dedup in Windows 8

I run a lot of Hyper-V VMs on my Windows 8 laptop, and my second hard drive is getting full, with all of my inactive vhd files.  I was thinking “It’s too bad Windows 8 doesn’t have volume deduplication like Windows Server 2012.” But I decided to have a bit of a nosy around the internet to see if there was a 3rd party solution.

Lo and behold! (And really, it shouldn’t surprise me by now, but it did a little bit anyway.) I found a really useful site that taught me how to hack the 2012 Dedup into my Win8 laptop.

NOTE: Doing this will put your computer in an unsupported state (due to mixing and matching SKUs of the windows code). It is up to you to assess the risk/reward equation of these actions.

Here’s the link:


One of the dism commands is a little hard to copy/paste from his website, so here it is:

dism /online /add-package /packagepath:Microsoft-Windows-VdsInterop-Package~31bf3856ad364e35~amd64~~6.2.9200.16384.cab /packagepath:Microsoft-Windows-VdsInterop-Package~31bf3856ad364e35~amd64~en-US~6.2.9200.16384.cab /packagepath:Microsoft-Windows-FileServer-Package~31bf3856ad364e35~amd64~~6.2.9200.16384.cab /packagepath:Microsoft-Windows-FileServer-Package~31bf3856ad364e35~amd64~en-US~6.2.9200.16384.cab /packagepath:Microsoft-Windows-Dedup-Package~31bf3856ad364e35~amd64~~6.2.9200.16384.cab /packagepath:Microsoft-Windows-Dedup-Package~31bf3856ad364e35~amd64~en-US~6.2.9200.16384.cab

And since there is no gui for dedup in Windows 8, here’s a link to the online PowerShell help for the dedup cmdlets:


Adding the Lync Import-CsRgsConfiguration and Export-CSRgsConfiguration cmdlets to your Lync Management Shell

Sorry I missed a week. L I’ll make up for it with multiple posts this week. I promise.

First post isn’t a major topic, but it does address a minor annoyance of mine: having to run a PowerShell script to add the Import-CSRgsConfiguration and Export-CSRgsConfiguration cmdlets. When I fire up the Lync 2010 Management Shell, I want all the cmdlets I need available to me.

So here’s the fix:

  1. If you haven’t already done so, download and install the Lync 2010 Resource Kit tools. Assuming that you likely have put them on a Lync server (and in the default location), you should have a folder C:\Program Files\Microsoft Lync Server 2010\Reskit.
  2. From that folder, find the PowerShell script that adds the Response Group Service import and export cmdlets. It is cleverly named RgsImportExport.ps1. Copy that file.
  3. Navigate to the Lync Management Shell module directory, C:\Program Files\Common Files\Microsoft Lync Server 2010\Modules\Lync. Paste the RgsImportExport.ps1 file into that folder.
  4. In that same directory there should be a file named Lync.psd1. Find that file and open it for editing.
  5. Find the “Nested Modules” line and add ,”RgsImportExport.ps1″ to the end of that line. When finished the line should look like this:
  6. Save the changes and close the file.
  7. From here on out, when you open the Lync Management Shell on the computer to which you’ve done this, the Import-CSRgsConfiguration and Export-CSRgsConfiguration cmdlets should be loaded and at your disposal.

One thing to note, if you want the cmdlets available on multiple Lync servers you will need to do the steps above on each server.

DHCP Resiliency in Windows Server 2012

I take pleasures in the little things in life. Reading a good book, going to see a cool act that nobody else cares about (Eli “Paperboy” Reed anyone?), so while there is lots and lots of really cool new stuff in Windows Server 2012 (Fibre Channel in Hyper-V, Virtual Networks, PowerShell improvements . . .and the list goes on) I want to have a look at one of the little things. Nothing too fancy or really big and noticeable, but something I think many people will find useful, and easy to implement: DHCP Scope Failover.

In the past, if an organization wanted to reduce their dependency on a single DHCP server, they needed to implement a DHCP Split Scope design or building Failover Clusters. It works–but in my experience, even with the Split Scope Wizard, it was a bit of a pain to design and implement. And with a split scope, the reality is that you’re just splitting your overall pool between multiple servers. If a server goes down, the part of the pool that it was responsible is unavailable/unresponsive. If the server stays down a long time, that can cause you problems and may require you to build a new server with a restored copy of the DHCP database from the original server.

Windows Server 2012 provides us with a much simpler, more elegant solution: DHCP Failover. At its simplest you need two Windows Server 2012 servers, configured with the DHCP Server role, as indicated in Figure 1.

Once you have two servers, choose one of them and create and configure a scope, just as you normally would. Configure the options you require, the lease expiry etc. Feel free to use whatever management tools you prefer for this. One thing to note: if you are planning on configuring a scope for failover, you will want to make sure the options are scope-based, not server-based (unless both DHCP servers are going have identical server options, but I like to keep my scopes self-contained). In Figure 2 you can see a private network scope with fairly common scope options configured.

Now that I’ve got a scope configured on one of my DHCP servers (JFIN-SRV), I can configure it for failover. You can configure failover for either a balanced workload approach (an active-active relationship between the two servers) or a hot-failover (active-passive). Using the DHCP Manager, either of these options is fairly straightforward to configure. In DHCP Manager connected to the DHCP server currently hosting the scope, right-click on the scope and choose Configure Failover…. The first screen confirms which scope or scopes you are configuring failover for. Choose accordingly and click Next. The next screen asks you to choose or add the partner server. If you already have a scope set up for failover, then that server should be available in the drop-down. If not, you will need to click on Add Server and then enter in the name of the other DHCP server. Once you have the failover server identified, click Next.

The “Create a new failover relationship” page is the most important page in the wizard. It is here that you get to configure the parameters of the relationship between the two DHCP servers. Choose a Relationship Name that makes sense for your ongoing management.

Figure 3: DHCP Failover Hot Standby

Figure 4: DHCP Failover Load Balance

Those of you with a keen eye will likely have noticed that there are two versions of this page. Figure 3,”Hot standby” is the Active-Passive approach, and Figure 4 shows “Load balance” the Active-Active. We’ll discuss the Maximum Client Lead Time and State Switchover Interval settings a little later. First though we need to go over the differences between the two modes. If you choose “Hot standby” then you need to choose whether the server you currently have the DHCP Manager connected to will be the Active or the Standby server. Additionally, you need configure what percentage of the scope will be reserved for the Standby server. You’ll notice that it defaults to only 5%. While this has the practical effect of reducing the number of addresses that can be leased, it’s a pretty small number.

If you choose “Load Balance”, then the two servers will share the workload in the percentages you choose. Both servers know about the entire scope (a bit different from the Hot standby mode) and use an internal algorithm based on the MAC address of the requestor to determine which server will handle the request and with what address. You change the percentages it changes the algorithm. It’s pretty hands off. To secure the failover messages between the servers, set a Shared Secret.

That leaves two settings that need to be configured. These settings control the speed with which full failover occurs. A scope (or servers) configured for DHCP Failover have three main states of being: Normal, Communication Interrupted and Partner Down.

Obviously, “Normal” is the mode you want to see most of the time. If a server loses communication with it’s partner, then the mode switches to “Communication Interrupted”. During this state you can manually trigger a failover to the remaining server if you know that the failed server is not coming up soon, and the remaining server will take over responsibility for the entire scope. The remaining server will wait for the Maximum Client Lead Time before taking control of the entire scope. If you want a remaining server automatically switch from “Communication Interrupted” to “Partner Down” (thus triggering the Maximum Client Lead Time interval) you can set the State Switchover Interval value to determine how long it will stay in “Communication Interrupted” before switching over.

You will want to consider the impact these two properties may have on the load balance or standby reservation percentages. Especially in a Hot standby scenario, if you set a long Maximum Client Lead Time and State Switchover Interval, then you might think about increasing the percentage held on the Standby to better service requests until full failover occurs. Having said that, you will want to have some idea how many IP addresses are normally refreshed within whatever timeframes you configure, and make sure that whatever percentages you set will support that.

Once you have finished on that page of the wizard, click Next and then click Finish to complete the configuration. When you are done, you can use the DHCP Manager to see that the scope now has a Status of “Active” and is configured for a failover relationship, as shown in Figure 6. You can do the failover management by right-clicking on the scope and choosing the appropriate replication options to move all active leases from one member of the partnership to another (perhaps for maintenance of one server), as well as an option to deconfigure failover.

Pretty easy to configure, easy to manage. Pleasure in the little things.

Managing PowerShell 3.0 Updateable Help

***Author’s Note:  I was in a rush and didn’t properly preview the graphics for this post in my browser. If you are finding them hard to read, try using your browser’s zoom-in capability. I found that if I zoomed in a bit, the text in the graphics became legible.  Sorry. :(***

Updateable Help is one of the new features of PowerShell 3.0. The biggest benefit of Updateable Help is the improved accuracy of the inline help, especially across patches/service packs/module additions. While I have to admit that the inconsistencies that would creep in were not a major issue for me personally, I can see how it would create frustration. So we’re going to look at some of the basics of using and managing help for PowerShell 3.0

Using Help

First first—I’m going to assume that if you’re reading this blog that you don’t me to tell you how to get help for PowerShell cmdlets. But you will notice that if you have a computer that has not gotten updated help (and out of the box, it won’t have), you’ll see that a normal Get-Help cmdlet will return the basic list of switches.

You’ll also notice that in the Remarks Section it tells you that the full help has not been downloaded. When you add the –Detailed switch to your Get-help command, the results are not much different. Each switch gets its own line, but the detail you are likely looking for is not there. Again, the Remarks section is telling you to get the updated help. Obviously, getting the updated help is a valid option, but not the only option.

There is a new switch for Get-Help, -Online. Assuming that the computer from which you are running powershell has an internet connection, this allows you to get the detailed help you need, without forcing a full update of the help files. It will open a web browser session and take you to the TechNet Library page for the help for the cmdlet you indicated.

Getting the Help onto Your Machine

That might be fine for module-specific cmdlets that I don’t use often, or while tweaking a script on a server (as opposed to writing a script in whatever environment you normally use), where you don’t really need the help there all the time. However, on the machine that you DO want the help at hand more readily you really want the help files on your machine. Microsoft has provided Update-Help for this.

For the help to update properly I’ve found that I need to make sure I am running the PowerShell console under the Administrator User Account Control (right-click, Run As Administrator).

Once I’ve done that, then I can keep it really simple with the cmdlet Update-Help

If you look at my results you’ll notice a couple of things.

  1. I didn’t run this with the appropriate UAC so some of the help files didn’t update. Easily fixed. Open a PowerShell Console in the correct context and that goes away.
  2. There were a couple of other errors about DTD files and incorrect URIs. Those have to do with the help files not being available properly from the Microsoft servers. Instances of those errors should drop over time. If you want a detailed explanation of what exactly is happening, read this: http://bit.ly/SoMnIB . It explains it all quite well. So we’ll ignore those for the moment.

There are additional switches for the Update-Help cmdlet that allow you more control over what is going on. For instance, the –Module switch allows you to update the help only for a specific module. Take the time to explore those switches and see which ones may be of use to you.

How Do I Update Help if my server doesn’t have access to the Internet?

That was the first question that popped into my head when I first came across this idea of Updateable Help. The solution is reasonably straightforward and done in four steps.

  1. From a machine with internet access (and the appropriate modules you want the help for) run Update-Help.
  2. From the same machine run the Save-Help cmdlet. Save-Help will copy the help files to a directory of your choosing. Much like Update-Help, you can use a –Module switch to only save the help files for a specific module. The main parameter you need to provide is the parent directory where you want the files saved. In the example below I only saved the help for the Hyper-V module.
  3. Somehow transport the directory with all the help files to the computer(s) that don’t have internet access. Network share, portable drive of some sort, whatever works for you really.
  4. On the isolated machine, run Update-Help –SourcePath <path to folder that holds the help files> -Module <Name(s) of modules that have help files in that directory>

You can see in the screen shot below how steps 1-3 work. You will notice that I created a folder to hold the help files, and then ran Save-Help only for the Hyper-V module (for the sake of simplicity). I then displayed what files were put in the destination path.

  1. Once I had done that I can transfer the .cab and .xml files to the remote machine. In this instance I created a folder called “HyperVHelp” on the destination machine and put the files that folder. Once I had done that I ran Update-help. You will note that I used the –Module switch to keep it simple. Had I not done that, my screen would have been filled with red as it tried and failed to update the help for all known modules. The Hyper-V help would still update, but all the error messages are a bit off-putting. So I only updated the module I had help files for.

I ran the Update-Help command a second time, just to show you what can happen if I try to update help files that are currently up-to-date. As you can see, nothing major happens, so there’s no big concerns in that space.


As you can see, the process for updating and managing PowerShell’s help is not terribly difficult. With a bit of practice and planning you should be able to develop and implement a plan for keeping your PowerShell inline help current and useful.

PowerShell 3.0 Workflow Basics

There are lots of new features and functionality in PowerShell 3.0, a brief overview of them found here: http://technet.microsoft.com/en-us/library/hh857339

One of the features that I find most exciting is the new scripting construct, Workflow. If you are familiar with creating a custom Function in PowerShell, then you know most of what you need to know about creating a workflow.

So what’s the difference?  The difference is that when you creating a new command using “Workflow” instead of “Function” in a script, the new command has access to a built-in library of common management parameters, such as PSComputerName, which enable multi-computer management scenarios.  This will make your scripts more powerful, and can be developed in a much simpler fashion.

Below you can see a very basic Workflow that I’ve created and saved on a member server in a domain.

As you can see, the Workflow itself is very basic, doing nothing more than gathering information about the powershell environment and writing it out to a text file that will site on the root of the C: drive. In reality this would need a lot more work, as it assumes that PowerShell is running, which is not a safe assumption if you’re getting this to execute on remote machines.  But ignore that, and assume that you do have a powershell console open on your remote machine.

I could have done the exact same thing with “Function” and it would work just fine on the local machine in which I ran the script.

However,  a look at the help for Get-PowerInfo reveals a host of parameters that are built in to the workflow.

Of immediate interest is -PSComputerName.  This parameter allows the code to run on remote machines (running PowerShell 3.0 and w/ remoting enabled) without me having to specifically add code to the workflow to manage remote sessions or import modules etc.

You can see that my workflow executes successfully, and when I go look at the C: drive on jfin-dc, the output text file has been created.

Obviously, a very simple use (and not all that practical in an of itself), but hopefully you can see that there is a great deal of power in this new Workflow construct in PowerShell 3.0.  As a scripting administrator, I can see how this will make my remote management scripts more powerful and easier to write.