How does ADMT2 work with Roaming Profiles?

[Joe Cotter]

We are in the midst of a 4 domain collapse (into one new 2003 AD
domain) and I've got some basic questions about how ADMT2 and Roaming
Profiles work.

1) No where in the documentation does it say that the user must be
logged in OR off, does it matter?

2) What are the ramifications if a user is logged on? Or off?

3) What does ADMT2 do to the romaing profile when it "translates" it?
Does it tweak it for the new domain? Or does it make everything so it
works between both source and new domains? I can't find ANY
documentation for this.

Thanks in advance for the help on this....

 

[Tim Springston \(MSFT\)]

Hi Joe-

1) It would be best if the user is logged off at that time. The reason is
that any new changes to the profile would not be present in the translated
profile (the logoff event would fail to update the translated profile).

2) If they are simply logged on or off the source domain and NOT using a
profile that is being translated then there are no ramifications. If you
are using roaming profiles in the target then there is no problem there,
however if you are translating local profiles that could be an issue (see
below).

3) ADMT2 does in essence the same thing that the Copy To command in System
Properties does for profiles; it changes permissions on it and the registry
hive in it for the new (target) user.

Here's a little more info for you. Although profiles are user-specific
attribute, they are more closely linked with computers and computer accounts
in migration scenarios. Profiles are located in one of two ways. For
roaming profiles, the profile path is read as an attribute of the user or
inetOrgPerson account and is loaded from the location specified. This
requires that the network path to is available and that the account has
appropriate permissions to the files located there. During migration, ADMT
can modify the permissions on the network-based roaming profiles so that the
migrated account still has sufficient permission to load the existing
profile.

Local profiles stored on individual workstations are located based on the
entries in HKLM\Software\Microsoft\WindowsNT\CurrentVersion\ProfileList.

These entries are primary user sIDs and when a user logs on with a sID that
matches one in the list, the system loads the corresponding profile. A
migrated user or inetOrgPerson account will have a new primary sID issued by
the target domain. This new sID will not be found by the system and the a
new profile will be loaded for the user.
Local profiles must be migrated before the migrated user account logs on to
the workstation. If the migrated user logs on before the local profile is
translated, the system will fail to find the existing profile and load a new
default profile instead.

Please repost if this doesn't answer your questions.