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 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 University

Revision and Signoff Sheet

Change Record
Date 06/14/11 06/23/11 06/30/11 Author David Thompson David Thompson David Thompson Version 1.0 1.1 1.2 Change reference Initial Draft Internal Review Final Version

Reviewers
Name Chris Lavelle Version approved 1.1 Position Date 06/26/2010

Page iii

2010 Idea Integration

Prepared For Cornell University

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

Page 5

2010 Idea Integration

Prepared for Cornell University

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

Page 6

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

Page 7

2010 Idea Integration

Prepared for Cornell University

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

Page 8

2010 Idea Integration

Prepared for Cornell University

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 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
Page 9

2010 Idea Integration

Prepared for Cornell University

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

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 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
Page 10

2010 Idea Integration

Prepared for Cornell University

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 premigration tasks. Resolves any issues related to the target domain (permissions, rights, availability, etc.).

Page 11

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

Page 12

2010 Idea Integration

Prepared for Cornell University

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 13

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

Page 14

2010 Idea Integration

Prepared for Cornell University

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.

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
Page 15

2010 Idea Integration

Prepared for Cornell University

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 16

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 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 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 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 17

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 Validate results Migration Scheduling Develop Migration Sessions Approve/Finalize Session Schedule Helpdesk Coordination Page 18

2010 Idea Integration

Prepared for Cornell University

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 19

2010 Idea Integration