Quiesce the UAG within the respective administration interface. But the process around here is much easier.

So we don’t need to patch the hardened linux appliance? For sure we do. The reboot and patching of the Windows based connection server can be done completely seamless for the end-user.

Maintainability: All tunnels between the end users Endpoint and their respective Desktop is tunneled over the UAG.

Since we are not constraint by a 1:1 relationship between the UAG and the Connection Server we are much more flexible and can create full redundancy for all access ways.

Availability: 2 Windows Connection Servers only.

What is the advantage of this design approach?

Access from the internet for a specific User group.

Access from a branch-office in a different not-so-well-trusted country that is only allowed to communicate with a single Endpoint within the (HQ) network.

Access from a branch-office that must use RSA-token.

Access from the internal head-quarters (HQ) – All virtual Desktops are hosted within the HQs datacenter.

We need to offer access to 4 types of users: How would we have dealt with this situation in an older environment including a Windows based Security Server? Since the Security Server required a 1:1 pairing between a Connection & a Security Server we would easily hit the maximum number of 7 Connection Server in case that we want to offer multiple accesses from different locations.

Constraints to always use tunneled connections (because of network-simplicity or security constraints).

Offering access to internal users coming from a not so trust-worthy site/location (including a second-factor authentication for those users).There might be use cases where we want to design our horizon environment in a way that we use the UAGs not just for external unsecure access, but internally as well.

Uag vmware horizon