Hello,

We are planning for interforest migration,  We have a special situation which is posing a challenge and wondering if we have any option to tackle this.

- few source\users are logging on to target\computers currently.

- Post user migration we want the target\users to retain their profile when they logon to target\computers

I know that we can modify the registry hive to map the profile , but is that sufficient since we are not processing any ACL's on files/folders/printers etc. 

Appreciate if anyone came across this kind of scenarios.

thanks

J

I'd have to test your scenario. if you have a migration lab already test the forensit tool

http://www.forensit.com/domain-migration.html

I've used it in the past for migrations but it has been a few years.

THanks

Mike

You need to provide more information.  How are you planning to perform an interforest migration?

Here is an option to merge the users if they are already present in target

Part I - User Account Migration and Merging Using ADMT

Part II - User Account Migration and Merging Using QMM

You can change the registry using this procedure - http://portal.sivarajan.com/2010/04/workstation-profile-migration.html

Hey Santosh,

We are planning to use QMM to migrate the user accounts. We cant go for the merge option since the user accounts are not present in the target domain.

Here is the scenario that we have

- Source\user1 logging on to target\computer1 getting Profile

- Post user migration it should be , target\user1 logging on to target\computer1 and should get profile1.

thanks

J

You can use USMT tool for the profile migration, it might help you.

http://blogs.technet.com/b/danstolts/archive/2009/09/02/migrate-windows-xp-to-windows-7-using-usmt-user-state-migration-tool-upgrade-xp-or-vista-step-by-step.aspx

Hi J,

Just to confirm, are you talking about going into HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList, taking a copy of the data from the source accounts key, creating a new key using the destination accounts SID and placing the data in there ... logging in with either account will reference the relevant SID in ProfileList but both reference the same ProfileImagePath?

If so, are you migrating the accounts with sidHistory? If you are then you shouldn't need to worry about permissions on the profile as both the source and destination SIDs will be present on the account. http://technet.microsoft.com/en-us/library/cc779590(v=ws.10).aspx
The only gotcha's I've had is if both source and destination accounts login referencing the same ProfileImagePath without a reboot in between. If ntuser.dat is still locked or refcount is not 0 at the time of the login Windows can mark the profile as corrupt.

Access to other resources (file shares, printers etc) should also continue to work if access is granted to the user account directly or via group membership as long as you migrate the source SID into the sidHistory attributes on the target objects.

The only gotcha's are the well known SIDs on built-in groups such as Domain Users as they cannot be migrated. For those gotcha groups I've used subinacl in the past to append the target domain's Domain Users wherever the source domains Domain Users group was found all the various file shares. Something like:

subinacl /subdirectories C:\SubInAcl\*  /migratetodomain=sourcedomain=targetdomain=mapfile.txt

where mapfile.txt simply contains: domain users=domain users

Using the Domain Users=Domain Users may be OK if you want to migrate to a new domain but if it's for a merger you may not want to open up these shares to ALL the accounts in the target domain so create another manual group.

I hope this helps,

Mark.

target\computer1 - Is not a migrated computer.  Correct?  Did you create this computer in the Target domain manually?

Agreeing to Awinish advice you can use AD migration tool.

Please have a look at this blog recommended by him as without a third party application it is difficult to this task.

Thanks.

Hello Santhosh,

We have created the target computer accounts manually - it was done as part of hardware refresh and the users were given new machines with computer account in target domain.

Will QMM be able to handle this via RUM even though the machine is in target domain?

thanks

J

Hello Mark,

We will be decommissiong the source domain after all the user have been migrated. So essentially the access via SID history will not be viable. (?) . We are looking to translate the permissions as well.

thanks

J

Hi J,

As far as I know, when you login your objectSID and any SID's in your sidHistory as well as the objectSID's and all SIDs in the sidHistory of the security groups you are a member of (directly or via nesting) are combined into an access token. This access token is presented when you are trying to access a resource and there isn't a reliance on the domains where any of the SIDs in your sidhistory originated from. The effectiveness of the SIDs in your sidHistory would only be compromised if you were attempting to access a resource across a trust as certain SID's could be filtered out depending on the SID Filtering\Quarantining configuration: http://technet.microsoft.com/en-us/library/1f33e9a1-c3c5-431c-a5cc-c3c2bd579ff1

Hopefully not spreading misinformation and someone could correct me if any of the above is incorrect.

Thanks,
Mark.