@dinhngtu That's great, thank you. I think I'll wait a bit before switching tools. Everything's working perfectly at the moment. If you need me to test anything, just let me know. I'd be happy to test it when I have time.

@dinhngtu Since I'm not currently using these group policies myself, I can't contribute any recent experience.

However, it seems to be the case, since you've also noticed this. Would my current approach be the most sensible regarding IP address retention and the number of restarts?

Or would it make sense to wait a while until a solution to this problem is found?

Would it be useful to offer the option to shut down instead of reboot in XenClean.ps1? Then disabling the Windows Update drivers could be done in the same step.

I've managed to test it as you suggested.

The IP address was retained throughout the entire process. But the installer of XCP-ng Tools still detects an incompatible device and asks to run XenClean again. The "Prevent installation of devices that match any of these device IDs" Policy was set as instructed.

This procedure has required four reboots. (1st XenClean, 2nd manual shutdown to disable Windows Update option, 3rd XenClean and 4th install XCP-ng tools)

Theoretically, there should be one final step to remove the PCI\VEN_5853&DEV_C000 device from the policy, just to avoid future problems.

@dinhngtu Hi dinhngtu, thank you for your answer. I will try this out and report back later with any findings about this procedure.

Hello everyone

I'd like to get your opinion.

It's about migrating from Citrix GuestTools to XCP-ng GuestTools.

The VMs have driver updates enabled via Windows Update.

According to the instructions at https://docs.xcp-ng.org/vms/#fully-removing-xen-pv-drivers-with-xenclean, Windows driver updates should be disabled.

If this is done before XenClean, the IP configuration is lost in my tests because the network device switches from XenServer PV to the
emulated device.

The following procedure worked for me. The IP address was always retained. However, three reboots are required:

1. Create a VM snapshot
2. Uninstall Citrix XenServer Tools using a script (XenClean.ps1)
   a. VM restarts automatically
3. Network check -> IP address correct
4. Shut down VM
5. Disable automatic driver updates for the VM via Windows Update
6. Restart VM
7. Network check -> IP address correct
8. Attempt to install XCP-ng drivers
   a. Errors may occur because the vendor device might still be active. In this case, run XenClean.ps1 again to uninstall it.
   b. Uninstall Citrix XenServer Tools using the script (XenClean.ps1)
   i. VM restarts automatically
9. Network check -> IP address correct
10. Install XCP-ng Tools
11. Reboot when prompted
12. Network check -> IP address correct

Point 8 is critical. The XCP-ng GuestTools cannot be installed at this time because the vendor device for driver updates is still detected and has to be uninstalled first.

What do you think? Is there a better way, perhaps with only two reboots, while keeping the IP address the same?

I find it important to take over the IP address, as otherwise it temporarily reverts to DHCP, which can cause problems with the running server services.

I also tried disabling Windows Updates first and then running XenClean. However, XenClean doesn't then take over the original IP address of the XenServer PV adapter.

Thanks for your opinions or experiences.

@dinhngtu From my point of view this would be fine So the systems can be distinguished even when the buildnumber is the same.

@dinhngtu I was just wondering. I would expect the Windows Name (as the property implies). At the moment "OS name" and "OS kernel" are filled with the same information. So in a quick view through the VM-tree one could not define its a server or a client OS. Sure, soon there will be another buildnumber for Windows 11 due to 25h2. But in this way IMHO it's a little bit more tricky to get an overview Overall its not a big thing.

It's great, thank you so far! I've noticed, that the reported OS in XenOrchestra (and XCP-ng Center) is reported differently compared to Citrix Tools. Is this intentional? For example, this is a Windows Server 2025 and not a Windows 11 24h2.

@openaithedolphinshop-svg Hey, the original issue of this thread occured only with Server 2025 with AD role installed. Without AD role on it it worked already beforehand.

Due to the release of the Xentool 9.4.2, I once again tested whether the tools will start again without Delay. This was now the case with me. My XCP-NG test host now has 8.3 on it. That means: XCP-NG 8.3 with Xentools 9.4.2 and with Windows Server 2025 with AD role installed in this combination lead to me that the tools now can start correctly without the delay setting. But I cannot say whether the problem may have been fixed beforehand or whether XCP-NG 8.3 has an impact. I just wanted to let you know briefly because I didn't have it on my screen at the moment. So the initial reason of this thread seems fixed to me

@stormi indeed not free of irony

@olivierlambert

Hi, thanks for your reply.

To your questions:

1. XO Commit 3aa36f9
2. XCP-ng 8.2.1 LTS with latest updates (updated last saturday)

Regards

Hi All

I am just curious if i am the only one who is facing this.

I have an actual XenOrchestra which is build from the sources. Recently i've noticed, that i'm not able to download the systemlogs tgz file from Hosts -> Host -> Advanced Tab -> yellow button "Download system logs".

I have two Hosts in a pool, they both behave the same with any browser:

1. Download starts without estimation but at high speed
2. Some Megabytes are downloaded (~180MiB when trying on masterhost while 90MiB on slavehost)
3. Download speed suddenly stop an stuck at 0 for some minutes
4. Browser considered the download as failed
5. The file "logs.tgz" is corrupted an cannot be read.

With google search i did not found anything useful. Am i missing something or is there currently a problem with this feature?

Kind regards and have a nice day!

Hi,

I agree to this conclusion at this time.

Greetings

My three test systems seems to work properly when the management agent start type is set to delayed. So i think this can be a workaround for the moment.

@Greg_E
Hi Greg_E

Thanks for your detailed report and informations I will try it with delayed start. It could be a solution indeed. When i have news on this, i will share it here.

@archw
Hi, i thought the same today so i gave a try. But unfortunately at my test server fully patched with fresh ADDC on it there are the same issues present. But i have to say that i did not a detailed test at this time.

@archw

You should also notice that you cannot run any task scheduler tasks any longer. The task starts, but the action is not taken and after the timeout it end. Also any .msi package cannot be installed due to the Windows Installer Service is not able to start.

@Greg_E

Hi Greg_E

Yea, that are exactly the same findings as mine

I think to disable the Service could be a workaround for the moment. 9.4.0 did not make a difference compared to 9.3.0.

We will start our new project with 2025 with workaround in place and monitor the situation when a new version become available where the issue may have been fixed.

I'm glad for any further comment on this topic when new informations become available from any the community members or the devs

Have a nice evening!