Windows Server 2003 on HP ProLiant Servers : The Pilot

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

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

• Verifying the supportability of client hardware

• Defining AD features to be used (no additional features added during the pilot)

• Identifying a representative cross-section of users and groups in terms of location, security access, applications, and business association

• Defining client OSs supported

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

• 50 Information Technology Users located at the General Office and the West Annex

• 40 Users from Various Business Units located at the General Office

• 20 Users from Various Business Units located at Charlie Brown Airport (OEL)

• 20 Users from Various Business Units located at the TMC (Confederate Ave.)

• 20 Users from Various Business Units located at Forest Park (OMR)

• 20 Users from Various Business Units located at District 1 (Gainesville)

• 20 Users from Various Business Units located at District 2 (Tennile)

• 20 Users from Various Business Units located at District 3 (Thomaston)

• 20 Users from Various Business Units located at District 4 (Tifton)

• 20 Users from Various Business Units located at District 5 (Jesup)

• 20 Users from Various Business Units located at District 6 (Cartersville)

• 20 Users from Various Business Units located at District 7 (Chamblee)

• 20 Users from 2 Area Offices (10 Users each) located in the Cartersville District

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:

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:

• The pilot users will be supported by members of the pilot team, the help desk, and client support.

• The pilot team will act as a second-tier support group to resolve issues that occur and cannot be supported and resolved via normal resolution channels.

• All support requests will be logged into Remedy to allow for tracking and better resolution maintenance.

• All application support issues that originate at the application support group level will be handled by the pilot team to determine whether a Group Policy problem exists.

• A Web site has been developed to include a FAQ section, which will be used by pilot participants and support team members for problem resolution.

• All server support personnel will have access to an Operations manual for AD that has been developed and is currently being expanded.

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

• Application name, version(s)

• Reported/resolved problems

• Deployment method

• Group Policies applied

• Support path

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:

• Test applications with simple compatibility on Windows 2000 and XP (this will vary depending on the OS you are supporting in your environment).

• Apply the “basic” GPO and test the applications in this environment.

• Apply additional GPOs that will apply to each application. Do this systematically.

• Apply these GPOs to all business unit OUs in the production environment.

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:

• Establish a specific help desk for the pilot users. Don't just use the normal help desk. This limits the scope of whom you have to train and who has access to the IT staff. This also allows communication of pilot issues to occur more easily.

• Determine how the help desk and clients will communicate with each other. Methods might be e-mail, a Web application, or a phone call to a special number for the pilot. Consider what the users use now and build on that. Making them call a phone number when they are used to logging cases via the Web will be confusing and frustrating for the users.

• Facilitate support and knowledge transfer between help desk staff and the IT staff.

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:

• The standard Windows NT 4.0 domain will not be collapsed until all users (4,700) have been migrated to AD so that in the event of a large-scale failure, the users participating in the pilot could be rejoined to the original domain and continue to perform their normal duties.

• A detailed backup and restoration plan is included in the AD Operations manual to allow for recovering a DC failure. This procedure will be available at all offsite locations to allow for a recovery in the event of a catastrophic failure.

• If application issues occur from Group Policy objects and they cannot be resolved within 72 hours, the faulty policy will be deleted. During the 72 hours, the policy will be removed from the offending OU so that normal work can continue.

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:

• Same or better functionality on the desktops

• Same or better functionality on the servers

• Training identified and executed

• AD plan successfully implemented

• Consistent downlevel client support

• Infrastructure shortcomings identified and planned modifications accepted