Upgrade Failure: Windows 10 10049 Using SCCM 2012 R2
I’ve been working on integrating Windows 10 into our environment and ran across a couple of issues learning opportunities while doing so.
Upgrading from 9926 to 10049
First off I hit a snag attempting to upgrade my test machines from build 9926 to build 10049. The SCCM Team published a blog article back in October of last year on how to use a task sequence to upgrade a client to Windows 10. You can find the article here. A couple of weeks ago I had the opportunity to work with Paul Winstanley (SCCMentor and WMUG author) on a live blog he was writing on upgrading from one build to another using this method. In the lab environment it worked wonderfully, but when I tried it outside of the lab it failed every time in my environment.
Now, your first question might be along the lines of, “Why are you upgrading builds like that?” That is a good question. I cannot use Windows Update to upgrade my machines as new builds come out because the company I work for uses a combination of Group Policy and SCCM client policies to block access to WU and use WSUS/SCCM as the source for all of our updates. So I have to upgrade builds outside of the native process, hence using the task sequence in SCCM to perform the upgrade.
Back to the failure I was experiencing. The upgrade process would go smoothly at first. The system would run setup and reboot into “mini setup” for Windows 10. It would be here that the train would come off of the track. It would reach 100% complete and then just sit there, apparently hung.
If everything is complete what was causing it to hang? At the completion of setup Windows will look for a script file called SetupComplete.cmd and if found execute it, nothing new there. In the case of this upgrade task sequence that CMD file calls a PowerShell script whose primary purpose is to repair the SCCM client. (Keep that in mind.) See, the SCCM client doesn’t like having the operating system ripped out from underneath it. Go figure! 🙂 Opening a command prompt I could see that the PowerShell command was still running but not doing anything. If I killed the PowerShell process “mini setup” would complete but the SCCM client would be busted.
Well after much searching I found the source of the problem. Jerry Abouelnasr pointed me in the right direction in the Windows 10 forums. To make a long story short the problem was rooted in how we have been installing the SCCM client in our builds. We include client-side patches and use a very common method for installing them. We copy them to a temp folder on the local system and use the PATCH=… parameter in the client install action to point the installer to the updates.
Remember that PowerShell script that I said was there to handle the repair of the SCCM client? It was attempting to repair the client but since we had installed the client using updates found in a temp folder the repair could not find them. The client repair would hang since it could not find all of the required files.
How do you get around this?
- You could re-deploy the SCCM client and use permanent file locations for the PATCH parameter
- (I haven’t tried this yet) You may be able to edit the MobileClient.TCF file and re-point the Install line to a location that had the client patches
Install=INSTALL=ALL PATCH=C:\Windows\temp\SCCMHotfix\configmgr2012ac-r2-kb2994331.msp;C:\Windows\temp\SCCMHotfix\configmgr2012ac-r2-kb3007095.msp SMSPROVISIONINGMODE=1 SMSSITECODE=AA1
I’ll have to give this second option a try. Could be a shot in the dark but worth a try.
Posted on April 15, 2015, in Configuration Manager, SCCM, Windows 10 and tagged Configuration Manager 2012, SCCM, System Center Configuration Manager, Windows 10. Bookmark the permalink. Leave a comment.