Re: AD Migration Feedback

From: Ryan Hanisco (rhanisco_at_flagshipis.com)
Date: 02/07/05 

Date: Mon, 7 Feb 2005 00:35:58 -0600

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. 

-- 
Ryan Hanisco
MCSE, MCDBA
Flagship Integration Services
"Charlie" <Charlie@discussions.microsoft.com> wrote in message 
news:6ED77395-C7D6-425A-BFA7-564F1E40E25C@microsoft.com...
> 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.
>
>

Relevant Pages

  • RE: Migration client issues
    ... You may use logon script to copy profile or my favorites to the new ... In Windows NT 4.0, locally cached profiles are stored as a subfolder of the ... Regardless of whether the user logs on to a local account or an account ... Description of Windows 2000 User Account and Profile Migration ...
    (microsoft.public.windows.server.migration)
  • AD Migration Feedback
    ... The large University where I work is currently in the midst of a migration ... Right now our NT4 network includes 3 account domains and several resource ... at which time they will run a logon script that changes the ... Simply changing the ACL on the existing profile wouldn't be enough for the ...
    (microsoft.public.win2000.active_directory)
  • Re: Enumerating organisational units within vbs script
    ... i have created the script below to read a list of account ... user sits in it will update the profile. ... One is a recursive function to enumerate OU's, ... probably what you mean by account name. ...
    (microsoft.public.windows.server.general)
  • RE: NT4 - ADMT - 2003 & XP Agents
    ... the 2003 DNS Server prior to their migration. ... ADMT creates several log files in the Logs folder under the ADMT ... Use user1 to logon to NT domain, you will find the profile is located to ... Logon to the windows 2003 domain DC and run ADMT to migrate user account ...
    (microsoft.public.windows.server.migration)
  • ADMT v3.0 ERR3: 7438 no NTUser.DAT file for "user" was found
    ... I am doing an interforest migration and trying to migrate a user from ... domain a --> domain b (target domain). ... The roaming profile cannot be migrated" ... Do not expire source account ...
    (microsoft.public.windows.server.migration)
Loading