Good news, today March 2nd, 2011 System Center Virtual Machine Manager 2008 R2 SP1 went RTM. I’ll update this short post with the download link when it becomes available ==> UPDATE: download it here from Microsoft (Evaluation) or from your TechNet subscription or licensing site. Seems like we got all host & guest updates to W2K8R2SP1 done exactly on time to get this one installed and have a state of the art, up to date infrastructure. Today the 2012 Beta version became available for download (here) and the documentation site went life (here). Things are moving in the system center space. Busy times ahead! Yet 2 more VMs to test with I the lab … and than Denali is coming.
Category Archives: Infrastructure
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={([xml]$vmkvp[0]).instance.property[1].value}}, @{Label=”ICVersion”;Expression={([xml]$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
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.
Exchange 2010 SP1 Rollup 3 Released: Fixes Bug since SP1 in EMC & Brings Back UDP Support
UPDATE March 9th 2011: I have installed Exchange 2010 SP1 Rollup 3 at one site and this did indeed fix this issue finally.
The Microsoft Exchange Team Blog just announced the release here Released: Update Rollup 3 for Exchange 2010 SP1 and Exchange 2007 SP3. This is good news for all the folks out there that got bitten by the Exchange 2010 SP1 bug that causes the Exchange Management Shell (EMC) not to show all database copies after upgrading to exchange 2010 SP1. I’ve blogged about this in EMC Does Not Show All Database Copies After Upgrade To Exchange 2010 SP1 and chimed in to the discussion at Database copies are not all showing up in EMC after SP1 upgrade on the Exchange forums. So apart from cheers for the UDP notifications returning in support of Outlook 2003 let’s hear it for a the EMC case sensitivity bug getting fixed ![]()
After while Microsoft also blogged about this Database copies fail to display after upgrading to Exchange 2010 Service Pack 1
We got notified around October 13th that they would included the fix in Exchange 2010 SP1 Roll Up 3 but that they where working on an interim update. They dropped the ball there because communication died about the latter and we were left to conclude we would have to wait for Rollup 3. Well that took it’s time. It’s now march 2011. One of the reasons I think it took so long for Rollup 3 to arrive is the decision for to re-add UDP support for Exchange 2010 for use with Outlook 2003 as blogged about in Microsoft Listens To Customers & Adds UDP Notification Support Back to Exchange 2010
In the ends we will have silly and long unaddressed bug fixed and a welcome aid in migrating customers to Exchange 2010 that are running Outlook 2003. I do wonder however if the bug had been with PowerShell in the EMS and not in the EMC if Microsoft would have fixed this sooner. Sure it wasn’t an issue as you could manage everything perfectly using PowerShell and it was only a GUI bug but for some users/customers this is not as obvious and it made ‘m feel a bit like 2nd class citizens so we had to do some extra “damage” control on that front as well.
Malta or the Microsoft BitLocker Administration and Monitoring (MBAM) Beta.
You have to hand it to Microsoft. At the moment a customer is contemplating buying MDOP they announce a sweet added benefit with that package, code named “Malta” or the Microsoft BitLocker Administration and Monitoring (MBAM) Beta. You can sign up for this via the connect page and the Béta is expected in March 2011, yes this month. Would be nice to see how it holds up in use.
According to the Connect site Malta is a BitLocker management solution that will enable IT to more easily deploy and manage BitLocker volume encryption technology across the enterprise. Using Malta:
- IT can automate the process of encrypting volumes on client machines across the enterprise
- Helpdesk can reduce the time required for BitLocker PIN and Recovery Key information
- Security officers can quickly produce reliable evidence that indicates the compliance state of individual computers or even the enterprise itself.
- Security Officers can easily audit access to Recover Key information.
- Windows Enterprise users are empowered to continue working anywhere knowing their corporate data is protected.
Look people even if you just a low profile outfit, don’t become road kill because some bad guys got to your data and published or sold it. Protect your assets and reputation. The technology to do this is available and it’s getting better and better. You do have to use it to be protected, so to paraphrase Nike, just do it. When your CFO forgets his laptop on the commute train he’ll thank you for it. More info on the Microsoft TechNet page Microsoft BitLocker Administration and Monitoring (MBAM)

