[Horizon API]Discovering pods and sites

When working with a Cloud Pod Architecture with the Horizon API’s we always have to make our scripts so that we connect to each pod separately. What if there is a way to discover the other available pods in a site or other site’s and connect to those? I already spent a couple of posts on working with pods and site’s. In this post I will be mainly using the get and list commands to get the information we need. First of all it’s the easiest to have the credentials saved somewhere because we will be disconnecting and connecting from and to pods. More on that can be found in this post.

To start we need to find what pod we’re currently connected to, with the following command we can list all pods:

$hvservice.Pod.Pod_List()

You see I have two pods: Cluster-Pod2CBR1 and Cluster-POD1CBR1, both have a property called localpod that provides the locality information we need. What we can’t see is if both pods belong to the same site. This can be done by comparing the VMware.Hv.Siteid object but I would prefer to do that from the site side because we might have several pods inside a site and it might become messy that way. The better was is to use that siteid to get all the information from the site.

$localpod=$hvservice.Pod.Pod_List() | where-object {$_.LocalPod -eq $True}
$localpod

And use the site id to grab the localsite.

$localsite=$hvservice.Site.Site_Get($localpod.site)
$localsite
($localsite).pods

The pods object is an array with all the pods within that site, I have added my second pod to this site to show this. Now I am going to select a connection server from each pod, if you want to connect to all the pods regardless the sites you can use the results from pod_list() to create the same output that we get by using this:

$sitepods=foreach ($sitepod in ($localsite.pods)){$hvservice.Pod.Pod_Get($sitepod)}
$sitepods

we still don’t have the name for the connection servers but those are part of the endpoints. We do this by getting the first podendpoint from all the pods within the site.

$podendpoints=foreach ($sitepod in $sitepods){$hvservice.PodEndpoint.PodEndpoint_Get((($sitepod).endpoints | select-object -first 1))}
$podendpoints

Now we’re getting somewhere, we just can’t connect to the serveraddress directly so we need to strip the things from the url’s

$connectionservers=$Podendpoints.serveraddress.replace("https://","").replace(":8472/","")
$connectionservers

Now we have a list of a connection servers from each pod inside site 1. If we would have used the pod_list() as source we would have ended up with one connection server from all pods within the CPA. The only thing we need to do now is to disconnect and do a foreach with whatever we want to do against the connectionservers.

foreach ($connectionserver in $connectionservers){
    Write-Output "This is connectionserver $connectionserver"
    $hvserver=connect-hvserver -Server $connectionserver -cred $cred
    $hvserver.ExtensionData.ConnectionServerHealth.ConnectionServerHealth_List()
    disconnect-hvserver $hvserver -confirm:$false
}

My VMworld EU 2019 presentations

It’s already the week after and I am looking back at a very good VMworld last week in Barcelona. In the end I was at a podium for none less than four times and wanted to share the decks or videos with you when available. For the vExpert daily there is no deck (duh) and for the EUC Beer and tapas community event there is no video. I also had to remove most of the slides because the fling hasn’t been published yet, you can expect a blogpost when it’s been published because it’s going to be awesome!

vExpert Daily: Video | Deck

vBrownbag: tools for Horizon Helpdesk: Video | Deck

EUC Beer and Tapas top 5 flings for Horizon: Video | Deck

VMware{Code}-Horizon API 101: Video | Deck

New Horizon API explorer posted (new queries!)

While watching the VMworld US 2019 video of Sean Massey presenting about getting started with the Horizon API’s I decided to check if the API explorer has been updated. To my surprise it was and it is good to see that several queries have been added besides the method’s that I previously found.

The new queries that I found are:

  • DesktopAssignmentView
    • Description:
      • Desktop id + Desktop assignment data which will include desktop pool information, operation system, global entitlement.
  • DesktopHealthInfo
    • Description:
      • Desktop health Information. This data will be populated only for the desktops which support application remoting.
  • GlobalEntitlementSummaryView
    • Description:
      • Summary information about Global Entitlements.
  • MachineSummaryView
    • Description:
      • This View includes summary data of all entities related to this Machine

So the DesktopAssignmentView seems to give a lot of similar data to what the DesktopSummaryData query already gives. They both give global entitlement data plus user assignment data. The big difference is that it gives way more detailed information about the desktop pool itself like vGPU settings. The names should have been DesktopInfo in my opinion.

Desktophealthinfo is created for the new Windows 10 App remoting and the monitoring for that. The globalentitlementsummaryview and machinesummaryview are linked to GlobalEntitlementInfo and MachineDetailsView from which they give a subset of data.

I hope to have a new blog post soon with more detailed information of what the new method’s and queries will bring but I wanted to update you with the fact that the api explorer has been updated as soon as possible.

Updates to the Horizon API’s in PowerCLI 11.4

So today PowerCLI 11.4 was released with the following updates:

  • Add support for Horizon View 7.9
  • Added new cmdlets to the Storage module
  • Updated Storage module cmdlets
  • Updated HCX module cmdlets

As usual we need to wait for API explorer to be updated before we get the exact changes to the api’s but I already grabbed s short list by comparing the methods. Later I will create a more elaborate blog post about the changes if I have an overview. What I do see are some new additions that might be added to the vCheck for Horizon.

Also: even though the updates are for Horizon 7.9 there’s a good chance that a lot of this also works for previous versions, the examples below where done with 7.8.

  • Datacenter
  • DesktopHealth
  • Gateway
  • GatewayHealth
  • MessageClient
  • Monitoring
  • PersistentDiskQueryService
  • Privilege
  • SecondaryCredentials
  • SessionStatistics
  • StorageAccelerator
  • UsageStatistics
  • Validator
  • VirtualCenterStatistics

Sadly it’s late so I can only show a couple of examples:

$services.Privilege.Privilege_ListSelectablePrivileges()

 

$services.SessionStatistics.SessionStatistics_GetLocalSessionStatistics()

Finally we can reset the usage counters as well now

And some statistics from vCenter

($services.VirtualCenterStatistics.VirtualCenterStatistics_listSummaryStatistics())
($services.VirtualCenterStatistics.VirtualCenterStatistics_listSummaryStatistics()).DataStoreSummaryStatistics

[API]How to successfully logoff users in Horizon

One of the things that annoy me about the Horizon admin interface is the fact that if you give a session the logoff command that this only works if the user is active aka when the desktop is not locked. With the api’s though (and Andrew implemented this in the helpdesk fling) it is possible to force a logoff. Let’s look at the available method’s first.

So we have a logoff and logoffForced. But there are also the logoffsessions and LofoffSessionsForced, I guess those let you logoff multiple sessions. this is what the extensiondata says about them.

So for the singular method’s we need a single id and for the sessions we need an array of ids. At first I will use get-hvglobalsession (yes, this works against sessions in other pod’s in a cloud pod architecture as well!) to get the id’s to show how it works. I have 5 sessions running from my desktop

$services1.Session.Session_Logoff((get-hvglobalsession | select -first 1).id)

Damn locked, let’s force this bastard from his desktop.

$services1.Session.Session_LogoffForced((get-hvglobalsession | select -first 1).id)

Aaaand it’s gone

And to show that it works I had to make sure the first session wasn’t locked.

And now the big bang fuck all of you!

$services1.Session.Session_LogoffSessionsForced((Get-HVGlobalSession).id)

As you can see one of my users was a but slow in logging off (nested esxi with only a couple vcpu’s for that one) I have also created a script that asks for the user whom you want to logoff and which session you want to logoff in case they have multiple. It’s not the cleanest code that I have written but it works 🙂

$hvserver1=connect-hvserver servername -user user -domain domain -password passwords
$Services1= $hvServer1.ExtensionData

$username= Read-Host "Which user do you want to logoff? (no wildcards needed, part of the name is enough)"

$queryService = New-Object VMware.Hv.QueryServiceService
$userdefn = New-Object VMware.Hv.QueryDefinition
$userdefn.queryEntityType = 'ADUserOrGroupSummaryView'
$userfilter1= New-Object VMware.Hv.QueryFilterContains
$userfilter1.membername='base.name'
$userfilter1.value=$username
$userfilter2= New-Object VMware.Hv.QueryFilterEquals
$userfilter2.membername='base.group'
$userfilter2.value=$False
$userfilter=new-object vmware.hv.QueryFilterAnd
[email protected]($userfilter1, $userfilter2)
$userdefn.filter=$userfilter
$users=($queryService.QueryService_Create($Services1, $userdefn)).results

$menu = @{}
for ($i=1;$i -le $users.count; $i++){ 
    Write-Host "$i. $($users[$i-1].base.name)" 
    $menu.Add($i,($users[$i-1].id))
}
[int]$ans = read-host "Please select the correct user"
$user=$menu.Item($ans)

$GlobalSessionQueryService = new-object VMware.Hv.GlobalSessionQueryServiceService
$sessionfilterspec=new-object vmware.hv.GlobalSessionQueryServiceQuerySpec
$sessionfilterspec.user=$user
$sessions=($GlobalSessionQueryService.GlobalSessionQueryService_QueryWithSpec($services1, $sessionfilterspec)).results

$menu = @{}
for ($i=1;$i -le $sessions.count; $i++){ 
    Write-Host "$i. $($sessions[$i-1].namesdata.basenames.MachineOrRDSServerName)" 
    $menu.Add($i,($sessions[$i-1].id))
}
[int]$ans = read-host "Please select the correct VDI Desktop"
$session=$menu.Item($ans)

$Services1.Session.Session_Logoffforced($session)
$queryService.QueryService_DeleteAll($services1)

This script forces the logoff for the sessions since I haven’t been able yet to find where the desktop status (locked or not) is visible.

[API’s] Getting session counts (incl performance comparison)

One of my customers asked the question if it is possible to get a quick sessioncount for a script that they can run very often for a correct logging of license usage. While this could easily be done by grabbing all the sessions I thought this could be a slow process. I remembered though that the first release of the vmware.hv.helper module had a function called get-podsessions that only returned a sessioncount. I decided to see what was used for this. By going back in time at github I found that the GlobalSessionQueryService was still used but with the GlobalSessionQueryService_GetCountWithSpec method. It needs the service and a spec of the type VMware.Hv.GlobalSessionQueryServiceCountSpec.

the spec itself can hold one of the many options to get a count for

As you can see there is a globalentitlement property that needs to be set using the id so let’s grab that one first.

$queryService = New-Object VMware.Hv.QueryServiceService
$defn = New-Object VMware.Hv.QueryDefinition
$defn.queryEntityType = 'GlobalEntitlementSummaryView'
$globalentitlements = ($queryService.QueryService_Create($Services1, $defn)).results

I will use the first globalentitlement to grab the sessioncount

$globalentitlement=$globalentitlements | select -first 1
$globalsessionqueryservice_helper = New-Object VMware.Hv.GlobalSessionQueryServiceService  
$count_spec = New-Object VMware.Hv.GlobalSessionQueryServiceCountSpec  
$count_spec.globalentitlement=$globalentitlement.id
$sessioncountperglobalentitlements=$globalsessionqueryservice_helper.GlobalSessionQueryService_GetCountWithSpec($services1,$count_spec)

As you can see we actually get a count per pod so to get all the counts from all pods from all globalentitlements I have created a script with a couple foreach’s.

$hvserver1=connect-hvserver SERVERNAME
$services1=$hvserver1.extensiondata
$queryService = New-Object VMware.Hv.QueryServiceService
$defn = New-Object VMware.Hv.QueryDefinition
$defn.queryEntityType = 'GlobalEntitlementSummaryView'
$globalentitlements = ($queryService.QueryService_Create($Services1, $defn)).results
$queryservice.QueryService_DeleteAll($services1)
[email protected]()


foreach ($globalentitlement in $globalentitlements){
  $globalsessionqueryservice_helper = New-Object VMware.Hv.GlobalSessionQueryServiceService  
  $count_spec = New-Object VMware.Hv.GlobalSessionQueryServiceCountSpec  
  $count_spec.globalentitlement=$globalentitlement.id
  $sessioncountperglobalentitlements=$globalsessionqueryservice_helper.GlobalSessionQueryService_GetCountWithSpec($services1,$count_spec)
  foreach ($sessioncountperglobalentitlement in $sessioncountperglobalentitlements){
    $pod=$services1.pod.pod_get($sessioncountperglobalentitlement.id)
    $sessioncount+= New-Object PSObject -Property @{
      "Global_Entitlement_Name" = $globalentitlement.base.displayname;
      "Pod_Name"=$pod.displayname
      "Pod_Sessioncount" = ($sessioncountperglobalentitlement | select-object -expandproperty count);
      "Site_Name"= ($services1.site.site_get($pod.site)).base.Displayname;
    }
  }
}
 return $sessioncount | select-object Global_Entitlement_Name,Pod_Name,Site_Name,Pod_Sessioncount

The W10_MGMT global entitlement only has a pool in pod1 so even though the pod doesn’t have a pool inside the global entitlement it will still return a sessioncount.

Performance

I also decided to time it but in my small environment it took 3 seconds and 3 of those where for connecting to the connection server. If I removed the connecting part it was 0.7 seconds.

Measure-Command {D:\scripts\dev\session_count.ps1}

Back at the customer I decided to compare this against dumping all global sessions, this will give some better data since it has a couple more sessions in it (around 3500 at the moment of testing)

The script I used for getting all global sessions is the code that I used for the get-hvglobalsession in the vmware.hv.helper module

$query_service_helper = New-Object VMware.Hv.GlobalSessionQueryServiceService
$query=new-object vmware.hv.GlobalSessionQueryServiceQuerySpec

$SessionList = @()
foreach ($pod in $services1.Pod.Pod_List()) {
  $query.pod=$pod.id
  $queryResults = $query_service_helper.GlobalSessionQueryService_QueryWithSpec($services1, $query)
  $GetNext = $false
  do {
    if ($GetNext) { $queryResults = $query_service_helper.GlobalSessionQueryService_GetNext($services1, $queryResults.id) }
    $SessionList += $queryResults.results
    $GetNext = $true
  } while ($queryResults.remainingCount -gt 0)
    $query_service_helper.GlobalSessionQueryService_Delete($services1, $queryresults.id)

}
return $sessionlist

Screenshots from the timing:

so the getcountwithspec method is about 2.5 seconds faster but the data in the globalsession is way more extensive and usable for all kinds of management overviews.

[API]Resetting Desktops

This is the first post in a series of shorts that I will be posting about various methods that you can use with the VMware Horizon API’s. This time it will be about resetting desktops. When looking at the API Explorer you’ll see that there are two ways do do this from the machine service.

So the first is for a single VDI desktop and the latter for multiple.

First we need to get a list of vm’s I will be using the machines in pod1pool02 as victims for this post.

$queryservice=new-object VMware.Hv.QueryServiceService
$defn=New-Object VMware.Hv.QueryDefinition
$defn.QueryEntityType="MachineNamesView"
$filter=new-object VMware.Hv.QueryFilterContains
$filter.MemberName='base.name'
$filter.Value="Pod1Pool2"
$defn.filter=$filter
$results=($queryservice.QueryService_Query($services1, $defn)).results

with this result:

From this we’ll make a variable with all of them and one with a single one

$singlevm=$results | select-object -first 1
$multiplevms=$results

Before I will reset the single VM I will show the state of all the vm’s.

($queryservice.QueryService_Query($services1, $defn)).results.base.basicstate

And now let’s reset the vm.

$services1.machine.machine_reset($singlevm.id)

Since this is an instant clone you’ll see provisioned and not reset. Now let’s reset the rest as well.

$services1.Machine.Machine_ResetMachines($multiplevms.id)

And this method will work for all managed vdi desktops full, linked or instant clones.

The VMware Labs flings monthly for April 2019

It has been a quiet month for me on the blogging side of things. I am slowly rebuilding my lab so that costs a lot of time that I can’t spend on blogging. This month two new flings have been released and no less than six have received an update. the new flings are MyVMware CLI and App Volumes Entitlement Sync. The ones to receive an update are App Volumes Toolbox, Workspace One UEM Workload Migration Tool, Cross vCenter Workload Migration Utility, Identity Manager Migration/Backup Tool, vSphere HTML5 Web Client,  and HCIBench.

New Releases

MyVMware CLI

The MyVMware CLI fling is an early preview of api’s to download your entitled software from http://my.vmware.com.

MyVMware CLI is a command line client used to login and interact with my.vmware.com.
It provides an interface for programmatic query and download of VMware product binaries.

This Fling is in early preview and allows you to find and download:

  • Every product
  • Every version
  • Every file

Note: Any download attempts will be restricted to the entitlements afforded by your my.vmware.com account.

App Volumes Entitlement Sync

If you have multiple App Volumes installations than the App Volumes Entitlement Sync fling can be usefull to make sure everyone has the same rights everywhere.

The App Volumes Entitlement Sync Fling will read, compare and sync entitlements from one App Volumes instance to another. This helps customers managing multiple App Volumes instances across one or multiple geographic sites.

Updated flings

App Volumes Toolbox

The App Volumes Toolbox fling makes it easier to manage your App Volumes setups.

Changelog

Version 2.0

  • Optimized for App Volumes 2.x
  • Remove support for Enzo and App Volumes 3
  • Bug Fixes

Workspace One UEM Workload Migration Tool

The Workspace One UEM Workload Migration Tool fling allows you to easily migrate applications and configurations between various WS One setups.

Changelog

Version 1.0.1

  • Fixed issue with expired credentials.

Cross vCenter Workload Migration Utility

The Cross vCenter Workload Migration Utility allows you to vmotion or move vm’s between linked and unlinked vCenter servers. Since this version it also supports NSX-T Opaque networking.

Changelog

Version 2.6, April 15, 2019

  • Added support for NSX-T Opaque Network (enables migration to/from VMC and on-premises vSphere with NSX-T)

Identity Manager Migration/Backup Tool

With the Identity Manager Migration/Backup Tool you can automate the process of migrating and backing up from one idm to another.

Changelog

Version 1.6

  • Exports categories to new XML file appname_categories.xml
  • Exports entitlements to a new XML file called appname_entitlements.xml
  • Imports categories
  • Creates the category if it doesn’t exist on tenant where importing
  • Shows if a bundle has an associated entitlement or category xml file
  • Shows number of applications returned
  • Shows number of categories an application has assigned to it
  • Windows reserved characters are replaced with an underscore for export bundle

Version 1.5

  • Allows more than 20 applications to be returned – now up to 500 applications will be returned by the tool
  • Added number of applications returned into the group box title

vSphere HTML5 Web Client

Want the newest even with vCenter 6.7? Use the vSphere HTML5 Web Client fling!

Changelog

Fling 4.2.0 – Build 13172979
New Features

  • vSphere Perspective Management available under Administration > Customization > Perspectives This new feature enables administrators to take control of which parts of the UI other administrators see. This is done by defining a set of views and combining them together into a so called “perspective”.
    • [Perspective tab] As an administrator you can show or hide: tabs, portlets and primary views.
    • [Assignments tab] Perspectives can be assigned to both users and groups.
    • Demo is available at https://www.dropbox.com/s/06z15xspsvrciys/Perspectives-demo-fling.mp4
  • Code Capture can also capture calls for operations made when managing Content Libraries.
  • Code Capture can generate scripts in additional languages: Python and vRO (vRealize Orchestrator) Javascript.

Known Issues

We noticed an intermittent issue with stopping the vsphere-client. You can always kill the process manually by running these commands

ps -ax | grep java
kill -9
ps -ax | node
kill -9

HCIBench

Want to test your Hyperconverged Infrastructure? HCIBench Is one of the tools you can use for that.

Changelog

Version 2.0

  • Added fio as an alternative workload generator
  • Added Grafana for workload live monitoring
  • Switched UI to clarity
  • Allow user to select one to four cases while using easy-run

Bug fixes

  • MD5 checksum of HCIBench_2.0.ova: ba3c2b06b8c27fb41a1bb68baedb325f

Applying Golden Images for VDI & RDS cloned pools using the Horizon View API’s

Recently I came up with the idea to create a script to apply new Golden Images against the various types of desktop pools and farms that we have in Horizon View. This was something that I thought was not available from the vmware.hv.helper module but after some research I did find that it it available from the module by using start-hvpool and start-hvfarm. No those are not the best names for the functions in my opinion. This wouldn’t stop me for creating this post though on how to apply the images using api’s only since the module uses mapentries and I still hate those. I will cover full clones and defining a new image without recomposing in a next post since that requires updating the pools.

Let’s take a look at the api explorer on what is needed to recompose or push an image.

 

The DesktopPushImageSpec for instant clones has a comparable setup with some nuance differences.

For RDS farms the linked clones spec is equal to the desktop spec but for instant clones there’s a rather big difference but I will cover that later on.

So the common steps for most types of applying the golden image are:

  • Selecting the Desktop Pool or RDS Farm
  • getting the id for the vcenter or datacenter where the parent VM lives
  • getting the id of the Parent VM
  • getting the id of the snapshot to use
  • getting the id’s of the machines in the desktop pool (Linked Clones only)
  • Select date & time for the recompose or imagepush (if required)
  • combine the above info into a spec to recompose or imagepush
  • Apply the recompose or ImagePush

Each step uses information from the step above it.

Selecting the Desktop Pool or RDS Farm

This can be done using queries. For desktops we user the desktopsummaryview definition and for farms farmsummaryview.

$poolname="pod02_LC"
$queryservice=New-Object VMware.Hv.QueryServiceService
$defn=new-object VMware.Hv.QueryDefinition
$defn.QueryEntityType='DesktopSummaryView'
$defn.Filter= New-Object VMware.Hv.QueryFilterEquals -property @{'MemberName'='desktopSummaryData.name'; 'value'=$poolname}
$desktoppool=($queryservice.QueryService_Create($services1, $defn)).results

And for a farm

$farmname="rds_IC"
$queryservice=New-Object VMware.Hv.QueryServiceService
$defn=new-object VMware.Hv.QueryDefinition
$defn.QueryEntityType='FarmSummaryView'
$defn.Filter= New-Object VMware.Hv.QueryFilterEquals -property @{'MemberName'='data.name'; 'value'=$farmname}
$farm=($queryservice.QueryService_Create($services1, $defn)).results

getting the id for the vcenter or datacenter where the parent VM lives

For desktops this is a property of the $desktoppool object we have now

$desktopppoolvcenterid=$desktoppool.desktopsummarydata.VirtualCenter

For automated farms we need a small extra step since it is not property for the summary data we we can get it by doing a farm_get with the id we received from the query

$farmvcenterid=($services1.Farm.Farm_Get($farm.id)).automatedfarmdata.VirtualCenter

getting the id of the Parent VM

Using the vcenterid as done below we are able to list all vm’s in the vCenter that might be a Golden Image using

$services1.BaseImageVm.BaseImageVm_List($desktopppoolvcenterid)

You might be able to see it but this gives a list of all VM’s in the vCenter, sadly there is no query for this yet even though that would be really useful. If you know the exact name you can select on that but if you look at the IncompatibleReasons property there’s info to filter (if you want to create a menu for example)

$baseimagevmlist=$services1.BaseImageVm.BaseImageVm_List($desktopppoolvcenterid)
$baseimagevmlist.IncompatibleReasons

InUseByDesktop is a usable one for instantclones. I don’t know why InUseByLinkedCloneDesktop doesn’t give any true values even though I have one pool with linked clones, viewcomposerreplica does work. I have filtered this on some of the more obvious ones and end up with both my golden images for Windows 7 & Server 2016

$baseimagevmlist |where {$_.IncompatibleReasons.InUseByDesktop -eq $false -and $_.IncompatibleReasons.InstantInternal -eq $false -and $_.IncompatibleReasons.ViewComposerReplica -eq $false}

I will do it easy and select on the name for now

$Desktopbaseimagevm=$baseimagevmlist | where {$_.name -eq "GI_H72"}
$farmbaseimagevm=$baseimagevmlist | where {$_.name -eq "rds_template"}

getting the id of the snapshot to use

With the baseimagevmid we can utilize the baseimagesnapshot method to get the id for the snapshot.

$desktopsnapshotlist=$services1.BaseImageSnapshot.BaseImageSnapshot_List($Desktopbaseimagevm.id)
$farmsnapshotlist=$services1.BaseImageSnapshot.BaseImageSnapshot_List($farmbaseimagevm.id)

In this there is also an IncompatibleReasons property but that doesn’t give a lot of information so we’ll need to filter on name.

$desktopLCsnapshot=$desktopsnapshotlist | where-object {$_.name -eq "gi_linked"}
$desktopICsnapshot=$desktopsnapshotlist | where-object {$_.name -eq "snap_gi"}
$farmsnapshot=$farmsnapshotlist | where-object {$_.name -eq "gi_rds_2016"}

getting the id’s of the machines in the desktop pool

As you’ll see later in the spec there’s a requirement to list the machine id’s for the pool if you want to do a recompose. These can be grabbed by doing a query

$queryService = New-Object VMware.Hv.QueryServiceService
$defn = New-Object VMware.Hv.QueryDefinition
$defn.queryEntityType = 'MachineSummaryView'
$defn.filter=New-Object VMware.Hv.QueryFilterEquals -property @{'memberName'='base.desktop'; 'value'=$desktoppool.id}
$QueryResults=$queryService.Queryservice_create($Services1, $defn)
$desktopmachinelist=$queryresults.results

For Linked Clone RDS farms you ned to use the QueryEntityType of RDSServerSummaryView but since I don’t have those in my lab I can only show the theory

$queryService = New-Object VMware.Hv.QueryServiceService
$defn = New-Object VMware.Hv.QueryDefinition
$defn.queryEntityType = 'RDSServerSummaryView'
$defn.filter=New-Object VMware.Hv.QueryFilterEquals -property @{'memberName'='base.desktop'; 'value'=$farm.id}
$QueryResults=$queryService.Queryservice_create($Services1, $defn)
$farmmachinelist=$queryresults.results

Settings date and time for the action

It’s not required to set a date and but is very usable if you want to schedule an action. Please be aware that this is based on us format for day and time so mm-dd-yyyy otherwise I would have scheduled it for august.

$datetime=[DateTime]"02-08-2019 10:00:00AM"

The [DateTime] converts the string that follows it to a variable of the type day and time

combine the above info into a spec to recompose or imagepush.

To build the spec we first need to declare a new object with new-object vmware.hv.DesktopRecomposeSpec please be aware that for this name you need to look at the data object in the API explorer and not the class.

$desktoprecomposespec=new-object vmware.hv.DesktopRecomposeSpec
$desktoprecomposespec.ParentVm=$desktopbaseimagevm.id
$desktoprecomposespec.Snapshot=$desktopLCsnapshot.id
$desktoprecomposespec.StartTime=$datetime
$desktoprecomposespec.LogoffSetting="WAIT_FOR_LOGOFF"
$desktoprecomposespec.StopOnFirstError=$true
$desktoprecomposespec.Machines=$desktopmachinelist.id

For the instant clone image push there’s an extra layer required for the settings

$desktopimagepushspec=new-object VMware.Hv.DesktopPushImageSpec
$desktopimagepushspec.settings=new-object vmware.hv.DesktopPushImageSettings
$desktopimagepushspec.ParentVm=$desktopbaseimagevm.id
$desktopimagepushspec.snapshot=$desktopICsnapshot.id
$desktopimagepushspec.settings.StartTime=$datetime
$desktopimagepushspec.settings.LogoffSetting="WAIT_FOR_LOGOFF"
$desktopimagepushspec.settings.StopOnFirstError=$true

The recompose for a linked clone rds farm is similar to the desktop linked clone.

$farmrecomposespec=new-object vmware.hv.farmRecomposeSpec
$farmrecomposespec.ParentVm=$farmbaseimagevm.id
$farmrecomposespec.Snapshot=$farmLCsnapshot.id
$farmrecomposespec.StartTime=$datetime
$farmrecomposespec.LogoffSetting="WAIT_FOR_LOGOFF"
$farmrecomposespec.StopOnFirstError=$true
$farmrecomposespec.Machines=$farmmachinelist.id

For RDS instant clone farms the pushing of a new image is part of the maintenance schedule that can be done immediate or recurring. I will do the recurring option for now since rds hosts needs to be refreshed every once in a while anyway. There’s some options inside the settings that are explained in the api explorer.

$farmmaintenancespec=new-object vmware.hv.FarmMaintenanceSpec
$farmmaintenancespec.recurringMaintenanceSettings=new-object vmware.hv.FarmRecurringMaintenanceSettings
$farmmaintenancespec.imageMaintenanceSettings=new-object vmware.hv.FarmImageMaintenanceSettings
$farmmaintenancespec.maintenanceMode="RECURRING"
$farmmaintenancespec.scheduledTime=$datetime
$farmmaintenancespec.logoffsetting="WAIT_FOR_LOGOFF"
$farmmaintenancespec.stopOnFirstError=$true
$farmmaintenancespec.recurringMaintenanceSettings.startTime="23:00"
$farmmaintenancespec.recurringMaintenanceSettings.maintenancePeriod="WEEKLY"
$farmmaintenancespec.recurringMaintenanceSettings.startInt=1
$farmmaintenancespec.ImageMaintenanceSettings.parentVm=$farmbaseimagevm.id
$farmmaintenancespec.ImageMaintenanceSettings.snapshot=$farmsnapshot.id

Apply the recompose or ImagePush

This is the easiest part of the spec’s have been build properly.

Please note that the variables for the pools I use are a bit different to show the linked and instant clone pools

$services1.Desktop.Desktop_Recompose($linkedclonepool.id,  $desktoprecomposespec)
$services1.Desktop.Desktop_SchedulePushImage($instantclonepool.id, $desktopimagepushspec)
$services1.farm.Farm_ScheduleMaintenance($farm.id, $farmmaintenancespec)

No visible feedback but it’s visible from the admin console (sadly not all tasks can be gotten from the api’s yet 🙁 )

That’s it for now but expect future posts about full clones, setting a default image for linked clones without recompose and maybe a complete script that does it all for you.

Added Checks to the vCheck for Horizon View

Starting this year I decided to really restart working on the vCheck for Horizon. I had several requests for RDS checks & Active directory plus I really wanted to get rid of everything related to the vmware.hv.helper module to make using it a little easier.

Just like the pools I pull the farms in the connection plugin so these can be used from other plugins.

# --- Get Desktop pools
$poolqueryservice=new-object vmware.hv.queryserviceservice
$pooldefn = New-Object VMware.Hv.QueryDefinition
$pooldefn.queryentitytype='DesktopSummaryView'
$poolqueryResults = $poolqueryService.QueryService_Create($Services1, $pooldefn)
$pools = foreach ($poolresult in $poolqueryResults.results){$services1.desktop.desktop_get($poolresult.id)}

# --- Get RDS Farms

$Farmqueryservice=new-object vmware.hv.queryserviceservice
$Farmdefn = New-Object VMware.Hv.QueryDefinition
$Farmdefn.queryentitytype='FarmSummaryView'
$FarmqueryResults = $FarmqueryService.QueryService_Create($Services1, $Farmdefn)
$farms = foreach ($farmresult in $farmqueryResults.results){$services1.farm.farm_get($farmresult.id)}

# ---- Remove queries
$services1.QueryService.QueryService_DeleteAll()

The deleteall() for the queries needs to be added to clean things up, otherwise you will run out of queries pdq. The RDS plugins I created are visible down below.

Also an AD check was added

The vCenter api call was split into three checks for vCenter itself, ESXi and datastores.

Besides these I have also added a saml check (tested by Aresh Sarkari, thank you!) and truesso checks (don’t have it in my lab so can’t test).

If you want an example of the vCheck that can be found HERE.