Windows Vista Deployment Planning - Part 1
As promises - I will start to deep dive into the areas that I consider when working with clients on Windows Vista deployment projects...in Windows Vista Client Build and Deployment Process, I presented the diagram used when scoping deployment projects, so in this post I'll start discussing the process in more detail - starting with the Infrastructure Prerequisites section and the sub sections associated with this section. For each subsection I have listed the issues that you may want to consider and some details of requirements.
The Infrastructure Prerequisites section breaks down as follows:
Imaging and Deployment
For a production level imaging and deployment design, there are a number of factors:
Whether to re-use and integrate existing client deployment infrastructure components.
Whether to introduce new technologies introduced by Windows Vista, e.g. BDD 2007, ImageX and Windows System Image Manager.
What issues, if any, there are with the current imaging and deployment methodology.
New requirements.
Dependent on the results of the above, infrastructure additions could include the following items:
- System Management Server (SMS) 2005 SP3 plus the Operating System Deployment Feature Pack Update to allow for OS upgrades as well as bare metal installation (also known as ‘Zero Touch’).
- Business Desktop Deployment (BDD) 2007 and the Windows Automated Installation Kit (AIK) which includes tools such as ImageX, Windows System Image Manager, Package Manager and PE Image Manager.
- Windows Deployment Services (WDS). An upgrade to Remote Installation Services (RIS), WDS allows for PXE enabled clients to launch Vista installation environments ‘over the wire’.
Note that it may also be necessary to investigate a programmatic way of upgrading the BIOS on existing machines in order to take advantage of the Windows Vista BitLocker feature.
Windows Server 2003 Active Directory
Although Windows Vista will deploy to machines in legacy Windows NT4.0 domains and users that are currently deployed in both Windows NT 4.0 and Active Directory, this is not a scenario that Windows Vista has been designed for or tested in. There are major improvements in manageability, performance and productivity if using Windows Server 2003 Active Directory and Exchange Server 2003/2007.
BitLocker Drive Encryption
This section discusses critical steps to take in the current infrastructure before deploying Windows Vista with BitLocker. These configuration changes are not absolute requirements to use BitLocker, but in larger organisations, they enhance the ease of recoverability and better support users on computers running BitLocker.
Configuring Active Directory Domain Services For BitLocker
For recovery and support purposes, BitLocker can be configured to store recovery information in Active Directory. This configuration provides a centralised location for storing BitLocker recovery information so that help-desk support professionals can easily assist users whose computers are forced into recovery.
To store BitLocker recovery information in Active Directory, the schema is extended to support additional attributes. The implementation of Active Directory needs to meet the following minimum requirements to use these schema extensions:
¡ All domain controllers in the domain must be running Microsoft Windows Server 2003 SP1 or later.
¡ The account that is updating the schema should be a member of the Schema Admins group.
Note - If there are more than one Active Directory forests in the environment, there is a requirement to extend the schema in each forest that will host clients running BitLocker.
BitLocker stores two pieces of recovery information in Active Directory – Recovery Password Information and the TPM Owner Information. BitLocker Password Recovery Information is stored as a sub-object of the Computer object in Active Directory Domain Services. That is, the computer object is the container for the BitLocker recovery object. More than one BitLocker recovery object can exist for each computer object, because more than one recovery password can be associated with a BitLocker-enabled volume.
Each BitLocker recovery object has a unique name and contains a globally unique identifier (GUID) and a recovery password on a BitLocker-enabled volume. There can be multiple attributes stored under the BitLocker recovery information object if more than one recovery password has been created for a computer.
In terms of the TPM Owner Information, only one TPM owner password exists for each computer, and a hash of the TPM ownership password is stored as an attribute of the computer object in Active Directory Domain Services. The TPM owner information is stored as a Unicode string through the common name.
Table 1 and Table 2 below show the object and attributes that are created.
Item |
Type |
Common name |
BitLocker recovery information |
Object |
ms-FVE-RecoveryInformation |
Recovery password |
Attribute |
ms-FVE-RecoveryPassword |
Recovery GUID |
Attribute |
ms-FVE-RecoveryGuid |
Table 1 - BitLocker Active Directory Domain Services Objects and Attributes
|
|
|
|
| |
|
|
|
| ||
Table 2 - TPM Active Directory Domain Services Attributes
Security Changes to Active Directory
In addition to the extending the Active Directory Domain Services schema, security attributes to the new objects and attributes should be assigned by using the AddWriteACEs.vbs script located in the BitLocker Active Directory Deployment Pack. The script adds three access control entries (ACEs) to the top-level domain object.
|
|
|
|
| |
|
|
|
|
| |
|
|
|
|
| |
|
|
|
|
| |
Table 3 - BitLocker Active Directory Security
These permissions supplement the default permissions of the Active Directory computer object. If these permissions are not added, the computer will not be able to add the BitLocker recovery information to its computer object in Active Directory.
To further secure BitLocker recovery information, the schema extensions take advantage of the confidential flag feature of Active Directory in Windows Server 2003 SP1 and later. On a domain controller running Windows Server 2003 SP1 and later, Active Directory automatically applies the confidential flag included in the schema updates so that only domain administrators or appropriately delegated individuals have read access to the attributes that contain BitLocker and TPM recovery information. No further configuration is required.
For additional information, and a step-by-step guide to implementing and testing BitLocker schema changes, refer to the Active Directory for BitLocker and TPM Backup Setup Guide in the BitLocker Active Directory Deployment Kit.
Wired & Wireless Group Policy
Wireless and wired clients running Windows Vista support enhancements that can be configured through Group Policy settings. To support these enhancements, the Active Directory schema must be extended. Computers running Windows Vista support the following enhancements to Group Policy-based configuration:
¡ Wired LAN settings: Unlike Windows XP, Windows Vista now supports the configuration of IEEE 802.1X-authenticated wired connections through Group Policy.
¡ Mixed security mode: It is now possible to configure several profiles with the same SSID with different security methods so that clients with different security capabilities can all connect to a same wireless network.
¡ Allow and deny lists for wireless networks: It is now possible to configure a list of wireless networks to which the Windows Vista wireless client can connect and a list of wireless networks to which the Windows Vista wireless client cannot connect.
¡ Extensibility: It is now possible to import profiles that have specific connectivity and security settings of wireless vendors, such as different EAP types.
Table 4 outlines the schema attributes and attribute values that Active Directory uses for storing GUID and data relating to 802.11 wireless Group Policy.
Attribute |
Attribute Description |
ms-net-ieee-80211-GP-PolicyGUID |
unique identifier for the wireless GP object |
ms-net-ieee-80211-GP-PolicyData |
stores the wireless policy settings |
ms-net-ieee-80211-GP-PolicyReserved |
reserved for future use |
Table 4: Wireless Group Policy Attributes and Values – 802.11
Table 5 outlines the schema attributes and attribute values that Active Directory uses for storing GUID and data relating to 802.3 wired Group Policy.
Attribute |
Attribute Description |
ms-net-ieee-8023-GP-PolicyGUID |
a unique identifier for the wired GP object |
ms-net-ieee-8023-GP-PolicyData |
stores the wired policy settings |
ms-net-ieee-8023-GP-PolicyReserve |
reserved for future use |
Table 5: Wired Group Policy Attributes and Values - 802.3
Extending the Active Directory Schema
Before extending the schema, the following should be understood:
¡ Schema modifications are global. When the schema is extended, the changes apply to every domain controller in the entire forest.
¡ Schema classes related to the system cannot be modified. Default system classes (those classes required for Windows to run) cannot be modified within the schema. However, directory-enabled applications that modify the schema may add new classes that you can modify.
¡ Schema extensions are not reversible. Attributes or classes cannot be removed after creation. They can however be modified or deactivated.
¡ Document changes. If the decision is made to extend the schema, be sure to document the changes.
A simple way to avoid damaging or costly schema mistakes in a production forest is to first test the schema extensions in a test forest. By using a test environment, it is possible to identify any potential problems before they affect users in the production environment. After making schema changes in a test forest, it is possible to reinstall the default schema by demoting each domain controller in the test forest to which the schema changes have replicated. Then, the Active Directory Installation Wizard is used to reinstall Active Directory on the servers. This procedure is practical only in a test environment.
Group Policy Co-Existence
Microsoft Windows Vista and Windows Server 2008 introduce a new format for displaying registry-based policy settings. Registry-based policy settings (located under the Administrative Templates category in the Group Policy Object Editor) are defined using a standards-based, XML file format known as ADMX files. These new files replace ADM files, which used their own mark-up language. The Group Policy tools, Group Policy Object Editor and Group Policy Management Console, remain largely unchanged. In the majority of situations, the presence of ADMX files during day-to-day Group Policy administration tasks will not be noticed.
Unlike ADM files, ADMX files are not stored in individual GPOs. For domain-based enterprises, administrators can create a central store location of ADMX files that is accessible by anyone with permission to create or edit GPOs. Group Policy tools will continue to recognise custom ADM files you have in your existing environment, but will ignore any ADM file that has been superseded by ADMX files such as system.adm, inetres.adm, conf.adm, wmplayer.adm, and wuau.adm. Therefore, if any of the these files have been edited to modify existing or create new policy settings, the modified or new settings will not be read or displayed by the Windows Vista based Group Policy tools.
The Group Policy Object Editor automatically reads and displays Administrative Template policy settings from ADMX files that are stored either locally or in the optional ADMX central store. The Group Policy Object Editor will automatically read and display Administrative Template policy settings from custom ADM files stored in the GPO. You can still add or remove custom ADM files with the Add/Remove template menu option. All Group Policy settings currently in ADM files delivered by the Windows Server 2003, Windows XP, and Windows 2000 will also be available in Windows Vista and Windows Server 2008 ADMX files.
New Windows Vista–based or Windows Server 2008 based policy settings can be managed only from Windows Vista based or Windows Server 2008 based administrative machines running Group Policy Object Editor or Group Policy Management Console. Such policy settings are defined only in ADMX files and, as such, are not exposed on the Windows Server 2003, Windows XP, or Windows 2000 versions of these tools. An Administrator will need to use the Group Policy Object Editor from a Windows Vista based or Windows Server 2008 based administrative machine to configure a new Windows Vista Group Policy settings.
ADMX Files in a Current Environment
¡ Group Policy Object Editor on Windows Server 2003, Windows XP, or Windows 2000 machines will not display new Windows Vista Administrative Template policy settings that may be enabled or disabled within a GPO.
¡ The reporting function of GPMC on Windows Server 2003 and Microsoft Windows XP will display new Windows Vista Administrative Template policy settings as extra registry settings.
¡ The Windows Vista or Windows Server 2008 versions of Group Policy Object Editor and Group Policy Management Console can be used to manage all operating systems that support Group Policy (Windows Vista, Windows Server 2008, Windows Server 2003, Windows XP, and Windows 2000).
¡ Administrative Template policy settings that currently exist in ADM files from Windows Server 2003, Windows XP, and Windows 2000 can be configured from all operating systems that support Group Policy (Windows Vista, Windows Server 2008, Windows Server 2003, Windows XP, and Windows 2000).
¡ The Windows Vista or Windows Server 2008 versions of Group Policy Object Editor and Group Policy Management Console support interoperability with versions of these tools on Windows Server 2003, and Windows XP. For example, custom ADM files stored in GPOs will be consumed by Group Policy Object Editor and GPMC on Windows Vista, Windows Server 2008, Windows Server 2003, and Windows XP.
Windows Vista Licensing
There are a number of ways to licence Windows Vista in a production environment:
¡ Original Equipment Manufacturer (OEM).
¡ Multiple Activation Key (MAK).
¡ Key Management Server (KMS).
Multiple Activation Key (MAK)
MAK activation supports users whose computers are unable or rarely able to connect to the network. MAK activation behaves similarly to activation keys used by retail customers of Windows XP or Windows Server 2003, except that a single key is designed to support as many disconnected users as required (very large enterprises, however, may require or desire several MAK Keys). Like the earlier retail keys, computers must activate with a Microsoft server over the Internet or through a Microsoft call centre. Machines can be pre-activated by system administrators (using the Volume Activation Management Tool) or they can be set to activate automatically. Either pre-activation or automatic activation is required for computers that are heavily locked down, since manual activation requires a user to have administrative privileges.
Additional information on MAK can be found in the Volume Activation 2.0 Step-By-Step Guide
Key Management Server (KMS)
Key Management Server (KMS) usage is targeted to managed environments where more than 25 physical computers regularly connect to the organisation’s network. Windows Vista computers activate themselves only after verifying that the required threshold of computers has been met.
A KMS service has a minimum count of 25 Windows Vista physical machines or a count of 5 Windows Server 2008 physical machines before each operating system type can activate itself after contacting the KMS.
Systems activated with KMS periodically renew their activations with the KMS machine. If they are unable to connect to a KMS machine for more than 180 days, they enter a 30-day grace period, after which they enter Reduced Functionality Mode (RFM) until a connection can be made with a KMS machine, or until a MAK is installed and the system is activated online or via telephone. This feature prevents systems that have been removed from the organisation from functioning indefinitely without adequate license coverage. Systems operating in virtual machine (VM) environments can be activated using KMS but do not contribute to the count of activated systems.
Note - KMS clients that have not yet been activated will attempt to contact a KMS machine every two hours, by default. Once activated, they will attempt to renew their activation every seven days, by default.
Advantages of KMS activation include automatic activation with little or no IT intervention, use of a single product key to activate and reactivate all systems, no Internet connection requirement (after the KMS machine has been activated), low network bandwidth use, and reporting made available through use of an available MOM pack. Drawbacks include the requirement to set up the KMS infrastructure and the potential manual effort that may be required if dynamic DNS is not available.
KMS machines can automatically advertise their presence through the use of Domain Name System (DNS) service (SRV) resource records. Organisations using dynamic DNS will enjoy automatic registration and resolution of KMS machines with no administrative intervention. Microsoft DNS and Berkeley Internet Name Domain (BIND) Version 8.x and later support dynamic DNS and SRV resource records.
Note - Some efficiency can still be achieved by using a single host name for manual KMS registration and then by using the round-robin capabilities of DNS to load balance two or more KMS machines from the same hostname.
KMS can be installed on machines running Windows Vista, Windows Server 2003 (See Note) or on systems running Microsoft Windows Server 2008.
Note - Microsoft will support KMS running natively under Windows Server 2003 by the end of 1H 2007.
A KMS can scale to hundreds of thousands of KMS clients per server. Most organisations can operate just two KMS machines (for redundancy) for their entire infrastructure. Additional information on KMS can be found in the Volume Activation 2.0 Step-By-Step Guide
Migration Requirements
For the purposes of the user’s migration to Windows Vista it would necessary to provide a means to facilitate the transfer of user’s personal data from the ‘old machine’ or Operating System environment to the ‘new machine’ or Windows Vista (whilst understanding that old and new machines may be the same physical machine).
One possible way of achieving this would be to provide a migration server(s) with sufficient disk storage to house user’s data temporarily. User’s data could be held on the server for a pre-defined period of time and then archived in readiness for the next Business Unit to be migrated. Microsoft’s User State Migration Tool (USMT) can be utilised to harvest user data and settings from machines prior to migration to Windows Vista and re-apply those user data and setting post installation. Additional information on USMT 3.0 can be found in the User State Migration Tool Guide
Management & Operations
You may wish to consider using System Center Operations Manager (MOM) 2007 to manage the Windows infrastructure components. Due for release in early 2007, System Center Operations Manager 2007 will provide desktop monitoring for Windows Vista with agentless exception monitoring, plus will supply a management pack for Windows Vista clients.
Patching and Updates
Due to Software Update Service (SUS) becoming un-supported after 6th December 2006, you should plan to migrate to Windows Server Update Services (WSUS) in the near term. To support Windows Vista, you should upgrade to WSUS 2.0 Service Pack 1 which will support both Release Candidate and Release to Manufacturer (RTM) versions or WSUS 3.0. WSUS 3.0 Beta 2 is currently available and delivers new features that enable administrators to more easily manage and deploy updates across the organisation. WSUS 3.0 Beta 2 benefits include a new MMC-based user interface with advanced filtering and reporting, improved performance and reliability, branch office optimisations and reporting rollup, and a Microsoft Operations Manager management pack.
If WSUS 3.0 is chosen for deployment then please note that Beta 2 does not support Windows Vista without an additional patch available from Microsoft. This patch will not work with post-RC builds or RTM. WSUS 3.0 RC will be the first release of WSUS3 that will support Windows Vista RTM. WSUS 3.0 is expected to RTM in 1H2007.
Anti-Virus
Anti-Virus products must be Windows Vista compatible. Previous versions of anti-virus products designed for earlier versions of Windows will not function on Windows Vista. This requirement may also need to consider changes to anti-virus infrastructure such as update points and management servers to align with newer Windows Vista compatible versions.
Information Rights Management
Although not directly related to either Windows Vista or Office 2007, you may like to consider the implementation of Microsoft Windows Information Rights Management Services (IRM) for Windows Server 2003. IRM is information protection technology that works with IRM-enabled applications such as Office 2007 and browsers such as Internet Explorer 7.0 to help safeguard digital information from unauthorised use - both online and offline, inside and outside of the firewall.
IRM could augment corporate security strategy by protecting information through persistent usage policies, which remain with the information, no matter where it goes. a company could use IRM to help prevent sensitive information, such as financial reports, product specifications, customer data, and confidential e-mail messages, from intentionally or accidentally getting into the wrong hands.
The manner in which you set up your infrastructure depends on the system requirements for the installation of IRM, as well as best practices for setting up your infrastructure. As a minimum, the basic server-side environment required to support IRM is a Windows Server 2003 Active Directory domain controller, a database server, e.g. SQL and an IRM server configured as a root certification server.
Network Infrastructure
The network infrastructure must be adequate to support the deployment of the client and the ongoing packaged software distribution. To support the deployment of the client, there may be a requirement to increase the bandwidth supplied. This may be due to an increased usage of the core applications, such as email and browser technology and/or automated software deployment requirements and build image replication.