How to: Active Directory Migration Discovery

/in /by

So I’ve mentioned this in several posts now.. A well-planned migration comes in phases:

  1. Discovery
  2. End-User Compute
  3. Applications and Services
  4. Cleanup & Closure

So what does a migration discovery actually consist of? What level of privilege should I request in the environments? These are some of the more common questions I’ve been asked.

For my clients, I use a set of custom scripts to extract data from each directory. There are also a number of COTS toolsets available that you can use if you choose. I prefer gathering information in CSV (comma-separated value) or TSV (tab-separated value) formatted outputs so I can easily review the datasets and gain some feel for each environment of interest.

On first-pass, I like to produce a taxonomy of objects for each directory. I use this for high-level discussion with the client and it helps me to visualize and size a level of effort for an upcoming migration.

My typical taxonomy would include:

Users

  • Count, Total v Disabled
  • Normal (but really, who’s normal these days??)
  • Service Accounts
  • Stats regarding logon scripts assigned, home drives assigned, etc.

Contacts

  • Quantity, location/s

Computers

  • Count, Total v Disabled
  • Workstations (OS versions)
  • Servers (OS versions)
    • Domain Controllers, Sites, Subnets

Groups

  • Security Groups (breakout w count by group type)
    • Mail-enabled
  • Distribution Groups (breakout w count by group type)

OU Structure

  • Count, observation (mature, greenfield, etc.)

GPOs

  • Count, observation (mature, greenfield, etc.)

Trusts

  • Count, enumeration

Schema Extensions

  • Count, enumeration

To gather this sort of data, you should request elevated permissions in both the source and target environments. Although active directory is read-only by nature, some things may be restricted. In a single forest single domain implementation, domain admin is usually sufficient. When working with root and child domains in the context of a forest, enterprise admin would be most effective.

When a client refuses, which sometimes happens due to security requirements or organizational complexity, suggest that someone with the appropriate privileges execute whatever discovery tool/scripts you need. If it’s too much hassle, they may grant you permissions after all; otherwise, they run the scripts for you and make the data collected available. Either way, you’re a winner!

After the collections are ran, and the taxonomies are generated, you’re ready to perform some readiness assessment – reviewing users and groups for name collisions, selecting available service attributes for Quest migration manager, and making a determination if you will want to configure object filtering in the toolset.

These types of analyses aren’t so bad if it’s a single domain organization coming into a relatively pristine greenfield; it gets a touch more complicated if you need to collapse multiple domains, or collapsing multiple domains into a well-established active directory environment.

“Measure twice, cut once.” is a mantra I try to impart to my clients. If applied it will help bring some peace and serenity to an otherwise complex and challenging project. Mitigating chaos and risk, that’s why you bring in experienced professionals to help lead the charge. 😊

We here at Convergent Technologies would love to be your partner in change. We’ve assisted many organizations with Microsoft Active Directory projects including assessments, segmentation, consolidation, as well as other forms of migration projects. How may we help you?