AD Migration Feedback

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

The large University where I work is currently in the midst of a migration
from NT4 to W2K Active Directory. I would like to generally explain how it's
being done and get some opinions about it from those of you who have
experienced AD migrations.....

Right now our NT4 network includes 3 account domains and several resource
domains. There is (and will only be) one AD domain with the trusts set up
exactly as if it were one of the NT4 account domains.

User migration part 1:
Someone with Admin rights (often the assigned user) needs to log on to every
Windows machine, at which time they will run a logon script that changes the
ACLs and group memberships to reference the AD domain. I guess the script
runs some sub-scripts and at least one 3rd party migration tool. I keep
insisting that this will have to be run again just before the NT domains are
decommissioned and SID history is gone.

User migration part 2:
This one is to be done one week later.
The user logs onto a machine on which part 1 has already been done. They
now have a new logon script which "migrates" their NT account to AD. As far
as I can tell, what it really does is disable their NT account and enable
their AD account, which exists beforehand but in a disabled state. I'm
guessing that the user profile is somehow migrated by a 3rd party tool.
Simply changing the ACL on the existing profile wouldn't be enough for the
user to automatically get the existing profile once they log on with their AD
account. Maybe keys are added to HKEY_Local_Machine for each profile, with
ProfileImagePath pointing to the respective existing profiles; I don't know.
If someone were to to run the "migration" script on a machine that hadn't
run the part one script, they would end up with a new profile because the ACL
would not have been changed on the existing profile. Supposedly there is a
safeguard in place for that, where the first script leaves a flag that must
be found before the part two script will run.

Computer migration -
Ooops. I guess this doesn't exist. Those of us who are OU administrators
must prepopulate our OUs with machines accounts and then go to each computer
to add it to the AD domain.

What do you think? Is this a good way of migrating? Is it unconventional?
Is it much different that ones that you've been involved in?

I don't know; I've never been involved in one before. I fooled around with
one in a test lab and it was nothing like this.

Hope to hear some feedback.
Thanks.
 
<inline response>

Charlie said:
The large University where I work is currently in the midst of a migration
from NT4 to W2K Active Directory. I would like to generally explain how
it's
being done and get some opinions about it from those of you who have
experienced AD migrations.....

Right now our NT4 network includes 3 account domains and several resource
domains. There is (and will only be) one AD domain with the trusts set up
exactly as if it were one of the NT4 account domains.
Click to expand...

Some larger organizations keep an "empty root" domain for holding
forest-wide accounts such as, Schema Admins and Enterprise Admins - but
that's always an open discussion.

User migration part 1:
Someone with Admin rights (often the assigned user) needs to log on to
every
Windows machine, at which time they will run a logon script that changes
the
ACLs and group memberships to reference the AD domain. I guess the script
runs some sub-scripts and at least one 3rd party migration tool. I keep
insisting that this will have to be run again just before the NT domains
are
decommissioned and SID history is gone.
Click to expand...

If the machine is Windows 2000 or Windows XP - perhaps not. SID history can
be disabled from the Active Directory domain. However, we did this on
thousands of machines with a push from SMS ...

User migration part 2:
This one is to be done one week later.

Computer migration -
Ooops. I guess this doesn't exist. Those of us who are OU administrators
must prepopulate our OUs with machines accounts and then go to each
computer
to add it to the AD domain.

What do you think? Is this a good way of migrating? Is it
unconventional?
Is it much different that ones that you've been involved in?
Click to expand...

Ours was quite a bit more automated than this - but then again, we did an
in-place upgrade for our larger environment. Our smaller ones were migrated
using a process similar to the one you mention above. In addition, we had
the local admins add the machine accounts and at the same time, change the
computername when appropriate to meet machine naming conventions.

I don't know; I've never been involved in one before. I fooled around
with
one in a test lab and it was nothing like this.
Click to expand...

Labs are great - but don't always reflect things in the live network.

-ds
 
Charlie,

Do be careful on something like this. I would suggest that you look really
hard at the ADMTv2 tools and think about their best practices. An
enterprise-wide domain migration is not something you want to get "creative"
on and you'll do best to follow the rules for workstation migration and
maintenance of SIDHistory.

Depending on your maintenance strategy and the sub-domain structure, you may
consider a management domain though this may not be needed. Think hard
about this.

Also, it sounds as though you are upgrading your domain to 2000/2003 but
treating it like it were an NT4 domain with trusts to resources. That's
like buying a new computer and expecting to use it as a calculator. Think
of your reasons to migrate and how your "business needs" are dictating it.
Do your migration and restructuring in that light; Don't just do this for
the desire to do it -- even with the support dropping off.

Finally, if this is not something you have done before or have the ability
to lab, hire an integration firm that has. It'll be much cheaper to do it
one with help than to flounder across the board and pay for a botched
migration for months.

I don't try to fix my own car... Even if I know what's wrong with it.
 
Back
Top