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 username@fulldomainname.
For example
get-hventitlement -user magneet.lab\user1
or
get-hventitlement -user user1@magneet.lab
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
get-hventitlement -user user1@magneet.lab
If you put this between brackets followed by a period and one of the properties a bit more info is shown.
(get-hventitlement -user user1@magneet.lab).base
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
(get-hventitlement -user user1@magneet.lab).localdata
Very good, a lot of id’s so what can we do with those? For now I will put this into $entitledids.
$entitledids=(get-hventitlement -user user1@magneet.lab).localdata
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.
