Windows Server 2003 on Proliants. Deployment Techniques and Management Tools for System Administrators
| < Day Day Up > |
| The pilot is a key component to any migration. This is the test bed for the design that has now been developed. The Georgia Dept. of Transportation (GDOT) has permitted me to publish the details of how it ran the pilot, and this section contains much of GDOT's design criteria and experience, as well as experience from the deployment of HP's pilot. The pilot is only required when migrating from Windows NT to Windows Server 2003. Because this is a complete change of technology with a brand new AD design, redesign of security groups, implementation of Group Policy, new security configuration, and many other changes in the environment, running a pilot allows a staged migration and mitigates the risk of failure. Migrating from Windows 2000 to Windows 2003, however, is usually little more than a simple upgrade. Both HP and GDOT indicated that the migration to 2003 did not require a new design or even new design docs. The migration plan's only speed bump was the process of raising the domain and forest functional levels. GDOT defined its pilot with the flowchart shown in Figure 6.21. Figure 6.21. Process flow for GDOT's pilot.
Requirements and Goals
When designing the pilot, you can't test for every possible condition. It's important, therefore, to state the requirements and goals up front and operate within a well-defined scope. Requirements might include
Define the scope by setting expectations of what the pilot will and will not accomplish. Use detailed, objective lists so that success can easily be measured. The Pilot Plan
In the Windows NT-to-2000 migration, HP found two basic approaches to deploying a pilot: an integrated pilot and an isolated pilot. The isolated pilot is configured, used in the pilot testing, and then torn down. This is more expensive and time-consuming , although the pilot infrastructure could be converted to become the test lab. The integrated pilot becomes the production infrastructure. Thus, the pilot becomes phase one of the migration. HP used the integrated pilot approach. User Selection
Create a representative cross-section of users. In addition, define user technical level ”some companies prefer to use "computer savvy" users in their pilot because they are more tolerant of the testing process and are easier to guide through problem resolution, taking some of the heat off of the help desk. On the other hand, these users tend to fix things themselves without asking for help. GDOT defined the its pilot users as
Note that this represented only about 6% of the total users and that the sole criterion for selection to the pilot program was the OS the users were running. GDOT included desktops and laptops, as well as Windows 95, 98, 98SE, and NT workstation OSs to ensure that all possible configurations were tested . Schedule
A schedule should be defined to deploy users to the pilot domain in phases. The phases can be defined by location, type of user, client hardware, security group, and so on. Leave sufficient time between these phases to obtain and evaluate the health of the AD, resolve authentication and access issues, and so on. The following schedule shows a summary of GDOT's deployment schedule:
Of course, a deployment schedule is much more complex than this summary, and you should use something like Microsoft Project or other Gantt Chart products to track progress and develop schedules for reporting progress to management and for your own use in project management. Chapter 3's section "Building a Business Case" discusses using Gantt Charts, including a Web site at http://associate.com/gantt/, which provides a free interactive tool that allows you to input the information for the chart in a form to produce the chart. Support
Define a support plan for the pilot users. This usually involves creating a separate help desk team trained to handle potential user issues who can notify the IT staff quickly if necessary. Define tools, internal processes, and problem escalation procedures. GDOT's support plan included the following points:
Again, the support plan should be well documented and approved by appropriate management to ensure the success of the pilot. If the users get frustrated, and can't get problems resolved in a timely manner, which in turn affects their productivity, it will have a very negative impact on the success of the pilot. Application Test Plan
During the pilot, it's important to test applications in the new environment ” especially home-grown and mission-critical applications. Third-party apps, including Microsoft applications, should be tested as well. Many Administrators I've talked to indicate that they check third-party apps to determine whether they are compatible with the OS, but then make sure they test the applications in the test lab or pilot environment to make sure they work as expected for the users. Build a test matrix and ensure that when you select the pilot users, you select users who can test the desired applications as part of their daily work. You don't want any surprises when the users start to work in the production environment. A test matrix might include
GDOT did a lot of application testing around the application of GPOs to users who would use the applications. GDOT's testing program included the following points:
Communications Plan
Some means of communicating with the pilot users needs to be established. It might be as simple as an e-mail distribution list or a more complex Web site that can provide information and accept user input. Again using GDOT's plan, consider the following points:
Rollback Plan and Contingencies
A contingency plan should be created to define the procedure to follow in the event of a major failure. The purpose of this plan is to get the users back into a production environment until the pilot problems can be resolved. Because part of the migration plan calls for a rollback plan, you might also want to test that rollback plan as part of normal pilot testing. GDOT's rollback plan consisted of the following points:
Documentation and Tools
The pilot should be well documented. Each phase of the pilot should be assigned to an IT staff member who is responsible for documenting successes as well as failures. This will prove to be valuable information in tweaking the migration plan or making configuration changes, such as applying updated drivers, hotfixes, and so on in preparation for starting the actual migration. Tools can include migration tools, monitoring tools, and diagnostic tools. These tools should be tested to ensure they produce expected information and are installed and configured appropriately. Evaluation
At the conclusion of the pilot, as well as at key points during the pilot, the responsible members of the IT staff should meet to evaluate the success of the pilot in meeting the objectives stated in the beginning. At this point, a decision to go forward or to retreat and make necessary changes should be made. GDOT evaluated their project success on the following points:
|
| < Day Day Up > |