Richard Smith : BDD2007

System Center Configuration Manager 2007 Toolkit released

ricsmith — Fri, 23 Nov 2007 16:21:32 GMT

For those that haven't seen it , we have just released the SCCM 2007 Toolkit for download. This excellent toolkit contains:

Client Spy - A tool to help troubleshoot issues related to software distribution, inventory, and software metering on Configuration Manager 2007 clients.

Policy Spy - A policy viewer to help review and troubleshoot the policy system on Configuration Manager 2007 clients.

Trace32 - A log viewer that provides a way to easily view and monitor log files created and updated by Configuration Manager 2007 clients and servers.

Security Configuration Wizard Template for Configuration Manager 2007 - An attack-surface reduction tool for the Microsoft Windows Server 2003 operating system with Service Pack 1 and Service Pack 2 (SP1 and SP2) that determines the minimum functionality required for a server's role or roles, and disables functionality that is not required.

DCM Model Verification - A tool used by desired configuration management content administrators for the validation and testing of configuration items and baselines authored externally from the Configuration Manager console.

DCM Digest Conversion - A tool used by desired configuration management content administrators to convert existing SMS 2003 Desired Configuration Management Solution templates to Desired Configuration Management 2007 configuration items.

DCM Substitution Variables - A tool used by desired configuration management content administrators for authoring desired configuration management configuration items that use chained setting and object discovery.

I would encourage anyone who uses BDD 2007 or Microsoft Deployment to download this toolkit for the excellent Trace32 tool that makes troubleshooting BDD/MDT log files so much easier.

You can download the SCCM 2007 Toolkit from:

http://www.microsoft.com/downloads/details.aspx?FamilyID=948e477e-fd3b-4a09-9015-141683c7ad5f&DisplayLang=en

Microsoft Deployment RC1 Released

ricsmith — Thu, 25 Oct 2007 11:06:00 GMT

Business Desktop Deployment (BDD) is now Microsoft Deployment!

The RC1 release and new name for the fourth generation deployment Solution Accelerator, Microsoft Deployment is available from today. Previous Beta releases have been using the code name "Deployment 4" to refer to Microsoft Deployment before the name was finalised.

Microsoft Deployment is the next version of Business Desktop Deployment (BDD) 2007. It unifies the tools and processes required for desktop and server deployment into a common deployment console and collection of guidance. Microsoft Deployment adds integration with recently released Microsoft deployment technologies to create a single path for image creation and deployment using:

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
2007 Office system
Windows Server 2008 Server Manager for automated server role definition

New Features in Microsoft Deployment

Microsoft System Center Configuration Manager 2007 support, with the following features:

Full support for Windows Vista, Windows XP, and Windows Server 2003 deployments with Microsoft Deployment 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.
- Extension of 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, and database settings.
Installation support for computers unknown to the Configuration Manager 2007 database
Added support for offline patching
Support for offline and online language pack installation
Deployment monitoring:
- Updated Management Pack for System Center Operations Manager 2007

Lite Touch Installation (LTI) support for Windows Server 2008:

Support for deploying Windows Server 2008 Beta 3 and potentially RC1 (to be verified after RC1 release), including support for Server Core installation options.
Automated server role definition using Server Manager

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 Microsoft Deployment, using new rules that can be defined in CustomSettings.ini.
Support for BDD 2007 upgrade or side-by-side installation with Microsoft Deployment.

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 Microsoft Deployment

Microsoft Deployment is available as an open beta download.

Join the Microsoft Deployment Connection program on Microsoft Connect.

If you are already registered for the program, click here.

Related Resources

Desktop Deployment Center on Microsoft TechNet

System Center Configuration Manager on Microsoft TechNet

System Center Configuration Manager evaluation software on Microsoft TechNet

Windows Server 2008 on Microsoft TechNet

I will be covering Microsoft Deployment RC1 in more detail over forthcoming blogs

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...

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 :-)

Useful Registry Changes During Build Creation/Image Deployment

ricsmith — Tue, 17 Jul 2007 16:30:00 GMT

As I have worked with different customers, a number of common requests often pop up for changes during build creation on deployment. For Windows XP deployment, I built up a library of VB scripts that carried out most of the customisations that I required (and were run either as part of the image creation process - using BDD, or as part of the deployment process - as post deploy actions)

With Windows Vista, I have started to build up the same sort of library and have put together a group of setting changes that can be used in reg files, batch files or VB scripts for making automated changes during image build or image deployment. Some of these entries are from my own deployment projects, whilst others are from Microsoft colleagues like Ben Hunter, Jon Bennett and Michael Murgolo to whom I wish to express my gratitude.

So here is my current list of tweaks...

;Adjust the system tray icons - 0 = Display inactive tray icons
[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer]
"EnableAutoTray"=dword:00000000

;Clear Most Frequently Used items
[-HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\UserAssist\{75048700-EF1F-11D0-9888-006097DEACF9}]
[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\UserAssist\{75048700-EF1F-11D0-9888-006097DEACF9}]
@=""

;Show/Hide desktop icons
; Internet Explorer = {871C5380-42A0-1069-A2EA-08002B30309D}
; User's Files = {450D8FBA-AD25-11D0-98A8-0800361B1103}
; Computer = {20D04FE0-3AEA-1069-A2D8-08002B30309D}
; Network = {208D2C60-3AEA-1069-A2D7-08002B30309D}

; 0 = Display
; 1 = Hide

[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\HideDesktopIcons]
[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\HideDesktopIcons\NewStartPanel]
"{871C5380-42A0-1069-A2EA-08002B30309D}"=dword:00000001
"{450D8FBA-AD25-11D0-98A8-0800361B1103}"=dword:00000000
"{20D04FE0-3AEA-1069-A2D8-08002B30309D}"=dword:00000000
"{208D2C60-3AEA-1069-A2D7-08002B30309D}"=dword:00000000

;Add "Explore From Here" to the context menu
[HKEY_CLASSES_ROOT\Folder\shell\fromhere]
@="Explore from &Here"
[HKEY_CLASSES_ROOT\Folder\shell\fromhere\command]
@="explorer.exe /e,/root,/idlist,%I"

;Add a Search Provider to the START MENU (example)
[HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\SearchScopes\Google]
"DisplayName"="Google"
"URL"="http://www.google.com/search?q={searchTerms}&rls=com.microsoft:{language}&ie={inputEncoding}&oe={outputEncoding}&startIndex={startIndex?}&startPage={startPage}"

;Resort the Start Menu
[-HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\MenuOrder]

;Disable Menu Delay
[HKEY_CURRENT_USER\Control Panel\Desktop]
"MenuShowDelay"="0"

;Add the Registry Editor to the context menu
[HKEY_CLASSES_ROOT\CLSID\{20D04FE0-3AEA-1069-A2D8-08002B30309D}\shell\regedit]
@="Re&gistry Editor"
[HKEY_CLASSES_ROOT\CLSID\{20D04FE0-3AEA-1069-A2D8-08002B30309D}\shell\regedit\command]
@="regedit.exe"

;Customise Windows Vista Shutdown Speed
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control]
"WaitToKillServiceTimeout"=20000

;Increase NTFS System Peformance by disabling NTFS Last Access Update and 8.3 Creation
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem]
"NTFSDisableLastAccessUpdate"=1
"NTFSDisable8Dot3NameCreation"=1

;Turn Off System Beeps
[HKEY_CURRENT_USER\Control Panel\Sound]
"Beep"=No

;Disable Welcome logon screen & require CTRL+ALT+DEL
reg add "hklm\Software\Microsoft\Windows NT\CurrentVersion\Winlogon" /v LogonType /t REG_DWORD /d 0 /f
reg add "hklm\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System" /v DisableCAD /t REG_DWORD /d 0 /f

;Interactive logon: Do not display last user name
reg add "hklm\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System" /v dontdisplaylastusername /t REG_DWORD /d 1 /f

;Enable Remote Desktop
reg add "hklm\system\currentcontrolset\control\Terminal Server" /v fDenyTSConnections /t REG_DWORD /d 0 /f

;Allow connections from computers running any version of Remote Desktop (less secure)
reg add "hklm\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" /v UserAuthentication /t REG_DWORD /d 0 /f

;Use simple file sharing - 0 = unchecked, 1 - checked
reg add "hklm\SYSTEM\CurrentControlSet\Control\Lsa" /v ForceGuest /t REG_DWORD /d 0 /f

;Disable Automatic Updates
reg add "HKLM\Software\Policies\Microsoft\Windows\WindowsUpdate\AU" /v NoAutoUpdate /t REG_DWORD /d 1 /f

;Set the Screen Saver Settings
reg add "hku\.DEFAULT\Control Panel\Desktop" /v ScreenSaveActive /t REG_SZ /d 1 /f
reg add "hku\.DEFAULT\Control Panel\Desktop" /v ScreenSaverIsSecure /t REG_SZ /d 1 /f
reg add "hku\.DEFAULT\Control Panel\Desktop" /v ScreenSaveTimeOut /t REG_SZ /d 900 /f
reg add "hku\.DEFAULT\Control Panel\Desktop" /v SCRNSAVE.EXE /t REG_SZ /d "%SystemRoot%\System32\YOUR_FILE.scr" /f

;Set the Desktop Wallpaper
reg add "hku\.DEFAULT\Control Panel\Desktop" /v Wallpaper /t REG_SZ /d "%SystemRoot%\Web\Wallpaper\YOUR_FILE.bmp" /f
reg add "hku\.DEFAULT\Control Panel\Desktop" /v WallpaperStyle /t REG_SZ /d "2" /f
reg add "hku\.DEFAULT\Control Panel\Desktop" /v TileWallpaper /t REG_SZ /d "0" /f

BDD Lite Touch and Zero Touch Lab Recommendations

ricsmith — Tue, 26 Jun 2007 19:46:00 GMT

So - I get asked a lot about how to set up a test lab or Proof of Concept environment for Lite Touch and Zero Touch. Working with my colleages in the MCS UK desktop team, specifically Mark Aslett and Adam Shepherd, we have developed a rough guide to a lab design that works for us that I thought I would share for discussion...The lab environment looks like this -

Infrastructure Server

Requirement	Why?
Windows Server 2003 R2	To fully support Windows Vista, in particular some group policy functionality and to test the DFS-R replication of images, domain controllers should be Windows Server 2003 R2.
Active Directory	Required to authenticate users accessing the Windows DS, RIS, SMS and BDD 2007 servers. Additionally Windows DS servers must be a member of an Active Directory domain.
DNS	DNS name resolution must be possible in the lab environment for Active Directory to function and for clients to locate network resources.
DHCP	During the development process clients will boot to the network to load Windows PE, this will not work without DHCP.

Build Server

Requirement	Why?
Windows Server 2003 R2	Recommended to host the other server applications, specifically Windows DS and RIS.
RIS	Prerequisite to installing Windows DS and used for legacy testing and OSD boot image delivery.
Windows Deployment Services	Should be installed in mixed mode to support legacy images such as the SMS OSD boot CDs as well a Windows PE 2.0 boot images used by BDD 2007 and Windows Vista deployments.
Windows Automated Installation Kit	Provides a number of tools required by BDD 2007 including System Image Manager, ImageX and Package Manager.
BDD 2007	Used as a repository for all build components, the generation of the reference build and the configuration of the ZTI scripts.
SQL 2005 Express	Used to test role based deployments and configurations that are moved to the deployment server

Deployment Server

Requirement	Why?
Windows Server 2003 R2	Recommended to host the other server applications.
SQL Server 2005 SP1	SQL is required by SMS 2003 and role based deployments using the BDD 2007 database. Can also be used for ACT database support. SQL 2005 SP1 should be the minimum service pack used.
SMS 2003 SP3	SMS is required to support OSD captures and deployments; it is also used as the mechanism for managing the replication of images and applications. Service Pack 3 is the update for SMS that supports Windows Vista and the latest OSD Feature Pack Update.
SMS OSD Feature Pack Update	Required to allow for operating system images to be captured and deployed via the SMS infrastructure.

The three server installation can be consolidated to two servers if Zero Touch is not required, but we find that this design works well when developing build and deployment designs in many customer environments.

User Account Control - What you need to know from a deployment perspective

ricsmith — Tue, 26 Jun 2007 19:24:00 GMT

I've had a couple of emails from people attempting to use their own admin accounts to carry out the build process and hitting User Account Control (UAC) issues. User Account Control is a core security feature of Windows Vista that fundamentally changes the way users will use the operating system. By default UAC helps protect against malware by running all users as Standard Users (including Administrators). When an application or user requires elevated privileges to complete a task, a consent prompt is presented to the user. The user can then subsequently (given the proper rights) elevate permissions in order for the application to complete the task. Enhancements in Windows Vista and UAC now allow Standard Users to perform more common tasks then before, opening up the possibility of removing administrative privileges from end users. The table below identifies some of the new stadard user tasks and the tasks that require admin elevation.

Standard User Tasks

Requires Administrator Elevation

Windows Vista

Ø Establish a Local Area Network connection

Ø Establish and configure a wireless connection

Ø Modify Display Settings

Ø Users cannot defragment the hard drive, but a service does this on their behalf

Ø Play CD/DVD media (configurable with Group Policy)

Ø Burn CD/DVD media (configurable with Group Policy)

Ø Change the desktop background for the current user

Ø Open the Date and Time Control Panel and change the time zone

Ø Use Remote Desktop to connect to another computer

Ø Change user's own account password

Ø Configure battery power options

Ø Configure Accessibility options

Ø Restore user's backed-up files

Ø Set-up computer synchronization with a mobile device (smart phone, laptop, or PDA)

Ø Connect and configure a Bluetooth device

Ø Install and uninstall applications

Ø Install a driver for a device (E.G. a digital camera driver)

Ø Install Windows updates

Ø Configure Parental Controls

Ø Install an ActiveX control

Ø Open the Windows Firewall Control Panel

Ø Change a user's account type

Ø Modify UAC settings in the Security Policy Editor snap-in (secpol.msc)

Ø Configure Remote Desktop access

Ø Add or remove a user account

Ø Copy or move files into the Program Files or Windows directory

Ø Schedule Automated Tasks

Ø Restore system backed-up files

Ø Configure Automatic Updates

Ø Browse to another user's directory

The BDD 2007 process uses the in-built administrator account that is re-enabled by the build unattend file (shown below) that BDD 2007 generates when you set up a new build. This account is used to carry out the required tasks when Windows Vista has finished it's initial installation. This account is exempt from UAC.

            <RunSynchronous>
                <RunSynchronousCommand wcm:action="add">
                    <Description>EnableAdmin</Description>
                    <Order>1</Order>
                    <Path>cmd /c net user Administrator /active:yes</Path>
                </RunSynchronousCommand>
                <RunSynchronousCommand wcm:action="add">
                    <Description>EnableAdmin_ploc</Description>
                    <Order>2</Order>
                    <Path>cmd /c net user Administrator_ploc /active:yes</Path>
                </RunSynchronousCommand>
                <RunSynchronousCommand wcm:action="add">
                    <Description>UnfilterAdministratorToken</Description>
                    <Order>3</Order>
                    <Path>cmd /c reg add HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System /v FilterAdministratorToken /t REG_DWORD /d 0 /f</Path>
                </RunSynchronousCommand>
            </RunSynchronous>

Issues arrise if you try to use your own Administrator account generated as part of the Windows Vista install process - these accounts, even though part of the local Administrators group are not exempted from UAC, so running particular tasks and scripts will cause the UAC dialogues to appear and interupt any automated process you wish to run. Always try to use the built in Administrator account for all build functions

Computer Name Selection in ZTI Deployments

ricsmith — Thu, 21 Jun 2007 12:42:00 GMT

I've been asked by a few people about the RequestComputerName.vbs script that i use in the ZTI configuration demo video posted earlier. The script prompts the technician for a computername at the start of the deployment process and stores it as an OSD variable (OSDNEWMACHINENAME) for use by the ZTI scripts.

The VB script is as follows:

Option Explicit

Dim numCount
Dim strComputerName
Dim objOSD

Do While numCount = 0
    strComputerName = InputBox ("Please enter a name for the new computer:","New Computer Name","Vista00",10,10)
    If strComputerName = "" Then
        Wscript.Echo "You must enter a computer name."
    Else
Set objOSD = CreateObject("OSD.Environment")
objOSD("OSDNEWMACHINENAME") = strComputerName
Set objOSD = Nothing
        Exit Do
    End If
Loop

The script is copied to your ZTI distribution point scripts folder (and then copied over to the SMS OSD deployment point) and is called by entering a new task into the task suquencer in the NEW COMPUTER folder in the PREINSTALL phase. This task, after creation should then be moved to the top of the list in the NEW COMPUTER folder

It is also possible to use the BDD 2007 wizard framework to create wizards that prompt for information at build time and use the OSD variables. BDD already supplies a COMPUTERNAME wizard and this could be used instead of the VB script shown above - Ben has an excellent piece on how to do this on his blog