ADMT migration, cannot access profiles

I just did a test migration from NT4 to 2003 using ADMT 3.0.
After the migration, the roaming profile doesn't load.

Here's what I did.
First I migrated the groups then the users then the member server which
happens to be a file server and the XP clients.
When migrating the file server, for the translated objects, I've selected
all (what options should I have selected for a file server?) and chose "add"
instead of "replace". The file server rebooted after the agent did its
thing.
When attempted to logon using already migrated user on a migrated XP, I got

Roaming profile not available
Event ID 1506 Your roaming profile is not available.
DETAIL - Access is denied.

But via explorer, the profile is accessible to the user with full permissions.
Checked the share/ntfs and the user has full permissions but cannot load the
profile.
So even tried logging in to the old NT 4 domain and still could not load the
profile and was accessible using explorer.

Anyone had a similar experience?

In news:CAA51066-1D0A-436D-841D-F3E70BC59FB5@microsoft.com,
study <study@discussions.microsoft.com> requesting assistance, typed the
following:
> I just did a test migration from NT4 to 2003 using ADMT 3.0.
> After the migration, the roaming profile doesn't load.
>
> Here's what I did.
> First I migrated the groups then the users then the member server
> which happens to be a file server and the XP clients.
> When migrating the file server, for the translated objects, I've
> selected
> all (what options should I have selected for a file server?) and
> chose "add" instead of "replace". The file server rebooted after the
> agent did its thing.
> When attempted to logon using already migrated user on a migrated XP,
> I got
>
> Roaming profile not available
> Event ID 1506 Your roaming profile is not available.
> DETAIL - Access is denied.
>
> But via explorer, the profile is accessible to the user with full
> permissions. Checked the share/ntfs and the user has full permissions
> but cannot load the profile.
> So even tried logging in to the old NT 4 domain and still could not
> load the profile and was accessible using explorer.
>
> Anyone had a similar experience?

Was a two-way trust established? What are the security permissions on the
actual location of the roaming profile?


--
Ace

This posting is a personal opinion based on experience, and is provided
"AS-IS" with no warranties or guarantees and confers no rights.

Ace Fekay, MCSE 2003 & 2000, MCSA 2003 & 2000, MCT
Microsoft Certified Trainer

For urgent issues, you may want to contact Microsoft PSS directly.
Please check http://support.microsoft.com for regional support phone
numbers.

Yes, a two-way trust was established.

The roaming profile parent folder's security permissions:
Share:
everyone full

NTFS=administrators = full
users = list folder and create folder

The acutal user's profile folder's security permissions:
%username% = full
Local System = full
Administrators = full

Thanks

"Ace Fekay [Microsoft Certified Trainer]" wrote:

> In news:CAA51066-1D0A-436D-841D-F3E70BC59FB5@microsoft.com,
> study <study@discussions.microsoft.com> requesting assistance, typed the
> following:
> > I just did a test migration from NT4 to 2003 using ADMT 3.0.
> > After the migration, the roaming profile doesn't load.
> >
> > Here's what I did.
> > First I migrated the groups then the users then the member server
> > which happens to be a file server and the XP clients.
> > When migrating the file server, for the translated objects, I've
> > selected
> > all (what options should I have selected for a file server?) and
> > chose "add" instead of "replace". The file server rebooted after the
> > agent did its thing.
> > When attempted to logon using already migrated user on a migrated XP,
> > I got
> >
> > Roaming profile not available
> > Event ID 1506 Your roaming profile is not available.
> > DETAIL - Access is denied.
> >
> > But via explorer, the profile is accessible to the user with full
> > permissions. Checked the share/ntfs and the user has full permissions
> > but cannot load the profile.
> > So even tried logging in to the old NT 4 domain and still could not
> > load the profile and was accessible using explorer.
> >
> > Anyone had a similar experience?
>
> Was a two-way trust established? What are the security permissions on the
> actual location of the roaming profile?
>
>
> --
> Ace
>
> This posting is a personal opinion based on experience, and is provided
> "AS-IS" with no warranties or guarantees and confers no rights.
>
> Ace Fekay, MCSE 2003 & 2000, MCSA 2003 & 2000, MCT
> Microsoft Certified Trainer
>
> For urgent issues, you may want to contact Microsoft PSS directly.
> Please check http://support.microsoft.com for regional support phone
> numbers.
>
>

Okay, second time was the charm. I've reverted back to the original state
and tried it again and this time, the user was able to load the profile.
1) When migrating the file server, for the translated objects, I've
elected all the options including the registry, files/folders, user
profiles, local groups, etc... is that what it's generally recommended?

2) During user migration, there's a check box for SID history migration.
What am I missing if I don't select the SID history option?

Thanks!


"study" wrote:

> Yes, a two-way trust was established.
>
> The roaming profile parent folder's security permissions:
> Share:
> everyone full
>
> NTFS=administrators = full
> users = list folder and create folder
>
> The acutal user's profile folder's security permissions:
> %username% = full
> Local System = full
> Administrators = full
>
> Thanks
>
> "Ace Fekay [Microsoft Certified Trainer]" wrote:
>
> > In news:CAA51066-1D0A-436D-841D-F3E70BC59FB5@microsoft.com,
> > study <study@discussions.microsoft.com> requesting assistance, typed the
> > following:
> > > I just did a test migration from NT4 to 2003 using ADMT 3.0.
> > > After the migration, the roaming profile doesn't load.
> > >
> > > Here's what I did.
> > > First I migrated the groups then the users then the member server
> > > which happens to be a file server and the XP clients.
> > > When migrating the file server, for the translated objects, I've
> > > selected
> > > all (what options should I have selected for a file server?) and
> > > chose "add" instead of "replace". The file server rebooted after the
> > > agent did its thing.
> > > When attempted to logon using already migrated user on a migrated XP,
> > > I got
> > >
> > > Roaming profile not available
> > > Event ID 1506 Your roaming profile is not available.
> > > DETAIL - Access is denied.
> > >
> > > But via explorer, the profile is accessible to the user with full
> > > permissions. Checked the share/ntfs and the user has full permissions
> > > but cannot load the profile.
> > > So even tried logging in to the old NT 4 domain and still could not
> > > load the profile and was accessible using explorer.
> > >
> > > Anyone had a similar experience?
> >
> > Was a two-way trust established? What are the security permissions on the
> > actual location of the roaming profile?
> >
> >
> > --
> > Ace
> >
> > This posting is a personal opinion based on experience, and is provided
> > "AS-IS" with no warranties or guarantees and confers no rights.
> >
> > Ace Fekay, MCSE 2003 & 2000, MCSA 2003 & 2000, MCT
> > Microsoft Certified Trainer
> >
> > For urgent issues, you may want to contact Microsoft PSS directly.
> > Please check http://support.microsoft.com for regional support phone
> > numbers.
> >
> >

In news:ADF6E017-C51C-47A0-8B44-D9BDC5703265@microsoft.com,
study <study@discussions.microsoft.com> requesting assistance, typed the
following:
> Okay, second time was the charm. I've reverted back to the original
> state and tried it again and this time, the user was able to load the
> profile. 1) When migrating the file server, for the translated
> objects, I've elected all the options including the registry,
> files/folders, user profiles, local groups, etc... is that what it's
> generally recommended?
>
> 2) During user migration, there's a check box for SID history
> migration. What am I missing if I don't select the SID history option?
>
> Thanks!

1. Actually, yes. When I run a migration, that is what I choose in order to
translate all associations to the objects over to the target.

2. SIDHistory allows the newly migrated user account to access the old
domain resources without needing to login. This is because ADMT, selecting
that object, will preserve the old SID with the newly created users'
account. When it connects to an old object, the SIDs are compared to the ACL
and if there's a match, it evaluates the permissions. You don't normally
need this unless you are co-existing with the old domain.

Ace

Thanks.
So for the user computer migration, I should also check off all the
selections for the translated objects as well?

"Ace Fekay [Microsoft Certified Trainer]" wrote:

> In news:ADF6E017-C51C-47A0-8B44-D9BDC5703265@microsoft.com,
> study <study@discussions.microsoft.com> requesting assistance, typed the
> following:
> > Okay, second time was the charm. I've reverted back to the original
> > state and tried it again and this time, the user was able to load the
> > profile. 1) When migrating the file server, for the translated
> > objects, I've elected all the options including the registry,
> > files/folders, user profiles, local groups, etc... is that what it's
> > generally recommended?
> >
> > 2) During user migration, there's a check box for SID history
> > migration. What am I missing if I don't select the SID history option?
> >
> > Thanks!
>
> 1. Actually, yes. When I run a migration, that is what I choose in order to
> translate all associations to the objects over to the target.
>
> 2. SIDHistory allows the newly migrated user account to access the old
> domain resources without needing to login. This is because ADMT, selecting
> that object, will preserve the old SID with the newly created users'
> account. When it connects to an old object, the SIDs are compared to the ACL
> and if there's a match, it evaluates the permissions. You don't normally
> need this unless you are co-existing with the old domain.
>
> Ace
>
>

In news:47E03A9D-3174-4A3E-9DF3-747D6D1EB355@microsoft.com,
study <study@discussions.microsoft.com> requesting assistance, typed the
following:
> Thanks.
> So for the user computer migration, I should also check off all the
> selections for the translated objects as well?
>

Yes, I would recommend it. You can run a test migration into a temp OU for
users and groups. If anything is wrong, you can wipe them and try again. But
this doesn;t apply to computer accounts. Once moved, they are disjoined from
the old and joined to the target. Make sure all computers are on but logged
off when you do the computer migration.

Ace