Active Directory Migration Planning

yompmulligrubsInternet και Εφαρμογές Web

31 Οκτ 2013 (πριν από 3 χρόνια και 9 μήνες)

440 εμφανίσεις




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 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 i
ntroduced 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 o
f
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.


An
y 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 author
ization 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 me
ntioned herein may be the trademarks of their respective owners.

Page
ii


Prepared For Cornell University

Page
iii

©2010

Idea Integrati on

Revision and Signoff Sheet

Change Record

Date

Author

Version

Change reference

06
/
14/11

Davi d
Thompson

1.0

I ni ti al Draft

06/23/11

Davi d
Thompson

1.1

I nternal Revi ew

06/30/11

Davi d
Thompson

1.2

Fi nal Versi on











Reviewers

Name

Version approved

Position

Date

Chri s Lavel l e

1.1


06/26/2010














Prepared For Cornell University

Page
iv

©2010

Idea Integrati on

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 S
erver 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




Prepared for Cornell University

Page
5

© 2010 Idea
I
ntegrati on




1.


Introduction

Cornell University

is
moving toward

establish
ing

a rationalized IT architecture which will provide
an

Enterprise

Shared Services platform for common ser
vices 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 implementation
and associated doc
umentation 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
University’s Server Virtualization Project, the support model dictates all virtualized
servers be member servers of the cornell.edu Active Directory F
orest/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 t
his 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 ad
ministration 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.



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.

Prepared for Cornell University

Page
6

© 2010 Idea
I
ntegrati on




2.

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 concept
s and terminology that follows in this document.






























Prepared for Cornell University

Page
7

© 2010 Idea
I
ntegrati on




3
. Migration Overview

Active Directory migrations can be monumen
tal 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
pe
rformed in an environment that mirrors the production environment as exactly as possible.

Cornell University’s lab environment will be a key asset in this testing.


Although no two migration
projects are exactly the same, utilizing industries best practic
es 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 user
s 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



I
deally, changes to your directory should oc
cur 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.

Schedul
ing 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, there’s inevitably a period of time when both old and new env
ironments are
intact.
For some of the larger Service Areas/Colleges, i
t 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 th
at 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 pas
swords 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.


Prepared for Cornell University

Page
8

© 2010 Idea
I
ntegrati on





3
.
2


Key Features of Que
st 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 activi
ties 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 don’t have to reboot their computers or log
in and out of their ac
counts 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 kee
ping 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 res
olve 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 wa
nt 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 Direc
tory 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 pro
vides 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
-
bas
ed administration
. Migration tasks have permissions associated with them.

As
we discussed a possible multi
-
team approach at Cornell,

m
igration projects can be split
between migration teams without risk of interfering with each other’s project tasks.

Prepared for Cornell University

Page
9

© 2010 Idea
I
ntegrati on




o

Repli
cated 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


S
ince 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, in
cluding passwords, security descriptors, and linked attributes. Synchronization
and scheduling is integrated into the tool so you don’t have to use the command line or set
up Windows Scheduled Tasks. A
lso include
d i
s a resource kit with utilities that as
sist 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 fr
om 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 us
er 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 sa
me 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 Capabili
ties


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 you’ve made, from changes made in
several sessi
ons 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 resour
ce
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 r
estructured
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.

Migrat
ion Manager for
Prepared for Cornell University

Page
10

© 2010 Idea
I
ntegrati on




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 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 migr
ation

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 sour
ce 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.

T
his is a requirement if QMM is being used for an Exchange
migration as well. In Cornell’s 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 ses
sion.



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.



Switch
ing 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.

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 Project
Manager role is a major reason for the success or failure of a project. Using proven pr
oject
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
milestone
s. Providing timely status reports will alert management to any criti
cal 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 overcom
e lack
of migration experience.



Technical Project Lead


This pers
on 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
Prepared for Cornell University

Page
11

© 2010 Idea
I
ntegrati on




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 Engi
neer


This person(s) acts as the technical engineer. Experie
nce 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 co
mplete
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 kn
owledge 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.).





Prepared for Cornell University

Page
12

© 2010 Idea
I
ntegrati on




4
.
Current Active Directory Infrastructure

During IDEA Integration’s 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

C
ORNELL.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 dom
ain (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 gra
nt
C
ollege/
S
ervice
A
rea 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 recove
ry 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



C
ampus 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.




Prepared for Cornell University

Page
13

© 2010 Idea
I
ntegrati on




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 a
s 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, w
ill build
confidence in the migration process and greatly assist in staying on track with the scheduling of
tasks.





Prepared for Cornell University

Page
14

© 2010 Idea
I
ntegrati on




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 acc
epting 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
Assessmen
t 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 user’s 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 p
reliminary
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 deploymen
t 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

Right
s 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 lever
aged 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 s
erver 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).

Prepared for Cornell University

Page
15

© 2010 Idea
I
ntegrati on




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 Ce
rtificate 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 t
he 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

a
n

ac
curate
workstation inventory for each source domain usually means renaming workstations prior to
migration works most efficiently.

Another fact
or 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 accoun
ts 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 Se
curity 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 wo
uld require some type of script
or program designed for this purpose. This would be a subset
of
tasks
in

the migration
Prepared for Cornell University

Page
16

© 2010 Idea
I
ntegrati on




project plan

outside of normal migration activities.

Idea would
work with Cornell IT staff in
the development of this process and evalua
te scripts/tools that would
provide the maximum
benefit to completing this required task.



Prepared for Cornell University

Page
17

© 2010 Idea
I
ntegrati on




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,
I
dea

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 Pr
oject 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 pre
-
migration, one in active migration, and one in p
ost
-
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
are
a’s 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 ac
count 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/Ser
vice 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
effi
ciently 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 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
t
o their projects.



Prepared for Cornell University

Page
18

© 2010 Idea
I
ntegrati on




Appendix A: Sampl
e 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 Sche
dule for User/Workstation
Migration


Execute Migration


Validate results


Migration Scheduling


Develop Migration Sessions


Approve/Finalize Session Schedule


Helpdesk Coordination

Prepared for Cornell University

Page
19

© 2010 Idea
I
ntegrati on





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