During my last two projects, my customers asked me to use USMT to migrate user data to a network location. The initial goal was to switch from a local profile on Windows XP to the user’s home folder on Windows 7. My initial answer was to avoid using USMT and to use a different process to move the data to the network. A simple script distributed with a teledistribution software would have been enough.
Of course this was not possible because of … you know … customers being … customers. Political Constraints, Technical Problems and very strong Egos prevented to do this so I had to come up with a different solution.
Before even thinking of the solution, my first customer asked me to try using USMT to send data on the network. And so I did (you know, they’re paying …).
- I first try to use the following syntax : <locationModify script=”MigXmlHelper.ExactMove(‘Z:’)”> where Z: was a mapped drive on the network … it didn’t work
- Then I tried to use the following syntax <locationModify script=”MigXmlHelper.ExactMove(“\\Server\Share\UserName‘)”> where \\Server\Share\UserName was the path to a user home folder. It didn’t work because I was using a different user, but I needed to establish that it was not possible to imagine a dynamic solution that would update the xml config file on the fly based on deployment variable to specify a given UNC path. Obvious but sometimes you have to prove the obvious to some customers.
- Finally <locationModify script=”MigXmlHelper.ExactMove(“\\Server\Share‘)”> where \\Server\Share was a UNC path that I had access to. I was very surprised but … it worked and USMT was able to restore file at this location
Now what ? let’s say you have 3 users sharing a workstation, if you use this syntax then all users data will be restored in the same location outside their profile, that’s not something we want to have and then we abandonned the idea.
Then came my second customer with an even more complex environment, their goal was to capture data from a local profile on Windows XP to a profile with folder redirection enabled on Windows 7. My initial answer was to activate Folder Redirection before the Windows 7 migration so that USMT doesn’t need to deal with data but only with application settings. The main reason was that USMT is designed to capture and restore files and settings locally on a computer.
Once again, not accepted by the customer because of the way Windows XP replicates redirected folders : at logon and logoff, generating sometimes long wait times resulting in user turning off their computer bestially
This time, I knew what USMT was capable of when it comes to network operations and after different discussion, we decided to use a robocopy-based script to send the data regularly (logon, etc) on the network. During the OS deployment, we decided to add a task to move the data on the network to the redirected folder’s location.
Another solution would have been to capture data with USMT, restore it using USMT too, and let Folder Redirection GPOs send data on the network. This solution is very straightforward but had a major issue, the time it would take to send the data initially.
USMT is a great tool, Folder Redirection is now better than ever with great new features, and OS migration has never been so powerfull, but when you need to combine those three factors, there are still great challenges and I really think that it should be easier to take care of Folder Redirection separately from the other two.