Summary: Microsoft Windows PowerShell MVP, Richard Siddaway, talks about using Windows PowerShell and WMI to work with operating system licensing.
Microsoft Scripting Guy, Ed Wilson, is here. This week we will not have our usual PowerTip. Instead we have excerpts from seven books from Manning Press. In addition, each blog will have a special code for 50% off the book being excerpted that day. Remember that the code is valid only for the day the excerpt is posted. The coupon code is also valid for a second book from the Manning collection.
This excerpt is from PowerShell and WMI
By Richard Siddaway
Product activation for Windows servers may seem to be a pain, but it’s a fact of life. You have to do it for two reasons:
- To ensure the software is properly licensed and you remain legal
- To keep the servers working
In this blog, which is based on Chapter 13 of PowerShell and WMI, I will explain how to test license state and set the license key. How can you ensure software is properly licensed in the most efficient manner? My friend James O’Neill answered this in a blog post. In it, he references two WMI classes:
- SoftwareLicensingProduct
- SoftwareLicensingService
Note These classes are new in Windows 7 and Windows Server 2008 R2. They’re not available on earlier versions of Windows.
These tips are derived from James’ post. You can test the license status of Windows like this:
Get-WmiObject SoftwareLicensingProduct |
select Name, LicenseStatus
LicenseStatus will return an integer value, where 0 = Unlicensed and 1 = Licensed. A number of results that represent the various ways Windows can be licensed or activated are returned. The important result is the one with a partial product key:
Get-WmiObject SoftwareLicensingProduct |
where {$_.PartialProductKey} |
ft Name, ApplicationId, LicenseStatus –a
This indicates the licensing situation you’re dealing with. It would be nice, though, if you could get a little bit more information about the licensing state of your system.
Testing license state
Has your IT environment ever been audited? Can you prove that all of your servers are properly activated? This section will help you answer the second question. In addition to being a useful test while you’re building a new server, you can use it to test the setup of your whole estate.
Problem
You need to test the activation and license state of your servers for auditing purposes. Some of the servers are in remote locations and you don’t have the time or resources to physically visit them all.
Solution
You’ve seen that the license status information is available through the SoftwareLicensingProduct class. The following listing shows how you can use that class to generate a meaningful statement about the license status of your server.
Listing 1: Test license status
$lstat = DATA {
ConvertFrom-StringData -StringData @'
0 = Unlicensed
1 = Licensed
2 = OOB Grace
3 = OOT Grace
4 = Non-Genuine Grace
5 = Notification
6 = Extended Grace
'@
}
function get-licensestatus {
param (
[parameter(ValueFromPipeline=$true,
ValueFromPipelineByPropertyName=$true)]
[string]$computername="$env:COMPUTERNAME"
)
PROCESS {
Get-WmiObject SoftwareLicensingProduct -ComputerName $computername |
where {$_.PartialProductKey} |
select Name, ApplicationId,
@{N="LicenseStatus"; E={$lstat["$($_.LicenseStatus)"]} }
}}
A hash table, $lstat, is defined at the beginning of the script. You can then call the SoftwareLicensingProduct class against the computer, passed as a parameter to the function. The results are filtered on the PartialproductKey property to ensure you only get the results you need. There are three pieces of data you need:
- The name of the product
- The ApplicationId, which is a GUID
- The decoded license status
The decoding of the license status is managed by the calculated field in the Select-Object statement.
Discussion
The following image shows the results of running the function. The ApplicationId is fixed for versions of Windows. You should get the same result returned on all versions.
The results in the previous image show that you’re still in the grace period after installation of the operating system. You need to set the license key before you can activate the server.
Setting the license key
A Windows license key consists of five groups of five alphanumeric characters. A valid license key is required for each instance of Windows. The key is usually found with the media. Keys are specific to the version of Windows and the source of the media. For instance, you can’t use an MSDN key on a commercial version of Windows.
Problem
The license key needs to be set before you can activate the system. You need to perform this act remotely and ensure that the license key is in the correct format.
Solution
Windows 7 and Windows Server 2008 R2 have a WMI class, SoftwareLicensingService, which you can use to solve this issue. This is shown in the following listing. The license key and computer name are mandatory parameters. This removes the need for default values. The license key pattern is evaluated by using a regular expression and the ValidatePatternmethod. This won’t guarantee that the key is correct, but it will ensure that it’s in the right format.
Listing 2: Set license key
function set-licensekey {
param (
[parameter(Mandatory=$true)]
[string]
[ValidatePattern("^\S{5}-\S{5}-\S{5}-\S{5}-\S{5}")]
$Productkey,
[parameter(Mandatory=$true)]
[string]$computername="$env:COMPUTERNAME"
)
$product = Get-WmiObject -Class SoftwareLicensingService `
-computername $computername
$product.InstallProductKey($ProductKey)
$product.RefreshLicenseStatus()
}
You use the SoftwareLicensingService class to create a WMI object. You can use the InstallProductKey method with the license key as an argument. The last line of the function refreshes the license status information.
Discussion
The function is used as follows:
set-licensekey -Productkey "XXXXX-XXXXX-XXXXX-XXXXX-XXXXX" `
-computername "10.10.54.118"
The "XXXXX-XXXXX-XXXXX-XXXXX-XXXXX" represents the license key. You didn’t really think I’d use my real key? The computer on which you’re installing the key can be designated by IP address as here or by its name.
Configuring a new server is a task that occurs on a regular basis in most organizations. There are a number of steps to be completed after the operating system is installed:
- Rename the server to something more meaningful.
- Stop and restart the server as required.
- Set the IP address and DNS servers.
- Rename the network connection.
- Join the server to the domain.
- Install the license key.
- Activate the server.
- Set the power plan.
All of these activities take time. You can use Windows PowerShell functions to perform these tasks remotely so you don’t need to spend time accessing the server directly.
~Richard
Here is the code for the discount offer today at www.manning.com: scriptw6
Valid for 50% off PowerShell and WMI and SharePoint 2010 Workflows in Action
Offer valid from April 6, 2013 12:01 AM until April 7, midnight (EST)
I invite you to follow me on Twitter and Facebook. If you have any questions, send email to me at scripter@microsoft.com, or post your questions on the Official Scripting Guys Forum. See you tomorrow. Until then, peace.
Ed Wilson, Microsoft Scripting Guy