In short - you cannot use the Virtual Machine Converter tool to target Azure Resource Manager resource or CSP Subscriptions in general.
I was recently tasked with helping a customer run a proof of concept with a production application in Azure. The application itself contains 4 x servers and is “off the shelve” but has years of custom development on it. The project in itself was straightforward, “lift and shift” the 4 x VM’s to Azure and see if they run. I went through all the usual planning stages of using the MAP tool to get compatibility and VM’s sizes etc. My original plan was to use Azure Site Recovery to replicate the VM’s to Azure for testing, however, this was a short-lived idea as 2 out of the 4 VM’s were running unsupported versions of Windows. After this was communicated to the customer, they decided to continue with the project as it was only a proof of concept, they accepted the risk that 2 out of the 4 VM’s might never run in Azure.
Due to the number of non-documented changes to the “out of the box” application it was considered a worthy risk to try using the unsupported operating systems. I did have in my mind that we could do a dirty upgrade of the unsupported servers to bring them up to Server 2008 R2, but who likes doing that? The application is to be retired in due course but a number of things must be done ahead of GDPR, therefore we continued and hoped for the best.
This particular customer has chosen to procure their Azure services using the Cloud Service Provider (CSP) model, which is very common as we all know. As Azure Site Recovery was out of the question in this particular case my plan was to do an offline “cold” conversion of the VMware VM’s using the Virtual Machine Conversion tool, provided by Microsoft. Although this was possible in theory I hit a snag which I could not get around (easily). When you launch the Virtual Machine Conversion tool and select the “Migrate to Microsoft Azure” option, the first information it asks for is you Subscription ID and your Subscription Certificate Thumbprint. This was the problem, I could get the Subscription ID from the Azure Portal, no problem. It was when I tried to access the Managed Certificates associated with that CSP subscription. As you can see below, it states that I have Insufficient Permissions to view or manage and managed certificates. It also states that the Co-Administrator role is required to manage and certificates related to this subscription. If you are well versed in dealing with CSP (not me), you will know that the Co-Administrator role does not exist for CSP subscriptions.
I proved this theory by trying to grant Co-Administrator to myself, the option does not even appear like it does when you try on a different subscription type other than CSP. I did some research and came across this article
which states that managed certificates should be accessed through the ASM portal. As this is was January 2018, the old ASM portal had been decommissioned. It looked like I was trapped in a period where the Virtual Machine Conversion tool was not going to be suitable. I did consider doing the conversion and targeting at another subscription which was not CSP, but this was not very clean. It turns out the Virtual Machines Conversion tool was all still based on ASM, even if you get past the certificate validation it only displays Storage Accounts that are “classic”.
To get around this problem and move the VM's to Azure, I used the following steps.
- Disk2Vhd to export each of the VM's to VHD files.
- Booted the VHD files on a Hyper-V server to ensure they worked.
- Used Hyper-V to convert the VHD's from Dynamic to Fixed size (only fixed size supported in Azure).
- Azure Storage Explorer to move the VHD's into blob storage.
- Used the following ARM template to deploy VM from the VHD