eosdata
Enthusiast
Enthusiast

Changing FQDN

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?

0 Kudos
6 Replies
sravuri
VMware Employee
VMware Employee

Which version of Horizon Workspace are you using?

0 Kudos
eosdata
Enthusiast
Enthusiast

Hi I use Version 1.8.1

0 Kudos
RaviChayanam
VMware Employee
VMware Employee

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

0 Kudos
RabbiX
Contributor
Contributor

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


 

0 Kudos
eosdata
Enthusiast
Enthusiast

OK i'll try that! Thanks!

0 Kudos
eosdata
Enthusiast
Enthusiast

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!

0 Kudos