By Dean Flaming, Sr. Technical Marketing Manager – Technical Enablement, End-User Computing, VMware
On behalf of the many folks who helped make this happen, I am proud to announce the release of the Horizon 6 with View Introduction Hands On Lab! This lab is a guided tour of Horizon 6 with View specifically focusing on the new features.
This Horizon 6 with View lab is designed to demonstrate and introduce you to the new Horizon 6 features, starting with the ease of installation and configuration of View, RDS-hosted application setup and configuration, RDS-hosted desktop setup and configuration, and Cloud Pod Architecture configurations, including some scenarios.
Technical Details of This Lab
We designed and built this fully functional, self-contained lab within our VMware Hands On Labs environment, where not only is every lab isolated from other labs, but also all are delivered via our VMware OneCloud enterprise architecture and accessible from around the world. For those readers who have attended VMworld, you will be familiar with this environment because this is the same environment used to deliver Hands On Labs for the VMware major worldwide events.
Attendees are allotted four hours for lab completion, but we expect many will be able to complete the lab in a shorter time span.
This lab contains eight top-level virtual machines; one ControlCenter where you drive the lab; one vPod router; a virtual OpenFiler appliance; a vCenter Server virtual appliance, and four virtual ESXi hosts which host additional nested virtual machines for use in completing the lab exercises.
ControlCenter– ControlCenter is the virtual machine where you drive the lab and run the lab exercises. This system also runs the following services for the lab environment:
- Microsoft Active Directory Domain Controller
- Certificate Authority
- File Sharing
vCenter appliance – The VMware vCenter Server virtual appliance provides the central management and control for the nested vSphere servers.
vCenter Servers – The four VMware vSphere servers work in a clustered configuration and report in to the vCenter Server virtual appliance to run the nested virtual machines needed for this lab to function properly.
OpenFiler appliance – The OpenFiler appliance provides virtual storage to the virtual vSphere servers in order for them to be able to host the nested virtual machines.
vPod Router appliance – The router appliance is a custom-built appliance for our VMware Hands On Labs and other lab environments to route network traffic appropriately, both internal to the vPods as well as externally, when virtually wired for external access.
Nested virtual machines – The virtual machines nested within this vPod architecture are:
- Horizon View Connection Server-1– The first Connection Server to be set up within the lab.
- Horizon View Connection Server-2– The second Connection Server to be set up within the lab.
- RDSH001– The first Remote Desktop Server within the lab. This server already has Microsoft Remote Desktop Services configured.
- RDSH002– The second Remote Desktop Server to be set up within the lab. This server needs Microsoft Remote Desktop Services installed and configured.
- Win7-VDI-1– The first Windows 7 virtual machine to be used as a VDI desktop.
- Win7-VDI-2– The second Windows 7 virtual machine to be used as a VDI desktop.
- Win8-VDI-1– The first Windows 8 virtual machine to be used as a VDI desktop.
- Win8-VDI-2– The second Windows 8 virtual machine to be used as a VDI desktop.
- EndPoint-01– The virtual machine configured to be a simulated endpoint system for accessing the previous VDI desktops and remote applications.
The lab takes you through three main modules.
View Install and Configure Module– This module is a prerequisite for both of the other two modules. It walks you through the installation and configuration of a connection server, the installation of the agent on a VDI desktop, and the installation and configuration of the client software on the endpoint.
View App Remoting Configuration– The application remoting module walks you through the initial configuration of Remote Desktop Services within a Microsoft Windows server in order to understand exactly what is needed for Horizon 6 with View application remoting. After you have completed the Remote Desktop Services configuration, this module walks you through installation and configuration of the Horizon 6 agent on the RDS hosts and the configuration and validation of RDS application pools and RDS desktop pools.
Cloud Pod Architecture– This module walks you through the installation, configuration, and validation of the global namespace features of View.
Lab Module Navigation
Many of you may not be aware how easy it is to navigate within the Hands On Labs with some of the various tools and functions available for listing lab topics and rearranging the interface.
Arranging the Console – To move the console around on the screen, you can find a control bar on the upper right side of the Web display. This allows you to use a full-screen display, dock the screen to the right or left side of the browser window, refresh the screen in case of latency, or toggle the screen between floating and docked.
Arranging the Lab Manual/Instructions– In addition to moving the console, you can also move, dock, undock, open the Table of Contents to jump to a specific section, or even split-screen the lab manual between your computer screen and your tablet of choice.
Sending Text to Console– You can also send text from your localsystem to the ControlCenter console by use of the Send Text option beneath the Console display. Just click the SEND TEXT button and the “Send text to console” window appears. Type or paste in what you wish to send to the ControlCenter console and click the SEND button.
How to Access This Lab
To access this lab directly, visit the Lab Registration Form to get started!
We are excited to bring you this lab—the first lab released in 2014 and the first to be released in conjunction with a VMware product release! Moving forward, this lab will be updated for VMworld to include other modules such as Virtual SAN integration, troubleshooting, and much more!
For more information on VMware Hands On Labs, visit hol.vmware.com and sign up!
In the first postI talked about the basic architecture of a large scale hybrid cloud build out, as well as integrating an on premises view environment into the vCHS hybrid cloud. We extended that Horizon View environment into the vCloud Hybrid Service by adding security servers and global load balancing on the top layer. You may be asking yourself “why” did we do that? Well, the ultimate goal of building this out was to mesh together vCloud Hybrid Service – Disaster Recovery and desktops to access those applications. With the next stage we set out to replicate an internal only application to vCHS-DR and use DaaS on vCHS to give the users access to it once it was failed over.
The Use Case Background
Before we go into the architecture solution we need to understand the problem we are trying to solve. Many times in the past I have shown how you can fail over public facing applications. However, not every application is web-based, public facing, or of a “Next Generation” architecture. In a lot of cases many applications are still internal only and although may be web based, need a desktop on the corporate side to access it. This is also the case for legacy fat client applications. So the goal in this architecture was to show how a user can connect to an application on premises and also connect to that same application once vCHS-DR is invoked to fail it over. The solution will comprise a few components for illustration, refer to the original overview diagram to understand all the connection points.
- On premises Horizon View Desktops previously configured
- On premises “Wiki” based application with a local DNS Entry
- On premises AD/DNS Servers
- vCloud Hybrid Service – Disaster Recovery running on the Wiki server ONLY
- VMware Horizon DaaS on vCHS
- IaaS based AD/DNS with VPN connection to the DR Cloud
- Cloud to Cloud VPN from Horizon DaaS Cloud to vCHS-DR Cloud
- Access to External DNS system
- A Horizon View Desktop Client
For the purposes of continuing we will assume that the VPN’s and networks are already configured and replication is running on the Wiki Server. We will also assume from the previous article that the desktop image used for Horizon View on premises is available and ready to synchronize with the new Horizon DaaS cloud. In order to make this all work we need to first ensure the same desktop image is available in DaaS on vCHS for the customer. We will double click into a few of the virtual data centers above later on.
Synchronizing View and DaaS Images with vCloud Connector
For ease of deployment we created our Horizon View on premises desktop image in vCenter. We set it up the way we wanted and then used vCloud Connector Content Sync to push a copy of that up to our DaaS on vCHS cloud. This way we are able to subscribe the DaaS catalog to the vCenter version of the image. vCloud Connector catalog sync then ensures that the DaaS cloud has the same copy available to use. This is not required and there is other DaaS related things you need to do to utilize the image, but we won’t go into that. The concept is just to build one image and sync to the cloud(s). If you want to learn more about Content Sync with vCloud Connector you can watch this video. Honestly it’s easy to setup and takes care of ensuring the image is always in sync. Once you have the image in cloud you can use the admin tools of Horizon DaaS on vCHS to create and deploy a desktop pool with the exact same image.
The Fail Over Process (Run Book)
In normal running conditions, the user would connect to view.companyname.com with their Horizon View Client, access their corporate desktop and get to the Wiki Application using http://Wiki01/ from a desktop browser. In order to ensure the client can get to the same application during failure we need to invoke a process such as this:
- Failover the Wiki Application to the vCHS-DR cloud
- Re-IP the application in the new cloud and power on
- Update the local DNS Servers in the IaaS cloud for the Wiki Entry
- Re-Direct External DNS for view.companyname.com to point to the DaaS Cloud instead on on Premises View
- Clients can then log in and access the same application, 100% cloud based on desktop and IaaS.
For illustration purposes the logical diagrams below show the on premises environment along with the disaster recovery, and IaaS environments. Remember that the assumption here is all these have the proper cloud to cloud VPN’s and firewall rules setup for network connectivity per the first image.
Below is the On Premises logical architecture. Notice the desktops are are available behind Horizon View and can connect to “WIKI01″
Below is the Dedicated Las Vegas IaaS cloud that is where the AD/DNS is running for access to directory and name services once fail over occurs. Recall that VPN connections here are in place between the DaaS cloud and the vCHS-DR cloud for access to these services.
Below is the Dedicated Las Vegas DaaS tenant logical architecture. You can see the dtRAM gateways in place on the internet passing connection to the DaaS based desktops in vCloud Hybrid Service. Remember this cloud is connected via VPN to the vCHS-DR cloud so it can access the application below upon fail over.
In the Texas Disaster Recovery Cloud shown below, we can do a full fail over or a test fail over. In each case the WIKI01 server will be connected to one of the two networks. Once it is given a new IP address and DNS is updated the DaaS desktops will be able to connect.
Using External DNS To Manage Connectivity
In order to quickly re-direct a user’s View Client from on premises Horizon View to the DaaS desktop and making it transparent to them you need to get creative. In my case I created the following External DNS records to support this use case.
view.dyn.companyname.org = Public IP of View Secure Gateway (A-Record)
daas.dyn.companyname.org = Public IP of Horizon DaaS dtRAM Gateway(A-Record)
view.companyname.org =view.dyn.companyname.org (CNAME 30 Second TTL)
If you are an avid user of DNS for cases like this you should be able to see why I did this. During normal operations the users always connect to view.companyname.com in their client. However, in a disaster event you FLIP the CNAME to use the daas entry on the back end and when the client connects it’s completely transparent to them they are now on a DaaS cloud based desktop. Pretty simply a clean and easy way to manage this step in the run book.
The Role of SSL Certificates For Clients
Something you want to make sure of in this setup so that all clients, both desktop and tablet based work, is that you need to use proper certificates. You have really two options here to maintain the transparency to the user
- Install the SSL certificate for view.comnpanyname.com on all View Security Servers AND all the DaaS gateway servers.
- Use a wildcard certificate on all the servers
In either case the client is always connecting to “view.companyname.com” so when you flip between Horizon View Servers and DaaS gateway servers, you need the client to be able to authenticate the cert with the same name. The goal here is to make it easy for the end user by not requiring them to change URL’s for their client.
Example Fail Over Video
Summary and Conclusions
My entire goal in life with this very extensive lab setup is simply to prove that you can use vCloud Hybrid Service not only for IaaS, DaaS, and DR…..but most importantly you can pull all the parts together into one enterprise level architecture. Instead of using vCHS-DR on the desktops themselves save yourself time and effort. Focus on the applications for DR along with the infrastructure and just leverage vCHS based desktops in Horizon DaaS to connect to those applications you have failed over.