K1000/K2000 User State
I am working on streamlining our deployment process. We currently use both the K1000 and K2000. I am running into a bit of a sequencing issue with our PC deployments that I am sure some others have had.
We tend to begin a PC build a couple of days before the build. I love what the K2000 does and with the user states. Only problem is, if I want to image a machine a couple of days ahead of time and have it ready I can't do a scan of a user state, as docs and other things may have changed.
Is there anything I can do to leverage the power of the K1 or K2 but after the image has been laid down? If not, is the best bet to work at making a gold image and create post install tasks for every little thing so that I can wait until the last second to image before a scheduled deployment?
-
Is the K1000 also able to retrieve user state information like the K2000 does? - shandobj 7 years ago
Answers (1)
On our admin side we pull a mig file a couple of days prior to replacement to give us time to get the box installed with any special software or printers for that machine. We then the night prior to replacement, inform the user we will be swapping the box out in the morning. We use a k1000 script to pull a mig from the old machine and then have a kscript that runs 1-2 hours after to put the final mig on the target machine. I placed the usmt files on a windows share and run the tasks and put the mig files there. I have recently modified the scipt to remove the machine from the domain and shut it down to make sure the user does not use the old box after we pull the final mig.
We have a wol server so at 4am we wake the box targeted to be upgraded and pull the first mig and shut the computer backdown.
I use the proper bit version of the 2 scripts "Aquire User Migration States to computername Directory..." to pull the first mig. It creates a directory with the machines name and puts the files there.
The night prior to replacement we wake it at 4 am and pull the mig to the default mig directory (old files are over written here so you can olny pull one mig at time with this method). Then depending on the size and time to create the first mig we time the apply script to run after 5am but before 7am. This script also removes the machine from the domain so users are unable to login on the old one and make changes after the final mig is pulled. You could create a unique script for each final apply and pull it mig from the machine dir also if you wanted, just replace "\migstore" in the put bat with the name the get by machine created when it ran. But you would need a script for each put since the new machine may not have the old machines name, you cannot use the %COMPUTERNAME% variable
here are some samples of the bat files I run to get/put the states then on remediation I either shutdown or remove and shutdown.
Getthemig64bit.bat
net use v: \\dr-main\images /user:domain\user password
v:\usmt\amd64\scanstate v:\usmt\migstore /i:v:\usmt\amd64\migapp.xml /i:v:\usmt\amd64\miguser.xml /l:v:\usmt\migstore\mig.log /o /v:5 /uel:120 /ui:admn\*
Putthemig64bit.bat
net use v: \\dr-main\images /user:domain\user password
v:\usmt\amd64\loadstate v:\usmt\migstore /i:v:\usmt\amd64\migapp.xml /i:v:\usmt\amd64\miguser.xml /l:v:\usmt\migstore\mig.log /v:5 /uel:120 /ui:admn\*
Migbymachine32bit
net use v: \\dr-main\images /user:domain\user password
v:
cd usmt
md %COMPUTERNAME%
v:\usmt\x86\scanstate v:\usmt\%COMPUTERNAME% /i:v:\usmt\x86\migapp.xml /i:v:\usmt\x86\miguser.xml /l:v:\usmt\%COMPUTERNAME%\mig.log /o /v:5 /uel:120 /ui:admn\*
