Will not download microsoft/lenovo drivers I am on 7.2.2

[acpowell]

I cannot get any Microsoft or Lenovo drivers to download. The log file is nothing but:

BitTransfer: Job state is "Error Error Error Error Error Error"
BitsTransfer: Checking BITS background job
as far as the eye can see. it also locks up the program. I have let it sit for 5-10 minutes and it never changes.

I did post this here but I think that isn't monitored often: MSEndpointMgr/ModernDriverManagement#246

[RandomTask93111]

I am also having this issue. Unable to download Surface Drivers and I get the same messages "error error" - program freezes and I have to shut it down in Task Manager.

[67dbc]

This is a major setback for us as well. Back to old school downloads for now. 👎

[acpowell]

This is a major setback for us as well. Back to old school downloads for now. 👎

If you were using the standard package option, what I have been doing in the meantime is just doing all the things the DAT does only doing them manually. It works well although takes WAY more time.

[ajn142attamu]

Hey, I think my fork might fix the Surface driver issue, we don’t have any Lenovos. I haven’t figured out compiling the .exe or .msi like the repo owner, so you have to run the .ps1 directly from an Admin Powershell window.

https://github.com/ajn142attamu/DriverAutomationTool/blob/master/Current%20Branch/7.2.2/DriverAutomationTool.ps1

Let me know if that helps and I can see about putting in a PR.

[jordanbueno]

Can confirm experiencing this issue on multiple machines in 2 different environments as well. I think @ajn142attamu is correct, the author needs to update XML containing the download links.

@acpowell how are you separating your models and SKUs for the surfaces so that the invoke script knows which to call upon in config mgr?

[ajn142attamu]

We also ran into some of the BITS issues earlier, based on #450 it seems the tool may not handle having multiple BITS sessions open concurrently very well.

[ajn142attamu]

Can confirm experiencing this issue on multiple machines in 2 different environments as well. I think @ajn142attamu is correct, the author needs to update XML containing the download links.

@acpowell how are you separating your models and SKUs for the surfaces so that the invoke script knows which to call upon in config mgr?

Technically I'd say he doesn't have to change the OEMLinks.XML file, but the with the last release being ~5 months ago, the update catalog hosted within the repo https://github.com/maurice-daly/DriverAutomationTool/blob/master/Data/OSDCatalogMicrosoftDriverPack.json is pretty dated. I figured out from the log what tool (https://github.com/OSDeploy/OSD/tree/master) he was using to generate that file, and found the OSDeploy team were routinely committing the same catalog to their repo. Easier to leverage theirs than try to create my own.

[acpowell]

Can confirm experiencing this issue on multiple machines in 2 different environments as well. I think @ajn142attamu is correct, the author needs to update XML containing the download links.

@acpowell how are you separating your models and SKUs for the surfaces so that the invoke script knows which to call upon in config mgr?

Each driver pack that I have in my OSD TS uses a WMI query based on the model number hard-coded into the BIOS/UEFI to determine if a machine gets that driver pack. Similar to what this site shows: https://www.anoopcnair.com/apply-driver-package-step-to-sccm-task-sequence/

When I get to the office Monday I can go into more detail if you need.

[67dbc]

Hey, I think my fork might fix the Surface driver issue, we don’t have any Lenovos. I haven’t figured out compiling the .exe or .msi like the repo owner, so you have to run the .ps1 directly from an Admin Powershell window.

https://github.com/ajn142attamu/DriverAutomationTool/blob/master/Current%20Branch/7.2.2/DriverAutomationTool.ps1

Let me know if that helps and I can see about putting in a PR.

So if I understand correctly, the tool for me is installed on the MECM server. I am elevating PS, then change direcory where I have it and hit enter? No switches or is the PS script a GUI outside of this tool or what is expected? Does it need to be in the Driver Tool folder somewhere? Looking for the breakdown if any.

[67dbc]

Hey, I think my fork might fix the Surface driver issue, we don’t have any Lenovos. I haven’t figured out compiling the .exe or .msi like the repo owner, so you have to run the .ps1 directly from an Admin Powershell window.
https://github.com/ajn142attamu/DriverAutomationTool/blob/master/Current%20Branch/7.2.2/DriverAutomationTool.ps1
Let me know if that helps and I can see about putting in a PR.

So if I understand correctly, the tool for me is installed on the MECM server. I am elevating PS, then change direcory where I have it and hit enter? No switches or is the PS script a GUI outside of this tool or what is expected? Does it need to be in the Driver Tool folder somewhere? Looking for the breakdown if any.

Never mind, figured it out but I'm still getting errors with use of PS workaround.

[ajn142attamu]

Hey, I think my fork might fix the Surface driver issue, we don’t have any Lenovos. I haven’t figured out compiling the .exe or .msi like the repo owner, so you have to run the .ps1 directly from an Admin Powershell window.
https://github.com/ajn142attamu/DriverAutomationTool/blob/master/Current%20Branch/7.2.2/DriverAutomationTool.ps1
Let me know if that helps and I can see about putting in a PR.

So if I understand correctly, the tool for me is installed on the MECM server. I am elevating PS, then change direcory where I have it and hit enter? No switches or is the PS script a GUI outside of this tool or what is expected? Does it need to be in the Driver Tool folder somewhere? Looking for the breakdown if any.

Nevermind, figured it out but I'm still getting errors with use of PS.

So, we ran into this, and one thing that may be at play is there's a local copy of the OEMLinks.XML file cached in the Settings folder. If you moved the .ps1 to the same directory as the installed EXE, it's likely picking up the local file originally pulled from this repo, rather than my fork. You can confirm by comparing the local OEMLinks.xml file on your computer to the one here in my fork https://raw.githubusercontent.com/ajn142attamu/DriverAutomationTool/master/Data/OEMLinks.xml

Also, there's some discussion of the BITS errors in #450, I'd try downloading just a single file at a time after you remove the errored BITS transfers.

[67dbc]

Uninstalled the application completely, removed all folders/files, re-installed it and kicked off the updated script again and seems to be working. Feel like it was grabbing the old data points and content presenting the same errors, so start fresh!

Hey, I think my fork might fix the Surface driver issue, we don’t have any Lenovos. I haven’t figured out compiling the .exe or .msi like the repo owner, so you have to run the .ps1 directly from an Admin Powershell window.
https://github.com/ajn142attamu/DriverAutomationTool/blob/master/Current%20Branch/7.2.2/DriverAutomationTool.ps1
Let me know if that helps and I can see about putting in a PR.

So if I understand correctly, the tool for me is installed on the MECM server. I am elevating PS, then change direcory where I have it and hit enter? No switches or is the PS script a GUI outside of this tool or what is expected? Does it need to be in the Driver Tool folder somewhere? Looking for the breakdown if any.

Nevermind, figured it out but I'm still getting errors with use of PS.

So, we ran into this, and one thing that may be at play is there's a local copy of the OEMLinks.XML file cached in the Settings folder. If you moved the .ps1 to the same directory as the installed EXE, it's likely picking up the local file originally pulled from this repo, rather than my fork. You can confirm by comparing the local OEMLinks.xml file on your computer to the one here in my fork https://raw.githubusercontent.com/ajn142attamu/DriverAutomationTool/master/Data/OEMLinks.xml

Also, there's some discussion of the BITS errors in #450, I'd try downloading just a single file at a time after you remove the errored BITS transfers.

That was my issue. I uninstalled, removed all folders, re-installed it, re-ran the script and worked. There is one selection under Surface Laptop 4 that keeps doing this and haven't figured it out.

[Latiron]

Uninstalled the application completely, removed all folders/files, re-installed it and kicked off the updated script again and seems to be working. Feel like it was grabbing old data points content presenting the same errors so start fresh!

Hey, I think my fork might fix the Surface driver issue, we don’t have any Lenovos. I haven’t figured out compiling the .exe or .msi like the repo owner, so you have to run the .ps1 directly from an Admin Powershell window.
https://github.com/ajn142attamu/DriverAutomationTool/blob/master/Current%20Branch/7.2.2/DriverAutomationTool.ps1
Let me know if that helps and I can see about putting in a PR.

So if I understand correctly, the tool for me is installed on the MECM server. I am elevating PS, then change direcory where I have it and hit enter? No switches or is the PS script a GUI outside of this tool or what is expected? Does it need to be in the Driver Tool folder somewhere? Looking for the breakdown if any.

Nevermind, figured it out but I'm still getting errors with use of PS.

So, we ran into this, and one thing that may be at play is there's a local copy of the OEMLinks.XML file cached in the Settings folder. If you moved the .ps1 to the same directory as the installed EXE, it's likely picking up the local file originally pulled from this repo, rather than my fork. You can confirm by comparing the local OEMLinks.xml file on your computer to the one here in my fork https://raw.githubusercontent.com/ajn142attamu/DriverAutomationTool/master/Data/OEMLinks.xml
Also, there's some discussion of the BITS errors in #450, I'd try downloading just a single file at a time after you remove the errored BITS transfers.

That was my issue. I uninstalled, removed all folders, re-installed it, re-ran the script and worked. There is one selection under Surface Laptop 4 that keeps doing this and haven't figured it out.

So are you saying that the DAT is now working with pulling Microsoft info after you uninstalled and reinstalled it? And you can verify that you are seeing all the Microsoft Models in both Windows 11 22H2 and Windows 10 22H2?

[67dbc]

Uninstalled the application completely, removed all folders/files, re-installed it and kicked off the updated script again and seems to be working. Feel like it was grabbing old data points content presenting the same errors so start fresh!

Hey, I think my fork might fix the Surface driver issue, we don’t have any Lenovos. I haven’t figured out compiling the .exe or .msi like the repo owner, so you have to run the .ps1 directly from an Admin Powershell window.
https://github.com/ajn142attamu/DriverAutomationTool/blob/master/Current%20Branch/7.2.2/DriverAutomationTool.ps1
Let me know if that helps and I can see about putting in a PR.

So if I understand correctly, the tool for me is installed on the MECM server. I am elevating PS, then change direcory where I have it and hit enter? No switches or is the PS script a GUI outside of this tool or what is expected? Does it need to be in the Driver Tool folder somewhere? Looking for the breakdown if any.

Nevermind, figured it out but I'm still getting errors with use of PS.

So, we ran into this, and one thing that may be at play is there's a local copy of the OEMLinks.XML file cached in the Settings folder. If you moved the .ps1 to the same directory as the installed EXE, it's likely picking up the local file originally pulled from this repo, rather than my fork. You can confirm by comparing the local OEMLinks.xml file on your computer to the one here in my fork https://raw.githubusercontent.com/ajn142attamu/DriverAutomationTool/master/Data/OEMLinks.xml
Also, there's some discussion of the BITS errors in #450, I'd try downloading just a single file at a time after you remove the errored BITS transfers.

That was my issue. I uninstalled, removed all folders, re-installed it, re-ran the script and worked. There is one selection under Surface Laptop 4 that keeps doing this and haven't figured it out.

So are you saying that the DAT is now working with pulling Microsoft info after you uninstalled and reinstalled it? And you can verify that you are seeing all the Microsoft Models in both Windows 11 22H2 and Windows 10 22H2?

Not quite - Some muddy water on my part but my original issue was trying to use the "workaround" script @ajn142attamu provided because I couldn't get anything to download. I was having issues and it pointed to OEMLinks.xml stored in \MSEndpointMgr\Driver Automation Tool\Settings folder. To fix, uninstall and cleanup DAT folders/files, re-install, re-run the script. Now, the above issue and I now understand under #450, if you have this specific issue, you need to close down DAT, run "Get-BitsTransfer -AllUsers | Remove-BitsTransfer", then re-launch the DAT script again, and it will let you download. With that said, issue for me still remains that there is no Windows 10 22H2 downloads and I still get the message to choose different OS/Build. Windows 11 22H2 is not a problem but most of my clients don't use Windows 11 at this time.

[ddubnyk]

Hey, I think my fork might fix the Surface driver issue, we don’t have any Lenovos. I haven’t figured out compiling the .exe or .msi like the repo owner, so you have to run the .ps1 directly from an Admin Powershell window.
https://github.com/ajn142attamu/DriverAutomationTool/blob/master/Current%20Branch/7.2.2/DriverAutomationTool.ps1
Let me know if that helps and I can see about putting in a PR.

So if I understand correctly, the tool for me is installed on the MECM server. I am elevating PS, then change direcory where I have it and hit enter? No switches or is the PS script a GUI outside of this tool or what is expected? Does it need to be in the Driver Tool folder somewhere? Looking for the breakdown if any.

Nevermind, figured it out but I'm still getting errors with use of PS.

So, we ran into this, and one thing that may be at play is there's a local copy of the OEMLinks.XML file cached in the Settings folder. If you moved the .ps1 to the same directory as the installed EXE, it's likely picking up the local file originally pulled from this repo, rather than my fork. You can confirm by comparing the local OEMLinks.xml file on your computer to the one here in my fork https://raw.githubusercontent.com/ajn142attamu/DriverAutomationTool/master/Data/OEMLinks.xml

Also, there's some discussion of the BITS errors in #450, I'd try downloading just a single file at a time after you remove the errored BITS transfers.

So i've used your OEMLinks and it works good for me to get the Surface Pro 9 drivers for Windows 11. However, it appears you don't have the latest or any driver for Windows 10 on that device and i haven't quite figured out how to add that link into my own version yet. The latest, and probably last version of Windows 10 drivers is this one.

https://download.microsoft.com/download/e/9/a/e9a35d1b-7b4c-48d4-8619-5301d4c09f65/SurfacePro9_Win10_19044_23.044.40192.0.msi