Windows 10 Pre-Upgrade Validation using SETUP.EXE
For those looking planning to do in-place upgrades to migrate from Windows 7, Windows 8, or Windows 8.1 to Windows 10 using System Center Configuration Manager task sequences (described here), you might be interested in doing a “trial run” with existing systems to identify machines that may have issues. To support this, SETUP.EXE includes a command line switch that tells it to “check for compatibility” but not actually perform the upgrade. The full command line would typically look something like this:
SETUP.EXE /Auto Upgrade /Quiet /NoReboot /DynamicUpdate Disable /Compat ScanOnly
It’s that last part, highlighted above, that does the trick. (You may or may not want to specify /DynamicUpdate Disable. Disabling it causes SETUP to not download the latest compatibility information from Windows Update, but it would be better if you could do this. That gets more interesting in ConfigMgr, but that’s a longer discussion.)
When you run this ScanOnly execution, the results are returned via return codes from SETUP.EXE itself. Here are the possible values:
- No issues found: 0xC1900210
- Compatibility issues found (hard block): 0xC1900208
- Migration choice (auto upgrade) not available (probably the wrong SKU or architecture)· 0xC1900204
- Does not meet system requirements for Windows 10: 0xC1900200
- Insufficient free disk space: 0xC190020E
(You’ll see these return codes as large negative numbers, but they are much easier to look at in hex.)
So all you have to do is deploy a simple ConfigMgr package or task sequence to all your devices, with the full Windows 10 source media. It’s probably not a good idea to use download and execute or download on demand with ConfigMgr in this case – make sure you run SETUP.EXE from the network. It’s rather unproductive to download the INSTALL.WIM when you aren’t actually going to use it. But it does have to be there, SETUP.EXE will complain if it isn’t.
Once you’ve run this, you can create a report that shows the devices with each of the statuses. The first obviously requires no further action, and the last has an obvious course of action (try to free up some more space). But for the others you’ll probably want to review the SETUPACT.LOG or SETUPERR.LOG generated by SETUP.EXE to see what the specific error was.