PowerShell: Measuring Download Speeds

Have you ever downloaded a file from the Internet? Probably.

Have you ever downloaded a file with PowerShell? Maybe.

Have you ever wondered how fast your download was going? Sure.

Have you ever wondered how to get that information when you’re downloading a file with PowerShell? Maybe, but you didn’t have a solution until now!

Our web browsers calculate download speeds for us, somehow. Specifically how, I have no clue, but what I do know is that we are more than capable of calculating download speeds using PowerShell.
Continue reading

Introducing Microsoft’s OFFICIAL Windows Azure PowerShell Module!

Hello folks! Today, Microsoft has officially announced the availability of a new PowerShell module to help manage Windows Azure features! In order to obtain this module, you will need to download the Web Platform Installer 4.0 (x64, x86). Once you’ve installed the Web Platform Installer 4.0, you’ll need to search for “PowerShell” and install the “Windows Azure PowerShell” package from it.
Continue reading

PowerShell: Automate Windows Azure Service Bus queue creation

One of the core services provided by the Windows Azure “cloud computing” platform is the ability to create first-in, first-out messaging queues. These queues are considered to be part of the Service Bus feature in Windows Azure. In some cases, it may be desirable to automate the creation of these queues, especially if there are a lot of them to create. By automating this process, rather than performing it manually, you can ensure consistency, repeatability, and speed.

Starting out with Windows Azure automation might lead you to download the official Microsoft Windows Azure cmdlets, or even the third-party Cerebrata Windows Azure module for Windows PowerShell. The latter module appears to have cmdlets that support queue creation, however the former (Microsoft) module does not. If you’d rather not spend the money on the Cerebrata module, can’t get your company to buy it for you, or you’d rather just stick to native Microsoft stuff, you’re still in luck. The Windows Azure .NET SDK 1.6 allows C# developers, and PowerShell script writers, to create queues using the provided .NET types!
Continue reading

PowerShell: Get the Windows Azure Certificate

If you’re automating Windows Azure using Windows PowerShell, one of the first things you’ll probably notice is that you need a management certificate to connect to the Windows Azure subscription that you’re attempting to view or modify. Management certificates are associated to a Windows Azure subscription inside the Management Portal, under the Hosted Services, Storage Accounts & CDN –> Management Certificates section (see screenshot).

Windows Azure - Management CertificatesOnce you have associated a management certificate with a subscription, it needs to be imported into your local computer’s certificate store so that it can be used from PowerShell to manage the Azure subscription. To do this, follow these directions:

  1. Open MMC
  2. Add the certificates snap-in (for current user or local computer)
  3. Navigate to the Personal –> Certificates “folder”
  4. Right-click the Certificates node and select All Tasks –> Import
  5. Select the file on the filesystem that contains the certificate
  6. Select the Personal certificate store if necessary and finish the import wizard
Next, you’ll need to grab the certificate’s thumbprint, which is basically a unique identifier that differentiates it from other certificates. To grab this, follow these steps:
  1. Double-click the certificate in the Certificates MMC snap-in
  2. Visit the Details tab
  3. Scroll down to the Thumbprint field and copy the value into Metapad or equivalent

Now that you’ve taken down the thumbprint of the certificate, you can use PowerShell to retrieve the certificate from the current user’s certificate store. If the certificate resides in the local computer’s certificate store, you’ll have to replace “CurrentUser” with “LocalMachine.” To get the certificate, check out the code below.

1
2
$AzureCertThumbprint = '4DAE6C3F444F21972B0823467C229605';
$AzureCert = Get-Item -Path cert:\CurrentUser\My\$AzureCertThumbprint;

The $AzureCert variable now holds a reference to the management certificate, and you can now use this to manage your Windows Azure subscription!

Octopus: A .NET Release Management Tool

Introduction

imageTo give you a little background, I started a job back in mid-January which has taken me from doing Microsoft infrastructure engineering to doing more software development related work. I’ve never worked in a professional development environment before, and this job has been a real eye-opener for me in many different ways. I’m learning lots of new technology, and I’m learning a lot about how professional development teams work.

During the course of my learnings, I have been introduced to a very cool tool which helps with release management for ASP.NET applications (or probably any type of service-based application).

Octo-what?

It’s interesting how there’s all these funny names for software projects in development field. Sometimes the project’s name is entirely relevant, and other times, you had to wonder if someone went through a children’s picture book and plopped their finger down on a random page they opened to. Thankfully the author (Paul Stovell) of this project known as “Octopus” chose a name that is intricately tied to how the software works.

Octopus has a central server service (and website) which handles the configuration of the tool, and the deployment end-points are befittingly known as Octopus “tentacles.”

Environments, Projects, Tasks, oh my!

Octopus is a very simple tool to use, and doesn’t require a whole lot of configuration. Once the server is set up and configured, you can go ahead and start configuring your software releases in the [very clean] Octopus web interface.

Settings

Before you get too far in, you’ll need to set up a NuGet package URL in the Octopus Settings page. The NuGet package feed will be used later on to run software releases.

Environments

First off, you’ve got the ability to define multiple server “environments.” These environments allow you to specify one or more servers of one of three types:

  • Application
  • Web
  • Database

You’ll probably end up setting up environment names similar to other development teams:

  • Dev
  • Test
  • Staging
  • Preview
  • Production
  • etc.

image

You don’t have to install the Octopus tentacle on the servers before you add them to the environment configuration, but until you do, they’ll show up as offline tentacles. Octopus has a built-in health check task that will automatically check the health of the tentacle endpoints every five (5) minutes.

image

Projects

Once you’ve built out your deployment environments, you can begin building your projects. Projects are the applications that you want to deploy. Creating a new project is as simple as giving it a name and an optional description.

Deployment Steps

Each Octopus project consists of several “Deployment Steps” that are executed in sequence. Each step represents a NuGet package that is executed.

image

Release History

As you build our your projects and begin performing releases, you’ll get a Release History under each project’s details. It shows each build number and environment that was deployed to, and the date/time that the deployment occurred at.

image

Variables

You can define variables in your Octopus project, which will then be passed to the PowerShell pre-deploy, deploy, and post-deploy scripts. These scripts are discussed in more detail in the Octopus documentation.

image

 

Conclusion

This has been a very brief overview of the Octopus .NET Deployment tool. I hope you’ll take a look at the tool for yourself. In terms of creating a consistent, repeatable, automated software release process, you can’t go wrong with Octopus.

PowerShell: Finding Friday the 13th

Update (2012-01-13): Justin Dearing (aka @zippy1981) informed me that it would be more efficient to look at the 13th of each month, and test if it was a Friday. In theory at least, he’s absolutely correct; I wrote the function the first way I thought of it, and I always welcome suggested improvements.

This morning I noticed that it was Friday the 13th. No, I didn’t realize it by looking at the Windows 7 system clock. I realized it because I had the worst morning waking up for the past month. I started wondering when the next Friday the 13th would be, and how often they occurred. To satisfy my curiosity, I immediately thought to write a PowerShell advanced function to find them! This was also partially inspired by Jeff Hicks’ posting 13 PowerShell scriptblocks for Friday the 13th.

There are two parameters to this function:

  • StartDate (default to "today")
  • EndDate (default to "today" +1460 days, which is roughly 4 years in the future)

You can call this function using neither parameter, one of them, or both of them. Both parameters are [System.DateTime] structs, and PowerShell will automatically try to parse any string value passed into them. Here is an example:

Find-Friday13th -StartDate 2000-01-01 -EndDate 2005-01-01

And here is the function!

<#
    .Synopsis
    This function finds Friday the 13ths.

    .Parameter StartDate
    The date you want to begin searching for Friday the 13ths.
    .Parameter EndDate
    The end date you want to search for Friday the 13ths.

    .Outputs
    [System.DateTime] objects that represent Friday the 13ths.

    .Notes
    Written by Trevor Sullivan (pcgeek86@gmail.com) on Friday, January 13, 2012.
#>
function Find-Friday13th {
    [CmdletBinding()]
    param (
        [DateTime] $EndDate = ((Get-Date) + ([TimeSpan]::FromDays(1460)))
        , [DateTime] $StartDate = (Get-Date)
    )

    # Inform user that the $EndDate parameter value must be greater than the $StartDate parameter value
    if ($EndDate -lt $StartDate) {
        Write-Error -Message 'The EndDate must be greater than the StartDate!';
        return;
    }

    # Get the next Friday after $StartDate
    while ($StartDate.DayOfWeek -ne 'Friday') {
        Write-Host "Finding next Friday";
        $StartDate = $StartDate.Add([TimeSpan]::FromDays(1));
    }

    # While $StartDate is less than $EndDate, add 7 days
    while ($StartDate -lt $EndDate) {
        # If the Day # is 13, then write the [DateTime] object to the pipeline
        if ($StartDate.Day -eq 13) {
            Write-Output -InputObject $StartDate;
        }
        # Add 7 days to $StartDate (next Friday after current)
        $StartDate = $StartDate.Add([TimeSpan]::FromDays(7));
    }
}

# Call the function
Find-Friday13th -EndDate 2017-12-31

 

Here’s what the function’s output looks like. The objects returned to the pipeline are all [System.DateTime] objects, which are automatically being ToString()’d.

image

PowerShell: List Strongly Typed Names in Global Assembly Cache

I dislike using deprecated commands or APIs when I know that there’s a more modern method of performing an action. I also generally prefer to use Windows PowerShell as a .NET scripting language, rather than constantly relying on cmdlets. To be sure, I use a balance of both concepts, since cmdlets can save a whole lot of coding a lot of the time.

Every time I want to load an assembly into PowerShell, the first thing that pops into my mind is using the LoadWithPartialName() method:

1
[Reflection.Assembly]::LoadWithPartialName();

Unfortunately Microsoft recommends against using that static method, as it is deprecated, and recommends use of other methods such as LoadFile() or Load() like:

1
[Reflection.Assembly]::Load(StronglyTypedAssemblyName);

In the interest of not breaking my conscience, I would like to use this method, but the problem then becomes that I have to constantly figure out what the strongly-typed name of the assembly I want is. To help solve this problem, I decided to write a PowerShell script that extracts information from the .NET assemblies in the Global Assembly Cache (GAC), since those are generally the most common ones I’ll need to reference.

Continue reading

PowerShell 3.0: List of Windows 8 Cmdlets & Modules

Here is a list of modules available in the new Windows Server 8:

Name
—-
ADDeploymentWF
AppLocker
Appx
BestPractices
BitsTransfer
BranchCache
CimCmdlets
ClusterAwareUpdating
DirectAccessClientComponents
Dism
DnsClient
DnsConfig
DnsLookup
DnsNrpt
FailoverClusters

 

Continue reading

Extreme PowerShell / ConfigMgr: Extending Hardware Inventory

Introduction

In previous versions of Microsoft System Center Configuration Manager (ConfigMgr / SCCM), a common task for administrators, engineers, and consultants, was to extend the hardware inventory configuration. These inventory extensions were written in Managed Object Format (MOF) and allowed the SCCM client agents to report back a wider array of information to the central site database for reporting purposes, collection building, and other management tasks. Making changes to the configuration could be a tedious task, as MOF is not very forgiving, and rather quite strict, in its syntax.

In Microsoft Systems Management Server 2003 (SMS 2003), each time a configuration change was made, it was necessary to deploy the updated MOF file to the SMS clients — this made ensuring hardware inventory consistency across all clients a challenging task. In SCCM, Microsoft included changes to these MOF files (SMS_DEF.mof and Configuration.mof) as part of the machine policy refresh task, which is a client-side polling mechanism for configuration changes.

In SCCM 2012 Beta 2, Microsoft is taking it a step further and has eliminated the SMS_DEF.mof altogether, left the configuration.mof behind by itself, and stuck the WMI inventory configuration in … WMI. What is WMI? WMI stands for Windows Management Instrumentation, a service built into the Windows Operating System since Windows XP (and Windows 2000 Service Pack 4, I think). It provides a standard method of exposing hardware and software level system information to applications, such as storage, processor, memory, running processes, installed software, and other application configuration data. SCCM is built on top of this technology, and often makes developing software and scripts around the product much easier than it otherwise might be.

For the remainder of this article, we’re going to look at specifically how to extend hardware inventory in SCCM 2012 programmatically using Windows PowerShell with the SCCM WMI provider.

Continue reading

Removing Permanent WMI Event Registrations

Introduction

Since I’ve worked on the PowerEvents PowerShell module, several folks have been confused about how to remove event registrations once they’ve been created. I wrote some documentation that’s included in the download, that explains how to manually remove these registrations using the built-in wbemtest tool. This is the fool-proof method, since wbemtest is included in every Windows installation.

In the interest of making things easier, however, I wrote a WinForms utility in C# a little while back. This utility simply enumerates the various permanent event objects in the WMI repository (filters, consumers, and bindings), and allows you to remove them. That’s all it does :)

In the remainder of this blog post, I’ll talk about the manual method of removing event objects, and show you the utility I just mentioned.

The Manual Method

While experimenting with the PowerEvents module, you might accumulate many WMI event filter and consumer objects. At some point, you’ll probably want to clear those out. As of this writing, the PowerEvents module needs further work on the Get-* and Remove-* advanced functions. Until this functionality can be implemented, use the following procedure to remove the filter/consumer bindings.

Here are the individual steps to remove an unwanted event binding:

  1. Open wbemtest as an administrator
  2. Click Connect
  3. In the Namespace field, type rootsubscription
  4. Click Connect or press {ENTER}
  5. Click Enum Instances
  6. Type __FilterToConsumerBinding in the text box
  7. Click OK or press {ENTER}
  8. Click the binding instance you want to remove
  9. Click the Delete button

Upon removal of the __FilterToConsumerBinding instance, the consumer will no longer respond to events. This process can be repeated to remove filters and consumers. Rather than enumerating instances of __FilterToConsumerBinding however, you would use “__EventFilter” or any of the five consumer class names.

The WMI Event Helper Utility

The utility I wrote a little while back is intended to display all filters, consumers, and event bindings to you, so that you can remove them from a friendly GUI. Although it works quite well in my personal testing, the tool has one important limitation, albeit it probably won’t affect most people.

The Limitation

In its current form, it does not allow you to specify a WMI namespace where the event objects reside. As I said, most folks should be OK, but you should be aware that you can create WMI filter objects in ANY WMI namespace, not just rootsubscription (the default). The out-of-box consumer instances can be created in either rootdefault or rootsubscription (latter is default). Finally, event bindings can be created in ANY WMI namespace.

Unless you’re explicitly specifying an alternate WMI namespace when creating the various WMI event objects, you won’t be affected by this. Just be aware that, if you’re a power user, you might want to make sure you don’t have event objects in other namespaces.

The Tool

Here’s what the tool looks like:

image

As you can see, it lists filters, consumers, and bindings in the rootsubscription namespace. You might notice that above the consumer list, there’s a “Consumer Type” combo box. By clicking the arrow, or scrolling through the list using your mouse scroll wheel (the control must have focus), you can select the Consumer Class that you want to enumerate instances of.

Simply click on the item you want to delete, and select the appropriate “Remove” button. That’s all there is to it!

You can download the WMI Event Helper utility on the PowerEvents project page.

Conclusion

This blog post has covered the removal of WMI permanent event objects both manually, and using a C# event management utility. For more information, please review the comprehensive documentation included in the PowerEvents module release download.