So if any of you actually gave my last post a shot, you might’ve found that one of the annoying parts about the Azure Visual Studio image is that it’s on Server 2012. The problem with that is, of course, you can’t dev for Windows 8 (8.1) from that OS using VS 2013. What a bummer. But what to do?
Put Windows 8 in the cloud, of course. How? Roll your own!
Ingredients:
- Convert-WindowsImage PowerShell script
- ISO of Windows 8 (or 8.1)
- Windows 8 (maybe 7 would work?) host OS
- Azure Subscription & account
- Azure PowerShell
- Visual Studio 2013 installation media
If you’ve ever created a bootable VHD, many of these steps might be familiar, in particular if you’ve done it via the “WIM2VHD” method, since that’s essentially what we’re going to be doing. The general approach goes something like this:
- Create bootable VHD of Windows 8/8.1
- Configure said VHD OS to allow remote access
- Sysprep the VHD
- Upload VHD to Azure
- Create Azure VM from VHD
- Profit
Let’s get started
1 – Create a bootable VHD of Windows 8/8.1
Fire up PowerShell (as Admin)
Then execute the script as shown:
PS S:\Brandon\Downloads> .\Convert-WindowsImage.ps1 –ShowUI
What can I say, I like UI configuration so much more than script/shell based. If you prefer the latter, you can read all the doco for Convert-WindowsImage here and roll your own installation that way.
You might be met w/ the following as a result of the above command:
.\Convert-WindowsImage.ps1 : File S:\Brandon\Downloads\Convert-WindowsImage.ps1 cannot be loaded because running
scripts is disabled on this system. For more information, see about_Execution_Policies at
http://go.microsoft.com/fwlink/?LinkID=135170.
At line:1 char:1
+ .\Convert-WindowsImage.ps1 -ShowUI
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : SecurityError: (:) [], PSSecurityException
+ FullyQualifiedErrorId : UnauthorizedAccess
Here’s how you fix that:
PS S:\Brandon\Downloads> set-executionpolicy unrestricted
Execution Policy Change
The execution policy helps protect you from scripts that you do not trust. Changing the execution policy might expose
you to the security risks described in the about_Execution_Policies help topic at
http://go.microsoft.com/fwlink/?LinkID=135170. Do you want to change the execution policy?
[Y] Yes [N] No [S] Suspend [?] Help (default is “Y”): y
now give the –ShowUI call another shot. You should be met with a nice window. Fill it out as shown:
The script reads the available SKUs from the media you have, so you might have other options than Professional or Core here, but I chose Pro. If you have the ISO for Windows 8/8.1, you can point the “source” to that and it will pull out the WIM file from inside it. Otherwise if you have the ISO already mounted, or burned to a disc, you can point right to \sources\install.wim and it’ll go from there.
You specify VHD (not VHDX) because Azure only (currently) supports VHD format. It doesn’t matter the size you pick here since it’s dynamic it doesn’t get made that size on disk anyway, so you’re not going to be burning any more upload time/usage if you increase the size – I’d recommend 64gb or better, though, since after all we are going to turn this in to a dev environment.
You’ll see the script go to work:
And you’ll also get an Explorer window popped up that has the VHD it’s creating mounted, so you’ll get to watch it place all the files in their spots (if you’re so inclined):
That’ll take a while depending on the speed of your media. Go grab a sammich & soda and meet me back here.
2 – Configure the VHD to allow remote access
This step is crucial. If you put your VHD up to Azure w/o doing this, then you can’t RDP in to it and you get to start all over w/ the upload process. So yeah, don’t skip it.
To boot the VHD, simply utilize Hyper-V (or another virtualization program like VirtualBox) to mount the VHD you’ve created. I’ll be demoing Hyper-V since it comes with Windows 8 Pro (and that’s what I’m running).
Fire up the Hyper-V manager
Create the new VM like so:
A couple of things to point out:
- Generation 1
- No network connectivity (so you don’t need an MS account to create the first user)
- Using the VHD file created in Step 1 as the VHD file for the VM
Fire up the VM now, you should see it go thru the typical Windows 8/8.1 startup sequence and then prompt you with the usual stuff you see when you get a new retail PC.
The one screen that’ll probably make you wonder for a split second is this one:
Click ‘Skip’ here. (You are going to be sysprepping the image before upload, which removes all activation anyway)
PC Machine name doesn’t matter, put whatever you want in there.
I elect to use “Express Settings” (since this is all just temporary anyway).
Since you don’t have a network connection to the VM, the first user you set up will be a “local account” – this is just fine for our purposes
Now you’ll see all that lovely setup stuff “Hi…We’re setting things up for you…”
We’re almost done with this part!
This is another reason that using a local account is a benefit here – you won’t be pulling all the apps already tied to your MS account down at this point, and you’ll keep the VM size to a minimum.
Sweet, we’re in
Now time to configure remote access:
Configure as shown:
That’s done.
Decision point
At this point you need to decide 1 of 2 things. Either install and set up your entire dev environment NOW (and pay the cost in upload time) or set it up AFTER you get it to Azure (and have to do it every time you spin up a VM based on this VHD). If you choose #1, go ahead and get all that done, then come back. If you choose #2, carry on.
3 – Sysprep the OS
This basically means to take it back to the way it was when you first booted up – no activation information, etc. The cool part is that it does NOT lose the remote setting, and does NOT lose the user that you just set up, so you can log in as this person once you get it out to Azure.
To sysprep the VHD, do the following in the VM:
Fire up the command prompt and type
c:\Windows\System32\Sysprep\sysprep.exe
Execute it as shown:
Once this completes, your VM will shut down and you’re on to step 4!
4 – Upload the VHD to Azure
Before we kick off the upload we have to prep our Azure storage. Log in to your Azure portal and head to the storage area.
If you don’t have a storage area, or want to set up a new one just for your VHDs, do so.
Once you’ve got your storage area, head to the ‘Containers’ area to create a new blob container for your VHDs (this is where they’ll end up after you upload them).
Copy the URL of the container and store it off somewhere, you’ll be using it in a minute.
Now fire up the Azure PowerShell (link in the ‘Ingredients’ area at the start of this post).
First we have to associate our Azure PowerShell session with our Azure account. To do this we download our subscription data and import it in to the PowerShell session.
In your PowerShell session, run:
Get-AzurePublishSettingsFile
This will open a browser and download a file to your computer that is your publish settings file. Take note of where you put this. After you have it, run:
Import-AzurePublishSettingsFile
Upon doing this it will report to you which Azure Subscription you’re talking to. If you want to switch the subscription, you execute the following:
Select-AzureSubscription ‘’
Set-AzureSubscription ‘’
You’re now ready to play w/ your Azure subscription. Namely, upload a VHD to it.
The scriptlet we’re going to be using is the add-azurevhd one and it goes a little something like this:
add-azurevhd –destination /.vhd –localfilepath
Here are the important parts:
- URL you copied – this is the URL to the blob container in your storage account that you copied just a moment ago
- Azure filename – this can be any filename you want. In my case I named it AzureDevMachineSysPreppedRemoteAccess so the full destination URL became http://________.blob.core.windows.net/vhds/AzureDevMachineSysPreppedRemoteAccess.vhd
- The .VHD on the end is EXTREMELY important. There is no *easy* way to rename blob objects in Azure, and without the .vhd on the end you cannot create a VM from the virtual disk. So DON’T for get it or you’ll be re-uploading (or using the Azure API to change the blob name, like I had to ;) )
- Path to local vhd – this is the full path to the VHD you created and sysprepped earlier. In my case: C:\VHDs\AzureDevMachine.vhd
Once you kick this off the script will do two things sequentially: 1) It’ll calculate an MD5 hash of the entire VHD (takes a while) and 2) It’ll start uploading the VHD to your Azure Storage container:
DSL connections really suck for uploading, btw.
Once that’s done, you’ll see your VHD in your Azure container!
ALMOST THERE
5 – Create the Azure VM from the VHD
Now the fun (and relatively quick) parts, letting Azure work its magic. Once your VHD is up on Azure, you just need to spin up some VMs based on it. This is EASY.
On your Azure Portal, go to the VM | Images area:
Click Create, and fill it out pointing it at your newly-uploaded VHD:
Clicking the folder icon takes you to another dialog where you pick the VHD:
Look familiar? Oh yeah.
Notice the checkbox at the bottom of the ‘Create’ dialog – that’s why we had to run Sysprep. You can’t create an image from the VHD in Azure if you haven’t done Sysprep on it.
Now that we have the Image created (to be honest I don’t know what the differences are between Images, Disks, and VHDs to Azure) we can spin up the VM based on that Image:
When configuring the new VM, remember that you already have an account on the VHD. So be careful not to use one of the same name. The one that Azure creates will be the “System Administrator”-level account, which I found afterward cannot be linked to a Microsoft Account. So what you specify here is mostly a throw-away account. But nonetheless don’t forget the username or password.
On this page, just put stuff in that makes sense. If you haven’t ever created a cloud service, then let it create one for you. Don’t create ____.cloudapp.net that is super-generic, make it relatively specific to you. Choose the reason that’s closest to you, and an availability set (if you have some set up).
I don’t usually change stuff here. If you have a *specific* port you want to use for RDP/PowerShell, this’d be the place to put it. AUTO means Azure will pick one, and let you know what it is when it’s done.
That’s it, here she goes!
Sit back and wait for the provisioning and boot up!
Once you get this, go ahead and click on the –> to get to the fun stuff
Notice the bottom row… “Connect”? Sweet!
Could this BE any easier?
The default login it shows here is that of the machine you’re coming from. Likely that’s not correct at all. So head to ‘User another account’ and specify the account you created on the VHD before uploading.
Voila, you’re in!
I hope you found this useful. If you did please share, like, or pin. Thanks.
Appendix A
There is some cleanup you can do on the VM after you get in. The account you created in Azure as part of the VM creation can be deleted by going to Computer Management | Local Users and Groups. Similarly, you can now connect your Microsoft Account to your login (if you so choose) as well as start installing any applications you wish.
If you do connect your Microsoft Account to a login on the machine, your login username to the VM does not change (ie: SmallDevMachine\Brandon) but your password changes to the one for your Microsoft Account.
Appendix B
By the way, if you don’t follow me on twitter you might’ve missed this, but Azure VMs have some serious bandwidth…
Appendix C
A lot of my readers are probably wondering if/how I have been able to develop for Windows Phone using this strategy. I’m sad to report that currently the answer is No. Since Windows Phone 8 uses Hyper-V to host the emulator, and the Azure VM is already running on Hyper-V, the emulator doesn’t function. And even though I have the RDP connection set up to pipe “Plug and Play Devices” through, it’s not picked up my Windows Phone when connected to my local machine so I can’t debug/deploy that way either. However I am running the GDR3 preview and have frequent “USB Device Not Recognized” warnings when I plug my Lumia 928 in to my machine, so that could be the reason I’m not able to do this…
The good news, however, is that you CAN develop for Windows 8, Windows Desktop, and Web with this strategy. If I, or anybody else, finds out how to do Windows Phone dev this way you can bet you’ll hear about it here on .Netitude!