VMware Horizon Published App-v applications

As you probably know ThinApp is tightly integrated with VMware Horizon. ThinApp is an excellent technology to deploy legacy applications or solve application conflicts. Unfortunately not everyone is using this technology. Other companies might use for example Microsoft App-v to deploy their applications.

App-v is a widely used application virtualization technology and works very well, it is just not integrated with VMware Horizon.

One of the questions I recently came across was this one:

How can you deploy App-v packages to your VMware Horizon Apps (RDS) environment and deliver them as published applications through the VMware Horizon client or Identity Manager Portal?

What I consider to be the preferred way to deploy App-v packages in your instant clone Horizon Apps environment is precaching the packages in the base image (or parent vm).

If you are only using Horizon published apps, there is no need to setup an App-v infrastructure.

In your parent vm, do the following:

Enable 8dot3 in registry:

  • Path: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem
  • Name: NtfsDisable8dot3NameCreation
  • Value: 0
  • Type: DWord

Execute these powershell commands:

  • Enable-Appv
  • Set-AppvClientConfiguration -ENABLEPACKAGESCRIPTS 1
  • Set-AppvClientConfiguration -SHAREDCONTENTSTOREMODE 0
  • Set-AppvClientConfiguration -PACKAGESOURCEROOT “Path_To_Package_Sources”

Create a scheduled task that executes this powershell script at startup of the instant clone. The script will add all the App-v packages on the package source share to the local cache. The DynamicDeploymentConfiguration parameter ensures the application shortcuts are added to the “C:\ProgramData\Microsoft\Windows\Start Menu\Programs” folder.

$path = “\\Path_To_Package_Share”

$names = Get-ChildItem $path -Recurse -Force | where name -like *.appv | select Name

$packagenames = New-Object System.Collections.ArrayList

$x = foreach ($name in $names){$packagenames.Add($name.Name.Substring(0,$name.Name.Length-5))}

foreach  ($packagename in $packagenames){

Add-AppvClientPackage ($path+$packagename+”\”+$packagename+”.appv”) -DynamicDeploymentConfiguration ($path+$packagename+”\”+$packagename+”_DeploymentConfig.xml”) | Publish-AppvClientPackage -global | Mount-AppvClientPackage


Because Instant clone vm’s don’t go through the complete startup cycle, sometimes the script does not run and App-v packages are not synced. To get around this, you can configure the scheduled task to repeat itself 3 times (every 1 minute).

Command: %SystemRoot%\system32\WindowsPowerShell\v1.0\powershell.exe

Argument:-ExecutionPolicy Bypass -file “\\Path_to_Powershell_Script.ps1”

Make sure this scheduled task runs under the system account and runs with highest privileges.

Every time an App-v package is updated or a new package is added to the App-v package source share, it will be automatically precached at reboot of the instant clone RDS server. The default cache location is under %programdata%\app-v

Once this is done, you can go ahead and publish the app-v package.

Publish the shortcut under the C:\ProgramData\Microsoft\Windows\Start Menu\Programs\ folder and you are ready to go.

App-v packages that are updated, don’t need to be re-published. The shortcut under the programs folder will not change, thus no need to change it in the application pool. Only new applications need to be added to the application pool.







IDM Connector authentication issue

Today I encountered an authenticaton issue on an idm connector, which is used for verification. Two verification adapters are configured on it, PasswordIdpAdapter and RadiusAuthAdapter.

I wanted to change a setting in the RadiusAuthAdapter.

(The screenshots are in dutch, because Identity Manager takes over the regional settings of your browser/endpoint. Currently there is no way to change languages.)

When you click on RadiusAuthAdapter, you are redirected to the configuration page of the verification adapter on the connector appliance. There you get an authentication prompt.

When entering the correct password (yes, I am sure it was the correct one 🙂 ), I always get the message “Your username or password is incorrect”:

I am not sure what the problem is, but it might be related to the redirection of the web page.

However there is an easy way to get around this.

Open a new tab in the browser and connect to the configuration page: https://FQDN of the connector:8443. Click on Connector-Services Manager. You are prompted for the admin password. Enter it and click on logon.

Logon is now succesfull:

Go back now to the browser tab with the verification adapters. Click again on the verification adapter you wanted to configure. In my case it was the RadiusAuthAdapter.

You can see it opens now without prompting for a password and you are able to configure it.

Identity Manager Cluster

As a follow up on my previous post (see here) I want to focus on how to create an Identity Manager Cluster.

This is my setup:

  • 1 Identity Manager (idm0)1 in DMZ, already behind a load balancer.
  • FQDN is changed from idm01.domain.com to portal.domain.com
  • Connectors in LAN are setup and configured for AD/Radius authentication and Horizon integration.

As you can see from the image above, everything is setup, except for the Identity Manager cluster. Identity Manager 2 and 3 are not in place yet.

To finalise the high available setup, the Identity Manager cluster in DMZ must be created. VMware recommends a 3-node cluster, because Elastic search has a known limitation with 2-node clusters. For more info, see here.

To create the cluster, follow these steps:

  1. Create DNS A-record and PTR (reverse lookup) for idm02.
  2. Create DNS A-record and PTR (reverse lookup) for idm03.
  3. Shutdown idm01.
  4. Shutdown both connectors.
  5. Snapshot idm01 (to be able to revert to the current situation in case anything goes wrong).
  6. Backup the sql database (or shutdown and snapshot sql).
  7. Clone idm01 to idm02.
  8. Clone idm01 to idm03.
  9. Start idm01.
  10. Start connector1.
  11. Start connector2.
  12. Wait until idm01 and connectors are fully booted and operational.
  13. Change ip address and hostname/FQDN on idm02 in the vAPP properties of the cloned appliance and power on the vm.
  14. Change ip address and hostname/FQDN on idm03 in the vAPP properties of the cloned appliance and power on the vm.
  15. Check the Elasticsearch cluster by executing this command on the idm appliances: curl -XGET ‘http://localhost:9200/_cluster/health?pretty=true’.
  16. Verify AD and Horizon synchronization (in my case an extra reboot of the connector appliances was needed)

In case anything goes wrong and you have to revert:

Shutdown idm02 and idm03
Revert snapshot on idm01