Win7 -> Win10 1809 upgrades failing using SCCM

Another one just got to 84%, and BSOD with a "CRITICAL PROCESS DIED" error.  

Thankful that alcohol is not available on-site right now.  :)

Upgrading Windows 7 at this late date to Windows 10 may have issues Any machine new in the last 2 even 3 years is already Windows 10, so these Windows 7 machines are getting ancient.

Get the Vendor Driver updates (including BIOS and Chipset) for the Windows 7 machines, remove legacy software (old Office, Adobe, and other old software (especially Anti Virus and VPN) for which new revised versions are available)

I'm importing the latest drivers from Dell into a SCCM package and using those for both models according to Johan's example.  

BIOS is current, and I've tried it without AV (we use Cylance).  

I've had our vanilla bare-metal images upgrade in test perfectly, no problems, and those had Office 2013.

I added the log from the 2nd failed machine into my post.  84% seems to be the consistent factor, and in the last phase of deployment.  You'd think most failures of consequence would come earlier in the process.

There are Dell machines that are not compliant with Windows 10 beyond about V1703 so you may wish to check this as well

Also, take one of the machines in question, format it and install Windows 10 fresh.  Does that work better?

Dell fully supports Windows 10 on both of our production models.  We can do bare-metal installs of Windows 10, and in-place upgrades on a machine built from our Windows 7 image, with no problems.  So, I don't see compatibility as a possibility.

I've also ensured BIOS is current.

Thanks for the update.  Also make sure all software is current.

It is.

Any other suggestions, John or anyone?  i was hoping the logs would reveal something that i didn't catch.

Whats the result when you upgrade without the DELL driver package for WIndows 10?

I've never tried it.  I'll do that now.

Same thing...bombs at the same point and rolls back.

Hi,

I need to swap machines to use CMtrace and  look at the log properly. However there are a couple of things to try.
Step 1 is just simplify. If you have a full task-sequence, make a copy then and remove everything except the OS and drivers - so no apps, no updates.
Step 2 - disable just the Windows update step in the TS

The answer (or a clue) WILL be there in the logs but you might need more detail. The default logging level is medium. You can set a variable to max it out. If you do that you need to increase the log size too. Add
CCMLOGMAXSIZE=5242880 CCMLOGLEVEL=0 CCMLOGMAXHISTORY=3 to your Setup Windows and ConfigMgr step.

If it is update related then look at creating a smaller Software Update Group for deployment, or better, use DISM to update the WIM. This just takes the impact of adding new updates to the fresh OS in real-time.

I will look at the log later but those 2 steps are good practise anyway. I generally do 3 phases of build - OS only with drivers, OS + apps and only when that works do I bother with updates. OSD is slow enough already without waiting for updates to apply.

Mike

Thanks Mike!  Where exactly in the TS would the CCMLOGMAXSIZE be added?  I just want to be sure I understand.

Hi - in the step where you install the CM agent "Setup Windows and ConfigMgr". This is where you specify the install properties like Site code, MP and FSP. Just add all the variables in uppercase as above. It is case specific for once.

Just reading the log:

step 132
Failed to run the action: Register Pathfinderinterface.DLL (CL 1.4.2 07 path).
Access is denied. (Error: 00000005; Source: Windows)

I've never seen that before given it is running as System.

Certificate [Thumbprint 84...6EED] issued to 'DPT...' has expired.

I'm not sure if that's a red herring or not. Doesn't sound good. I am guessing it falls back to HTTP instead as downloads then continue after this.


A couple of thoughts:

have you updated WinPE boot images?

have you updated ADK to appropriate version

are you using MDT integrated? (Doesn't look like it).


What seems to be happening is that the Apply OS step finishes and the machine reboots and can't find the key in the registry to resume the TS so it fails there. There's an 18 minute delay between fail and ending (16:30 - 16:48) with the "GetTsRegValue() is unsuccessful. 0x80070002."

Do you know what it does at that error code? Enable F8 will help to poke around whilst the TS is running.

Finally, given this happens after the Windows Update screen have you looked at the WindowsUpdate.log to see if there's any updates listed in there it is choking on? Worth a look.

Mike

Mike, thanks for the detailed answer.  

I'm doing an in-place upgrade, so I don't have a CM install command.  We install the CM client automatically via GPO with Jason Sandy's startup script.  Can I set that on a system in advance, perhaps, and then run my upgrade?

The Pathfinder DLL is a reoccurring push that we don't need anymore.  I'd ignored that, and others like it, just because I didn't think they'd have an effect.  We do need to clean that up and perhaps others like it - I'll do that now.

Not even sure how to track down that cert error or how we're deploying it, GPO maybe.  I'll check into it.  Do you think it's causing our failure?

Boot images/ADK:  Since we're doing in-place upgrades, I haven't worried about boot images too much.  The only thing (this is related to your ADK question) is that I realized I'd messed up the ADK/ADK WinPE upgrades, and had the wrong versions installed.  I removed what I have, then installed ADK 1809 and ADK WinPE 1809.  I then reloaded the proper boot images from ADK, and tried my task sequences again.  Same failures.  Was there an additional step after I updated all that to make the TS reflect the updates?

Not using MDT integrated.  I'm trying to keep things really simple right now until I get my problem fixed.  I don't use SCCM for OSD very much.

I will run another one and wait for the 75% (where I think the failure process starts, b/c 18 minutes sounds about right) mark and then dig around.

Again, thank you for your help (!).

I'm not installing any Windows updates purposely, unless maybe a task is kicking off.  Something that is interesting is, I can build a new Windows 7 machine from MDT, patch it completely, and then run an In-Place Upgrade task sequence and it works perfectly.  It's only when I do existing ones is when it breaks.

Hi,

In reverse order:
That's interesting and a clue - it maybe that you need an extra patch up front before doing the upgrade. Maybe try build a W7, do NOT patch it, but run the upgrade and see if it hangs the same. That would prove patches are the culprit but then you need to figure out which one!

Testing during the TS is often vital when doing SCCM deployments so I leave F8 enabled until 100% happy. OSD can fail in many, many ways!

Not having MDT is fine for now. It really does help massively when you get into task-sequences more.
Boot images - getting the right version is vital. It is a common oversight. Once you have re-generated them boot WIM files the only thing you need to do is point the TS at them. The other error people make is only building one boot WIM. SCCM needs both x32 and x64 or PXE will fail. As you are doing in-place upgrades that won't matter yet. Just warning you :). Obviously you only need to put drivers in one boot WIM though. The other can be left native.

The cert error is not causing this issue that I can tell but is definitely something to get fixed.
PAthfinder doesn't matter for your problem - I just saw it in passing.

With regards the client, I see what you mean. Yes, you can uninstall the CM client from a machine so it's clean, reinstall from the command line, using the parameters and that will set the new logging behaviour. Or tweak the registry.

I just found some PowerShell in my OneNote to do that:

Set-ItemProperty -Path Registry::HKLM\SOFTWARE\Microsoft\CCM\Logging\@GLOBAL -name LogLevel -value 0 -ErrorAction SilentlyContinue
Set-ItemProperty -Path Registry::HKLM\SOFTWARE\Microsoft\CCM\Logging\@GLOBAL -name LogMaxHistory -value 2 -ErrorAction SilentlyContinue
New-Item -Path Registry::HKLM\SOFTWARE\Microsoft\CCM\Logging -Name DebugLogging –Force -ErrorAction SilentlyContinue
In my remediation script, I am changing the value of LogLevel and LogMaxHistory, then creating the DebugLogging Key. In order to avoid logs rolling over in production, I recommend changing the value of LogMaxSize as well.

from https://blogs.technet.microsoft.com/systemcenterpfe/2015/04/10/configmgr-debug-logging-the-easy-way-using-system-center-configuration-manager-compliance-settings/

Mike, thanks for the suggestions.  I'll figure out how to implement F8 in my task sequence.  I'll also set the logging behavior for an existing CM agent (first) and see if that gives me more output.  

I did regenerate the boot WIMs but did not import drivers into them as I didn't think I needed them for an in-place upgrade.  Should I do that?  I would think I'd have failures earlier if that were my problem.

I actually ran my upgrade package manually and got this.  This fits what I've seen in my TSes, minus the dialog.

Hi,

It could be update related after all - this is the exact same error.

https://jdr244.wordpress.com/2016/10/07/windows-10-in-place-upgrade-via-sccm-stuck-on-75/

Check your Wuahandler.log too.

Also look at the upgrade logs
$Windows.~BT\sources\Panther
$Windows.~BT\sources\Rollback

There also seems to be a strong trend of needing to uninstall AV. I would scour the logs first.
Boot WIM drivers are not key here. The annoying thing is to enable F8 you change the properties on the "Customisation" tab of your WIM (tick "Enable command support (testing only)") and it then triggers a whole re-generation. It's not the fastest thing to do.


Mike

The Wsus pool was started, so no.  But it sure sounded good.  :)  

I've uninstalled AV as a troubleshooting step earlier (Cylance) in my efforts, and no difference.  Also, Cylance is in place when I do upgrades from newly-imaged Windows 7 machines, and it works fine there.  

Working on the F8.

Figured out my problem.  Actually, the engineer I was working with from Microsoft mentioned this as a trouble spot, and he was correct.

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Ole]
"MachineLaunchRestriction"

This sets the computer-wide restriction policy for component launch and activation.  This value can get abnormally large, and at the point in the setup process where the value is read, DCOM crashes.  

Once I deleted this, everything went through like butter.  Added that step as an initial step in my task sequence, and it's a problem no more!
 I'm adding some bells and whistles to my TS now, but the core stuff is going great.

Thanks for the assistance everyone.  (and Dhamodaran and KC, if you're reading this - thanks a TON!!!  Drinks are on me if we ever bump into each other at a conference)

Well that's definitely a new one on me. Never come across this, but glad you fixed it.

Me too.  Appreciate the helpful advice and pointers Mike and everyone.