Sometimes I really love the #vCommunity – Just kidding: I love them all of the time. I was confronted with a scenario where only certain users of a Horizon environment should be allowed to access their own Desktop via the Internet.
In general you have certain options to do some kind of restrictions:
- Using Tags on the Connection Server and Create Desktop Pools that only allow the usage by Users coming from a tagged Connection Server
- Using VMware vIDM (Identity Manager) and create conditonal access rules. This will work, but will also create some new overhead to implement vIDM in a high-available fashion.
Fortuneatly the EUC-Champion Slack Community came up with another idea I haven’t really heard about before (The feature was introduced with Horizon 7). Thx Sven and Joe for your help here.
The following section shows you how to make use of VMware’s Unified Access Gateway (UAG) Appliance to give the enduser access into our virtual Desktop / Remote hosted Applications over an unsecure network like the Internet.
When we are creating this access we have multiple options.
- Using a VPN to ‘tunnel’ into the secure cooperate network environment and connect further to the Horizon View environment.
- Placing a Windows Server in the DMZ and installing/configuring the Horizon View Security Server and make it public accessible.
- Placing the virtual Unified Access Gateway in the DMZ and installing/configuring the Horizon View Security Server and make it public accessible.
What is the / my recommendation nowadays? Go with the Unified Access Gateway. Why?
- It is a general opinion within Security experts that a Windows, even if it’s hardened, offers more attack potentials than a hardened minimal linux.
- Using the Windows based security server creates a 1:1 relationship between the Security Server and the Connection Server, therefore it takes away some access flexibility.
- The UAG is getting more and more features to integrate other solutions like specific Airwatch functionality
- You can make use of the UDP based Blast Extreme Protocol Adaptive Transport protocol that gives you a better remote/user experience even if you are connecting over a lossy network
- It is much easier to operate than the first Access Point versions VMware has made GA a few years ago ;-)
One important aspect of the UAG is that you need to know about the packet-flow between the Horizon Client and the Desktop. You will be dependant on the networking and security guys. Make sure you are able to clearly articulate the requirements and what is going to happen. If you can tell the flow, the other people will be able to help you much better.
In the following article I am going to tell you how easy it is to set up a load balanced Horizon View environment. But remember: Just because something is easy to install it is not necessarily easy to design. There are multiple design affecting factors I am going to discuss in my #design guide. There are many Installation Guidelines out there, so I will keep it quick and simple and try to give you some hints what to do or not to do.
What do I want to achieve or show to you in this blog post?
- Creation Redundant Connection Server to access virtual Desktops
- A redundant Load Balancer in front of it (#NSX ftw)
- Internal Access only – I spent a lot of time with the Unified Access Gateway and show you in the second blog post about how to enable access over the Internet into your Horizon Homelab
The Connection Server is a core component within our Horizon View environment. It gives us the opportunity to create Desktop Pools out of Windows / Linux machines or Application Pools (based on Microsoft RDSH-Hosts) and entitle them to any Active Directory User in our environment. It offers us the following key functionality
- Brokering between Endpoints (that have the Horizon Client installed) and a virtual Desktop / Remote Desktop Session Host (Application)
- Authentication Handler (AD only or 2nd factor)
- View Administration via web-based (Flash :-/ ) user interface
- HTML5-Client to access the Desktops/Applications without the need of a client
- Connection to the vCenter Server to create new VMs / Desktops
*taken from the Horizon Reference Architecture
This section within my VDI series is not just relevant for VDI environments. In the following I will cover many things that are relevant for regular vSphere (cloud-a-like) environments.
The Management & Virtualization Layer plays quite an important role within a VDI environment. Within EUC solutions we typically should focus on the User and the User experience. But before we can deliver a performant, reliable and available working environment we need to make sure the layer on the bottom is rock solid as well.
What is the purpose of this layer?
- Hosting Instances of Virtual Desktops
- Hosting Instances of Remote Desktop Session Hosts (RDSH)
- Hosting Management components
- Components for brokering between Endpoints (Desktop User) and the Virtual Desktops Horizon View)
- Components for Integrating with Virtualization Management (Horizon View & vCenter Server)
- Delivering Applications into the Virtual Desktops (App Volumes)
- Monitoring of the Environment (e.g. Icinga)
- Operations Management (vRealize Operations Manager and Log Insight)
- Management of the Virtual Machines (aka Desktops / RDSH Hosts) and the Hypervisor (vCenter Server)
- Component for managing Security relevant components (NSX-Manager)
In my design guide I will write about general design decisions regarding the management & virtualization layer. In my implementation guide I will give you hints about the setup of the environment.
The goal of this post is to describe / discuss design implications, design decisions and characteristics for the following relevant Products within the core Layer in their most current release:
- vSphere Layer
- vCenter Server
- NSX Manager
- Horizon View Connection Server
Implementation Details can be found in the corresponding Implementation post I have created.
Before we can start with the implementation guide I want to give a brief description what key functionalities must exist.
The following components has been installed and configured:
- vSphere ESXi host (physical or nested)*
- vCenter Server (Appliance)*
- HA/DRS Cluster
- vSAN Cluster
- Active Directory Domain Controller (including DNS)*
- Microsoft Certificate Authority Role*
- NSX Manager*
- FTP Service (for backing up NSX Manager)
- CIFS-Share for UEM User Profile Archive and Config files
This will be the first post in my Horizon Guide implementation section. Since my focus is on Horizon I will not go through each of the steps that are involved in setting up the foundation. If you want to get a feeling of the purpose of my blog series: Check it out here.
In my design guide I will write a little bit about general design decisions regarding the management & virtualization topic. In my implementation guide I will quickly go through the setup I have chosen. As a side note I want to remember you to always use English Language and Keyboard Layout :-). Going into native US-Mode for all kind of setup will keep a lot of pain away from you.
Before being selected as an EUC champion I was already planning a bigger guide on how to design and implement a feature rich and enterprise ready VMware Horizon environment (Check out my opinion about the evolvement of VDI solutions over the years).
In 2017 VMware is putting more and more effort into transforming the enterprises into digital workspaces with their Workspace One solution / initiative. Within Workspace One VMware combines Horizon with Airwatch technology (for device management and application delivery).
Since my homelab has been a little bit underutilized over the last months I decided to built up an Horizon environment , including most of the Software pieces of Horizon Enterprise. Lucky me: VMware has just announced Horizon 7.2 which finally includes a new help desk tool to deliver faster 1/2nd level support to our (beloved) users.
My goal of this series is not just to have a simple implementation guide. I want to give a guideline about important things from an architectural point of view as well.
Introducing the Cloud Pod Architecture and Global entitlements within Horizon View was quite an important step. Suddenly the boundaries of having a Pool per Cluster was dealt with.
Since there is still a misunderstanding about the Cloud Pod Architecture and one feature Global Entitlement, please keep in mind:
A Global Entitlement does not create a Desktop Pool that spans multiple Clusters. It puts a logical layer for the Active Directory entitlement on top of existing independent Desktop pools.
There can be multiple use cases for that. Having multiple independent View environments in different locations or just having a Single vCenter with multiple Clusters. Since we are dealing with independent pools (and just putting a logical entitlement layer on top of it) all the templates and Desktop pool operations must be done local on each pool.
I observed this in my homelab while multiple nested ESXi were not available. If you create a Desktop Pool in Horizon 7 (and I guess earlier as well) the following meaningful error might show up during the select of a host or cluster resource:
java.lang.IllegalArgumentException: Invalid paramaters during Cluster selection
Going through the Connection Server log files I figured out the java exception is called when the vCenter is crawled for all available Hosts and Clusters.
The routine is crashing when it hits an disconnected or not-responding ESXi host within the inventory.
Make sure every ESXi host is in a connected state.
ESXi hosts within some maintenance can really steal the show right here.
Make sure to get rid of this ESXi host by fixing the host or removing the host from the inventory. Please be aware of that a remove will also affect the your distributed switch.
I created several blog posts about the Predefined settings so far that hopefully gave you some understanding about the basic and advanced concepts.
In the following I want to show you a little bit about a feature not all of us know:
The opportunity to create dynamic predefined settings with the help of Environment variables and placeholders.
Placeholders within UEM’s predefined settings.
Within the predefined settings you are able to define variables that will be dynamically set during the runtime.
How can we do that you ask? Just use the the following placeholder within your default/predefined settings (Case sensitive):
The following example should show you how we can use this functionality to deliver a flexibel dynamic and context-based environment for the user (that almost sounds like marketing once again).
In on of my last posts I have explained what the basic concept of VMware’s User Environment Manager (UEM) is and how we can use it to pre-configure or enforce specific settings of applications in our Desktop environment.
In the following I am going to dig a little bit deeper and show you how those concepts get configured and can be used in the world of UEM.
### Check my further readings ########################
Create Default Settings with the Application Profiler
Once we have installed the Application Profiler we are able to create config files for UEM that explain which portion of the filesystem/registry is a part of the application’s user data.
The process is quiet simple. Start the Application Profiler, start the application from within and configure the relevant settings you want to enforce or have as a default configuration.