@Andrew said in All drop-down options are empty: XO install video thanks Andrew - 100% agree Tom's video is the exact one that introduced me to the ronivay script, which is what I've used for all XO-from-source installs without problems.

I'm expericing the same/similar behaviour with SAML, and submitted a Feature Request that it should be looked at. https://xcp-ng.org/forum/topic/10430/feature-request-if-authenticated-don-t-stop-at-the-xo.company.net-signin-page

@Danp Thanks a million dear. much appreciated

I'm starting to think that something is wrong. Everywhere I check, I can see that the SAML request from the SP should have a signature of some sort. It doesn't seem that there is anything of the sort in our case. We are using the opensource for preproduction and are waiting for a pro license (paperwork on it's way) so maybe there is something wrong in the implementation ?

@dinhngtu said in LDAP fails with error "Code: -32000 Message: Code: 0x3": sAMAccountName Thank you. (userPrincipalName={{name}}) filter made the trick. When I use (userPrincipalName={{name}}), it works for me either I set certificate check ON or not. (Actually I was expecting to check AD root cert as this connection is using LDAPS) And also test only works when I do it using UPN but not with username@domain format. Other filter options did not work at all.

positive Update: today I wanted to continue with this problem, but when I logged Into XOA today, Master status was Green / enabled. Since no one execpt me has credentials to the Testcluster, I am sure that no one else had done something. So the master host seemed to recovered itself from grey to green within the last 8 Hours. There were at least 1-2 hours yesterday between execution of "pool-emergency-transition-to-master" and still beeing grey dot / Halted. xe pool-emergency-reset-master master-address=... then added the remaining hosts to the new master.

bringing up the host and restarting the tools on master seem to stop the excessive logging. EDIT: Bringing down host 3 triggers the alerts again EDIT2: Looks like it may be due to how i shutdown the host. First time I put it into maintenance mode, then did the halt command. That caused the messages to come up. Second time I just did halt and that caused the messages to come up. Third time, i hit disable first then halt. So far seems the messages are no longer coming up. I guess i should RTM more lol.

@olivierlambert Awesome! Can't wait.

So, problem solved.....

Maybe the IO scheduler is not the right one?

@eeldivad i turned on "override-certs" option and it seems to work now. I'm still curious why the other build fails. Does anyone know how i can generate those 3 pem files manually to test?

This is solved. What I ended up doing was installing ubuntu and doing the whole install as root. Thanks for the help, I hope I can use XOA in the future!

@olivierlambert said in XOCE - Language not keep when i come back (surrely dumb question): Why? I mean you are the first person to ask this. It's more work to do that and I'm not sure to really see the value A cookie is the perfect simple way to store info that are from your same browser/session, so it's very logical. Yeah, I don't see the value in having to keep a user preference within XO itself either.. just don't clear your cookies. It's what they are meant for.

Thank you for your attention. It worked!

@payback007 said in vm start delay - does it work yet?: unfortunately "start delay" is not working as expected. The function what you marked above is to change the start delay of an existing "vApp". Here is an example of my setup: [image: 1558128450595-04e7439d-6b92-4356-aa23-14d704588be3-grafik.png] The value whould change the "Delay interval" later by XOA, nothing else. Otherwise is vApp feature also not working on my XCP-ng installation, I think it was never really tested. If you want to implement start delays to your VM's you can follow this guide: define vApp for autostart in xcp-ng center including start order find out the uuid of the vApp: xe appliance-list write autostart script containing #!/bin/sh xe appliance-start uuid=uuid-autostart-vApp implement new systemd.service in /etc/systemd/system/autostart.service [Unit] Description=autostart script for boot VM After=graphical.target [Service] Type=simple ExecStart=/path/to/your/autostart-script.sh TimeoutStartSec=0 [Install] WantedBy=default.target enable the service systemctl enable autostart.service Editing of boot delay time is then possible via XOA which is already a nice feature at all for "fine tuning" or adapt if new VMs are added to the autostart vApp. @olivierlambert whould it make sense to open an additional feature request? vApp-implementation was several times discussed with no "final statement" I think. When I have a pool without HA, how could I use this script? I thought about setting the script on the master server. However, in a maintenance, where a second node becomes the master, will I have to recreate the script?