Well…You’ve been working for a long time with Windows XP, and now you got the approval to upgrade to a newer OS, and that’s Windows 7. I can already see the smile on your face. The downside of this, is that you can’t perform a direct upgrade. First, because is not supported by Microsoft, and second, because you want to upgrade from a 32 bit OS to a 64 bit OS. The only way is to do a clean install. But what about users data? Don’t worry, users data will not be lost during refresh, if you do it right. Now, I presume you already have MDT running in your network, if not, you should install it, because it’s a great tool and you will need it in order to do this lab and the migration. I also presume you have imported a Windows 7 X64 image in your MDTdeployment share.
If you don’t want to use that image, the one from the installation media, you can always install Windows 7 on a PC, customize it, set it up the way you want it, then capture the image and import it into MDT. In my deployments I always use this approach, because I don’t like to have those Windows effects and default themes on my systems. There are two ways to deploy using MDT, a manual way and a more automated way, using MDT rules. I will show you both, but right now, let’s start with the first one. After you imported the Windows 7 x64 image in MDT, you need to create a Task Sequence. For that, right-click the Task Sequences folder and choose New Task Sequence. On the Select Template page go with the Standard Client Task Sequence, then on the next page select your operating system. Finish the wizard using the default settings. If you need a more detailed guide on how to create a task sequence, follow this link.
You should now have a task sequence present in your MDT Workbench deployment share.
Before we update the Deployment Share and start the XP migration, make sure you have the proper network drivers imported in MDT. This is necessary, because the system will reboot, then start from a WinPE image. If the WinPE image does not find a proper network driver it will not get an IP address from your DHCP server and will not be able to connect to the Deployment Share. How to add drivers to MDT boot images, is showed in this guide.
Now you can update the Deployment Share.
Everything is set up, everything is in order; let’s start the migration. Log in to one of your Windows XP systems with an account that has read/write permissions to the MDT deployment share and do a Start > Run. Here type the path of your Deployment Share.
Open the Scripts folder and run the LiteTouch.vbs file. This will launch the Windows Deployment Wizard.
Select the Task Sequence tight to your Windows 7 image and click Next.
In the first box, type a computer name if you want to change the existing one, then select if the Windows 7 (future Windows 7) system will be part of the domain.
This is an important page, so you need to do this right, because user data is at stake. You have the option to save the users profiles to a share, or to just leave them locally and the wizard will move them back after the refresh/migration finishes. I created a share on my MDT server for users data, because I don’t like to leave users profiles on the local workstations hard drive. I recommend you use a file server for this operation, because the MDT machine will be busy enough deploying images.
If you want to backup the Windows XP system before is wiped out, you can do this, again, locally or over the network. The wizard will create a .WIM image from the current OS. By backing up the system, it will dramatically increase the refresh/migrate time.
Specify the time settings and local preferences then click Next.
If you want to enable BitLocker on the system, just select Enable BitLocker then choose where to store the recovery key.
On the Ready to begin page click Details if you want to see all your selections, if not, just hit the Begin button to start the migration.
If the system passes validation, the wizard will start the migration by capturing user profiles using USMT (User State Migration Tool), injecting drivers, applying WinPE settings, etc.
After all this, the system will be restarted and it will boot into a WinPE environment and start the deployment.
At the end, you should have your Windows 7 system ready, and all user profiles restored.
OK, doing all this works better than copy and paste users data, and manually installing the Windows 7 system. But for how long can you do this ? is still a lot of work. There is another way, a more automated way, but it has some drawbacks, which I’m going to tell you as we move forward. To automate the refresh/migration process, you will have to create and configure an MDT database, populate it with computers, and create some rules. If you don’t know how to do all this stuff, please follow the links, read the articles, then come back here and continue. You need to create an MDT database and populate it because there is a computer naming “issue”, and if you don’t do it, your computers will have some strange names instead of the desired ones. Here I have one computer populated in the database
and I’m going to use its MAC address to tie it to the settings I want for this machine; the machine name.
The rules need to be created so you don’t have to keep clicking Next on the Deployment Wizard pages. To create the rules right-click your Deployment Share and choose Properties.
Go to the Rules tab and type/paste the following rules:
You will need to modify some of them to match your configuration and network. Like the path where to save users data, the credentials used for joining machines to the domain (Administrator in this case). The account needs to have rights to create/modify objects in AD.
[Settings] Priority=CSettings, RSettings, Default Properties=MyCustomProperty [Default] _SMSTSORGNAME=vKernelRO | www.vkernel.ro OSInstall=Y SkipComputerName=Yes SkipDomainMembership=YES JoinDomain=vkernel DomainAdmin=Administrator DomainAdminDomain=vkernel DomainAdminPassword=admin SkipCapture=YES SkipAdminPassword=YES SkipProductKey=YES SkipComputerBackup=YES SkipBitLocker=YES SkipUserData=Yes UserDataLocation=NETWORK UDShare=\\server-mdt\usersbackup UDDir=%computername% SkipLocaleSelection=YES KeyboardLocale=en-US UserLocale=en-US UILanguage=en-US SkipTimeZone=YES TimeZoneName=Central Standard Time SkipTaskSequence=YES TaskSequenceID=002 SkipSummary=YES
Now right-click Database and choose Configure Database Rules.
On the Computer Options screen check only the first option, Query for computer-specific settings. If you have applications that you want to be installed only on specific computers you need to check the third box too.
On the next two screens disable all the boxes, because we don’t need them right now.
Here enable only the first option, Query for role-specific settings and click Next.
On the Summary screen hit Next to apply the changes, then Finish to close the wizard.
If you take a look at the Rules tab, you can see that some new rules were added, database rules.
Before moving on, I want to discuss a “problem” that I encountered during my testing and migrations with the SkipUserData rule and it’s parameters. If you configure it, like you see in the above or bellow example
SkipUserData=Yes UserDataLocation=NETWORK UDShare=\\server-mdt\usersbackup UDDir=%computername%
and your computers that you want to migrate have two partitions, after the migration is done, all the data from the second partition will be copied to the root of the C drive. Some exclusions need to be made in USMT .xml files if you don’t want files from other drives except C to be backed up, but that’s for another time. The system that I will migrate in this lab has only one partition, the C drive, so for me the SkipUserData rule is going to work. Don’t hit OK if you did not configured the Bootstrap.ini. This is to bypass the login screen in the WinPE environment. After your done, update the Deployment Share.
The user that I’m logged in with is a simple domain user with some files on his Desktop.
If you try to run the LiteTouch.vbs script under a domain user, the Deployment Wizard will launch an error: “You do not have the correct permissions to perform this deployment. Please run as a local administrator.”
So the story goes like this: in order to run the script, you need to launch it under a user that has local admin rights on the workstation. Ouuuu Adrian you say ! Now, don’t panic, you can use the runas command, you remember it, right ? Here is what I do. I create a user, give that user local admin rights on all the workstations I want to migrate then send an email to the users:
run this command and provide the following password when asked.
What harm can the user do with this ? None, if it’s not and advanced user. How, how many of your users know how to run programs/scripts under a different account ? If you think you will have problems with this, you can further restrict it, by denying permissions to this account to log in to any computer. Any way, is your choice, I told you there will be drawbacks with this method. To be able to run the script under a user account, type this line in a Run window:
runas /user:mdtdeploy @vkernel.local "cscript \\server-mdt\deploymentshare$\scripts\litetouch.vbs"
where mdtdeploy is a local administrator account. Off course, replace the credentials and the script path with your own.
Provide the password and hit Enter.
The Microsoft Deployment Toolkit wizard will launch, and it will need a few minutes to process the rules
but when is done processing them, the migration will begin.
If you used a UNC path to save user data/profiles, and open that share you should see a folder with the name of your workstation(s). Inside this folder is the USMT capture state data.
After the Windows 7 installation is complete the MDT wizard pops-up and starts restoring users data.
If the MDT wizard pops-up without errors or warning, you are good to go.
Don’t be shocked if your desktop is empty. This is because the system is logged in with the local administrator account. Just log off then log back in with the domain user account, and all your data should be back, but this time on a Windows 7 system.
The migration succeeded, with a few small impediments, but MDT is a great option if you don’t have the money to pay for System Center Configuration Manager (SCCM).
Want content like this delivered right to your