MSEndpointMgr / ConfigMgr

Microsoft Endpoint Configuration Manager scripts and tools
629 stars 282 forks source link

Invoke-CMApplyDriverPackage.ps1 3.0.4 - Incorrect Target OS Build Version for 1909 #226

Open Wraith4260 opened 4 years ago

Wraith4260 commented 4 years ago

Matching during the ConfigMgr WebService phase fails to properly detect Windows 10 1909 mistaking it for 1903 thus causing it to not match any driver packages (we are skipping 1903). I am deploying 10.0.18363.778 based off the current 1909.3 .ISO in VLSC (serviced with WIM Witch up to 2020-04 patch level) but for some reason it thinks it is 10.0.18362.778.

See below for an example from ApplyDriverPackage.log:

image

Winver: image

However, even in SCCM the .WIM says 18362.778 despite being an 18363 build from VLSC. image image

Additionally, I found some resources that may explain this behavior -- sort of? In this article under Versioning, "Because of the common baseline, even after installing Windows 10, version 1909, individual system file versions will still appear as 18362." I found that information here.

I'm wondering if this matching method is problematic for 1903/1909 based builds and needs to be modified to query some other data set within the operating system. Has anyone else run into this on 1903/1909?

For what its worth I was able to workaround this by setting the TargetOSVersion parameter to '18363'.

dsolodow commented 4 years ago

I've run into this as well. It's because of the version property on the WIM, so probably would have to find some other way to detect it. I know WIMWitch had similar issues.

NickolajA commented 4 years ago

We introduced a fix for this a couple of versions back, so simply add the following to your 1909 TS step parameters for Modern Driver Management:

-TargetOSVersion "18363"

This will override the version returned from the web service and force it to match with 1909 that's kept in a static table within the script.

azulol commented 4 years ago

Hey i got the same problem. with the parameter -TargetOSVersion "18363" nothing changed. In which order do i have to put this in line? i got this: -URI "http://www.blablar.asmx" -SecretKey "12345" -Filter "Drivers" -TargetOSVersion "18363"

dsolodow commented 4 years ago

I don't have the quotes around the number of -TargetOSVersion but since it's a string I wouldn't think it would matter.

One thing I did find is that if you mount & then dismount with commit the WIM on a machine running a 19600+ build of Windows 10, it corrects the OSVersion property of the WIM

NickolajA commented 4 years ago

Yeah this issue is not there if you service a WIM of version 1909 with ADK 2004 that's about to be released soon.

NickolajA commented 4 years ago

Hey i got the same problem.

with the parameter -TargetOSVersion "18363" nothing changed.

In which order do i have to put this in line?

i got this: -URI "http://www.blablar.asmx" -SecretKey "12345" -Filter "Drivers" -TargetOSVersion "18363"

Did you update to use he latest version of the script? It's been running well here. What's in your ApplyDriverPackage.log?

azulol commented 4 years ago

Yes i have the latest script version 3.0.4 and thats in the log.

EDIT: i did it now without the quotes in 18363 and it worked! Thank You dsolodow!

phillipwp1 commented 4 years ago

Hi. I noticed the same issue at a customer today that recently started buying HP laptops. They normally use only Dells. I added the TargetOSVersion switch. Will let you know how it goes. That switch should not affect Dell right? As dell only has 3 detection checks compared to HP which has 4? EDIT: All good for me now as well. Adding TargetOSVersion variable without the quotes is working for me.