Vista E Book Ch3

Chapter 3

1

Chapter 3

The Expert’s Guide to Implementing Microsoft®Windows® Vista™

ContentsChapter 3 - Preparing and Planning for Deployment ............................3Introduction ................................................................................................3

Tell me again: why are we doing this? ...............................................3Planning Methodology ........................................................................5Application Compatibility ....................................................................6Application Management/Deployment .............................................8Define Computer Imaging System .....................................................9

Choosing an Image Strategy........................................................................9Deployment Planning .......................................................................10

Select the appropriate deployment scenarios. ........................................10Ensure that the required infrastructure exists.........................................10Determine the monitoring plan.................................................................11

Infrastructure Remediation (Preparation).......................................11Gather and Analyze Infrastructure Inventories ........................................11Propose Infrastructure Modifications.......................................................11

Security Planning..............................................................................11System Security Settings...........................................................................12Planning User Account Control .................................................................13Planning Windows Firewall........................................................................13Planning Data Encryption..........................................................................14Restricting the Use of Removable Storage Devices ................................15Planning Windows Defender .....................................................................15Third-part Security Applications ................................................................15Infrastructure and Deployment Security ..................................................15

The Expert’s Guide to ImplementingMicrosoft® Windows® Vista™

® 2007 ScritpLogic®

2

Chapter 3

Testing ...............................................................................................16Lab Requirements......................................................................................16Bug Rating, Reporting, and Tracking ........................................................16Change Control...........................................................................................16Test Schedules ...........................................................................................16

Training ..............................................................................................17Training Requirements...............................................................................17Training Schedule.......................................................................................17Training Methods .......................................................................................17Materials and Resources ..........................................................................18

User State Migration ........................................................................18Application Inventory and Prioritization....................................................18Identify Application Files and Settings .....................................................18Identifying Operating System Settings .....................................................19Develop and Test .......................................................................................19

Summary...........................................................................................20



3

Chapter 3

Chapter 3Preparing and Planning for Deployment

IntroductionIn previous chapters we’ve reviewed the new features in Microsoft® Windows® Vista™, and provided acursory analysis of the benefits of each feature. In this chapter, we will make a “plan for a plan,” that is,discuss what it will take to migrate to Vista and what the process might look like.

While the benefits of implementing Vista might be obvious to an IT manager, it is probably not obviousto the end user or mid-level manager. In fact, just the opposite—any change is regarded as disruptive andlooked upon with suspicion and trepidation. For that reason it is imperative to create and manage adetailed plan, train and inform clients, and maintain constant communication to the affected population.

Much of the migration to Vista involves analyzing and inventorying the installed base (both hardwareand software components), and determining impacts on the enterprise infrastructure. An additional, andnon-trivial, aspect is taking inventory of applications and determining their readiness for the newoperating environment. Lastly, we must not forget preparing end users for the change—educating them,garnering buy-in, and generating enthusiasm for the change.

Tell me again: why are we doing this?

Let’s begin our plan with the obvious: the business case for doing a lot of work, spending a lot of money,and potentially disturbing the user base. Every situation will be different, but Vista providesimprovements in many areas, including benefits as outlined below (straight from Microsoft1).

IT Department Benefits

• Reduced Security Mgmt

• Reduced Information Theft

• PC Recycling

• Automated Desktop Management

• Reduced Help Desk Support

• Reduced Image Management

• Third-Party Application Savings



1 http://www.microsoft.com/technet/desktopdeployment/bdd/2007/WdBusCase_9.mspx

http://www.microsoft.com/technet/desktopdeployment/bdd/2007/WdBusCase_9.mspx

4

Chapter 3

Business Benefits

• Performance and Reliability

• Computer Failures

• Power Management

• Application Responsiveness

• Information Management

Of course, all of these benefits are offset by the time, cost, and effort required to deploy a new operatingsystem. Thus, the first step in our plan is to develop a business case. The business case will help garnerthe crucial buy-in from management, as well as provide insight into the scope of the project.

At a minimum, the business case should develop a clear-cut and easily expressed reason for the newdeployment. For example, “Substantially improve productivity, security, and maintainability of enterprisedesktops by standardizing on the Windows Vista operating environment.” The business case will quantifywhat is meant by “substantially improve,” as well as outline project scope and objectives, costs, risks,and schedule. Microsoft provides an in-depth example case study with the Solution Accelerator forBusiness Desktop Deployment (BDD) 2007 toolkit. For our purposes, a successful plan is one where theright things (and no more) were at the right place at the right time.



5

Chapter 3

Planning MethodologyMicrosoft recommends using BDD 2007 for planning, building, testing, and deployment of Vista (SeeFigure 1). BDD 2007 is a downloadable collection of sample templates, technology files (such as scriptsand configuration files), and a case study. It also documents software that must be downloaded fromMicrosoft to assist in Vista deployment. BDD assumes a Microsoft Windows Server® 2003 or WindowsServer (“Longhorn”) server domain.

Figure 1. Microsoft’s Business Desktop Deployment (BDD) model2

Generally, other tools will be used to complement BDD, including Microsoft’s Systems ManagementServer (SMS), the Windows User State Migration Tool (USMT), and/or third-party products. While it isobviously not necessary to employ BDD, we will use the model as the basis for developing our Vistadeployment plan3.

Microsoft breaks the project tasks into cross-organizational teams that are responsible for individual partsof the overall project; however, each team is responsible for all phases of the project, including planning,development, stabilization, and deployment.



2 http://www.microsoft.com/technet/desktopdeployment/bdd/2007/default.mspx3We use BDD as model only loosely; for brevity some of Microsoft’s recommended tasks are omitted in this document.

http://www.microsoft.com/technet/desktopdeployment/bdd/2007/default.mspx

6

Chapter 3

The cross-organizational teams recommended by Microsoft, and used here as a template for planning, are :

• Application Compatibility

• Application Management/Deployment

• Define Computer Imaging System

• Deployment Planning

• Infrastructure Remediation (Preparation)

• Operations Readiness

• Security Assessment

• Testing

• User State Migration

Since these planning activities are somewhat independent, they are presented (and can generally beexecuted) in no particular order. Staffing requirements and availability will dictate the scheduling of eachactivity.

Application CompatibilityApplication compatibility is one the most important challenges faced by organizations when deployingnew operating systems. An organization is typically supported by hundreds or thousands of in-house andthird-party applications, many of which are critical to the conduct of the business. These applications canbe categorized as:

• Core line-of-business applications, such as Enterprise Resource Planning, accounting, and customerrelationship management applications. Further, these applications are generally supported by some kindof database management system(s).

• Desktop applications such as office productivity suites and other third-party suites like AdobePhotoshop and the like.

• Administrative tools, such as antivirus, file management, and backup/restore utilities.

• Custom tools such as logon scripts.

Some of the interactions between applications and the operating system have changed with WindowsVista; these changes can result in behaviors from not executing at all to running but producing incorrectresults. To help plan and manage the migration to Vista, Microsoft provides the ApplicationCompatibility Toolkit (ACT).



4 Adapted from the BDD 2007 documentation; this is a subset of the BDD-recommended teams.

7

Chapter 3

Figure 2. The Microsoft Application Compatibility Toolkit (ACT) process

ACT is a comprehensive tool that allows administrators to deploy “compatibility evaluator” agents to theclient desktops to collect information on applications’ compatibility, analyze the information, andmanage test results (Figure 2). Administrators can select different agents, depending upon the type ofinformation desired:

• Inventory Collector: Examines client computers to identify the installed applications and systeminformation.

• UserAccount Control Compatibility Evaluator (UACCE): Enables identification of potentialcompatibility issues that are due to permission restrictions enforced by the User Account Control(UAC). UACCE provides information about both potential application permission issues and suggestsways to fix the problems.

• Update Compatibility Evaluator (UCE): Provides insight and guidance about the potential effects ofa Windows operating system security update on installed applications. The compatibility evaluatorcollects information about the modules loaded, the files opened, and the registry entries accessed by theapplications currently running on the computers and writes that information to log files that areuploaded to the ACT database.

• Internet Explorer Compatibility Evaluator (IECE): Enables identification of potential Webapplication and Web site issues that occur due to the release of a new operating system. IECE works byenabling compatibility logging in Internet Explorer, parsing logged issues, and creating a log file foruploading to the ACT Log Processing Service.

•Windows Vista Compatibility Evaluator: Enables identification of issues that relate to the GraphicalIdentification and Authentication (GINA) DLLs, to services running in Session 0 in a productionenvironment, and to any application components made obsolete by changes in the Windows Vistaoperating system (Figure 3).



4 Adapted from Windows Defender>Options Help

8

Chapter 3

Figure 3. Sample ACT client analysis for Windows Vista Compatibility

ACT allows administrators to maintain an application inventory, test and assess applications, and logresults in a sharable database.

Application Management/DeploymentOnce applications have been inventoried, the next step is to determine priorities and deploymentmechanisms. Microsoft recommends5:

Identify core and supplemental applications. An enterprise environment typically requires multipleapplications to be deployed to different computers. Some applications, such as office productivityapplications, may be required on the majority of the computers. Others may be required on a small set ofcomputers. Applications should be categorized as core or supplemental. Core applications, such asMicrosoft Office programs, are built into the client computer images that organizations deploy so that allusers in the organization have the application. Supplemental applications, such as line-of-businessapplications, are installed on a user-by-user basis as necessary.

Understand packaging techniques. Understand the different ways an application can be packaged fordeployment and whether the package can be incorporated in the base operating system image.

Inventory applications. Identify all applications that must be packaged for deployment before startingto create packages.

Prioritize applications.After applications have been identified, prioritize them and create packagesbased on the established priority.



5 From the BDD 2007 documentation.

9

Chapter 3

Identify application subject matter experts (SMEs). The deployment team may not be aware of all theintricacies of the various applications that will be deployed in the enterprise architecture. SMEs for thedifferent applications can help the team understand installation and migration needs for the applications.Additionally, SMEs can help develop end-user training materials to help users adapt to any changes thatinfluence them.

Identify files and settings. Different applications may contain settings that must be implemented ormigrated. SMEs can help with the identification of such settings and files that may be necessary fordeploying the applications.

Choose distribution techniques. Determine and document how to distribute enterprise applications.

Define Computer Imaging SystemA specific solution is recommended for imaging the operating systems and the core applications that arepart of a standard desktop. The solution should be modular to allow team members to separately manageeach system component. The advantage of the modular approach is that when changes occur, teammembers do not have to re-engineer the entire process. The solution should also provide the tools andscripts to install, configure, and customize the Windows platforms and incorporate device drivers andupdates.

Choosing an Image StrategyMost organizations strive for a standard desktop configuration based on a common image for eachoperating system version. Of course, a single image is rarely attainable; however it is a worthy goal tominimize the number of images. The tradeoffs between many, more specialized, images against fewer,more general images involve development, testing, storage, and networking costs. Microsoft suggestscategorizing images by size and complexity of deployment6:

Thick Image. Thick images are monolithic images that contain core applications, language packs, andother files. Part of the image development process is installing core applications and language packsprior to capturing the disk image. Thick images are simpler to create, because the image contains all coreapplications and language packs and can be deployed in a single (albeit large) step.

The disadvantages of thick images are increased costs. For example, updating a thick image with a newversion of an application or language packs requires rebuilding, retesting, and redistributing the entireimage.

Thin Image. Thin images contain few core applications and/or language packs; these will be installedseparately from the OS disk image. There are several advantages to thin images, including less cost tobuild, maintain, and test, and lower bandwidth requirements during deployment.

The primary disadvantages of thin images are that they can be more complex to develop initially, andcore applications and language packs are not available on first start.



6 From BDD 2007 documentation, “Computer Imaging System Feature Team Guide.doc”

10

Chapter 3

Hybrid Image. As the name implies, a hybrid image mixes thin and thick strategies. In a hybrid image,the disk image is configured to install applications and language packs on first run, giving the illusion ofa thick image but applications and language packs are installed from a network source. Hybrid imageshave most of the advantages of thin images; however, they are not quite as complex to develop. They dorequire longer installation times, , which can raise initial deployment costs.

Deployment PlanningDeployment planning involves examining the existing production environment and deciding how toapproach deployment. Considerations include determining the deployment scenario and deploymentmethods, insuring the required infrastructure is in place, and establishing a monitoring and feedbackmechanism.

High-level steps in the deployment Planning Phase include those described below.

Select the appropriate deployment scenarios.Different deployment scenarios are used depending upon each desktop’s current state and the deploymentmethod (Table 1). The deployment scenario is logged with all of the other information collected duringthe client population inventory.

Table 1. Deployment scenarios depending upon current system state.7



7Microsoft, “Deployment Feature Team Guide.doc”

Scenario Description User statemigrated

Usesexistingclient

computer

File systempreserved

New Computer A new installation of Windows is deployed to a new com-puter This scenario assumes that there is no user data orprofile to preserve.

No No No

Upgrade Computer The current Windows operating system on the target com-puter is upgraded to the new operating system. The existinguser state migration data, user profile, and applications areretained (as supported by the new operating system).

Yes Yes Yes

Refresh Computer A computer currently running a supported Windows operat-ing system is refreshed. This scenario includes computersthat must be re-imaged for image standardization or to ad-dress a problem. This scenario assumes that the team ispreserving the existing user state data on the computer..

Yes Yes No

Replace Computer A computer currently running a supported Windows operat-ing system is replaced with another computer. The existinguser state migration data is saved from the original com-puter. Then, a new installation of Windows is deployed to anew computer. Finally, the user state data is restored to thenew computer.

Yes No No

11

Chapter 3

Ensure that the required infrastructure exists.Deployment planning also includes determining if the required infrastructure exists for the upgrade orreplacement. This includes storage requirements for deployment images, user state migration, backups,and deployment logs. (Deployment logs can be centrally located if sufficient network bandwidth existsto/from the target systems).

Similarly, each deployment point needs access to the application and operating system source files to beused in the deployment process. These can be located on either a common network shared folder that isaccessible to all servers hosting the deployment points, or individual servers hosting deployment points.

Determine the monitoring plan.Obviously, progress should be monitored and packaged for management review. Teams can use toolssuch as Microsoft Systems Management Server (SMS) 2003, Microsoft Operations Manager (MOM)2005, and the BDD 2007 Management Pack for MOM 2005.

Infrastructure Remediation (Preparation)Examining and preparing the infrastructure (systems, networking, etc.) is a key activity in planning theVista deployment. The first step of this planning element is critical to the entire project—accuratelydescribing the physical location of assets, performing an inventory of systems and software, anddetermining infrastructure changes to execute the deployment plan. Assessments from this phase ofplanning are provided to other phases, especially deployment planning (above).

Gather and Analyze Infrastructure InventoriesThe information gathering phase of defining the infrastructure produces a geographical description of thebusiness, inventories of hardware and software, and network infrastructure. The ultimate purpose of allof this information is to create an analysis document that will become the basis for recommendations toinfrastructure changes. At a minimum, the inventory should produce:

• The number of computers being deployed

• The number of computers requiring upgrades to existing hardware

• The number of computers that must be replaced before the new Vista image is deployed

Inventory data collection can use the newApplication Compatibility Testing (ACT) tool, as discussed inthe section “Application Compatibility” above.

Analysis of the inventory should be combined with the Application inventory taken in the ApplicationManagement activity; the combination of the two will produce data required to determine infrastructuremodifications.



12

Chapter 3

Propose Infrastructure ModificationsThe inventory analysis determines the scope of the deployment itself, along with suggested modificationsto the infrastructure. These modifications can include hardware upgrade/replacement, and/ormodifications to the network infrastructure.

Additional organizational changes that should be considered—include; preparing the IT organization forincreased service calls (perhaps even preparing a dedicated staff to handle migration issues), andexamining risks and remedies that might (will) be encountered during deployment.

Security PlanningGiven the benefits that Vista provides in the security arena, security planning occupies a large part of theoverall planning budget. As we’ve seen in previous chapters, Vista provides extensive security technology;each of these technologies should be tested for their applicability for each desktop (or group of desktops)in an enterprise. At a minimum (and not a trivial task), a risk assessment must be made for each desktopthat involves weighing increased security against possibly reduced functionality and/or user efficiency.

The easiest method to approach security planning is to assume a default baseline configuration, and makeadjustments to the baseline as exceptions. Microsoft BDD 2007 provides three baseline configurations8:

Default Configuration. In this grouping, the Windows image is essentially unchanged. It is configuredwith the same features and security settings that are provided when Windows is installed from theoriginal media.

Enterprise Client. In this grouping, security policies are applied that are more restrictive than the defaultWindows configuration; these policies are targeted at a typical corporate enterprise computer. Generally,these settings best suit most enterprise users.

Specialized Security–Limited Functionality (SSLF). In this grouping, security policies are applied thatare the most restrictive of the three options. This option focuses on securing the computer and requiressignificant compromises; while security is increased, engineering time will be increased and usabilitywill be decreased.

System Security SettingsThere are literally thousands of different settings that can be changed that will affect the security of anindividual desktop. These settings can be managed in a number of ways, including the use of GroupPolicies in an Active Directory domain, third-party software such as ScriptLogic’s Desktop Authority, or(more commonly) a combination of both.

Administrators should review required system security settings for a variety of categories (Table 2).Changes should be carefully weighed, and described in the security plan as differences from the baselinesecurity configuration.



8 Adapted from BDD 2007 Documentation, “Security Feature Team Guide,” p. 19

13

Chapter 3

Table 2. Security settings and considerations when planning for deployment.9

Planning User Account ControlUser Account Control (Chapter 2) has the potential to change the way a legacy application executes,largely because the application now no longer has write access to key system files (e.g. the registry).Planners should work with application compatibility testers to insure the proper UAC security settingsare enabled for users that will be using such applications.

Planning Windows FirewallVista made some significant changes to the firewall functionality, notably blocking some outboundcommunications (see Chapter 2). The effect of this change may cause some applications to require non-baseline firewall settings to execute successfully.

One of the mechanisms to help manage the non-baseline settings is firewall profiles (Figure 4). Profilesallow administrators to create pre-packaged firewall settings and deploy them as necessary. Similarly,firewall port exceptions may need to be configured to allow communications traffic through the firewallfor applications that make assumptions about network availability. Firewall settings may be managedthrough Group Policy objects or on individual systems via the Windows Firewall MMC Snap-in.



9 Adapted from BDD 2007 Documentation, “Security Feature Team Guide,” pp. 20-25

Security Category Considerations

User Accounts The Windows operating system includes several default user accounts. Care should be used if additional ac-counts are added.

Group Memberships and LimitedUsers

Vista includes multiple built-in groups, and different users can be made members of different groups. Somegroups (e.g., Administrators) have elevated security privileges; care must be taken in assigning users to thesegroups. Pay particular attention to elevating security levels just to run legacy applications which made the as-sumption that all users executing the application would have administrator rights (see User Account Controlin Chapter 2 for additional information on UAC).

Password Settings Passwords are the most popular authentication mechanism for desktops. Administrators may want to changepassword requirement properties, including password length, complexity, and frequency of change.

File Permissions Generally, Vista’s default file permissions are sufficient to provide a level of security without limiting users’functionality or ease-of-use. However, some legacy applications may make assumptions on file permissions;see information on User Account Control and Application Compatibility Testing (ACT) in Chapter 2.

Registry Permissions The system’s registry is a critical repository of operating system and application configuration information.Similar to password settings and file permissions, care must be used in granting access to the registry, espe-cially just to allow a legacy application to execute.

Service Permissions Services executing in the background traditionally (under Windows XP) had elevated permission levels; Win-dows Vista dramatically changed this model by running services with minimal privileges by default. See Chap-ter 2 for additional information on Services.

Event Log and Auditing Settings While the default settings for Event Logging and Auditing are generally sufficient, security planners mightwant to employ third-party software that analyzes these logs to provide intrusion detection capabilities.

User Rights Settings User Rights describe what actions users are allowed to take (e.g., program debugging, system profiling, sys-tem shutdown). Planners will need to consider changing user rights for some selected users, especially appli-cation development users.

Other Security Options There are a myriad of additional security options. Often the default settings will suffice, however, each situa-tion should be reviewed and documented to insure that security settings are not changed “on the fly,” poten-tially opening a security loophole that goes undetected.

14

Chapter 3

Figure 4. Sample profile settings for Windows Firewall

Planning Data EncryptionVista provides three methods of protecting data through encryption (RMS, EFS, and BitLocker DriveEncryption; see Chapter 2 for additional information). Planners must work with management todetermine data sensitivity, where the data resides, and the type of encryption that is applicable.Sometimes the need for encryption may not be obvious; even if the data on a lost or stolen computer isnot sensitive in itself, it could provide information that would allow access to an enterprise network thatdoes contain sensitive data. Table 3 shows the data security scenarios that each technology supports.

Table 3. Data encryption and security scenarios10



10 From Microsoft Vista BDD 2007 Documentation, “Security Feature Team Guide.”

Scenario RMS EFS BitLocker

Remote document policy enforcement �Protect content in transit �Protect content during collaboration �Local multi-user file and folder protection �Remote file and folder protection �Untrusted network administration �Portable computer protection �Branch office computers �Local single-user file and folder protection �

15

Chapter 3

Restricting the Use of Removable Storage DevicesThe myriad of portable storage mediums today make it essential for corporations to prohibit or monitorthe use of certain devices on the company network. These devices can allow confidential data to easily becopied to any portable device, viruses can be introduced to the network and spread corporate wide, andillegal software can be copied to the company network.

To prevent users from installing such devices on Windows Vista, configure Group Policy settings toallow or deny installation of specific device IDs or device classes or to deny installation of removabledevices. Alternatively, third party tools like ScriptLogic’s Desktop Authority provide extensive tools formanaging removable storage devices.

Planning Windows DefenderWindows Defender helps protect users from spyware and other potentially unwanted software bydetecting and removing known spyware on users’ computers. Defender is most often used in conjunctionwith third-party tools as part of a comprehensive anti-spyware solution.

If the decision is made to deploy and activate Windows Defender, Group Policy objects or third-partysoftware may be used to enable and configure it within the enterprise.

Third-party Security ApplicationsMost organizations complement Microsoft’s security applications with additional applications for virusprotection and/or backup. Generally, and enterprise will enforce the use of a comprehensive antivirussolution that gives administrators centralized control over the antivirus configuration and thatautomatically updates antivirus signatures. (See http://www.microsoft.com/security/partners/antivirus.aspfor a list of Microsoft partners).

Infrastructure and Deployment SecurityLastly, Vista deployment planning must comprehend the deployment itself. Staging areas, servers, andinfrastructure should be examined for enforcement of security policies, both during initial deployment andongoing updates.

Protect Deployment Staging Areas. Staging areas where images are created, updated, and maintainedpose a significant potential vulnerability. Computers in the staging area contain critical information,including credentials used to automatically authenticate computers during the setup process. Also,because the staging area contains images that are distributed enterprise-wide, a compromised image canhave a widespread effect and incur very high costs.

Protecting Production Deployment Servers. Similarly, deployment servers must be protected duringdeployment. Microsoft recommends protecting deployment servers with physical controls and physicallyisolating them11. They also recommend limiting the services that are running, disallowing remote login (ifpossible), and enforcing collaboration such that no single administrator can make critical changes to images.



11 From Microsoft Vista BDD 2007 Documentation, “Security Feature Team Guide.”

http://www.microsoft.com/security/partners/antivirus.asp

16

Chapter 3

Protecting Windows PE and Client Deployment Scripts. If an organization uses the MicrosoftWindows Preinstallation Environment (Windows PE) during the client deployment process, keepWindows PE updated and thoroughly tested. In addition, consider security in developing Windows PEscripts, including the avoidance of including user credentials in clear text and using file and sharepermissions to protect the scripts.

Other Infrastructure Security Considerations. Microsoft includes planning on additional securityconsiderations during deployment; see the Microsoft BDD 2007 documentation for additionalinformation.

TestingA large part of a successful deployment is testing target configurations, applications, and securitysettings. The testing team should develop an in-depth test plan and use that plan to establish labrequirements, risks, and schedule. The Microsoft BDD 2007 documentation provides a detailed sampletest plan, as well as a template that follows the BDD 2007 testing methodology. An abbreviateddiscussion of the most relevant topics of the test plan is discussed below.12

To keep the scope of the project manageable, it is generally simpler to assume that applicationsthemselves are tested independently (probably by the vendor). Assuming the application works correctlyreduces testing to those components that are sensitive to the application environment.

Lab RequirementsTo accurately test applications, the test plan should specify a lab environment that closely matches theproduction environment. The lab environment should reflect software packages, operating systemimage(s), and networking components to insure that application behavior will be consistent afterdeployment.

Bug Rating, Reporting, and TrackingBug reporting, rating, and tracking will allow problems to be tackled quickly and by the rightdevelopment team or SME. Issues should be prioritized and tracked, with periodic reports to the otherdeployment teams. The test plan should concisely define these teams and mechanisms forcommunicating with them.

Change ControlChange control centralizes management of issues and permits collaboration on changes to infrastructure,system images, or processes. The test plan should put in place change control procedures to insureaccurate and timely communication of changes and/or proposed changes.



12 Adapted from BDD 2007 Documentation “Test Feature Team Guide,” pp 14-16

17

Chapter 3

Test SchedulesA big part of the test plan is the testing schedule. Much of testing is dependent upon other planningactivities, depending on the types of tests and whether tests are done piecemeal (as items are released), ortesting is done on complete system images prior to deployment.

The testing schedule should include, at minimum, the following tasks:

• Test environment setup

• Documentation review

• Preparation of high-level test scenarios

• Test case preparation

• Test execution

• Number and duration of testing cycles

TrainingTraining IT staff and end users plays a critical role in a successful deployment. Planners should develop abase set of training requirements; from that they should develop a plan that comprehends the schedule,training methods, and the materials and resources that will be required.

The IT staff will need training on new deployment methods, security features, and changes in networkingand configuration tools. Training planners should work closely with other deployment team members toinsure consistency across teams and to minimize impact on schedule.

At a minimum, users should be trained on the new productivity and security features in Windows Vista.Additionally, if line-of-business applications have any externally visible changes, training will berequired to avoid surprises after deployment. For example, an enterprise will generally deploy Office2007 with Vista; users will need training on the new user interface that those applications offer.

Training RequirementsInitial steps in planning training should define the baseline requirements; given the staff and user base,what are the minimum training requirements for testing, deployment, and ongoing operations?Application SMEs should be consulted for materials on user visible changes to applications andenterprise-developed tools.

Training ScheduleGiven requirements, planners should develop a schedule that takes into account the user base, deploymentschedule, staff and materials availability, and budget. Certainly, IT Staff will be trained first as planningand testing proceeds, with the user base trained in parallel as staff gains experience during testing.



13 http://msdn2.microsoft.com/en-us/windowsvista/aa904962.aspx

http://msdn2.microsoft.com/en-us/windowsvista/aa904962.aspx

18

Chapter 3


Training MethodsOnce requirements and schedule are scoped, the training methods may be determined. Depending uponthe subject matter, there are many methods for training. Microsoft offers extensive training opportunities(especially for developers ). Additionally, there are any number of third-party training organizations thatsupport multiple delivery methods. Consider the following training methods14:

• Hands-on Training

• Presentations

• Computer-based training (CBT), Web-based training (WBT)

• Handouts

• Certification (identify training requirements that will require certification to demonstrate a specifiedlevel of proficiency).

Materials and ResourcesPlanners will need to make decisions on the materials and resources required to carry out the training asit is scoped. Considerations include whether the materials need to be developed or purchased, and timingfor obtaining the materials (make sure they show up on time).

Resources also need to be scheduled, including staff to provide the training, facilities, and budgetrequirements. If travel is required, the schedule and budget will need to reflect the appropriate resources.

User State MigrationThe user state on a system is the user’s preferences (such as screen savers, browser favorites, etc.),documents, and applications data. Retaining this information through an upgrade or system replacementto Vista is obviously critical to the operation of the enterprise.

Systems that are to be upgraded in-place, using the standard Vista upgrade process, will not need statemigration because the data remains on the system throughout the upgrade. (Of course, it is advisable toperform a system backup before any upgrade.)

It is expected that in-place upgrades will be the exception, however, and most systems will be upgradedeither through a “wipe and load” (use the same computer, but wipe it clean and load the system image fromscratch), or a “side-by-side” upgrade (where the user’s state is moved to a new system)15. Automating thisprocess is almost a necessity, since it is time-consuming and error-prone. Microsoft recommends using theUser State Migration Tool (USMT 3.016), updated to version 3.0 for Windows Vista.

A side note here—preserving users’ states on top of a standard system image (by whatever method)almost guarantees that the resulting images will not adhere to a standard. Consider third-party tools thatmanage enterprise-wide user settings.


14 Adapted from BDD 2007 documentation “Training Plan.doc”15 “Migrating to Windows Vista Through the User State Migration Tool” at www.microsoft.com16Windows Vista technical library at http://technet2.microsoft.com/WindowsVista/en/library/

19

Chapter 3

Application Inventory and PrioritizationAs with other aspects of the deployment planning, the first step is to review the application inventory todetermine application migration requirements. Once the list of applications is created, it should beprioritized to help focus the migration work. Prioritization can be on the importance of the application tothe enterprise, how prevalent an application is in the environment, and/or the complexity of theapplication.

Identify Application Files and SettingsFor each application, the files and settings that require migration should be documented. The best placeto start is the SME (see the section “Application Management/Deployment”) for that particularapplication.

The SME should assist with several key issues17:

• Locating the software media (Often, the SME is the best source of information on where the sourcemedia, such as CDs and floppy disks, can be found.)

• Describing the appropriate configuration, behavior, and usage of the application

• Identifying which data files (if any) must be migrated

• Identifying which preferences or settings (if any) must be migrated

• Identifying any constraints associated with restructuring file locations during the restoration

Carefully document files and settings that need to be migrated as input to the process of creatingmigration scripts or USMT configuration files.

Identifying Operating System SettingsMost user preferences settings seem trivial, but nothing scares users like logging on and seeing adifferent wallpaper image. Even if they understand what happened, often they forget how to recreate theirfamiliar environment.

Key system settings that should be migrated (for each user on a system) include18:

Appearance. Includes items such as wallpaper, colors, sounds, and the location of the taskbar

Action. Includes items such as key repeat rate, whether double-clicking a folder opens it in a newwindow or the same window, and whether users must click or double-click an item to open it

Internet. Includes Internet connection settings and controls how the browser operates; additional itemsinclude home page, favorites or bookmarks, cookies, security settings, and proxy settings



17 BDD 2007 Documentation, “User State Migration Feature Team Guide.doc”18 BDD 2007 Documentation, “User State Migration Feature Team Guide.doc,” p. 14

20

Chapter 3

Mail. Includes the information required to connect to mail servers, signature files, views, mail rules,local mail, and contact lists

If USMT is employed, the ScanState process of USMT is an automated method of determining whichitems will be migrated. As with applications state migration, document which of these items will bemoved during the upgrade.

Develop and TestUser state migration plans should be handed off to the testing teams to test the migration scripts. Asmentioned in the Test planning section, testing in an accurate lab setting reduces surprises duringdeployment.

SummaryMigrating to Vista could quite possibly be the largest project an IT organization has ever undertaken. Ifmigration is years away, or will take place over the next few years, it is advisable to be proactive and puta plan in place. Even if it’s a back-of-the-envelope plan, the organization needs estimated duration,budget, manpower, and IT resources that will be required.

Microsoft has developed a huge toolset to help with the migration. While many IT organizations may“roll their own” migration toolset, it wouldn’t hurt to take a look at the Microsoft SMS (SystemsManagement Server) 2003, and all of its related tools.

An obvious alternative is the range of third-party tools that are available. If an organization already has athird-party desktop management toolset in place, check with the vendor(s) to get the details on Vistamigration. For example, ScriptLogic, Altiris, and LANDesk have been working with Vista beta releasesfor several years, and their products are already Vista compatible. Most of these vendors offer tools thatallow a proactive approach to deployment—begin planning now for future Vista deployment.

Lastly, because Vista can require extensive infrastructure changes, the tools are only a part of the plan.Determining when to upgrade is just as important. It is advisable to work with lifecycle managementteams within the organization; upgrading to Vista when a desktop is replaced makes a lot of sense. Resistthe urge to make a wholesale upgrade within the organization—Vista migration is a big enough challengewithout trying to tackle the entire enterprise at once.



Technology

Vista E Book Ch3