Recently I found an issue regarding the UAG not able to name resolve my Horizon Connection Servers in my lab environment.

I’m running Horizon version 7.11 with UAG version 3.8 appliances for external access. The appliances are enrolled fully automated with a PowerShell and a configuration file.

I’ve created a blog post on how to do this for Horizon DaaS. The same principle also applies also Horizon 7.

UAG Deployment

The appliances are enrolled with the DNS server IP address and DNS Search domain configuration parameters within the PowerShell configuration file:

dns=192.168.0.10
dnsSearch=domain.local

After the UAG deployment, you can see the configuration is correctly applied in the UAG admin page (https://uag-mgt-ip:9443/admin)

Log in with the admin account. Go to Manual Settings -> Advanced Configuration -> System Configuration (scroll down)

2020-02-18 18_42_47-DED-S19-VDI100

The problem

When the UAG is initially deployed, everything works as expected and the UAG is able to name resolve the Horizon Connection servers. The problem occurs only when you reboot the appliance. After the appliance is rebooted, I noticed I was not able to connect externally to my Horizon environment anymore.

As it turns out, this change came with UAG version 3.7. The underlying OS Photon version 3 handles DNS resolving differently, for instance not resolving .local domains anymore.

When I looked again at the UAG admin page, I noticed my Horizon Connection server was not reachable after the reboot:

2020-02-17 10_39_32-DED-S19-VDI100

When I logged on as root on the UAG console, I could not ping the Horizon Connection Server with FQDN. This was strange because the DNS and DNS Search settings were still present in the configuration.

I decided to perform some basic Linux tests to see if everything was configured correctly on the appliance. The first place you want to look for DNS settings is the /etc/resolv.conf file. It was there I noticed the DNS name server IP address was reset to IP address 127.0.0.53, and according to KB78611, this is as-designed and the file should never be editted.

2020-02-17 10_33_19-DED-S19-VDI100

The workaround

Update: According to KB50120424 and KB78611 the following procedure not fully supported anymore, so please change at own risk and test only in non-production environments. 

An easy workaround is to change the file /etc/systemd/resolved.conf

You will have to out-comment the Domains line and fill in your DNS Search domain FQDN, in this case domain.local and save the file.

2020-02-18 19_04_27-DED-S19-VDI100

When you go back to /etc/resolv.conf, you will notice the extra line search domain.local

2020-02-18 19_08_05-DED-S19-VDI100

The nameserver is still 127.0.0.53 in this file. Don’t worry, because this doesn’t matter and DNS name resolving works perfectly again.

When you now reboot the appliance, the configuration is still there, and the Horizon Connection servers are still reachable.

2020-02-17 10_40_29-DED-S19-VDI100