Richard Smith : Deployment Process

Windows Vista Deployment Planning - Part 3

ricsmith — Fri, 23 Nov 2007 16:07:10 GMT

In Windows Vista Client Build and Deployment Process, I presented the diagram that I use when scoping deployment projects, so in this post I'll continue discussing the process in more detail - previous posts have covered Infrastructure Prerequisites and Client requirements. In part 3 of this series, I will consider Application Compatibility.

Before starting down the application compatibility testing and remediation route, it is worth considering where the application compatibility issues will arise. From experience this usually falls into two distinct areas that Windows Vista introduces - security enhancements and operating system changes and innovations.

The following new security enhancement features in Windows Vista may cause compatibility issues with applications:

User Account Control provides a method of separating standard user privileges and tasks from those that require administrator access. UAC increases security by improving the computer experience for users running standard user accounts. Users can now perform more tasks and enjoy higher application compatibility without the need to log on to their client computers with administrative-level privileges. This helps reduce the affect of malware, unauthorised software installation, and unapproved system changes. UAC can introduce problems in applications that are not compliant with this technology enhancement. For this reason, it is important to test applications with UAC enabled before you deploy them. For more information about application compatibility testing, see the BDD Application Compatibility Feature Team Guide.
Windows Resource Protection is a new feature in Windows Vista that helps safeguard system files and protected registry locations to help improve the overall security and stability of the operating system. Most applications that previously accessed or modified these locations are automatically redirected to temporary locations, which they can then use to continue to operate without issues. However, applications that require full access to these protected areas and cannot handle the automatic redirection process will not operate properly with Windows Vista. In these cases, the applications must be modified so that they function as intended.
Protected Mode is a new feature of Microsoft Internet Explorer 7 that helps to protect computers running Windows Vista from the installation of malware and other harmful software by running the browser with lower, more secure rights. When Internet Explorer is in Protected Mode, the browser can only interact with very specific areas of the file system and registry. Although Protected Mode helps maintain the integrity of client computers running Windows Vista, it can affect the operation of older Internet and intranet Web applications. Such Web applications may need to be modified to run them in a more restrictive Internet Explorer 7 environment.

The following operating system changes and innovations in Windows Vista may cause compatibility issues with applications:

Application programming interfaces (APIs) expose layers of the Windows Vista operating system differently than in previous versions of Windows. Antivirus and firewall software are examples of applications that rely on these new APIs to properly monitor and safeguard Windows Vista. Applications that perform these functions need to be upgraded to versions that are compatible with Windows Vista.
16-bit applications and 32-bit drivers are not supported in the Windows Vista 64-bit environment. Automatic registry and system file redirection is not available for the 64-bit environment. For these reasons, new 64-bit applications must comply with the full Windows Vista application standards.
Many older applications check for specific versions of Windows. When third-party applications cannot detect a specific operating system version, many of them stop responding.

The Windows Vista Developer Story: Application Compatibility Cookbook on MSDN provides additional information about the security enhancements and operating system changes and innovations in Windows Vista. The cookbook also provides test approaches and possible remedies for many of the compatibility issues that may be encountered.

Now that we have considered the main areas where application compatibility issues arise, we can consider how the application compatibility testing and remediation will fit into our project process.

Applications Compatibility Testing

The ability to create standardised MSI packages, the introduction of packaging procedures, and a central application database, are the building blocks for many of the new features that can be enabled as part of a Windows Vista deployment project. They also serve other initiatives such as active patching and asset management. In most cases companies will adopt an industry standard, centralised packaging system at the very least.

If this is the case, I recommend using the Microsoft Application Compatibility Toolkit (ACT) 5.0 to aid in the application migration onto the Windows Vista platform. ACT provides a platform to carry out discovery and remediation work and tends to be used by application owners and developers. ACT makes it easier to introduction testing and remediation within a current packaging process.

With ACT in use, the remediation effort should be folded in as part of a packaging workflow. The way that this tends to work is that on entering the packaging workflow, applications are evaluated against known issues using ACT. This will give an early view of applications that will need further investigation, or those that have standard fixes already documented. Additional information on ACT 5.0 can be found in Microsoft TechNet

Application Remediation

Changes to an operating system, whether it be a minor change such as a service pack update or as major change such as a migration to a new version requires a significant amount of planning in terms of application remediation. The level of application remediation for these changes is often underestimated due to a lack of pertinent or accurate information. I often advise clients to analyse the entire application portfolio to determining the effort required to ensure the applications will operate correctly when run on Windows Vista.

Application remediation can then fall into a number of areas, from simple shims that enable the application to run without change on Windows Vista to complete re-design and re-writing of an application by in-house developers of the software vendor responsible for the application.

There are also additional Microsoft technologies that can be used to address application compatibility issues that might take some time to fully resolve. These technologies are designed to help migrate to Windows Vista, and continue to run business critical applications that are not compatible with Windows Vista. These technologies include the following:

Virtual PC 2007 can be used to run applications on Windows Vista that only work properly with older versions of Windows. Virtual PC lets users keep a previous version of Windows available to run non-compatible applications within their Windows Vista environment until upgraded versions of non-compatible applications are developed.
Terminal Services for hosting applications provides hosting and delivery of Windows-based applications, or the Windows desktop itself, to virtually any computing device on the network. Windows Vista clients can connect to these application-hosting environments through Remote Desktop to access older applications.
Virtual Server for hosting applications allows the hosting of legacy applications and allows remote connectivity from end users who need access to those applications. In conjunction with Windows Server 2003, Virtual Server 2005 R2 provides a virtualisation platform that runs most major x86 operating systems in a guest environment, and is supported by Microsoft as a host for Windows Server operating systems and Microsoft Windows Server System applications.
Microsoft SoftGrid is an application virtualisation solution that delivers applications that are never installed, yet securely follow users anywhere, on demand. SoftGrid is comprised of the SoftGrid platform, an engine that turns applications into centrally managed virtual services that are delivered on-demand.

Applications Delivery and Installation

An application delivery and installation mechanism that I tend to favour uses a tiered application delivery process. I tend to recommend four tier levels that can be used to categorise applications.

The first tier (Tier 1) are applications that are included as part of the core image.

I then consider the other applications to be non-core lines of business applications falling into the other three tiers (tier 2, 3 or 4) which will not be included as part of the core build image. These Line of business applications are catagorised into the remaining three tiers as follows:

Tier 2 Applications – Applications that are delivered via the web browser
Tier 3 Applications – Applications that are delivered via SMS or another management platform
Tier 4 Applications – Applications that are exceptions

Tier 4 usually contains legacy line of business applications that cannot be delivered to users via the browser and will not run under Windows Vista. These will need to be managed as exceptions. The management of exceptions should be ongoing and non-compliant software must be considered for redesign, terminal server use, SoftGrid delivery, Virtual PC/Server delivery or retirement.

The diagram below shows the conceptual design for application delivery based on the four tier idea.

2007 Office System

Although rolling out 2007 Office System as part of a Windows Vista deployment project is common in the customers I work with, there are some things to consider. Although not directly tied to application compatibility, there is a link because many companies use Office as the core of their productivity tool set and because of changed in 2007 Office System, there will be compatibility and remediation work to carry out. Some of this compatibility and remediation work will be technical issues (file formats and extensibility of 2007 Office System) while others are based around user education.

For 2007 Office System inclusion in a Windows Vista deployment project, you should consider:

The 2007 Office System has a completely new user interface for Word, Excel and PowerPoint applications with the traditional menu bar being replaced by the “ribbon”. The redesign makes the whole user experience more intuitive, graphical and contextualised by completely rationalising the interface. In addition, there are new features available within the clients such as the new Smart Art graphical features that users of previous versions will not be familiar with. The Office 2007 client has the potential to be a valuable tool in business optimisation and personal productivity.
The Office 2007 file format is a departure from the binary format in previous versions of Office and is based upon XML technologies. Although this provides a number of benefits, an initiative to manage the conversion to the new File Format is required. Patches are available for previous versions of Office (Office 2000 and above) that will provide a level of flexibility in that all users will be able to view and edit documents saved in the new file format from older versions of Office.
In terms of co-existence, users will need to understand what capabilities are tied to the new Office 2007 client, for example, Smart Art functionality cannot be modified within Office 2000. Therefore extra consideration will need to be taken into account when authoring content with regard to who is potentially going to modify or update the documents once they have been distributed. Also, for documents that are to be made available externally, they may need to be saved in the old binary format in order for others to be able to contribute and collaborate on the content.
Office 2007 clients are fully extensible and Visual Studio Tools for Office (VSTO) provides a mechanism for such customisation and extensibility. One of the main areas of customisation will involve the new Ribbon. The customisation of the Ribbon is based on a declarative model, using XML supported by an object model to develop against. This approach simplifies development and allows for more rapid extensions of the core clients. This allows for the creation of tabs, customisation of built-in tabs, additions to the File Menu, additions to the contextual tabs and the possible removal of tabs, groups and controls. Third party vendors who integrate into the Office 2007 client will can carry out their integrations as extensions to the ribbon interface.

TOOLS

The following are freely available tools that are useful in application compatibility testing processes.

ACT 5.0.2

Windows Vista Hardware Assessment

Microsoft Office Migration Planning Manager

The Windows Vista Developer Story: Application Compatibility Cookbook

BDD Application Compatibility Feature Team Guide

Moving from RIS to Windows Deployment Services (WDS)

ricsmith — Fri, 23 Nov 2007 14:44:05 GMT

I wanted to point you in the direction of a document that helps with moving from Remote Installation Services (RIS) to Windows Deployment Services (WDS) on Windows Server 2003.

Many of the clients that I consult for are big RIS users, so this whitepaper has been especially useful in recent months as they have moved to deploying Windows Vista...

You can download it from the link below:

Deploying and Managing the Windows Deployment Services Update on Windows Server 2003

Microsoft Product Evals on Virtual Hard Disk

ricsmith — Mon, 12 Nov 2007 14:00:00 GMT

I am often asked why deployment is such a great place to work as a consultant and I usually answer by saying that deployment (both client and server) touches all aspects of the infrastructure and therefore you need a knowledge across many products. All though I think this is a great thing - it also means that you have to keep up with other technologies - and have them set up in a test environment for your deployment engagements.

I often setup small proof of concept labs for customers - and I make us of a lesser known Microsoft service that provides many products ready configured as time limited Virtual Hard Disks (VHD) ready for download - over the months I have created a library of these that I can set up and leave at customer sites for time limited testing (usually 30 day evaluations). Below are the links to all of the products that we supply as VHD:

BizTalk Server 2006

Exchange Server 2007

Exchange Server 2007 SP1 Beta 2

ISA Server 2006

Microsoft Office 2007 Professional

Office SharePoint Server 2007

SQL Server 2005

SQL Server 2005/Exchange 2007

System Center Configuration Manager 2007

System Center Essentials 2007

System Center Virtual Machine Manager 2007

Visual Studio 2005 Team Suite

Visual Studio 2005 Team System

Windows Server 2008 Beta 3

Windows Server 2003 R2

Windows Vista

Search Server 2008 Express

Hopefully this set of server and client pre-configured virtual machine hard disks will save you endless setup hours and also enable you to start configuring in other services to your deployment engagements.

Deployment 4 - Using Your BDD 2007 Task Sequences as Templates

ricsmith — Tue, 02 Oct 2007 18:29:40 GMT

So - Deployment 4 Beta 3 - very cool indeed...but I bet your thinking "how can I use the task sequences that I built in BDD 2007 as templates in Deployment 4 Beta 3?" - well that's a good question.

Deployment 4 Beta 3 stores it's task sequence templates in the Program Files\Deployment 4\Templates folder and come with three templates ready configured:

Client.xml
ClientReplace.xml
Server.xml

You can add you own templates to this directory by creating new task sequences in the Deployment 4 Beta 3 Workbench or by copying you task sequences from BDD 2007. In the example below, I have copied two XML files (TS.vista.xml and TS.xp.xml) to the Program Files\Deployment 4\Templates location that I had previously configured in BDD 2007.

We now need to update the headers in our newly copied task sequences to give them a descriptive name. This is because BDD 2007 names all task sequences as SA Task Sequence. Open each task sequence file in your favourite XML editor and change the Name and Description tags to give your files descriptive names (you will see why shortly)

Now that our templates are configured and in the correct location it just a case of creating a new task sequence based on our newly added template files. Open Deployment 4 Beta 3 and right click Task Sequence - choose NEW to start the New Task Sequence Wizard and give your new task sequence an ID, Name and Comments on the General Settings page:

On the Select Template page, the drop down should now show your new templates with the names as edited earlier, which you can now select to create the starting point for your new task sequence.

Once the wizard has completed you will have a new task sequence based on your imported file from BDD 2007 which is now a re-usable template in Deployment 4 Beta 3.

You can use this process to add as many templates as you need for your environment - you may want to merge some of the new task sequences from Deployment 4 Beta 3 with your BDD 2007 task sequences to ensure that you are taking advantage of some of the tasks delivered in Deployment 4 Beta 3 such as network card and disk configuration (see Ben's blog for more on this...). You will also need to ensure that any scripts, applications and custom code referenced in your BDD 2007 task sequencer are copied across to the Deployment 4 environment so that the tasks can find them.

For more information, check out Bens article on How to Create a Custom Task Sequence for some other great hints and tips on Deployment 4 Beta 3 task sequences and Michael Niehaus is running a great set of blogs on Deployment 4 Beta 3 New Features.

Disabling the Network Location Prompt

ricsmith — Tue, 25 Sep 2007 16:39:06 GMT

Over the past few months, many of the clients I have been working with have started deploying Windows Vista into their environment. One thing that commonly crops up is that the Windows Vista Network Location prompt fires up on all newly built machines asking for the network type that the machine is connected to (Home, Work or Public).

It doesn't harm the build or deploy process and can usually be ignored - it will just sit in the background and wait for input or machine shutdown, however a more elegant solution is to stop it appearing. The easiest way to do this is to this is by adding a RunSynchronousCommand to RunSynchronous section in the x86_Microsoft-Windows-Deployment_neutral block in the specialize phase of your unattend.xml file... :-)

If you are using BDD 2007, the unattend file created by BDD will have three RunSynchronous commands already configured in this section - to enable the local administrators account (two commands) and to un-filter the local administrators token. These are listed as EnableAdmin, EnableAdmin_PLOC and UnfilterAdministratorToken and are ordered as 1, 2 and 3.

To stop the Network Locator Prompt from appearing add a fourth RunSynchronous command to RunSynchronous block (specialize) with the following details:

In the Description field, enter something to identify the task - like "DisableNetworkLocationPrompt".
In the Order field enter 4 (if you are editing the BDD 2007 created unattend.xml file) or 1 if it is your first RunSynchronous command.
In the Path field enter the command line (as one complete line)

reg add "HKLM\SOFTWARE\Policies\Microsoft\Windows NT\CurrentVersion\NetworkList\Signatures\FirstNetwork" /v Category /t REG_DWORD /d 00000001 /f

In the WillReboot field enter Never

When this command runs as part of the build or deploy process, the Network Location Prompt will be suppressed.

Note: You will probably want to turn this back on after the build or deploy process has been completed, as this tool provides the user with a friendly way of configuring the Windows Firewall to protect them in a number of differing network locations. You may want to consider running a VB Script to reset the registry key and turn the Network Location Prompt back on from the BDD 2007 task sequence as one of the final tasks in your build or deploy process.

New Deployment Forum Site...

ricsmith — Tue, 18 Sep 2007 12:44:00 GMT

Deployment Forum is a new community Web site devoted to IT professionals deploying Windows. Myself and fellow MCS blogger Ben Hunter, as well as MCS architect Steve Campbell have taken up residency in the MVP section with a selection of the industry's best deployment specialists and we will all be adding content to the Deployment Forum. The site is run by Jerry Honeycutt, a well respected writer, speaker, and technologist who has written more than 30 technology books and hundreds of technical articles and white papers.

You find Deployment Forum at: http://www.deploymentforum.com

Deployment 4 Beta 3 Released

ricsmith — Mon, 17 Sep 2007 11:39:00 GMT

The BDD team have announced that Deployment 4 (the code name for the next version of Business Desktop Deployment (BDD) 2007) has been released as BETA 3 and unifies the tools and processes required for desktop and server deployment into a common deployment console and collection of guidance. Previously referenced as BDD.Next and Windows Server Deployment (WSD), Deployment 4 adds integration with recently released Microsoft deployment technologies to create a single path for image creation and deployment, including:

System Center Configuration Manager 2007 Operating System Deployment
Windows Automated Installation Kit
Windows Deployment Services with new multicast technology
Application Compatibility Toolkit 5.0
User State Migration Tool 3.0.1
Windows Server 2008 Server Manager for automated server role definition (coming soon)

Deployment 4 Beta 3 combines the guidance and toolset from previous releases of Business Desktop Deployment and Beta releases of Windows Server Deployment. This release continues to support Zero Touch Installation (ZTI) of desktop operating systems using Systems Management Server (SMS) 2003 with the Operating System Deployment Feature Pack and adds new deployment and task sequencing capabilities for desktops and servers using System Center Configuration Manager 2007. Deployment 4 also continues to provide Lite Touch Installation (LTI) support without infrastructure requirements and adds capabilities for Windows Server 2003 and pre-release versions of Windows Server 2008.

New features in Deployment 4 Beta 3

Microsoft System Center Configuration Manager 2007 support, with the following features:
- Full support for Windows Vista, Windows XP, and Windows Server 2003 deployments with Deployment 4 and Configuration Manager 2007.
- Complete integration into the Configuration Manager 2007 admin console and task sequencing capabilities.
  - Quick start Configuration Manager 2007 operating system deployments using one wizard to create needed task sequences and packages.
  - Extends the Configuration Manager 2007 task sequencing capabilities with new actions.
- Feature parity with BDD 2007 and SMS 2003, including dynamic package installation, automatic determination of state store location, computer backup, database settings.
Lite Touch Installation (LTI) support for Windows Server 2008:
- Support for deploying Windows Server 2008 Beta 3 and potentially RC0 (to be verified after RC0 release), including support for Server Core installation options. (Windows Server 2008 TAP customers only.)
Lite Touch Installation (LTI) enhancements:
- Enhanced disk and network interface cards (NICs) configuration options, including support for static TCP/IP configuration.
- Design changes to ease the migration from LTI to Configuration Manager 2007.
- Support for multiple task sequence templates. New sample templates include:
  - Client template: Windows Vista, Windows XP
  - Server template: Windows Server 2003, Windows Server 2008
  - Replace scenario template
- Ability to invoke web service calls Support for web service calls from rules
  - Web services can be invoked as part of the rules processing performed by Deployment 4, using new rules that can be defined in CustomSettings.ini.
- Support for side-by-side installation with Deployment 4 and BDD 2007 installed on the same machine.
Lite Touch Installation (LTI) multicast support:
- Deployment Workbench supports multicast transmission of operating system images when performing LTI deployments from Windows Server 2008 servers that are running Windows Deployment Services.

Where to Find Deployment 4 Beta 3

Deployment 4 Beta 3 is available as an open beta download.

To join Deployment 4 beta 3 program, follow these steps:

Visit the Microsoft Connect Web site (http://connect.microsoft.com).
Click Invitations on the Connect menu.
You will need to sign in using a valid Windows Live ID before you can continue to the Invitations page.
Enter your Invitation ID in the box. Your invitation ID is: BDDP-QMYH-VWTH
Click Go.
If you have not previously registered with Microsoft Connect, you might be required to register before you continue with the invitation process.
To download Deployment 4, click Download Now.

Great work from the team getting this release out...

Windows Vista Deployment Planning - Part 2

ricsmith — Wed, 12 Sep 2007 19:24:00 GMT

Back in July, I started a series of articles on Windows Vista Deployment Planning, and in Windows Vista Deployment Planning - Part 1 I shared with you details of Infrastructure Prerequisites that need to be considered when deploying Windows Vista in an enterprise environment. In Windows Vista Client Build and Deployment Process, I presented the diagram used when scoping deployment projects, so in this post I'll carry on discussing the process in more detail - this time considering the Client Hardware section. My hope is that these pieces will build up into a complete deployment planning document that you can use in your own projects.

The Hardware for Windows Vista deployment projects in which I have worked are usually defined across a number of levels but can usually be simplified into three categories - High-end Desktop, Standard Desktop and Laptop. These categories define a base set of hardware components, as listed below, along with a refresh interval.

The table above can be used to detail the minimum specifications for deployment and the hardware platform and this should be reviewed every six months to maintain the equivalent position on the technology curve.

The fact that a deployment project is taking place usually means that companies will set the specification to a position closer to the top of the technology curve than is currently the practice within that company This is to ensure that the equipment continues to be useful for the duration of its working life (defined by the company refresh cycle) throughout the inevitable changes of the software configuration.

However - you may consider a new feature introduced with Windows Vista as an alternative to specifying hardware specifications, the Microsoft WINSAT performance utility which can be used to determine acceptable performance criteria for a particular hardware platform. This tool will allow you to define exact benchmark performance statistics, rather than having a minimum specification of hardware. Examples of this would include:

Graphics Processor Sub-System.
Memory Performance.
CPU Performance.
I/O Throughput.

These statistics measured are combined to produce an overall score. This score can then be given to the hardware vendor in order for them to recommend a platform than can meet the scores criteria. Additional Information on the WINSAT Performance Utility can be found in Microsoft TechNet

Windows Vista Deployment Planning - Part 1

ricsmith — Mon, 23 Jul 2007 02:30:00 GMT

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

Item	Type	Common name

TPM owner password—hash	Attribute		ms-TPM-OwnerInformation

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.

Common name	Type		Group	Permission
ms-TPM-OwnerInformation		Attribute	Authenticated Users	Write
ms-FVE-RecoveryInformation		Object	Authenticated Users	Create—Child Objects
ms-FVE-RecoveryInformation		Object	Authenticated Users	Write—All Properties

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 6^th 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.

Windows Vista Client Build and Deployment Process

ricsmith — Thu, 05 Jul 2007 11:05:00 GMT

I often get asked about the process I go through when working with clients on deployment projects - I find that building a corporate client image that meets the needs and requirements of a large organisation follows a distinct process. All aspects of the client and deployment design including hardware compatibility, user experience, look and feel, locality support, language support, security testing, application testing image certification and final deployment are delivered as elements within a project. So i put together the diagram below that outlines the areas that I consider when working with clients on Windows Vista deployment projects.

Over the coming weeks, i'll be discussing each section in more detail with a hope that this will help with your own deployment projects