The frustration when migrating to a new workstation
“Ohh damn, I need to re-create my Explorer favorites, I need to re-enter my wireless profiles..”
Those are some of the comments you will hear from users receiving a new machine in a Service Desk function. Don’t worry, this tool includes it all, and will work when migrating from Windows 7 to Windows 10 as well!
Users will be able to migrate data them self by running this tool from Software Center.
In many cases, enterprises dosen’t offer an easy solution when it comes to migrating data from one machine to another. The best free tool i have come across is the User State Migration Tool (USMT) which is included in the Windows ADK. Sadly this solution is a command-line tool, and dosen’t offer an GUI. Then i came up with a solution. By combining PowerShell App Deployment Toolkit(PSADT) with USMT I made it easy to make this accomplishment. Be aware that this tool requires local administrative privileges for the end user, or making a package running as the local system account on the client PC.
If there is an external USB storage connected, the user gets the option to backup/restore to that location or the network location.
So what does the Data Migration Tool consist of?
The tool consist of a script installer “Deploy-DataMigrationTool.ps1” and a folder containing the installation files. Basically the installer will copy the files to “C:\Program Files (x86)\Data Migration Tool” and log to “C:\Windows\Logs\Software”. It will also create a shortcut in start “C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Data Migration Tool.lnk”.
There is two ways of deploying this tool with SCCM:
- Can run as admin and system: Make a package that contains the files in “.\Data Migration Tool” and executes the “.\Deploy-Application.exe”
- Requires local administrator previledges: Make an application that contains all files in “.\” which executes “.\Deploy-DataMigrationTool.ps1” for installation and “.\Deploy-DataMigrationTool.ps1 -uninstall” for the uninstallation, and a detection method checking for the presence of the “C:\Program Files (x86)\Data Migration Tool” folder. (You can change the installation destination an log location in the top of the script).
I prefer option two because this will make a shortcut in start, and can be deployed on the users machine before usage.
Before you begin
Before you test and deploy the tool, change the $NetworkLocation variable in the “.\Data Migration Tool\Deploy-Application.ps1” file, or re-define it in the commandline when using deployment method 1.
By defining the correct rights on the network location you can ensure that it’s only the ‘CREATOR OWNER’ of the migration files/folders that can access their corresponding files.
After specifying the $NetworkLocation variable, and done the correct NTFS rights on the share, run the “.\Deploy-DataMigrationTool.ps1” as described in method 2, but only now do it on your local machine.
Start the program from Start
Now start the backup. (If a restore is present on the share or USB, a button will be present.)
When users are not local admins
If you are in an environment where users are not local administrators, the best solution is to run this as a package in system context. Below i describe how this can be archived. Be aware that this solution will give every system(computer object) account access to all folders in the share. There is no way to overcome this unless you want the user to type in the hostname of the PC performing the restore. One could setup a cleanup script on the server hosting the share, to delete backups older than 14 days.
1.Create a folder and give Everyone full control on share permissions. I recommend to make it a hidden share.
2. Give Domain Computers modify rights.
3. Type in the share variable in the script : $NetworkLocation and create the package.
4.Create the program:
Remember to edit the Environment tab:
5.Deploy the package as an Available deployment to a user collection.
The user are now able to run the package via Software Center! After a User policy update ofc 🙂
-Removed the parameter -NoAppSettings switch from the Start-UserStateMigrationTool function call in the Deploy-Application.ps1 script.
-Removed the custom XML from the command line string in the Start-UserStateMigrationTool function located in the AppDeployToolkitExtensions.ps1
-Changed the current user variable to be the current user session instead of running context. Was an issue if running as system.
I would very much like to improve this tool, so please share ideas!