active directory migration planning

8/2/2019 Active Directory Migration Planning

1/19

Active Directory Migration Planning

Prepared for

Cornell University

Tuesday June 23, 2011

Version 1.2 Final

Prepared by

David Thompson

Infrastructure Consultant

[email protected]


2/19

Prepared For Cornell University

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


3/19


Page iii

2010 Idea Integration

Revision and Signoff Sheet

Change Record

Date Author Version Change reference

06/14/11 David

Thompson

1.0 Initial Draft

06/23/11 David

Thompson

1.1 Internal Review

06/30/11 David

Thompson

1.2 Final Version

Reviewers

Name Version approved Position Date

Chris Lavelle 1.1 06/26/2010


4/19


Page iv


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


5/19

Prepared for Cornell University

Page 5


1. IntroductionCornell 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 cost-saving 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 implementationand associated documentation provided by the client.

Review the various approaches for consolidation and make recommendations of riskmitigation 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 consolidationeffort.

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 ComplexityThe CIT Identity Management Staff will now be responsible for allAD administration of domain controllers and all Active Directory functionality (mainly

security related). Organizational Unit (OU) Administration delegation is in place to allowindividual IT groups across the University to manage their own OU infrastructure relating to

User/Group administration as well as rights/permissions to resources.

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


6/19


Page 6


2. Intended AudienceThis 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.


7/19


Page 7


3. Migration OverviewActive 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 complexityA 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 userproductivity 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 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.


8/19


Page 8


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


9/19


Page 9


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

o Security descriptors of Active Directory objects

o 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

off-peak 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 aresult 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 CleanupMigration 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


10/19


Page 10


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.

3.3 Migration Process OverviewThe 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 MigrationSelected 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. 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 ProcessingAccess 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 CleanupSource 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.

3.4 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 ProjectManager 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


11/19


Page 11


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


12/19


Page 12


4. Current Active Directory InfrastructureDuring 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 thesesource domains when scheduled for an actual migration project.

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

4.2 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

The information obtained during these productive meetings has assisted greatly with the content

and recommendations listed in this document.


13/19


Page 13


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.


14/19


Page 14


5. Areas of RemediationA 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 risksdiscovered 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 schedulingare 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 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).


15/19


Page 15


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

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 scriptor program designed for this purpose. This would be a subset of tasks in the migration


16/19


Page 16


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.


17/19


Page 17


6. Planning Recommendations

The following recommendations are proposed for review and discussion:

Use of Quest Migration Manager (QMM) for Active DirectoryBased 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 TeamsThis 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 pre-migration, 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 projectsPer 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 mostpeople 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 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.


18/19


Page 18


Appendix A: Sample High Level AD Migration Project Plan

Task Name

High Level AD Migration Project Plan Example

EnvisioningProject 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 TestingUser 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 ProductionDisable 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

Validate results

Migration Scheduling

Develop Migration Sessions

Approve/Finalize Session Schedule

Helpdesk Coordination


19/19


Page 19


Knowledge Transfer

Coordinate Migration Activities

Go - No Go meeting

Stabilization closeout

Pre-Deployment Tasks

Coordinate Change Control

Agent InstallsDeployment

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