We created and deployed many Azure VM Role Instances during the course of testing the
TreyResearch Windows Azure Hybrid Application. For example, in order to do the functional test and performance test, we created and deployed to the cloud four Visual Studio VM Role Instances with one
for each tester, one VS Load Test Controller VM Role Instance shared by all testers, and ten VS Load Test Agent VM Role Instances registered with the Controller. It would have taken lot of time and effort if we had started from scratch to repeatedly build
a new VM, install the OS, configure the firewall, and installed the common software each time we need a new VHD. Instead, we took the approach of creating a base VHD that has the common configurations for all of our VHDs as the starting point for build all
of our VHDs. Whenever we needed a new VHD with specific requirement, we made a copy of the base VHD, made necessary changes such as change the disk size, then installed additional tools such as Visual Studio, and uploaded it to the cloud. This approach worked
well for us.
By going through the process of creating a base VHD as a starting point, extending the base VHD to other specific VHD, uploading the specific VHD to the cloud, publishing the VHD into a Windows Azure VM role instance, and using the published instances, we
learned the following lessons regard building the base VHD:
- Having a base VHD file as the starting point for creating various other specific VHD files instead of start from scratch each time we need a new VHD can save time and effort.
- Specifying the hard disk size for the base VHD to be equal to the smallest hard disk size we want to deploy in the cloud, which is 15GB. Later, if we need bigger hard disk for a new specific VHD, we can increase the disk size. However, we cannot
reduce the disk size use the Hyper-V manager.
- Don’t install local endpoint of Windows Azure in a VHD. If we install local endpoint from windows azure in the VHD, the computer identity will be different from the original VHD VM after the VHD is sys-preped and deployed to windows azure, and local
endpoint would become invalid. We would have to un-install the local endpoint, restart the VM role, and re-install local endpoint. The correct way is to install local endpoint after the VM role instance is running in the cloud.
- Use sa authentication or mixed mode authentication when installing SQL Server
or SQL Server Express in the VHD even if we would eventually use the integrated Windows Authentication when the VM Role instance is in the cloud. The reason is that after Sys-prep the computer identity will be changed and the Windows user (even for the
administrator) in the original VHD will become invalid, and we would be unable to access the SQL Server.
- Run the common tasks needed for all of the planned VHDs in the base VHD. One of those tasks is to opening a few windows firewall ports to support the load test.
- Don’t worry about the memory allocation of the VHD. The assigned memory in the VHD is not the actual memory used when deployed in Windows Azure. The actual memory when VHD is deployed in the cloud is determined by the vmsize attribute in ServiceDefinition.csdef
- Always test the VHD after sys-prep. After the VHD is sys-preped, we always save it and test it to make sure that the software installed still works. This step will catch issues such as not being able to access the SQL Server due to authentication
settings not using sa.
- Install Windows in the newly created partition
In this step, we installed the Windows Azure VM Role Integration Components.
- In the Hyper V Manager Console right click on the Virtual Machine and select
settings. Click on DVD Drive then select Image File and then click
Browse. Navigate to the directory C:\Program Files\Windows Azure SDK\v1.5\iso and select file
wavmroleic.iso then click Apply.
- Note: If we have not installed the Windows Azure SDK in our Hyper-V server, we would need to copy the
wavmroleic.iso file from another computer where we installed the SDK to the Hyper-V server’s hard disk. We could find this file in the
iso folder of the Windows Azure SDK installation directory.
- After we connect the ISO file to the DVD drive the virtual machine, wait for the
AutoPlay dialog to appear and then click Open folder to view files using Windows Explorer. If the AutoPlay feature is not enabled, open a Windows Explorer window and browse to the CD/DVD drive.
- In the Windows Explorer window, locate the WaIntegrationComponents-x64.msi
(Windows Installer) file and double-click it to start the installation.
- At the Welcome screen, click Next to proceed.
- In the Operating System Configuration step, enter an Administrator Password, confirm it, and then click
- Click Install to begin the installation of the Integration Components.
- When prompted to install device software, click Install to proceed.
- Wait for the installation to complete, which should only take a few seconds.
- Click Finish to exit the setup program.
- Once the installation of the components has finished, we will be prompted to restart the system. Click Yes to continue.
- Wait for the system to restart and log in to the guest machine once again.
Configure IE ESC off by running Server Manager. Otherwise, we are unable to install the Windows Azure Connect Local Endpoint later.
- Start Server Manager
- Under Security Information, click Configure IE ESC
- Check Off radio button under both Administrators and
- Click OK.
This step will disable the automatic update feature of Windows Operating System. This will require to update the VM manually after is deployed.
- Open the Windows Update control panel from Start | All Programs | Windows Update.
- In the Windows Update page, select Change Settings.
- In the Change Settings page, select the option labeled Never check for updates (not recommended) and then click
- Next, click Check for updates and install all available updates.
- If prompted, we may need to reboot and repeat the check for updates in case there are additional updates to install.
- Create C:\ AzureSTartUp.cmd. Start task scheduler, create a basic task, name it AzureStartUpTask, set the trigger to the computer starts, set the action to start a program->c:\AzureStartup.cmd to run AzureStartUp.cmd. Make sure to change the owner
of the task to system account. Use highest permission.
- To open windows firewall ports for VS2010 client, VS2010 load test controller, and VS2010 load test agent. We copied the following script to the AzureStartup.cmd file:
netsh advfirewall firewall add rule name="ICMPv6" dir=in action=allow enable=yes protocol=icmpv6
netsh advfirewall firewall add rule name="Port 445 TCP" dir=in action=allow service=any enable=yes profile=any localport=445 protocol=tcp
netsh advfirewall firewall add rule name="Port 445 UDP" dir=in action=allow service=any enable=yes profile=any localport=445 protocol=udp
netsh advfirewall firewall add rule name="Port 6901 TCP" dir=in action=allow service=any enable=yes profile=any localport=6901 protocol=tcp
netsh advfirewall firewall add rule name="Port 6901 UDP" dir=in action=allow service=any enable=yes profile=any localport=6901 protocol=udp
netsh advfirewall firewall add rule name="Port 6910 TCP" dir=in action=allow service=any enable=yes profile=any localport=6910 protocol=tcp
netsh advfirewall firewall add rule name="Port 6910 UDP" dir=in action=allow service=any enable=yes profile=any localport=6910 protocol=udp
netsh advfirewall firewall add rule name="devenve.exe" dir=in action=allow program=""%"ProgramFiles"%" (x86)\Microsoft Visual Studio 10.0\Conmmon7\IDE\devenv.exe” enable=yes
netsh advfirewall firewall add rule name="mstest.exe" dir=in action=allow program=""%"ProgramFiles"%" (x86)\Microsoft Visual Studio 10.0\Conmmon7\IDE\MSTest.exe"
net stop lanmanserver
net start lanmanserver
exit /b 0
- The purpose of this step is to prepare the image for cloning by generalizing unique elements that are present on the operating system like computer names, security identifiers and driver cache. By doing this step we will be able to clone from this image
and generate VMs that are unique after the base image is uploaded.
- Now, inside the VM, open the Start menu, type %windir%\system32\sysprep\sysprep.exe and then press Enter to launch the System Preparation Tool. Set the System Cleanup Action to “Enter System Out-of-Box Experience (OOBE)”, check the option labeled
Generalize, set the Shutdown Options to Shutdown, and then press OK.
- Note: The Sysprep tool (Sysprep.exe) prepares the image by cleaning up various user and machine settings and log files, as well as removing any hardware-dependent information.
- Wait for the system to completely shut down. Our image is now ready for deployment.