Share via

Windows Deployment Scenarios and Tools

  • Article

Applies To: Windows 8.1

To successfully deploy the Windows 8.1 operating system and applications for your organization, it’s essential that you know which tools to use, when they should be used, and how to use them. You also need to understand the different deployment scenarios that are available. In this topic, you learn about the most commonly used tools and scenarios for Windows 8.1 deployment.

Microsoft provides many tools, services, and solutions to support the various deployment scenarios. These tools include Windows Deployment Services (WDS), the Volume Activation Management Tool (VAMT), the User State Migration Tool (USMT), Windows System Image Manager (Windows SIM), Windows Preinstallation Environment (Windows PE), and Windows Recovery Environment (Windows RE). Keep in mind that these are just tools and not a complete solution on their own. It’s when you combine these tools with solutions like Microsoft Deployment Toolkit (MDT) 2013 or Microsoft System Center 2012 R2 Configuration Manager that you get the complete deployment solution.

In this topic, you also learn about different types of reference images that you can build, and why reference images are beneficial for most organizations

In this topic

  • Windows 8.1 deployment scenarios

  • Windows 8.1 image options

  • Windows 8.1 and drivers

  • Windows 8.1 and Volume Activation

  • Windows 8.1 drive encryption with BitLocker

  • Windows Assessment and Deployment Kit

  • Windows Recovery Environment

  • Windows Deployment Services

  • Microsoft Deployment Toolkit 2013

  • Microsoft Security Compliance Manager 2013

  • Microsoft Desktop Optimization Pack 2013 R2

  • Internet Explorer Administration Kit 11

  • Windows Server Update Services

  • Unified Extensible Firmware Interface

See also

Windows 8.1 deployment scenarios

Operating system deployment can be divided into different scenarios. The scenarios are explained in detail in the following sections, but here is quick summary:

  • New computer. A bare-metal deployment of a new machine.

  • Computer refresh. A reinstall of the same machine (with user-state migration and an optional full Windows Imaging (WIM) image backup).

  • Computer replace. A replacement of the old machine with a new machine (with user-state migration and an optional full WIM image backup).

New computer

This scenario occurs when you have a blank machine you need to deploy, or an existing machine you want to wipe and redeploy without needing to preserve any existing data. The setup starts from a boot media, using CD, USB, ISO, or Pre-Boot Execution Environment (PXE). You can also generate a full offline media that includes all the files needed for a client deployment, allowing you to deploy without having to connect to a central deployment share. The target can be a physical computer, a virtual machine, or a Virtual Hard Disk (VHD) running on a physical computer (boot from VHD).

The deployment process for the new machine scenario is as follows:

  1. Start the setup from boot media (CD, USB, ISO, or PXE).

  2. Wipe the hard disk clean and create new volume(s).

  3. Install the operating system image.

  4. Install other applications (as part of the task sequence).

After taking these steps, the machine is ready for use.

Refresh

A refresh is sometimes called wipe-and-load. The process is normally initiated in the running operating system. User data and settings are backed up and restored later as part of the deployment process. The target can be the same as for the new computer scenario.

The deployment process for the wipe-and-load scenario is as follows:

  1. Start the setup on a running operating system.

  2. Save the user state locally.

  3. Wipe the hard disk clean (except for the folder containing the backup).

  4. Install the operating system image.

  5. Install other applications.

  6. Restore the user state.

After taking these steps, the machine is ready for use.

Note

Windows 8 and Windows 8.1 have a built-in function called Upgrade. See Upgrade Windows 8 to Windows 8.1 for guidance on the upgrade process.

Replace

A computer replace is similar to the refresh scenario. However, since we are replacing the machine, we divide this scenario into two main tasks: backup of the old client and bare-metal deployment of the new client. As with the refresh scenario, user data and settings are backed up and restored.

The deployment process for the replace scenario is as follows:

  1. Save the user state (data and settings) on the server through a backup job on the running operating system.

  2. Deploy the new computer as a bare-metal deployment.

Note

In some situations, you can use the replace scenario even if the target is the same machine. For example, you can use replace if you want to modify the disk layout from the master boot record (MBR) to the GUID partition table (GPT), which will allow you to take advantage of the Unified Extensible Firmware Interface (UEFI) functionality. You can also use replace if the disk needs to be repartitioned since user data needs to be transferred off the disk.

Windows 8.1 image options

Starting with Windows Vista, operating-system deployment has been completely image based. For example, if you open the Windows 8.1 ISO or DVD and look in the Sources folder, you will find the install.wim file. This is a ready-to-go image of Windows 8, created using the System Preparation (Sysprep) tool. This image also supports offline servicing, which enables you to add updates, language packs, drivers, and more.

Reference images

With Windows 8.1, it’s not necessary to create a reference image, because the image on the Windows 8.1 DVD ISO is ready for deployment. However, you probably still want to create a reference image of Windows 8.1 for other reasons, such as speed of deployment and security during the deployment process.

As with all operating systems, Windows 8.1 will require updates in the future, and using reference images with integrated updates greatly saves time during deployment. In general, we strongly recommend creating reference images from the beginning because changing methods later on takes additional time.

Thin image

A thin image is an image without any applications. It may contain some basic settings, such as customizations to Internet Explorer or other operating system changes. When deploying thin images, the applications, drivers, and additional settings are installed or injected at deployment time. Even if this image type typically contains operating system components like the Microsoft .NET Framework, Internet Explorer, and updates from Microsoft Update, it’s still considered a thin image.

Thick image

A thick image is an image that includes most applications. The primary reason for creating a thick image is deployment speed. Drivers and settings are still kept outside the image, with the exception of the Windows To Go feature in Windows 8 and Windows 8.1, for which you do want to include drivers.

In general, a thick image is more suitable in a static environment. Educational organizations might use this type of image when they need to deploy Windows to classrooms with many machines in a short time.

Note

If you decide to use applications in the image, make sure that the applications are Sysprep aware. For example, never put antivirus software in the reference image it is the most common cause of Sysprep breaking. Applications that have unique identifiers should also not be included in an image as they will not survive the Sysprep process.
The main purpose of thick images is to reduce deployment time. If you have applications that require a manual installation, it’s ideal to include them in the reference image. Once they are included in the thick image, you won’t need to install them individually again.

Hybrid image

A hybrid image is an image that includes only some features or applications, while others are installed as part of the image deployment process. The primary reason for creating this image type is for deployment speed. A hybrid image can sometimes provide you with the best of both worlds, decreasing deployment time, but providing flexibility. This is the most commonly used image type, and in this topic you will use the hybrid image.

Windows 8.1 and drivers

When deploying Windows to physical hardware, the setup requires drivers, and the various deployment solutions from Microsoft have slightly different ways of handling them. However, they do have a few things in common, the first of which is that you need to find the drivers.

Finding the drivers

Ideally, there would be one place where you could download ready-made drivers for all your hardware. Instead, you’ll need to download drivers for each vendor’s separately.

  • HP. For HP hardware, you can use their SoftPaq Download Manager utility, accessible on the HP Support site. This allows you to quickly select your hardware model(s) and the operating system for which you want the drivers.

  • Lenovo. For Lenovo hardware, we recommend using the Lenovo ThinkVantage Update Retriever utility, which is available on the Lenovo website. This utility is similar to the HP tool.

  • Dell. For Dell hardware, you don’t need to use a separate utility because Dell provides ready-made CAB files with drivers for each model. These CAB files are accessible via the Dell TechCenter.

  • Others. For other vendor’s hardware, you need to go to their website and download the drivers.

Driver scenarios

In general, you always want to start with each vendor’s solution for getting drivers because these will be the only supported drivers from that vendor. However, sometimes you simply cannot find the driver at the vendor site. If that happens, the next best option is to go to the vendor’s vendor. Another option is to go to the Microsoft Update Catalog site, which has drivers for most hardware.

Figure 1. The Microsoft Update Catalog drivers for NVIDIA Quadro K3000M.

Windows 8.1 and Volume Activation

Since Windows Vista, all versions of Windows need to be activated. As an enterprise organization, you have a few different options: You can activate the Windows 8.1 client on premises via Active Directory-based activation (ADBA) or Key Management Service (KMS). You can activate off premises through Microsoft Hosted Volume Activation services (online or via telephone), or you can use Multiple Activation Keys (MAKs). For more details, see Volume Activation for Windows 8.1.

Active Directory-based activation

If your activation server is running Windows Server 2012 R2, you can use the new Active Directory-based activation service for your Windows 8.1 clients. The only requirement is that you have extended the Active Directory schema. ADBA is configured by adding the Volume Activation Services server role.

If you need to support clients running previous versions of Windows like Windows 7, you still need to use KMS. If you cannot use ADBA or KMS, you can also use MAKs to activate the installations. Like ADBA, KMS is also configured by adding the Volume Activation Services role.

Figure 2. Configuring the activation method.

Note

The Volume Activation Tools wizard doesn’t behave the way you would expect. You need to select Close before the wizard is obviously complete. If you continue to press Next, the wizard will remove the key in the end. Read the text carefully so you know when to click Close.

Key Management Service (KMS)

KMS allows enterprise organizations to enable activation of operating systems for Windows Vista and later.

You also can use an existing Windows 7 or Windows Server 2008 R2 KMS host to activate Windows 8.1 clients, but first you need to apply the KB2885698 hotfix on your KMS host. With that hotfix, KMS provides support for the following client activations:

  • Windows Vista, Windows 7, Windows 8, Windows 8.1

  • Windows Server 2008, Windows Server 2008 R2

  • Windows Server 2012, Windows Server 2012 R2

Important

KMS running on a client operating system can only activate clients, while KMS running on a server can activate both clients and servers. For more details, see Volume Activation for Windows 8.1.

Multiple Activation Keys (MAK)

If you cannot use KMS or Active Directory-based activation, you can use Multiple Activation Keys (MAKs) to activate the installations. It’s not uncommon for organizations to use both KMS and MAK licenses. KMS and Active Directory require the clients to be activated at least once every 180 day. If this is not possible, then a MAK key can be used.

Your license agreement provides a certain number of MAKs. Every time you activate a machine using a MAK, the number of available activations decreases. When you have reached zero, Microsoft will provide new keys for you. If you do use MAK, the Volume Activation Management Tool (VAMT) is suitable for managing the keys. VAMT is a part of Windows Assessment and Deployment Kit (Windows ADK).

Figure 3. Sample view of VAMT.

Windows 8.1 drive encryption with BitLocker

Since Windows clients started to become mobile, the need for drive encryption has increased. Laptops are stolen or lost every day, and by encrypting them, you prevent unauthorized access to their data.

The Microsoft drive encryption solution is BitLocker, and it provides volume encryption rather than full disk encryption. As an administrator, you can determine which volumes you want to have encrypted. You also can use BitLocker to help protect Windows To Go, and BitLocker To Go to encrypt content on USB sticks and external hard drives.

What makes BitLocker different from many of the third-party solutions is that it’s easy to integrate BitLocker with the operating system deployment process.

Note

The Windows 8.1 version of BitLocker also supports hardware-based encryption.

Windows Assessment and Deployment Kit

Windows ADK contains core assessment and deployment tools and technologies, including Deployment Image Servicing and Management (DISM), Windows System Image Manager (Windows SIM), User State Migration Tool (USMT), Volume Activation Management Tool (VAMT), Windows Preinstallation Environment (Windows PE), Windows Assessment Services, Windows Performance Toolkit (WPT), Application Compatibility Toolkit (ACT), and Microsoft SQL Server 2012 Express. For more details, see Windows Deployment with the Windows ADK.

Figure 4. The Windows ADK feature selection page.

Deployment Image Servicing and Management (DISM)

DISM is one of the deployment tools included in the Windows ADK and is used for servicing boot images and operating system images. The Windows 8 and Windows 8.1 versions of DISM now support applying and capturing images; this support was not offered in the DISM version for Windows 7.

DISM services online and offline images. For example, with DISM you can installing the Microsoft .NET Framework 3.5.1 in Windows 8.1 online, which means that you can start the installation in the running operating system, not that you get the software online. The /LimitAccess switch configures DISM to get the files only from a local source:

Dism.exe /Online /Enable-Feature /FeatureName:NetFX3 /All /Source:D:\Sources\SxS /LimitAccess

In Windows 8.1, you can use Windows PowerShell for many of the functions performed by DISM.exe. The equivalent command in Windows 8.1 using PowerShell is:

Enable-WindowsOptionalFeature -Online -FeatureName NetFx3 -All 
-Source D:\Sources\SxS -LimitAccess

Figure 5. Using DISM functions in PowerShell.

For more information on DISM, see the DISM Technical Reference

User State Migration Tool (USMT)

USMT is a backup and restore tool that allows you to migrate user state, data, and settings from one installation to another. Microsoft Deployment Toolkit (MDT) and System Center 2012 R2 Configuration Manager use USMT as part of the operating system deployment process. USMT 6.3 is used to support migrating from earlier versions of Windows (Windows 7 or later) to Windows 8.

Note

Occasionally, we find that customers are wary of USMT because they believe it requires significant configuration, but, as you will learn below, using USMT is not difficult. If you use MDT and Lite Touch to deploy your machines, the USMT feature is automatically configured and extended so that it is easy to use. With MDT, you do nothing at all and USMT just works.

USMT is a command-line version of the Windows Easy Transfer migration tool built into Windows 8.1. USMT 6.3 includes several tools, the most important of which are ScanState and LoadState:

  • ScanState.exe. This performs the user-state backup.

  • LoadState.exe. This performs the user-state restore.

  • UsmtUtils.exe. This supplements the functionality in ScanState.exe and LoadState.exe.

In addition to these tools, there are also XML templates that manage which data is migrated. You can customize the templates, or create new ones, to manage the backup process at a high level of detail. USMT uses the following terms for its templates:

  • Migration templates. The default templates in USMT.

  • Custom templates. Custom templates that you create.

  • Config template. An optional template, called Config.xml, which you can use to exclude or include components in a migration without modifying the other standard XML templates.

Figure 6. A sample USMT migration file that will exclude .MP3 files on all local drives and include the folder C:\Data and all its files, including its subdirectories and their files.

USMT 6.3 supports upgrading from Windows 7 to Windows 8 or Windows 8.1, and from Windows 8 to Windows 8.1. It also supports migrating from a 32-bit operating system to a 64-bit operating system, but not the other way around. For example, you can use USMT to migrate from Windows 7 x86 to Windows 8.1 x64.

By default USMT migrates many settings, most of which are related to the user profile but also to Control Panel configurations, file types, and more. The default templates that are used in Windows 8.1 deployments are MigUser.xml and MigApp.xml. These two default templates migrate the following data and settings:

  • Folders from each profile, including those from user profiles as well as shared and public profiles. For example, the My Documents, My Video, My Music, My Pictures, desktop files, Start menu, Quick Launch settings, and Favorites folders are migrated.

  • Specific file types. USMT templates migrate the following file types: .accdb, .ch3, .csv, .dif, .doc*, .dot*, .dqy, .iqy, .mcw, .mdb*, .mpp, .one*, .oqy, .or6, .pot*, .ppa, .pps*, .ppt*, .pre, .pst, .pub, .qdf, .qel, .qph, .qsd, .rqy, .rtf, .scd, .sh3, .slk, .txt, .vl*, .vsd, .wk*, .wpd, .wps, .wq1, .wri, .xl*, .xla, .xlb, .xls*.

Note

The OpenDocument extensions (*.odt, *.odp, *.ods, etc.) that Microsoft Office applications can use are not migrated by default.

  • Operating system component settings

  • Application settings

These are the settings migrated by the default MigUser.xml and MigApp.xml templates. For more details on what USMT migrates, see What Does USMT Migrate?. For more information on the USMT overall, see the USMT Technical Reference.

Windows System Image Manager (Windows SIM)

Windows SIM is an authoring tool for Unattend.xml files. When using MDT and/or Configuration Manager, you don’t need Windows SIM very often because those systems automatically update the Unattend.xml file during the deployment, greatly simplifying the process overall.

Figure 7. Windows 8.1 answer file opened in Windows SIM.

Volume Activation Management Tool (VAMT)

If you don’t use KMS, you can still manage your MAKs centrally with the Volume Activation Management Tool (VAMT). With this tool, you can install and manage product keys throughout the organization. VAMT also can activate on behalf of clients without Internet access, acting as a MAK proxy. Windows ADK includes VAMT version 3.1.

Figure 8. The updated Volume Activation Management Tool.

VAMT 3.1 also can be used to create reports, switch from MAK to KMS, manage Active Directory-based activation, and manage Office 2010 and Office 2013 volume activation. VAMT 3.1 now supports PowerShell (instead of the old command-line tool). For example, if you want to get information from the VAMT database, you can type:

Get-VamtProduct

For more information on the VAMT, see the VAMT Technical Reference.

Windows Preinstallation Environment (Windows PE)

Windows PE 5.0 is a “Lite” version of Windows 8.1 and was created to act as a deployment platform. Windows PE replaces the DOS or Linux boot disks that ruled the deployment solutions of the last decade.

The key thing to know about Windows PE is that, like the operating system, it needs drivers. It requires Windows 8.1-type drivers, at the very least network and storage drivers. Luckily Windows PE 5.0 has the same drivers as Windows 8.1, which means much of your hardware will work out of the box.

Figure 9. A machine booted with the Windows ADK default Windows PE 5.0 boot image.

For more details on Windows PE, see WinPE for Windows 8: Windows PE 5.0.

Windows Recovery Environment

Windows Recovery Environment (Windows RE) is a diagnostics and recovery toolset included in Windows Vista and later operating systems. The latest version of Windows RE is based on Windows PE 5.0. You can also extend Windows RE and add your own tools if needed. If a Windows 8.1 installation fails to start and Windows RE is installed, you will see an automatic failover into Windows RE.

Figure 10. A Windows 8.1 client booted into Windows RE, showing Advanced options.

For more information on Windows RE, see the Windows RE Technical Reference.

Windows Deployment Services

Windows Deployment Services (WDS) has been updated and improved in several ways starting with Windows 8. Remember that the two main functions you will use are the PXE boot support and multicast. Most of the changes are related to management and increased performance. In Windows Server 2012 R2, WDS also can be used for the Network Unlock feature in BitLocker.

Figure 11. Windows Deployment Services using multicast to deploy three machines.

In Windows Server 2012 R2, Windows Deployment Services can be configured for stand-alone mode or for Active Directory integration. In most scenarios, the Active Directory integration mode is the best option. WDS also has the capability to manage drivers; however, driver management through MDT and Configuration Manager is more suitable for deployment due to the flexibility offered by both solutions, so you will use them instead. In WDS, it is possible to pre-stage devices in Active Directory, but here, too, Configuration Manager has that capability built in, and MDT has the ability to use a SQL Server database for pre-staging. In most scenarios, those solutions are better than the built-in pre-staging function as they allow greater control and management.

Trivial File Transfer Protocol (TFTP) configuration

In some cases, you need to modify TFTP Maximum Block Size settings for performance tuning reasons, especially when PXE traffic travels through routers and such. In the previous version of WDS, it was possible to change that, but the method of do so—editing the registry—was not user friendly. In Windows Server 2012, this has become much easier to do as it can be configured as a setting.

Also, there are a few new features related to TFTP performance:

  • Scalable buffer management. Allows buffering an entire file instead of a fixed-size buffer for each client, enabling different sessions to read from the same shared buffer.

  • Scalable port management. Provides the capability to service clients with shared UDP port allocation, increasing scalability.

  • Variable-size transmission window (Variable Windows Extension). Improves TFTP performance by allowing the client and server to determine the largest workable window size.

Figure 12. TFTP changes are now easy to perform.

Microsoft Deployment Toolkit 2013

MDT 2013 is a free deployment solution from Microsoft. It provides end-to-end guidance, best practices, and tools for planning, building, and deploying Windows operating systems. MDT builds on top of the core deployment tools in the Windows ADK by contributing guidance, reducing complexity, and adding critical features for an enterprise-ready deployment solution.

MDT 2013 has two main parts: the first is Lite Touch, which is a stand-alone deployment solution; the second is Zero Touch, which is an extension to System Center 2012 R2 Configuration Manager.

Note

Lite Touch and Zero Touch are marketing names for the two solutions that MDT 2013 supports, and the naming has nothing to do with automation. You can fully automate the stand-alone MDT 2013 solution (Lite Touch), and you can configure the solution integration with Configuration Manager to prompt for information.

Figure 13. The Deployment Workbench in MDT 2013, showing a task sequence.

For more information on MDT 2013, see the Microsoft Deployment Toolkit resource center.

Microsoft Security Compliance Manager 2013

Microsoft SCM is a free utility used to create baseline security settings for the Windows client and server environment. The baselines can be exported and then deployed via Group Policy, local policies, MDT, or Configuration Manager. The current version of Security Compliance Manager includes full support for Windows 8, Windows Server 2012, and Internet Explorer 10 baselines. For security baselines for Windows 8.1, Windows Server 2012, and Internet Explorer 11, see Security baselines for Windows 8.1, Windows Server 2012 R2 and Internet Explorer 11.

Figure 14. The SCM console showing a baseline configuration for a fictional client's computer security compliance.

Microsoft Desktop Optimization Pack 2013 R2

MDOP is a suite of technologies available to Software Assurance customers through an additional subscription.

The following components are included in the MDOP suite:

  • Microsoft Application Virtualization (App-V). App-V 5.0 provides an integrated platform, more flexible virtualization, and powerful management for virtualized applications. With the release of App-V 5.0 SP2, you have support to run virtual applications on Windows 8 and Windows 8.1.

  • Microsoft User Experience Virtualization (UE-V). UE-V monitors the changes that are made by users to application settings and Windows operating system settings. The user settings are captured and centralized to a settings storage location. These settings can then be applied to the different computers that are accessed by the user, including desktop computers, laptop computers, and virtual desktop infrastructure (VDI) sessions.

  • Microsoft Advanced Group Policy Management (AGPM). AGPM enables advanced management of Group Policy objects by providing change control, offline editing, and role-based delegation.

  • Microsoft Diagnostics and Recovery Toolset (DaRT). DaRT provides additional tools that extend Windows RE to help you troubleshoot and repair your machines.

  • Microsoft BitLocker Administration and Monitoring (MBAM). MBAM is an administrator interface used to manage BitLocker drive encryption. It allows you to configure your enterprise with the correct BitLocker encryption policy options, as well as monitor compliance with these policies.

For more information on the benefits of an MDOP subscription, see Streamlining Windows Deployment with the Microsoft Desktop Optimization Pack.

Internet Explorer Administration Kit 11

There has been a version of IEAK for every version of Internet Explorer since 3.0. It gives you the capability to customize Internet Explorer as you would like. The end result of using IEAK is an Internet Explorer package that can be deployed unattended. The wizard creates one .exe file and one .msi file.

Figure 15. The User Experience selection screen in IEAK 11.

To download IEAK 11, see the Internet Explorer Administration Kit (IEAK) Information and Downloads page.

Windows Server Update Services

WSUS is a server role in Windows Server 2012 R2 that enables you to maintain a local repository of Microsoft updates and then distribute them to machines on your network. WSUS offers approval control and reporting of update status in your environment.

Figure 16. The Windows Server Update Services console.

For more information on WSUS, see the Windows Server Update Services Overview.

Unified Extensible Firmware Interface

For many years BIOS has been the industry standard for booting a PC. BIOS has served us well, but it is time to replace it with something better. UEFI is the replacement for BIOS, so it is important to understand the differences between BIOS and UEFI. In this section, you learn the major differences between the two and how they affect operating system deployment.

Introduction to UEFI

BIOS has been in use for approximately 30 years. Even though it clearly has proven to work, it has some limitations, including:

  • 16-bit code

  • 1 MB address space

  • Poor performance on ROM initialization

  • MBR maximum bootable disk size of 2.2 TB

As the replacement to BIOS, UEFI has many features that Windows can and will use.

With UEFI, you can benefit from:

  • Support for large disks. UEFI requires a GUID Partition Table (GPT) based disk, which means a limitation of roughly 16.8 million TB in disk size and more than 100 primary disks.

  • Faster boot time. UEFI does not use INT 13, and that improves boot time, especially when it comes to resuming from hibernate.

  • Multicast deployment. UEFI firmware can use multicast directly when it boots up. In WDS, MDT, and Configuration Manager scenarios, you need to first boot up a normal Windows PE in unicast and then switch into multicast. With UEFI, you can run multicast from the start.

  • Compatibility with earlier BIOS. Most of the UEFI implementations include a compatibility support module (CSM) that emulates BIOS.

  • CPU-independent architecture. Even if BIOS can run both 32- and 64-bit versions of firmware, all firmware device drivers on BIOS systems must also be 16-bit, and this affects performance. One of the reasons is the limitation in addressable memory, which is only 64 KB with BIOS.

  • CPU-independent drivers. On BIOS systems, PCI add-on cards must include a ROM that contains a separate driver for all supported CPU architectures. That is not needed for UEFI because UEFI has the ability to use EFI Byte Code (EBC) images, which allow for a processor-independent device driver environment.

  • Flexible pre-operating system environment. UEFI can perform many functions for you. You just need an UEFI application, and you can perform diagnostics and automatic repairs, and call home to report errors.

  • Secure boot. Windows 8 and Windows 8.1 can use the UEFI firmware validation process, called secure boot, which is defined in UEFI 2.3.1. Using this process, you can ensure that UEFI launches only a verified operating system loader and that malware cannot switch the boot loader.

Versions

UEFI Version 2.3.1 is the version required for Windows 8 and Windows 8.1 logo compliance. Version 2.3.1C was approved in June 2012, which means that many machines need to upgrade their firmware to fully support the UEFI implementation in Windows 8.

Hardware support for UEFI

In regard to UEFI, hardware is divided into four device classes:

  • Class 0 devices. This is the UEFI definition for a BIOS, or non-UEFI, device.

  • Class 1 devices. These devices behave like a standard BIOS machine, but they run EFI internally. They should be treated as normal BIOS-based machines. Class 1 devices use a CSM to emulate BIOS. These older devices are no longer manufactured.

  • Class 2 devices. These devices have the capability to behave as a BIOS- or a UEFI-based machine, and the boot process or the configuration in the firmware/BIOS determines the mode. Class 2 devices use a CSM to emulate BIOS. These are the most common type of devices currently available.

  • Class 3 devices. These are UEFI-only devices, which means you must run an operating system that supports only UEFI. Those operating systems include Windows 8, Windows 8.1, Windows Server 2012, and Windows Server 2012 R2. Windows 7 is not supported on these class 3 devices. Class 3 devices do not have a CSM to emulate BIOS.

Windows support for UEFI

Microsoft started with support for EFI 1.10 on servers and then added support for UEFI on both clients and servers.UEFI support (x86 and x64):

  • Windows Vista SP1 x64 and later

  • Windows Server 2008 x64 and later

  • Windows 8 x86 and later

With UEFI 2.3.1, there are both x86 and x64 versions of UEFI. Windows 8.1 supports both. However, UEFI doesn’t support cross-platform boot. This means that a computer that has UEFI x64 can run only a 64-bit operating system, and a computer that has UEFI x86 can run only a 32-bit operating system.

How UEFI is changing operating system deployment

There are many things that affect operating system deployment as soon as you run on UEFI/EFI-based hardware. Here are considerations to keep in mind when working with UEFI devices:

  • Switching from BIOS to UEFI in the hardware is easy, but you also need to reinstall the operating system because you need to switch from MBR/NTFS to GPT/FAT32 and NTFS.

  • When you deploy to a Class 2 device, make sure the boot option you select matches the setting you want to have. It is common for old machines to have several boot options for BIOS but only a few for UEFI, or vice versa.

  • When deploying from media, remember the media has to be FAT32 for UEFI, and FAT32 has a file-size limitation of 4GB.

  • UEFI does not support cross-platform booting; therefore, you need to have the correct boot media (32- or 64-bit).

For more information on UEFI, see the UEFI Firmware overview and related resources.