Active Directory Migration

Planning

Prepared for
Cornell University
Tuesday June 23, 2011
Version 1.2

Final

Prepared by
David Thompson
Infrastructure Consultant
David.Thompson5555@idea.com

Prepared For Cornell University00

IDEA INTEGRATION MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS DOCUMENT.

Complying with all applicable copyright laws is the responsibility of the user. Without limiting the rights
under copyright, no part of this document may be reproduced, stored in or introduced into a retrieval
system, or transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or
otherwise), or for any purpose, without the express written permission of Idea Integration Corporation.
Idea Integration may have patents, patent applications, trademarks, copyrights, or other intellectual
property rights covering subject matter in this document. Except as expressly provided in any written
license agreement from Idea Integration, our provision of this document does not give you any license to
these patents, trademarks, copyrights, or other intellectual property.
The descriptions of other companies products in this document, if any, are provided only as a convenience
to you. Any such references should not be considered an endorsement or support by Idea Integration.
Idea Integration cannot guarantee their accuracy, and the products may change over time. Also, the
descriptions are intended as brief highlights to aid understanding, rather than as thorough coverage. For
authoritative descriptions of these products, please consult their respective manufacturers.
2009 Idea Integration Corporation. All rights reserved. Any use or distribution of these materials without
express authorization of Idea Integration Corp. is strictly prohibited.
Idea Integration and Windows are either registered trademarks or trademarks of Idea Integration
Corporation in the United States and/or other countries.
The names of actual companies and products mentioned herein may be the trademarks of their respective
owners.
Page ii

Prepared For Cornell University00

Revision and Signoff Sheet

Change Record
Date

Author

Version

Change reference

06/14/1
1

David
Thompson

1.0

Initial Draft

06/23/1
1

David
Thompson

1.1

Internal Review

06/30/1
1

David
Thompson

1.2

Final Version

Reviewers
Name

Version
approved

Chris
Lavelle

1.1

Position

Date
06/26/2010

Page iii

2010 Idea Integration

Prepared For Cornell University00

Table of Contents
1.

Introduction....................................................................5

1.1 Executive Summary.................................................................................. 5

2.

Intended Audience...........................................................6

3.

Migration Overview.........................................................7

3.1 Migration Challenges................................................................................ 7

3.2 Key Features of Quest Migration Manager for Active Directory.................8
3.3 Migration Process Overview....................................................................10
3.4 Team Composition.................................................................................. 10

4.

Current Active Directory Infrastructure...........................12

4.1 CORNELL.EDU......................................................................................... 12
4.2 Additional Forests/Domains....................................................................12
4.3 Development/Lab Environment..............................................................13

5.

Areas of Remediation.....................................................14

5.1 Ongoing Virtualization and Exchange Migration Projects........................14

5.2 Existing Microsoft SharePoint Deployments............................................14
5.3 Existing Microsoft System Center Configuration Manager Deployments 14
5.4 Existing Microsoft SQL Server Deployments...........................................14
5.5 Existing Microsoft Windows Server Update Service (WSUS)...................14
5.5 Certificate Services................................................................................. 15
5.6 Centralized Backups Tivoli Configuration Manager..............................15
5.7 Schema Extensions (Biometrics)............................................................15
5.8 Workstation Rename Requirement.........................................................15
5.9

RADIUS Authentication Proxy Policy....................................................15

5.10 Deployed VPN Solutions.......................................................................15

5.11 Stand-Alone Workstation Migrations.....................................................15

6.

Planning Recommendations............................................17

Appendix A: Sample High Level AD Migration Project Plan.....18

Page iv

2010 Idea Integration

Prepared for Cornell University

1.

Introduction

Cornell University is moving toward establishing a rationalized IT architecture

which will provide an Enterprise Shared Services platform for common services
such as authentication, messaging and collaboration. The Active Directory
Migration Project is being undertaken to provide the base infrastructure on which
these services will be provided. In addition, creating a Centralized Data Center
Support Model for a campus-wide virtualized Server Infrastructure is a key costsaving driver being undertaken at the University and is directly linked to the
Active Directory Migration Project.

1.1

Executive Summary

The objectives of this engagement, as indicated in the Statement of Work, are

to deliver solution recommendations with consideration for the following items
of scope and drivers to the business:

Gather and review the existing Active Directory Forest and Domain
implementation and associated documentation provided by the
client.

Review the various approaches for consolidation and make

recommendations of risk mitigation strategies and tool selection.

Generate an executive report outlining high level consolidation

approach, activities, and toolsets.

Generate high level work effort, tasking, and timeline for domain
consolidation effort.

As part of the Universitys Server Virtualization Project, the support model

dictates all virtualized servers be member servers of the cornell.edu Active
Directory Forest/Domain. Scheduling has already begun for some of the 70+
domain across the campus to virtualize their server infrastructure. It is
imperative that a coordinated Active Directory Migration Project schedule be
prepared and implemented in support of this Server Virtualization Project. The
transition for Cornell University to function in this centralized environment will
introduce the following challenges:

Operational Complexity The CIT Identity Management Staff will now

be responsible for all AD administration of domain controllers and all
Active Directory functionality (mainly security related). Organizational
Unit (OU) Administration delegation is in place to allow individual IT groups
across the University to manage their own OU infrastructure relating to
User/Group administration as well as rights/permissions to resources.

Page 5

2010 Idea
Integration

Prepared for Cornell University

2.

Enterprise Applications- Schema Extensions, LDAP authentication, etc.

will all occur under this centralized Active Directory environment. More
design and policy creation may be required to produce a uniform way of
Enterprise Applications existence in this environment.
Agility - Growth and restructuring are part of normal operations for
Cornell University. The IT infrastructure needs to handle these events as a
more natural part of the IT ecosystem instead of as a major exception to
the IT operations. Organizational restructuring should not alter the
structure of the directory service.

Intended Audience
This document was written for and intended for Cornell University IT staff
and supporting personnel. It is designed as a guide and roadmap for the
development of an Active Directory Migration Plan at Cornell. All Cornell
University IT staff and supporting personnel should be familiar with the
concepts and terminology that follows in this document.

Page 6

2010 Idea
Integration

Prepared for Cornell University

Page 7

2010 Idea
Integration

Prepared for Cornell University

3.

Migration Overview

Active Directory migrations can be monumental tasks. This is especially true for
large distributed and complex environments as discovered at Cornell University.
It is essential that a solid discovery and analysis be completed on the entire
enterprise prior to migration. All testing should be performed in an environment
that mirrors the production environment as exactly as possible. Cornell
Universitys lab environment will be a key asset in this testing. Although no two
migration projects are exactly the same, utilizing industries best practices and
partnering with an experienced solutions provider will greatly enhance the
chances of completing a successful migration.

3.1

Migration Challenges
Size and complexity A restructuring project requires you to manage
change to a large number of users and resources. Cornell University has
70+ domains to consolidate ranging from several thousand users and
dozens of servers to domains with only a few dozen users and a handful of
servers.
Impact on users Ideally, changes to your directory should occur
without disrupting user productivity or requiring calls to the various help
desk for support. Users should not need to log off, and they should
continue to be able to access all appropriate resources during and after
the restructuring project. Scheduling off-hours workstation migrations at
Cornell could further reduce the impact on faculty and staff.
Double administration during the transition period When
executing inter-forest migrations, theres inevitably a period of time when
both old and new environments are intact. For some of the larger Service
Areas/Colleges, it might take a considerable amount of time before
everyone is migrated and the old environment can be decommissioned.
During that time, any changes made in one directory have to be made in
the other as well.
Limited IT resources A restructuring project can stretch your
overworked IT department. Administrators might need to work nights or
weekends. Overtime might be needed, and the restructuring project could
drag on for many months.
Lack of tools Native tools and most third-party tools do not handle all
aspects of Active Directory restructuring. Active Directory does not include
tools to automatically merge two or more domains, split domains, move
objects between domains and forests, or perform other Active Directory
reconfiguration procedures. In addition, native tools and most third-party
tools do not migrate all types of Active Directory objects and attributes.
Nor do they update permissions across all platforms such as Exchange,
SQL, and Active Directory. You might face several restructuring issues that
cannot be addressed with your existing tools.
Risk Changes made directly to your production Cornell.edu environment
can be risky. You need a way to restructure your directory that also allows
you to preview and test your changes before applying them to your
Page 8

2010 Idea
Integration

Prepared for Cornell University

network. You also need a way to selectively roll back changes if something
unexpected occurs.
Security concerns During restructuring, existing security measures,
such as passwords and permissions, must be preserved. To maintain a
secure environment, you need to clean up SIDHistory and track and delete
source objects that have been migrated. These tasks are not easily
accomplished with native tools.

3.2 Key Features of Quest Migration Manager for Active

Directory

ZeroIMPACT on Users Migration Manager for Active Directory provides

Active Directory restructuring with no disruption to users or your network.
Migration Manager for Active Directory performs restructuring activities
while allowing users to maintain uninterrupted access to all their
resources, regardless of whether the resources are being moved. Users
can be migrated while they are online, and they dont have to reboot their
computers or log in and out of their accounts after the move.
Directory Synchronization Migration Manager for Active Directory has
built-in synchronization capabilities to ease the burden of coexistence. It
can synchronize account properties, group membership, and even
passwords (even though this is not required in your environment), so
administrators can simply make necessary changes in one environment
and have those changes automatically replicated to the other
environment. This reduces the administrative burden and improves
security by keeping the environments consistent.
Test Mode A migration session can be executed in test mode. In test
mode, Migration Manager for Active Directory attempts to actually perform
the migration but does not create/merge the accounts in the Cornell.edu
target environment. During this test, the tool detects most of the possible
issues with the migration, including lack of permissions, matching
conflicts, and missing linked objects (such as group members). This lets
you safely experiment with migrations and resolve issues so they do not
arise in your real migration.
Centralized Project Management Migration Manager for Active
Directory gives administrators control of the migration project. Features
include:
o
Delegation of permissions over the migration project. For
example, a local administrator might get read-only access to the
project but full control over a task to migrate a set of OUs. This is not
normally used, but wanted to mention it in case during the planning of
the migrations it becomes an option we want to implement.
o
Online queues for errors, matching conflicts, and missing
linked objects (e.g., missing group members). Migration
Page 9

2010 Idea
Integration

Prepared for Cornell University

Engineers can check the queues and take corrective actions for
problems. One option is for Migration Manager for Active Directory
keeps trying to perform the synchronization. Once the issue gets
resolved, Migration Manager for Active Directory automatically
synchronizes the objects.
o
Statistics portal. Migration Manager for Active Directory ships
with Statistics Portal, which provides Web-based reporting and
monitoring of the migration project. It provides both high-level
statistics information and low-level migration details. With this tool it is
easy to give read-only access to the migration information to anyone
involved in the project. This tool requires additional setup
requirements if it is deemed that this level of reporting is needed.
Task Delegation Migration Manager for Active Directory was created
with large-scale migration projects in mind. Features include:
o
Role-based administration. Migration tasks have permissions
associated with them. As we discussed a possible multi-team approach
at Cornell, migration projects can be split between migration teams
without risk of interfering with each others project tasks.
o
Replicated project database. Migration Manager for Active
Directory uses Microsoft Active Directory in Application Mode (ADAM) as
its backend database. Because ADAM has built-in replication and
support for Active Directory security model, you can now set up
Migration Manager for Active Directory in multiple locations, give each
team permissions for their parts of the project, and set replication so
that all these migration tasks are still accomplished within the same
common project.
Integrated Product Set Since Migration Manager for Active Directory
was designed specifically for Active Directory restructuring, you can
migrate any type of object including sites and subnets, contacts, printer
queues and volume objects. You can migrate all object attributes,
including passwords, security descriptors, and linked attributes.
Synchronization and scheduling is integrated into the tool so you dont
have to use the command line or set up Windows Scheduled Tasks. Also
included is a resource kit with utilities that assist with restructuring tasks
and further minimize the impact to users. The GPO migration tool is one
example of a provided utility that would assist in the consolidation of the
domains into their respective OUs within Cornell.edu.
Comprehensive Resource Update To ensure that users retain access
to network resources during and after restructuring, Migration Manager for
Active Directory provides comprehensive resource updating. After
migration, you must update network resources to apply the permissions
from source objects to target objects. Migration Manager for Active
Directory can process all files and folders regardless of the permissions or
ownership. It can update all resources, including:
o
Distributed resources such as files, folders, services and user
profiles
Page 10

2010 Idea
Integration

Prepared for Cornell University

Security descriptors of Active Directory objects

Microsoft SQL Server version 7.0, 2000, 2005, and 2008
permissions
o
Microsoft Internet Information Services (IIS) Server version 4, 5,
and 6 permissions
o
Microsoft Systems Management Server 2003 and System Center
Operations Manager 2007 permissions
Migration Manager for Active Directory updates resources quickly and
efficiently by performing resource update locally. In addition, it updates
permissions for all migrated users and computers at the same time, even
if they were migrated from different source domains. Migration Manager
for Active Directory also allows you to schedule resource updating for offpeak hours and to retry at specified intervals if a computer is offline.
Granular Undo Capabilities Migration Manager for Active Directory
offers several undo options so that you can quickly roll back changes
should something unexpected occur as a result of restructuring. You can
roll back any change youve made, from changes made in several sessions
to a single operation on a single object. As you migrate objects, a project
database captures all the changes made in the target Cornell.edu domain
by any migration session, and the source domain remains untouched until
disabled or deleted. All resource update tools have revert mode, in which
they restore source permissions in resource ACLs.
Post-Migration Cleanup Migration Manager for Active Directory
provides several options and tools to ensure maximum security, integrity,
and performance of your restructured environment. To make sure that
resources are accessed properly after restructuring, Migration Manager for
Active Directory allows you to delete SIDHistory entries for migrated
accounts and remove references to source accounts from ACLs. Migration
Manager for Active Directory also provides options to disable or delete
source accounts and clean your network of any unused objects that could
affect the security and stability of your environment.

o
o

3.3

Migration Process Overview

The steps outlined below are meant as a high level overview of the migration
process. Planning, Discovery, and Pre-migration tasks (service account creation,
establishing two-way trusts, disabling SIDHistory filtering, etc.) are also critical
components of a successful migration that will be listed in greater detail when a
migration plan is put in place for the migration of a source domain to the target
Cornell.edu domain.

Account Migration Selected accounts are merged (through the use of a

mapping file) from selected source domains to the target Cornell.edu
domain.
Ongoing Directory Synchronization For all or selected migrated
accounts, synchronization can be established so the account properties,
including group membership are kept in sync for the coexistence period.
Page 11

2010 Idea
Integration

Prepared for Cornell University

3.4

This is a requirement if QMM is being used for an Exchange migration as

well. In Cornells environment it may not be necessary for directory
synchronization to be used. More detail on this will appear during
discussions of an actual migration planning session.
Resource Processing Access permissions to files, shares, printers, and
other securable objects are updated. This can run multiple times if
needed. We will need to follow up on the testing of the TSM Backup agent
to determine best approach.
Switching to the New Domain Source accounts are disabled, if
possible to prevent users from continuing to log into the source domain.
Users begin using their Cornell.edu (NetID) accounts and passwords to log
into the Cornell.edu domain.
Post-Migration Cleanup Source accounts are cleaned up and deleted
and SIDHistory is removed for all target accounts to ensure maximum
security, integrity, and performance of the target environment.

Team Composition

The team member descriptions outlined below identifies critical skillsets required
for a successful Active Directory Migration Project:

Project Manager As with any major project, having the right person(s)
in the Project Manager role is a major reason for the success or failure of a
project. Using proven project management framework (ITIL, MSF, etc.) will
assist in the successful tracking of assigned tasks and deadlines, as well
as, risk management and sign-off when exiting major milestones.
Providing timely status reports will alert management to any critical
issues, resource constraints, or budgeting/burn rate concerns. Past
migration experience is helpful but not a requirement. Working closely
with the Technical Project Lead can overcome lack of migration
experience.
Technical Project Lead This person acts as the Subject Matter Expert
(SME) for the entire migration project. Works closely with the Project
Manager for assignment and scheduling of tasks. Attends technical, as
well as, non-technical meetings. Acts as the liaison between IT
management and the migration engineers. Assist the Project Manager in
the kick-off meetings by giving a migration overview presentation,
addressing departmental concerns, and begins the discovery process for
each source domain scheduled for migration.
Migration Engineer This person(s) acts as the technical engineer.
Experience with the migration tools and having completed large scale
migration projects is a must. Responsible for the installation and
configuration of the migration tools. Works with IT staff to complete all
necessary setup (production and lab environment if possible), testing, and
successful test case completion. Will raise any concerns to the Technical
Project Lead for resolution and tracking. Will be responsible for the
Page 12

2010 Idea
Integration

Prepared for Cornell University

completion of the actual migration steps as related to the toolset. Will

ensure the health of the migration toolset and its related database.
Cornell IT Staff Member This person(s) will work with the migration
engineer during the entire process. Will need to have extensive
knowledge of the current production environment, as well as, knowledge
of the source domains targeted for migrations. Will work with migration
engineer and source domain IT staff in the completion of the pre-migration
tasks. Resolves any issues related to the target domain (permissions,
rights, availability, etc.).

Page 13

2010 Idea
Integration

Prepared for Cornell University

4.

Current Active Directory Infrastructure

During IDEA Integrations onsite visit, a brief overview of the current target
domain (cornell.edu) was provided. Meetings were held with a sampling of other
colleges/service areas that may become some of the first source domains to be
migrated. Again, brief overviews of these source domains were provided during
our meetings. A thorough discovery process would occur for each of these
source domains when scheduled for an actual migration project.

4.1

4.2

CORNELL.EDU
This is the current campus-wide forest/domain containing nearly 400k user
accounts.
It is currently running in native 2008 domain and forest functional levels.
There is one child domain (citstaff.cornell.edu) that is in the process of
being decommissioned.
All users, campus-wide, have an account (NetID) in this domain
provisioned by ILM. An instance of MIT Kerberos is in place for provisioning
of the NetID account and maintains password synchronization with the
cornell.edu domain.
The NetID account also serves as the authentication method for
CUWebLogin (access to most campus web applications).
Guests (users without a NetID) are provisioned in the cornell.edu domain
using a guest ID naming convention.
Campus wide Microsoft Exchange 2007 environment is contained in the
cornell.edu forest as well. Plans to upgrade to Exchange 2010 are in
place.
OU Administration Delegation has been set up using QUEST Active Role
Server (ARS) to grant College/Service Area IT staff rights to administer
their assigned OU upon completion of the consolidation effort.
All Domain Controllers are located within the campuses two data centers.
A possible third data center will be stood up for disaster recovery
protection and would contain additional Domain Controllers.

Additional Forests/Domains

As part of this engagement, Idea met with the following sampling of source
domains and support staff during onsite visit:

Facilities
S&O
AG & Life Services
Campus Life / Admin Services
Nanoscale / Johnson School of Management / Law School
Exchange Administration

Page 14

2010 Idea
Integration

Prepared for Cornell University

The information obtained during these productive meetings has assisted greatly
with the content and recommendations listed in this document.

4.3

Development/Lab Environment

There is a virtualized lab environment for the Cornell.edu domain built on

VMware technology. The QMM Console and Database are fully supported in a
virtual environment and as stated previously, the availability of this test
environment could prove crucial to a successful migration experience. Testing of
the migration process and completing the test cases and potentially more
important, the testing and sign-off of the source domain applications deemed
critical or high-risk, will build confidence in the migration process and greatly
assist in staying on track with the scheduling of tasks.

Page 15

2010 Idea
Integration

Prepared for Cornell University

5.

Areas of Remediation

A major component to the overall plan of a project is Risk Management. Risk

Management is the identification, assessment, and prioritization of risks followed
by a strategy to manage the identified risks. Avoiding the risk, reducing the risk,
or even accepting some or all of the consequences of a particular risk are all
examples of managing risks. The identified areas below are some of the risks
discovered during the onsite visit that will require some type of remediation. A
more complete Risk Assessment would be part of the actual project plan for the
Active Directory Migration Project.

5.1

Ongoing Virtualization and Exchange Migration Projects

There are several ongoing and planned projects at Cornell. The
introduction of more than one change at a time during a migration
project is not desirable and can lead to an unsatisfactory user experience.
Careful collaboration with the Virtualization and Exchange Migration
projects is imperative. Each separate project should have its own freeze
period by which no other changes are being made while the current
project is progressing. A strong project management presence is required
to ensure communications and tasks scheduling are completed and
documented.

5.2

Existing Microsoft SharePoint Deployments

While a co-existence period will be kept to a minimum, user experience
can be affected during this timeframe. SharePoint is a web-based
application and as such does not benefit from the use of SidHistory for
granting access to a particular workspace. New account access will need
to be granted prior to a users migration or the user will be prompted for
its username/password from the source domain until the SharePoint
deployment has been moved into the target domain (cornell.edu). There
have been some preliminary discussions about deploying a campus-wide
SharePoint.

5.3 Existing Microsoft System Center Configuration

Manager Deployments
During co-existence, workstations that have joined the target domain but
are still being managed by a SCCM deployment in the source domain will
lose some functionality. The ability to deploy by OU is a key limitation. A
campus-wide SCCM deployment project has started and would be the final
solution at some point.

5.4

Existing Microsoft SQL Server Deployments

Rights to databases on SQL servers that are assigned via domain accounts
will need to be updated during migration of the SQL servers when they are
joined to the target domain. This can be done via scripting or if an
automate toolset (QMM for AD) is being leveraged for the migration; the
Page 16

2010 Idea
Integration

Prepared for Cornell University

toolset should be able to automate this process through the SQL resource
update process.

5.5 Existing Microsoft Windows Server Update Service

(WSUS)
This is a minimal issue normally during a migration. If a campus-wide
WSUS server is available for use when the migrated workstations are
joined to the target domain, a simple update on the workstation to point to
the new WSUS server will be required. This can be done via Group Policy
Object (GPO).

5.5

Certificate Services
During the discovery process of the project, any deployed certificate
services will need to be addressed. Certain deployments (i.e. Wireless
Authentication) can be mitigated by the deployment of additional
Cornell.edu domain certificates. If an actual Certificate Authority has been
deployed in a source domain, coordination in the project plan will need to
be tracked to ensure a smooth transition to a deployed CA in the
Cornell.edu domain as well as any application utilizing certificates from the
source CA.

5.6

Centralized Backups Tivoli Configuration Manager

Coordination (or possible halting) of the workstation backup agent will
need to occur to ensure no interruption of the migration process.
Additional testing is taking place currently to determine behavior of a
newly joined workstation to the target domain and/or permission changes
of files and folders to document behavior of the backup post migration (full
backup vs. incremental).

5.7

Schema Extensions (Biometrics)

A decision paper and then eventually a campus-wide policy needs to be in
effect regarding the handling of Schema Extensions in the Cornell.edu
domain. For this particular extension, the use of other two-factor
authentication options could possibly allow the use of Biometrics to be
discontinued in the Cornell.edu domain.

5.8

Workstation Rename Requirement

All workstations joining the target domain will need to comply with the
campus-wide naming standard. This additional step can be performed
prior to, during, or post migration. The requirement during the discovery
phase of the migration project to produce an accurate workstation
inventory for each source domain usually means renaming workstations
prior to migration works most efficiently. Another factor in the Cornell
environment to take into consideration is workstations that utilize the TSM
Backup agent and the need to reload/update the machine names upon
being renamed within Tivoli.
Page 17

2010 Idea
Integration

Prepared for Cornell University

5.9

RADIUS Authentication Proxy Policy

If source domain accounts are being used to authenticate users via a
RADIUS deployment, steps need to be in place on the RADIUS server to
ensure target domain accounts are also searchable for authentication. If
universal NetID accounts are being used no further steps should be
required.

5.10

Deployed VPN Solutions

A decision paper and an eventual campus-wide policy should be in place
regarding the use of a campus-wide VPN solution or continue to allow each
college/service area to maintain their own VPN solution. Input from
Security would be required to ensure its policies are being met.

5.11

Stand-Alone Workstation Migrations

Workstations that are not currently joined to a domain would require a
simple join to the target domain. Updating their profiles on the
workstation would require some type of script or program designed for this
purpose. This would be a subset of tasks in the migration project plan
outside of normal migration activities. Idea would work with Cornell IT staff
in the development of this process and evaluate scripts/tools that would
provide the maximum benefit to completing this required task.

Page 18

2010 Idea
Integration

Prepared for Cornell University

6.

Planning Recommendations

The following recommendations are proposed for review and discussion:

Use of Quest Migration Manager (QMM) for Active Directory

Based on the size, duration, and complexity of this project, Idea strongly
recommends the use of a complete end-to-end migration solution inclusive
of the Quest migration tools. Key features and benefits of using QMM are
noted in section 3.2 of this document and address the migration concerns
noted in section 3.1. Use of this toolset will allow for a repeatable
migration process for each source domain targeted for migration that can
continually be refined during the entire Active Directory Migration project.
Commitment to Project Management (PM) As noted earlier in the
document, Idea would recommend (require) dedicated PM(s) to the
migration project. This is essential to a successful migration.
One Migration Team vs. Multiple Migration Teams This is normally
dictated by balancing cost versus project deadlines. A migration team
(composition listed previously in document) can handle up to three source
domain migrations in different phases of the migration process (one in premigration, one in active migration, and one in post-migration). If two
migration teams are utilized a potential of six source domain migrations
could be managed. With over 70+ domains to consolidate by a potential
deadline of July 2012, Idea recommends strong consideration should be
given to utilizing this multiple migration team scenario.
Coordinated Scheduling with other ongoing projects Per onsite
discussions, Active Directory migrations on a particular source domain
should occur prior to that college/service areas Virtualization Project. This
would eliminate the need for multiple steps focused around
permissions/administration and make for a more smooth transition to a
virtualized environment. In addition, there are ongoing email/Exchange
migrations occurring that will need to be taken into account when
scheduling college/service areas for Active Directory migrations to ensure
no conflicts or undesirable end-user experiences. Idea recommends the
merging of the AD migration project plan to a single consolidated project
plan for each College/Service Area scheduled for consolidation. This
consolidated project plan would not only track the AD migration portion of
the project but also ensure that the additional projects (virtualization and
email migrations) for each source domain are scheduled efficiently and
without conflict of one another.
Roadmaps and Prioritization for Campus-Wide Services An area of
concern that most people expressed during our meetings was around
timelines for SCCM and SharePoint. Addressing these concerns with some
valid timelines would assist in the risk mitigation planning during the
discovery phase of the project. Idea recommends the development and
creation of a task force or steering committee that consists of the sponsor
Page 19

2010 Idea
Integration

Prepared for Cornell University

and at least one team member of each related project (AD, Exchange,
virtualization, SCCM, and SharePoint deployment) so that each group has
visibility into the scheduling and risk mitigation activities supporting the
AD projects and understand potential impacts to their projects.

Page 20

2010 Idea
Integration

Prepared for Cornell University

Appendix A: Sample High Level AD Migration Project

Plan
Task Name
High Level AD Migration Project Plan Example
Envisioning
Project Kickoff
High Level Project Plan
Set-up Project Management Office
Vision\Scope definition
Communication Plan
Envisioning closeout
Planning
Capture - Current State Analysis
Architecture/Design
Deployment Scheduling
Detailed Project Plan
Planning closeout
Developing
Lab Build Out
Design Lab Architecture
Design physical layout
Design logical layout
Determine hardware requirements
Finalize lab architecture
Infrastructure Servers Build
Implement Network Topology
Load base server OS
Lab Environments
Build out Infrastructure
Install Active Directory Environment
Install and Configure Quest Migration Tools
Migration Testing
User Synchronization
Workstation Migration
Resource Update Manager
Member Server Migration
Other Services (DNS, DHCP, Linux, Etc.)
Test Plans
Develop test plans
Verify test plans
Execute test plans with QA
Develop Migration Plans
Build Migration Documents
Pre-production Tasks
Provision required Hardware in Production
Disable SIDHistory Filtering
Verify Quest Account Permissions
Install Quest tools into Production
Finalize Pilot Group
AD Synchronization
Development closeout
Stabilization
Pilot Rollout/Testing
Coordinate/Execute Schedule for User/Workstation Migration
Execute Migration
Page 21

2010 Idea
Integration

Prepared for Cornell University

Validate results
Migration Scheduling
Develop Migration Sessions
Approve/Finalize Session Schedule
Helpdesk Coordination
Knowledge Transfer
Coordinate Migration Activities
Go - No Go meeting
Stabilization closeout
Pre-Deployment Tasks
Coordinate Change Control
Agent Installs
Deployment
User/Groups Migration
Workstation Migration
Resource/Profile Updating
User Switch (Workstation Move)
Member Server Migration
Coordinate with Server/Application Owner
Submit Change Control
Post Migration Activities
Deployment Closeout

Page 22

2010 Idea
Integration