Changing FQDN

[eosdata]

Hi

I have a problem with changing FQDN. All works fine as long as I do not change FQDN. As soon as I change it, the system diagnostigs says AppManager Connection: Connection test failed in data-va

As a result AD synchronization doesn't work anymore.

The new FQDN is published via revers proxy.

Can anyone help with this issue?

[sravuri]

Which version of Horizon Workspace are you using?

[eosdata]

Hi I use Version 1.8.1

[RaviChayanam]

Hello,

Can you go back to system diagnostics page and see if the following is what you see for your Connector(s) from which AD synchronization does not work after you change the FQDN

Directory Server: ldap://(your AD):389

Directory Sync Configuration: Sync configured (manually)

Directory Service Status: Connection test successful

Then, please login to your Connector Admin UI (example URL : https://(your connector):8443/hc/admin/) and click on the About link on the left hand side. You will see some info like the following on that page:

The Horizon server is https://(your fqdn)

Does the fqdn you changed to show up there correctly?

Can you send me the /opt/vmware/horizon/configuratorinstance/logs/configurator.log file from configurator-va and /opt/vmware/c2/c2instance/logs/connector.log from the connector-va from which AD synchronization does not work via Private Message? Thanks.

Message was edited by: RaviChayanam to fix formatting

[RabbiX]

This has occurred to me once before and there is one thing you could easily verify:

If you have permitted root login via SSH to the data-va (or possibly others) by editing the sshd_config such as in this article:

Enabling SSH in Horizon Workspace Virtual Appliances | Horizon Tech Blog - VMware Blogs

then this will cause the FQDN change to fail when an automated check is performed.  If this sounds applicable, then you would just reverse the steps in the above article, make the FQDN change, then re-enable root SSH logon after you are done (if desired).

[eosdata]

OK i'll try that! Thanks!

[eosdata]

Hi all

OK, solution was to let the internal DNS Server point the FQDN to the internal IP adresses and not to the revers proxy. Thanks for helping me!