@pdonias Sure thing. I can test it in my test environment.

@archw I can confirm. That is exactly the behaviour I see with my Windows VMs.

@dinhngtu Thanks for the pointer. Yes, it seems that the root cause also makes routes disappear. Howerver, that the routing information is gone is sadly not mentioned explicitly. May be something to add to your docs as well.

Caution when updating tools: Verify interface IP configuration and routing entries.

Just did a couple more tests. Here are my findings:

• Upgrading the tools from v9.3.3 to v9.4.1 does preserve the routing table.
• Upgrading the tools from v9.2.1 to v9.4.1 does not preserve the routing table.

Here are a couple of powershell commands used for testing:

Get-NetRoute -PolicyStore PersistentStore
Get-NetAdapter
New-NetRoute -DestinationPrefix "10.10.0.0/24" -InterfaceIndex <ifIndex> -NextHop 10.10.0.254

@pdonias Sure thing. I can test it in my test environment.

@DustinB Not IP assignments, I am talking about static routes. See e.g. https://learn.microsoft.com/en-us/powershell/module/nettcpip/get-netroute

Here is another interesting fact: After installing the new tools (v.9.4.1) my static routes in Windows were all gone. Definitively a good way to loose connectivity to your domain controller. And that's why you have good monitoring and store things in Ansible et al. ...

@dinhngtu On the machine where it worked, the option "Manage Citrix PV drivers via Windows Update" was not enabled. Seems that my older BIOS Windows 10 VMs have that option enabled. On all UEFI VMs the options is disabled.

As I wanted to go and check that is present in the templates, I realized that the Windows Templates are gone from Xen Orchestra v5.106.4???

On another Windows 10 host it worked. What was different: I saw the message box "Tools have been installed successfully". May be that makes a difference?

@dinhngtu On a Windows 10 VM rebooting alone did not do the trick. After 5 reboots the script still reports vulnerable devices:

.\Install-XSA468Workaround.ps1 -Scan

Looking for vulnerable XenIface objects
Found vulnerable object XENBUS\VEN_XSC000&DEV_IFACE\_
Found vulnerable object XENBUS\VEN_XSC000&DEV_IFACE\_

Looking for vulnerable XenIface WMI GUIDs
Found vulnerable WMI GUID 1D80EB99-A1D6-4492-B62F-8B4549FF0B5E
Found vulnerable WMI GUID 12138A69-97B2-49DD-B9DE-54749AABC789
Found vulnerable WMI GUID AB8136BF-8EA7-420D-ADAD-89C83E587925

Found XenIface vulnerability, it's recommended to run the script
True

Running .\Install-XSA468Workaround.ps1 works as expected. After another reboot nothing is reported as being vulnerable anymore.

On a Windows 2019 Server I saw the behaviour you described: Installing the tools and a reboot was enough.

@dinhngtu Ok, I will keep that in mind as I go through all the VMs. As I currently cannot update XCP-ng on all hosts (8.2.1 LTS), the VMs where the new tools were installed and mitigations applied show up as "orange".

On a XCP-ng 8.3 test hosts with all updates applied the detection works as advertised.