Some Basic Questions about Side By Side Migrations

[kcdinga]

Hello,

 

I am working on some task sequences to migrate data during a side by side migration in OSD. We are using SCCM 2007 R2 with MDT 2010 integrated. I have USMT 4.0 installed on the primary site.

 

I have used ANYWEBs recommendations, and can get the In Place Migration with Hardlinking to work just fine, but I need a solution when upgrading the hardware also.

 

Up until now, I was under the impression that I could create a Computer Association (Source and Destination) and then use a single task sequence to capture the data from one pc, migrate it to a Storage Point, apply the image to a new baremetal machine, and then restore the data to the new machine. I have imported the Side by Side Migration task sequence from ANYWEB, and it does show a single task sequence that will accomplish this...however, I believe you need to pixie boot, and we are unable to pixie boot due to network configuration issues.

 

Is there a way, to use two separate task sequences to capture data and restore data to a new machine?

I would assume I could create a collection for the source computer and the destination computer...import my baremetal pc and associtate it with the source computer and then advertise the tasks (one to the collections. Would I be able to use boot media for the bare metal machine?

 

I appreciate any help you can provide.

 

Ray

[anyweb]

hi Ray,

if you cannot pxe boot due to network issues (what issues are they ?) did you know that you can create standalone media (cd) to handle that part of the boot process and the rest will be performed as normal ?

 

the suggestions i offer are only one way of doing things, you could of course do it differently and use some HTA frontend which links to variables in your task sequence which in turn decides what gets migrated and when

 

hth

cheers

niall

[kcdinga]

hi Ray,

if you cannot pxe boot due to network issues (what issues are they ?) did you know that you can create standalone media (cd) to handle that part of the boot process and the rest will be performed as normal ?

 

the suggestions i offer are only one way of doing things, you could of course do it differently and use some HTA frontend which links to variables in your task sequence which in turn decides what gets migrated and when

 

hth

cheers

niall

 

Thank you for your response Niall...This is one area that I just am not getting for some reason. Would the steps below seem logical? or do you have a better way to accomplish this?

 

1. Create a task to Capture user settings in SCCM.

2. Create a collection for the capture of the source computer user settings

3. Advertise the task to the newly created collection from step 2 and make it available to boot media

4. Create a task sequence to build the machine and restore user settings in sccm

5. Create a collection for the restore/build of bare metal equipment

6. Advertise the task sequence to the Restore collection from step 5 and make it available to boot media

7. Import computer information from the bare metal machine in to computer association, and associate the Source and Destination computers

8. Add Source computer to the collection from Step 2 and boot using the boot media

9. Add Destination computer to collection from step 5 and boot using the boot media

 

I really appreciate the help! This site is really great for us users who are not as experienced.

 

Ray

 

ps- I really do not know the reason why I cannot use PXE boot on our network. I was just told as I moved into this role, and managing our older BDD setup that we could not. We have some new blood on our Network Engineering team, and I think its time to bring this up again. I will let you know what their reasoning was for "do not pxe boot"

[ArmitageID]

I am having a similar issue. I am trying to do a side by side migration, but my USMT backup to the SMP results in creating an In-Place migration object in Computer Associations. I have an association for the source machine to the destination machine, but so far no luck.

 

I have two Task Sequences and am running both of them from within Windows (Capture done in XP and Restore done in Win 7)

 

I do not understand that part about having to PXE boot to do a side-by-side migration. Every time I try to run my Task Sequence it errors out and the logs state that I cannot do the Request State Store or the Capture User State from within PE.

 

Do you have an example Task Sequence that shows how this is done (The side-by-side...I can do an inplace xp-7 on the same machine SMP or hardlinked). I'd much appreciate it.

[anyweb]

can you post the smsts.log file from a failed attempt at capture user state from a PXE booted task sequence please ?

[ArmitageID]

Sure thing. Here is what I have. The smsts_scan.log is from running my Task Sequence from WinPE. AS you can see, it will not talk to the SMP for the site since it is in WinPE.

 

smsts_scan.log

 

The second attachment, smsts-20100916-140850.log is when I am trying to do a restore to a Win 7 system. I have a computer association setup in SCCM, but there is not a storage location defined on it.

 

smsts-20100916-140850.log

 

AS originally stated, when I did my USMT backup in Windows with the same TS that fails in WinPE it creates a backup on the SMP, but shows up as an In-Place object under computer associations.

 

Thank you for your help on this.

[ArmitageID]

Also, while you are looking at those, here is a file from running the same TS on my source PC from XP.

 

Here are the computer associations for the machine. The bottom one was generated after the backup TS finished.

 

 

Here it shows the store information for the laptop, but it is an In-Place

 

 

The association shows absolutely nothing

 

 

Here is the smsts.log file from the upload TS

 

smsts.log

 

Thanks again for your assistance. MY head aches from banging against the wall.

[ArmitageID]

Sorry for all the posts....still working on this issue.

 

Have another question. Do I need to be using USMT 3.0.1 for this to work? For migration from XP to Win 7?

 

I know USMT 4.0 does not support XP to XP....just wondering if for some reason that is why it isn't updating the computer association in my case....

 

So, for Win 7 -> Win 7 side-by-side the TS can use USMT 4.0 but when I do a Win XP -> Win 7 side-by-side it may need to use USMT 3.0.1?

 

I know the tutorial you have on your site is using USMT 3.0.1, so not sure if that is the root of my issues with why it wont update the computer association after the capture state runs.

 

Thanks again for any input!

[ArmitageID]

Another update.

 

I decide to try a Win 7 -> Win 7 computer association and USMT to SMP migration. Same results. It connects to the SMP and uploads the data, but it shows up as an In-Place and doesn't do anything to the computer association I created before hand.

 

Steps I did:

 

1. Created "Win 7 to Win 7 migration" to SMP Task Sequence using USMT 4.0 in SCCM

2. Create a computer association between Win 7 machine A and Win 7 machine B (Both belong to the same Site).

3. Add the source computer to a new collection folder called "Win 7 to Win 7 SMP Migrations"

4. Advertise the "Win 7 to Win 7 migration" TS to the "Win 7 to Win 7 SMP Migrations" Collection

5. While running Windows 7, I told Config Manager to check for new programs and about 2 seconds later it popped up with the "Win 7 to Win 7 migration" TS.

6. I ran the TS and it created a folder on the SMP (This runs solely in Win 7. It never boots into PE or anything like that)

7. Job finished and released the store successfully.

8. Machine pops into the Computer Associations tab as an In-Place disregarding the association I created in step #2.

 

I just don't know what I am doing wrong here.

[kcdinga]

Another update.

 

I decide to try a Win 7 -> Win 7 computer association and USMT to SMP migration. Same results. It connects to the SMP and uploads the data, but it shows up as an In-Place and doesn't do anything to the computer association I created before hand.

 

Steps I did:

 

1. Created "Win 7 to Win 7 migration" to SMP Task Sequence using USMT 4.0 in SCCM

2. Create a computer association between Win 7 machine A and Win 7 machine B (Both belong to the same Site).

3. Add the source computer to a new collection folder called "Win 7 to Win 7 SMP Migrations"

4. Advertise the "Win 7 to Win 7 migration" TS to the "Win 7 to Win 7 SMP Migrations" Collection

5. While running Windows 7, I told Config Manager to check for new programs and about 2 seconds later it popped up with the "Win 7 to Win 7 migration" TS.

6. I ran the TS and it created a folder on the SMP (This runs solely in Win 7. It never boots into PE or anything like that)

7. Job finished and released the store successfully.

8. Machine pops into the Computer Associations tab as an In-Place disregarding the association I created in step #2.

 

I just don't know what I am doing wrong here.

 

I ended up canning the whole usage of USMT 4.0 in SCCM for side by side migrations. Now I use a batch file that includes the command line for USMT Scanstate and Loadstate using offline migration. I basically do the following:

 

1. build my new machine using SCCM

2. Pull the hard drive from the old machine and connect it to the new machine (either via USB or E-Sata)

3. Plug in a USB thumbdrive containing USMT 4.0 and my batch files for both scanstate and loadstate

4. Verify the drive letters match the drive letters in my command line in the batch file (there are many ways to get around this step...I am just lazy)

5. Run Scanstate.bat (this runs scanstate using the following command line:

e:\USMT\x86\scanstate.exe C:\Migrate /offlineWinDir:F:\Windows /o /localonly /c /efs:copyraw  /v:5 /l:E:\Logs\scanstate.log /progress:E:\Logs\scanstateprogress.log /i:E:\USMT\x86\miguser.xml /i:E:\USMT\x86\migapp.xml /uel:90 /ui:ats\*

You will want to modify this, as I am only pulling domain profiles...so ATS is our domain

You will notice that I am saving logs back to the thumb drive...I am scanning a windows folder on the E drive (the drive we pulled from the old pc) and a local store on the new pc C:\migrate.

 

6. Run Loadstate.bat (runs the loadstate on the new pc)

e:\USMT\x86\loadstate.exe C:\Migrate /c  /v:5 /l:E:\Logs\loadstate.log /progress:e:\Logs\loadstateprogress.log /i:E:\USMT\x86\miguser.xml /i:E:\USMT\x86\migapp.xml /lac /uel:90  /ui:ATS\*

Again, we are running the loadstate from our thumb drive...it is saving the logs to the thumbdrive...and it is restoring the data from the mig file created on the local C drive from our scanstate.

 

It just works for us...seems pretty simple, and cuts down on the amount of time to migrate data. We migrated 17GB with 15000 files..took 12 minutes to scan...and 9 min to load.

 

Hope this helps.

 

PS- the batch files are simply the code snippets above...just copy and create a batch file with each of the command lines (and adjust for drive letter differences and whatnot)

[ArmitageID]

I ended up canning the whole usage of USMT 4.0 in SCCM for side by side migrations. Now I use a batch file that includes the command line for USMT Scanstate and Loadstate using offline migration. I basically do the following:

 

1. build my new machine using SCCM

2. Pull the hard drive from the old machine and connect it to the new machine (either via USB or E-Sata)

3. Plug in a USB thumbdrive containing USMT 4.0 and my batch files for both scanstate and loadstate

4. Verify the drive letters match the drive letters in my command line in the batch file (there are many ways to get around this step...I am just lazy)

5. Run Scanstate.bat (this runs scanstate using the following command line:

e:\USMT\x86\scanstate.exe C:\Migrate /offlineWinDir:F:\Windows /o /localonly /c /efs:copyraw  /v:5 /l:E:\Logs\scanstate.log /progress:E:\Logs\scanstateprogress.log /i:E:\USMT\x86\miguser.xml /i:E:\USMT\x86\migapp.xml /uel:90 /ui:ats\*

You will want to modify this, as I am only pulling domain profiles...so ATS is our domain

You will notice that I am saving logs back to the thumb drive...I am scanning a windows folder on the E drive (the drive we pulled from the old pc) and a local store on the new pc C:\migrate.

 

6. Run Loadstate.bat (runs the loadstate on the new pc)

e:\USMT\x86\loadstate.exe C:\Migrate /c  /v:5 /l:E:\Logs\loadstate.log /progress:e:\Logs\loadstateprogress.log /i:E:\USMT\x86\miguser.xml /i:E:\USMT\x86\migapp.xml /lac /uel:90  /ui:ATS\*

Again, we are running the loadstate from our thumb drive...it is saving the logs to the thumbdrive...and it is restoring the data from the mig file created on the local C drive from our scanstate.

 

It just works for us...seems pretty simple, and cuts down on the amount of time to migrate data. We migrated 17GB with 15000 files..took 12 minutes to scan...and 9 min to load.

 

Hope this helps.

 

PS- the batch files are simply the code snippets above...just copy and create a batch file with each of the command lines (and adjust for drive letter differences and whatnot)

 

Thanks for responding, but this will not work in our scenario. Due to the number of deployments and location etc we won't be able to move hard drives. We will have to use the SMPs to hold the data for the migration. I found this hotfix today and I'm wondering if it will help resolve this problem.

 

http://support.microsoft.com/?kbid=980270