Changing the DNS server configuration on your servers is not a task you do on a daily basis. But when you have to, it is not always a straight forward action, as I experienced when trying to change the DNS server on the VMware Life Cycle Manager Appliance.

Changing the DNS
configuration under Windows is no big deal and is as easy as next, next,
finish. Under linux however there are multiple ways to accomplish this task
depending on the linux distribution. In most cases the easiest and common way
is to edit /etc/resolv.conf and restart the service.

In this case, I am
working with a virtual appliance, so I want to keep the editing on the command
line to a minimum. Virtual appliances
are normally managed through a management webpage, and for the vLCM appliance
this is equally so. I login to the vLCM management page and under settings I
see the configured IP and DNS configuration.

Unfortunately, I can
only view the configuration but can’t make any changes. So I searched the
VMware knowledgebase to see what the supported method for changing DNS on
Photon OS was, but got nothing. Even a Google search didn’t give any good
results. This left me with no other option than to dive into the command line
and edit the configuration by hand.

As mentioned earlier,
most linux based distributions use resolv.conf as the configuration file for
DNS. However upon opening resolv.conf I saw that Photon uses “systemd-resolved”
to manage name resolving and that I shouldn’t edit this file by hand.

When working with
system and DNS there a few places where you can configure settings. Let’s look
at them for a second:

/etc/resolv.conf is a symbolic link
to /run/systemd/resolve/resolv.conf and is the running configuration which must
not be edited by hand.

/etc/systemd/network/10-eth0.network
is the configuration file for the vm’s ethernet adapter. You set the IP
address, subnet mask and gateway here, but can also specify search domains, NTP
and DNS.

/usr/lib/systemd/network
this folder contains the configurations of other (virtual) adapters on the
system

/etc/systemd/resolved.conf this file
contains the configuration of DNS that would normally be located in resolv.conf

I changed both 10-eth0.network
and resolved.conf with the desired DNS servers and search domains, restarted
the services, and for a short time everything seemed to work. But after a
reboot all settings where back to the old configuration. I was rattled and
searched for some other configuration files, looked through a lot of log files,
but couldn’t find the culprit.

When all seemed lost,
I had a bright moment. I did a search for the old DNS IP in all files (grep
-rnw '/' -e '172.25.168.3'), and there between all the rows of text I saw the
mentioning of “/opt/vmware/etc/vami/ovfEnv.xml”.

ovfEnv.xml is a file
that is created at the deployment of an OVF and apparently is loaded every time
the VM boots. I changed the configuration in the XML file and after a reboot
the new configuration was still there.

From time to time you’ll
see machines in vRA that have the status “On (Reconfigure failed, waiting to
retry)”. In some cases this status will never go away, because in reality the
retry is already done and everything went well but the status in vRA still says
“Waiting for retry”.

The problem with a “Waiting
on retry” status is that you cannot edit the machine properties, as vRA thinks
that the machine is still waiting for other changes to be applied.

So we login to the vRA
database server (in this case a MSSQL server) and select the vRA database. As
you can see in the table view, there are many different tables containing
everything that vRA is made of.

The table that
contains the machines and its status is “dbo.Virtualmachine”. You can check the
contents of this table by starting a new query like select * from [dbo].[virtualmachine]

To check what the current state of a machine is, you can query select CurrentTask from [dbo].[virtualmachine] where VirtualMachineName in ('VM_name').

Now as we want to reset this status to the default, we have to reset the CurrentTask field to nothing. To do this we execute the following SQL statement: update [dbo].[virtualmachine] set CurrentTask = NULL where VirtualMachineName in ('VM_name ').

When we run the
previous query (select from) again, we can check the new status of the current
task. And when we check in vRA we will see that the status is back to “On” and
we can make modifications to the machine again.

We did an update of
our Horizon View environment from version 7.4 to version 7.5.1. After the
update we noticed something strange. Everything was working except for the
BLAST client on the Chrome browser. Other browsers didn’t give errors and
worked, but Chrome threw the error: “Failed to connect to the Connection
Server”.

After some searching
in the VMware knowledge base, I found that the error has something to do with
security. The View Security document talks about Cross-Origin Resource Sharing
(CORS) as the feature that handles the policies in regard to HTTP request. (https://docs.vmware.com/en/VMware-Horizon-7/7.5/horizon-security.pdf). This means that when an URL is
used that is not the same as the listening domain, or when multiple domains are
used, the policies can block access because the actions are considered not
secure (like there could be a man in the middle attack).

In our case we have
two URL’s to the Connection Servers. The first is a loadbalanced URL (http://ViewDesktop.LocalDomain) and the second is a direct URL to the
Connection Server (http://HostName.LocalDomain). We noticed that the direct URL
didn’t gave problems, but de loadbalanced URL did. So it seems clear that the
problem must have something to do with CORS and in specific with the Chrome
browser.

When we read a little
bit further in the security documentation we’ll see an explanation for our
Chrome problem: “Chrome extension clients set their initial Origin to their own
identity. To allow connections to succeed, register the extension by adding a
chromeExtension entry to the locked.properties file”.

Now, all CORS related
settings are set in the file called locked.properties. You can find the file on
your View Connection and Security Servers in the folder C:\Program Files\VMware\VMware
View\Server\sslgateway\conf\ and if it doesn’t yet exist, you can simply create it.

So now that we know
the problem in the Chrome browser seems to be coming from a security feature,
how do we fix the problem? There are multiple solutions to solve this problem,
which all include the locked.properties file.