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:
| • IT users deployed | April 1 |
| • General Office users deployed | April 3 |
| • Charlie Brown deployed | April 5 |
| • TMC deployed | April 5 |
| • Forest Park deployed | April 5 |
| • District 1 deployed | April 8 |
| • District 2 deployed | April 10 |
| • District 3 deployed | April 12 |
| • District 4 deployed | April 14 |
| • District 5 deployed | April 16 |
| • District 6 deployed | April 18 |
| • District 7 deployed | April 20 |
| • District 6 Area Office deployed | April 18 |
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
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
