Intro

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 [email protected]

For example

get-hventitlement -user magneet.lab\user1

or

Both work but

get-hventitlement -user magneet\user1

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

At least

get-hventitlement -user user1

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.

get-help get-hvinternalname -examples

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.

foreach ($Entityid in ($entitledids.machines)){get-hvinternalname $Entityid}

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

foreach ($Entityid in ($entitledids.desktops)){get-hvinternalname $entityid} foreach ($Entityid in ($entitledids.desktopuserentitlements)){get-hvinternalname $entityid} foreach ($Entityid in ($entitledids.aplicationuserentitlements)){get-hvinternalname $entityid} foreach ($Entityid in ($entitledids.applications)){get-hvinternalname $entityid}

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:

foreach ($Entityid in ($entitledids.machines)){($services1.machine.machine_Get($Entityid)).base}

Conclusion

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.