This project has moved and is read-only. For the latest updates, please go here.

Changing the VHD drive size

Sep 9, 2011 at 7:08 PM

Here's the procedure I use to expand the VHD's size while preserving all of the drive's current content.

  1. Backup the VHD
    1. Download the "dotnetnuke6.vhd" blob (or whatever yours is called) for backup purposes (with Azure Storage Explorer, CloudBerry, etc.)
  2. Copy the VHD contents to node local storage
    1. RDP into the SMBServer instance (see David's documentation on how to do this)
    2. Copy the contents of the mounted drive (where your DNN installation files are; mine's named "WindowsAzureDrive") to local disk storage on the node (my instance has a "C" drive with 256 free gb; I copied the contents to a 'C:\DNN_Drive')
  3. Stop the DNN deployment
    1. Go to your hosted services in the Azure Management Portal
    2. Right click your DNN deployment and select "Stop" (stops all instances from both the 'SMBServer' and 'DNNAzure' roles)
    3. Wait for the status of all roles, instances and the deployment to say "Stopped" before proceeding
  4. Increase the VHD's size in the deployment config
    1. Go to your hosted services in the Azure Management Portal
    2. Right click your DNN deployment and select "Configure"
    3. Select the "Edit current configuration" radio button
    4. Increase your VHD's size by editing the "driveSize" setting (Ex. <Setting name="driveSize" value="5120" />)
    5. Select "OK"
  5. Delete the VHD
    1. Use Azure Storage Explorer, CloudBerry, or something else to delete the "dotnetnuke6.vhd" blob (mine's in the "azure-accelerator-drives" folder)
  6. Start the DNN deployment
    1. Go to your hosted services in the Azure Management Portal
    2. Right click your DNN deployment and select "Start"
    3. Wait for the status of all roles, instances and the deployment to say "Ready" before proceeding
  7. Copy the DNN content from node storage into the new VHD
    1. RDP into the SMBServer instance
    2. Check the size of the mounted drive (mine's called 'WindowsAzureDrive' again) make sure it is the new size
    3. Delete everything from the mounted drive
      Notes: Since we deleted the old VHD, when the deployment restarted it created a new VHD (with the new size) and filled it with fresh DNN installation files; we don't care about these files because we want our old DNN install files.
    4. Copy your old DNN installation contents from local node storage (remember step 2.2? My files where in 'C:/DNN_Drive') into the mounted drive (the new VHD)

Your done! Go to your DNN portals and make sure they all work like before.


  • Downtime: If this process runs smoothly, you should only have about 10 minutes of downtime or so. I am unaware of any way to enlarge the VHD without some downtime to your DNN portals.
  • Risk of using the node's local storage: Azure doesn't provide any guarentees for files you place on the local node storage. It is possible that while you're doing this, the SMBServer instance gets moved to another Azure node, in which case you'll loose everything you copied to local node storage (in my example, the "C:\DNN_Drive" folder). If this happens, you can revert to your old state by stopping the deployment, deleting the current VHD (if there is one), than uploading the VHD you download in step 1 back into blob storage (make sure to upload it as a page blob).

The way I did it seems pretty straight forward to me, but perhaps I'm missing something; is there any easier way of doing this? Are there any other drawbacks to this method other than the ones I mentioned?


Sep 11, 2011 at 3:58 PM

Hi Daryl,

I'm just working in a command line tool to make this process more easy (the command line tool will be called by a future admin web app published on the default site of the webroles, that will serve management utilities). The summary of the process should be:

1) Create a resized VHD of the current served VHD: the command line tool will do it on this steps automatically:

  1. Create a snapshot of the current VHD and mount it locally on the SMB server for read only (i.e. Drive W)
  2. Create a new empty and resized VHD and mount it locally on the SMB server (i.e. Drive Y)
  3. Copy the contents from drive W to drive Y
  4. Unmount drive W and Y, and delete the snapshot created on step 1

2) Deploy on staging: deploy on staging the DNN Azure accelerator package. The service configuration file targets the new resized VHD

3) VIP Swap: push the button "Swap VIP" to change the Virtual IPs (production-staging)

This approach should:

  • Ensure No downtime: the VIP swap ensures the all the web requests will be served and no downtime;
  • Ensure No data loss: as the copy-contents process is an standalone process and the risk of using node's local storage disappears (my advice is if you are copying things to the node's local storage, download a copy of the zipped contents to another location)

The command line tool is very easy to create. I'm thinking on the creation of this an more tools that will be available at "X:\utils" folder on the VHD. I'll create a workitem for this and put it on the roadmap.

Thanks for feedback!





Sep 11, 2011 at 4:05 PM

Hi again,

Dayl, after reading a second time your process, I recommend you another one while you wait for the command line tool:

1) Create a second service on staging, with the desired "driveSize" and pointing to another page blob name (i.e. "dotnetnuke6_resized.vhd")

2) Open RDP sessions on both production and staging environments

3) Zip the contents from production, and copy/paste on staging via RDP (this a slow and manual process, and there are better choices like mentioned before, but it works)

4) VIP swap

In any case, there is no need to download the complete VHD and of course, no need for deletion.

Hope this helps,


Sep 11, 2011 at 4:07 PM
This discussion has been copied to a work item. Click here to go to the work item and continue the discussion.
Sep 12, 2011 at 7:23 PM

Hey David,

Thanks for the suggestion, and that command line tool sounds really useful. I'll definitely try using your corrections; I especially like the idea of using the VIP swap. In my process, there is a potential to get into a corrupt state if anything goes wrong between the deletion of the old VHD and the creation and filling of the new VHD.

I'll be interested in trying out your comand line tool, too!


Mar 6, 2013 at 7:18 PM
The research done by Maarten Balliauw seems to be the definitive solution for resizing the VHD (read this post

Going to include the feature on the Accelerator this way.