New vmware.hv.helper cmdlets (also looking for ideas!)

It’s already a couple of weeks ago that the pull request was merged but I managed to build a couple of new functions for the vmware.hv.helper module. Besides these I am also always looking for new functions to add and since I keep forgetting them I create a project on my own fork of the PowerCLI-Example-Scripts. That can be found here: so if you have any requests or good ideas for functions please send them my way or add them yourself off course 🙂

This was recently done after my pr’s or is still open to be merged:

New functions

  • reset-hvmachine
    • Resets machines
  • get-hvlocalsession
    • Gets all sessions for the local pod
  • get-hvglobalsession
    • Gets all global sessions + the sessions directly to the local pod

Changed functions

  • get-hventitlement
    • had some issues with groups
  • add-hvdesktop & add-hvrdsserver
    • removed the displaying of the vcentervm id that was added to the pool
      • PR done, not yet merged!

Removed Functions

  • get-hvpodsession
    • this only got a sessioncount so hardly any usefull data

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..

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:

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.

Finding Horizon View local entitlements using PowerCLI


In a previous post i mentioned that finding the entitlements for a user from the Horizon side of things can be a bit of a hassle. If only active directory groups are used its dead easy: just use the Active directory commands for those groups. If the groups are used for multiple pools and if you have assigned desktops things get a bit more complicated. For now I will only concentrate on the local pod without global entitlements.

getting that info

To get started the vmware.hv.helper module has the get-hventitlement command. As almost always a very useful one but it has some flaws. First it requires full domainname\username or username@fulldomainname.

For example


Both work but

gives this message: Get-HVEntitlement: No entitlements found with given search parameters.

At least

If you add the -type group to this command you get all group entitlements

gives an error message that the -user argument does not match the “^.+?[@\\].+?$” pattern. With this last one you at least get an error so you know where to look but not displaying any entitlements is an issue for me.

So, back to the results of these commands, I have assigned the user user1 the following rights

  • Pool04 directly and by using a group
  • directly on a single desktop in pool04.
  • Pool01 only by group.
  • Paint rds app by group
  • Calculator rds app direct
  • Wordpad rds app by both group & directly

When using the get-hventitlement without anything else it doesn’t seem to show a lot of usable things

If you put this between brackets followed by a period and one of the properties a bit more info is shown.

Some information about the user, not very usable the session data property gives some information about current sessions (none at the moment)

With the localdata property it looks like we hit the motherload jackpot thingy

Very good, a lot of id’s so what can we do with those? For now I will put this into $entitledids.

I read something about get-hvinternalname when checking out the module, sounds usable.

Ah, so this needs an entityid as input, a machine is an entity so let’s try it. This might need a foreach though because the output gave machines and not machine.

Damn, that’s not usable, let’s double-check with the other id types

The ones we need are readable, couple of them not but I don’t those will be missed.

The missing machine name is actually easy to solve by doing an api call:


Because this is rather easy to use and since I didn’t have a direct use case for that I decided not to create a complete script. With get-hventitlement, get-hvinternalname and maybe an api call here or there it’s very easy to pull the information about which account or groups have what rights. To see if a user belongs to a group can easily be done with any of the multitude of scripts for that here’s a good example of those.


Adding manual desktops in Horizon View and assigning them using Powercli

A while ago I received a question from Geoffrey O’Brien if I knew how to add a desktop and assign it using PowerCLI. I started building this using the api’s and after a lot of hours, cussing, swearing running into weird problems I actually got it working. When I was busy writing that blog post and wanting to add this to the vmware.hv.helper module I found out that both functions had already been added back in July! I just ignored, or better, forgot about the module for a while because at first it lacked a lot of options.

Key ingredients to do this are add-hvdesktop and set-hvmachine commands. For this post I will assume that the user is already entitled to the pool. This is something that can be checked but because of some ‘things’ it will be a separate post. Please be aware that if you combine these commands in a single script that there needs to be some time for the connectionserver to actually add the desktop.

First check if the system isn’t already registered with this this pod:

If the desktop is already added somewhere and you know the pool it can be removed with the api (issue logged to create remove-hvmachine here)

Since the desktop can’t be found yet it can be added by:

Did you notice the extra S in the -machines part in the command? Multiple machines can be added by separating them with a comma.

To assign the user to the machine things get a it more complicated. We need to set an advanced option for that with set-hvmachine. Why an advanced option? It seems like assigning a single machine isn’t considered an entitlement! The module has no option to grab the horizon userid for you so we need to use the api’s for that (request to add it has been made here)

the username has to be exact samaccountname from your active directory otherwise it will not be able to find the user.

so now we do have the userid the base.user needs to be updated.


the command:


And since the user has been assigned something now it has it’s own userorgroupid as you can see and that can again be check with the api’s. First put the userorgroupid into a variable and then use that against the aduserorgroup service.

This is the script you can use as a base:

As always the most up to date version of the script can be found on Github.


get-hvmachine only finds 1000 desktops

Edit: this is supposed to be fixed already in the vmware.hv.helper module so make sure you have the latest version of it. I was late in writing it out :@

A while ago I wanted to list all desktops in use from one of our Connection servers. After several tries I kept having issues in finding some of the desktops. This prompted me to do a count on the amount with

and it turned out that I received only a 1000 results while I had over 1100+ in that pod. After talking to some people in the VMware Code slack it turned out that this is a limit in the query system that the View API uses. This was verified by running the query myself instead of using the module. Sadly I forgot to make screenshots when I did this and don’t have access to this environment anymore.

Despite setting the maximums to 1000 or not even filling them I always ended up with 1000 max. After again going over this on Slack I decided to create a do until to pull these results with each time a maximum of 1000 results until no results are received..

For this I did make a screenshot:

As you see it kind of stacks the results but the count is ok so I should be able to incorporate this into other scripts.

Removing faulty Horizon desktops using PowerCLI

So last week there where a couple of posts on vmtn about people wanting to automatically removing or refreshing faulty Horizon desktops. With faulty I mean desktops in Agent Unreachable or in error state or whatever status are available. Since this was something i had been investigating anyway I decided to make a script for it that had separate menu’s for the status the desktop needs to be and to pick the desktop to be deleted. The latter part can be rebuild to do all those desktops at once  in case something breaks pretty badly during a recompose of the pool.

The largest part of the script is for creating the menu’s. Since the amount of returned desktops is variable and names differ it’s not possible to use a static menu. Instead I have used a menu structure created by Roman Gelman and that can be found inside this script on github. The part that gets things done i have listed below. The $spec array doesn’t need to be created but it is required in the API call to remove the desktop, Powershell assumes everything true by default when it’s empty but it just has to be called otherwise you will get a big fat red error. To remove multiple desktops at once machine_deletemachines needs to be used with an array filled with desktop id’s and $spec.

As always the complete script can be found at Github where it will also be updated. This is how it looks in the end:


After the comment below I decided to create the script to delete all desktops in a certain state. It’s a variation of the script above, just a bit shorter. Again it can be found on Github. Please be aware that due to a limitation in get-hvmachine both these scripts will only handle 1000 desktops at a time. It is safe to just repeat the script to do the rest.

Creating local ESXi user in a locked down situation and add it to exception list

So my customer asked for a solution to add local users on ESXi hosts that are in lockdown mode. A side quest was to add these to the lockdown exception list. The use case for this is app volumes, they want to be able to keep using them in case the vCenter server goes down. The trick to this that you need to talk to two different viserver entities. The vCenter server and the local ESXi host since you can add those users via vCenter.

Offcourse PowerCLI to the rescue! I decided to do everything in a try catch construction for some error handling and to give some visual output. These cab be stripped if you want but i like some feedback.

Some of the outtakes:

These two disable and enable the current lockdown mode, this is necessary before being able to create the local user.

Some encryption stuff in here but that’s because I dislike having password visible as plain tekst. This first test if the account exists and then sets the password and description. If the user doesn’t exist it will create the user for you.

This gives the newly created or edited user the admin role. If you want to use a custom role this could be added to the script, we decided to go for the admin role since app volumes needs an awful lot of rights anyway. In that case i would recommend to use a variable for role name and create it per host using new-VIrole

This simply adds the user to the lockdown exception list.

So now the complete script:

Future versions of this script will not be edited on here so always check the latest version on github.


Horizon view vCheck : Pool Overview plugin

So one of the things still missing in the Horizon View vCheck was a plugin that simply gives an overview of all Pools with their status. In short what I am talking about is a translation from this view:

Although this sounds easy there where a lot of challenges for this one. First of all there are three separate pool types: Automated,Manual and RDS and all of them have subtypes like VIEW_COMPOSER,VIRTUAL_CENTER,FULL_CLONES,INSTANT_CLONE_ENGINE,UNMANAGED or RDS and not all of these subtypes are available for all pool types. This gives a lot of options that need to be separated for the pool types. Also the VIRTUAL_CENTER subtype is used for both manually added desktops that reside on a vSphere environment and for an automatic pool creating full clones. The FULL_CLONES subtype I haven’t been able to create in my lab yet.

Further outputs like true, false or any of the subtypes above weren’t clear enough for me to use as output. For this I learned a new trick in my book called switch.

Some documentation for the switch command can be found here but what it in short does is match the variable u use as input and sets or gives some output based on that. Also it can do a comparison as in above example so I was able to distinguish between Full Clones and Manually Added vCenter Managed Desktops. One thing to be aware of is that it will go trough the complete list. At first I had the two lines with the comparison in it at the top but that got overwritten since below it VIRTUAL_CENTER was recognized and the $sourceoutput would be based on that.

The Automated and Manual pools use a very similar set of code, the biggest difference is that one gets the data from the AutomatedDesktopData propertywhile the other gets it from the manualdesktopdata property.

The RDS block gives a totally different view though. The information had to be pulled from the farms that are the backend for the desktops.

And when done I ended up with the following script. As usual it might get some improvements or I need to squash some bug so better check the latest version on Github.

And a screenshot of the result:

VMworld EU 2017 Day 3

Day three, the last one, was a short day for me this year. I had an appointment with the VMware Design studio at 8am but the gates didn’t open until 8 as well and I had to drop my suitcase first so I rescheduled it to 9.15 while talking to the guy that I would have the session with! After this I decided to go to the vmtn area to finish up my powerpoint for the vBrownbag I would be doing by noon. I kept changing and changing stuf and somehow managed to remove the one slide you need when generating output: the output itself. Also during the presentation I never got into a good flow so I wasn’t happy with the end result. After this there where some rumors about horrible queues at the airport so I scrambled to get there but in the end the line to drop off my suitcase took longer then security.

VMworld EU Hackaton join me to have some View vCheck fun!

So for a long time I have been looking forward to the VMworld EU Hackaton. The announcement has now been made and it will take place on Monday evening the 11th from 6pm to officially 10pm but my guess is that it might run a little longer 😉 It will be held at the Valkiria Hub Space and you can join as a member of mine or another team or as spectator, just schedule the right session in the schedule builder.

My Team

So I have signed up to lead a team to improve and expand the Horizon View vCheck I have been building. Since this probably also wil involve the Horizon View Community module I wouldn’t be too surprised if improvements will be made to that as well.

Who am I looking for?

For my team i don’t care how much experience you have with PowerCLI or Horizon view but it might be handy if you at least have some idea when we talk about it. Just bring your laptop and if we end up having learned something by the end of the night it has been a success for me!

Do I need something installed on my laptop?

Yes, make sure PowerCLI (at least 6.5) has been installed and your favorite script editor. I will prepare the connection brokers, composers and other vm’s on my laptop.

Anything else?

Just have fun!