The deployment of Windows 7 within large organisations involves more than the simple delivery and installation of the operating system onto PCs. Prior to deployment, analysis of the host environment in terms of suitability and compatibility must be undertaken. When I say ‘suitability’, I’m talking about whether the infrastructure can host and deliver the Windows 7 image together with all the other files involved e.g. drivers, updates, applications etc.

As for Windows 7 compatibility, this must consider both applications and hardware. Analysis must be undertaken to determine whether a successful deployment requires new PC hardware be provisioned or maybe just requires new drivers. In other words, whether it is appropriate to undertake bare metal or refresh deployments.Irrespective of the approach taken, application compatibility must also be consideredwell before undertaking any deployment.

In this issue of our Windows 7 Deployment series, I compare the 2 common Windows 7 Zero-touch deployment scenarios of bare-metal and refresh. Depending on the specification of your current PC hardware, Windows 7 deployment may involve one or both approaches.

Before I go any further, let me clarify exactly what we mean by these terms:

· Bare-metal – this scenario should really be called ‘new hardware’ as we include both empty disk and prestaged media approaches. Both types of deployment can be initiated via removable media or more typical for large environments, via PXE boot. We will concentrate on the PXE boot approach here.

· Refresh – in this scenario the deployment is initiated from the existing operating system via a ConfigMgr advertised program.

let us take a closer look at the 2 new hardware scenarios commonly available:

Bare-metal or Prestaged media

New hardware is either supplied with no (usable) OS installed, or prestaged with the operating system and boot images (support for prestaging the operating system and boot images was introduced in ConfigMgr R3). The latter option obviously provides advantages in terms of lessening the time needed to deploy the new operating system once the hardware has arrived. ConfigMgr facilitates both scenarios through deployment of the appropriate task sequence. So how is the prestage accomplished in ConfigMgr? Well, basically, you would create a task sequence media WIM file using a wizard in the ConfigMgr administration console. This would then be shipped to the OEM where they would deploy this onto the new hardware. Once the new hardware has arrived from the OEM, the machine can be PXE booted and targeted with a task sequence to complete the deployment. The final task sequence will typically install drivers, updates and applications. The prestage scenario therefore can save considerable time and bandwidth copying and installing the image – especially where the locations are not well connected to a distribution point server or does not make use of 1E PXE Lite.

Despite the advantages, prestaging may not suit all organisations. It can be argued that the time saved in performing deployments must be balanced against the extra effort and time required to implement any change to the image once the original has been shipped to the OEM. However, since things such as drivers, updates and applications are installed in the post prestage deployment, it is likely that this will be infrequent, for instance upon release of a service pack.

Pre-Deployment

If attempting to perform a refresh, then it is likely you will spend more time in the pre-deployment phase of the project undertaking hardware compatibility analysis than if the decision were taken to upgrade only as part of a hardware refresh cycle. As described in a previous article, this is where the Microsoft Assessment and Planning (MAP) Toolkit 5.0 comes into play. The results of the analysis leads to the decision to either retain existing hardware and refresh, or that due to poor specification or driver availability, new hardware must be provisioned. In the bare-metal scenario, the hardware vendor will usually certify the new hardware as Windows 7 ready with drivers available for all onboard devices making this approach an attractive proposition.

User State Capture and restore

The process of user state capture in a new hardware scenario is different to that which takes place during a refresh mainly in the fact that user data cannot be stored locally on the machine being built. Without PXELite, this necessitates the use of a ConfigMgr State Migration Pointserver (SMP). Deployment of SMPs can therefore demand the same consideration as when deploying Distribution Point servers if excessive WAN traffic is to be avoided.

User state capture and restore is accomplished using the Microsoft User State Migration Tool (USMT). For a refresh scenario, USMT v4 allows migration data to be retained on the local disk throughout the deployment process using ‘hardlinks’. This results in minimal local storage requirements which also speeds up the capture and restore process. However, this feature is only available when upgrading from Vista to Windows 7. If upgrading from XP, then SMPs may still be required if the machine runs short on disk space.

Another difference is that bare-metal requires a Computer Association (CA) object, which must first be created in the site before data capture can take place. The CA maps the source and (new) target machines within ConfigMgr. Pre-creation of the CA can be too restrictive for some customers and 1E have adapted the bare-metal process to make the process of capture and restore as seamless as possible.

In our experience, it is also important that the state capture process takes place at the right time in terms of ensuring all data is captured without inconvenience to the user. This goes for both the bare-metal and refresh scenarios. 1E Shopping can facilitate this by allowing the user to decide when to run the state capture on their old machine, or to refresh their existing machine.

Running the Deployment

In a Refresh scenario, an advertisement is used to launch the deployment task sequence. Therefore, unlike the bare-metal scenario, it relies on the host machine and ConfigMgr client being operational. Refresh does of course offer the ability to schedule deployments.

Accessing Deployment Packages

For both deployment scenarios, ready access to packages referenced within the deployment task sequence is critical. For PCs that are well connected to Distribution Points (and State Migration Points for that matter), this is not a problem. For remote sites of maybe 2 to two hundred machines that may not have access to a local server, then this can be a show stopper for deployments. PXE Lite does however provide a cost effective solution.

PXE Lite facilitates PXE booting, image deployment and user data storage without the need for any local ConfigMgr site systems (PXE Service Point, Distribution Point and State Migration Point). Typically, the nominated PXE Lite Local server or workstation (with the Nomad agent installed) has the deployment packages ‘pre-cached’ and is able to serve these to deployments occurring on the local subnet. This is for both new hardware and refresh scenarios. A PXE Lite enabled task sequence means that the deployment process can be entirely contained within the subnet.

To simplify the deployment and administration process, some of our customers use PXE Lite throughout their entire environment rather than just in their branch offices. Typically Distribution Points are still used in the larger sites for content distribution .

Facilitating a Speedy Refresh

Preserving application files that have been cached locally prior to OS deployment is important if application installation during the refresh is to complete as quickly as possible. If Nomad has been used to perform application deployments prior to the refresh, then Save and Restore Nomad Branch Cache steps can be added to the refresh task sequence to facilitate this as shown below: