Like many others organizations, mine is in the process of deploying Windows 10. Any new machine is now Windows 10, and we are now taking requests for users who want to do an in-place upgrade from 7 to 10. We are a small organization in comparison to most, so considering we do not use SCCM due to the cost, we needed to use another tool to do an in-place upgrade. For this reason, I created a PowerShell function that could perform multiple, remote, in-place upgrades to our AD-joined workstations using MDT. It does a great job, in fact I wrote an article about it, so if you are inclined to use it, grab it on Github.

This week as I went to upgrade a workstation, it bombed. Of course it threw a couple of errors in the MDT results screen, none of which I was familiar with.

A look at the C:\Windows\temp\deploymentlogs\results.xml file had this:

Thus it began. My journey directly into the dark abyss that is Windows 10 in-place upgrade troubleshooting hell…

I knew it wasn’t old hardware because its an HP 800 G1. OK, so before I go deep diving into logs I tried a few things from this article:

  • Checked for external hardware connected – Didn’t fix it.
  • Did a chkdsk – Nope.
  • Ran sfc /scannow (which in my experience has never resolved any issue ever) – Nope.
  • Checked Windows updates were up to date – Yep they were.
  • Uninstall Vipre Anti-virus – OK did that and made no difference.
  • Verify 16 GB of free space on Windows partition – Yep but no.
  • Updated drivers and firmware – Nope that wasn’t it either.

Then, I realized something. I had a GPO set to block Windows upgrades on Windows 7 machines, you know since Microsoft was trying to force everyone to upgrade for their own enjoyment. That must be it! It makes so much sense! Although I had been able to upgrade other machines with this same policy, maybe the Gods would throw me an bone. Nope, na-na nope nope. Still failed during upgrade.

So I googled around looking for some hints based on these codes and unfortunately did not find anything satisfying (God, I sound like the typical Windows Sysadmin idiot right?). Next, I took to a mailing list I use for MDT that has some great experts in that area. One of them, who was a Microsoft rep, told me to look at logs located at at C:\Windows\Panther\NewOS\Panther. I took a look at setupact.log and setuperr.log but it might as well have been written in Chinese as there was nothing that made sense in it to me. Then, I stumbled upon this little beauty – an XML file called “ScanResult” which appears to be a compatibility scan prior to upgrading. It showed:

Ah ha! Take a look towards the bottom of this file:

<HardwareItem HardwareType=”Setup_InsufficientSystemPartitionDiskSpace” ActualValue1=”15“> <CompatibilityInfo BlockingType=”Hard” /> <Action Name=”Setup_InsufficientSystemPartitionDiskSpace” ResolveState=”Hard” /> </HardwareItem>

There it is. The culprit. The system reserved partition does not have enough space for the upgrade. You may be asking “Why the hell is the system partition only 15MB?” Well, I do not know why that is exactly, but it probably has something to do with the fact we used to use the dreaded Norton Ghost to push out images before we started using MDT, I know MDT is configured to create the partition correctly.

OK, so now I know what the issue is, but how do I fix it? Diskpart? Uhh no. Diskpart does not allow you to shrink the Windows partition and then increase the system reserved partition. Not to mention if it does, I don’t trust it or myself not to brick the system using it. So, I googled around again and found this third-party tool called Partition Manager. A nice little tool to resize partitions in Windows.

So I logged on to the workstation and installed it via Chocolatey:

Now in Partition Manager, I decreased the size of the Windows partition by about 400 MB just to be safe, and then increased the system reserved partition by that same amount. Hit “Apply”, and rebooted so the software can do it’s magic. Next, tried to perform an in-place upgrade again and BAM, issue resolved. Upgrade successful.

Leave a Reply

Your email address will not be published. Required fields are marked *

Related Posts


Restart multiple computers with the PowerShell PCSVDevice module

To restart multiple computers with PowerShell and without relying on functionality of the remote operating system, you can use the PCSVDevice module. The module contains several useful cmdlets for out-of-band management and supports the IPMI Read more…


Remotely migrate user data with USMT and PowerShell

USMT has been a staple for system administrators for years and has greatly reduced the time to migrate data between computers. USMT has the ability to migrate user files, OS settings, and application settings. It Read more…


Deploy VMware VMs with PowerCLI and MDT

If you are managing Windows servers, chances are you have a mix of physical and virtual servers in your data center. While VMware provides a method to create VMs from templates to simplify server deployments, Read more…