Tag: horizon

I should’ve already posted a blog about this but better late then never. At the end of february I posted about several new functions being added to the vmware.hv.helper and two out of three where about pulling session information. Recently I received some questions about using those since it’s the raw data being returned. For my Dutch vmug presentation I used several gif’s that showed what you can do with that data. I might need to update the cmdlets so all information will be shown at once but that’s for another time since it might slow down the cmdlet a lot and I don’t like that.

Usage

Since get-hvglobalsession and get-hvlocalsession show almost similar data I will only show the latter one.

get-hvglocalsession

As you see this only shows the methods contained inside the session. We can show the content by pipelining it to  select-object -expandproperty but I prefer the bracket method since these might go several layers deep.

(get-hvlocalsession).namesdata

Some of the returned values are logical like the username, machineorrdsservername. The desktop name though is the actual desktop pool the user is connected to. Desktoptype can be Automated, Manual or RDS depending on the type of desktop and Desktopsource can be Virtual_Center (VM’s hosted on vCenter but not managed by Horizon or Full Clone desktops), View_Composer(when using Linked Clones), Instant_Clone_engine (when using Instant Clones), Unmanaged (physical machines, non-vCenter vm’s) or RDS (Terminal Servers). Farmname will be used when it’s an RDS session. The Securitygateway will show the Connection Server the user connected to or the UAG/Security server used.

the same can be done with referencedata and sessiondata

(get-hvlocalsession).referencedata
(get-hvlocalsession).sessiondata

Not a lot of directly usefull information but a bunch of id’s that you might be able to use with the api’s if needed.

A lot of information about the session itself.

The actual code

The get-hvglobalsession actually is a query repeated for all pods. First it connects to the query service and then creates a query to run against each pod and add that to a sessionlist.

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

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

}
return $sessionlist
} 

The get-hvlocalsession is almost the same, it just doesn’t need to foreach since it doesn’t have multiple pods to query.

 $query_service_helper = New-Object VMware.Hv.QueryServiceService
  $query = New-Object VMware.Hv.QueryDefinition

  $query.queryEntityType = 'SessionLocalSummaryView'
  $SessionList = @()
  $GetNext = $false
  $queryResults = $query_service_helper.QueryService_Create($services, $query)
  do {
    if ($GetNext) { $queryResults = $query_service_helper.QueryService_GetNext($services, $queryResults.id) }
    $SessionList += $queryResults.results
    $GetNext = $true
  } 
  while ($queryResults.remainingCount -gt 0)
    $query_service_helper.QueryService_Delete($services, $queryResults.id)
  

  return $sessionlist
  [System.gc]::collect()
} 

In both there is a do while because otherwise it will run into some restrictions about maximum amount of data to return.

One of the new cmdlets for the vmware.hv.helper that I am currently working on is initiating the Cloud Pod Architecture (CPA) and more actions related to this. This blog post will show the basics about initiating, and joining a CPA using the API’s. Doing things with site’s within the CPA will be covered in a later blogpost.

If we look at the services available in the Horizon API’s you’ll see that podfederation is one of them, let’s take a look at that and what method’s are available.

$services1.PodFederation | gm

So we can Eject, Get, Initialize, Join, Unintialize, Unjoin and update a podfederation. If we look at the brackets behind the methods than (un)initializing and unjoin don’t need any extra info so let’s get ahead and initialize the podfederation. To show you there’s nothing there yet I made a screenshot of the admin interface.

[sta_anchor id=”initialize” /]

Initialize the podfederation

Now to initiate the podfederation

$services1.PodFederation.PodFederation_Initialize()

And if you are quick enough in switching to the admin interface will also still show it initializing

[sta_anchor id=”get” /]

Get information about the federation

With podfederation_get() we can grab the configuration information.

$services1.PodFederation.PodFederation_Get()
($services1.PodFederation.PodFederation_Get()).data
($services1.PodFederation.PodFederation_Get()).localpodstatus
($services1.PodFederation.PodFederation_Get()).localpodstatus.LocalConnectionServerStatuses

Not a lot of information but there isn’t a lot more anyway in the podfederation itself.

[sta_anchor id=”join” /]

Join a federation

I have another pod that I want to join to this federation since we’ve already seen that this needs some more input let’s check what it exactly needs.

$Services1.PodFederation.PodFederation_join

So we need a remotepod address, presumable one of the connection servers in that pod will be enough, a username where domain\username will do just like in the admin console and a password of the type vmware.hv.securestring. The last one was new for me but thankfully it was described in one of the examples in the api explorer (https://code.vmware.com/apis/75/view and click on Data Object Types).

$vcPassword = New-Object VMware.Hv.SecureString
$enc = [system.Text.Encoding]::UTF8
$vcPassword.Utf8String = $enc.GetBytes('passwd')

With this it’s easy to add the local pod to the podfederation

$Services1.PodFederation.PodFederation_join("connectionserver","domain\username",$svcpassword)

And again if you are fast enough this is also visible in the admin console

And now a get will also show that it has been enabled

[sta_anchor id=”unjoin” /]

Unjoining a Podfederation

If you are braking down a pod because of whatever reason the best way to do this is to unjoin the pod from the federation. As we saw before there’s no extra information need so you just need to connect to a connection server in that pod and do an unjoin.

$services1.PodFederation.PodFederation_Unjoin()

this is really fast so over several tries I did not succeed in making a screenshot of the admin console.

[sta_anchor id=”eject” unsan=”Eject” /]

Ejecting a pod

This is the only podfederation function not available through the admin console as far as I could see. Ejecting a pod for is for me a last option if a datacenter burned down, everything is gone and you want to get rid of the pod. I did it in my lab against an alive pod and had to uninitialize the (now unlinked) podfederation from that pod to be able to rejoin it to the correct pod. This method also requires some input so let’s see what that is.

$services1.PodFederation.PodFederation_Eject

So we need the podid of the pod to eject, this information can be get trough the pod service

$services1.pod.Pod_List()

I want to eject the pod from pod2cbr1

$pod=$services1.pod.Pod_List() | where {$_.displayname -like "*pod2cbr1*"}

and with $pod I can check if I have the correct one

So let’s serve the eviction notice to the pod.

 $services1.PodFederation.PodFederation_Eject($pod.id)

No feedback, nothing but if we check the pod list it’s gone.

I will show how to remove the remnants in the uninitialize chapter.

[sta_anchor id=”update” /]

Updating a Pod Federation

This one sounds bigger then it is since there’s only one thing that we can update in a federation. To do this it is better to use the helper service then to use the podfederation_update method since that can get complicated very fast sometimes. To use the helper service we will need to create some variables first

$podservice=new-object vmware.hv.podfederationservice
$podservicehelper=$podservice.read($services1)

and when we do a get method on it

After some trial and error I know we need to getdatahelper method to continue

This only show the updates that are currently in the queue to be applied with a get method it’s possible to see what can be set.

$podservicehelper.getDatahelper() | gm

What we need to look for is a set so the only options here are setdisplayname that needs a string value and setupdates that needs a load of information and that probably might also be a way to do it but I will use the setdisplayname.

$podservicehelper.getDatahelper().setdisplayname("Whatever name you like")

This will give no feedback and nothing will be changed yet, what needs to be done is to apply this update in the helper service to the service.

$podservice.update($services1, $podservicehelper)

and if you now do a get on the podfederation it will show the changed name.

[sta_anchor id=”Unintialize” /]

Uninitializing a Podfederation

To show the pod uninitialization step I will use the pod that I have ejected from the podfederation pod2cbr1. It is clear that it is a bit wonky if we look at the pod list from that connection server.

So it knows about the pod federation but doesn’t see itself in it anymore.

$services1.PodFederation.PodFederation_Uninitialize()

This is again a fast one so I couldn’t get it visible in the admin console but when checking the data from a get it shows it has been disabled.

Looking from the other pod it still shows the Podfederation as enabled.

No github scripts this time since I will be adding this functionality into the vmware.hv.helper module.