Introduction

Sooner or later you will encounter some Compatibility Scan errors with your Windows 10 upgrades.

And if you like me run the Compat Scan prior to the actual Windows 10 upgrade, you will have time to fix these errors before the end-user is aware. Clever, right? 😀

So this post is an example of such and is based on a really simple approach to fixing an incompatible driver. Curious? Read on 🙂

Compat ScanOnly

First things first and as mentioned. All of this is based on precaching and running compatibility scan prior to the actual upgrade.

In short, this is done with a task sequence similar to below and is something I have covered in details here: https://www.imab.dk/windows-as-a-service-sharing-my-precache-and-in-place-upgrade-task-sequences-part-1/

What this essentially does, is running the setup.exe with a /Compat ScanOnly parameter. Hence no actual upgrade, but a validation of the process. Greatness.

CompatData.xml

So how do I know if something is incompatible? Logs and CompatData.xml to the rescue.

Again, I have covered my precaching task sequence in details previously here: https://www.imab.dk/windows-as-a-service-sharing-my-precache-and-in-place-upgrade-task-sequences-part-1/

In below illustration, I’m making sure to copy out the relevant log and .xml files. This is very useful when needing to troubleshoot any issues related to upgrading Windows 10.

When taking a peek at the CompatData*.xml, the blocking type and reason is mentioned. In this scenario, the intcdaud.sys driver is incompatible.

Note: The reason for the compat scan failure is also mentioned in the smsts.log and is referenced with a hexadecimal value. More info here: https://docs.microsoft.com/en-us/windows/deployment/upgrade/upgrade-error-codes#result-codes

Fixing the Issue

Now knowing that some devices have driver compatibility issues, it would be a decent idea to fix them before letting the users into upgrading Windows.

All of my WaaS setup prevents the actual upgrade from being offered to any device that failed the compatibility scan, so this is something that needs manual attention.

When a device fails either of the checks, it automatically becomes a member of new collection(s). See below illustration.

This is based on custom inventory (also covered previously) and with that in hand, you are quickly able to create additional collections and/or queries.

With that information available, I know exactly which device that failed the compat scan and what specific model this is.

Note: The specific model is important in this case, seeing it’s a driver related issue and a driver often is unique for the specific model.

pnputil.exe

Now that we know the ups and downs, it’s time to do something about it. As we know, in my scenario, this was caused by an incompatible driver.

So the first step is obviously to find an updated driver and test if this works with the particular model and version of Windows 10.

Once all of that is confirmed, it’s time to update the driver on the existing devices.

For this I’m leveraging pnputil.exe with a batch file:

@ECHO OFF
IF NOT "%PROCESSOR_ARCHITEW6432%"=="AMD64" GOTO native
  %SystemRoot%\Sysnative\cmd.exe /c %0 %*
  EXIT
:native
pnputil.exe /add-driver "%~dp0intcdaud.inf" /install

I’m running this with a package/program with SCCM (System Center Configuration Manager), and we all know that a package runs as a 32-bit process on a 64-bit OS.

Therefore we have to trick the script into being launched from the sysnative folder, as pnputil.exe is not available when coming from a 32-bit process on a 64-bit OS.

Complicated much? Just copy/paste above if you want to run pnputil.exe with a package on a 64-bit OS 🙂

The content of the package in my example looks like below:

And the program running pnputil.bat looks like below:

Result

Eventually as the devices gets their driver updated, the compat scan is being rerun on a schedule. This is done only for the devices which failed the compat scan initially. Neat!

This is the collection, which is having a separate compat scan deployed:

Running the task sequence on a daily basis. What I really want here, is that the collection membership count is 0 and thus running this so aggressively shouldn’t be a problem.

For your convenience, below is an illustration of the separate compat scan task sequence.

The devices which failed the compat scan, only needs the actual compat scan. Therefore I have separated that part from the original PreCaching Task Sequence.

Let me know in the comment section down below if you have any questions.

ENJOY 🙂