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


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
    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



Shout out to Gavin van Niekerk from Microsoft SA