Added functions in vmware.hv.helper

Last Saturday I created a pull request to add some new functionality to the VMware.hv.helper. Together with an older PR that was still open it received an okay on Sunday. This is a list of the functionality I have added:

  • Get-HVHealth
    • Shows the health information for the following services:
      • ADDomain
      • CertificateSSOConnector
      • ConnectionServer,EventDatabase
      • SAMLAuthenticator
      • SecurityServer
      • ViewComposer
      • VirtualCenter
      • Pod
  • new-hvpodfederation
    • Initiates the Cloud Pod Architecture.
  • remove-hvpodfederation
    • Uninitiates the Cloud Pod Architecture.
  • get-hvpodfederation
    • Shows information about the Cloud Pod Architecture.
  • register-hvpod
    • Registers a new pod in the Cloud Pod Architecture.
  • unregister-hvpod
    • Removes a pod from the Cloud Pod Architecture. This can either be gracefully or forced.
  • set-hvpodfederation
    • Sets the name of the Cloud Pod Architecture.
  • get-hvsite
    • Retrieves information about all sites in the Cloud Pod Architecture.
  • new-hvsite
    • Creates a new site in the Cloud Pod Architecture.
  • set-hvsite
    • Sets site properties within the Cloud Pod Architecture.
  • remove-hvsite
    • Removes a site from the Cloud Pod Architecture.

The next functionality on my list is to put the pod service methods from this previous post into functions.

Managing Pods in a Horizon View Cloud Pod Environment using PowerCLI & Api’s

After Pod Federations and Sites it is time to manage the actual pods. Let’s take a look at what we can do.

$services1.pod | gm

Looks like a short post to me since there’s onl Get, List and Update

[sta_anchor id=”get” unsan=”Get” /]

Pod_Get

Just like with site’s the get can be used in conjunction with a podid that might be gotten from somewhere else

$services1.pod.pod_get((($services1.site.site_list()).pods | select -first 1))

This selects the first podid listed when pulling all the pods from all sites and gets the information about that pod. We’ll see the same information when doing a list but just with all pod’s listed.

[sta_anchor id=”list” unsan=”List” /]

Pod_List

$services1.pod.pod_list()

Those endpoints are the connection servers in the pod. Let’s take a short detour and get the listing for one of those (the podendpoint service only has list and get so you will not see them separately anyway).

$services1.PodEndpoint.PodEndpoint_Get((($services1.pod.pod_list() | select -first 1).endpoints | select -first 1))

It might look lazy to use the select -first one and yes it is a bit but doing  a foreach to explain things also doesn’t really work in my opinion.

[sta_anchor id=”update” unsan=”Update” /]

Pod_Update

Standard by now, first we need to connect to the podservice.

$podservice=new-object vmware.hv.podservice
$podhelper=$podservice.read($services1, ($services1.pod.pod_list() | select -first 1).id)

Under $podhelper we can already see how to set things.

$podhelper | gm

Let’s update  the easy things.

$podhelper.setdescription("This is a new description")
$podhelper.setDisplayName("This is a new name")
$podservice.update($services1, $podhelper)
$services1.pod.pod_list()

As a result we have updated the name and description of the pod. The other thing we can do is assign the pod to another site. Thankfully I already have two of those created.

$services1.site.site_list()
$siteid=$services1.site.site_list() | select -first 1

$podhelper.setsite($siteid.id)
$podservice.update($services1, $podhelper)
($services1.pod.pod_list()).site
$services1.site.site_list()

Both the lists aren’t required but I added them to show that the pods are spread over both pods now.

 

Creating and managing Sites in a Horizon View Cloud Pod Environment using PowerCLI & Api’s

Intro

Like I said in my previous post about Pod Federations this is a separate post that will show how to handle Sites within a Pod Federation. There are only a couple of API calls that do not include assigning a pod to a site. This is done trough the podservice which I will post about in a next blog post.

Let’s take a look at the site service to see what it actually has in api call’s

$services1.site | gm

So we have Site_create, Site_delete, site_get, site_list and site_update. To Make it myself easy I will use the order of List, create, get, update and delete.

[sta_anchor id=”list” /]

Site_list

With site_list a list of all available site’s will be created, currently I have only one so let’s show that one.

$services1.site.site_list()

Note a lot of information is shown so let’s take a look at the contents of base and pods.

($services1.site.site_list()).base

($services1.site.site_list()).pods

so again not a lot of information since it only contains a name, description and the pod id’s of the member pods.

[sta_anchor id=”create” /]

Site_Create

Since we already saw in the methods under the siteservice that the create needs a bit more information then just a name let’s take a look again at what is required.

$services1.site.site_create

An object is needed of the type vmware.hv.sitebase, we will need to take a look in the API explorer to see what this object should contain. Under Site_create we can click on sitebase.

The sitebase object has 2 properties of which only DisplayName is required. I have tried various ways to keep the description empty but haven’t succeeded so far and with it it the create also doesn’t work so how optional is it?

Let’s create the sitebase object

$sitebase=new-object vmware.hv.sitebase
$sitebase.displayname="blogpostdemosite"
$sitebase.description="This is a blog demo site"
$sitebase

The $sitebase is not required but shows what the object contains. Now we have enough to create the new site.

$services1.site.site_create($sitebase)

[sta_anchor id=”get” /]

Site_Get

In the overview we have seen that a site_get needs a bit more information.

$services1.site.site_get

We already know how to get this site id by using site_list, normally you would only use the site_get with an id received from another service like the pod service. For the example I will use the demo site I create in the site_create part of this post.

First I will need to get the siteid

$demosite=$services1.site.site_list() | where-object {$_.base.displayname -like "*blogpostdemosite*"}

And now we need to apply that to the site_get

$services1.site.site_get($demosite.id)

[sta_anchor id=”update” /]

Site_Update

As said before for an update method it is better to use the helper service for that service.

$siteservice=new-object vmware.hv.siteservice

now what method’s do we see?

$siteservice | gm

To see the difference between the sitebasehelper and siteinfohelper I will create both objects.

$siteinfohelper=$siteservice.read($services1, $demosite.id)
$sitebasehelper=$siteservice.read($services1, $demosite.id)

Now let’s compare them.

$sitebasehelper | gm
$siteinfohelper | gm

 

This is again one of those wtf moments, they both do exactly the same! I will use the sitebasehelper for now will update both the Displayname and description. For this I will need to use the getbasehelper 1 step deeper

$sitebasehelper.getbasehelper() | gm

$sitebasehelper.getbasehelper().setDisplayname("thissitecanberemoved")
$sitebasehelper.getbasehelper().setDescription("yes it can really be removed")

and apply the update, since neither will generate a response I won’t put any screenshots in.

$siteservice.update($services1, $sitebasehelper)

Now let’s see the result for a site_get for this site now

[sta_anchor id=”delete” /]

Site_Delete

We can take a look at it but to delete a site we only need the siteid so let’s remove that site we gave an update.

$services1.site.Site_Delete($demosite.id)

again no visual feedback but if we do a sitelist there’s only one left.

 

 

Initiating and managing the Podfederation in a Horizon Cloud Pod Architecture using PowerCLI & API’s

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.

Multi vlan Network for Horizon View using PowerCLI & API’s

One of the things I wanted to do for a while is to write an API version on how to use multiple dvSwitch portgroups with Horizon View linked clones. With instant clones there’s a gui way to select multiple portgroups but for instant clones the only was to do this was to use the View PowerCLI. This gets installed with the connection server and can only be used from there. What you do is create a file, edit and apply it. Johan has described this process very well on his blog. I decided there had to be a way to do this as well with ‘regular’ PowerCLI & the api’s.

The api explorer shows a property named networklabel for both desktop pools and rds farms. This entry showed me what data I needed to configure. I spent most of my time in gathering all the data for this. As you can see in the script I had to dig rather deep to get all information like hostorclusterid and snapshotid. This information then needs to be put into an object called nics.

The script I made is a working prove of concept and doesn’t contain logic about what portgroups to apply. It just grabs all portgroups that comply with a simple filter. It then grabs the id’s for those and configures them to use for the pool. The script grabs information using the snapshotid but in my testing it’s 100% safe to change snapshots or golden images after that, is just uses that information to know where to configure things.

Something I found during testing is that the maximum amount of labels is respected and spread over all port groups as long as there are labels available. If the system runs out of labels it will continue using only the last configured label! I have tested this on View 6.2 and 7.3.2 with vSphere 6.5 on both methods of configuring the portgroups.

This is the script, it asks for some required information at first. This way you don’t have to put a password in plain text in the script. You can see I have the maxlabeltype and enabled properties pre-configured as LIMITED and $true. If the maxlabeltype is UNLIMITED the composer would stop using any other labels configured after that one and if enabled would be $false that label wouldn’t be used at all..

#-------------------------------------------------
# Linked Clone Configure multiple vlan's
# This script is created to allow a Linked Clone
# Desktop pool to use multiple vlan's
#
# In the past only the 'old' View PowerCLI on the Connection
# broker could be used to accomplish this. Now it's possible 
# from any system running PowerCLI 6.5 or above.
#
# This version replaces all current settings!
# 
# Requires PowerCLI 6.5 or higher
#
# Feel free to use or alter in anyway but please remember the original creator :)
#
# Version 1.0
# 16-01-2018
# Created by: Wouter Kursten
# https://retouw.eu
# Twitter @Magneet_NL
#-------------------------------------------------

$hvservername=Read-host "Which Connection broker do you want to connect to?"
$domain=read-host "Please enter your active directory domain?"
$username=Read-host "Please enter your useraccount"
$password=Read-host -assecurestring "Please enter your password"
$poolname=read-host "What pool to configure?"
$labelfilter=Read-host "What portgroups do you wnat to configure (use * as wildcard i.e. DVVDI*)"
$maxlabels=read-host "How many labels to configure per portgroup?"

#Connect to View Connection broker
Import-module vmware.hv.helper
write-host "Connecting to the connection broker" -ForegroundColor Green
try {
	$hvserver1=connect-hvserver $hvservername -domain $domain -username $username -password $password -WarningAction silentlyContinue -erroraction stop
	$Services1= $hvServer1.ExtensionData
}
catch {
	Write-host "Can't connect to the Connection server please check the credentials." -ForegroundColor Red
	exit
}
$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}
try     {
        $poolid=($queryService.queryservice_create($Services1, $defn)).results
        }
catch   { 
        throw "Can't find $poolname, exiting" 
        }

$pool=$Services1.Desktop.desktop_get($poolid.id)
$networklabelsall=$services1.networklabel.NetworkLabel_ListByHostOrCluster($pool.AutomatedDesktopData.VirtualCenterProvisioningSettings.VirtualCenterProvisioningData.hostorcluster)
$networklabels=$networklabelsall | where-object {$_.data.name -like $labelfilter}
$NetworkInterfaceCard=$services1.NetworkInterfaceCard.NetworkInterfaceCard_ListBySnapshot($pool.AutomatedDesktopData.VirtualCenterProvisioningSettings.VirtualCenterProvisioningData.snapshot)
$NetworkInterfaceCardSettings=new-object vmware.hv.desktopNetworkInterfaceCardSettings
$NetworkInterfaceCardSettings.nic=$NetworkInterfaceCard.id
$networkLabelAssignmentSpecs=@()

foreach ($networklabel in $networklabels){
    $NetworkLabelAssignmentSpec=new-object VMware.Hv.desktopNetworkLabelAssignmentSpec
    $NetworkLabelAssignmentSpec.enabled=$True
    $NetworkLabelAssignmentSpec.networklabel=$networklabel.id
    $NetworkLabelAssignmentSpec.maxlabeltype="LIMITED"
    $NetworkLabelAssignmentSpec.MaxLabel=$maxlabels
    $networkLabelAssignmentSpecs+=$networkLabelAssignmentSpec
    }
$NetworkInterfaceCardSettings.networkLabelAssignmentSpecs=$networkLabelAssignmentSpecs

$VirtualCenterNetworkingSettings=@()
$VirtualCenterNetworkingSettings=new-object vmware.hv.DesktopVirtualCenterNetworkingSettings
$VirtualCenterNetworkingSettings.nics+=$NetworkInterfaceCardSettings

$desktopService = New-Object VMware.Hv.DesktopService
$desktopInfoHelper = $desktopService.read($services1, $Pool.Id)
$desktopinfohelper.getAutomatedDesktopDataHelper().getVirtualCenterProvisioningSettingsHelper().setVirtualCenterNetworkingSettingsHelper($VirtualCenterNetworkingSettings)
$desktopservice.update($services1, $desktopInfoHelper)

I used a lot of variables and arrays with the names as they are pulled from the data, that explains their long names. Afterwards it doesn’t give any feedback. For this I created a separate script so you can separately check what is configured before or after you change the configuration:

#-------------------------------------------------
# Linked Clone get vlan configuration
# This script is created to check if a linked clone pool 
# has any configured vlan/portgroup configuration
#
# Requires PowerCLI 6.5 or higher 
#
# Feel free to use or alter in anyway but please remember the original creator :)
#
# Version 1.0
# 16-01-2018
# Created by: Wouter Kursten
# https://retouw.eu
# Twitter @Magneet_NL
#-------------------------------------------------

#region variables
$hvservername=Read-host "Which Connection broker do you want to connect to?"
$domain=read-host "Please enter your active directory domain?"
$username=Read-host "Please enter your useraccount"
$password=Read-host -assecurestring "Please enter your password"
$poolname=read-host "What pool to check?"

#endregion

#region Connect to View Connection broker
Import-module vmware.hv.helper
write-host "Connecting to the connection broker" -ForegroundColor Green
try{
    $hvserver1=connect-hvserver $hvservername -domain $domain -username $username -password $password -WarningAction silentlyContinue -erroraction stop
    $Services1= $hvServer1.ExtensionData
}
catch{
    Write-host "Can't connect to the Connection server please check the credentials." -ForegroundColor Red
    exit
}
    
#endregion

#regio gather and display data
$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}
try     {
        $poolid=($queryService.queryservice_create($Services1, $defn)).results
        }
catch   { 
        throw "Can't find $poolname, exiting" 
        }

$pool=$Services1.Desktop.desktop_get($poolid.id)
$labels=($pool.automateddesktopdata.virtualcenterprovisioningsettings.VirtualCenterNetworkingSettings.nics).NetworkLabelAssignmentSpecs
if (!$labels){
    write-output "No configured portgroup(s) or $poolname not found."
}
else{
    $output=@()
    foreach ($label in $labels){
        $output+= New-Object PSObject -Property @{
            "Labelname" = get-hvinternalname $label.networklabel;
            "Enabled" = $label.Enabled;
            "Labeltype" = $label.maxlabeltype;
            "Max_labelcount" = $label.maxlabel;
        }
    }
$output | select-object Labelname,Labeltype,Max_labelcount,enabled
}

And the result:

In the end the script looks and is way more complex than the ‘old’ way to assign multiple vlans. On the other hand it is way more flexible to use in any scripting you are already using for the automation of your Horizon environment.

As always both scripts can be found on Github here and here.

Building a Horizon View vCheck with those nice api’s (part 1 of ??)

Intro

Ever since I saw Alan Renouf’s vCheck script first in action years ago it has been one of the tools I have been promoting to use for daily checks. The fact that you can disable and enable plugins makes it a flexible adjustable solution that helped me preventing companies having big problems or proving that I have been warning them about things for weeks or months. Also I have whipped many colleague or customer around the ears with questions why they didn’t remove those snapshot they created 3 days before

Getting started

Fast forward until a couple of months ago when I saw those release note’s for PowerCli 6.5 with more options to talk to the Horizon View api’s. This immediately gave me the idea to build a set of vCheck scripts for Horizon View. One of the first things to do was finding out how the vCheck framework actually works. This turned out to be a matter of outputting the info you would like in the output as if it is on the command line. Also adding a section that contains a description helps in building the output:

$Title = "Composer Servers Status"
$Header = "Composer Servers Status"
$Comments = "These are the used Composer Servers"
$Display = "Table"
$Author = "Wouter Kursten"
$PluginVersion = 0.1
$PluginCategory = "View"

The 2nd thing to do is deciding on what checks needed to be build. After checking on the vExpert slack and with some co-workers and friends I came up with a shortlist:

  • Dashboard error status (Sean Massey)
  • Desktops with error (non-standard) status (Myself,Sean Massey)
  • Compare the Snapshots that have been set to the ones actually used on desktops to see if recompose might not have run (Brian Suhr, myself)
  • relation between Composer and vCenter (Kevin Leclaire)
  • last use time for dedicated desktops (Kees Baggeman)
  • Event Database status
  • Connection,composer,security server status
  • Information and status about the various desktop pool types
  • RDS farm status

Getting things done

Before actually building any checks a connecton has to be made this is done in the Connection plugin:

$Title = "Connection settings for View"
$Author = "Wouter Kursten"
$PluginVersion = 0.1
$Header = "Connection Settings"
$Comments = "Connection Plugin for connecting to View"
$Display = "None"
$PluginCategory = "View"

# Start of Settings
# Please Specify the address of one of the connection servers or the address for the general View environment
$Server = "Servername"
# Maximum number of samples to gather for events
$MaxSampleVIEvent = 100000
# Please give the user account to connect to Connection Server
$hvcsUser= "username"															
# Please give the domain for the user to connect to Connection Server
$hvcsDomain = "domain"														

# End of Settings



# Credential file for the user to connect to the Connection Server
$hvcsPassword = get-content .\hvcs_Credentials.txt | convertto-securestring		
# Credential file for the User configured n View to connect to the Database
$hvedbpassword=get-content .\hvedb_Credentials.txt | convertto-securestring   	

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

# --- Connect to Horizon Connection Server API Service ---
$hvServer1 = Connect-HVServer -Server $server -User $hvcsUser -Password $hvcsPassword -Domain $hvcsDomain

# --- Get Services for interacting with the View API Service ---
$Services1= $hvServer1.ExtensionData

# --- Connect to the view events database ---
#$eventdb=connect-hvevent -dbpassword $hvedbpassword

# --- Get Desktop pools
$pools=(get-hvpool)

As you might notice the vmware.hv.helper plugin is required to do this.

The first real check I decided to build was to see if the desktops are actually build on the same snapshot as configured on pool level. With this you are able to see if a recompose ran into trouble. Let me highlight some of the code:

if ($pool.type -like "*automated*" -AND $pool.source -like "*VIEW_COMPOSER*"){

There are a couple of pooltypes and one of them is automated, since we’re looking for linked clones we also need to make sure the pool source is VIEW_COMPOSER if this says VIRTUAL_CENTER you’re looking at full clones.

$wrongsnaps=$poolmachines | where {$_.managedmachinedata.viewcomposerdata.baseimagesnapshotpath -notlike  $pool.automateddesktopdata.VirtualCenternamesdata.snapshotpath -OR $_.managedmachinedata.viewcomposerdata.baseimagesnapshotpath -notlike $pool.automateddesktopdata.VirtualCenternamesdata.snapshotpath}

I could have shortened this one by defining a couple of variables but this gives an impression of how deep you might have to go to get the required data. WHat I do is check if the snapshot has the same name AND if the selected source VM has the same name if either of the two is different the vm wil be entered on the output.

$wrongsnapdesktops+= New-Object PSObject -Property @{"VM Name" = $wrongsnap.base.name;
								"VM Snapshot" = $wrongsnap.managedmachinedata.viewcomposerdata.baseimagesnapshotpath;
								"VM GI" = $wrongsnap.managedmachinedata.viewcomposerdata.baseimagepath;
								"Pool Snapshot" = $pool.automateddesktopdata.VirtualCenternamesdata.snapshotpath;
								"Pool GI" = $pool.automateddesktopdata.VirtualCenternamesdata.parentvmpath;

Last of the real code is about displaying the actual info for the desktop.

This all results in the following plugin, be aware that this might be a bit slow to run since it needs go go trough all desktops. For my customer it takes about 3 minutes on 1350 desktops.

# Start of Settings
# End of Settings


$wrongsnapdesktops=@()
foreach ($pool in $pools){
$poolname=$pool.base.name
if ($pool.type -like "*automated*" -AND $pool.source -like "*VIEW_COMPOSER*"){

$poolmachines=get-hvmachine ($pool.base.name)
$wrongsnaps=$poolmachines | where {$_.managedmachinedata.viewcomposerdata.baseimagesnapshotpath -notlike  $pool.automateddesktopdata.VirtualCenternamesdata.snapshotpath -OR $_.managedmachinedata.viewcomposerdata.baseimagesnapshotpath -notlike $pool.automateddesktopdata.VirtualCenternamesdata.snapshotpath}
foreach ($wrongsnap in $wrongsnaps){
$wrongsnapdesktops+= New-Object PSObject -Property @{"VM Name" = $wrongsnap.base.name;
								"VM Snapshot" = $wrongsnap.managedmachinedata.viewcomposerdata.baseimagesnapshotpath;
								"VM GI" = $wrongsnap.managedmachinedata.viewcomposerdata.baseimagepath;
								"Pool Snapshot" = $pool.automateddesktopdata.VirtualCenternamesdata.snapshotpath;
								"Pool GI" = $pool.automateddesktopdata.VirtualCenternamesdata.parentvmpath;
}
}
}
}
$wrongsnapdesktops

$Title = "VDI Desktops based on wrong snapshot"
$Header = "VDI Desktops based on wrong snapshot"
$Comments = "These desktops have not been recomposed with the correct Golden Image Snapshot"
$Display = "Table"
$Author = "Wouter Kursten"
$PluginVersion = 0.1
$PluginCategory = "View"

And this is how it looks:

Another script I already made is a simple one to get the status of all full clone pools. Not really fancy but it gets information about what template is used as the base and several counts for the various status of desktops:

# Start of Settings
# End of Settings

$fullpoolstatus=@()
foreach ($pool in $pools){
$poolname=$pool.base.name
if ($pool.type -like "*automated*" -AND $pool.source -like "*VIRTUAL_CENTER*"){
$desktops=get-hvmachinesummary -pool $poolname
$fullpoolstatus+=New-Object PSObject -Property @{"Name" = $Poolname;
								"Template" = $pool.AutomatedDesktopData.VirtualCenterNamesData.TemplatePath;
								"Desktop_Count" = ($desktops).count;
								"Desktops_Unassigned" = ($desktops | where {$_.base.User -eq $null}).count;
								"Available" = ($desktops | where {$_.base.basicstate -eq "AVAILABLE"}).count;
								"Connected" = ($desktops | where {$_.base.basicstate -eq "CONNECTED"}).count;
								"Disconnected" = ($desktops | where {$_.base.basicstate -eq "DISCONNECTED"}).count;
								"Maintenance" = ($desktops | where {$_.base.basicstate -eq "MAINTENANCE"}).count;
								"Provisioning" = ($desktops | where {$_.base.basicstate -eq "PROVISIONING"}).count;
								"Customizing" = ($desktops | where {$_.base.basicstate -eq "CUSTOMIZING"}).count;
								"Already_Used" = ($desktops | where {$_.base.basicstate -eq "ALREADY_USED"}).count;
								"Agent_Unreachable" = ($desktops | where {$_.base.basicstate -eq "AGENT_UNREACHABLE"}).count;
								"Error" = ($desktops | where {$_.base.basicstate -eq "ERROR"}).count;
								"Deleting" = ($desktops | where {$_.base.basicstate -eq "DELETING"}).count;
								"Provisioning_Error" = ($desktops | where {$_.base.basicstate -eq "PROVISIONING_ERROR"}).count;
}
}
}
$fullpoolstatus | select Name,Template,Desktop_Count,Desktops_Unassigned,Available,Connected,Disconnected,Maintenance,Provisioning,Customizing,Already_Used,Agent_Unreachable,Error,Deleting,Provisioning_Error
$Title = "Full Clone Desktop Pool Status"
$Header = "Full Clone Desktop Pool Status"
$Comments = "These are all pools with full clones and their most common counters"
$Display = "Table"
$Author = "Wouter Kursten"
$PluginVersion = 0.1
$PluginCategory = "View"

and again this is how it can look:

Github

After Alan Renouf saw me posting screenshots on Twitter he offered to setup a github project for this. Last week this was done and I have already done my first few commits. Hopefully more people will jump on the bandwagon so we can make this check as awesome as the original is.

Talking PowerCLI against Horizon view (basics)

You know that VMware product that really lacked on the PowerCLI front called Horizon View? Well from PowerCLI 6.5 R1 it finally (try to imagine saying this like The Rock : Finally Powercli has come to Horizon View!) has its own module that you can use to talk to Horizon View and the View API’s.

Offcourse i am not the first to write about it and lots can already be found at the above link to the VMware blog by Graeme Gordon but I did want to share a couple of easy commands with you. I will not bore you with how to set it up because that’s already perfectly explained in Graeme’s post.

First we need to connect, looks like the connect-viserver right?:

connect-hvserver SERVERNAME

you will get a popup box for credentials, I haven’t found an option yet to do something like new-vicredentialstoreitem yet but you can use a hashed password in a text file.

Now for example to retrieve all disconnected desktops

Get-HVMachineSummary -State DISCONNECTED

This can be changed to whatever states are available for desktops.

One of the things Horizon View always lacked was proper reporting for desktop counts i.e. how many desktops are in what state. Lots of people had to use things like scripts that counted them from the adam database (sloooooow) or used tools like the VMware Horizon toolbox 2. To get a count is now really easy with powercli, just repeat the above command and do a count on it.

(Get-HVMachineSummary -State DISCONNECTED).count

For me this was a matter of a second with over 900 desktops available.

Want some information about a single desktop?

get-hvmachinesummary -machinename "machinename" | fl

In short you can find anything you want with the command or by using the View API’s. Since I am not an APi expert myself I would recommend heading over to the API browser and see what you want to use.  In my next post I will dig into the command a bit more by grabbing the script from the VMware blog post and editing it more to my taste.

Can you smellllllll what The Rock is cooking?