Driver install fails during 1909 Upgrade Task Sequence in SCCM

[king-matthew-g]

1909 initially gets installed as 1903 when updating from 1809/1709. Then it applies an update after the Task Sequence has ended which changes it to 1909. The result is that running Modern Driver Management with 1909 drivers downloaded fails on the 1909 update claiming no drivers compatible with 1903 were found.

[NickolajA]

Are you using a Windows 10 version 1909 based media serviced with the latest quality update?

[vbateman]

I have had the same issue, the OS upgrade package for 1909 will show a build number of 18362, but if you have driver packages for 1909 or 1903 it will pick 1903. The enablement package inside 1909 does not get installed until later to flip the digit by 1 to 18363. As I can see your making a web service call to get the TSPackageID to get the build number, but that is always going to be 18362 even if its a 1909 OS Upgrade Image. Is their anyway to handle the build version between 1909 & 1903 in the script when doing a OS Upgrade

[NickolajA]

Yeah I just reviewed the scenario and I can confirm the issue. Further investigation is required, will get back to this issue when we know more.

[Belial2003]

The same thing described by vbateman happens with a bare metal scenario. The imported Windows 10 1909 Media show a OS Version of 10.0.18362.x which is recognized as 1903 by the script.

[vbateman]

Thanks Nickolaj

[NickolajA]

Just an assumption here, this is not a captured reference image, right? It's just an import of source files directly from the ISO?

[vbateman]

In my situation yes that is correct, just a import of the sources files.

[NickolajA]

I'm currently verifying that assumption. But let's say you'd use MDT to create a reference image, apply the Enablement Package and capture the image, the version would be 18363.xxx. I'm getting the same issue with just an import of the source files at least. I'm checking now if the Enablement Package can be offline serviced into install.wim (used for source file import)

[vbateman]

Yes i could see how it works properly on a MDT image as it would be captured, could we add another switch to use with the cmapplydriverpackage to handle this?

[Belial2003]

I used the standard iso from Microsoft, updated it through OSDBuilder. So no build and capture per se.

[NickolajA]

I'm more thinking down the line of not supporting source files only, unless they've been offline serviced with an Enablement Package when applicable, if the offline servicing tests I'm doing now increases the build number.

[king-matthew-g]

To confirm what's already been found, this was all done using the ISO provided in VLSC by Microsoft with no changes. Thank you for responding so quickly and investigating the issue.

[NickolajA]

Just had a chat with Maurice about this issue and we came up with two solutions. One requiring a change to the ConfigMgr WebService and the other to pass another parameter to the Invoke-CMApplyDriverPackage.ps1 script. We're currently working on the latter with an addition parameter that will override the logic where the web service is asking for OSImageVersion.

[vbateman]

Thanks for the update, very much appreciate the quick response on this.

[NickolajA]

Sorry for the delay, but version 2.2.7 has now been published with a fix for this. However it has not been verified. Could you please see if adding the -TargetOSVersion parameter with a value of e.g. "18363" works for you? It has to be the build number, not the "name" e.g. 1909.

[king-matthew-g]

Just to confirm, the parameter format would be '-URI "https://my.server.uri/ConfigMgrWebService/ConfigMgr.asmx" -SecretKey "pretend-this-is-a-valid-key" -Filter "Drivers" -DeploymentType "OSUpgrade" -TargetOSVersion "18363"'?

[NickolajA]

That should do the trick (I hope)

[king-matthew-g]

I'm guessing it'll be added once confirmed, but it may be nice to add an example of that use. Looking at the 2.2.7 raw, I don't see it in the example list.

Edited because I'm poor at sentence building.

[vbateman]

I'm seeing it in the 2.2.7 script "TargetOSVersion". I cant test as I'm not at work this week.

[vbateman]

Sorry, my bad - u meant an example of use..read your post wrong. I hope this works for us.

[king-matthew-g]

An 1809 Install OS task sequence that was working, calling Modern Driver Management with no -DeploymentType flag after OS install, is now failing due to empty InputObject per SMSTS.log. Final log from ApplyDriverPackage.log is "Attempting to detect OS Image data from task sequence...".

[king-matthew-g]

Shouldn't this be OSVersion = $OSBuild?

Based on logging, it has to be that else block, unsure why the catch block wouldn't have triggered though.

[NickolajA]

Yeah, made a copy/paste error there. Fix committed now.

[king-matthew-g]

Thanks so much for the quick replies and fixes!

[king-matthew-g]

It was actually a two-fer, line 464 in the right-hand history screen shot should be $OSImages.Version not $OSImage.Version. I missed it on first glance as well.

Even with that done though, $OSBuild is reporting as empty so the error is still occuring.

[king-matthew-g]

It's a hair late now, but now that I'm more familiar with the code, might be cleaner to go back to the 2.2.6 Version and do this to the Windows 10 area of # Get operating system name and from build number. Maybe throw in [ValidateSet("14393","15063","16299","17134","17763","18362","18363")] in the Parameter declaration to ensure proper entry?

Then you can add back in the parameters, script build number, added comments, and capitalizing System (old line 490, new line 523).

[NickolajA]

You're not wrong. But I added it there to keep most of the override code within the same function to keep the code cleaner and easier to read (you don't have to jump around in different functions etc).

[NickolajA]

Did the latest commit work btw?

[NickolajA]

I got some feedback from Microsoft when I contacted them, and with the new ADK preview a 1909 ISO shows up as 18363. So it seems that Microsoft are aware of the issue and fixing it. Hopefully, the fix implemented here should not be necessary in the future.

[king-matthew-g]

I had two image correctly using the amended 2.2.6 revision I was talking about, but it got too late and I had to take off so haven't gotten to test yet. I'll try real quick.

If you're interested, I attached that version. Invoke-CMApplyDriverPackage.txt

[king-matthew-g]

And looking at it, the new revision is still going to fail due to empty input object (at least if -TargetOS is not specified). Line 465 should be $OSBuild = $OSImages.Version as $OSImage would be null at that time.

[NickolajA]

You're correct. Missed that, thanks! Fixed now.

[king-matthew-g]

I'm seeing last commit 15 hours ago, from that commit I had changed it to be $OSImages and it was still failing with $OSBuild being null or whitespace when -TargetOS was empty. This was to image my test machines so I did not set the switch which I intended to do when upgrading them to 1909 from 1809.

[NickolajA]

Internet went down here at the customer site, so I was not able to publish the change... doh. It's there now.

[king-matthew-g]

Awesome, I'll start a test run when I'm getting ready to head out to lunch.

[king-matthew-g]

That appears to work! However, I noticed something odd that I can issue a different report for. We have 1909, 1809, and 1709 driver packages for our computers. The ApplyDriverPackage.log shows that all 3 were detected as possible matches (which makes sense based on this script block).

But it does not ever scrape away those versions that do not match properly. It only scrapes away packages where the Model does not match. It looks like the problem is in this bit.

The logic checks for bad model matches, and only then strips bad version matches. I assume since the original package check looks for manufacturer, this should be changed to looking for proper version and adjusting the log output to match.

The end result of this error is that it is defaulting to the newest created package, which is 1909 based on luck but could actually be lower versions with older drivers if we had just begun using Driver Automation Tool.

[NickolajA]

You're correct. I was looking at exactly this earlier today as it was reported in another issue. I believe the logic part needs to be re-written as it has evolved over so many versions now and it's hard to remember each change at this point.

[king-matthew-g]

I'll go submit my proposed fix in that one then! Thanks for the work!