Creating an OSD test environment
The first step in successful OSD is to have a useful test environment that you can connect to remotely and rebuild quickly. You need a Virtual Machine (VM). VMs allow you to quickly perform testing cycles with OSD. Enter MICROSOFT HYPER-V.
This may come as a surprise to many, but Microsoft Hyper-V Server 2008 R2 is actually a free product. Microsoft Hyper-V Server is a free download from Microsoft—to obtain the latest version, use your favourite web search utility to search for hyper-v server free.
Or if you have an available license for Windows Server 2008 or R2, you can simply install the OS on your server, and enable the Hyper-V role. We'll show you how to use the free Hyper-V offering below to make a VM, but the option for the Hyper-V role is similar.
Getting ready
Install Microsoft Hyper-V Server 2008 R2 on a server (preferred) or workstation system. Once Hyper-V is installed, it will appear similar to Windows Server Core, in that you will not have a graphical user interface to log in to. Depending on your hardware, you may need to add network drivers to the Hyper-V server using drvlo ad.exe (http://technet.microsoft.com/en-us/library/dd744511(v=WS.10).aspx) or pnputil.exe (http://technet.microsoft.com/en-us/library/ff800798(v=WS.10).aspx).
Ensure your Hyper-V server is on a DHCP network that can resolve to the FQDN of the Management Point (MP) and Distribution Point (DP). Install the Remote Server Administrator Toolkit (RSAT) on a Windows workstation, and then install the Hyper-V component.
How to do it...
- Launch Hyper-V Manager from a Windows 7 system, and connect to your Hyper-V server.
- Use the Virtual Network Manager to create a new virtual network. For Connection Type, select External, and select the actual NIC card in the system, and enable the Allow management operating system to share this network adapter checkbox. Click on OK to close the Virtual Network Manager configuration utility.
- Right-click on the server and go to New | Virtual Machine. Provide an appropriate name and location to store the virtual machine, and assign default memory of at least 1024 MB.
- To configure networking, specify the connection to be to your Local Area Connection NIC.
- Specify whether to use an existing virtual hard disk or create a new virtual hard disk.
- Leave the default Installation Options, and then select Finish to complete the New Virtual Machine wizard.
- Before powering on the new VM, right-click the VM and view settings. If you plan to build the system using PXE, or if the target guest OS will be Windows XP or Server 2003, add a Legacy Network Adapter from the Add Hardware action.
You have successfully created a test VM for OS Deployment testing. You can mount an ISO file or boot to PXE (if configured for your environment). Testing OS deployment in a VM will significantly reduce the time required for test and re-test.
How it works...
VMs are essential to building, capturing, and deploying images. Hyper-V is a tool you can quickly bring up to get you started. The VMs you create with it can be used for creating and testing OS deployments.
There's more...
Testing OS deployment in a VM simplifies the testing process, as well as allowing you to connect remotely to the Hyper-V server. Depending on your operating system version, you can either install the Hyper-V components natively from the OS, or you can install the RSAT, and then enable the Hyper-V console. You can completely create and test your reference image (discussed in the Leveraging the Build and Capture Process using a VM recipe. You can also perform significant testing for your production build in a VM.
In the next recipe, you will create a reference build. This is simply the base image that will be used in your production's build process. Your reference build should contain no additional drivers if at all possible. CM does a great job of managing the drivers for your OS deployment, and the goal is to keep them modular so that you can update either piece (the OS image or the drivers) without the need to update both. Also, by keeping the drivers separate, you can leverage CM to surgically inject the necessary drivers into the driver store at production build time. Your goal is to have one image per OS architecture, and dynamically apply drivers and other hardware-specific applications during the production OS deployment.
You will also update your reference image at regular intervals (possibly every quarter, or bi-annually.) Review the Patching your Reference Build recipe in the chapter for an easier method to apply windows patches. Performing the entire process in a standard VM provides a very repeatable, reusable process.
Most OS deployments will eventually be deployed to physical hardware, so testing will need to occur on the physical hardware. Depending on your environment, you may also have virtual machines that you deploy. Either way, perform initial testing of your production build in a VM. You can quickly perform several testing iterations, as well as test most application installations during the OSD process.
There will be some components that you will not be able to fully test until the OS is deployed to hardware—specifically drivers. Network, mass storage, video, and other drivers will likely be different than your test VM. In addition to drivers, you may have software-based hard drive encryption, Bluetooth applications, and other utilities that are tied to the hardware. Keep these in mind, and test these on real hardware when possible.