I have seen a few forum posts vaguely similar to this one, but none containing an answer for this specific scenario: All of the clients in my enterprise login with the Novell client. Even though the users are authenticating to a network server to sign in to their machines, it's Novell and not AD so it creates what Windows considers a local profile for them on the machine. I am using a standard task sequence to upgrade workstations from XP to Win7, join them to the domain, and migrate all user accounts (USMT 4). Everything works, but when I sign in as my domain test user (who had a pre-existing local account with identical credentials to the domain account) Windows creates a separate account. The old profile is on the machine as "test" (with all Desktop and My Docs data intact), but when I log into the domain with that same user it creates a local "test.ad" profile folder. Is there any way to overcome this internally in SCCM or externally with some kind of post-script? Basically I just need the domain user login to use the existing (migrated) local profile folder and not create a fresh one. Thanks!

USMT can handle this for you. Refer to the following post: http://social.technet.microsoft.com/Forums/en-US/itprovistadeployment/thread/c843afe7-d3c3-45f8-b927-d4d7d419bd29.Jason | http://myitforum.com/cs2/blogs/jsandys | Twitter @JasonSandys

I don't think the answer marked in that thread will work for in my scenario for two reasons: 1. I'm using hard-linked user state migration. 2. The domain accounts aren't using roaming profiles.

Roaming profiles is not part of the solution in that thread -- it is mentioned but discounted. I don't think hard-links will make any difference. Hard-links don't change the end result of what USMT can do, just how it gets there with respect to physically moving or not moving files. All hard-links do is physically preserve files on a disk, it has nothing to do with where they appear in a logical folder structure.Jason | http://myitforum.com/cs2/blogs/jsandys | Twitter @JasonSandys

I'm having some difficulty getting USMT to accomplish this. I've added a USMT variable to the User Restore stage of my task sequence: Task sequence variable: OSDMigrateAdditionalRestoreOptions Value: /mu:%username%:DOMAIN\%username% I've also tried a particular user account (/mu:test123:DOMAIN\test123). No luck. No errors, but the pre-existing local profile is not used by the domain user account. I keep getting one step out of a dozen from different forum posts. Does anyone have a thorough procedure they follow?

ablackar123 did you ever get this working in the end. I'm currently looking at doing the same solution for a Novel to AD upgrade in which a machine will need to capture the local profile > join the domain > restore to domain userid (No OS upgrade) Have been looking at performing this manually with a LTITouch Wizard (MDT) or preferably fully automated with SCCM. How did it all go?

If anyone is still interested in this thread. I managed to accomplish this with a Novell to AD migration. All machines would logon locally with a account 'login'. Machines were then added to the domain and users were given a %username% for the active directory domain. We needed them to have there profile moved to the new domain user account profile scanstate.exe c:\tempprf\%computername% /targetxp /v:13 /i:migapp.xml /i:miguser.xml /i:migsys.xml /c /o /l:c:\scanstate.log /localonly /ue:*\* /ui:login loadstate.exe /i:migapp.xml /i:miguser.xml /i:migsys.xml c:\tempprf\%computername% /l:c:\load.log /mu:login:domain\%username% Loadstate was run using user permissions in the sccm program configuration for the %username% variable to return that environment variable successfully. We performed these actions using SCCM. Because this was an XP - XP profile migration I also had to use a older version USMT 3.0 Arran