Skip to content
Home » VMware Horizon – Powershell scripting (ViewAPI)

VMware Horizon – Powershell scripting (ViewAPI)



I’ll be starting my new blog with a series of posts about using Powerschell to get information about a VMware Horizon infrastructure.

I’m using PRTG as my monitoring system because it has very flexible customized scripting capabilities. This way you can just monitor anything by writing your own scripts (if it’s not already builtin).

Requirements

First things first. We’ll need to make sure we have installed the VMware.VIMAutomation.Core & VMware.VIMAutomation.HorizonView powershell modules. With those modules we can manage our vSphere infrastructure and VMWare Horizon (In fact, the VMware.VIMAutomation.HorizonView module provides the cmdlets to connect to the View API Service of VMware Horizon).

Install the modules with the following powershell commands

Install-Module -Name VMware.VimAutomation.Core
Install-Module -Name VMware.VimAutomation.HorizonView

Before we can start using the new cmdlets we need to import the necessary modules. As we will connect to our VMware Horizon infrastructure, we’ll need both the Core module and the HorizonView module

Import-Module VMware.VimAutomation.Core
Import-Module VMware.VimAutomation.HorizonView

When you run the import-module command for the first time, you’ll get a warning about joining the VMware Customer Experience Improvement Program:

I don’t mind joining their program as long as I’m using my test setup, but for companies I still prefer to disable sending any information about your setup to VMware (or any other company). You can set your choice using:

Set-PowerCLIConfiguration -Scope Allusers -ParticipateInCEIP $false

Where: 

Scope can be User, AllUsers or Session.

ParticipateInCeip can be $true or $false.

To get the current confiration run:

Get-PowerCLIConfiguration | select Scope, ParticipateInCEIP

To get a list of all available commands in the module use:

Get-Command -Module VMware.VimAutomation.HorizonView

For the HorizonView module, the list is pretty small:

Now that we have all our requirements set, we’re ready to start!

Connecting… and disconnecting

First thing we need to do is connect to the Horizon Connection server. Therefore we use the cmdlet connect-HVServer.

Connect-HVServer -Server connectionserver.horizon.cloud

Where connectionserver.horizon.cloud is the fqdn of your Horizon connection server (not a security server of UAG).

When no other options are specified, credentials will be prompted. This is most likely the same user you use to access the Horizon Console or Horizon Administrator website. You can also specify a user and password by using the parameters -User and -Password or by specifying a PowerShell credential object with -Credential.

Current open connections to Horizon View servers can be viewed by checking the global PowerShell variable DefaultHVServers. This is also the object we will be using further on in our scripts to get all the information out of our Horizon Infrastructure.

$global:DefaultHVServers

After we have done all our work, we clean up everything nicely of couse by disconnecting the server. I specify the -Confirm:$false parameter here to prevent PowerShell from asking me confirmation if I really want to disconnect this Horizon View server.

Disconnect-HVServer -Server connectionserver.horizon.cloud -Confirm:$false

View API

As briefly mentioned before, to get information from the Horizon Connection server, the PowerShell module actually connects to the Horizon View API. I could of course just point you to https://code.vmware.com/apis/902/view and let you search out all the information you need yourself, but there’s no fun in that isn’t it?

Let’s start by saving our Horizon server connection into the variable $cs. That makes it easier to get the necessary information out of it.

$cs = Connect-HVServer -Server connectionserver.horizon.cloud

If we take a look at the possible properties of our $cs object, there’s not much to find here.

$cs | Get-Member

There’s only 1 property that we are interested in, namely ExtensionData. The ExtensionData property contains all the information we need. And if you take a quick look at that property, you’ll see that’s a lot of information!

$cs.ExtensionData

The screenshot above is not even showing all the properties. I won’t be covering all those properties on my blog, but I’ll show you some interesting ones to get usefull information about our Horizon infrastructure into our monitoring system.


That concludes our short introduction to VMware Horizon PowerShell scripting. We have the necessary modules installed and we can connect to our Horizon Connection server. In the next parts I will show you how to get some relevant information from the Connection server so we can monitor our Horizon Infrastructure.



2 thoughts on “VMware Horizon – Powershell scripting (ViewAPI)”

  1. Hello Michiel!, nice to meet you, and nice blog!. Very usefull article this one about, Horizon from PowerCLI, though I just want to ask you about PRTG since you mentioned that you choose it ’cause gives high monitor customization with scripts. I’m currently working as Monitoring Engineer on a insurance company and guess what?, our main monitoring system was Solarwinds, untill all this mess last December about the hacking the code and creating a backdoor hole…in short, we are evaluating new tools, and this one that you mentioned on the blog, caught my attention, and I started reading a bit about it.
    What I want to ask you here is about the sensors. Suppose I want to monitor CPU consumption, MEM load, disks space, and network traffic on a single server, in this I’m gonna count this as 4 sensors right?
    I will appreciate anything you can recommend about how I should approach this topic about the sensors.
    Thank you very much.
    Regards,

    1. You are correct: each sensor counts toward 1 license.
      You can also limit the number of sensors by combining multiple channels into 1 sensor. E.g. to monitor diskspace of a server, you can either choose the WMI Disk space sensor (included in PRTG) which will create 1 sensor containing a channel for each disk found on the server. On the other hand, you could create an SNMP Disk space sensor, which will create separate sensors for each disk found on the server.
      The drawback of using channels is that when 1 channel goes into warning/error status, the whole sensor goes into warning/error (although in the notification message you do see which channel is causing the current warning/error state). So it all depends on how flexible you want your monitoring to be.
      You can test this all out yourself by downloading the trial version at https://www.paessler.com/. After the trial period, you can keep using it for free for a maximum of 100 sensors. Also note that paused sensors don’t count into you used licenses. So if you have a 100-license you can have 150 sensors of which 50 sensors are paused (=not monitored).

Leave a Reply

Your email address will not be published. Required fields are marked *