FriendsOfMDT
Drivers do not extract on VMware Workstation Windows guest
IIRC, the WIM gets copied but the drivers do not extract. I worked on this sometime back and even though I modified the code to ensure that the name was being passed correctly (quoting) it still failed to extract. Running the extraction command interactively worked though.
Is your VMware Workstation machine reporting a model name of VMware7,1? I'm having the same issue and curious if the comma within the model name as causing the problem.
Here is the path: E:\PSDDEPLOYMENTSHARE\PSDRESOURCES\DRIVERPACKAGES ├───Windows_10_x64-LENOVO-ThinkPad_T495s ├───Windows_10_x64-VMware,_Inc.-VMware20,1 └───Windows_10_x64-WinPE_X64
I unfortunately don't have the skill to fix the issue myself, but I assume the PowerShell script that injects the drivers just needs to account for commas within the model name variable. So, if the theory is correct, we just need that minor fix for it to work.
can u show the DriverPath value and your Out-Of-Box Drivers structure ? @JerichoJones
@JerichoJones
you can try this with your Out-Of-Box Drivers structure
Same issue. I think it is a path quoting issue. I checked and the WIM exists (on C: anyway).
From the PSDDrivers.log
<![LOG[Get-PSDContent: Download from PSDResources\DriverPackages\Windows_10_x64-VMware,_Inc.-VMware20,1 to S:\MININT\Cache\PSDResources\DriverPackages\Windows_10_x64-VMware,_Inc.-VMware20,1 took 00:00:00.5773684]LOG]!><time="11:58:09.807-480" date="02-14-2024" component="PSDDeploymentShare.psm1:330" context="NT AUTHORITY\SYSTEM" type="1" thread="2732" file="PSDDeploymentShare.psm1"> <![LOG[PSDDrivers.ps1: Entering GenericDriver section]LOG]!><time="11:58:09.807-480" date="02-14-2024" component="PSDDrivers.ps1:118" context="NT AUTHORITY\SYSTEM" type="1" thread="2732" file="PSDDrivers.ps1"> <![LOG[PSDDrivers.ps1: Property GenericDriverPath is Windows 10 x64\Generic]LOG]!><time="11:58:09.807-480" date="02-14-2024" component="PSDDrivers.ps1:119" context="NT AUTHORITY\SYSTEM" type="1" thread="2732" file="PSDDrivers.ps1"> <![LOG[PSDDrivers.ps1: Property DriverPath is Windows 10 x64\VMware, Inc.\VMware20,1]LOG]!><time="11:58:09.807-480" date="02-14-2024" component="PSDDrivers.ps1:123" context="NT AUTHORITY\SYSTEM" type="1" thread="2732" file="PSDDrivers.ps1"> <![LOG[PSDDrivers.ps1: PowerShell variable SourceDriverPackagePath is PSDResources\DriverPackages\Windows_10_x64-Generic]LOG]!><time="11:58:09.807-480" date="02-14-2024" component="PSDDrivers.ps1:124" context="NT AUTHORITY\SYSTEM" type="1" thread="2732" file="PSDDrivers.ps1"> <![LOG[PSDDrivers.ps1: Searching for package(s)]LOG]!><time="11:58:09.807-480" date="02-14-2024" component="PSDDrivers.ps1:127" context="NT AUTHORITY\SYSTEM" type="1" thread="2732" file="PSDDrivers.ps1"> <![LOG[PSDDrivers.ps1: No driver package(s) found, could be a bad thing...]LOG]!><time="11:58:09.854-480" date="02-14-2024" component="PSDDrivers.ps1:133" context="NT AUTHORITY\SYSTEM" type="1" thread="2732" file="PSDDrivers.ps1"> <![LOG[PSDDrivers.ps1: Creating S:\Drivers folder]LOG]!><time="11:58:09.854-480" date="02-14-2024" component="PSDDrivers.ps1:138" context="NT AUTHORITY\SYSTEM" type="1" thread="2732" file="PSDDrivers.ps1"> <![LOG[PSDDrivers.ps1: Getting driver(s)...]LOG]!><time="11:58:09.854-480" date="02-14-2024" component="PSDDrivers.ps1:142" context="NT AUTHORITY\SYSTEM" type="1" thread="2732" file="PSDDrivers.ps1"> <![LOG[PSDDrivers.ps1: Found 0 ZIP package(s)]LOG]!><time="11:58:09.854-480" date="02-14-2024" component="PSDDrivers.ps1:147" context="NT AUTHORITY\SYSTEM" type="1" thread="2732" file="PSDDrivers.ps1"> <![LOG[PSDDrivers.ps1: Found 1 WIM package(s)]LOG]!><time="11:58:09.874-480" date="02-14-2024" component="PSDDrivers.ps1:182" context="NT AUTHORITY\SYSTEM" type="1" thread="2732" file="PSDDrivers.ps1"> <![LOG[PSDDrivers.ps1: Unpacking S:\MININT\Cache\PSDResources\DriverPackages\Windows_10_x64-VMware,_Inc.-VMware20,1\Windows_10_x64-VMware,_Inc.-VMware20,1.wim]LOG]!><time="11:58:09.885-480" date="02-14-2024" component="PSDDrivers.ps1:185" context="NT AUTHORITY\SYSTEM" type="1" thread="2732" file="PSDDrivers.ps1"> <![LOG[PSDDrivers.ps1: Entering WIM file section]LOG]!><time="11:58:09.885-480" date="02-14-2024" component="PSDDrivers.ps1:195" context="NT AUTHORITY\SYSTEM" type="1" thread="2732" file="PSDDrivers.ps1"> <![LOG[PSDDrivers.ps1: About to run: PowerShell Expand-WindowsImage -ImagePath "S:\MININT\Cache\PSDResources\DriverPackages\Windows_10_x64-VMware,_Inc.-VMware20,1\Windows_10_x64-VMware,_Inc.-VMware20,1.wim" -ApplyPath "S:\Drivers" -Index 1]LOG]!><time="11:58:09.885-480" date="02-14-2024" component="PSDDrivers.ps1:196" context="NT AUTHORITY\SYSTEM" type="1" thread="2732" file="PSDDrivers.ps1"> <![LOG[Error: Process exited with code 1]LOG]!><time="11:58:11.922-480" date="02-14-2024" component="PSDDrivers.ps1:201" context="NT AUTHORITY\SYSTEM" type="1" thread="2732" file="PSDDrivers.ps1"> <![LOG[Exception occurred: You cannot call a method on a null-valued expression.]LOG]!><time="11:58:11.949-480" date="02-14-2024" component="PSDDrivers.ps1:207" context="NT AUTHORITY\SYSTEM" type="1" thread="2732" file="PSDDrivers.ps1"> <![LOG[Exception details: System.Management.Automation.RuntimeException: You cannot call a method on a null-valued expression. at System.Management.Automation.ExceptionHandlingOps.CheckActionPreference(FunctionContext funcContext, Exception exception) at System.Management.Automation.Interpreter.ActionCallInstruction2.Run(InterpretedFrame frame)
at System.Management.Automation.Interpreter.EnterTryCatchFinallyInstruction.Run(InterpretedFrame frame)
at System.Management.Automation.Interpreter.EnterTryCatchFinallyInstruction.Run(InterpretedFrame frame)]LOG]!><time="11:58:11.949-480" date="02-14-2024" component="PSDDrivers.ps1:208" context="NT AUTHORITY\SYSTEM" type="1" thread="2732" file="PSDDrivers.ps1">
<![LOG[Stack Trace: at System.Management.Automation.ExceptionHandlingOps.CheckActionPreference(FunctionContext funcContext, Exception exception)
at System.Management.Automation.Interpreter.ActionCallInstruction2.Run(InterpretedFrame frame) at System.Management.Automation.Interpreter.EnterTryCatchFinallyInstruction.Run(InterpretedFrame frame) at System.Management.Automation.Interpreter.EnterTryCatchFinallyInstruction.Run(InterpretedFrame frame)]LOG]!><time="11:58:11.949-480" date="02-14-2024" component="PSDDrivers.ps1:212" context="NT AUTHORITY\SYSTEM" type="1" thread="2732" file="PSDDrivers.ps1"> <![LOG[PSDDrivers.ps1: Get list of drivers from \Drivers]LOG]!><time="11:58:12.966-480" date="02-14-2024" component="PSDDrivers.ps1:219" context="NT AUTHORITY\SYSTEM" type="1" thread="2732" file="PSDDrivers.ps1">
@JerichoJones, there is a new build released, please download and update your deployment share(s) and try again. The model alias for vmware has been set to only that without commas and version, so it will cover every vmware VM that it's model contains the "VMWare" part.
We've tested the updated version on the latest VMWare releases, and the fix seem to have solved the issue. Closing this issue.
This doesn't work in my environment. I would assume that the driver folder in MDT would have to be renamed. There are multiple versions of VMware and the drivers are not always compatible across versions. Yes, PnP should handle it but I prefer not to deal with possible issues.
Below are the changes I have made to support VMware without having to manually adjust anything.
PSDDrivers.ps1
Current
$SourceDriverPackagePath = ($BaseDriverPath + "\" + ($tsenv:DriverPath).Replace("\","-")).Replace(" ","_")
Change
$SourceDriverPackagePath = ($BaseDriverPath + "\" + ($tsenv:DriverPath).Replace("\","-").Replace(" ","_").Replace(",","_"))
PSDDriverPackage.ps1
Current
$FileName = ($DriverFolder.BaseName).replace(" ","_") + ".$($CompressionType.ToLower())"
Change
$FileName = ($DriverFolder.BaseName).replace(" ","_").replace(",","_") + ".$($CompressionType.ToLower())"
PSDGather.psm1 Current
# $LocalInfo['ModelAlias'] = ((Get-WmiObject -Class "Win32_ComputerSystem" | Select-Object -ExpandProperty Model).Trim()).replace(",","") # Remove the "," and replace with ""
$LocalInfo['ModelAlias'] = "VMWare" # Sets all models to VMware
Change
$LocalInfo['ModelAlias'] = ((Get-WmiObject -Class "Win32_ComputerSystem" | Select-Object -ExpandProperty Model).Trim()).replace(" ","_").replace(",","_") # Remove the "," and replace with "_", Remove the " " and replace with "_"
#$LocalInfo['ModelAlias'] = "VMWare" # Sets all models to VMware
Yes, the folder in PSDResources\DriverPackages have to match, and also interesting: In our testing it seemed like the newer drivers where quite compatible with older VMware versions. Do you have an example where a 20,1 driver doesn't work with an older version of VMware? Recent Broadcom changes also makes it challenging to test.
In my testing the vmxnet3 20,1 driver does not work on a 7,1 vSphere/ESX guest. I did not iterate through all the possible versions though.
I took a look at what is working. 7,1 - vmxnet3 1.8.x 20,1 - vmxnet3 1.9.x
What's the likelihood that Windows 10/11 or Windows Server 2016/2019/2022 will be running on older VMware platforms? Would be ok if we would only test with supported VMware versions, and/or newer guest OS hardware compatibility versions?
It's interesting that VMware has distinct support lifecycle entries for the VMware Tools, separately from the virtualization products (ESXi, vSphere, VMware Workstation, etc.). So there's two parts to that: platform versions (detected by PSD as a model string) and driver versions (either installed using the VMware Tools installer or extracted from a system where that has already been installed).
https://lifecycle.vmware.com/#/?advancedFilter=checkbox_sup
We should have general support for any supported version, but there shouldn't really be a need for any real version-specific logic (e.g. "model starts with VMware" is sufficient for VM detection).
It's interesting that VMware has distinct support lifecycle entries for the VMware Tools, separately from the virtualization products (ESXi, vSphere, VMware Workstation, etc.). So there's two parts to that: platform versions (detected by PSD as a model string) and driver versions (either installed using the VMware Tools installer or extracted from a system where that has already been installed).
https://lifecycle.vmware.com/#/?advancedFilter=checkbox_sup
We should have general support for any supported version, but there shouldn't really be a need for any real version-specific logic (e.g. "model starts with VMware" is sufficient for VM detection).
That's what I mentioned in the previous release announcement to @DeploymentBunny on Twitter, a couple of days ago: https://twitter.com/GSimos/status/1759689768152027616.
Another thing that I faced lately is that the extracted drivers from the VMWare tools package, contain some drivers that are targeted to Windows 10 and Server SKUs, however, when I deployed them on a VMWare VM, they weren't getting installed, so I resorted in getting the ones that were covering SKUs from Windows 8 and later. The drivers I had issues were the PVSCSI, VMXNET3, I don't remember by heart another one but those were enough to create issues to the deployed machines.
It's interesting that VMware has distinct support lifecycle entries for the VMware Tools, separately from the virtualization products (ESXi, vSphere, VMware Workstation, etc.). So there's two parts to that: platform versions (detected by PSD as a model string) and driver versions (either installed using the VMware Tools installer or extracted from a system where that has already been installed).
https://lifecycle.vmware.com/#/?advancedFilter=checkbox_sup
We should have general support for any supported version, but there shouldn't really be a need for any real version-specific logic (e.g. "model starts with VMware" is sufficient for VM detection).
It's good that you mention these two different parts, regarding the VMWare tools setup executable, that is more restrictive because they are doing platform checks and if it is not supported the installation is aborted with a relevant message. So for VMware tools, it can be a challenge, but for extracted drivers, if they are properly selected and tested (https://github.com/FriendsOfMDT/PSD/issues/131#issuecomment-1960359301) they should work perfectly fine.
Installing drivers is not enough anyway, the application needs to be installed anyway, so drivers only needs too be the nic,
Skickat från Outlook för iOShttps://aka.ms/o0ukef
Från: George Simos @.> Skickat: Thursday, February 22, 2024 10:37:19 PM Till: FriendsOfMDT/PSD @.> Kopia: Mikael Nystrom @.>; Mention @.> Ämne: Re: [FriendsOfMDT/PSD] Drivers do not extract on VMware Workstation Windows guest (Issue #131)
It's interesting that VMware has distinct support lifecycle entries for the VMware Tools, separately from the virtualization products (ESXi, vSphere, VMware Workstation, etc.). So there's two parts to that: platform versions (detected by PSD as a model string) and driver versions (either installed using the VMware Tools installer or extracted from a system where that has already been installed).
https://lifecycle.vmware.com/#/?advancedFilter=checkbox_sup
We should have general support for any supported version, but there shouldn't really be a need for any real version-specific logic (e.g. "model starts with VMware" is sufficient for VM detection).
That's what I mentioned in the previous release announcement to @DeploymentBunnyhttps://github.com/DeploymentBunny on Twitter, a couple of days ago: https://twitter.com/GSimos/status/1759689768152027616.
— Reply to this email directly, view it on GitHubhttps://github.com/FriendsOfMDT/PSD/issues/131#issuecomment-1960359301, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ADZWWO3UVSB2PORFWF2K3D3YU63A7AVCNFSM6AAAAABC6FYAZWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNRQGM2TSMZQGE. You are receiving this because you were mentioned.Message ID: @.***>
In our env, I have only the nic drivers, then using WMI we detect platform snd install appropriate app for it
Skickat från Outlook för iOShttps://aka.ms/o0ukef
Från: Mikael Nystrom @.> Skickat: Thursday, February 22, 2024 10:45:13 PM Till: FriendsOfMDT/PSD @.>; FriendsOfMDT/PSD @.> Kopia: Mention @.> Ämne: Re: [FriendsOfMDT/PSD] Drivers do not extract on VMware Workstation Windows guest (Issue #131)
Installing drivers is not enough anyway, the application needs to be installed anyway, so drivers only needs too be the nic,
Skickat från Outlook för iOShttps://aka.ms/o0ukef
Från: George Simos @.> Skickat: Thursday, February 22, 2024 10:37:19 PM Till: FriendsOfMDT/PSD @.> Kopia: Mikael Nystrom @.>; Mention @.> Ämne: Re: [FriendsOfMDT/PSD] Drivers do not extract on VMware Workstation Windows guest (Issue #131)
It's interesting that VMware has distinct support lifecycle entries for the VMware Tools, separately from the virtualization products (ESXi, vSphere, VMware Workstation, etc.). So there's two parts to that: platform versions (detected by PSD as a model string) and driver versions (either installed using the VMware Tools installer or extracted from a system where that has already been installed).
https://lifecycle.vmware.com/#/?advancedFilter=checkbox_sup
We should have general support for any supported version, but there shouldn't really be a need for any real version-specific logic (e.g. "model starts with VMware" is sufficient for VM detection).
That's what I mentioned in the previous release announcement to @DeploymentBunnyhttps://github.com/DeploymentBunny on Twitter, a couple of days ago: https://twitter.com/GSimos/status/1759689768152027616.
— Reply to this email directly, view it on GitHubhttps://github.com/FriendsOfMDT/PSD/issues/131#issuecomment-1960359301, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ADZWWO3UVSB2PORFWF2K3D3YU63A7AVCNFSM6AAAAABC6FYAZWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNRQGM2TSMZQGE. You are receiving this because you were mentioned.Message ID: @.***>
Installing drivers is not enough anyway, the application needs to be installed anyway, so drivers only needs too be the nic, Skickat från Outlook för iOShttps://aka.ms/o0ukef … ________________________________ Från: George Simos @.> Skickat: Thursday, February 22, 2024 10:37:19 PM Till: FriendsOfMDT/PSD @.> Kopia: Mikael Nystrom @.>; Mention @.> Ämne: Re: [FriendsOfMDT/PSD] Drivers do not extract on VMware Workstation Windows guest (Issue #131) It's interesting that VMware has distinct support lifecycle entries for the VMware Tools, separately from the virtualization products (ESXi, vSphere, VMware Workstation, etc.). So there's two parts to that: platform versions (detected by PSD as a model string) and driver versions (either installed using the VMware Tools installer or extracted from a system where that has already been installed). https://lifecycle.vmware.com/#/?advancedFilter=checkbox_sup We should have general support for any supported version, but there shouldn't really be a need for any real version-specific logic (e.g. "model starts with VMware" is sufficient for VM detection). That's what I mentioned in the previous release announcement to @DeploymentBunnyhttps://github.com/DeploymentBunny on Twitter, a couple of days ago: https://twitter.com/GSimos/status/1759689768152027616. — Reply to this email directly, view it on GitHub<#131 (comment)>, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ADZWWO3UVSB2PORFWF2K3D3YU63A7AVCNFSM6AAAAABC6FYAZWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNRQGM2TSMZQGE. You are receiving this because you were mentioned.Message ID: @.***>
And the PVSCSI driver when using the paravirtual storage controller Mike. However I always add the mouse and display drivers as well on both the boot images and during the deployment. My workflow is this:
- Have a boot image with the proper required minimum drivers (Storage, NIC(s), Mouse, Display)
- Install the drivers after applying the OS, in order to have the machine in a good working state
- Install VmWare Tools after the installation of the OS and when we are in Full OS mode via WMI conditions This works fine and without issues so far (for years), except the hiccup with the model names.
Yes, the folder in PSDResources\DriverPackages have to match, and also interesting: In our testing it seemed like the newer drivers where quite compatible with older VMware versions. Do you have an example where a 20,1 driver doesn't work with an older version of VMware? Recent Broadcom changes also makes it challenging to test.
Is this relevant Johan? https://github.com/FriendsOfMDT/PSD/issues/131#issuecomment-1960359301
So here is what I found: VMWare Tools Workstation (20,1) VMXNET3 19.12 ESX (7,1) VMXNET3 19.14
Hardware ID in both INF files: PCI\VEN_15AD&DEV_07B0
VMXNET3 19.12 does not load on ESX Windows 10 guests (even though it appears that it should).
`[version] Signature = "$Windows NT$" Class = Net ClassGUID = {4d36e972-e325-11ce-bfc1-08002be10318} Provider = %VMware% DriverVer = 11/30/2022, 1.9.12.0 DriverPackageType = PlugAndPlay CatalogFile = vmxnet3.cat PnpLockdown = 1
; Build for 3 different driver versions that support Windows versions: ; - x86 and x64 6.1 - ; - x86 and x64 6.2, 6.3 and later. ; - arm64 10.0.16299 and later `
`[version] Signature = "$Windows NT$" Class = Net ClassGUID = {4d36e972-e325-11ce-bfc1-08002be10318} Provider = %VMware% DriverVer = 08/28/2023, 1.9.14.0 DriverPackageType = PlugAndPlay CatalogFile = vmxnet3.cat PnpLockdown = 1
; Build for 3 different driver versions that support Windows versions: ; - x86 and x64 6.1 - ; - x86 and x64 6.2, 6.3 and later. ; - arm64 10.0.16299 and later `