Won't download OptiPlex 7010 drivers

[staze]

The OptiPlex 7010 drivers are a bit of a mess, and have MANY SKUs associated with them. That seems to be causing some issue with them downloading, which then causes DAT to fail to extract a non-existant .exe file.

[ceasley112]

We are seeing the same issue. The new 7010's are labeled incorrectly as well. Our standard model is the "7010 Micro Plus" as reported by WMI.

[staze]

The labelling issue is on Dell's side. They decided to externally call them all 7010's. =(

[ceasley112]

I just had a look through the .xml, and you are absolutely correct. I've complained to our Dell rep about it, and requested they fix up the .xml. I suspect it's the incorrect entries in the .xml leading to the large SKU string as well (at least I hope it is). We'll see where this ends up.

[scchram]

Getting the same result still on the Dell 7010's. Hey Maurice Daly.. any influence at Dell?

[staze]

we yelled at our Dell rep's team about this insanity. breaking the driver pack into three, etc. so far no real response. mentioned it had broken DAT.

Not sure what else to do. I've manually imported all three driver packs now, and can actually confirm the Tower pack seems to contain all the drivers for all three... so I don't know what the heck Dell is thinking on this. The 7010 as a whole has been a giant cluster (not putting the model number on the case!?)

[ceasley112]

we yelled at our Dell rep's team about this insanity. breaking the driver pack into three, etc. so far no real response. mentioned it had broken DAT.

Not sure what else to do. I've manually imported all three driver packs now, and can actually confirm the Tower pack seems to contain all the drivers for all three... so I don't know what the heck Dell is thinking on this. The 7010 as a whole has been a giant cluster (not putting the model number on the case!?)

We have done the same with our Dell rep, and they noted we are not the only customers to have provided this "feedback" :) Hopefully this gets sorted out soon. I'm using it as leverage to refuse to purchase any 7010's for the time being (I realize this isn't feasible for everyone).

[staze]

yeah, we have our seed unit arriving today so we can get imaging working. I'll note that someone already tried and the thumbdrive didn't see the internal drive due to needing to update the Intel RAID driver in WinPE.

Anywho, here's hoping Dell gets this fixed on their end.

[PowershellBacon]

Open DriverPackCatalog.xml and find "FOLDER09319941M/1/7010-DNNP6_Win10_1.0_A00.exe", a few lines down rename it from Optiplex 7010 to OptiPlex Micro 7010 on all 4 sku's then save it, relaunch DAT and you can download it. (adding this reply BEFORE i have fully tested imaging with it, but its in SCCM now). Also make sure you remove the SKU's from any other 7010 packages you have in SCCM.

Edit: Confirmed working, devices image and choose the correct package now.

[vartaxe]

does someone have a case number for dell?

[PowershellBacon]

does someone have a case number for dell?

I have no case number but I did email talk on the phone with them and show them the issue on 4/26. He was noticing an issue on their side as well with the integration suite for MECM. He said he was going to work with the engineers to see how they can fix the entries. You can manually fix the xml for the new 4 sku's for win10 and win11 entries and it will import just fine.

[staze]

I don't have one either. I just told our sales engineer it was broken and they tried to tell me how to get the driver manually. =/

I do note that their bios cab also seems to be missing some recent bios's as well. So kinda wondering if there's something up on that team...

[PowershellBacon]

Update: Just in case anyone else hasn't noticed this yet, there are 3 new SETS of 7010's, all are labled Optiple 7010. Each set has 4 different skus included, so 12 new machines all together, and each set has its own driver package.

When you want to download them, I suggest going into your DriverPackCatalog and finding their entries and giving each set their own name, don't name the skus different, just each set should have 1 name applied to all 4 skus. Then when you launch DAT you can download each one separately and it will be separate in MECM as well. Since the name/title of the package doesn't really matter you can name them whatever you want, below is an example. Remember each set is listed twice, 1 for each windows version, so windows 10 and windows 11 will have a set entry. I have found that windows 10 drivers work perfectly on windows 11 and do not both to download 11's.

0BCC/0BCD/0BCE/0BCF - Optiplex 7010 Release 85HR5 0BE3/0BE4/0BE5/0BE6 - Optiplex 7010 Release DNNP6 0BD0/0BD1/0BD2/0BD3 - Optiplex 7010 Release NPDX0

[PowershellBacon]

After talking with Dell they will not be fixing anything in the XML file to differentiate between the sets of 7010's. Here is a fix for the .ps1 file to automatically rename the 7010's based on release.

Open the DriverAutomationTool.ps1 file and go to line 14171 (# Read XML File), right below it, paste the following.

[xml]$xmledit = Get-Content -Path (Join-Path -Path $global:TempDirectory -ChildPath $DellXMLFile) -Raw
$7010Sku = New-Object -TypeName System.Collections.ArrayList
$7010Sku.AddRange(@(
    "0BCC"
    "0BCD"
    "0BCE"
    "0BCF"
    "0BE3"
    "0BE4"
    "0BE5"
    "0BE6"
    "0BD0"
    "0BD1"
    "0BD2"
    "0BD3"
))

foreach($driveredit in ($xmledit.driverpackmanifest.driverpackage | where {$_.SupportedSystems.Brand.Model.name -eq "Optiplex 7010"})){
    foreach($modeledit in $driveredit.SupportedSystems.Brand.Model){
        if($modeledit.systemID -in $7010Sku){
            $modeledit.name = "$($modeledit.name) ReleaseID $($driveredit.releaseID)"
        }
    }

}
$xmledit.Save((Join-Path -Path $global:TempDirectory -ChildPath $DellXMLFile))

Save it and now you can right click the ps1 file and run with powershell, this will use the edits to modify the xml file automatically creating separate entries in the GUI. They will be imported into SCCM with the same titles and will install based on SKU during OSD

[staze]

Awesome. Sad they're not going to fix this mess. Here's hoping the next model won't be this garbage... =/

[alayac]

Awesome. Sad they're not going to fix this mess. Here's hoping the next model won't be this garbage... =/

I don't think they'll change anything unless customers actually stop buying computers over this (doubtful). We're lucky to have this workaround and I see @PowershellBacon just submitted a PR to add it to the source. 👍

[staze]

I mean, they've already said they're going to add the number back to the badge (instead of it just saying "OptiPlex").

This all feels like Dell is trying to do an Apple...

We've definitely made our complaints known, and said it breaks tooling we have. I haven't even tried my script that will tell me if new driver updates are available... I'm sure it's going to either pitch a fit, or completely miss the 7010 drivers. =/

[jak552]

I'm hoping one of your fine gentlemen who have posted the workaround for this might be able to lend me your assistance with this.

I've edited the XML as suggested and now have the drivers showing up in SCCM. However, during the TS our step to dynamically apply drivers is failing. When I crack open the smstslog it shows error 9, when I crack open the applydriverpackage log it shows the correct systemsku (which also exist in the driver package) however it gives an error that the OS architecture or model doesn't match.

Below are the three relevant lines of the appydriverpackage log: Attempting to find a match for driver package: Drivers - Dell Optiplex 7010 Release DNNP6 - Windows 11 x64 (ITC03A92) Match found for computer model using detection method: SystemSKU and SKU value (0BE3) Driver package does not meet computer model, manufacturer and operating system and architecture criteria: Drivers - Dell Optiplex 7010 Release DNNP6 - Windows 11 x64 (ITC03A92)

Is anyone else running into this issue or has editing the XML been the only required step for other people?

[PowershellBacon]

I'm hoping one of your fine gentlemen who have posted the workaround for this might be able to lend me your assistance with this.

I've edited the XML as suggested and now have the drivers showing up in SCCM. However, during the TS our step to dynamically apply drivers is failing. When I crack open the smstslog it shows error 9, when I crack open the applydriverpackage log it shows the correct systemsku (which also exist in the driver package) however it gives an error that the OS architecture or model doesn't match.

Below are the three relevant lines of the appydriverpackage log: Attempting to find a match for driver package: Drivers - Dell Optiplex 7010 Release DNNP6 - Windows 11 x64 (ITC03A92) Match found for computer model using detection method: SystemSKU and SKU value (0BE3) Driver package does not meet computer model, manufacturer and operating system and architecture criteria: Drivers - Dell Optiplex 7010 Release DNNP6 - Windows 11 x64 (ITC03A92)

Is anyone else running into this issue or has editing the XML been the only required step for other people?

I haven't run into that issue, however my Win10 and Win11 TS all use the same command to install, I only look for windows 10 drivers and those seem to be working fine.

[jak552]

For some reason the W10 drivers do work for a W11 install, but the W11 drivers don't work for a W11 install. I think it's probably an issue with us still using an older script within our TS because we aren't ready to switch to the admin service yet.

One of the techs on my team is worried about a possible performance hit on the server hosting the admin service.

[PowershellBacon]

ohhh yeah thats probably the issue then, the admin service is not to hard to setup and def worth doing.

[jak552]

We have it setup and configured in our test environment, so we know it works here. We are also investigating getting away from doing a full imaging process. We would use the OS the vendor ships and layer, use a TS to get our tools on there, then layer additional things after boot. But that is a whole other story for a whole other time.

Thanks for the tip, that got me pointed in the right direction!

[ceasley112]

Just learned from our Dell rep the driver cab .xml has been updated. We've done some testing and found everything seems to work now, finally!

[staze]

hahahahah. enough of us must have complained that it was horribly broken.

Good job everyone! =)

[alayac]

Just learned from our Dell rep the driver cab .xml has been updated. We've done some testing and found everything seems to work now, finally!

This is very good news, but the names still don't match the Models as pulled from WMI.

My test device... Actual model name: OptiPlex Micro Plus 7010 Dell's updated XML: OptiPlex 7010 Micro

In your screenshot, you can see OptiPlex 7010 Micro still has multiple identifiers.

[PowershellBacon]

Dell's "fix" is ok, it doesnt really matter for those of use using Dell's, the script matches by SKU anyways. So they could have called it optiplex 1 thru 4 and it will still match. Each SKU is a different type of machine, there are 12 new skus, a set of 4 skus all use the same driver package.

[randhirsinggh]

Just learned from our Dell rep the driver cab .xml has been updated. We've done some testing and found everything seems to work now, finally!

Mine is still showing up same, do I need to do something for appropriate model name to showup?