Physical efforts in virtualization and mobility

Category Archives: VMware Horizon

VMware Horizon Internal Traffic Ports

Following on from my last post which focussed on traffic flows to enable remote connectivity, I thought I would look at the internal side of things. I am coming across more and more on premises environments where there are lots of VLANs with firewalls inbetween them so this is becoming more of a requirement.

For this post I have just produced a diagram which you may find useful, when I get time, maybe I’ll produce another firewall spreadsheet. This diagram assumes that there is a common server VLAN hosting the likes of the Connection Servers and App Volumes Managers so I have not added the ports required between those sorts of components.

Horizon Ports - Internal

You may have noticed that I favour flat diagrams over the 3D ones that VMware produce. I have created a basic Visio stencil set for these which you can download if you wish.



VMware Unified Access Gateway Firewall Rule Generator

Hello Folks,

When deploying Virtual Desktop/Application remote access solutions you often need to engage with ‘The Firewall Guy’. This can often be a difficult conversation involving lots of questions such as “what?”, “from where?”, “to where?” and “why?”

To this end I have created a Unified Access Gateway Firewall Rules Generator which you can download. You just need to plug in the parameters on the lookup tab and it will pre-populate the firewall rules for you. Other than the standard back end stuff which you (as the Virtual Desktop Consultant) should already know, the only things you need to ask the firewall guy for are:

  1. Unified Access Gateway owned IP addresses in the DMZ
  2. Internet facing IP Address for the NAT rule  – You don’t actually need to know this yourself but it helps in order to provide a fully completed rule set
  3. Certificates – May be from someone else entirely

Hopefully you won’t even need to talk to the firewall guy at all after that! You can fill in the sheet and email it off to him/her. Here’s a diagram I put together with the ports:

UAG Ports

A Few points to note:

  • This is based upon the information from this VMware article which I found to be missing items such as DNS and RADIUS so I have added these in
  • The deployment mode is based upon the two IP addresses per Access Point; Single IP will work fine, just enter the same IP in both the Front-End and Back-End Management sections
  • When Deploying the Unified Access Gateway either via PoSH or OVF, the first IP entered becomes the external one, not the Management/Backend Communication one, which is the second one entered
  • If you want to read a blog on actually deploying UAG, this by Carl Stalhood is probably the best one out there

I’ve used the PowerShell deployment method before but since 2.8 the OVF deployment actually works properly so it’s just as easy to deploy it that way then import your predefined settings from a JSON file.




Automating Creation of Desktop Pools in VMware Horizon

I don’t know about you guys but I really hate the add new pool wizard in VMware Horizon. Generally speaking, I only work with non-persistent pools and during the life of a project will create and tear down a number of pools for dev, test, UAT and then create a bunch or production pools later on. These pools will have pretty much the same settings except for a few things like pool name, naming pattern, target storage etc. I get fed up with having to click around on the same stuff when all I want is effectively a duplicate with a few bits changing. What got me onto this was the desire to fix production pools to specific vSphere network labels detailed here.

First of all you will need some information about your environment, best thing is if you’ve been through the wizard once and have a pool setup like you’d want it to end up, run:

Get-Pool > C:\Temp\Get-Pool1.txt

From the resulting text file you can copy and paste all of the information you’ll need to automate the creation for all future pools. In particular you will want:

vc_id #Virtual Center ID so static setting
vmFolderPath #The parent folder where the desktops will land so static setting
ResourcePoolPath #Path to the vSphere Resource pool, static
ParentVmPath #Path to the Master VM so static setting
ParentSnapshotPath #Path to the particular snapshot of the above VM, more likely dynamic setting
DatastoreSpecs #Path and configuration of storage could be either static or dynamic
Composer_ad_id #Composer ID, static setting
organizationalUnit #Where the Computer accounts in AD will land, dynamic setting
NetworkLabelConfigFile #Path to text file containing the Network labels to use, built in the article mentioned earlier

I’ve noted above which of the settings are static (ones unlikely to change between pools) and which are likely to be dynamic.

Next you can use this example PowerCLI just changing the bits from your Get-Pool. The red text is stuff that is unlikely to change within an environment and the greens are ones that you will probably want to overwrite with the specifics of a new pool. You’ll need to run this on a connection server in an administrative PowerCLI window (you can remotely connect too if you want).

Add-AutomaticLinkedClonePool -Pool_id UAT1 -NamePrefix “UAT1-{n:fixed=2}” -Vc_id 40263e00-123e-43481-9a05-99afg09732c3 -Persistence NonPersistent -VmFolderPath  /Datacenter1/vm/Desktop Pools” -ResourcePoolPath “/Datacenter1/host/Cluster1/Resources” -ParentVmPath “/Datacenter1/vm/Reference Desktops/GOLD01” -ParentSnapshotPath “Snapshot1/Snapshot2/Snapshot3“-DatastoreSpecs “[Aggressive,OS,data]/Datacenter1/Custer1/Storage1” -Composer_ad_id 474cdee0-60dd-447f-bdfr-692rg3f83dbe -UseUserDataDisk $false -organizationalUnit “OU=UAT,OU=Virtual,OU=Clients” -NetworkLabelConfigFile “C:/Temp/label1.txt” -UseTempDisk $false -MinimumCount 10 -MaximumCount 10 – HeadroomCount 1 -PowerPolicy RemainOn -deletePolicy RefreshOnUse -SuspendProvisioningOnError $false -defaultProtocol PCOIP -allowProtocolOverride $false

So this powerCLI string will create a NonPersistent pool called UAT1 with 10 machines using a naming pattern starting at UAT1-01. It will not use a disposable disk, will refresh desktops at logoff, use PCOIP as the protocol and not permit the users to change to RDP. Just changing a few parts of this string means you can quickly create new pools in seconds by just pasting over the pertinent parts, and no more using that annoying wizard that seems to take days to get through…..

VMware Horizon 6.2 NetScaler TLS Support

So it turns out that TLS 1.1 and 1.2 is not supported on the NetScaler VPX platform to communicate with the backend servers.

Update: At the time of writing this was the case but support has now been provided with version 10.5 Build 65. MPX and SDX appliances would also be affected if they are running firmware older than 10.5 Build 58. I have since load balanced these services successfully using MPX 10.5 Build 60.7004.e with no need to carry out the procedure below.

The check boxes are there on an SSL Service Group but they won’t allow you to tick them. The trouble with this is that Horizon View 6.2 forces use of 1.2 on Server 2012/R2 so if you have created an SSL service group and point to 6.2 Connection servers (or recently carried out an upgrade), the members will show as Red (Down). Given the lack of support on the NetScaler end, the only workaround at the present time is to add TLS 1.0 support to the connection servers, which is achieved by editing the View LDAP instance on the Connection Servers using ADSI Edit. Below is a procedure I have adopted from the VMware documentation center but is specific to this issue:

1. Start the ADSI Edit utility on your View Connection Server computer.
2. In the console tree, select Connect to.
3. In the Select or type a Distinguished Name or Naming Context text box, type the distinguished name DC=vdi, DC=vmware, DC=int (exactly this DN, not your own domain)
4. In the Select or type a domain or server text box, select or type localhost:389
5. Expand the ADSI Edit tree, expand OU=Properties, select OU=Global, and select CN=Common in the right pane.
6. On the object CN=Common, OU=Global, OU=Properties, select pae-ServerSSLSecureProtocols, this will be configured as <not set>
7. Enter the following string in this field \LIST:TLSv1.2,TLSv1.1,TLSv1
8. Restart the View Connection Server Service

You do not need to do this on the other connection servers as this change will replicate to all other servers in the cluster. Restarting the Connection Server service on all of the all of them will suffice. As a side note, this also seemed to affect Imprivata OneSign appliances connecting to the Connection Servers so it looks like they don’t support TLS 1.2 either.

%d bloggers like this: