VMware Hands-on Labs - HOL-1951-05-VWS


Lab Overview - HOL-1951-05-VWS - Horizon Enterprise Security and Troubleshooting

Lab Guidance


Note: It may take more than 90 minutes to complete this lab. You should expect to only finish 2-3 of the modules during your time.  The modules are independent of each other so you can start at the beginning of any module and proceed from there. You can use the Table of Contents to access any module of your choosing.

The Table of Contents can be accessed in the upper right-hand corner of the Lab Manual.

VMware Horizon 7 Enterprise is comprised of multiple products. In this lab, we will review the security configuration of Horizon and some of it's components (UAG and vGPU). We will also cover security best practices and we will look at troubleshooting Horizon View, App Volumes and User Environment Manager. The Horizon troubleshooting will focus mainly on various type of Instant Clones.

Lab Module List:

 Lab Captains:

This lab manual can be downloaded from the Hands-on Labs Document site found here:

http://docs.hol.vmware.com

This lab may be available in other languages.  To set your language preference and have a localized manual deployed with your lab, you may utilize this document to help guide you through the process:

http://docs.hol.vmware.com/announcements/nee-default-language.pdf


 

Location of the Main Console

 

  1. The area in the RED box contains the Main Console.  The Lab Manual is on the tab to the Right of the Main Console.
  2. A particular lab may have additional consoles found on separate tabs in the upper left. You will be directed to open another specific console if needed.
  3. Your lab starts with 90 minutes on the timer.  The lab can not be saved.  All your work must be done during the lab session.  But you can click the EXTEND to increase your time.  If you are at a VMware event, you can extend your lab time twice, for up to 30 minutes.  Each click gives you an additional 15 minutes.  Outside of VMware events, you can extend your lab time up to 9 hours and 30 minutes. Each click gives you an additional hour.

 

 

Alternate Methods of Keyboard Data Entry

During this module, you will input text into the Main Console. Besides directly typing it in, there are two very helpful methods of entering data which make it easier to enter complex data.

 

 

Click and Drag Lab Manual Content Into Console Active Window

You can also click and drag text and Command Line Interface (CLI) commands directly from the Lab Manual into the active window in the Main Console.  

 

 

Accessing the Online International Keyboard

 

You can also use the Online International Keyboard found in the Main Console.

  1. Click on the Keyboard Icon found on the Windows Quick Launch Task Bar.

 

 

Click once in active console window

 

In this example, you will use the Online Keyboard to enter the "@" sign used in email addresses. The "@" sign is Shift-2 on US keyboard layouts.

  1. Click once in the active console window.
  2. Click on the Shift key.

 

 

Click on the @ key

 

  1. Click on the "@ key".

Notice the @ sign entered in the active console window.

 

 

Activation Prompt or Watermark

 

When you first start your lab, you may notice a watermark on the desktop indicating that Windows is not activated.  

One of the major benefits of virtualization is that virtual machines can be moved and run on any platform.  The Hands-on Labs utilizes this benefit and we are able to run the labs out of multiple datacenters.  However, these datacenters may not have identical processors, which triggers a Microsoft activation check through the Internet.

Rest assured, VMware and the Hands-on Labs are in full compliance with Microsoft licensing requirements.  The lab that you are using is a self-contained pod and does not have full access to the Internet, which is required for Windows to verify the activation.  Without full access to the Internet, this automated process fails and you see this watermark.

This cosmetic issue has no effect on your lab.  

 

 

Look at the lower right portion of the screen

 

Please check to see that your lab is finished all the startup routines and is ready for you to start. If you see anything other than "Ready", please wait a few minutes.  If after 5 minutes your lab has not changed to "Ready", please ask for assistance.

 

Module 1 -VMware Unified Access Gateway (30 minutes)

Introduction & Overview


 

VMware Unified Access Gateway (UAG) is a virtual appliance primarily designed to allow secure remote access to VMware end-user-computing resources from authorized users connecting from the Internet. UAG provides this secure connectivity to desktops and applications that are either cloud-hosted through Horizon Air or on-premises in a customer datacenter through VMware Horizon.


 

UAG Introduction Continued

UAG functions as a secure gateway for users who want to access application and desktop resources from outside the corporate firewall. A UAG appliance typically resides within a network demilitarized zone (DMZ) and acts as a proxy host for connections inside your organizations trusted network. This design provides an additional layer of security by shielding VMware Identity Manager, virtual desktops, application hosts, and servers from the public-facing Internet.

UAG directs authentication requests to the appropriate server and discards any un-authenticated requests. The only VMware Identity Manager, virtual desktop, and hosted application traffic that can enter the organizations data center is traffic on behalf of a strongly authenticated user. Users can access only the resources that they are authorized to access.

UAG provides very similar functionality to View security server for Horizon 7 but does not need 1-to-1 pairing with a View Connection Server. UAG is also capable of proxying sessions to other VMware products and providing more advanced security options including authentication in the DMZ. If you are running View security servers, take the time to look at replacing them with UAG appliances.

This portion of the lab will show how the appliance has been deployed into the environment, review the appliance settings in vSphere. Demonstrate how UAG is tied into View Administrator console and configured. Then a walk-through of the steps of a user connecting into the environment with a view client logging into UAG.

This Module contains the following lessons:

 

UAG Appliance Review and Settings in vSphere


This lesson will provide an overview of what Unified Access Gateway is, how its deployed and configured within vSphere.  You will also login to Unified Access Gateway to review various configuration options for the appliance.

Unified Access Gateway is an appliance that is normally installed in a demilitarized zone (DMZ).

Unified Access Gateway is used to ensure that the only traffic entering the corporate data center is traffic on behalf of a strongly authenticated remote user.

Unified Access Gateway directs authentication requests to the appropriate server and discards any unauthenticated request. Users can access only the resources that they are authorized to access.


 

UAG REVIEW CONTINUED

 

 

Deploying Unified Access Gateway

Unified Access Gateway is packaged as an OVF and is deployed onto a vSphere ESX or ESXi host as a pre- configured virtual appliance.

Two primary methods can be used to install the Unified Access Gateway appliance on a vSphere ESX or ESXi host. Microsoft Server 2012 and 2016 Hyper-V roles are supported.

The vSphere Client or vSphere Web Client can be used to deploy the Unified Access Gateway OVF template. You are prompted for basic settings, including the NIC deployment configuration, IP address, and management interface passwords. After the OVF is deployed, log in to the Unified Access Gateway admin user interface to configure Unified Access Gateway system settings, set up secure edge services in multiple use cases, and configure authentication in the DMZ.

PowerShell scripts can also be used to deploy Unified Access Gateway and set up secure edge services in multiple use cases. You download the ZIP file, configure the PowerShell script for your environment, and run the script to deploy Unified Access Gateway.

For the purpose of this lesson the vSphere method will be discussed.

 

 

Deploying Unified Access Gateway Using the OVF

Due to the UAG appliance already being deployed within this lab, the first portion of the lesson will simply review the steps of deploying the OVF into the virtual environment.

You can deploy the Unified Access Gateway appliance by logging in to vCenter Server and using the Deploy OVF Template wizard.

Two versions of the Unified Access Gateway OVA are available, standard OVA and a FIPS version of the OVA. The FIPS 140-2 version runs with the FIPS certified set of ciphers and hashes and has restrictive services enabled that support FIPS certified libraries. When Unified Access Gateway is deployed in FIPS mode, the appliance cannot be changed to the standard OVA deployment mode.

Use the native vSphere Client or the vSphere Web Client to log in to a vCenter Server instance. For an IPv4 network, use the native vSphere Client or the vSphere Web Client. For an IPv6 network, use the vSphere Web Client.

  1. Select a menu command for launching the Deploy OVF Template wizard.
  2. On the Select Source page, browse to the .ova  le that you downloaded or enter a URL and click Next. Review the product details, version, and size requirements.
  3. Follow the wizard prompts and take the following guidelines into consideration as you complete the wizard.
    • Name and Location (Enter a name for the appliance)
    • Deployment Configuration (Here you can select the number of NICs needed for both IPv4 and IPv6)
    • Host/Cluster (Select the host or cluster to deploy to)
    • Disk Format
    • Setup Networks/Network Mapping
    • Customize Network Properties
  4. On the Ready to Complete page, select Power on after deployment, and click Finish.
  5. When deployment is complete, verify that end users can connect to the appliance by opening a browser and entering the following URL:
    • https://uag-01.corp.local (for this lab)

 

 

Log in and Configure UAG appliance

Please follow along within the console for this portion of the lab.

Once the UAG appliance has been deployed you can login to the appliance to review and configure various settings based on use case

 

 

Conclusion

This lesson provided instruction to deploy the UAG appliance with a OAV file and logging into the UAG appliance to review various configuration options.

Moving onto the next lesson will dive deeper into configuring UAG for Horizon.

 

Unified Access Gateway Integration with Horizon Configuration


This lesson will provide you the steps needed to integrate UAG with Horizon View


 

Configure Horizon Settings

Please follow along on the console for this portion of the lab.

You can deploy Unified Access Gateway from Horizon View and Horizon Cloud with On-Premises Infrastructure. For the View component of VMware Horizon, the Unified Access Gateway appliance fulfills the same role that was previously played by the View security server.

 

 

Connect to UAG Admin

 

  1. Click on Horizon folder.
  2. Choose UAG-01 Admin.

 

 

Log in UAG Appliance

 

  1. Login Username: admin
  2. Password: VMware1!
  3. Click Login.

 

 

Change admin password

 

You may have to change the admin password when logging into the UAG appliance.  If that is the case, follow the below instructions.  If not, you can continue to the Configure Manually step.

1. Old Password - VMware1!

2. New Password - VMware2!

3. Confirm New Password - VMware2!

4. Select Change Password

 

 

Confirm Password Change

 

If the password has been successfully changed, you will see "Password is changed successfully".  Please proceed to login to the appliance and provide the updated password

1 . Admin Password - VMware2!

2. Select Login

 

 

Configure Manually

 

  1. Configure Manually and Select

 

 

General Settings

 

  1. In the General Settings > Edge Service Settings line, click Show.

 

 

Horizon Settings

 

  1. Click the Horizon Settings gearbox icon.

 

 

Verify Horizon CONFIGURATION Settings

The Following List of settings can be configured:

 

 

Verify UAG Configuration Settings

 

For the purpose of this lesson verify the following for Horizon integration.

  1. Connection Server URL to https://horizon-01.corp.local
  2. Proxy Destination URL Thumb Prints to sha1=c7 d5 22 ac c0 22 03 49 43 a4...
  3. Enable PCOIP
  4. Enable BLAST
  5. Enable UDP Tunnel Server Enabled
  6. Select Cancel.

 

 

Conclusion

This lesson provided you the steps necessary to integrate the Unified Access Gateway with Horizon.

 

User Demonstration Connecting to Horizon With Unified Access Gateway


This lesson will demonstrate a user logging into the UAG portal through the VMware Horizon Client and the VMware Horizon Web Client.


 

Login with VMware Horizon Client

 

  1. Launch the VMware Horizon Client from the Desktop

 

 

 

CHOOSE UAG CONNECTION

 

  1. Select the Unified Access Gateway uag-01.corp.local server that is already configured for you.

 

 

Login

 

Login to the client by inputting:

  1. User Name: user1mod1
  2. Password: VMware1!
  3. Select Login

 

 

Login to any Available Entitlement

 

  1. You are now logged into the Horizon View environment through the Unified Access Gateway!  You can log into any of the available entitlements presented with the VMware Horizon Client. Close the entitlement you launched and close the Horizon Client.

 

 

Login with VMware Horizon Web Client

 

  1. Select Google Chrome from the Desktop.

 

 

Launch Horizon Web Client

 

  1. In the address bar type https://uag-01.corp.local and hit enter to launch HTML5 web client access via UAG.

 

 

VMware Horizon HTML Access

 

  1. Click on VMware Horizon HTML Access to launch the web client.

 

 

Login to Web Client

 

Login to the web client.

 

 

Login to any Available Entitlement

 

  1. You are now logged into the Horizon View environment through the Unified Access Gateway using the web client!  You can login to any of the available entitlements presented with the VMware Horizon Web Client. Close out when you are completed.

 

 

Lesson Conclusion

This concludes the steps required to login to the UAG appliance through both the VMware Horizon Client and VMware Horizon Web Client.

 

Module 2 - vGPU Configuration (30 minutes)

Module Guidance


The Table of Contents can be accessed in the upper right-hand corner of the Lab Manual.

In this Hands-on Labs Interactive Simulation, you will learn about the different 3D technologies that exist, and considerations for each one.   You will then walk through various stages of the installation and configuration process of setting up vGPU in Horizon 7.1 environment utilizing instant clones, application pools, and our Blast Extreme Protocol.

The module consists of

Horizon Cloud Hosted Infrastructure Overview (15 Minutes - Basic)  - Overview of 3D options in an  Horizon 7 environment (informational only)

NVIDIA Graphics Processing Until (GPU) Manager  VIB Installation (15 Minutes - Advanced) - Walk through installation of a vGPU card on a ESXi 6.5 host

Selecting Virtual Graphic Unit (vGPU) Profile (15 Minutes - Advanced) - Walk through setup and modification of a VM utilizing a vGPU

Creating a 3D Horizon Desktop Pool (45 Minutes - Advanced) Walk through process of creating a Horizon desktop pool configured with a vGPU

Creating a 3D Horizon Remote Application Pool (45 Minutes - Advanced) Prepare RDS host, and deploy an application pool.

 Captain:

Pamela Norris, Staff Technical Account Manager, Chicago, Illinois


 

Location of the Main Console

 

  1. The area in the RED box contains the Main Console.  The Lab Manual is on the tab to the Right of the Main Console.
  2. Your lab starts with 90 minutes on the timer.  The lab can not be saved.  All your work must be done during the lab session.  But you can click the EXTEND to increase your time.  If you are at a VMware event, you can extend your lab time twice, for up to 30 minutes.  Each click gives you an additional 15 minutes.  Outside of VMware events, you can extend your lab time up to 9 hours and 30 minutes. Each click gives you an additional hour.
  3. All work in this HOL Interactive Simulation will take place in the manual.

 

Introduction


Engineers, designers, and scientists have traditionally relied on dedicated graphics workstations to perform the most demanding tasks, such as manipulating 3D models and visually analyzing large data sets. These standalone workstations carry high acquisition and maintenance costs. In addition, in industries such as oil and gas, space exploration, aerospace, engineering, scientific research, and manufacturing, users with these advanced requirements must be in the same physical location as the workstation.

Moving the graphics-acceleration hardware from the workstation to a server provides users with compute, memory, networking, and security advantages. With this data center architecture, users can access and manipulate complex models and very large data sets from virtually anywhere. With appropriate network bandwidth and suitable remote client devices, IT can offer the most advanced users an immersive 3D-graphics experience while freeing them from the limitations of fixed workstations and processors. Fewer physical resources are needed, the wait time to open complex models or run simulations is reduced, and users are no longer tied to a single physical location. In addition to handling the most demanding graphical workloads, hardware acceleration can also reduce CPU usage for less demanding basic desktop and published application usage, and for video encoding or decoding, which includes the default Blast Extreme remote display protocol.

 


3D Desktop Graphics in Horizon


VMware vSphere servers with Horizon 7 hosted in enterprise data centers enable users to access virtual desktops running 3D applications from a wide range of client devices.


 

Virtual Shared Graphics Acceleration

Virtual Shared Graphics Acceleration (vSGA) allows you to share a GPU across multiple virtual desktops. It is an attractive solution for users who require the GPUs full potential during brief periods. However, vSGA can create bottlenecks depending on which applications are used and the resources the applications require. This type of graphics acceleration is generally used for knowledge workers and occasionally for power users.

With vSGA, the hosts physical GPUs are virtualized and shared across multiple guest virtual machines. You must install a vendor driver in the hypervisor. Each guest virtual machine uses a proprietary VMware vSGA 3D driver that communicates with the vendor driver in VMware vSphere. Drawbacks of vSGA are that applications might need to be re-certified to be supported, API support is limited, and support is restricted for OpenGL and DirectX. Supported vSGA cards for Horizon 7 version 7.x and vSphere 6.5 include Intel Iris Pro Graphics P580  NVIDIA Tesla M10/M60/P40.

For a list of compatible vSGA cards, see the VMware Virtual Shared Graphics Acceleration Guide.

 

 

Virtual Shared Pass-Through Graphics Acceleration

Virtual Shared Pass-Through Graphics Acceleration allows you to share a GPU across multiple virtual desktops instead of focusing on only one user. Unlike vSGA, it does not use the proprietary VMware 3D driver, and most graphics card features are supported.

You must install the appropriate vendor driver on the guest virtual machine. All graphics commands are passed directly to the GPU without having to be translated by the hypervisor. On the hypervisor, a vSphere Installation Bundle (VIB) is installed, which aids or performs the scheduling. Depending on the card, up to 24 virtual machines can share a GPU, and some cards have multiple GPUs. Calculating the number of desktops or users per GPU depends on the type of card, application requirements, screen resolution, number of displays, and frame rate, measured in frames per second (fps).

The amount of frame buffer (VRAM) per virtual machine (VM) is fixed, and the GPU engines are shared between VMs. AMD has an option to have a fixed amount of compute, which is called predictable performance.

Virtual shared pass-through technology provides better performance than vSGA and higher consolidation ratios than Virtual Dedicated Graphics Acceleration (vDGA). It is a good technology for low-, mid-, and advanced-level engineers and designers and power users with 3D application requirements. Its drawbacks are the lack of VMware vSphere vMotion support and that the technology might require applications to be recertified to be supported.

Supported shared pass-through cards for Horizon 7.x and vSphere 6.5 include

AMD FirePro S7100X/S7150/S7150X2 (multi-user GPU, or MxGPU)  NVIDIA Tesla M10/M60/P40 (virtual GPU, or vGPU)

For a full list of compatible shared pass-through GPU cards, see the VMware Shared Pass-Through Graphics Guide.

 

 

Virtual Dedicated Graphics Acceleration

Virtual Dedicated Graphics Acceleration (vDGA) technology, also known as GPU pass-through, provides each user with unrestricted, fully dedicated access to one of the hosts GPUs. Although dedicated access has some consolidation and management trade-offs, vDGA offers the highest level of performance for users with the most intensive graphics computing needs.

The hypervisor passes the GPUs directly to individual guest virtual machines. No special drivers are required in the hypervisor. However, to enable graphics acceleration, you must install the appropriate vendor driver on each guest virtual machine. The installation procedures are the same as for physical machines. One drawback of vDGA is its lack of vMotion support.

Supported vDGA cards in Horizon 7 version 7.x and vSphere 6.5 include AMD FirePro S7100X/S7150/S7150X2  Intel Iris Pro Graphics P580/P6300  NVIDIA Quadro M5000/P6000, Tesla M10/M60/P40

For a list of partner servers that are compatible with specific vDGA devices, see the VMware Virtual Dedicated Graphics Acceleration (vDGA) Guide.

 

 

 

 

Comparison of the Types of Graphics Acceleration

 

 

 

HARDWARE REQUIREMENTS

 

This table shows the hardware requirements for graphics acceleration solutions.

 

 

TYPICAL USE CASES

The following are some typical use cases and offer guidelines for the different types of graphics acceleration.

 

 

Knowledge Workers

 

Office workers and executives fall into the knowledge-worker category, typically using applications such as Microsoft Office, Adobe Photoshop, and other non-specialized end-user applications.

Because the graphical load of these users is expected to be low, consolidation is important. These users are best matched with one of the following types of graphics acceleration.

Virtual Shared Pass-Through Graphics Acceleration (MxGPU or vGPU)  When performance and features, such as hardware video encoding and decoding, or DirectX/OpenGL levels, matter most.

vSGA  When consolidation matters most.

 

 

POWER USERS

 

Power users consume more complex visual data, but their requirements for manipulations of large datasets and specialized software are less intense than for designers, or they use only viewers, like Autodesk DWG TrueView.

Power users are best matched with Virtual Shared Pass-Through Graphics Acceleration (MxGPU or vGPU)

 

 

DESIGNERS

 

Designers and advanced engineering and scientific users often create and work with large, complex datasets. They require graphics-intensive applications, such as 3D design, molecular modeling, and medical diagnostics software from companies such as Dassault Systèmes, Enovia, Siemens NX, and Autodesk.

Designers are best matched with one of the following.

• Virtual Shared Pass-Through Graphics Acceleration (MxGPU or vGPU) – When availability or consolidation matters most.

• vDGA – When every bit of performance counts.

 

 

Performance and Consolidation

 

This chart summarizes the performance and consolidation profiles of the three types of graphics acceleration.

 

Choosing a 3D Graphics Acceleration Technology


There are three types of hardware-based graphics acceleration available for View virtual desktops in Horizon 7


 

Choosing a 3D Graphics Acceleration Technology

 

The table compares the main features of the GPU options.  As you can see there is a trade-off between  performance and compatibility.

 

 

Hands-on Labs Interactive Simulation: NVIDIA Graphics Processing Unit (GPU) Manager VIB Installation


In the following section you will walk through the process of installing the NVIDIA Grid Manager VIB for the NVIDIA Grid Tesla M60 care on a vSphere 6.7 host.  

The process will cover

The interactive simulation will allow you to experience steps which are too time-consuming or resource intensive to do live in the lab environment.   We recommend you use Chrome to take the iSIM.

  1. Click here to open the interactive simulation. It will open in a new browser window or tab.
  2. When finished, click the “Return to the lab” link to continue with this lab.

Hands-on Labs Interactive Simulation: Virtual Graphic Processing Unit (vGPU) Profiles


The interactive simulation will allow you to experience steps which  are too time-consuming or resource intensive to do live in the lab  environment.  We recommend you use Chrome to take the iSIM.

  1. Click here to open the interactive simulation. It will open in a new browser window or tab.
  2. When finished, click the “Return to the lab” link to continue with this lab.

 


Hands-on Labs Interactive Simulation: Creating a 3D Horizon Desktop Pool


This part of the lab is presented as a Hands-on Labs Interactive Simulation. This will allow you to experience steps which are too time-consuming or resource intensive to do live in the lab environment. In this simulation, you can use the software interface as if you are interacting with a live environment.  We recommend you use Chrome to take the iSIM.

  1. Click here to open the interactive simulation. It will open in a new browser window or tab.
  2. When finished, click the “Return to the lab” link to continue with this lab.

Hands-on Labs Interactive Simulation: Creating a 3D Horizon Remote Application Pool


In this section, you will

The interactive simulation will allow you to experience steps which are too time-consuming or resource intensive to do live in the lab environment. We recommend you use Chrome to take the iSIM.

  1. Click here to open the interactive simulation. It will open in a new browser window or tab.
  2. When finished, click the “Return to the lab” link to continue with this lab.

Tuning Blast and PCoIP (REFERENCE)


This section will have no associated lab, but will provide some helpful hints and and tips on how to tune both Blast, and PCoIP protocols.


 

TUNING BLAST

 

 

EncoderMaxFPS

 

 

AudioEnabled

 

 

H264maxQP

 

 

H264minQP

 

 

JpegQualityHigh

 

 

JpegQualityMid

 

 

JpegQualityLow

 

 

MinBandwidthKbps

 

 

UdpEnabled

 

 

Tuning PCoIP

Tuning PCoIP for optimal performance requires the administrator to manipulate the display protocol settings so that the session consumes the least amount of bandwidth possible while maintaining a quality user experience. When done properly, the perceived performance of the PCoIP session will improve as the bandwidth demands of the session decrease. To achieve this, the PCoIP session quality must be gradually reduced until an optimal ratio of quality and performance are achieved. Many settings are available to influence image quality, frame rate, audio, protocol throttling, etc. Even a minor, inperceivable quality reduction can have significant performance benefits. This methodology is relevant on both high performance, local area networks and highly constrained wide area networks.

HKLM\SOFTWARE\Policies\Teradici\PCoIP\pcoip_admin_defaults

C:\ProgramData\VMware\VDM\logs

The “pcoip_server” log file contains display performance and diagnostic information. Every time a user connects to a virtual desktop, a new pcoip_server log file will be created. Since these log files are suffixed by the date and a hexadecimal string, it may be helpful to sort these files by date making it easier to pick out the latest one.

 

 

pcoip.event_filter_mode

 

 

pcoip.maximum_frame_rate

 

 

 

pcoip.maximum_initial_image_quality

 

 

pcoip.minimum_image_quality

 

 

pcoip.use_client_img_settings

 

 

pcoip.enable_audio

 

 

pcoip.device_bandwidth_floor

 

Module 3 - Horizon Instant-Clone Troubleshooting & Operations (45 minutes)

Introduction


In this module we will dive deeper into troubleshooting Horizon Instant Clones, .  


 

What Is Horizon Instant Clone Technology?

Horizon Instant Clone Technology is all about delivering VDI desktops just in time. Horizon Instant Clone Technology allows administrators to rapidly clone and deploy a virtual machine in less time than it took for you to read these two sentences. Yes, that is one clone created every 3-5 seconds. Horizon Instant Clones(IC) is the ultra-fast part of the Just in Time(JIT) desktop.

 

 

Anatomy of an Instant Clone


Horizon instant-clones introduce a number of new objects in vCenter: replicas, parents, and templates. It is important to understand not only how these are structured, but also their interrelationships, in order to troubleshoot your environment accordingly


 

Understanding Horizon instant-clone objects: replicas, parents, and templates.

 

 

 

Instant-Clones in HOL

All the IC vm's for this lab are built in vCenter under cluster RegionA01-IC01 and that cluster contains one host named esxi-04a.corp.local which for the purposes of this lab is considered our VDI workload domain. So lets get started by logging into vCenter to see how things are setup from a Horizon IC perspective.

 

 

Open Chrome Browser from Windows Quick Launch Task Bar

 

  1. Click on the Chrome Icon on the Windows Quick Launch Task Bar.

 

  1. Click Use Windows session authentication to login to vCenter.
  2. Click Login

 

 

vCenter IC cluster

 

  1. Click Hosts and Clusters icon
  2. Click RegionA01-IC01 Cluster

In Horizon we have created two pools. RDSH1 is part of a Windows 2012 RDSH farm and Win10IC-1 & 2 is a IC Desktop pool that was configured for this lab.

 

 

Master VM

With instant-clones you start with your master image, in a way that is similar to linked clones. The master image is the VM you install the operating system on, then join to the domain, and install user applications on; you follow the same OS optimizations procedures you would use for Linked Clones.

When you’re ready to create the IC pool, release its IP address, shut it down, and create a snapshot. This Master VM should have VM Tools installed, along with the Horizon Agent with the instant-clone module. It could also have other agents like AppVolumes and UEM.

It is NOT possible to have the instant-clone and composer modules co-installed, so you will always need different snapshots if using instant-clones and linked clones from the same master image.

 

 

Master VM's for the our instant-clone pools

 

For this lab we have two master VM's for the two IC pools we have setup as part of the lab.

base-RDS-01 is the Master VM for our IC RDSH Farm it is a full thin provisioned copy of the Windows 2012 R2 with RDSH services enabled.

base-w10-1709-x64-01 is the Master VM for our IC Desktop pool and is a full thin provisioned copy of Windows 10 with the Horizon Agent Instant Clone feature turned on.

 

 

Master VM snapshots

As part of the instant-clone provisioning process we need a snapshot of the current state of the Master VM we want to deploy. So lets take a look at the IC Desktop Master VM.

 

 

  1. Right-click the base-w10-1709-x64-01 under RegionA01-IC01
  2. Click Snapshots
  3. Click Manage Snapshots

Note this Master VM is a Windows 10 x64 machine and we have created a IC-Pool1 in Horizon from this VM.

 

 

Master VM Snapshot

 

Here you see the snapshot used to create the IC Desktop pool. When you configure the IC pool settings you pick a snapshot from the Master VM to create the IC-Pool from. This sets up the next stage of the Instant Clone structure, the CP-Template which is created as part of the Horizon Instant Clone priming process

 

 

 

Close snapshot manager for IC

 

  1. Click DONE to close the Snapshot Manager

 

 

CP-Templates

When you create an Instant Clone pool, Horizon will create a protected internal template VM. The instant-clone engine uses the master VM snapshot that you specified to create one internal template VM on the same datastore as the master VM. It will have the name cp-template-guid, and will be automatically placed in the folder ClonePrepInternalTemplateFolder.

The system performs a domain join on this internal template VM, which ensures that all the proper Windows registry keys and settings are correctly populated. This process involves a reboot.

 

  1. Click on one of the cp-template vm's listed under RegionA01-IC01 Cluster.

Note that there are two cp-template vm's in the view above because we have both a IC Desktop pool configured in this lab and a IC RSDH Farm. Because there are two pools of IC's based on two different Master VM we have two cp-template vm's.

 

 

CP-Template properties

 

  1. Right Click on one of the BP-template VM's above.
  2. Select Power from the list
  3. Note that no power operations can be performed on this VM.
  4. Also note that many other VM operations cannot be performed such as Edit Settings for the VM, Remove from inventory, Migrate VM and others are all greyed out.

 

 

CP-Replicas

After the CP-Template vm is created and joined to the domain, Horizon will create a replica, which is the same as a Linked Clone replica. It is a thin-provisioned, full clone of the template VM. This will serve as the common read disk for all of your Instant Clones, so it can be tiered onto appropriate storage through the Horizon Administrator console, the same way it is done with Linked Clones. Of course, if you are using VSAN, there is only one datastore, so tiering is done automatically. Horizon will also create a CBRC Digest file for the replica. The replica will be called cp-replica-GUID and will be in the folder ClonePrepReplicaVmFolder. The disk usage of the replica will be depend on how big your Master VM is, but remember, it’s thin provisioned and not powered on, so you will not have VSwap file.

 

  1. Click on one of the cp-replica vm's listed under RegionA01-IC01 Cluster

 

 

Access the Datastore

 

Lets take a look at how the cp-replica looks when it is deployed on the datastore.

  1. Click Datastores
  2. Click the ESX04a-Local datastore

 

 

Access the datastore files

 

  1. Click on Files
  2. Click on the Expand icon

 

  1. Click on of the cp-replica folders

Note that the replica has a digest disk, since this is the disk that all instant clones use for read operations this ensures that all IC vm's can take advantage of the Content Based Read Cache(CBRC)

If you have multiple datastores that support a pool of VM's you will find a cp-replica on each of those datastores.

  1. Close the Datastore view window.

 

 

Return to Hosts and Clusters

 

  1. Click on Hosts and Clusters to return to our view of RegionA01-IC01 cluster.

Next lets look at cp-parent VM's.

 

 

CP-Parent VM's

Horizon will create the a final copy of the original VM, called a parent, which will be used to fork the running VMs. The parent is created on every host in the cluster; remember, we are forking running VMs here, so every host needs to have a running Parent VM. These will be placed on the same datastore as the desktop VMs, where there will be one per host per datastore. Because these are powered on, they have a VSwap file the size of the allocated vMEM. In addition, there will be a small delta disk to capture the writes booting the parent VM and the VMX Overhead VSwap file, but this—and the sum of the other disks—is relatively small, at about 500 MB. These will be placed in ClonePrepReplicaVmFolder.

 

 

Where are the CP-Parents?

 

If you have just started this lab and have not taken the other modules that make changes to the IC pools you might be wondering where the CP-Parent VM's are? In the view above we see the Master VM's, the cp-templates, the cp-replica's, and even some deployed Instant clone VM's but no cp-parents? Why would this be?

 

 

CP-Parents where are they?

The reason there are currently no cp-parent VM's is because the parent VM's are only used to during VM fork operations and running IC VM's do not have any connection to the parents after the initial fork operation. This is why during host maintenance mode operations the cp-parents can be deleted. Parent VM's are only recreated when a new IC is needs to be deployed on a host.

Instant clone creation requires that parent VMs are created on all hosts in the selected cluster. The parent VMs are tied to the host they are on and cannot be migrated through the vSphere client. Since Horizon 7.1 if you put a host into maintenance mode, as we did to prepare this lab, the cp-parent VM's are automatically deleted.

Putting a host into maintenance mode is a good first step to see if there are any issues with the IC's deployed to that host.

 

 

Getting a cp-parent to deploy

 

Lets see if we can get a cp-parent to deploy in the lab.

  1. Right click on WIN10IC-2
  2. Select Power
  3. Select Power Off

 

 

Delete WIN10IC-2

 

  1. Right click on WIN10IC-2
  2. Select Delete from Disk

 

 

New cp-parent and Windows 10 Instant-Clone

 

Once the WIN10IC-2 VM is removed, monitor the Recent Tasks and watch the VM list in the RegionA01-IC01 cluster and within a minute or two you should see a new powered on cp-parent automatically deploy and shortly after that you should see a replacement WIN10IC-3 vm deploy and power up. The task "Instant Clone virtual machine" is the actual point that the vmfork operation is done and the instant-clone is created from the parent VM.

 

 

Instant-Clone VMs

After the running parent VMs are created, the provisioning of instant-clones can begin.

Instant-clones use copy-on-write for memory and disk management.

The instant-clone engine performs the following tasks to create instant-clones:

  1. The engine brings the running parent VM to a quiescent, or quiet, state and then forks it using the vSphere vmFork technology. The forking process is like creating two similar branches of development so that disk and memory can be shared.
  2. The engine customizes each forked instant-clone. This ClonePrep process performs the following customization tasks, all without requiring a reboot:
    • Changes the IC machine name.
    • Gives the VM a unique MAC address.
    • Changes the Active Directory password.
    • Joins the machine to the Active Directory domain.
    • This domain join does not require a reboot because the associated internal template VM was already joined to the domain and rebooted during the publishing process described earlier.
    • Activates the Microsoft license.

The provisioning process does not require power operations, and the clones are forked from a running parent VM, so the process takes only a couple of seconds.

 

 

Instant-Clone VM's in this Lab

 

In this lab there are normally three instant-clone VM's. RDSH1 is a instant-clone of a Windows 2012 R2 server configured as part of a RDSH farm in Horizon.

The two WIN10IC-# machines are instant clones that are part of a Windows 10 desktop pool in Horizon.

Instant-clone VM's can be migrated to other hosts in the cluster but in this lab we only have one host in the RegionA01-IC01 cluster so we don't have another host to migrate or deploy instant-clones too.

 

 

Conclusion

In this chapter we learned about the structure of a Horizon instant-clone. Instant Clones introduce a number of new objects: replicas, parents, and templates. Knowing how the different IC objects interrelate is important to be able to troubleshoot when issues arise.

At the top of the list of benefits of Instant Clone Technology is simplified deployment and patching for administrators. Instant clones do not need to be refreshed, recomposed, or rebalanced. When a user logs out of the desktop, that desktop always gets deleted and recreated as a fresh image from the latest patch. This process creates a staggered approach to patching, thus eliminating “boot storms,” reducing storage IOPS, and creating less of a load on the vCenter Server.

Instant Clone Technology does not need a separate SQL database, which greatly simplifies the Horizon 7 architecture. This also helps to lower the overall support cost of the solution, and reduces the complexity of future environment upgrades.

 

Instant-clone maintenance operations & troubleshooting tools


In this chapter we will review IC maintenance operations and some useful tools to use when things get out of sync between Horzon and vCenter server.


 

Host Maintenance mode operations.

One of the most frequent things you will have to do when working with instant clones is to put your host into maintenance mode  to either reboot a host or patch a host.  

With the parent VM's on these hosts running and in a protected state you can't just power off a parent VM and parent VM's cannot use vMotion.

Since Horizon 7.1 and above if you put a host into maintenance mode all parent VM's should be deleted from the host.

Let's see what that looks like in our lab.

 

 

Open Chrome Browser from Windows Quick Launch Task Bar

 

  1. Click on the Chrome Icon on the Windows Quick Launch Task Bar.

 

  1. Click Use Windows session authentication to login to vCenter.
  2. Click Login

 

 

vCenter IC cluster

 

  1. Click Hosts and Clusters icon
  2. Click RegionA01-IC01 Cluster

In Horizon we have created two pools. RDSH1 is part of a Windows 2012 RDSH farm and Win10IC-1 & 2 is a IC Desktop pool that was configured for this lab.

 

 

IC Parent VM

 

If you just completed the last section of this lab called Anatomy of an Instant Clone you should also see a cp-parent-guid protected VM in the list of VM's on the RegionA01-IC01 cluster.

Note: If you just started this lab and skipped directly to this section you my need to refer back to the previous section called CP-Parents where are they? to get the cp-parent vm's to deploy.

 

 

Put a host into Maintenance Mode

 

  1. Right click esx-04a-corp.local host
  2. Select Maintenance Mode
  3. Click Enter Maintenance Mode

 

 

Confirm Maintenance Mode

 

  1. Click OK to confirm you want host esx-04a-corp.local to go into Maintenance Mode

 

 

Powered on VM's Warning

 

  1. Click OK to safely ignore this warning.

The host will not be able to go all the way into maintenance mode because in this lab we do not have another host to vMotion the IC's too, we could just power off the VM's running on this host and it would go into Maintenance mode.

However in the next step we will just cancel the maintenance mode operation because the cp-parent VM's have already been deleted.

 

 

Cp-parent vm's removed events

 

Take a look at the Recent Tasks list.

Note that the cp-parent VM's were:

  1. Powered off and
  2. The cp-parent VM's were deleted.
  3. Click the gray X button to cancel the Maintenance Mode operation on the host.

This will cancel the maintenance mode operation on the host so that we dont have to power down the vm's.

Will the Instant Clone parent vm's automatically redeploy to the host?

 

 

 

When do Instant Clone parents automatically deploy?

 

Currently Instant Clone cp-parents automatically deploy when a host needs one to deploy new instant clones. So as provisioning operations occur on a host it will automatically deploy a new parent VM to be used for Instant Clone/VMfork operations, if one is not currently available.

The fact that Horizon desktops are parentless is the reason why we can continue to run live instant clones without a live cp-parent VM on a host.

 

 

Maintenance Mode Operations Summary

 

If you have followed along from the beginning your RegionA01-IC01 cluster probably looks similar to above.

Note that all the WIN10IC VM's on this host are still running even though their are no cp-parent vm's.

Hosts running instant-clones can be easily put into maintenance mode by initiating a maintenance operation and waiting for the cp-parents to be removed. Also in a cluster with additional hosts the remaining running instant-clone VM's can be vMotioned to another host or powered off to complete host maintenance operations.

Note: that with Horizon 7.1 and above initiating maintenance mode on a host automatically removes cp-parent vm's. If your still running a version below Horizon 7.1 you will need to use the IC-Maint utility.

 

 

IC-Maint Utility

The IC-Maint.cmd is a utility that is provided as part of a Horizon Connection server installation. This command deletes the parent VMs and optionally puts a host in IC maintenance mode. After performing maintenance, you can run this command to take a host out of IC maintenance mode.

The utilities are IcMaint.cmd are located in C:\Program Files\VMware\VMware View\Server\tools\bin. on the Horizon connection server.

 

RDSH Farm Instant Clone Maintenance


This section uses Horizon Console (https://horizon-01.corp.local/newadmin) to perform Instant Clone Maintenance.

Let take a couple minutes to look at our RDSH Farm and see how its configured.


 

Start Horizon Console - New Tab

 

  1. Click New tab in the browser
  2. Click the VMware JMP shortcut

 

 

Login to Horizon Console

 

  1. Type administrator for User Name
  2. Type VMware1! for the password
  3. Make sure the domain is CORP
  4. Click Sign In

 

 

New Horizon Console interface

 

  1. Click Farms under the Inventory Menu
  2. Click on the RDSH-01 Farm

Let take a look at how we schedule the IC Farm Maintenance. Farm maintenance can help reduce problems with your RDSH farm by ensuring your hosts always run a clean copy of your Master VM image.

 

 

RSDH-01 Farm Maintenance

 

  1. Click the Maintain drop down menu
  2. Click Schedule

 

 

Schedule Recurring Maintenance

 

This is the where you schedule maintenance operations on a RDSH server farm.

  1. Note that you can set the Effective start date for the maintenance operation
  2. You can also set if the operation occurs Daily, Weekly, or Monthly
  3. Finally you can the repeat internval for the maintenance operation.

 

 

Select the Immediate option

 

For the lab we will schedule Immediate Maintenance

  1. Click the drop down list where it says Recurring
  2. Change to Immediate

 

 

Schedule Immediate Maintenance

 

Use the Immediate Maintenance Schedule to push an emergency patch to your RDSH server farm. For this lab we will schedule a immediate maintenance operation on the farm to refresh the RDSH-01 host with the our base image.

  1. Click Start Now
  2. Click Next

 

 

Select an Image

 

At this point we select the image that we want to use to refresh the RDSH farm. This is the point that you could switch to a different snapshot for your RDSH farm but for this lab we are going to stick with the current parent VM image.

  1. Make sure Use current parent VM image is checked
  2. Click Next

 

 

 

Schedule Maintenance Settings

 

The Schedule Maintenance setting screen is where you choose to either Wait for users to log off a RDSH host to minimize the impact of a scheduled reboot to the end users or if you need to force an update right now the option to Force users to log off is a good option. For this lab we will use the Force users to log off option.

  1. Choose Force users to log off
  2. Click Next

 

 

Ready to Complete

 

The Ready to Complete screen provides a summary of the Maintenance Operation.

Things to review are:

  1. Number of RDSH hosts impacted by this change: 1
  2. Start Time of the scheduled maintenance: NOW
  3. User log off now or wait for user to logoff: Force users to log off
  4. Parent VM in vCenter: base-RDS-01
  5. Image: AppVolAgentInstalled *
  6. Click Finish

* AppVolAgentInstalled is the current snapshot for this RDSH pool since we just "refreshing" the pool with the current parent image.

 

 

 

 

After the maintenance operation completes you should see that the IC engine has deleted the original RDSH1 host and replaced it with a fresh instant clone. You may also have had to wait for a new cp-parent to be created for the RDSH pool if you recently tried to enable Maintenance mode on a host.

 

Conclusion


This module showed you how Horizon Instant-Clones can be used in your environment. It demonstrated how Instant Clones are deployed, and how to do various instant-clone maintenance tasks.


 

Congratulations, you've finished Module 3

 

 

If you are looking for additional information on Instant Clones, try one of these:

Proceed to any module below which interests you most.

 

 

How to end your Lab

 

1. To end your lab, click on the END button.

 

Module 4 - App Volumes Troubleshooting (60 minutes)

Introduction


In this module we will dive deeper into troubleshooting VMware App Volumes.  


 

What is VMware App Volumes?

 

VMware App Volumes is a real-time application delivery system that IT can use to dynamically deliver and manage applications. 

 

This module will be covering troubleshooting of Manager and Agent components of App Volumes. It will cover the point of interaction between App Volumes, Active Directory and SQL Database. It will also help you gain hands-on experience with the solution.  If you would like a general overview of App Volumes, please take lab HOL-1951-02-VWS - Horizon Getting Started.


 


We will show you the difference between a "live/instant" attachment and one done at next reboot or login.

We will also cover the AppStacks update process, best practices and what to look for.

 

App Volumes Manager Troubleshooting


Enterprises can use App Volumes to build real-time application-delivery systems that ensure applications are centrally managed. Applications are delivered to desktops through virtual disks. With the App Volumes solution, you do not need to modify desktops or applications themselves, and you can scale out easily and cost-effectively, without compromising end-user experience.

In modern desktop environments, the demand for real-time application delivery often puts strain on existing infrastructures. Through App Volumes, VMware addresses this strain by virtualizing applications above the operating system (OS) and by offering an alternative to managing per virtual machine.


 

How App Volumes Manager Interacts with Other Components

Applications virtualized above the OS are delivered as if natively installed—without modification, in various configurations, to multiple groups of users. And, through file and registry virtualization, applications are organized into application management containers. This arrangement uses existing storage and networking services, reduces infrastructure strain and overhead, and simplifies application life-cycle management.

Administrators use the App Volumes Manager, a Web-based interface integrated with Active Directory (AD) and VMware vSphere®, to create AppStacks and assign application entitlements. Application installations recorded in AppStacks are stored in shared volumes across virtual disks. These applications require no special packaging formats or snapshot technologies and are easy to provision. During provisioning of AppStacks, App Volumes intelligently records the entire application-installation process, and the changes made by the native application installers are available for delivery to users.

Administrators can easily deliver provisioned AppStacks to an individual system, a user, or a group. Applications delivered by App Volumes look and feel natively installed, and they follow users across sessions and devices, as can data, at the administrator’s option. Administrators can update or replace applications in real time and remove any assigned application, either immediately, while the user is still logged in, or, in accordance with VMware best practices, at next login or reboot.

 

 

App Volumes Components

 

The App Volumes Manager solution is installed on a Windows Server. Windows Server 2012 R2 and above is recommended for your deployment.

As you can see from the image, there are several components that make up the App Volumes Manager server.

All administrative work is done through the Web interface but behind the scenes, there is a Load-Balancer handling request (NGINX) and sending/receiving command through a set of API's.

Schedulers and Workers are an intricate part of how App Volumes works and we will cover the functionality of each in the following section.

All ports can be customized during or after installation.

 

 

A closer look at the App Volumes Manager Installation

The App Volumes Manager service is started on machine boot. The configuration information for the server is read from both registry and file locations.

Registry entries are read from HKEY_LOCAL_MACHINE. We will explore the specific hives in the following steps.

There are also a few additional files that are read when the service starts.

Let's take a look at the configuration information.

 

 

Remote Desktop Connection to App Volumes Manager

 

From the Control Center

  1. Open the App Volumes Manager RDP connection
  2. Enter the password for the administrator, "VMware1!"
  3. Click on Connect or press Enter

 

 

Open Regedit.exe

 

Once you have connected to the App Volumes Manager RDP session, you will need to open the Registry Editor.

  1. Click on the Windows Button at the bottom left of the screen
  2. Start typing regedit.exe
    You will see the application show up in the search window after you start typing the first couple of characters
  3. Select regedit.exe

 

 

Navigate the Registry

 

  1. Navigate the registry by expanding the hives:
    HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\CloudVolumes\Manager
  2. Close the Registry Editor
    We will not make any changes to the current App Volumes Manager installation.

The HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\CloudVolumes\Manager hive contains configuration information for the App Volumes Manager.

If you need to troubleshoot or change any of the information here, please keep in mind that you will need to restart the App Volumes Manager service to apply the changes.

 

 

Open Windows Explorer

 

  1. Select the Windows Explorer icon from the taskbar of AppVol-01

 

 

Open Clock.yml

 

 

The next file we will look at is the Clock.yml file.

  1. Navigate to the Manager configuration directory:
    C:\Program Files (x86)\CloudVolumes\Manager
  2. Right-Click on the clock.yml file
  3. Choose to Edit with Notepad++

Note: Leave the Windows Explorer window open.

This file contains configurations information for the Manager as it relates to the numbers of Workers and Schedulers running on a particular manager and also Background Jobs running on that server.

You can go to this White Paper for more information on both: App Volumes Database Best Practices.

 

 

Review Clock.yml

 

  1. Once the file is opened, look for the section containing a hashtag: # default. In our lab, the medium configuration section is active right now.

You can see that the current configuration is for:

Again, for recommendation on sizing, depending on the size of your deployment, you should refer back to the App Volumes Database Best Practice guide.

 

 

Changes to Clock.yml

There may be a specific situation in your deployment where you need to modify the number of servers or workers for your App Volumes Manager server.

There might also be situation where you need to change the frequency at which the background jobs run.

Changing background job frequencies is only done for advanced troubleshooting and is always done with VMware support. If you need to change the frequency of a background job, please contact VMware support.

 

 

Modify Clock.yml

 

For this lab, we will make two modifications to the clock.yml file:

  1. Change the number of Servers to 2.
  2. Change the frequency of Active Directory synchronization by adding the line:
    "sync_ad: 12:00:00"

 

 

Save and Close Clock.yml

 

  1. Click the disk icon to save changes
  2. Click the X to close Notepad++

After the changes to the Clock.yml file are done, you need to restart the App Volumes Manager Service for these changes to take effect.

To be able to see the changes in action, we will copy and open Process Monitor before restarting the service.

 

 

Copy ProcessMonitor.zip

 

You should still have a Windows Explorer window open in the remote desktop session for App Volumes Manager. If not, open Windows Explorer from the taskbar.

  1. Navigate to: \\ControlCenter\c$\Tools
  2. Right-Click on the file ProcessMonitor.zip
  3. Choose Copy

 

 

Paste ProcessMonitor.zip

 

  1. Navigate to C:\Tools (this is the local C:\ of the App Volumes Manager)
  2. Right-Click the blank space in the folder
  3. Choose Paste

 

 

Extract ProcessMonitor.zip

 

  1. Right-Click ProcessMonitor.zip
  2. Choose Extract All...
  3. Choose Extract

 

 

Open Process Monitor

 

  1. Double-Click Procmon.exe

 

 

Security Warning

 

  1. Choose Run

 

 

Accept License Agreement

 

  1. Choose Agree

Since this is the first time this application is opened in the lab, you will see the Process Monitor License Agreement.

We will now use Process Explorer to see the process running after we restart the App Volumes Manager Service.

 

 

Review Process Tree

 

The last step in ProcMon is to look at the Process Tree.

  1. From Process Monitor, choose Tools
  2. Choose the Process Tree... option

We will leave Process Monitor Running and restart the services.

 

 

Navigate to Administrative Tools

 

  1. Click the Windows Start button
  2. Type Administrative Tools
  3. Choose Administrative Tools from the list

 

 

Open Services

 

  1. Double-click Services

 

 

Restart App Volumes Manager Service

 

  1. Right-click App Volumes Manager
  2. Choose Restart

 

 

Navigate to the Process Monitor Process Tree

 

  1. Once the service is restarted, switch back to the running Process Monitor window
  2. Scroll down and select CVManager.exe

 

 

Select Ruby.exe

 

  1. Locate and select the first ruby.exe entry below CVManager.exe
  2. Note the command that ends with ... clock.rb

This is the line that reads the data within the clock.yml file. Since we changed the number of servers to 2, it will launch 2 servers processes instead of 4 (the default).

 

 

NGINX

 

 

The nginx process is the load-balancer internally used by App Volumes Manager.

  1. Locate the nginx.exe entries
  2. Select the first occurrence of cmd.exe following nginx.exe
  3. If you look at the command, you will see that it has started a web listener on port 3001.
  4. Click on the following cmd.exe and you will see another web listener, listening on port 3002.

These are the 2 server processes that are load-balanced by the nginx process.

 

 

App Volumes Log levels

When working with VMware support, you might be asked to change the log levels of your App Volumes Manager server.

This is extremely useful when troubleshooting an issue but you should keep in mind that this will make the logs grow much faster and should only be done when troubleshooting a problem.

Since you are still in the Remote Desktop session for the App Volumes Manager server, we will show how to change this setting.

This is a lab environment, if you were going to do this for your own environment, we recommend to copy and save the file as a backup precaution before making any changes.

 

 

Realtime Request and Background Jobs

App Volumes Manager logs contain a wealth of information but reading those logs might be hard at first.

In this section, we will run a couple of commands and look for the corresponding information in the logs.

 

App Volumes Agent Troubleshooting


VMware App Volumes uses an agent on the Virtual Desktop. That agent is a mini-filter driver that virtualizes files, folders and registries.

The agent receives commands from the manager and handles merging of files and registry entries.

You install an agent on your provisioning desktop and on all target desktops where you plan to use App Volumes


 

App Volumes Agent overview

 

1. The App Volumes agent is a minifilter driver. Microsoft uses a concept of altitudes for filter drivers. The concept is the larger the number the "higher" the altitude. Minifilter drivers can only see other filter drivers that are at a higher altitude.  The actions done at a lower altitude are not able to be seen by filterdrivers operating at a higher level.

2. The lower number minifilter drivers are the first to interact with a request from the OS or other applications. Generally speaking the requests are then given to the next minifilter driver in the stack (next highest number) after the first is finished processing the request. However this is not always the case as some minifilter drivers may not release the request and "close" it out to the OS or application. In this case the other minifilter driver would never have seen the request at all. If this happens with an application running at a lower altitude than App Volumes, then the App Volumes minifilter driver would never get a chance to process the request, and thus would not be able to virtualize the I/O as expected.

3. Legacy file system filter drivers add additional complexity in that they can attach only to the top of an existing file system driver stack and cannot attach in the middle of a stack. As a result, interaction with App Volumes can get interrupted because the legacy drivers will be loaded at a higher level in the stack.

This is the primary reason certain applications that use a minifilter driver should be disabled or removed from the OS while installing applications with App Volumes and vice versa. There might be additional scenarios where App Volumes should be disabled allowing other applications to install correctly in the base OS.

 

 

Taking a closer look at driver altitudes

In this section we will use fltmc to review driver altitudes.

 

 

Launch VMware Horizon Client

 

  1. From the Main Console, open the VMware Horizon Client

 

 

Connect to Horizon-01

 

  1. Connect to the Horizon-01.corp.local environment

 

 

Authenticate to Horizon Client

 

Login to the client

  1. User name: Administrator
  2. Password: VMware1!
  3. Choose Login

 

 

Launch Instant Clone Pool

 

  1. Choose the Instant Clone Pool

 

 

Open PowerShell

 

  1. Right-Click on the Windows Start Menu
  2. Choose Windows PowerShell (Admin)

 

 

Run fltmc

 

  1. Type the command: fltmc

You will see that the App Volumes agent, called svdriver, has an altitude of 190000.

You will also see that other filter drivers are loaded on the Windows 10 desktop.

You might encounter a situation where AppStacks are not loading on the Virtual Desktop. If this happens, one of the reason might be that a competing filter driver is blocking the App Volumes Agent.

Software like Anti-virus or DLP (Data Leakage Prevention) might interfere with the App Volumes driver.

It is very important to know what exclusions needs to be put in place and VMware has a guide on this, it's called the Antivirus Considerations in a VMware Horizon 7 Environment. It contains information on Horizon, User Environment Manager and App Volumes.

Microsoft owns and assigns driver altitude to software vendors. You can read more information about this on the Microsoft site, Load Order Groups and Altitudes for Minifilter Drivers.

 

 

Unloading a driver

When troubleshooting a driver conflict, one of the quick test is to unload that driver and see if it resolves the issue.

In the case of App Volumes not mounting an AppStacks, what you could do is unload the competing driver that is sitting at a higher altitude and see if it mounts the AppStacks.

In this lab, we will unload the App Volumes driver because we do not have any Anti-Virus installed but in your own environment, you would unload the culprit driver.

 

  1. Run the command: fltmc unload svdriver
  2. Then type fltmc on it's own to see the list of remaining drivers

You will notice that svdriver is not present.

 

In a real-life troubleshooting, you would do something similar but with the competing driver.

For example, Trend Micro Anti-Virus driver is called "tmevtmgr" or one of the McAfee Anti-Virus driver is called "masvc"

So, the commands would be: flmtc unload tmevtmgr or fltmc unload masvc.

 

 

Change the Altitude

 

  1. Click on the Windows Start Menu
  2. Type regedit
  3. Choose regedit

 

 

Modify the Registry

 

  1. Navigate to: Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\svdriver\Instances\App Volumes Instance
  2. You will see the Registry key called Altitude, with a value of 190000.

Another possible troubleshooting step for the agent would be to change the altitude of the App Volumes Driver, putting it higher or lower than the competing driver that is causing the problem.

We will not be modifying the altitude in this lab.

Stay in the Registry Editor for the next steps.

 

 

Registry

 

  1. Navigate to: Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\svservice\Parameters

You will see the values used by the agent. Those values were set when the Agent was installed. If, for any reasons you need to modify these values, please keep in mind that the service needs to be stopped before modifying these values.

You can now close the Registry Editor.

 

 

Agent Logs

There are three App Volumes agent logs.

svservice.log and svdriver.log are on end point devices with the App Volumes agent installed.

svcapture.log is only present on capture or provisioning VMs.

 

 

Open Windows Explorer

 

  1. Select the Explorer tab from the system tray.

 

  1. Navigate to C:\Program Files (x86)\CloudVolumes\Agent\Logs
  2. Double-click svservice

 

 

Review svservice.log

 

This log contains useful information about the virtualized desktop interaction with App Volumes. This log is very useful and when troubleshooting a Desktop issue, it should be inspected in correlation with the App Volumes Manager Server logs.

 

Active Directory and SQL Troubleshooting


VMware App Volumes uses Active Directory as it's authoritative user directory. When you initially setup App Volumes, you need to establish a connection with an Active Directory Domain. To be able to complete the initial setup, you need a successful connection to a Global Catalog server, in the domain you are connecting to.

In this lab, we have already completed this step for you but we will take a look at the information and talk about common errors when setting this up.


 

Launch Chrome Browser

 

  1. From the Desktop of the Main Console, double-click Google Chrome

 

 

Looking at AD Configuration

 

  1. Click on the App Volumes Folder
  2. Choose AppVol-01

 

 

Login to App Volumes Manager

 

  1. Enter the Username: Administrator
  2. Password: VMware1!
  3. Click on Login

 

 

Navigate to AD Domains

 

  1. Click on the Configuration Tab
  2. Click on AD Domains
  3. Expand the corp.local domain
  4. Click on Edit

 

 

Review AD Configuration

 

You can see in this section that we have not specified a Domain Controller host. App Volumes, leveraging AD Sites and Services, will find the Domain Controller the closest to it. If you specify a Domain Controller, we would recommend that you specify at least two. If one of the domain controller fails, you will have a backup. If Domain Controllers are specified, App Volumes will not search for any other than the one specified in that field.

A common mistake when people setup App Volumes for the first time is to leave the default value for security (Secure LDAP (LDAPS)) but their Active Directory is not setup to support that method of connectivity.

 

 

Database Information

Another configuration point for App Volumes is the Database. App Volumes works with a SQL Database. In a pilot or test environment, you can use SQL Express. By default, App Volumes will offer you to install a SQL Express 2014 database, on the same server where you are installing it. For a production deployment, you should always use a separate SQL Server.

 

 

Remote Desktop Connection to App Volumes Manager

 

From the Main Console

  1. Open the App Volumes Manager RDP connection
  2. Enter the password for the administrator: VMware1!
  3. Click on OK

 

 

Open Windows Explorer

 

  1. Select the Windows Explorer icon from the taskbar of AppVol-01

 

 

Navigate to Configuration Folder for the Database

 

The next file we will look at is the Clock.yml file.

  1. Navigate to the Manager configuration directory:  C:\Program Files (x86)\CloudVolumes\Manager\config
  2. Right-Click on the database.yml file
  3. Choose to Edit with Notepad++

Note: Leave the Windows Explorer window open.

 

 

Validating Database connection information

 

We will not be making changes to this file in this lab but it is important to note the DSN (Data Source Name). This information needs to match the ODBC connection information on the App Volumes Manager server. We will validate that both information match in the next steps.

 

 

Administrative Tools

 

  1. Click on the Windows Start Menu and choose the Administrative Tools icon

 

 

ODBC

 

  1. Double-click ODBC Data Sources (64-bit)

 

 

Validate ODBC connection

 

  1. Choose the System DSN tab
  2. Choose svmanager 64-bit
  3. Click on Configure

 

 

SQL Configuration information

 

  1. Look at the Name: field, it needs to match the information in the Database.yml file
  2. The ODBC connection will show you what SQL Server you are connecting to and if you are using a specific SQL instance, it will be shown here as well.
  3. Select Cancel

This is a working App Volumes environment. We will not make any modification to this setting.

 

Conclusion


This module showed you advanced notions of troubleshooting App Volumes. It demonstrated how navigate the Manager logs, to retrieve and read the Agent logs and configure advanced options.


 

Congratulations, you've finished Module 4

 

 

If you are looking for additional information on VMware App Volumes, try one of these:

Proceed to any module below which interests you most.

 

 

How to end your Lab

 

1. To end your lab, click on the END button.

 

Module 5 - User Environment Manager Troubleshooting (60 minutes)

Introduction


In this lab we will go over troubleshooting Tips and Tricks with VMware User Environment Manager.  The lab will explore


 

User Environment Manager Overview

VMware User Environment Manager offers personalization and dynamic policy configuration across any virtual, physical and cloud-based Windows desktop environment. User Environment Manager simplifies end-user profile management by providing organizations with a single, light-weight and scalable solution that leverages existing infrastructure. It accelerates time-to-desktop and time-to-application by replacing bloated roaming profiles and unmaintainable, complex logon scripts. It maps environmental settings (such as networks and printers), and dynamically applies enduser security policies and personalizations. This focused, powerful and scalable solution is engineered to deliver workplace productivity while driving down the cost of day-today desktop support and operations, and is a key component of JMP  the next generation of desktop and application delivery.

 

 

Features

 

 

Use Cases

Some of the most popular reasons why enterprises use User Environment Manager:

 

 

Components of User Environment Manager

User Environment Manager can be summarized in three parts:

  1. Management Console - Primary application interface for IT to configure and manage User Environment Manager.
  2. FlexEngine - Agent component, which is installed on the virtual or physical machines that you want to manage.
  3. File shares - User Environment Manager relies on a folder hierarchy. User Environment Manager stores configuration files in the configuration share. User data is stored in the profile archives share.

 

 

Architecture of User Environment Manager

 

 

Better understanding of login process


FlexEngine needs to run during the Windows login process so that User Environment Manager can get all the settings for the client device and apply some of them as soon as the user logs in. You can enable FlexEngine to run during the Windows login process in two ways:

1. Set Group Policy to Run FlexEngine as Group Policy Extension.

2. Configure a Windows logon script in Group Policy.

The first method is recommended if you are deploying User Environment Manager 8.x or later, because it is easy to configure and works on all supported operating systems. If you use an earlier release of User Environment Manager, such as Immidio FlexProfiles 6.x, or if you prefer to write a Windows logon script, use the second method.

To have FlexEngine run during the Windows logout process, configure a Windows logoff script in Group Policy. The Windows logoff script is required to save user settings to the network user profile share.

You must configure these two paths:

• Flex configuration files

• Profile archives

During logon, the specific features and functions provided by UEM are processed in a specific order.This order has been chosen to allow features to work together. For instance, Environment Variables are created first, so you can use this newly set variable to create a Drive Mapping or Printer Mapping.

Individual items configured within each feature are processed in alphabetical order.

For example:If you have configured three Drive Mappings with the following names, the alphabetical order in which they are processed are:

List of all the specific features UEM processes

As you can see below, there is a lot of information that can be processed during login. They don't all have to be processed but it shows you how granular it can be.

Processing order at logon (import)

 

Processing order at logoff (export)


Troubleshooting a user


The profile archives share stores the personal settings for users as FlexEngine creates a subfolder for each user. The share contains User Environment Manager profile archives, which are ZIP files. FlexEngine reads personal user settings from the profile archives share when a user logs in to the environment or launches a DirectFlex-enabled application.

FlexEngine writes the modified settings when the user logs out, or closes a DirectFlex-enabled application. In a typical deployment, profile archive backups and log files are stored on the same share, but you can configure different locations in the FlexEngine GPO.

You should use a share that is dedicated to the profile archives. A dedicated share improves performance, simplifies configuring the User Environment Manager SyncTool, and makes it easier to configure permissions for the Helpdesk Support Tool


 

Validate Log levels

The logs for a user are usually located in the sub-folder for the profile path.

In most cases, the share will be an SMB share and will be something similar to:

\\<ServerName>\UEMUsers$\

The "$" is to make the share hidden from normal network browsing, this is optional.

In User Environment Manager, each user will have it's own repository to store his/her personal information and also the logs for that specific user. You configure the share in the solution using the %Username% variable.

You can do this in 1 of two places. You configure this in the User Environment Manager Group Policy Object, under "FlexEngine Logging" setting. You set this GPO value to "Enabled".

Once the setting is enabled, you set:

- Path for the log (Example: \\<ServerName>\UEMUser$\%username%\Logs\FlexEngine.log)

- Log Level (from warning to Debug)

- Maximum Log File Size in KB  (We recommend a minimum of 2048 = 2MB)

In this lab, we use the 2nd and preferred method, to set the user logs, through the NoAD.XML configuration file.

Let's look at the configuration log level setup in the lab.

 

 

FlexEngine Command Switches

There are a lot of commands that can be run for the User Environment Manager Agent.

These are very useful command to know for a System Administrator.

To see a list of all the possible commands, you can open the VMware User Environment Manager Installation Guide and look for FlexEngine Operations and Arguments.

https://docs.vmware.com/en/VMware-User-Environment-Manager/9.1/com.vmware.user.environment.manager-install-config/GUID-95909F61-CAF9-44A1-A5EE-373BB957B415.html

n this lab, we will try out 2 of them.

 

 

Disabling Settings for a Specific User

When troubleshooting a user, you might need at some point to turn off settings that are applied to him by User Environment Manager. This can help prove the impact of UEM on the user login or rule out User Environment Manager completely as a component impacting the environment.

You can put a file in the User Profile Archive Path that will make the User Environment Manager agent skip path-based import/export, Offline import, DirectFlex refresh, and UEM refresh for single user.

 

 

Generating Reports About Flex Configuration Files and User Environment Settings

User Environment Manager can generate a report containing information about all the Flex configuration files and user environment settings that have been processed.

Use the reporting feature only to perform troubleshooting and other diagnostics.

 

Finding additional troubleshooting information


As you have seen so far, the user logs for VMware User Environment Manager are very well detailed when used in DEBUG mode and contain a lot of rich information about the user session, how his settings are configured and what is injected on login and logout of his/her session.

In the previous section, we have extensively went over the user logs and it's content.

Another good place to be aware of, when you are doing a troubleshooting session for a user is the Windows Application Logs.

VMware User Environment manager stores it's information in that log.

We will not go into the details for this part since we already covered the UEM logs in depth in the previous section but feel free to login to the Horizon desktop with "user1mod5", open Event Viewer and go look at the Windows Application logs, you should see something similar to the image below. You can sort by "source" to see all the Immidio Flex+ events.

 


 

Excluding an application from User Environment Manager

There is a built-in feature in User Environment Manager to exclude an application from being inspected by the User Environment Manager Agent.

This scarcely happen, we have seen this on less than 5 applications in last few years but this feature is useful to know, in case you need to do advanced troubleshooting.

The feature is called Application Black Listing. Applications configured to use DirectFlex can sometimes cause conflicts with other programs, which can cause the application to stop unexpectedly.

DirectFlex uses "hooks" to be notified of processes launching and exiting, and this technique sometimes conflicts with other software, particularly security and antimalware products.

VMware User Environment Manager provides advanced policy settings to resolve conflicts with specific third-party applications. Check Knowledge Base article 2145286 for the policies you can use with specific vendors.

You can blacklist one or more executables, so that they are not affected by the hooking mechanism by creating a Blacklist.xml file (this file does not exist by default).

We will not do these steps in this lab but you would just:

 

For example: list="calc.exe|notepad.exe|mspaint.exe"

 

 

What is VMware Logon Monitor

VMware Logon Monitor monitors Windows user logons and reports a wide variety of performance metrics intended to help administrators, support staff, and developers troubleshoot slow logon performance. Metrics include, but are not limited to, logon time, CPU/memory usage, and network connection speed. VMware Logon Monitor also receives metrics from other VMware products which provide even more clues about what is happening during the logon flow.

While other VMware products are not required to benefit from VMware Logon Monitor, some VMware products may be active during user logon. The Horizon Agent, Horizon Persona Management, and App Volumes are examples and report additional metrics which further enhance the value of VMware Logon Monitor's logs.

 

 

Integration with Horizon VMware Logon Monitor Service

User Environment Manager continues to improve Horizon 7 integration with the VMware Logon Monitor service (VMLM) feature. VMLM collects and logs information during the login process to the following file:

C:\ProgramData\VMware\VMware Logon Monitor\Logs\vmlm.txt

Both App Volumes and User Environment Manager add events to this log file, providing a comprehensive log file for events that occur during login to Horizon 7 desktops.

 

 

Logon Monitor Included in Horizon 7.1

Logon Monitor is included by default with Horizon 7.1. If you are using an older version of Horizon, there is a Fling you can download to get this functionality.

 

 

Open the VMware Horizon Client

 

Launch the VMware Horizon Client

 

 

Log into the Horizon server

 

Double-click on the horizon-01.corp.local

It may take a minute or two to connect into the Horizon-01 server.

 

 

Log in as User1Mod5 user

 

User name: user1mod5

Password: VMware1!

Click Login

 

 

Open the Windows Instant Clone Desktop

 

Launch the Windows 10 Instant Clone Desktop

 

 

Open the Folder and Navigate to the directory

 

Open Windows Explorer

Navigate to the folder C:\ProgramData\VMware\VMware Logon Monitor\Logs

 

 

 

Open in Notepad

 

Look at the latest file vmlm and Double click to open in Notepad.  

Note: If you changed the font and clicked on wordwrap in the previous labs, you can click on the pulldown under format for notepad and uncheck wordwrap. You can also edit the font and change size.

 

 

Search for data

 

Click on Edit button for Notepad and click on Find.  You can search for UEM or Logon to see the data is populated in the file.

Click the X in top right corner of the Notepad window to close the file.

 

 

Logout of Desktop

 

Click under Options and select Disconnect and Logoff.

 

Conclusion


In this module we went over better understanding of the User Environment Manager login process and Troubleshooting a User.  We looked at Windows Login Process, Log levels and where to look for information, and UEM Integration with Logon Monitor. 


 

You've finished Module 5

 

Congratulations on completing  Module 5.

If you are looking for additional information on User Environment Manager, try one of these:

Proceed to any module which interests you most.

 

 

How to End Lab

 

1. To end your lab click on the END button. 

 

Conclusion

Thank you for participating in the VMware Hands-on Labs. Be sure to visit http://hol.vmware.com/ to continue your lab experience online.

Lab SKU: HOL-1951-05-VWS

Version: 20190309-192323