---
# source: blog-content: posts/en/how-to-horizon-verbindung-absichern-teil-2.md
# route:  /en/insights/how-to-horizon-verbindung-absichern-teil-2/
title: Securing the Horizon connection – part 2
date: 2024-12-11
author: raphael-thommen
locale: en
summary: Part 1 covered how locked.properties secures the connection between Horizon Connection Servers and clients, mainly through balancedHost. There are cases where that causes trouble.
capabilities: [modern-workplace, virtualization]
vendors: [omnissa, vmware]
series: how-to
hero: /blog-assets/how-to-horizon-verbindung-absichern-teil-2/hero.webp
migrated: 2026-08-24
translationReviewed: false
draft: false
---

In the first part of this series I described how configuring `locked.properties` helps secure the connection between the Horizon Connection Servers and the clients and agents, mainly through the `balancedHost` parameter. [Part 1 is here](https://soultec.ch/how-to-horizon-verbindung-absichern/).

There are scenarios where that method causes trouble. This post looks at an alternative configuration and weighs it up.

## The problem: no access to the Horizon admin console over the load-balanced DNS name

Even with the configuration in place, the Horizon admin console may be unreachable over the load-balanced DNS record, for example `vdi.soultec.lab`. This happens in particular when `balancedHost` is set in the configuration and the load balancer distributes traffic incorrectly.

Missing or incorrect configuration can cause this:

-   The administrator sees "Login Failed", "404 Not Found" or "The page you requested is not available" when signing in to the console on the load balancer URL with /admin

![](/blog-assets/how-to-horizon-verbindung-absichern-teil-2/01.webp)

### The alternative: several `portalHost` entries

One way round it is to list every relevant URL explicitly as a `portalHost` in `locked.properties`. That includes:

1.  The load-balanced DNS record (for example `vdi.soultec.lab`).
2.  The individual Horizon Connection Servers (for example `labhrzcs01.soultec.lab` and `labhrzcs02.soultec.lab`).
3.  Any further hosts, such as Unified Access Gateways (UAGs).

Example configuration:

```properties
portalHost.1=vdi.soultec.lab
portalHost.2=labhrzcs01.soultec.lab
portalHost.3=labhrzcs02.soultec.lab
```

`locked.properties` lives at:  
`C:\Program Files\VMware\VMware View\Server\sslgateway\conf\locked.properties`

This configuration covers every possible connection, which keeps access problems to a minimum.

### Worth knowing

-   Every `portalHost` entry has to match the servers' DNS names exactly.
-   Test the connection after every change.

## Conclusion

Using `portalHost` entries is a flexible way to solve access problems on the Horizon admin console, particularly in environments with load balancers. It does mean checking the configuration regularly and making sure every relevant host is listed in `locked.properties`.

If you have further questions on this or need a hand, get in touch through our website.