资料来源：Gartner.
Many organizations are skipping Vista and looking forward to Windows 7. This research provides the necessary steps to prepare for Windows 7 and ensure a successful migration with adequate operating system (OS) support.
Key Findings
. Preparation is essential for a successful migration. Most organizations will require 12 to 18 months to prepare for a Windows 7 migration.
. Organizations that have tested or prepared for Vista and have good management systems and processes could complete the preparation process in 12 months.
. Complex environments will face additional issues and require more time.
Recommendations
. Allocate sufficient time and resources to upfront activities to lower the costs during migration.
. Although your planned migration may be more than a year away, don't delay the initiation of the preparation process.
. Form a project committee that includes members from each major business unit, as well as operational groups in the IT organization, to oversee the development of a project timeline that features high-level milestones and estimates required resources.
. Establish a formal, comprehensive and workable testing methodology to ensure that issues are identified and categorized.
. Plan on piloting for a minimum of three months. The shorter the pilot, the more problems will occur during the deployment.
1.0 Preparation and Education: Three Months
Organizations should establish a project committee and develop an overall project timeline. The project committee should include members from each major business unit, as well as operational groups from the IT organization. The project timeline should include high-level milestones and estimates of required resources. Companies must obtain a detailed inventory of the user environments, including hardware, software and processes. Without this, planning and testing will be hit-or-miss, based on IT perceptions, rather than reality. Although many companies have a general handle on the PCs in their environments, most have more difficulty with the other components. A full inventory will include the following areas:
1.1 PC Hardware
Although organizations should primarily install Windows 7 on new equipment, having a complete inventory sizes up the problem and provides guidance as to the order in which users are likely to be migrated. Organizations that have skipped Vista will probably need to perform some forklift upgrades, and will find that a detailed PC hardware inventory is even more essential. The inventory will also help identify deviations from corporate standards, and should identify where user data is being stored.
Along with basic configuration, age and model information, the inventory should also include more-detailed data (for example, BIOS levels, memory and disk space), as well as installed components (for example, adapter cards and chipsets). The Windows 7 Hardware Assessment tool can help identify potential issues. For the most part, systems purchased since early 2007 (machines that were released after the introduction of Windows Vista) should have no problems running Windows 7, unless they were poorly configured.
Decide which machines to upgrade based primarily on their age and secondarily on their configurations. If PCs purchased in 2009 and 2010 are chosen for upgrade to Windows 7 in 2011, their configurations won’t really matter. Unless your migration costs are extremely low, don’t plan to upgrade any PC that has less than two years of useful life left before replacement.
1.2 Attached Peripherals
Even when PCs are replaced, attached devices are frequently retained. These may include monitors, specialized keyboards and mice, external storage devices, printers or other items that require supporting drivers. Business-critical devices (i.e., essential to the completion of a business function) should be identified. Fortunately, most devices supported on Windows Vista carry that support directly to Windows 7. This means that, for most organizations, only older legacy devices are likely to pose an issue for Windows 7. Device driver compatibility should be somewhat less of a problem with Windows 7 than it was initially for Vista. Only a complete inventory of peripherals can expose potential problems. If your plans include installing 64-bit Windows 7, expect to find more legacy devices without suitable drivers. This will require budgeting for their replacement, and adding time to allow for the additional work.
1.3 Applications
A software inventory must include all applications and utilities installed on corporate PCs. Many software inventory tools exist, including Microsoft’s free Application Compatibility Toolkit (ACT) 5.5. It is not sufficient to restrict testing to “formally supported”applications, because users’ opinions may differ significantly from those of the IT organization, resulting in substantial delays during implementation. All applications should be categorized into four buckets: business-critical, user-critical, support tools/utilities and all others. A weighting should be added that establishes each as broadly deployed, narrowly deployed or specialized. All business-critical applications must be determined to work on Windows 7, while all user-critical applications must operate or have reasonable workarounds. Because most support tools will require a new version after an OS change, replacements or upgrades must be identified for each utility.
1.4 Processes and Procedures
Although not typically considered an asset, the processes and procedures that an organization has created to make the user environment functional are likely to be affected by an OS change. Hence, it’s critical that organizations document all the processes associated with outfitting their users. This should also include a list of policies, including group policy objects (GPOs).
During this initial phase, organizations should create a testing facility/laboratory. It should include a representative sample of systems expected to be used with Windows 7 throughout the organization. Although it’s impossible to have one of everything, any hardware combination used by more than 5% of the user base or part of a business-critical function should be represented.
During this phase, key members of the technical team should begin using Windows 7 (final code should be available to corporate customers in September 2009, or in August under programs such as MSDN and Technet) as part of their daily routine, followed by most IT staff. This leverages the most technically competent (and least likely to be seriously impaired) employees to spot potential problems. It also serves as an informal training ground.
2.0 Development: Three to Six Months
The replacement of the OS is an opportunity to update the user environment and implement best practices. As such, it is good to survey the stakeholders (e.g., user groups, developers and IT support) to determine whether there are pain points or other issues that must be addressed. With this feedback and the complete inventory, four separate development areas must be addressed.
2.1 Windows 7 Administrative Environment
Organizations already using Windows Vista should find that little change is required for Windows 7. For the most part, all GPOs and administrative processes function the same for Windows 7 as they do for Windows Vista, with a few additional options. Organizations currently on Windows XP will require more-extensive changes. Using Windows XP processes as a starting point, organizations must identify where Windows 7 5 administration will deviate. Organizations must examine the new features and capabilities within Windows 7 and determine a response. They will also need to become familiar with new GPOs introduced with Windows 7, as well as those that came with Vista.
Determining the deployment techniques that will be used is a critical decision. Even organizations bringing in Windows 7 on new equipment need to review image distribution, software deployment, and migration processes for data and settings. Organizations should also familiarize themselves with newer options, such as application virtualization, which might be appropriate for some applications.
Organizations also must identify the implications of leveraging new administrative capabilities in Windows 7 and plan to address these issues. This goes beyond changes to the administration tools built into the product; it extends to third-party tools that are likely to require an update.
2.2 Windows 7 User Environment and Standards
Organizations need to determine guidelines for hardware selection. Although Microsoft has provided general hardware recommendations, these must be interpreted with respect to corporate standards and procurement practices. Organizations should review our regularly updated hardware configuration recommendations.
Companies must also revisit the question of lockdown for their user environments, given the improvements in this area provided with Windows 7. Again, organizations that have skipped Vista are likely to have more to do to prepare for a more locked-down environment, but even organizations running Vista will need to decide if any changes are required, based on the new user account control levels in Windows 7.
2.3 Image Development
The final and most-critical piece of the development process involves the creation of an initial master build for a corporate user environment. This will include all the common elements included in a corporate desktop PC (for example, major applications, management utilities, security, and anti-malware tools and communication tools). It will be used for initial application testing, user pilot testing and as the basis for further customized builds.
2.4 Infrastructure impacts
Windows 7 adds a number of new networking and operational capabilities such as Direct Access, Branch Cache or Federated Search, which could have server dependencies and significant networking impacts. These will require additional planning and education to determine whether they are compatible with your infrastructure and, if so, how to properly integrate them into the environment. For example, the BranchCache feature may improve your software distribution capabilities, but the content that users access must be on Windows Server 2008 R2.
3.1 Lab Testing
It is impossible to test all combinations of hardware and software within any major organization. Most large enterprises can pare down the number of permutations by finding common system patterns. For configurations that cannot be represented in the laboratory, unless some business-critical external force is at work, a “test in production”methodology will generally suffice, assuming that high-level testing has been performed on similar configurations.
The way PC activation works for volume license customers changed between Windows XP and Windows Vista (and, by extension, Windows 7). During testing, enterprises should ensure that they are familiar with the volume activation options and include them in testing scenarios.
Application testing can be conducted concurrently with initial hardware testing. For each product, a formal checklist of test parameters and goals should be created, containing five sections:
• Installation: Does the application install cleanly or are tweaks required?
• Basic functionality: Does it start up, and do major functions work?
• Advanced functionality: Do specialized or rarely used functions, such as macros, perform?
• Interoperation and interaction: Does the application coexist with others, do communication and data interchange functions still work, and has the user interface changed?
• Performance: Does the application behave differently, and have hardware requirements changed?
Regression testing (that is, testing against previously discovered problem scenarios) is critical to ensure steady progression to a release candidate. Test scenarios should be built using help-desk records and notes from previous testing exercises. Reintroducing old problems will severely damage the IT organization’s credibility and turn an otherwise successful implementation into a failure. During testing, any anomaly or change from the current version must be recorded. This implies that the tester is somewhat familiar with the current environment.
Deeper functionality testing is likely to require the participation of a user or a developer to create a formal script. IT groups should prioritize the application testing order based on the breadth of deployment, with the most widespread handled first. This will speed up the process of shifting to full image design and testing. Companies should also consider the ability to run applications in a reduced-rights user environment.
One difference between Windows 7 testing and previous versions is the availability of richer and more mature testing tools. Acresso’s Installshield and Symantec’s Wise Installer include capabilities to detect and mitigate conflicts between applications and the OS.
Microsoft’s ACT 5.5 has emerged as a solid tool for finding potential issues with application and device compatibility. It can be run on Windows XP systems to help triage the testing effort, enabling organizations to better allocate resources during testing and remediation. Customers should download and familiarize themselves with the ACT.
The Microsoft Deployment Toolkit (formerly known as the Business Desktop Deployment Toolkit) has also been expanded to include more tools and best practices. Testing tools that continually look for incompatibilities with new versions of Windows, as well as Service Packs, are available from such vendors as App-DNA and ChangeBASE.
Two areas of special concern for testing that might be overlooked are testing browser-based applications for compatibility with IE8 and testing applications in a 64-bit environment. With Vista, customers reported the most serious and often most difficult to remediate compatibility problems with IE6-targeted Web applications failing under IE7. This situation is unlikely to improve with IE8 in Windows 7. We strongly recommend that customers begin this phase of testing as early as possible, because remediation efforts may require recoding or adding virtualization to their environments. On the 64-bit front, it is likely that, by 2011, some users may require 64-bit support for their environments. Adding a 64-bit test environment will identify potential issues early, and, although it will add some additional effort, it will not seriously complicate the testing process.
Once application testing is well under way, attention must be turned to the development and testing of system images. This testing includes the same five categories as for applications, with particular attention given to interaction and installation. Image testing requires matching images to particular hardware configurations, and is likely to demand the largest effort. Device drivers for legacy peripherals must also be validated, especially if you’re implementing 64-bit. Once the first few images are completed, subsequent ones will require a minimum of three days to create, followed by a day or more of testing.
The final area is the testing of internal processes. Many well-established procedures and policies will need fine-tuning or outright replacement with Windows 7. Particular attention should be given to migration processes, moves/adds/changes and ongoing support processes (for example, software distribution and system backup/recovery).
4.0 The Pilot Test Phase: Three to Six Months
Once formal lab testing is done, pilot testing should begin. Piloting moves the testing out of the lab and exposes real users to the new environment. Most pilots should consist of at least two phases. The first should test basic builds, establish training needs, gauge general user reaction and enable IT staff to exercise their new Windows 7 skills. This pilot should be limited to a small group of users (fewer than 50) that does not perform mission-critical (or high-profile) activities, and should optimally last for 45 to 90 days.
Following this, a second, broader pilot extends the first by field testing installation and support processes within a production (but still closely monitored) environment. The broad pilot should optimally run an additional 45 to 90 days to ensure that the pilot tests extend across several different business process cycles (for example, month-end and quarter-end).
For most organizations, a three- to four-month piloting period will be sufficient; however, those with more-complex environments, or those that encounter significant problems in early testing, may need to run for the full six months.
In many cases, organizations may be tempted to cut back on piloting to speed the overall timeline. Although both phases of the pilot could be completed in as little as two months, shortening the pilot period increases the likelihood that some underlying issues will not be encountered until the production rollout phase, when making repairs is more disruptive.
Once the piloting process has been completed, the preparation process is effectively completed. Organizations can then conduct staged rollouts of the OS to their user populations. Critical to all testing and piloting is ensuring that a suitable feedback mechanism is in place.
5.0 Bottom Line
A formal testing process significantly smoothes the Windows 7 migration path by enabling companies to spot potential problems, adjust designs to better leverage new features and build experience with the nascent platform.
本文转simmy51CTO博客，原文链接：http://blog.51cto.com/helpdesk/301433，如需转载请自行联系原作者
