Richard Smith : Build 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.

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

How drivers are added to Windows PE and Windows Vista during an unattended installation

ricsmith — Wed, 15 Aug 2007 15:15:00 GMT

My MCS colleague and top deployment gent - Mark Aslett has put together a handy process list for how device drivers are added to Windows PE and Windows Vista during deployment. The example below assumes than an unattend.xml file is being used to specify the location of drivers in both the windowsPE pass and the offlineServicing pass of the unattend.xml file.

If peimg is used to inject drivers directly into an offline Windows PE image then this fully installs the drivers, i.e. it performs the registry load, hardware ID and service information reflection, etc, and does not significantly delay the Windows PE boot or Vista deployment times.

BDD 2007 gets around most of the issues around deployment time identified above. When BDD creates the Windows PE boot image it will add any drivers that you specify at image creation time, so there is no need to use the windowsPE pass (or peimg to add drivers directly). BDD 2007 uses the offlineServicing pass for driver injection avoiding the bulk of the delays. It also has the added benefit of only copying across the drivers required instead of the entire driver store.

Big thanks to Mark for sharing his findings...

General Purpose CustomSettings.ini

ricsmith — Thu, 02 Aug 2007 16:11:00 GMT

One thing that seems to stump a number of people with BDD 2007 is using the CustomSettings.ini file (accessible via the Rules tab) to automate the deployment wizards. The usual issues are around differing language settings for Windows XP and Windows Vista, as well as turning off and on the relevant wizards.

The customsettings.ini file below is a general purpose one that I tend to use as the starting point for most engagements - it has most of the wizard entries (currently set to NO so that they all show) as well as the UK specific language settings for Windows XP and Windows Vista and UK time zone - for the languge settings, just comment out the ones not used (Windows Vista or Windows XP) and turn off the wizards you dont need - remember that any wizards turned off usually need additional parameters to be entered in customsettings.ini for the options they are requesting...

[Settings]
Priority=Default
Properties=MyCustomProperty

[Default]
OSInstall=Y

SkipApplications=NO
SkipAppsOnUpgrade=NO
SkipProductKey=NO
SkipDeploymentType=NO

SkipDomainMembership=YES
JoinWorkgroup=WORKGROUP

SkipAdminPassword=NO
AdminPassword=P@ssw0rd

SkipLocaleSelection=YES

; VISTA LOCALE SETTINGS
KeyboardLocale=en-gb
UserLocale=en-gb
InputLocale=0809:00000809

; XP LOCALE SETTINGS
;InputLocale=0809:00000809
;UserLocale=0809:00000809

SkipTimeZone=YES
TimeZone=85
TimeZoneName=GMT Standard Time

SkipCapture=NO
DoCapture=NO

SkipUserData=NO
UserDataLocation=NONE

Addational information on these settings can be found in the Deployment Configuration Guide located in the documentation directory included with BDD 2007 (usually Program Files\BDD 2007\Documentation)

WMI Tags for Task Sequencer Logic

ricsmith — Wed, 01 Aug 2007 17:42:00 GMT

One of the things that I am often required to obtain for customers are certain WMI tags so that we can write task sequence IF statements and provide the build process with some logic. Gathering these WMI tags can be tricky, so we put together a VB Script to pull out the 10 most popular items and display them to the screen - we also copy the results to a file called sysinfo.txt. By running this file on the machines that will be built, we can ensure that we use the correct WMI entries for things like MANUFACTURER, MODEL and CHASIS.

The scipt (sysinfo.vbs) is listed below and is a variation on the script used by BDD to gather information at the start of the build process:

' Initialization
Set fso = CreateObject("Scripting.FileSystemObject")
Set shell = CreateObject("Wscript.Shell")
Set reg = GetObject("winmgmts:root\default:StdRegProv")
Dim sOutput

On Error Resume Next

' Create the appropriate OS information
For each os in GetObject("winmgmts:").InstancesOf("Win32_OperatingSystem")
   If Instr(1,os.caption,"XP") <> 0 then Call makefile("OS = XP")
   If Instr(1,os.caption,"2000") <> 0 then Call makefile("OS = WIN2000")
   If Instr(1,os.caption,"2003") <> 0 then Call makefile("OS = WIN2003")
   If Instr(1,os.caption,"NT") <> 0 then Call makefile("OS = NT4")
   If Instr(1,os.caption,"2000 Server") <> 0 then Call makefile("OSTYPE = SERVER")
   If Instr(1,os.caption,"Advanced Server") <> 0 then Call makefile("OSTYPE = ADVANCED")
   If Instr(1,os.caption,"Professional") <> 0 then Call makefile("OSTYPE = PRO")
   If Instr(1,os.caption,"Standard") <> 0 then Call makefile("OSTYPE = STANDARD")
   If Instr(1,os.caption,"Enterprise") <> 0 then Call makefile("OSTYPE = ENTERPRISE")
   If Instr(1,os.caption,"Web") <> 0 then Call makefile("OSTYPE = WEB")
   If os.ServicePackMajorVersion <> "" then
      Call makefile("OSSP = " & os.ServicePackMajorVersion)
   Else
      Call makefile("OSSP = NONE")
   End if
Next

' Obtain the enclosure type
for each Enclosure in GetObject("winmgmts:").InstancesOf("Win32_SystemEnclosure")
   if join (Enclosure.Tag)<>"System Enclosure 1" then
      CaseType = Enclosure.ChassisTypes(0)
   end if
next
Select case CaseType
Case "3", "4", "5", "6", "7", "15"
     Call makefile("CHASSIS = " & "DESKTOP")

Case "8", "10", "12", "14", "18", "21"
Call makefile("CHASSIS = " & "LAPTOP")

Case "23"
Call makefile("CHASSIS = " & "SERVER")

Case ELSE
Call makefile("CHASSIS = " & "OTHER")
End Select

' Since there is no good way to identify a Tablet PC except by using an API call (GetSystemMetrics),
' cheat and use a well-known registry location.
Err.Clear
ver = shell.RegRead("HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Tablet PC\Ident")
If Err then
' Not a tablet
Else
Call makefile("OSTYPE = TABLET")
End if

' Obtain the HAL that is being used
halID = shell.RegRead("HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Class\{4D36E966-E325-11CE-BFC1-08002BE10318}\0000\MatchingDeviceId")
halName = shell.RegRead("HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Class\{4D36E966-E325-11CE-BFC1-08002BE10318}\0000\DriverDesc")
'Wscript.Echo "HAL ID=" & halID
'Wscript.Echo "HAL Name=" & halName
Call makefile("HALID = " & halID)
Call makefile("HALNAME = " & halName)

' Obtain the manufacturer and model
For each os in GetObject("winmgmts:").InstancesOf("Win32_ComputerSystem")
   If Instr(1,os.Manufacturer," ") <> 0 then
      Manu=Left(os.Manufacturer,(instr(1,os.Manufacturer," "))-1)
   else
      Manu=os.manufacturer
   end if
   Call makefile("MANUFACTURER = "&manu)
   Call makefile("MODEL = "&os.model)
Next

' Get the CD/DVD information
x = 0
CD = false
DVD = false
For each os in GetObject("winmgmts:").InstancesOf("Win32_CDROMDrive")
   x = x + 1
   If Instr(1,UCASE(os.name),"RW") <> 0 then Call makefile("CDROM-RW")
   If Instr(1,UCASE(os.name),"DVD") <> 0 then
      DVD = true
   ElseIf instr(1,UCASE(os.name),"DV")<>0 then
      DVD = true
   ElseIf instr(1,UCASE(os.name),"CD")<>0 then
      CD = true
   End If
Next
If DVD then
   Call makefile("CDROM = DVD")
ElseIf CD then
   Call makefile("CDROM = CD")
Else
   Call makefile("CDROM = NONE")
End if

' Get the BIOS information
For each os in GetObject("winmgmts:").InstancesOf("Win32_BIOS")
Call makefile("BIOS = "&os.SMBIOSBIOSVERSION)
Next

' Get the video information
For each os in GetObject("winmgmts:").InstancesOf("Win32_VideoController")
Call makefile("VIDEO = "&os.name)
next

' Get the audio information
For each os in GetObject("winmgmts:").InstancesOf("Win32_SoundDevice")
Call makefile("Audio = "&os.name)
Next

' Display output
shell.popup sOutput

'create a file called sysinfo.txt
call CreateFile

Sub Makefile (filename)
filename = Trim(filename) ' Strip whitespace
sOutput = sOutput & filename & vbcrlf
End sub

Sub CreateFile()
Set objFSO = CreateObject("Scripting.FileSystemObject")
Set objTextFile = objFSO.OpenTextFile("sysinfo.txt", 2, True)
objTextFile.WriteLine sOutput
objTextFile.Close
End Sub

A simple alternative to this script - if you just want to find make and model information - is to follow the process identified by my MCS colleague Ben

1. Open a Command Prompt

2. Type WMIC

3. To determine the Make, type CSProduct Get Vendor

4. To determine the Model, type CSProduct Get Name

Ben also has an excellent article on how to use specific WMI information in rules to perform different tasks based on hardware types. You can find his blog entry here

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.

Multiple Partitions in BDD 2007

ricsmith — Mon, 23 Jul 2007 00:37:00 GMT

Have had a couple of requests to cover creating multiple partitions using BDD 2007. By default BDD 2007 creates a single partition (C:) that then builds out with your required OS and applications via the task sequencer. The partition and format information is not done by the unattend.xml file (WinPE section) as you might expect, but via ZTIDiskpart.wsf. This script uses ZTIDiskpart.txt to describe how the drive should be wiped, re-partitioned and formatted.

The default ZTIDiskpart.txt use DiskPart commands and looks like this:

select disk 0

clean

create partition primary

assign letter=c:

active

exit

In the default settings, the first disk (disk 0) is selected and then cleaned (wiped). A primary partition is then created (using all available space) and assigned drive letter C: The partition is then set as active. ZTIDiskpart.wsf takes care of formatting this single partiton.

To have the ZTIDiskpart.wsf script apply different settings (in this case - create two partitons on the same disk) then we can edit ZTIDiskpart.txt as follows:

select disk 0

clean

create partition primary size=20000

assign letter=c:

active

create partition primary

assign letter=d:

format FS=NTFS QUICK

exit

In this example, the first disk is selected (disk 0) and cleaned as it was in the default script. A primary partition of 20GB is then created (specified in MBs) assigned letter C: and made active. A second partition is then created (by not specifying a size on this second entry, all remaining available space is used) and assigned letter D: This partition is then formatted with NTFS using the QUICK switch (ZTIDiskpart.wsf will take care of formatting the C: drive, however it won't format the second partition, so we include a command for this in ZTIDiskpart.txt)

There is however a gotcha...The allocation of drive letters from within the Windows PE environment doesn't carry over to the installed operating system if you are trying to create partitons on different physical disks. When the operating system has finished installing, the disk letters can be out of sync. To enable the ZTIDiskpart.wsf script to correctly add drive letters and create two partitions on different disks (usefull if using BDD 2007 to create server builds), use the

Select disk 0

Create partition primary

Assign letter=c:

Active

Select disk 1

Create partition primary

Assign

Exit

The key to this working is that no letter is assigned to the second partition (that will be created on the 2nd disk). When the operating system starts you will find that D: will be assigned to the second disk by the OS.

I am greatful (as ever) to Ben Hunter and Michael Niehaus for their input and guidance :-)

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