System Centre Virtual Machine Manager Error 11822

This error appeared this morning:

Error (11822)
Management pack Microsoft.SystemCenter.VirtualMachineManager.2012.Discovery version 3.2.8145.0 is incompatible with this version of Virtual Machine Manager

Recommended Action
Use Repair-SCOpsMgrConnection cmdlet to import version 3.2.8169.0 of the Microsoft.SystemCenter.VirtualMachineManager.2012.Discovery management pack onto your Operations Manager server, and then retry the operation

For some reason using Repair-SCOpsMgrConnection did not resolve the issue, suspect it to be some corporate firewall being a pita. To resolve I copied the management packs from C:\Program Files\Microsoft System Center 2012 R2\Virtual Machine Manager\ManagementPacks and import them using the MP import method of choice. Once that has completed on the VMM console goto Settings -> System Center Settings -> Operations Manager Server and click on the Refresh button. You can monitor progress in the Jobs window.

Looking further I have also seen that this has been happening for awhile with the error below.

Management pack Microsoft.SystemCenter.VirtualMachineManager.2012.Discovery version 3.2.8145.0 is incompatible with this version of Virtual Machine Manager

Not sure why no OM alerts where generated

Quickly convert from VMDK to VHD

You will need two tools for this, a decent unzipping tool like 7Zip if you have the OVA and Microsoft Virtual Machine Converter

If you downloaded an OVA file decompress this with 7Zip

7z.exe e D:\temp\ucspe.ova -oD:\Temp\UCSPE

After this you should have at least three files

filename.mf
filename.ovf
filename.vmdk

Some OVA’s will contain multiple VMDK’s.

One you have these files open and admin powershell prompt

Import-Module ‘C:\Program Files\Microsoft Virtual Machine Converter\MvmcCmdlet.psd1’

ConvertTo-MvmcVirtualHardDisk -Verbose -SourceLiteralPath D:\temp\UCSPE_2.5.2a\UCSPE_2.5.2a-disk1.vmdk -DestinationLiteralPath D:\Path\To\HyperV\ -VhdType Dyna
micHardDisk -VhdFormat Vhdx

Once you have the disks create the VM as you normally would in HyperV and attach the converted disk, code snippet I use is below

$vmGeneration = “1” #Gen 2 for UEFI
$vmName = “Test”
$vmMemory = “2GB”
$vmDiskPath = D:\HyperV\Disks\UCSPE\UCSPE_2.5.2a-disk1.vhdx”
$switchName = “Ethernet”
New-VM -Name $vmName -VHDPath $vmDiskPath -MemoryStartupBytes $vmMemory -SwitchName $switchName -Generation $vmGeneration
Add-VMNetworkAdapter -VMName $vmName -SwitchName $switchName
Add-VMNetworkAdapter -VMName $vmName -SwitchName $switchName

Download Windows PowerShell 4.0 and Other Quick Reference Guides from Official Microsoft Download Center

Some useful cheat sheets thanks to Microsoft

Quickly learn tips, shortcuts, and common operations in Windows Powershell 4.0, Windows PowerShell Desired State Configuration, Windows PowerShell Workflow, Windows PowerShell ISE, Windows PowerShell Web Access, Server Manager for Windows Server 2012 R2, WinRM, WMI, and WS-Man

via Download Windows PowerShell 4.0 and Other Quick Reference Guides from Official Microsoft Download Center.

Getting ADFS 3.0 with WAP to actually work in my environment

Setting this up has been “fun”. For whatever reason we have been having all sorts of weird errors. Hope something here helps someone else out there.

Basically the design is as such: ADFS Design Connecting to the ADFS servers from the internal networking worked as expected using the https://sts.contoso/adfs/ls/idpinitiatedsignon URL.

First we where getting certificate issues when accessing https://sts.contoso/adfs/ls/idpinitiatedsignon from a machine with a hacked together hosts files pointing to either of the two proxies. On this TechNet Post I noticed a mention by someone asking if the certificates on the WAP and ADFS server where verified and that the certificate paths where okay. We found that the path was not complete we and exported the certificate again from a working source and imported again. That problem cleared.

While we had been waiting for the F5’s to be configured we setup the proxies with DNS pointing to only one of the ADFS servers (ADFS-01), and everything was working. Once the F5’s where done DNS was changed to the F5 IP which is when we started having the proxy connections break. After inspecting the logs we noticed that we where getting trust failures with the self-signed certificates that get created when you join the WAP to the ADFS servers. Reconfiguring the proxies did not help. After approaching the F5 admin we realised that the F5’s are configured by default to MiM the SSL connections. Once the internal F5 cluster was reconfigured to pass the certificate on that problem disappeared.

Currently working at getting the access from inet.0 to the proxies configured via our external F5’s, will update post with information there. This seems to be an issue with SNI and the F5’s. I found two possible fixes, F5 Dev Central has a write up on ADFS SNI and F5’s. Another possible is to run
netsh http add sslcert ipport=IPAddress:443 certhash=certificatethumbprint certstorename=MY sslctlstorename=AdfsTrustedDevices appid={5d89a20c-beab-4389-9447-324788eb944a}
on each of the proxies. We have tested this and it worked, but it is not exactly elegant. One of the good examples of documentation being important.

Something I have noticed that is really annoying and is going to be a maintenance nightmare is the fact that the proxy trust certificates expire after 20 days but now there are 30 odd device certificates in the ADFSTrustedDevices store. Apparently there is a hot fix on the way.

Useful Tips:

  • How to reconfigure the ADFS WAP
    Change the registry key at HKLMSoftwareMicrosoftADFSproxyConfigurationStatus from 2 to 1, and then run ramgmtui.exe, clicking on Web Application Proxy
  • Use
    https://sts.contoso.com/federationmetadata/2007-06/federationmetadata.xml and
    https://sts.contoso.com/adfs/ls/idpinitiatedsignon
    to test ADFS
  • To test if your SSL Certificate is binding correctly netsh http show sslcert
    Hostname:port : adfs.contoso.com:443
    Certificate Hash : bdaa3368d535b0612055ee8b0494423829f585cf
    Application ID : {5d89a20c-beab-4389-9447-324788eb944a} <- this is the ADFS SSL Owner GUID so we know this mapping was created by ADFS
    Certificate Store Name : MY
    Verify Client Certificate Revocation : Enabled
    Verify Revocation Using Cached Client Certificate Only : Disabled
    Usage Check : Enabled
    Revocation Freshness Time : 0
    URL Retrieval Timeout : 0
    Ctl Identifier : (null)
    Ctl Store Name : AdfsTrustedDevices <- this is the important part to watch out for
    DS Mapper Usage : Disabled
    Negotiate Client Certificate : Disabled

 


References:


Shout out to Gavin van Niekerk from Microsoft SA

Problems encountered setting up SCOM 2007 R2 in a lab

While setting up a SCOM 2007 deployment to do some testing from 2007 to 2012 I came across some annoying as F issues, this is what I did to clear the logs. If more pop up I shall append to this post.

The first hurdle with installing SCOM 2007 I came across was the default database not installing. The workaround is in the toolkit on the install disk/iso under SupportToolsAMD64DBCreateWizard.exe . This will walk you through setup of the Database. Once that is done rerun the installation tool and you should be good to go.

The next bump in the road was what looked to be a common issue where you get a periodic event in the Operation Manger event log with ID 11464, even after I thought I had created the SCOM AD SCP correctly. For some reason the SDKServiceSCP was not being created. Creating that manually using ADSIEdit solved that WTF.

For some reason the permissions on the OperationsManager container where also screwed up, adding the SCOMAdmin group resolved that tidily.

Of course I had to remember to restart the HealthService (net stop HealthService && net start HealthService) each time otherwise you will wait around an hour to see if the error has been eradicated.

Customising actions on USB using USBDLM

There are many problems with USB in Windows. One being that every time you insert a drive it can have almost any drive letter, another running something automatically from the drive. Will discuss the second first:

Microsoft had Autorun for many years, since Windows 95, but they have had to nerf the hell out of it to stop the prevalence of virus’s and Trojan’s propagating using sneaker-net. A clever chap by the name of Uwe Sieber (http://www.uwe-sieber.de) has come to the rescue with USBDLM (USB Drive Letter Manager).

USBDLM is a Windows service that gives control over Windows’ drive letter assignment for USB drives. Running as service makes it independent of the logged on user’s privileges, so there is no need to give the users the privilege to change drive letters.
It automatically solves conflicts between USB drives and network or subst drives of the currently logged on user.
Furthermore you can define new default letters for USB drives and much more.

On my flash drive I have a TrueCrypt install with a 4GB container for my documents and wanted it to mount automagically whenever that drive is inserted into one of my computers. One of the features of USBDLM is to execute a command when a specific device is attached.

First things first, go fetch USBDLM ZIP file from http://www.uwe-sieber.de/usbdlm_e.html and unzip to a folder. I recommend using C:Tools for this sort of stuff, makes backups easier. Once unzipped run the _install.cmd file as Administrator, if you are not logged on as an Administrator use the RunAs Administrator option in the context menu. To get started rename the USBDLM_sample.INI to USBDLM.INI, this file is read every time a device is inserted so no need to restart the service while testing.

To have the “Autorun” mount a TrueCrypt you will need a section like this one

[OnArrival20]
DeviceID1=USBVID_125F&PID_312A9021000000000003637772282
FileExists=%drive%MyTrueCryptFile.TC
open=”%drive%TrueCryptTrueCrypt.exe” /q /v %drive%MyTrueCryptFile.TC /letter N

To open an item on the drive you need to create an [OnArrival] section.
The DeviceID can be determined using the included ListUsbDrives_To_Notepad.cmd which will open a text file through which you can find the USB DevID for the USB device your Truecrypt file is on.
The FileExists portion is optional, use this to first check the file is actually on the device. The %drive% is a placeholder for whatever drive letter the USB device is mounted as.
The open portion is where you will put the command line to open whatever you want, here it is a TrueCrypt file.

Once my TrueCrypt container is mounted another OnArrival section opens my KeePass database. A really useful feature when you have applications automatically running is the OnRemovalRequest section which can then run the commands to un-mount the TrueCrypt volume after closing my KeePass database.

Another very useful feature of USBDLM is the initial purpose behind the service, the ability to enforce the assignment of USB drives to specific drive letters. This is done thusly

[DriveLetters]
Letters=F,G,H,I,-

[DriveLetters10]
DeviceID1=USBVID_125F&PID_312A9021000000000003637772282
Letters=A

This is far simpler, [DriverLetters] defines what letters are available to be assigned to USB drives.

[DriveLetters10] is a bit more complex, a very small bit. Using this example it will assign the drive letter A whenever the device with DeviceIS1 is attached.

There are lots of additional things you can do, all well documented in the help file included with the download.