Many organizations that move to Active Directory (AD) choose to run a new AD
domain parallel with their existing Windows NT 4.0 domain. Administrators create the
new AD accounts by cloning or copying the NT accounts so that the account name is
duplicated (e.g., NT4DOM\NEUBAUER becomes ADDOM\NEUBAUER) and the two
accounts have the same password. When I perform these types of migrations, I prefer
to disable the AD accounts until they're needed, especially if I create all the accounts
at one time, then phase users into the accounts. Disabling the accounts also can help
prevent the common "My icons are missing!" migration problem, which I explain in
the next section. This migration approach has value, but enabling the accounts later
can be a chore. Therefore, I created a scripting solution that can help.
Blank Profiles
When someone logs on to a workstation, Windows
creates a user profile linked to the
authenticated account and uses this profile to
store user-specific information. For example,
if I log on to my workstation with my
NT4DOM\NEUBAUER account and configure
a network printer, define three persistent drive
mappings, and install desktop shortcuts for all
my frequently used applications, Windows
stores these settings in a user profile linked to
my NT4DOM\NEUBAUER account so that the
settings are available each time I log on to the
workstation. When I log on to the workstation
with my new ADDOM\NEUBAUER account,
Windows creates a blank profile and links it to
the ADDOM\NEUBAUER account. However,
the new account profile has none of the customizations
that I made while logged on
through the NT4DOM\NEUBAUER account.
A good migration plan will include a way to
copy the old profile so that its settings are available
to the new AD account, making the
migration more transparent to the user. A
problem in many migrations is that people log
on to the workstation with the new account
before the profile information has been copied
to the new account. When this happens, Windows
creates the blank profile and the first
thing users notice is that their desktop icons
are missing.
By disabling the AD accounts, you can prevent
people from logging on until after you finish
the profile copy process. However, adopting
this strategy creates an additional challenge:
how to link the profile-copy process on a specific
workstation with a specific user so that
you know when to enable the user's new
account. I solve this problem by shifting the
profile-copy task to the user, then I use an
Active Server Pages (ASP) script in a
Web page to enable the new account.
Through a batch file, such as the one
Listing 1 shows, a migrating user runs
a tool such as the profile update utility
(update.exe) from Quest Software's
Quest Migrator. You can deploy the
batch file by using a logon script or
Microsoft Systems Management Server
(SMS) or by having users launch the
file from a Web site. When Migrator
finishes duplicating the profile, the
batch file launches Microsoft Internet
Explorer (IE) and opens an ASP Web
page on an intranet Web server. The
ASP page serves two purposes: First, it
tells the user that the account migration
is finished. Second, it contains
code that accesses AD to enable the
user's new account.
ASP Code Details
The script Enable.asp contains the
code that the Migration Complete Web
page uses to enable a newly migrated
account. Listing 2 shows an excerpt
from this script. The code at callout A
lets you define seven variables for the
account you want to enable. The first
variable, sLDAPServer, holds the name
of an AD domain controller (DC). The
script uses authenticated Lightweight
Directory Access Protocol (LDAP)
queries against this server to enable the
account. The next two variables—sObjAccess
and sObjKey—hold the username
and password, respectively, of
the account that will authenticate the
script's access to the DC.
As you know, AD lets you create
containers called organizational units
(OUs) that can hold user account
objects. When I migrate accounts, I like
to place the new accounts in an OU
named Staging. When an account is
ready to be used, I enable the account
and move it to the Users OU (or the
OU it needs to be in to be managed by
account administrators). The sStaging-
OU and sDestinationOU variables define
these containers. After Enable.asp
enables an account, the script moves
the account from the Staging OU to the
destination OU (in this example, the
Users OU). From an administrative
perspective, this approach is handy
because after the migration, any
account that remains in the Staging OU
probably isn't needed and can be
retired. From a security perspective, I
like this migration method because the
script works only once to enable an
account. This approach prevents
someone from using the script (or the
LDAP authentication account) at some
later date to enable a purposefully disabled
account.
The last two variables you need to
define are sOldDomain and sNewDomain.
The sOldDomain variable holds
the name of the NT 4.0 domain. When
someone opens the Web page, the
script retrieves the user's ID from the
AUTH_USER server variable, as the
code at callout B shows. The ID has two
parts—a domain and a user ID—in the
format DOMAIN\USERID. The script
compares the domain name with the
sOldDomain variable's value. When the
items match, the script continues to
execute; otherwise, the script terminates.
The script uses the sNewDomain
variable to display the user's new
Domain and LAN ID in the Web page,
as Figure 1 shows.
The script's overall flow is simple:
The script gets the current logon
domain and account name from IE and
uses that information to build LDAP
paths to the various AD containers.
Next, as the code at callout C shows, the
script uses the credentials defined in the
sObjAccess and sObjKey variables to
establish an authenticated LDAP session
and access the object representing
the user account. After changing that
object's status to enabled, the script
uses the object's SetInfo method to
upload the change to AD.