@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.

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

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.

@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.