Windows 10 Upgrades – Task Sequences – Issues and Fixes

I’ll try to keep this post updated as I continue to find problem, and link any new posts back to this one (and vice versa).

We’re part way into our 1809 push and we’ve found some problems (edge cases) which others might see.  Some issues are completely specific to us (or at least places who use the same 3rd party tools, like alternate content providers (of whom have worked to provide hot-fixes when issues have been brought to their attention), security, etc.. I will not be going into any of those on my Blog).

General Issues we’ve encountered:

1. ISSUE 1: Windows Path Variables
   1. Sub-ISSUE: Missing Critical Path Variables completely (Very Rare)
      1. This manifest itself very oddly during the upgrade, several steps failed because it couldn’t find the exe called. “path not found” when trying to call reg.exe or other exes that you’d expect wouldn’t require full path.
      2. Remediation… adding them back in. We also flag these for support teams to look into root cause as to why those critical paths were removed in the first place. Ones we watch for:
         1. C:\Windows
         2. C:\Windows\System32
         3. C:\Windows\System32\Wbem
         4. C:\Windows\System32\WindowsPowerShell\v1.0\
   2. Sub-ISSUE: Having PowerShell 32 bit in the Path before 64 bit causing all TS PowerShell processes to run in 32 bit mode. (Rare, but more common)
      1. This manifest itself during PowerShell Scripts when I tried to call the COM object, which is a 64bit COM object.  It would fail on command line steps that called powershell.exe in a way that referenced a COM Object (Setting a Variable)
      2. Root Cause: This is when C:\Windows\SysWOW64\WindowsPowerShell\v1.0 is in the Path before C:\Windows\System32\WindowsPowerShell\v1.0
      3. Temporary Remediation: Anytime you call PowerShell.exe, use the full path: %Windir%\System32\WindowsPowerShell\v1.0\Powershell.exe
         1. This doesn’t work for PowerShell Scripts, those still run in whatever the Path tells it to.  You’d need to change these to Run Command Line Steps, calling Powershell to call a Script.
      4. Long Term Solution, Make 64bit the default.. however since we didn’t know why 32bit was even in the path, we assume some other process needed it, and we are now flagging these to figure out why they are set to 32 bit.
   3. MONITOR:  We have a CI in our WaaS Pre-Assessment Baseline that checks for these.  I’ll be posting a Blog Post soon with the info for creating that CI (DONE)
2. ISSUE 2 – Random… I just wanted to say, Update the Upgrade Media with all of the updates available.  We’ve had apps that had issues after upgrade, but with each month’s patches some of those apps just start working.  Not going to call out any vendors here, but point is… Dynamic Updates, and Updated Media is a MUST.
3. ISSUE 3 – SETUPCOMPLETEPAUSE – After it upgrades to 1809, the TS doesn’t kick back in.  This was very random, but we found it happen a lot more on old hardware and on VDI. 
   Failed to initate policy evaluation for namespace ‘root\ccm\policy\machine’, hr=0x80041010 Error compiling client config policies. code 80041010 Task Sequence Manager could not initialize Task Sequence Environment. code 80041010
   In 1910 a new variable was created that adds a pause to the setupcomplete.cmd which triggers DURING the 1809 upgrade after the last reboot, but before the TS kicks back in and the upgrade is officially finished.  At this point, if you have slow hardware or very bloated WMI, there is a chance that the TS tries to kick in and WMI isn’t ready yet, and you’ll see that error.  At first we added a 60 second timeout, and it seems like that helped a bit, we finally landed on 180 seconds as default, and 300 seconds for VDI.  We found that even on our VDI, 180 wasn’t enough.  For more info about this Variable, check out the docs.