Key Value Pair Exchange WMI Component Property GuestIntrinsicExchangeItems & Assumptions

Now that Windows 2008 R2 SP1 is being deployed some scripts to check whether the Integration Components (IC) in Hyper-V VM guests are upgraded came back on the radar screen. Host are being upgraded and thus the clients need upgraded IC as well. Now to check this for hundreds or thousands of guest we need some automation. PowerShell comes in handy for this and some neat scripts can be found around the internet. The most concise PowerShell code to do this, that I know of, is the one Peter Noorderijk (great Dutch IT Pro)  uses in his  PowerShell function Get-IntegrationServicesVersion on his blog How to check the version of the Integration Components.  As he provided this script just when I needed one I used it. This worked fine until I ran into an issue with it on some clusters. On two test clusters and two production clusters, it did the job as expected. On one test cluster and one production cluster, we ran into the situation where the output seemed wrong. The screenshot below is an example of this.

The red arrows indicate wrong data for the VMname and ICVersion. What happened here?  Well, when we read out the  GuestIntrinsicExchangeItems property from the WMI object Msvm_KvpExchangeComponent we get back XML. That XML needs to be parsed to display it for human consumption. The function depends on fixed positions containing the correct data. I’ve marked the relevant portions with a red arrow above, they come from$vmkvp[0] en $vmkvp[14] in the script below.

function Get-Integ.rationServicesVersion ($HVhost = $(throw “HVHost required”))
    {
    $kvps = Get-WmiObject -Namespace rootvirtualization -ComputerName $HVHost -Query “Select GuestIntrinsicExchangeItems From Msvm_KvpExchangeComponent”
        foreach ($kvp in $kvps)
         {
         $vmkvp = $Kvp.GuestIntrinsicExchangeItems
         $vmkvp | select-object @{Label=”VMHost”;Expression={$hvhost}},
                                @{Label=”VMName”;Expression={($vmkvp[0]).instance.property[1].value}},        
                                @{Label=”ICVersion”;Expression={($vmkvp[14]).instance.property[1].value}} -first 1
         }    
    }
  
foreach ($hvhost in get-content servers.txt) {Get-IntegrationServicesVersion $hvhost}

And indeed, when we dump the XML for two of the affected servers out to text files you can see the order is indeed different so counting on the exact location in an array is what tripped us up here.

Should this ever happen? Am I making a scripting mistake somewhere? Running a check with a VBScript that parses the XML  using XDOM (just in case my PowerShell skills are the cause of this) confirms the order is different but that the key pairs match up and are correct

D:SysAdminPowerShellScripts>cscript.exe test.vbs

Microsoft (R) Windows Script Host Version 5.8

Copyright (C) Microsoft Corporation. All rights reserved.

Guest OS information for server01

CSDVersion : Service Pack 1

FullyQualifiedDomainName : server01.lab.test

IntegrationServicesVersion : 6.1.7601.17514

NetworkAddressIPv4 : 10.10.100.118

NetworkAddressIPv6 : fe80::a177:729:8840:250%9

OSBuildNumber : 7601

OSEditionId : 7

OSMajorVersion : 6

OSMinorVersion : 1

OSName : Windows Server 2008 R2 Standard

OSPlatformId : 2

OSVersion : 6.1.7601

ProcessorArchitecture : 9

ProductType : 3

RDPAddressIPv4 : 10.10.100.118

RDPAddressIPv6 : fe80::a177:729:8840:250%9

ServicePackMajor : 1

ServicePackMinor : 0

SuiteMask : 272

D:SysAdminPowerShellScripts>cscript.exe test.vbs

Microsoft (R) Windows Script Host Version 5.8

Copyright (C) Microsoft Corporation. All rights reserved.

Guest OS information for server13

FullyQualifiedDomainName : server13.lab.test

OSName : Windows Server 2008 R2 Standard

OSVersion : 6.1.7601

CSDVersion : Service Pack 1

OSMajorVersion : 6

OSMinorVersion : 1

OSBuildNumber : 7601

OSPlatformId : 2

ServicePackMajor : 1

ServicePackMinor : 0

SuiteMask : 272

ProductType : 3

OSEditionId : 7

ProcessorArchitecture : 9

IntegrationServicesVersion : 6.1.7601.17514

NetworkAddressIPv4 : 10.10.100.112

NetworkAddressIPv6 : fe80::c18b:e3f2:7f05:31e4%12

RDPAddressIPv4 : 10.10.100.112

RDPAddressIPv6 : fe80::c18b:e3f2:7f05:31e4%12

When I look at where that data lives in the registry on those servers it all looks exactly the same, neatly ordered buy the RegEdit GUI:

So when getting that data from the Key-Value Pair Exchange WMI component with the property GuestIntrinsicExchangeItems you get a bunch of XML. That has to be parsed to be displayed in a readable fashion. The problem we are seeing is due to the fact that the items in the XML file are not in the same order. Peter’s function assumes it is. However this does not happen to be the case for most virtual machines, the majority is in the expected order. I don’t know why that is or if this is supposed to happen but it doesn’t seem to cause any harm. All is fully functional and operational in Hyper-V Manager, SCVMM 2008R2 … etc. Perhaps an MVP or Microsoft guru can shed some light on this. It seems like a bug waiting to happen if a developer of Hyper-V management software makes the same assumption. Of is this never suppose to happen and do I need to worry? I don’t know Smile I reinstalled the IC on the guests that have a different ordering and live migrated them, but that didn’t change anything

Anyway if you want to make sure you get the correct output we’ll need another approach that doesn’t make assumptions. You can roll your own and get the output customized to your needs but you need to parse the XML using a filter.  An example of this is listed below.

# Filter for parsing XML data
filter Import-CimXml 
{    
# Create new XML object from input  
$CimXml = [Xml]$_    
$CimObj = New-Object -TypeName System.Object     

# Iterate over the data and pull out just the value name and data for each entry   
foreach ($CimProperty in $CimXml.SelectNodes("/INSTANCE/PROPERTY[@NAME='Name']"))      
 {          
     $CimObj | Add-Member -MemberType NoteProperty -Name $CimProperty.NAME -Value $CimProperty.VALUE       
 }  
    
 foreach ($CimProperty in $CimXml.SelectNodes("/INSTANCE/PROPERTY[@NAME='Data']"))     
   
 {         
     $CimObj | Add-Member -MemberType NoteProperty -Name $CimProperty.NAME -Value $CimProperty.VALUE      
 }    


# you send the output from the property to the filter via a pipe
$KvpComponentVMGuest.GuestIntrinsicExchangeItems $vmkvp |Import-CimXml 

Maarten Wijsman (a fellow blogger at http://www.hyper-v.nu like Peter)  has a nice example script here that also uses a filter Import-CimXML. Do note that there are variants on this filter depending on what output you desire that explains the difference between the filters.

Hyper-V Dynamic Memory does not work on a Windows Server 2008 Standard Edition or Windows Web Server 2008 virtual machine (VM)

Here’s a pointer to a Microsoft Knowledge base article on Hyper-v Dynamic Memory not working on Windows 2008 Standard & Web edition Hotfix: Hyper-V Dynamic Memory does not work on a Windows Server 2008 Standard Edition or Windows Web Server 2008 virtual machine (VM) As you probably already know you have a similar issue with Window 2008 R2 Standard and Web edition virtual machines which is fixed by installing SP1 in the guest. For the predecessor of R2 you need to install this hotfix.

The cause is that on these versions of the operating systems the the required memory enlightenment is supported. After installing the hotfix (or SP1 in the case of Windows 2008 R2) memory addition enlightenment is available on these SKU and your good to go.

Windows 2008 R2 SP1 Publicly Available & Update on Error 0x00f0818

Yesterday, late last night in Europe, Windows Server 2008 R2 SP1 became available to the general public. That means it will be pushed via Windows Updates or that you can download it manually here Windows 7 and Windows Server 2008 R2 Service Pack 1 (KB976932)

I’ve been busy doing deployments in the lab but also in production at several locations. The speed of a deployment depends on the host and what’s running on that host. I’ve seen anything between 22 minutes and 65 minutes. For a walk through of an install see my previous blog post on this Upgrading a Hyper-V R2 Cluster to Windows 2008 R2 SP1

I’ve also noticed an increased amount of hits for my blog on error 0x00f0818 when installing the Windows 2008 R2 SP1 Beta. The same solution holds true for RTM. More info on that is available at Windows 2008 R2 SP1 Beta Install Gone Wrong: Service Pack Installation failed with error code 0x800f0818

I had one place where dozens of VMs had this issue so in order to progress quickly we scripted the replacement of the C:WindowsservicingPackages folder content with know good files in bulk. Read the above mentioned article to learn about the security settings you’ll need to address in any automated solution (use takeown F c:WindowsServicingPackages /D y /R & cacls c:WindowsServicingPackages /E /T /C /G “UserName”:F  to take care of business). That saved us the time to check on each affected server individually what packages were involved. This works but test this before using it in production and don’t forget to return the security settings to the default when you’re done. In this case it was a rather large lab environment.

Hyper-V Component Architecture Poster Updated With Windows 2008 R2 SP1 Features

You probably are all familiar with the component posters that Microsoft put out for Several technologies. You have the Exchange 2010 (Exchange Server 2010 Architecture Poster), Windows 2008 R2 (Windows Server 2008 R2 Feature Components Poster) & Hyper-V (Hyper-V Component Architecture).

I have them hanging on the walls around our offices and these make a great tool to discuss the technology and where what is being done or accomplished. Or as a reference when you need to explain some features.  I suggest you download them and have them plotted in a print shop.

Microsoft recently put out a new version of the Hyper-V Component Architecture poster with the Windows 2008 R2 Service Pack 1 features (Windows Server 2008 R2 Hyper-V Component Architecture (with Service Pack 1)). It’s nice to see that they update these so quickly.  We’re plotting this on A0 as we speak.