0
Chapter 3
Chapter 3




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




                  Testing .....................................................................................
Chapter 3




          Chapter 3
          Preparing and Planning for Deployment


          Introduction
          In pr...
Chapter 3




         Business Benefits
         • Performance and Reliability
         • Computer Failures
         • Po...
Chapter 3




          Planning Methodology
          Microsoft recommends using BDD 2007 for planning, building, testing...
Chapter 3



          The cross-organizational teams recommended by Microsoft, and used here as a template for planning, ...
Chapter 3



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




          ACT is a comp...
Chapter 3



          Figure 3. Sample ACT client analysis for Windows Vista Compatibility




          ACT allows admin...
Chapter 3



          Identify application subject matter experts (SMEs). The deployment team may not be aware of all the...
Chapter 3



          Hybrid Image. As the name implies, a hybrid image mixes thin and thick strategies. In a hybrid imag...
Chapter 3




         Ensure that the required infrastructure exists.
         Deployment planning also includes determin...
Chapter 3




          Propose Infrastructure Modifications
          The inventory analysis determines the scope of the ...
Chapter 3



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



           Figure 4. Sample profile settings for Windows Firewall




           Planning Data Encryption
   ...
Chapter 3




           Restricting the Use of Removable Storage Devices
           The myriad of portable storage medium...
Chapter 3



           Protecting Windows PE and Client Deployment Scripts. If an organization uses the Microsoft
       ...
Chapter 3




          Test Schedules
          A big part of the test plan is the testing schedule. Much of testing is d...
Chapter 3




         Training Methods
         Once requirements and schedule are scoped, the training methods may be de...
Chapter 3




           Application Inventory and Prioritization
           As with other aspects of the deployment plann...
Chapter 3



         Mail. Includes the information required to connect to mail servers, signature files, views, mail rul...
Upcoming SlideShare
Loading in...5
×

Vista E Book Ch3

1,152

Published on

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
1,152
On Slideshare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
20
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Transcript of "Vista E Book Ch3"

  1. 1. Chapter 3
  2. 2. Chapter 3 The Expert’s Guide to Implementing Microsoft® Windows® Vista™ Contents Chapter 3 - Preparing and Planning for Deployment ............................3 Introduction ................................................................................................3 Tell me again: why are we doing this? ...............................................3 Planning Methodology ........................................................................5 Application Compatibility....................................................................6 Application Management/Deployment .............................................8 Define Computer Imaging System .....................................................9 Choosing an Image Strategy........................................................................9 Deployment Planning .......................................................................10 Select the appropriate deployment scenarios. ........................................10 Ensure that the required infrastructure exists.........................................10 Determine the monitoring plan.................................................................11 Infrastructure Remediation (Preparation).......................................11 Gather and Analyze Infrastructure Inventories ........................................11 Propose Infrastructure Modifications.......................................................11 Security Planning..............................................................................11 System Security Settings...........................................................................12 Planning User Account Control .................................................................13 Planning Windows Firewall........................................................................13 Planning Data Encryption..........................................................................14 Restricting the Use of Removable Storage Devices ................................15 Planning Windows Defender .....................................................................15 Third-part Security Applications ................................................................15 Infrastructure and Deployment Security ..................................................15 ® 2007 ScritpLogic® The Expert’s Guide to Implementing 1 Microsoft® Windows® Vista™
  3. 3. Chapter 3 Testing ...............................................................................................16 Lab Requirements......................................................................................16 Bug Rating, Reporting, and Tracking ........................................................16 Change Control...........................................................................................16 Test Schedules ...........................................................................................16 Training ..............................................................................................17 Training Requirements...............................................................................17 Training Schedule.......................................................................................17 Training Methods .......................................................................................17 Materials and Resources ..........................................................................18 User State Migration ........................................................................18 Application Inventory and Prioritization....................................................18 Identify Application Files and Settings .....................................................18 Identifying Operating System Settings .....................................................19 Develop and Test .......................................................................................19 Summary...........................................................................................20 ® 2007 ScritpLogic® The Expert’s Guide to Implementing 2 Microsoft® Windows® Vista™
  4. 4. Chapter 3 Chapter 3 Preparing and Planning for Deployment Introduction In previous chapters we’ve reviewed the new features in Microsoft® Windows® Vista™, and provided a cursory 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 obvious to the end user or mid-level manager. In fact, just the opposite—any change is regarded as disruptive and looked upon with suspicion and trepidation. For that reason it is imperative to create and manage a detailed 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 hardware and software components), and determining impacts on the enterprise infrastructure. An additional, and non-trivial, aspect is taking inventory of applications and determining their readiness for the new operating 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 provides improvements 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 http://www.microsoft.com/technet/desktopdeployment/bdd/2007/WdBusCase_9.mspx 1 ® 2007 ScritpLogic® The Expert’s Guide to Implementing 3 Microsoft® Windows® Vista™
  5. 5. 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 operating system. Thus, the first step in our plan is to develop a business case. The business case will help garner the 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 new deployment. For example, “Substantially improve productivity, security, and maintainability of enterprise desktops by standardizing on the Windows Vista operating environment.” The business case will quantify what 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 for Business Desktop Deployment (BDD) 2007 toolkit. For our purposes, a successful plan is one where the right things (and no more) were at the right place at the right time. ® 2007 ScritpLogic® The Expert’s Guide to Implementing 4 Microsoft® Windows® Vista™
  6. 6. Chapter 3 Planning Methodology Microsoft recommends using BDD 2007 for planning, building, testing, and deployment of Vista (See Figure 1). BDD 2007 is a downloadable collection of sample templates, technology files (such as scripts and configuration files), and a case study. It also documents software that must be downloaded from Microsoft to assist in Vista deployment. BDD assumes a Microsoft Windows Server® 2003 or Windows Server (“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 Management Server (SMS), the Windows User State Migration Tool (USMT), and/or third-party products. While it is obviously not necessary to employ BDD, we will use the model as the basis for developing our Vista deployment plan3. Microsoft breaks the project tasks into cross-organizational teams that are responsible for individual parts of the overall project; however, each team is responsible for all phases of the project, including planning, development, stabilization, and deployment. http://www.microsoft.com/technet/desktopdeployment/bdd/2007/default.mspx 2 We use BDD as model only loosely; for brevity some of Microsoft’s recommended tasks are omitted in this document. 3 ® 2007 ScritpLogic® The Expert’s Guide to Implementing 5 Microsoft® Windows® Vista™
  7. 7. 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 be executed) in no particular order. Staffing requirements and availability will dictate the scheduling of each activity. Application Compatibility Application compatibility is one the most important challenges faced by organizations when deploying new operating systems. An organization is typically supported by hundreds or thousands of in-house and third-party applications, many of which are critical to the conduct of the business. These applications can be categorized as: • Core line-of-business applications, such as Enterprise Resource Planning, accounting, and customer relationship management applications. Further, these applications are generally supported by some kind of database management system(s). • Desktop applications such as office productivity suites and other third-party suites like Adobe Photoshop 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 Windows Vista; these changes can result in behaviors from not executing at all to running but producing incorrect results. To help plan and manage the migration to Vista, Microsoft provides the Application Compatibility Toolkit (ACT). Adapted from the BDD 2007 documentation; this is a subset of the BDD-recommended teams. 4 ® 2007 ScritpLogic® The Expert’s Guide to Implementing 6 Microsoft® Windows® Vista™
  8. 8. 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 the client desktops to collect information on applications’ compatibility, analyze the information, and manage test results (Figure 2). Administrators can select different agents, depending upon the type of information desired: • Inventory Collector: Examines client computers to identify the installed applications and system information. • User Account Control Compatibility Evaluator (UACCE): Enables identification of potential compatibility issues that are due to permission restrictions enforced by the User Account Control (UAC). UACCE provides information about both potential application permission issues and suggests ways to fix the problems. • Update Compatibility Evaluator (UCE): Provides insight and guidance about the potential effects of a Windows operating system security update on installed applications. The compatibility evaluator collects information about the modules loaded, the files opened, and the registry entries accessed by the applications currently running on the computers and writes that information to log files that are uploaded to the ACT database. • Internet Explorer Compatibility Evaluator (IECE): Enables identification of potential Web application and Web site issues that occur due to the release of a new operating system. IECE works by enabling compatibility logging in Internet Explorer, parsing logged issues, and creating a log file for uploading to the ACT Log Processing Service. • Windows Vista Compatibility Evaluator: Enables identification of issues that relate to the Graphical Identification and Authentication (GINA) DLLs, to services running in Session 0 in a production environment, and to any application components made obsolete by changes in the Windows Vista operating system (Figure 3). Adapted from Windows Defender>Options Help 4 ® 2007 ScritpLogic® The Expert’s Guide to Implementing 7 Microsoft® Windows® Vista™
  9. 9. 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 log results in a sharable database. Application Management/Deployment Once applications have been inventoried, the next step is to determine priorities and deployment mechanisms. Microsoft recommends5: Identify core and supplemental applications. An enterprise environment typically requires multiple applications to be deployed to different computers. Some applications, such as office productivity applications, may be required on the majority of the computers. Others may be required on a small set of computers. Applications should be categorized as core or supplemental. Core applications, such as Microsoft Office programs, are built into the client computer images that organizations deploy so that all users in the organization have the application. Supplemental applications, such as line-of-business applications, are installed on a user-by-user basis as necessary. Understand packaging techniques. Understand the different ways an application can be packaged for deployment 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 starting to create packages. Prioritize applications. After applications have been identified, prioritize them and create packages based on the established priority. From the BDD 2007 documentation. 5 ® 2007 ScritpLogic® The Expert’s Guide to Implementing 8 Microsoft® Windows® Vista™
  10. 10. Chapter 3 Identify application subject matter experts (SMEs). The deployment team may not be aware of all the intricacies of the various applications that will be deployed in the enterprise architecture. SMEs for the different 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 that influence them. Identify files and settings. Different applications may contain settings that must be implemented or migrated. SMEs can help with the identification of such settings and files that may be necessary for deploying the applications. Choose distribution techniques. Determine and document how to distribute enterprise applications. Define Computer Imaging System A specific solution is recommended for imaging the operating systems and the core applications that are part of a standard desktop. The solution should be modular to allow team members to separately manage each system component. The advantage of the modular approach is that when changes occur, team members do not have to re-engineer the entire process. The solution should also provide the tools and scripts to install, configure, and customize the Windows platforms and incorporate device drivers and updates. Choosing an Image Strategy Most organizations strive for a standard desktop configuration based on a common image for each operating system version. Of course, a single image is rarely attainable; however it is a worthy goal to minimize the number of images. The tradeoffs between many, more specialized, images against fewer, more general images involve development, testing, storage, and networking costs. Microsoft suggests categorizing images by size and complexity of deployment6: Thick Image. Thick images are monolithic images that contain core applications, language packs, and other files. Part of the image development process is installing core applications and language packs prior to capturing the disk image. Thick images are simpler to create, because the image contains all core applications 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 new version of an application or language packs requires rebuilding, retesting, and redistributing the entire image. Thin Image. Thin images contain few core applications and/or language packs; these will be installed separately from the OS disk image. There are several advantages to thin images, including less cost to build, 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, and core applications and language packs are not available on first start. From BDD 2007 documentation, “Computer Imaging System Feature Team Guide.doc” 6 ® 2007 ScritpLogic® The Expert’s Guide to Implementing 9 Microsoft® Windows® Vista™
  11. 11. 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 of a thick image but applications and language packs are installed from a network source. Hybrid images have most of the advantages of thin images; however, they are not quite as complex to develop. They do require longer installation times, , which can raise initial deployment costs. Deployment Planning Deployment planning involves examining the existing production environment and deciding how to approach deployment. Considerations include determining the deployment scenario and deployment methods, insuring the required infrastructure is in place, and establishing a monitoring and feedback mechanism. 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 deployment method (Table 1). The deployment scenario is logged with all of the other information collected during the client population inventory. Table 1. Deployment scenarios depending upon current system state.7 Scenario Description User state Uses File system migrated existing preserved client computer New Computer A new installation of Windows is deployed to a new com- No No No puter This scenario assumes that there is no user data or profile to preserve. Upgrade Computer The current Windows operating system on the target com- Yes Yes Yes puter is upgraded to the new operating system. The existing user state migration data, user profile, and applications are retained (as supported by the new operating system). Refresh Computer A computer currently running a supported Windows operat- Yes Yes No ing system is refreshed. This scenario includes computers that must be re-imaged for image standardization or to ad- dress a problem. This scenario assumes that the team is preserving the existing user state data on the computer.. Replace Computer A computer currently running a supported Windows operat- Yes No No ing system is replaced with another computer. The existing user state migration data is saved from the original com- puter. Then, a new installation of Windows is deployed to a new computer. Finally, the user state data is restored to the new computer. Microsoft, “Deployment Feature Team Guide.doc” 7 ® 2007 ScritpLogic® The Expert’s Guide to Implementing 10 Microsoft® Windows® Vista™
  12. 12. Chapter 3 Ensure that the required infrastructure exists. Deployment planning also includes determining if the required infrastructure exists for the upgrade or replacement. This includes storage requirements for deployment images, user state migration, backups, and deployment logs. (Deployment logs can be centrally located if sufficient network bandwidth exists to/from the target systems). Similarly, each deployment point needs access to the application and operating system source files to be used in the deployment process. These can be located on either a common network shared folder that is accessible 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 tools such 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 the Vista deployment. The first step of this planning element is critical to the entire project—accurately describing the physical location of assets, performing an inventory of systems and software, and determining infrastructure changes to execute the deployment plan. Assessments from this phase of planning are provided to other phases, especially deployment planning (above). Gather and Analyze Infrastructure Inventories The information gathering phase of defining the infrastructure produces a geographical description of the business, inventories of hardware and software, and network infrastructure. The ultimate purpose of all of this information is to create an analysis document that will become the basis for recommendations to infrastructure 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 new Application Compatibility Testing (ACT) tool, as discussed in the section “Application Compatibility” above. Analysis of the inventory should be combined with the Application inventory taken in the Application Management activity; the combination of the two will produce data required to determine infrastructure modifications. ® 2007 ScritpLogic® The Expert’s Guide to Implementing 11 Microsoft® Windows® Vista™
  13. 13. Chapter 3 Propose Infrastructure Modifications The inventory analysis determines the scope of the deployment itself, along with suggested modifications to the infrastructure. These modifications can include hardware upgrade/replacement, and/or modifications to the network infrastructure. Additional organizational changes that should be considered—include; preparing the IT organization for increased service calls (perhaps even preparing a dedicated staff to handle migration issues), and examining risks and remedies that might (will) be encountered during deployment. Security Planning Given the benefits that Vista provides in the security arena, security planning occupies a large part of the overall 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 desktop that 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 make adjustments 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 configured with the same features and security settings that are provided when Windows is installed from the original media. Enterprise Client. In this grouping, security policies are applied that are more restrictive than the default Windows 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 that are the most restrictive of the three options. This option focuses on securing the computer and requires significant compromises; while security is increased, engineering time will be increased and usability will be decreased. System Security Settings There are literally thousands of different settings that can be changed that will affect the security of an individual desktop. These settings can be managed in a number of ways, including the use of Group Policies 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 baseline security configuration. Adapted from BDD 2007 Documentation, “Security Feature Team Guide,” p. 19 8 ® 2007 ScritpLogic® The Expert’s Guide to Implementing 12 Microsoft® Windows® Vista™
  14. 14. Chapter 3 Table 2. Security settings and considerations when planning for deployment.9 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 Limited Vista includes multiple built-in groups, and different users can be made members of different groups. Some groups (e.g., Administrators) have elevated security privileges; care must be taken in assigning users to these Users groups. 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 Control in Chapter 2 for additional information on UAC). Password Settings Passwords are the most popular authentication mechanism for desktops. Administrators may want to change password 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 might want 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. Planning User Account Control User 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 settings are enabled for users that will be using such applications. Planning Windows Firewall Vista made some significant changes to the firewall functionality, notably blocking some outbound communications (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). Profiles allow 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 firewall for applications that make assumptions about network availability. Firewall settings may be managed through Group Policy objects or on individual systems via the Windows Firewall MMC Snap-in. Adapted from BDD 2007 Documentation, “Security Feature Team Guide,” pp. 20-25 9 ® 2007 ScritpLogic® The Expert’s Guide to Implementing 13 Microsoft® Windows® Vista™
  15. 15. Chapter 3 Figure 4. Sample profile settings for Windows Firewall Planning Data Encryption Vista provides three methods of protecting data through encryption (RMS, EFS, and BitLocker Drive Encryption; see Chapter 2 for additional information). Planners must work with management to determine 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 is not sensitive in itself, it could provide information that would allow access to an enterprise network that does contain sensitive data. Table 3 shows the data security scenarios that each technology supports. Table 3. Data encryption and security scenarios10 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 From Microsoft Vista BDD 2007 Documentation, “Security Feature Team Guide.” 10 ® 2007 ScritpLogic® The Expert’s Guide to Implementing 14 Microsoft® Windows® Vista™
  16. 16. Chapter 3 Restricting the Use of Removable Storage Devices The myriad of portable storage mediums today make it essential for corporations to prohibit or monitor the use of certain devices on the company network. These devices can allow confidential data to easily be copied to any portable device, viruses can be introduced to the network and spread corporate wide, and illegal software can be copied to the company network. To prevent users from installing such devices on Windows Vista, configure Group Policy settings to allow or deny installation of specific device IDs or device classes or to deny installation of removable devices. Alternatively, third party tools like ScriptLogic’s Desktop Authority provide extensive tools for managing removable storage devices. Planning Windows Defender Windows Defender helps protect users from spyware and other potentially unwanted software by detecting and removing known spyware on users’ computers. Defender is most often used in conjunction with 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-party software may be used to enable and configure it within the enterprise. Third-party Security Applications Most organizations complement Microsoft’s security applications with additional applications for virus protection and/or backup. Generally, and enterprise will enforce the use of a comprehensive antivirus solution that gives administrators centralized control over the antivirus configuration and that automatically updates antivirus signatures. (See http://www.microsoft.com/security/partners/antivirus.asp for a list of Microsoft partners). Infrastructure and Deployment Security Lastly, Vista deployment planning must comprehend the deployment itself. Staging areas, servers, and infrastructure should be examined for enforcement of security policies, both during initial deployment and ongoing updates. Protect Deployment Staging Areas. Staging areas where images are created, updated, and maintained pose 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 can have a widespread effect and incur very high costs. Protecting Production Deployment Servers. Similarly, deployment servers must be protected during deployment. Microsoft recommends protecting deployment servers with physical controls and physically isolating them11. They also recommend limiting the services that are running, disallowing remote login (if possible), and enforcing collaboration such that no single administrator can make critical changes to images. From Microsoft Vista BDD 2007 Documentation, “Security Feature Team Guide.” 11 ® 2007 ScritpLogic® The Expert’s Guide to Implementing 15 Microsoft® Windows® Vista™
  17. 17. Chapter 3 Protecting Windows PE and Client Deployment Scripts. If an organization uses the Microsoft Windows Preinstallation Environment (Windows PE) during the client deployment process, keep Windows PE updated and thoroughly tested. In addition, consider security in developing Windows PE scripts, including the avoidance of including user credentials in clear text and using file and share permissions to protect the scripts. Other Infrastructure Security Considerations. Microsoft includes planning on additional security considerations during deployment; see the Microsoft BDD 2007 documentation for additional information. Testing A large part of a successful deployment is testing target configurations, applications, and security settings. The testing team should develop an in-depth test plan and use that plan to establish lab requirements, risks, and schedule. The Microsoft BDD 2007 documentation provides a detailed sample test plan, as well as a template that follows the BDD 2007 testing methodology. An abbreviated discussion 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 applications themselves are tested independently (probably by the vendor). Assuming the application works correctly reduces testing to those components that are sensitive to the application environment. Lab Requirements To accurately test applications, the test plan should specify a lab environment that closely matches the production environment. The lab environment should reflect software packages, operating system image(s), and networking components to insure that application behavior will be consistent after deployment. Bug Rating, Reporting, and Tracking Bug reporting, rating, and tracking will allow problems to be tackled quickly and by the right development team or SME. Issues should be prioritized and tracked, with periodic reports to the other deployment teams. The test plan should concisely define these teams and mechanisms for communicating with them. Change Control Change 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 insure accurate and timely communication of changes and/or proposed changes. Adapted from BDD 2007 Documentation “Test Feature Team Guide,” pp 14-16 12 ® 2007 ScritpLogic® The Expert’s Guide to Implementing 16 Microsoft® Windows® Vista™
  18. 18. Chapter 3 Test Schedules A big part of the test plan is the testing schedule. Much of testing is dependent upon other planning activities, depending on the types of tests and whether tests are done piecemeal (as items are released), or testing 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 Training Training IT staff and end users plays a critical role in a successful deployment. Planners should develop a base 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 networking and configuration tools. Training planners should work closely with other deployment team members to insure 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 be required to avoid surprises after deployment. For example, an enterprise will generally deploy Office 2007 with Vista; users will need training on the new user interface that those applications offer. Training Requirements Initial 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 and enterprise-developed tools. Training Schedule Given requirements, planners should develop a schedule that takes into account the user base, deployment schedule, staff and materials availability, and budget. Certainly, IT Staff will be trained first as planning and testing proceeds, with the user base trained in parallel as staff gains experience during testing. http://msdn2.microsoft.com/en-us/windowsvista/aa904962.aspx 13 ® 2007 ScritpLogic® The Expert’s Guide to Implementing 17 Microsoft® Windows® Vista™
  19. 19. Chapter 3 Training Methods Once requirements and schedule are scoped, the training methods may be determined. Depending upon the 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 that support 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 specified level of proficiency). Materials and Resources Planners will need to make decisions on the materials and resources required to carry out the training as it is scoped. Considerations include whether the materials need to be developed or purchased, and timing for obtaining the materials (make sure they show up on time). Resources also need to be scheduled, including staff to provide the training, facilities, and budget requirements. If travel is required, the schedule and budget will need to reflect the appropriate resources. User State Migration The 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 replacement to 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 state migration because the data remains on the system throughout the upgrade. (Of course, it is advisable to perform a system backup before any upgrade.) It is expected that in-place upgrades will be the exception, however, and most systems will be upgraded either through a “wipe and load” (use the same computer, but wipe it clean and load the system image from scratch), or a “side-by-side” upgrade (where the user’s state is moved to a new system)15. Automating this process is almost a necessity, since it is time-consuming and error-prone. Microsoft recommends using the User 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 that manage enterprise-wide user settings. Adapted from BDD 2007 documentation “Training Plan.doc” 14 “Migrating to Windows Vista Through the User State Migration Tool” at www.microsoft.com 15 16 Windows Vista technical library at http://technet2.microsoft.com/WindowsVista/en/library/ ® 2007 ScritpLogic® The Expert’s Guide to Implementing 18 Microsoft® Windows® Vista™
  20. 20. Chapter 3 Application Inventory and Prioritization As with other aspects of the deployment planning, the first step is to review the application inventory to determine application migration requirements. Once the list of applications is created, it should be prioritized to help focus the migration work. Prioritization can be on the importance of the application to the enterprise, how prevalent an application is in the environment, and/or the complexity of the application. Identify Application Files and Settings For each application, the files and settings that require migration should be documented. The best place to start is the SME (see the section “Application Management/Deployment”) for that particular application. The SME should assist with several key issues17: • Locating the software media (Often, the SME is the best source of information on where the source media, 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 creating migration scripts or USMT configuration files. Identifying Operating System Settings Most user preferences settings seem trivial, but nothing scares users like logging on and seeing a different wallpaper image. Even if they understand what happened, often they forget how to recreate their familiar 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 new window 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 items include home page, favorites or bookmarks, cookies, security settings, and proxy settings BDD 2007 Documentation, “User State Migration Feature Team Guide.doc” 17 BDD 2007 Documentation, “User State Migration Feature Team Guide.doc,” p. 14 18 ® 2007 ScritpLogic® The Expert’s Guide to Implementing 19 Microsoft® Windows® Vista™
  21. 21. 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 which items will be migrated. As with applications state migration, document which of these items will be moved during the upgrade. Develop and Test User state migration plans should be handed off to the testing teams to test the migration scripts. As mentioned in the Test planning section, testing in an accurate lab setting reduces surprises during deployment. Summary Migrating to Vista could quite possibly be the largest project an IT organization has ever undertaken. If migration is years away, or will take place over the next few years, it is advisable to be proactive and put a 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 (Systems Management 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 a third-party desktop management toolset in place, check with the vendor(s) to get the details on Vista migration. For example, ScriptLogic, Altiris, and LANDesk have been working with Vista beta releases for several years, and their products are already Vista compatible. Most of these vendors offer tools that allow 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 management teams within the organization; upgrading to Vista when a desktop is replaced makes a lot of sense. Resist the urge to make a wholesale upgrade within the organization—Vista migration is a big enough challenge without trying to tackle the entire enterprise at once. ® 2007 ScritpLogic® The Expert’s Guide to Implementing 20 Microsoft® Windows® Vista™
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×