Deploying the SCCM 2012 Client to WES 7 devices that are locked down with the FBWF using 2007 task sequence via WEDM.

Question

I'm wondering how people are migrating their embedded devices that are using the FBWF. I've done some googling and it seems like most people are just re-imaging the devices and after migrating a single device i see why. Its not a pretty process. This will
be a long description but ultimately my question stems more from trying to find a better way to execute the device migration from 2007 to 2012.
Some back ground on my situation might be in order here. I'm in the process of wrapping up our 2007 to 2012 migration. We have a 2007 infrastructure that was a central server with 2 primaries and 286 secondary site servers. I've consolidated that to a single
2012 primary site server that hosts all the main roles. There are 2 more servers in the data centers both operating solely as push distribution points I'll refer to them as 2012 01 02 and 03. I'm over half way through the migration and so far haven't needed
to offload any site roles. There are almost 10,000 clients now reporting to the 2012 site server and almost a 100 field servers pulling content from 2012 02 as their source dp as pull dp is the only way forward for this many devices. I've read the horror stories
of trying spin up 200 plus push dps. We are running PKI. I'm at the point now where i need to start migrating the Windows Embedded Seven Standard clients that have the 2007 sccm client on them with WEDM for write filter handling.
What i'm wondering is if anyone has any pointers for me regarding migrating the WES 7 devices. My plan that i've come up with is to somehow script the process using a 2007 WEDM Task Sequence to try and migrate them over to 2012. Things are complicated as
I need to somehow script the install, the policy checkin, hardware inventory, software inventory, and validate the SCEP client installs before I reboot the device one last time to enable the FBWF. How I handled the SCCM 2007 client install on these devices
when they were provisioned was to just create a batch file that would sleep for ten minutes then check to see if the inventoryagent.log file had been created yet. I realize now that is inefficient as i can kick off the inventory using a WMI method once the
client has installed. Also I need to make sure the machine gets its first policy as that is how it creates the communication using PKI through that first policy transfer and that also finalizes the client install. The biggest piece i'm uncertain about in this
regard is the SCEP client.
I had to change the SCEP client install from yes to no in the default client settings as we have some Mcaffee servers that can't have the SCEP client on them. I have incremental updates enabled on the collection that has the policy that installs the SCEP
client but this will take an unknown amount of time unless i force the environment to update as the device starts in 2012 install, or if I could kick off the SCEP isntall... IDK. I'm also wondering if i should keep the device in the migration process until
i validate it has its proper scep policy applied which I believe can be validated by a registry key somewhere.
Once the 2012 client gets installed will that cause it to lose its place within the 2007 Task Sequence? Considering its going to take a minimum of 2 reboots I'd normally use the task sequence to handle its progression through the process.
I'm also considering trying to use an Orchestrator runbook, as that would be a good way to keep track of the migration process as each device migrates. Especially since this might take several seperate scripts.
I'm going to take a stab at scripting the migration process, but if anyone has any pointers that might make this a less complicated I'd really appreciate it as I've got about 3000 of these devices that need to be migrated over. The other things i've learned
the hard way is any time you have something this complicated over the course of 3000 devices you will run into unknowns and the failure rate increases. I'm in the precarious position of having to not only build this process out but in some situations have
it complete in the shortest amount of time possible as we have sites running 24x7. I know the end users behavior all to well and they will just keep hitting the power button sometimes even though their not supposed to so they can get their device functional
again. In those situations i'd end up, if i'm lucky with a device that no longer has a healthy SCCM client in either environment and the write filter disabled.
So like i said any pointers anyone could throw my way i'd really appreciate. I manually went through the migration process on a single device for proof of concept and ended up with almost 2 pages of pseudo code for my migration script/scripts.
Thanks,
-K.R.

Answer 1

Hi,
In R2 there are some new variables you can use to solve this,
http://ccmexec.com/2014/12/smstsmplistrequesttimeout-value-in-milliseconds/
In Sp1 though adding a step to sleep for 2-5 minuter after reboot and before the application install step is a common workaround.. a powershell command with "Start-Sleep
-s 120" should do it. 
/Jörgen
-- My System Center blog ccmexec.com -- Twitter
@ccmexec