1. The Essence of Migration
One of the words that you're going to see used throughout your 70-647 exam and throughout your career in the IT world is migration.
Migration is just a marketing term that means transferring from one
place to another, transferring from one version to another, or both. In
the older days of administration, migration was an ominous task that
took a lot of planning, design, and best implementation practices.
Mainly, this was because of the inherent difficulty of transferring from
a non-Active-Directory-capable environment to an Active
Directory–capable environment. Obviously, there were problems.
In the world of Windows
Server 2008, those concerns are mostly gone. The days of Windows NT are
numbered, and it is rare that you will find an organization that doesn't
implement Active Directory in some form throughout the enterprise. This
changing of the guard occurred in the age of Windows 2000 Server and
Windows Server 2003.
Now, with Windows Server
2008, you'll face the lesser challenging of moving objects between
Active Directory–capable versions of servers that aren't so up-to-date
or moving objects between overall designs that perhaps aren't as evolved
as they could be. To facilitate this transformation, you can take
advantage of a very powerful administrative tool that must be installed
by hand: the Active Directory Migration Tool (ADMT).
2. Using the Active Directory Migration Tool
The primary tool that we
use to migrate objects from one domain to another is the Active
Directory Migration Tool. The Active
Directory Migration Tool version most widely used at the enterprise
level is ADMT 3.0. This is the version that is used with Windows Server
2003 and mostly facilitated transfers between Windows 2000, Windows NT,
and Windows Server 2003.
With the release of Windows
Server 2008, Microsoft introduced the ADMT version 3.1. This powerful,
new version of the previous ADMT tool is designed from the ground up to
support Windows Server 2008 and all previous versions of Windows Server.
Because of the inherent power of this tool and how heavily it will to
be used in the enterprise environment, it's important for us as
enterprise administrators to understand the capabilities of this tool.
3. Using Caution with Migration
There's a big difference between whether you can do something and whether you should
do something. We all know that Windows Server 2008 is a powerful, new,
and fancy operating system with numerous capabilities. From the
perspective of an administrator, you'd like to incorporate as many
features as possible into your design. But from the perspective of a
business, migrating any machine from one platform to another means two
things: money and liability.
We IT professionals might like
to ignore such details, but migrating to Windows Server 2008 costs a lot
of money. A business has to worry about the costs of Windows Server,
which include the labor costs associated with installing the software
and the cost of any additional hardware to support the upgrade with the
appropriate amounts of RAM, CPU power, and other associated
functionality. More often than not, this means purchasing new computers.
A business must also be
concerned with liability issues. Gary Olsen, a software engineer with
Hewlett-Packard, once commented in an article he wrote pertaining to
migration with Windows Server 2008 that a customer was potentially
losing up to $1 million per hour because of incompatibility between the
version of SQL Server currently in use in the office and an upgrade to
another application.
Just imagine that: $1
million per hour. A lot of regular, hardworking people barely make a
million dollars in their entire lifetime. And this business was losing
that much in a single hour. The moral of the story? Plan. And then plan
again. Although we might want to jump into the situation headfirst and
upgrade on a whim, we have to use caution. If you don't, you'll most
likely regret it. Don't count on being lucky. Be certain.
4. Migrating Objects
Objects are, for the most
part, the only reason you need to concern yourself with migration. This
is because objects contain most of the information you need in order to
conduct business. Remember from your earlier study of Active Directory
that an Active Directory object is either one or a collection of
important resources, user accounts, computers, printers, or other
elements that exist as part of the Windows infrastructure. When we say
that we are "migrating objects," we are simply taking objects from one
source domain and transferring them to the target domain.
For example, say you have two
different domains, MyCorp and MegaCorp. MyCorp is a small, independent
seller of machine equipment for use in excavating archeological
discoveries. MegaCorp, on the other hand, is a giant manufacturer of
equipment used for thousands of purposes. MegaCorp is involved in coal
mining, dumping, building construction, road construction, and many
other endeavors. Recently, MegaCorp decided to purchase MyCorp for an
undisclosed amount, acquiring all of its employees, resources, and
assets. Accordingly, MegaCorp wants to migrate the resources of MyCorp
to its infrastructure.
In a simple example like
this one, you face the problem of migrating objects from a small domain
to a larger one. Accordingly, you need to use the ADMT. You would start
by migrating users from the MyCorp domain. You would do this by logging
on to a server in the MegaCorp domain and executing an instance of the
ADMT.
The reason you do this from
the target domain and not the source domain is that the ADMT works in a
similar fashion to a crane. If you're using the ADMT, it's like
operating the crane. When you're operating, you can dig into a target
area and move it to another one. More technically, when you're using the
ADMT, you have to point the ADMT to a target and tell the ADMT what you
would like to take.
4.1. Consolidating Objects
Beyond moving objects from
domain to another, or from one Windows platform to another, a
dramatically increasing usage trend is to use the ADMT to consolidate
the number of servers within an existing Active Directory
infrastructure. Consider that in the "older" days of computing, hardware
was nowhere near as powerful and software was nowhere near as robust,
stable, and capable.
Because of this, it is easy for
administrators to use the ADMT to take objects from a previously
overburdened server and place them into a higher-level server that has a
much greater maximum capacity than the previous server. Consider Figure 1, where the forest root domain for the SuperCorp corporation is the supercorp.com server, and the extending child domains are children of the root.
In this figure, you can
see that the IT department domain (it.supercorp.com) is overburdened.
Although it isn't illustrated in this figure, the reason for this is
that the users in the IT department are running an outdated Windows 2000
Server machine with a whopping 400MHz processor and barely enough RAM
to run Office 2007. But then again, that's sort of the way it goes in
IT—just enough to get the job done.
To deal with this situation,
you'd have to perform a common task—taking the existing user accounts
from that Windows 2000 Server that existed in a child domain and
integrating them into the domain a level up. In this case, you'd use the
ADMT to consolidate the number of servers. You'd do this by first instantiating
(which is just a fancy word for initializing) the ADMT on the server
that you want to ultimately consolidate toward and take out the user
accounts. After this, you could remove the child domain.
OmniCorp, a medium-sized search
engine–based advertising company, has a central office in Washington,
DC; four additional domains installed within the company for various
projects; and departments throughout the enterprise. However, new
government privacy regulations require OmniCorp to consolidate its
existing domain structure into a centralized, focused environment with
only one domain and one domain controller.
The reasons why this is
necessary are complicated, but suffice to say that security is of great
concern. Some of the data to which OmniCorp has access is very private
and consequently very valuable. Currently, OmniCorp's corporate
infrastructure appears as shown, with one root domain and four child
domains.
Within each child domain
are multiple thousands of user accounts. Each of these domains may have
its own policies and procedures regarding accounts. However, all the
domains must now be consolidated into one domain. Currently, the entire
OmniCorp enterprise is running Windows Server 2003 R2 with the domain
and forest level at Windows Server 2003.
To solve this problem, you
would need to use the Active Directory Migration Tool to migrate the
objects from the child domains to the root domain. Once you have
migrated the objects, you will have the opportunity to remove the child
domains and reduce the overall amount of domains within the
infrastructure. In this situation, it may be a good idea to upgrade the
overall forest to Windows Server 2008, especially if the domain policies
are so specific that they include multiple password policies. Remember,
only Windows Server 2008 supports the new fine-grained user password
policy feature.
5. Options with the Active Directory Migration Tool (ADMT)
After you've initially
installed the ADMT, it appears in the Administrative Tools section of
your Windows Server 2008 Start menu in a similar fashion to many other
MMCs for Windows Server 2008 Thus, you can access it by selecting Start => Administrative Tools => Active Directory Migration Tool. When you open this tool, you'll see a default screen, as shown in Figure 3.2,
which will look relatively unimpressive until you begin the process of
migrating objects back and forth and generating reports based on your
actions.
In the Action menu,
you'll see several options that open wizards. In normal operation,
you'll rarely use a wizard in a form other than the standard one. This
is because Microsoft has gone through great pains to make sure that the
ADMT doesn't just work but works very well. Thus, it behooves you to use
the tools for the purpose they were designed—convenience. In total,
there are nine wizards, only some of which you have to be concerned with
for your exam. The nine wizards are as follows:
User Account Migration Wizard
The User Account
Migration Wizard transfers user accounts between domains and keeps track
of account information such as password settings and privilege levels.
When complete, the users should see no difference between their previous
accounts and their current accounts on the new server.
Group Account Migration Wizard
Using the Group Account
Migration Wizard, administrators can move target groups from one domain
to another. Within this wizard, there are options to select individual
groups and user accounts, as well as the option to exclude certain
groups and group members. But most important, in order to maintain group
membership, groups need to be moved before user accounts to maintain
membership during migration. Otherwise, the target server won't
understand the groups, just the users within.
Computer Migration Wizard
The Computer Migration
Wizard is designed to transfer computers from domain to domain anywhere
within the infrastructure, including within organizational units. Just
like the Group Account Migration Wizard, this wizard lets you select
individual computers and configure the migration settings for each.
Security Translation Wizard
This wizard changes things up a
bit in that it is designed to change security identifiers (SIDs) for
access control lists (ACLs) and system access control lists (SACLs) on
migrated objects. Without this translation, objects would have a lot of
difficulty properly identifying themselves within the infrastructure.
Reporting Wizard
The Reporting Wizard is a
web-compatible report tool that helps document the process of migration
for your future use. You can choose to report domain changes, folder
changes, security settings, and several other options. At the enterprise
level, this is particularly recommended because of the good chance that
this will probably occur again and again as technology continues to
evolve. This way, you have a record of everything that has changed.
Service Account Migration Wizard
This wizard locates
and identifies services on computers in the migration source domain (the
domain that is being transferred) that do not use the Local System
account. Once it does this, the ADMT identifies these accounts so that
they are included in the migration at a later time.
Exchange 5.5 Mailbox Translation Wizard
If your enterprise is
running Microsoft Exchange version 5.5, you can use this wizard to
translate security and mailbox settings for Microsoft Exchange.
Retry Task Wizard
You can use this wizard
if you attempt to initiate a migration and the migration fails. If any
settings are configured incorrectly, you can attempt to correct them
with this tool.
Password Migration Wizard
It's no secret that
sometimes domains can have a lot of passwords and different password
settings. Using this wizard, you can both transfer all your password
settings and then establish new protocols for your passwords in the
infrastructure.
