Before reading my comments, you might want to download the event instructions:

• Beginner 4: An Auditing Adventure
• Advanced 4: An Auditing Adventure

The first entry I will comment on is from Beginner 4:

• Comment based help is leveraged to provide a synopsis, description and basic usage. Comment-based help and the Active Directory module which is leverage was introduced in PowerShell 2.0, thus #requires –version 2.0 could have been used to prevent users trying to run this in PowerShell 1.0 getting error messages.
• HTML-formatting (head, pre- and post-content) as well as a couple of other variables is defined (note that I have updated my previous article with more info on working with HTML in PowerShell). I would also suggest the search base to be specified as a variable rather than a hard coded path in the script. Although, this is specifically stated in the synopsis.
• The time stamp for when the report was created is included in the bottom of the report as required by the event instructions. In addition the username of the user generating the report is added, which is nice.
• The actual cmdlets generating the report is a one-liner, nicely formatted on multiple lines for readability.
• The lastlogon date property is used to determine when the users last logged on to the domain. There are ways to retrieve this information, and not all of them is accurate. For example the lastlogontimestamp property will be 9-14 days behind the current date. For more information, see this article on the “Ask the Directory Services Team” blog. To get a more accurate time stamp, you might want to query all domain controller, see this TechNet article for one example on how to accomplish this. Although I would not withdraw any points for not catching this “gotcha”, I would give a bonus point for those who did.

The second entry I have decided to comment on is from Advanced 4:

• Leveraging the #requires statement is a good practice, however, this should be separated into two lines. When the script is run “as is” in PowerShell 2.0 the following error will be returned: “Cannot process the “#requires” statement at line 1 because it is not in the correct format.”. If separating into two lines, it will work in both 2.0 and 3.0:

#Requires -Version 3.0
#Requires -Module ActiveDirectory

• Comment based help is leveraged in an excellent way, providing both help for all parameters as well as several examples.
• [CmdletBinding()] is defined in order to use [Parameter()] decorators to validate input. Although there is nothing wrong with parameterizing this as a script, I would consider to turn it into a function (a personal preference).
• The FilePath parameter is marked as mandatory, as well as positional. This is perfectly fine, but another option would be to default to a path using an environment variable (for example $env:userprofile\Documents\Report.html). The requirement of validating the filename extension (htm or html) is accomplished using a regular expression inside a ValidateScript validation.
• The Count parameter is configured with a default value of 20 as required. In addition ValidateRange is leveraged to make sure the number specified is valid. This is not necessary, as defining the parameter as an integer would perform the necessary validation:

Cannot convert value “2222222222222222″ to type “System.Int32″. Error: “Value was
either too large or too small for an Int32.

• Two additional parameters is supplied: One for overwriting the report-file if it exists (-Force) and one returning the newly created HTML file (-PassThru). These two parameters provide additional functionality not required by the instructions.
• The parameter values for ConvertTo-Html is quite large, and providing these as a hashtable and leveraging splatting makes it more readable. This also makes it possible to collapse/expand the HTML-code (the hashtable) in PowerShell ISE.
• The PSCustomObject type accelerator is used to create new objects. There are many ways to create new objects in PowerShell 3.0, but this is the easiest/preferred way in my opinion. Also, the new [ordered] type adapter in PowerShell 3.0 is leveraged to decide the order of the properties, rather than using Select-Object which will actually create new objects (more overhead).

Like the previous events, there have been many great submissions in event 4. Keep up the good work, and good luck with event 5 – “The Logfile Labyrinth”.

Before reading my comments, you might want to download the event instructions:

• Beginner 3: A Disk Decision
• Advanced 3: A Disk Decision

The first entry I will comment on is from Beginner 3:

• Two pieces of information is required for this event, which we typically find in WMI. Since the instructions clearly stated that both CIM and WMI is available, and we do not have to think about authentication or firewalls, I find leveraging CIM a good practice. CIM is the newest technology, based on standards based management. It also requires just one firewall port to be open, compared to WMI which requires a lot more. Although, I would not give less points if WMI was leveraged in this event, since this is also a valid option in the instructions. In the real world however, we would typically need to think about authentication and firewalls in addition to other considerations, such as legacy systems. If Windows 2000 was still present, CIM would not have worked against WMI on that system without specifying the DCOM protocol for the CIM session.
• Filtering is performed on the server side, which speeds up the query. A bad practice would have been skipping the –Filter parameter, and performed the filtering on the client side using Where-Object.
• Extracting the data required by the instructions is done using Select-Object. What I also like is that formatting the data is done in the same operation. The –f operator is used to format the data, and PowerShell`s built-in constants for converting values to MB and GB is leveraged.
• PowerShell has built-in capabilities to convert objects to HTML, in the form of the ConvertTo-Html cmdlet. This is leveraged in a way that meets the goals for the event instructions: The 3 properties needed is specified, and a header and a footer is added with the required data. However, a bonus point would have been added if the computer name was added to the header as specified in the event instructions. This is an example of how important it is to read the instructions carefully. I would recommend you to read through the instructions one more time before submitting your entry, as you might miss things like this.
• The FilePath parameter is omitted on Out-File. This works fine since the parameter is positional. However, I prefer to use full parameter names when sharing scripts or even one-liners with others.
• The instructions required a one-liner. Many people takes this literally, and place everything on one line. That is very bad for readability. This submission leverages the pipeline symbol, the comma and the back tick to continue on the next line. This is fully counted as a one-liner. However, the semi-colon as some people used does not qualify for a one-liner. This is simply a statement separator, and will break the pipeline.

The second entry I have decided to comment on is from Advanced 3:

This entry does produce a nice looking HTML-report with the required data. However, there are some bad practices I would like to highlight as learning points:

• A ping function is created. This is not required, as PowerShell has a Test-Connection cmdlet giving the same functionality.
• The naming of the function is not very descriptive for the end user sitting at the helpdesk.
• The HTML code is created in a here-string rather than leveraging PowerShell`s ConvertTo-Html cmdlet. This makes it harder than necessary.
• Aliases is used. This is ok when working interactively when you want to type fast, but not in a script or function you will share with others (think readability).
• Write-Host is used (don`t kill puppies), use Write-Verbose to output additional information. Alternatively, output an object even if the computer could not be contacted. You could add a “Connectivity” property to inform the user whether the computer was reachable or not, and add this to the report.

There have been many great suggestions in this event. Keep up the good work, and good luck with event 4 – “An Auditing Adventure”.

Update 2013-05-21: The good thing about the Scripting Games is that everyone learns something, including the judges. I haven`t been using here-strings for creating HTML, but as Rob Campbell (@mjolinor) stated on Twitter: “Here strings are an AWESOME tool for creating HTML or XML documents. ” -Jeffrey Snover. (link). Of course, this implies that you know HTML. On the topic of HTML, I would also like to recommend Don Jones` free ebook “Creating HTML Reports in PowerShell“. Available with the book is also a PowerShell module for working with HTML. In addition, there is also a very good session recording from the 2013 PowerShell Summit by Jeffrey Hicks called “Creating HTML Reports With style“.

Before reading my comments, you might want to download the event instructions:

• Beginner 2: An Inventory Intervention
• Advanced 2: An Inventory Intervention

The first entry I will comment on is from Beginner 2:

Note: I am testing Gist as a way to share code snippets. I may need to edit the article after posting, please refresh your browser or go to the Gist URL manually if you do not see the code.

• I find using [System.Net.Dns]::GetHostEntry unnecessary in this case, as the name of the computers will be available from the WMI calls being used.
• Whether to use the foreach statement or the ForEach-Object cmdlet is not that relevant in this case, as saving the contents of a small text-file into memory does not consume much resources.
  However, using Foreach-Object two times is unnecessary, there is nothing that prevents wrapping everything in one foreach-loop.
• The event instructions did not require you to provide alternate credentials. Since it is done anyway in this submission, I would rather save the credentials into a variable once and re-use that variable inside the foreach-loop. If not, the user will be prompted for credentials two times for each computer in the text-file.
• Re-writing the property names in the last line to make them more user-friendly is good, but there are some room for improvement in this line as well. Consider using Select-Object instead of Format-Table, this will make it up to the user what to do with the output. For example outputting them to a Csv-file using Export-Csv, or creating an HTML-report using ConvertTo-Html. Consider breaking the line into multiple lines to make it easier to read. Do not use aliases (ft in this case) when sharing a script, this makes it harder to read. Aliases are good though, when you work interactively in the shell and want to type as quickly as possible.

The second entry I have decided to comment on is from Advanced 2:

• The use of the #requires statement is good, since this function leverages new functionality in PowerShell 3.0 which would have caused errors in previous versions of PowerShell.
• Comment based help is leveraged in an excellent way, showing a very detailed description, help for each parameter, several examples, and what kind of object the function accepts as input and produces as output. .PARAMETER ShowProtocol is missing, although this parameter is documented in the description.
• The function accepts input from the pipeline by using [Parameter(ValueFromPipeline=$True)], which makes it possible to pipe the contents of a txt-file to the function as shown in one of the examples.
• A new Cim Session Option object is created in the begin block, defining DCOM as the protocol. This is a good example of showing how to use the begin block, which is typically used for operations that needs to be performed once for all of the objects that will be processed in the process block. One of the most common examples of using the begin block is connecting to a database server, but this function also shows another usage scenario.
• The new CIM cmdlets in PowerShell 3.0 is leveraged when WSMAN 3.0 is available, if not the legacy DCOM protocol is used. This way, the function will work against both newer systems like Windows Server 2012 as well as older systems like Windows 2000 Server. As stated in the description, “The Cim cmdlets have been used to gain maximum efficiency so only one connection will be made to each computer.”.
• Error handling is implemented, ensuring that even if the function is unable to connect to a computer, an object is returned stating that it was not possible to connect to the computer.
• Splatting is leveraged for passing parameters, see examples on line 71 and line 95.
• The function is outputting a custom object rather than text or formatting objects. This makes it up to the user using the function to decide what to do with the data. The new [ordered] syntax in PowerShell 3.0 is leveraged when creating the hash table which is passed to New-Object, in order to control the order of the properties of the custom object.

It has been fun to read through many of the great submissions made to event 2. Keep up the good work, and good luck with event 3 which starts May 9th.

The first entry I have decided to comment on is from Beginner 1: An Archival Atrocity.

$RootPath = "C:\ScriptingGames\Application\Log"
$Paths = Get-ChildItem $RootPath
$ArchivePath = "C:\ScriptingGames\Archive"
$varTime = (Get-Date).Adddays(-90)

ForEach ($Path in $Paths)
{
    If ((Test-Path "$ArchivePath\$Path") -eq "True")
        {
            Echo "Path Exists"
        }
    Else
        {
            Echo "$Path Created"
            Mkdir "$ArchivePath\$Path"
        }
    
        Get-ChildItem -literalpath "$RootPath\$path" -Include "*.*" -Recurse | Where-Object {$_.CreationTime -lt "$varTime"} | Move-Item -Destination "$ArchivePath\$path\" 
}

Learning Points

• Add comment based help. This makes it more easy for others to leverage the script, you also get the benefit of using Get-Help on your function or script.
• The instructions did not require any output, consider using Write-Verbose instead of Write-Output. This makes it up to the user leveraging the script to decide if any output is wanted, by editing the $VerbosePreference automatic variable.
• Avoid using aliases in scripts (Echo and Mkdir in this case), although it is great for interactive use when you want to type quickly.
• When sharing a script, I also prefer to use full parameter names. For example Get-ChildItem -Path $RootPath instead of Get-ChildItem $RootPath.

The second entry is from Advanced 1: An Archival Atrocity.

function Move-Log{
<#
.SYNOPSIS
Moves old log files in the specified repository to another location.

.DESCRIPTION
Move-Log is used to move old log files from specified application folders in a root log repository to a new location. 
By default only files older than 90 days are moved, but this can be configured with the -Period parameter.
Subfolder structure is mantained in the destination path.

.PARAMETER LogPath
Specifies the root path of the log repository.
Default = C:\Application\Log

.PARAMETER ApplicationLogFolder
Specifies application folders in the log repository that may contain log files.

.PARAMETER DestinationPath
Specifies the new location for the log files.

.PARAMETER Period
Specifies how old, in days, must be the log files to be moved.
Default = 90

.EXAMPLE
Move-Log -ApplicationLogFolder App1, OtherApp, ThisAppAlso -DestinationPath \\NASServer\Archives

This will move files older than 90 day located in "C:\Application\Log\App1", "C:\Application\Log\OtherApp" and "C:\Application\Log\ThisAppAlso" 
to their respective destination folders "\\NASServer\Archives\App1", "\\NASServer\Archives\OtherApp" and "\\NASServer\Archives\ThisAppAlso".

.EXAMPLE
Move-Log -LogPath C:\MyLogRepository\ -ApplicationLogFolder App1,OtherApp,ThisAppAlso -DestinationPath \\NASServer\Archives -Period 365

This will move files older than 1 year from "C:\MyLogRepository\App1", "C:\MyLogRepository\OtherApp" and "C:\MyLogRepository\ThisAppAlso" 
to their respective destination folders "\\NASServer\Archives\App1", "\\NASServer\Archives\OtherApp" and "\\NASServer\Archives\ThisAppAlso".

.INPUTS
None.
.OUTPUTS
None.
#>
    [CmdletBinding()]
    param(
    [ValidateScript({ Test-Path $_ -PathType Container })]
    [string]$LogPath="C:\Application\Log",
    [Parameter(Mandatory=$true)]
    [ValidateScript({ Test-Path "$LogPath\*" -Include $_ -PathType Container })]
    [string[]]$ApplicationLogFolder,   
    [Parameter(Mandatory=$true)] 
    [ValidateScript({ Test-Path $_ -PathType Container })]
    [string]$DestinationPath,
    [int]$Period=90
    ) 
    
    # Get the date limit. Only files older than that date will be moved    
    $DateLimit = (Get-Date).AddDays(-$Period)

    foreach ($AppFolder in $ApplicationLogFolder)
    {
        $AppLogPath      = "$LogPath\$AppFolder"
        $DestAppLogPath  = "$DestinationPath\$AppFolder"

        # Create destination folder if not exists
        if (!(Test-Path $DestAppLogPath -PathType Container))
        {
            try
            {
                New-Item -Path $DestAppLogPath -ItemType Directory -ErrorAction Stop -ErrorVariable $DirectoryError
            }
            catch
            {
                Write-Error "Error creating destination directory $DestAppLogPath. Error: $DirectoryError"  
                # Jump to the next $AppFolder              
                continue
            }
        }

        # Get the name of the files to move
        $FilesToMove = Get-ChildItem $AppLogPath -File | Foreach { if ($_.LastWriteTime -lt $DateLimit) { $_.Name } }

        foreach ($File in $FilesToMove)
        {
            $FilePath = "$AppLogPath\$File"
            $DestPath  = "$DestAppLogPath\$File"

            # Move the file
            try
            {
                Move-Item -Path $FilePath -Destination $DestPath -ErrorAction Stop -ErrorVariable $MoveError
            }
            catch
            {
                Write-Error "Error moving file $FilePath to destination $DestPath. Error: $MoveError"
            }
        }
    }     
}

Learning Points

• The use of a function makes this tool easier to reuse without the need to call a script each time.
• The use of an advanced function makes it work more like an actual cmdlet, since you can do more advanced things such as marking a parameter as mandatory and validating the arguments. For more information, see Get-Help about_Functions_Advanced.
• This is also a good example on leveraging comment based help. All parameters is properly described, and a few examples is provided. Often the first thing people look at before reading the actual help is the examples, so it is important to provide at least a couple of them.
• The use of parameter validation is excellent, as this simplifies the function and is leveraging functionality PowerShell is providing “for free”.
• Default values is configured for the LogPath and Period parameters. This means that these parameter values will be used if the user using the function does not specify these parameters. It is also easy to change the values if needed, which was a requirement for this task.

There have been many great submissions for the first event. Keep up the good work, and good luck with event 2 which starts May 2.

There are also some differences in how the games is run. Previously, only the jugdes could assign scores. Now everyone can vote on submitted scripts, while the judges will review and comment on selected submissions. I highly encourage you to read the Competitor Guide (link in the resource section below), which is a PDF-file with all the information you need to know in terms of the games.

I will participating as a judge, and I am really looking forward to writing articles about some of the submissions.

Whether you are a beginner in terms of using Windows PowerShell, or an experienced scripter, the scripting games is a perfect opportunity to challenge yourself and get feedback on your work. Remember, the key point about the games is learning. Good luck to all participants!

2013 Scripting Games Resources

• 2013 Competitor Guide
• 2013 Scripting Games schedule
• Scripting Games Announcement Channel
• Scripting Games Judges Notes
• Twitter hashtag: #Psh2013

When virtual machines are migrated (imported) to a Windows Server 2012 Hyper-V host, the virtual hard disk files is not automatically converted to the new VHDX format. This is something you must do manually, either by using the “Edit Virtual Hard Disk Wizard” or by using the Convert-VHD cmdlet in the Hyper-V PowerShell module.

As soon as a virtual machine is migrated from an earlier version of Hyper-V to Windows Server 2012 Hyper-V, best practice would be to convert the virtual hard disk files to the new VHDX format.

If you have more than a couple of virtual machines, it would be a good idea to automate the conversion process. You can start to explore the Convert-VHD cmdlet by running Get-Help “Convert-VHD” –ShowWindow:

If you do not get a similar result as above, run Update-Help from an elevated PowerShell session and try again.

If you scroll to the bottom you will also find a few examples:

Example 1 shows how to convert a single VHD file to a new VHDX file. There are several things to consider before doing this in a production environment:

• Should you keep the source VHD in case something goes wrong? If no, add the –DeleteSource swich parameter.
• Should you use Fixed disks or Dynamically expanding disks? There are different recommendations both in the community and in Microsoft. In the Performance Tuning Guidelines for Windows Server 2012 dynamically expanding is recommended, while in this Premier Field Engineering (PFE) blog article Fixed size is recommended. To read more opinions from the community, see this article by Virtual Machine MVP Aidan Finn as well as this article by Virtual Machine MVP Thomas Maurer.
• The virtual machine must be stop before its virtual hard disk files can be expanded.
• The old VHD file must be replaced by the new VHDX file in the virtual machine configuration.
• Enough disk space must be available on the underlying data disk. For example, if the VHD file to be converted is 100 GB, you must have minimum 100 GB free space on the data disk for the destination VHDX file.

I have created a sample PowerShell script below which will convert VHD-files for stopped virtual machines to VHDX. If the virtual hard disk files for the stopped virtual machines is already of type VHDX, the virtual machine will be skipped.

You may want to add additional logging and error handling before using this script in a production environment. I would also encourage to always test the script in a lab environment before using it in production.

You can find the script here on the Microsoft TechNet Script Center.

In an enterprise environment the help system typically needs to be centrally managed. There are several ways to accomplish this, for example we can use the “Set the default source path for Update-Help” Group Policy setting under Computer Configuration->Administrative Templates->Windows Components->Windows PowerShell to specify a default value for the SourcePath parameter:

In order to automatically update help files on computers running PowerShell 3.0 we can leverage scheduled tasks and distribute these through Group Policy.

1) On a computer running Windows Server 2012 or Windows 8, create a scheduled task that will periodically run the Save-Help cmdlet to save the files to a central location. This is not mandatory, but typically large environments have computers without internet access, thus it may be appropriate to download the help files to a central file server. In order to retrieve help files for all modules you should also install all management tools from Server Manager on the Windows Server 2012 computer running the scheduled task (using Remote Server Administration Tools if running Windows 8). Note that there is a HelpModules available which removes the requirement to install the management tools made by PowerShell MVP Joel “Jaykul” Bennett. You can read more in his blog post “Get-Help for Modules you don’t have installed”.

Create a new scheduled task which runs with the computer account`s credentials (SYSTEM):

Note: Remember to configure the file and NTFS settings for the central file share to allow Domain Computers to read the files.

Next, configure an appropriate time when the scheduled task should run:

Configure an action with the Start a program option:

Path: C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe
Arguments: -Command “& {Update-Help;Save-Help -DestinationPath ‘\\server\share\PowerShell\Help-files’}”

This will first run Update-Help to retrieve the newest help-files from Microsoft, and Save-Help to save the help-files from the local computer to the central file share.

Note: You could also use PowerShell to create the scheduled task which will run Save-Help, an example can be found in this blog post by Pat Richard.

2) On a Group Policy object which will affect all computers where you want the help files to be deployed, create a new scheduled task using Group Policy Preferences:

Create a new scheduled task which runs with the computer account`s credentials (SYSTEM):

Next, configure an appropriate time when the scheduled task should run (this should run shortly after the Save-Help scheduled task is run):

Configure an action with the Start a program option:

Path: C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe
Arguments: -Command “& {if (($PSVersionTable.PSVersion).Major -ge 3) {Update-Help -SourcePath ‘\\server\share\PowerShell\Help-files’}}”

You could also use Item-level targeting in order to create the scheduled task only on computers where PowerShell 3.0 is installed (if doing so, the if (($PSVersionTable.PSVersion).Major statement above can be dropped):

Here we test if the key named “3” exists under the PowerShell hive in HKLM:

Finally the task is created:

When future PowerShell versions is released, for example PowerShell 4.0, the Item level targeting must be updated to check for the “4” key in the registry as well. Alternatively an even more clever method to determine that the minimum version of PowerShell is 3.0 may be incorporated (please leave a note in the comments section below if you create one).

Resources

• about_Updatable_Help
• Understanding and Using Updatable PowerShell Help
• How Updatable Help Works

I did a session together with my colleague at Crayon Norway, Ingar Kopperud, called “Configuration Manager 2012 – Automation using PowerShell”. In the session we provided an overview of the new Windows PowerShell module in Configuration Manager 2012 SP1 before we looked at automation of the initial configuration of a Configuration Manager infrastructure. After that we showed how to automate deployment of distribution points, before we ended the session by showing how to automate application deployment. The session was very demo focused, thus we had only 3 slides in our presentation. The slides is available here, while the video recording is available here.

Video recordings of all the other sessions at NIC 2013 is available here (there is a “click to view video” link for each session).

PowerShell related videos

• NICconf Opening and Keynote: Modernizing Windows Server/Modernizing Ourselves – by Jeffrey Snover
• Jeffrey Snover: PowerShell CrashCourse

Dear Jan Egil Ring,
Congratulations! We are pleased to present you with the 2013 Microsoft® MVP Award! This award is given to exceptional technical community leaders who actively share their high quality, real world expertise with others. We appreciate your outstanding contributions in PowerShell technical communities during the past year.

This is the 3rd time I receive this award, and I am very honored and privileged to be part of this amazing community. Windows PowerShell 3.0 was released as part of Windows 8 and Windows Server 2012, with a very broad PowerShell coverage. I`m looking forward to contribute and interact with the PowerShell community in 2013, as we see that PowerShell is becoming more and more important.

Resources

About the MVP Award Program

Windows PowerShell MVP Awardees

Jan Egil Ring`s MVP Profile

Windows Azure Virtual Machines

The first offering for running virtual machines in Windows Azure was the VM Role, targeted at scale-out cloud services. This offering made it possible to upload your own Windows Server 2008 R2 VHD image, which could be managed using Remote Desktop. The main disadvantage with this service from an IT Professionals perspective is that the service uses non-persistent storage.

The new Virtual Machines offering, currently available in Preview, brings more features which makes it more attractive for IT Professionals. The main differences compared to the VM Role is persistent storage, and more networking features. This means you can configure your own networks as well as a VPN tunnel to your on-premises network in Windows Azure Virtual Machines. This makes the offering attractive for many scenarios, such as:

• Using Windows Azure as a secondary site
• Deploying services typically deployed in a traditional DMZ, such as scale-out web servers
• Lab and demo environments

Windows Azure PowerShell Cmdlets

There are several API`s available to automate Windows Azure administration. Targeted mainly at developer there is a Windows Azure REST API. For IT Professionals there are Windows Azure PowerShell Cmdlets available. The first PowerShell Cmdlets for managing Windows Azure was available on Codeplex, while the currently available cmdlets is available directly from the engineering team. The cmdlets is available as a Windows PowerShell module, and requires Windows PowerShell 2.0 or 3.0. Features which can be managed from the module includes:

• Subscriptions
• Virtual Machines
• Virtual Networks
• Storage Accounts
• Cloud Services

Installation

The steps to download, install and configure your computer for the Windows Azure PowerShell Cmdlets is well documented on the Get Started with Windows Azure Cmdlets website.

The download link points directly to the Windows Azure PowerShell application available in the Web Platform Installer:

The installer will add the path (C:\Program Files (x86)\Microsoft SDKs\Windows Azure\PowerShell\) to the Azure PowerShell module to the $env:PSModulePath environment variable, which means you can import the module using the module name:

Import-Module Azure

If you are using Windows PowerShell 3.0, you can skip the manual module import, due to the new module autoloading feature.

If you have not enabled execution of PowerShell scripts on your computer, you would need to configure your PowerShell execution policy before importing the Azure PowerShell module. A general recommendation is to use RemoteSigned:

Set-ExecutionPolicy RemoteSigned

To explore the available cmdlets, we can use Get-Command:

Get-Command -Module azure

There is also an overview of the currently available cmdlets on the Windows Azure Management Cmdlets website.

Configuration

Before you can use any of the cmdlets to manage your Azure subscription, you must configure the publish settings and subscription information for your Windows Azure subscription. There are two ways to accomplish this:

1. Automated configuration using Get-AzurePublishSettingsFile and Import-AzurePublishSettingsFile
2. Manual configuration using Set-AzureSubscription and Select-AzureSubscription

#1 is the easiest one, you first run Get-AzurePublishSettingsFile which opens your default web browser where you have to sign-in to Windows Azure in order to download your settings file. When you have downloaded the file you use Import-AzurePublishSettingsFile and specify the path to the .publishsettings file you downloaded.

#2 requires more work, but is appropriate if you want more control over the settings. For example you may want to use your own certificate which you have uploaded to the Windows Azure Management Certificates store. This is a sample on how to use Set-AzureSubscription:

   1:   Set-AzureSubscription `

   2:       -SubscriptionId   26e6d24e-7e46-4a30-9f58-a14706bbfea1 `

   3:       -Certificate      (Get-ChildItem cert:\currentuser\my\8A15ED234D550ECBEDB7E051C59820105BFC2BEC) `

   4:       -SubscriptionName "Windows Azure MSDN – Visual Studio Ultimate"

Now you should be able to use Get-AzureSubscription to see the details of the subscription you have configured. If you have configured more than one subscription, you can switch between the subscriptions using Select-AzureSubscription.

One last thing you might want to configure is a default storage account. Several cmdlets requires you to specify a storage account, which you will not need to do if you have configured a default account. To list the available storage accounts, run Get-AzureStorageAccount. To configure a default account, use Set-AzureSubscription with the CurrentStorageAccount parameter. An example:

Get-AzureSubscription | Set-AzureSubscription -CurrentStorageAccount portalvhdspd3kt2t

Usage

Now that you have installed and configured your environment for Windows Azure PowerShell cmdlets, you are ready to use them.

I would recommend you to start exploring what is available by using the Get- cmdlets. You can obtain all of the Azure Get- cmdlets by using Get-Command:

Get-Command -Module azure -Verb Get

For example, start with the Get-AzureVMImage cmdlet to obtain information about the available virtual machine images:

Get-AzureVM will list your virtual machines:

Start a virtual machine:

A few examples of typical usage:

   1:  # Create a new virtual machine

   2:  New-AzureVMConfig -Name "DEMO-01" -InstanceSize ExtraSmall -ImageName (Get-AzureVMImage)[3].ImageName `

   3:                | Add-AzureProvisioningConfig –Windows –Password "P@ssw0rd" `

   4:                | New-AzureVM –ServiceName "DEMO-01" -Location "West Europe" -VNetName "Azure Vnet 01" -AffinityGroup 1

   5:   

   6:  # Start the new virtual machine

   7:  Get-AzureVM "DEMO-01" | Start-AzureVM

   8:   

   9:  # Connect to the new virtual machine using Remote Desktop

  10:  Get-AzureRemoteDesktopFile -ServiceName "DEMO-01" -Name "DEMO-01" –Launch

  11:   

  12:  # Save your virtual network configuration to an XML-file

  13:  Get-AzureVNetConfig | Select-Object -Expand XMLConfiguration | Out-File c:\temp\Azure-Vnet.xml

When you create a new virtual machine, by default an endpoint for Remote Desktop will be created. If you do not want this default endpoint to be created, you can specify the switch parameter –NoRDPEndpoint on the Add-AzureProvisioningConfig cmdlet.

You can also create your own endpoints, for example for PowerShell Remoting (TCP 5985):

   1:  # Add an endpoint for PowerShell Remoting (Windows Remote Management)

   2:  Get-AzureVM "DC-AZURE-01" | Add-AzureEndpoint -Name "WinRM" -PublicPort 5985 -LocalPort 5985 -Protocol tcp | Update-AzureVM

   3:   

   4:  # Add the hostname of the virtual machine to the local WSMan Trusted Hosts

   5:  Set-Item WSMan:\localhost\Client\TrustedHosts -Value "demo-01.cloudapp.net"

   6:   

   7:  # Connect to the virtual machine using PowerShell Remoting

   8:  Enter-PSSession -ComputerName demo-01.cloudapp.net -Credential (Get-Credential)

You can find more information on how to use the cmdlets on the  Use Windows Azure Cmdlets website.

I would also recommend you to download the Windows Azure Training Kit, which contains demos, labs and presentations. I would like to highlight the following presentations:

• WindowsAzureITProOverview.pptx
• WindowsAzureVirtualMachines.pptx
• ManagingVMs-PowerShell.pptx

There are also several PowerShell related labs in the training kit, for example Automating VM Management with PowerShell, and Deploying Active Directory with PowerShell.

Resources

Windows Azure Virtual Machines

Windows Azure PowerShell

Windows Azure Management Portal

Windows Azure Training Kit

Sign up for a Windows Azure 90 day free trial

Trivia: This WordPress blog is hosted on Windows Azure Web Sites.