|
Preparing To Join Active Directory
SERVERS
<
Back
|
Prior
to upgrading to an AD Organizational Unit (OU), it is important to spend
some time analyzing the current utilization of services within your existing
NT 4.0 domain and make judgments on what services can be consolidated or
what services should exist on separate machines. For example, if a
machine exists that (as the result of history) has Exchange 5.5 as well as
SQL Server and Systems Management Server (SMS) version 2.0, it may be an
appropriate time to split those services off to separate machines.
Also,
there may be some circumstances where software upgrades will be appropriate.
For instance, some services that may do well within an NT 4.0 domain
environment may not function when upgraded to Active Directory or may have
specific versions designed for a directory environment (for example –
Exchange). Be sure to consult your software vendor for specific
information regarding releases of your software.
An
axiom for upgrading to an OU is “don’t bite off more than you can
chew.” In looking at an upgrade strategy, an all too common problem
is getting lost in the details. We recommend that upgrades should be
viewed at a per-server/per-service level. In other words, take each of
the services on a server and plan how to upgrade them and the operating
system (OS) that resides on it.
|
TOP
|
|
One organizational step that can
be taken almost immediately is a review of the Access Control Lists (ACLs)
for shares on servers. A good rule to live by is access by group.
Despite the size of the group accessing the share, a group can be created to
use for assignment of permissions. For example, the Physics Department
has a share on a server that the secretary and chair of the department use
to pass confidential documents to each other. Rather than assigning
permissions to the share to the department chair and secretary, consider
creating a group called ‘CAS Physics Chair’ which is a descriptive name
for the group preceded by the OU name; consult the migration website for a
definitive list of OU names. Endless amounts of groups can be created
and can be a useful tool because there is no longer a need to keep track of
large amounts of ACLs, only making sure group membership is correct.
|
TOP
|
|
In NT
4.0 the common practice was to make a machine a Domain Controller in order to
assist in the authentication of users. In migration, first target
Backup Domain Controllers (BDCs) convert them to a Windows 2000 member server
that has a minimum 4GB system partition (the larger the better).
Understandably, converting the BDCs may be a lengthy process but a necessary
one. Keep in mind, installing Windows 2000 on a larger system partition will
provide benefits in the long run with less system baggage from a NT 4.0
installation and a larger partition, which will help Windows 2000 operate.
Also,
all Back Office products should be upgraded to the latest versions possible
with all current service packs applied. The migration section will cover
specific products; however, for right now, bringing all service packs and
versions current will better facilitate the migration.
Some
Back Office products require great care in rebuilding or upgrading the OS.
For example, there are implications with SMS 2.0 in changing site or
server names. Please consult CISS or Microsoft’s TechNet prior to attempting any upgrades to avoid
problems with the migration. Specific
Back Office application migration will be discussed later in this document.
During
the migration process for a simple file server (not a domain controller), it
can be upgraded or rebuilt. If it is to be rebuilt do as follows: all existing resources are moved to other machines, the file
server is taken off-line and rebuilt, and resources are moved back. Should a
department be in the position of not having resources to maintain a separate
machine running NT 4.0 while the migration is occurring, CISS may be
able to make accommodations. If it is to be upgraded, make sure the server is
backed up and then run the install upgrade.
|
TOP
|
|
We
recommend focusing on any pre-existing member servers first. Upgrading
these machines to Windows 2000 Server has little or no effect on the
authentication of users into an NT 4.0 domain. In addition, all currently
planned purchases for servers should not be loaded with NT 4.0 and should be
built as Windows 2000 member servers in preparation for a migration.
Following the upgrade of all member servers, attention should be turned to BDCs
next.
BDCs
propose a bit of a new challenge. NT 4.0 domain controllers want to be
domain controllers within an Active Directory structure and if they can’t be
then problems arise. Consequently, for BDCs, the decision inevitably
becomes one of a complete rebuild. However, we are currently researching a
product, UPromote, which will allow NT domain controllers to be demoted to
member servers. Once a NT domain controller has been demoted to a member server,
it can be upgraded to Windows 2000. The product, UPromote, will be available
campus wide.
PDC
upgrading involves a different plan of attack. The last NT 4.0 machine in
the domain should be a spare machine setup to be the PDC. The existing PDC
should be downgraded to a BDC and then either rebuilt or decommissioned
depending on the future use of the PDC; prior to a complete transition over,
another machine (it can be a workstation that has NT 4.0 Server installed)
should be brought up as the PDC for the domain.
It is
also important to note that pre-migration preparation can be a daunting task by
itself. We recommend that any steps
taken should be sequentially considered and no two services or servers should be
migrated at the same time. Servers,
Back Office services, and workstations all present their own unique challenges
for upgrading and by no means should the process be taken lightly.
|
TOP
|
|
Preparing
for migration to Active Directory in the Back Office Products provides little or
no difficulty. One caveat, however, is that the ease of migration comes
with each of the services existing on a Windows 2000 member server prior to the
move. This should not be too difficult for most of the products:
-
SQL
Server: Links on the ISU migration site point to MS Knowledgebase (KB)
articles with considerations for SQL Servers.
-
SMS
2.0: There should be no implications running this software on a
Windows 2000 platform.
-
Exchange
5.5: Should install correctly provided that srvrmax.exe is renamed to
setup.exe.
-
IIS
5.0: If a server is being upgraded from 4.0, the ISU migration site
has a link with step-by-step instructions on how to do an upgrade.
|
TOP
|
|
The
final pre-migration step that should be taken is the preparation of user
scripts. In the NT environment, user scripts were housed in the
\\logonserver\NETLOGON share which resided in the c:\winnt\system32\repl\import\scripts
directory. Script replication was setup by designating either a BDC or the
PDC as an export server and populating the c:\winnt\system32\repl\export\scripts
directory on that server with scripts. Replication occurred as the
directory replication service was turned on at each of the domain controllers;
however, if the export server ever crashed, a new export server needed to be
designated and each DC would require a change to point to the new export server.
In
Active Directory, script replication looks a bit different. AD brings with
it the concept of Multi-Master Replication where information stored on a domain
controller can be replicated out to the other existing controllers from the
domain controller where the information is stored, thus eliminating the need for
an export server. How this is accomplished is that on each DC within the
directory exists a share with the name ‘SYSVOL’. This share replicates
not only scripts but GPOs as well. The scripts folder still exists as the
NETLOGON share on the server for down-level clients; however, in our situation
we have created a folder for each OU within the NETLOGON share. In other
words, the current NETLOGON share looks like this:
In order to minimize any connectivity problems for end-users, an important
step of pre-migration will be to first create a folder in your existing
NETLOGON share corresponding to the name of your OU, copy all of your existing
scripts to that folder, and update the location of the scripts in each NT
account. For example, the College of Business (COB) would first create a
folder in their existing NETLOGON share entitled ‘COB’ and copy any
existing scripts to that share. Next, each script would be examined and
any references to the NETLOGON share would be changed to reflect the new
directory structure.
Finally,
the accounts associated with that script would be edited to point to the new
copy of the script. A typical user account’s properties in NT looks like
this:
To
change the location of the script, click on ‘Profile’ and
Highlight
the ‘Logon Script Name’ field and prefix the name of the script with
‘OU\’. In this example, the change would be ‘COB\eanorto.cmd’:
As a
result, the next time that user logs in, they will run their script like normal
and should notice no change. When the user is eventually migrated to AD,
their script location will not change either resulting in the user seeing no
downtime and no connectivity issues.
|
TOP
|
|
The
final steps prior to migration include notifying the CISS of a department’s
prep work to date via a survey form to aid in
determining the readiness of the department and to identify any additional steps
to follow. After receipt of the feedback to the department from CISS on the Pre-Migration Survey Form and taking any identified steps, a formal
request to migrate to an OU within the domain should be sent to CISS to request
a migration timeline/plan to join AD. Upon commencement of the
migration, CISS will establish a trust with your domain in order to
facilitate the ADMT migration tool, ACLs assignment during the transition, and
computer authentication.
|
TOP
Copyright 2003 ©
Illinois State University • Appropriate
Use and Copyright Reports
An equal opportunity/affirmative action university encouraging diversity • Mail
comments to: helpdesk@ilstu.edu
This service provided by Computer
Infrastructure Support Services
|