Persist Enterprise Mode Site List with VMware User Environment Manager

 

 

Problem Overview

Deployment requires the use of Enterprise Mode Site List with Microsoft Edge on Windows 10 in a linked clone environment running Windows 10. This setting is typically delivered via GPO.  The goal:  when a user opens Edge and attempts to navigate to a site, Windows automatically opens that site in IE 11 and close Edge. 

 
 

Behavior

When the user logs in, they are required to open Edge once to get the policy downloaded.  Once downloaded, the next time a user opens Edge with the URL in question, IE 11 opens the URL and closes Edge as expected, but this is required to occur once during every time the user logs into a new desktop, they must repeat these steps.  What they’d like to is have UEM persist the fact that Edge has received the policy and simply open the link in IE 11.  We are using UEM 9.2.1, with the Edge.ini file provided on the VMTN site. We are looking for assistance on how to persist the site list downloaded by the policy. 

Solution Overview

Edge stores the Enterprise Mode Site List information in <LocalAppData>\Micosoft\Windows\WebCache. This WebCache information is regularly in use by a scheduled task called Wininit\CacheTask which always keeps the files in use.

 


 

By simply adding <LocalAppData>\Micosoft\Windows\WebCache to the UEM config file, the FlexEngine.log file will show access denied errors when attempting to import the WebCache files. This is why the login tasks are necessary.

 

Three steps are required to ensure the Enterprise Mode Site List is made available to Edge immediately at logon. Those steps are below:

 

  • Modifications to the Edge.ini file used by UEM
  • Logon Task to cancel the CacheTask scheduled task before profile import
  • Logoff Task to begin the CacheTask scheduled task once profile import is complete

 

Solution Details

Below are detailed information for each step required to remedy the issue.

 

Step 1: Modifications to the Edge.INI file used by UEM

 

[IncludeFolderTrees]

<LocalAppData>\MicrosoftEdge

<LocalAppData>\Microsoft\Windows\WebCache

 

[IncludeRegistryTrees]

HKCU\SOFTWARE\Microsoft\MicrosoftEdge

 

Step 2: Create a Logon Task to stop the CacheTask process

The first logon task ends the Scheduled Task mentioned above using the SCHTASKS command and is set to run before the profile archive import – this unlocks the files in <LocalAppData>\Microsoft\Windows\WebCache in order to allow UEM to import the persisted data from the users’ profile.

 

 

 

Step 3: Create a Logoff Task to stop the CacheTask process

The second logon task runs the Schedule Task mentioned above using the SCHTASKS command and is set to run after the profile archive import – this reinitiates the CacheTask scheduled task.

 


 

 

Other Notes

There is one unknown to this solution. Given that the webcache file contains not only the Enterprise Mode Site List settings – it also contains Internet Explorer History, Cookies, Modern App cache, and more. As a result, the webcache will grow over time. This can consume a storage and could cause performance issue on logon time to copy the file back in. This solution may require the use of some mechanism to purge older cache data

 

This blog by James Rankin provided some insight on the scheduled tasks

http://www.htguk.com/ie10-and-ie11-cookies-and-history-persistence-in-roamingcitrix-situations-the-last-word/

 

Clear Cache via Command Line

https://stackoverflow.com/questions/12621969/clear-cache-of-browser-by-command-line

 

 

Advertisements

Creating a new UEM Persistence setting for User DSNs

  1. Launch User Environment Manager – Management Console

 

  1. Right-click Windows Settings and select Create Config File…


 

 

 

 

 

 

  1. Select Create a custom config file, and click Next


 

  1. Enter a name, for example User DSN, and click Next


  1. Add the text shown below.


 

 

  1. Navigate away from the node, and click Yes to save


 

  1. To validate:
  • login as a user
  • Create a user DSN
  • Log off
  1. Look in the user’s UEM profile archive folder to ensure it contains UserDSN.zip. A similar path is shown below:


Basic Deployment of NSX for Horizon

Solution Overview

This process includes an outline of the steps needed to deploy a micro-segmentation policy for VDI desktops using NSX for Horizon. The goal is to create a few groups of rules. These rule groups include the following:

  • ID-based Rules – Identity-based rules are used to allow access to applications. Multiple ID-based rules can be used to allow specific AD groups access to specific applications. These rules include access to system that would not be required when a user is not logged in.
  • Computer Rules – This rule set allows access from VDI desktops to talk to computer-level services, like domain controllers, KMS, Connection Servers, and DHCP. These services would need to be available to the system at startup.
  • Block Rules – These rules will block East-West traffic among the desktops to ensure desktops cannot communicate with one another; block all remaining traffic out of the desktop (and into the desktop if desired).
  • Client Access – This rule allows client endpoints the ability to access the desktop using display protocols and virtual channels for USB Redirection and Client Drive Redirection.

This solution assumes a kiosk setup. The desktops are configured to use local mandatory profiles. The solution does not include user profile persistence, nor does it leverage App Volumes.

Preliminary Steps

This preliminary section is required in order to ensure all components function properly and the components for all of the rules are created and available when it comes time to create the rules.

Deployment Assumptions

  • NSX Manager deployed and registered
  • VIBs deployed to hosts
  • Licenses allocated
  • Log Insight deployed and configured
  • Appropriate permissions assigned
  • vDS configured for all hosts

Create Exclusions

  • Create exclusion for vCenter

Prepare for ID Rules

  • Connect to domain – will need to create a specific service account
    • The domain account must have AD read permission for all objects in the domain tree. The event log reader account must have read permissions for security event logs – KB2122706
  • Create VDI User AD Group
  • Create Super User Group
  • Validate VMware Tools Versions
    • 10.0.8
    • KB 2139740
  • Deploy Guest Introspection
    • 1x IP address per host
    • Create IP Pool

Create Objects

Security Groups

  • Contains VDI Desktops
    • based on VM name or OS-type
  • Contains AD group
    • user accounts that will be used to login to desktops
  • Contains AD super users group (Domain Admins)

IP Sets

  • Network Address ranges that should be able to access VDI desktops
  • Proxy Server
  • DHCP Servers
  • DNS/Domain Controllers
  • Connection Server
  • KMS Server

Service Objects

  • Blast Extreme – 22443 TCP
  • Blast Extreme UDP – 22443 UDP
  • KMS – 1688
  • MMR – 9457
  • VMware-View6.x-JMS – 4002

Service Group Objects

  • Client Access
    • VMware-View-PCoIP
    • Horizon 6 PCoIP UDP traffic from View Agent to Client
    • VMware-View5.x-PCoIP-UDP
    • Blast Extreme
    • Blast Extreme UDP
    • Horizon 6 USB Access to desktops
    • MMR
    • RDP

Create Firewall Rules Desktops

This section describes how to use the newly created objects as well as pre-existing objects to create the various rule groups.

Group – Block E/W

Source

Service

Destination

Purpose

VDI Security Group

Any

VDI Security Group

Block E/W Traffic

Group – Grant Client Access

Source

Service

Destination

Purpose

Client Access IP Set

-Client Access (Group)

VDI Security Group

PCoIP

Blast Extreme

USB Redirection

MMR/CDR

RDP

Group – Permit User Applications

Source

Service

Destination

Purpose

Desktop User Secuirty Group

-HTTP

-HTPS

Proxy Server IP Set

Internet Access/Proxy

Super User Security Group

Any

Any

Super User – Unrestricted

Group – Permit Computer Applications

Source

Service

Destination

Purpose

VDI Security Group

-DHCP Server

-DHCP Client

DHCP Server IP Set

DHCP Relay

VDI Security Group

-Win 2008 – RPC, DCOM, EPM, DRSUAPI, NetLogonR, SamR, FRS

– Microsoft Active Directory (Group)

Domain Controller IP Set

Domain Authentication

VDI Security Group

-MKS

KMS Server IP Set

KMS

VDI Security Group

– VMware-View6.x-JMS

– VMware-View5.x-JMS

Connection Server IP Set

Connection Server Management of Desktop Agents

Connection Server IP Set

– Blast Extreme

VDI Security Group

HTML 5 Access

Block All – All traffic from VMs

Source

Service

Destination

Purpose

VDI Security Group

Any

Any

Block All other traffic

OR

Block All – All traffic to AND from VMs

Source

Service

Destination

Apply To

Purpose

Any

Any

Any

VDI Security Group

Block All other traffic

Wrap Up & Validation

  • Enable Logging on all rules
  • Enable flow monitoring – Validate

Validate

  • Log in to VDI desktop via HTML
  • Log in to VDI desktop via Client using PCoIP
  • Log in to VDI desktop via Client using Blast
  • Verify USB Redirection
  • Verify Connection Server reports desktops are reachable
  • Verify Internet is reachable
  • Verify other desktops are not reachable within a VDI desktop

Finding the right Lenovo Firmware for vSAN

With any new vSAN deployment, it is critical to ensure the drivers and firmware levels are in compliance with the VMware Compatibility Guide (VCG). Get to the VCG by following the steps below.

  1. Go to the VMware Compatibility Guide here
  2. Go to the vSAN section of the Compatibility Guide here
  3. Select Build Your Own based on Certified Components near the bottom

You’ll see the vSAN component selector. Even if you purchase a vSAN ready node, it is a good idea to reference this page to ensure that the firmware and driver that comes preinstalled on the system are what is supported by vSAN.

Our focus today is Lenovo firmware, specifically the ServeRAID 5210 SAS/SATA controller. Select I/O Controller in the Search For field and Lenovo in the Brand Name field, and enter 5210 in the click Update and View Results.

In this case, two 5210’s are listed. On the console of the host, run the following command (assuming your ServeRAID controller is vmhba0) to view the Vendor ID, Device ID, SubSystem Vendor ID, and Subsystem ID of the device.

In this case, the following value was returned, showing that a ServeRAID 5210 was installed and NOT a ServeRAID 5210e.

Upon clicking the link for the model, the below information is presented. This is where the fun begins.

The vSAN VCG shows that version 4.620.00-7178 should be installed. Upon checking the IMM of the Lenovo server, it was determined that the controller had a firmware version of 24.16.0-0104. Needless to say, the version installed does not line up with the version listed in the VCG.

Upon going to the Lenovo support site, and checking for controller firmware for the 5210, which was installed in a Lenovo 3650 M5 type 8871, the versions continued to be mismatched.

So, here’s the trick. Open up the Change History file. The change history file contains the mapping between the Lenovo firmware package name, and the MegaRAID firmware version. Below is a snipped of the change log. It seems that the MegaRAID firmware version is what is listed in the VCG. In this case, firmware version 4.620.00-7178 corresponds with Lenovo firmware package 24.12.0-0033.

Using VSAN Performance Graphs

This document details the use of the graphs provided by the vSAN performance service. The vSAN performance service provides end-to-end visibility into vSAN performance. With metrics accessible by the vSphere Web Client, it further enhances an administrators view into the vSAN storage environment.

Front-end vs Back-end

Many of the performance graphs refer to front-end and back-end. Virtual machines are considered front-end – where the application on the virtual machine reads and writes to disk, generating say 100 IOPS. Backend traffic refers to the underlying objects – where the same VM, configuring in a RAID-1 configuration, would generate that same 100 IOPS across both replicas, thus totaling 200 back-end IOPS.

Cluster Level

These views provide insight into the front-end and back-end performance and utilization at the cluster level.

vSAN – Virtual Machine consumption

This set of graphs provides a front-end view of all virtual machines in the cluster.

Graphs

  • IOPS – IOPS consumed by all vSAN client in the cluster, including virtual machines & stats objects
  • Throughput – Throughput of all vSAN client in the cluster, including virtual machines & stats objects
  • Latency – Average latency of IOs generated by all vSAN clients in the cluster, including virtual machines & stats objects
  • Congestion – Congestion of IOs generated by all vSAN clients in the cluster including virtual machines & stats objects
  • Outstanding IO – Outstanding IO from all vSAN clients in the cluster, including virtual machines & stats objects

vSAN – Backend

This section provides a glimpse into the backend of the vSAN cluster.

Graphs

  • IOPS – vSAN Cluster Backend IOPS
  • Throughput – vSAN Cluster Backend Throughput
  • Latency – vSAN Cluster Backend Latency
  • Congestion – vSAN Cluster Backend Congestion
  • Outstanding IO – vSAN Cluster Backend Outstanding IO

Host Level

Similar to the Cluster view, the host view provides insight into the front-end and back-end performance and utilization, except at the host level. Given that the ESXi host is the foundation building block of a vSAN cluster, these views provide insight into the indidual disk groups and disks, as well as the hardware and software adapters used by vSAN.

vSAN – Virtual Machine Consumption

This set of graphs provides a front-end view of all virtual machines on the host.

Graphs

  • IOPS – IOPS consumed by all vSAN client on the host, including virtual machines and stats objects
  • Throughput – throughput of all vSAN client on the host, including virtual machines and stats objects
  • Latency – latency of all vSAN client on the host, including virtual machines and stats objects
  • Local Client Cache Hit IOPS – Average local client cache read IOPS
  • Local Client Cache Hit Rate – Percentage of read IOs which could be satisfied by the local client cache
  • Congestions – Congestion of all vSAN client on the host, including virtual machines and stats objects
  • Outstanding IO – Outstanding IO for all vSAN client on the host, including virtual machines and stats objects

vSAN – Backend

This section provides a glimpse into the backend of the vSAN host.

Resync Metrics

The resync metrics include traffic/load created by operations initiated automatically, or by an administrator. These operations include changes in policy, the repair of objects, maintenance mode and/or related evacuations, and rebalance operations whether manually initiated or automatic. The metrics in the graphs also detail what was the cause of the resync operation, which can be helpful when trying to determine the impact of maintenance mode, and rebalance operations.

Graphs

  • IOPS – vSAN host Backend IOPS
  • Throughput – vSAN host Backend Throughput
  • Latency – vSAN host Backend Latency
  • Resync IOPS – IOPS consumed by resync operation
  • Resync Throughput – Throughput of resync operations
  • Resync Latency – Latency of resync operations
  • Congestions – vSAN host Backend Congestion
  • Outstanding IO – vSAN host Backend Outstanding IO

vSAN – Disk Group

This view enables an administrator to review read and write performance on the level of the individual disk group. If activity or latency is occurring on a disk group, vCenter will show you in this section.

Graphs

  • Frontend(Guest) IOPS – vSAN disk group (cache tier disk) front-end IOPS
  • Frontend(Guest) Throughput – vSAN disk group (cache tier disk) front-end Throughput
  • Frontend(Guest) Latency – vSAN disk group (cache tier disk) front-end Latency
  • Overhead IOPS – vSAN disk group (cache tier disk) overhead IOPS
  • Overhead IO Latency – vSAN disk group (cache tier disk) overhead latency
  • Read Cache Hit Rate – vSAN disk group (cache tier disk) read cache hit rate
  • Evictions– vSAN disk group (cache tier disk) evictions
  • Write Buffer Free Percentage– vSAN disk group (cache tier disk) write buffer free percentage
  • Capacity and Usage–vSAN disk group capacity and usage
  • Cache Disk de-stage rate – The throughput of the data de-staging from cache disk to capacity disk
  • Congestions – vSAN disk group congestion
  • Outstanding IO – The outstanding write IO of disk groups
  • Outstanding IO Size – The outstanding write IO size of disk groups
  • Delayed IO Percentage – Percentage of IOs which go through vSAN internal queues
  • Delayed IO Average Latency – The average latency of IOs which go through vSAN internal queues
  • Delayed IOPS – The IOPS of delayed IOs which go through vSAN internal queues
  • Delayed IO Throughput – The throughput of delayed IOs which go through vSAN internal queues
  • Resync IOPS – vSAN disk group level IOPS of resync traffic
  • Resync Throughput – vSAN disk group level throughput of resync traffic
  • Resync Latency – vSAN disk group level average latency of resync traffic

vSAN – Disk

This view enables an administrator to review read and write performance on the level of the individual disk, whether it is the cache disk, or the capacity disk.

Graphs

  • Physical/Firmware Layer IOPS – vSAN cache/capacity tier disk physical IOPS at the firmware level
  • Physical/Firmware Layer Throughput – vSAN cache/capacity tier physical throughput at the firmware level
  • Physical/Firmware Layer Latency – vSAN cache/capacity tier disk physical latency at the firmware level
  • vSAN Layer IOPS – Capacity tier disk vSAN layer IOPS
  • vSAN Layer Latency – Capacity Tier disk vSAN layer latency

vSAN – Physical Adapters

This view enables an administrator to review inbound and outbound performance on the level of the individual physical network adapter.

Graphs

  • pNIC Throughput – Physical NIC throughput
  • pNIC Packets Per Second – Physical NIC packets per seconds
  • pNIC Packets Loss Rate – Physical NIC packet loss

vSAN – Vmkernel Adapters

This view enables an administrator to review inbound and outbound performance on the level of the individual VMkernel adapter.

Graphs

  • vMKernal Network Adapter Throughput – Vmkernel write throughput
  • VMkernel Network Adapter Packets Per Second – Vmkernel packets per second
  • VMkernel Network Adapter Packets Loss Rate – Vmkernel packet loss

vSAN – Vmkernel Adapters Aggregation

This view enables an administrator to review the aggregated inbound and outbound performance on all VMkernel adapters in a host.

Graphs

  • vSAN Host Network I/O Throughput – Host throughput for all VMkernel network adapters enabled for vSAN traffic.
  • vSAN Host Packets Per Second – Host packets per second for all VMkernel network adapters enabled for vSAN traffic.
  • vSAN Host Packets Loss Rate – Host packet loss for all VMkernel network adapters enabled for vSAN traffic.

VM Level

These views provide insight into the front-end and back-end performance and utilization at the VM level.

vSAN – Virtual Machine Consumption

This section displays metrics of the individual VM.

Graphs

  • IOPS – VM IOPS
  • Throughput – VM Throughput
  • Latency – VM Latency

vSAN – Virtual Disk

This section shows metrics at the level of the virtual disk. The granularity of this level enables an administrator to look at the specific disk in question, at the VSCSI level of said disk.

Graphs

  • IOPS and IOPS Limits – normalized IOPS for a virtual disk. If an IOPS limit has been applied via policy, then the graph will also show the limit.
  • Delayed Normalized IOPS- Normailzed IOPS for the IOs that are delayed due to the application of the IOPS limit – this shows the impact of the limit.
  • Virtual SCSI IOPS – IOPS measured at the VSCSI layer for the individual disk
  • Virtual SCSI Throughput – Throughput measured at the VSCSI layer for the individual disk
  • Virtual SCSI Latency – Latency measured at the VSCSI layer for the individual disk

Alerting in an vSAN Environment

As with any storage environment, it is critical to receive a notification when any component in the environment is not functioning properly. This holds true in a vSAN environment. The Health Check plug-in for vCenter provides a comprehensive list of issues, which are useful when someone is looking in the vSphere Web Client, but does little own its own with regard to notification. Fortunately, VMware has included a myriad of alarms for vSAN that can be used to provide those reactive notifications. When triggered, these alarms will be visible in the vSphere Web Client, additional configuration will be required to ensure that a notification is sent. I typically configure email notification, which require vCenter to be configured with an SMTP server to use for sending said email. In most deployments, I recommend the following alarms be enabled for email notification. The list of alarms below are:

  • Disk Capacity

  • Overall Health Summary

  • Congestion

  • Disk Health

  • Network Health

  • Overall disks health

In the vSphere Web Client, right click on the vCenter object. Click the Monitor tab, and select Alarm Definitions

Search for the alarm name listed in the bullet points above

Click the Edit button

The alarm wizard begins

Click the Actions link on the right

Click the green Plus sign, and enter the email address that should receive the alerts.

Click Finish

Continue those steps for all VSAN alarms listed in bullet points at the top of the document.

Below is a comprehensive list of vSAN alarms available in vCenter.

Finding the right Lenovo Firmware for vSAN

With any new vSAN deployment, it is critical to ensure the drivers and firmware levels are in compliance with the VMware Compatibility Guide (VCG). Get to the VCG by following the steps below.

  1. Go to the VMware Compatibility Guide here
  2. Go to the vSAN section of the Compatibility Guide here
  3. Select Build Your Own based on Certified Components near the bottom

You’ll see the vSAN component selector. Even if you purchase a vSAN ready node, it is a good idea to reference this page to ensure that the firmware and driver that comes preinstalled on the system are what is supported by vSAN.

Our focus today is Lenovo firmware, specifically the ServeRAID 5210 SAS/SATA controller. Select I/O Controller in the Search For field and Lenovo in the Brand Name field, and enter 5210 in the click Update and View Results.

In this case, two 5210’s are listed. On the console of the host, run the following command (assuming your ServeRAID controller is vmhba0) to view the Vendor ID, Device ID, SubSystem Vendor ID, and Subsystem ID of the device.

In this case, the following value was returned, showing that a ServeRAID 5210 was installed and NOT a ServeRAID 5210e.

Upon clicking the link for the model, the below information is presented. This is where the fun begins.

The vSAN VCG shows that version 4.620.00-7178 should be installed. Upon checking the IMM of the Lenovo server, it was determined that the controller had a firmware version of 24.16.0-0104. Needless to say, the version installed does not line up with the version listed in the VCG.

Upon going to the Lenovo support site, and checking for controller firmware for the 5210, which was installed in a Lenovo 3650 M5 type 8871, the versions continued to be mismatched.

So, here’s the trick. Open up the Change History file. The change history file contains the mapping between the Lenovo firmware package name, and the MegaRAID firmware version. Below is a snipped of the change log. It seems that the MegaRAID firmware version is what is listed in the VCG. In this case, firmware version 4.620.00-7178 corresponds with Lenovo firmware package 24.12.0-0033.