Remove desktop assignment

In this blogpost I showed how to assign a certain vdi machine to a user. This has been made easier since in the vmware.hv.helper module. These days we can use this:

get-hvmachine -machinename MACHINENAME | set-hvmachine -user USER@DOMAIN

This week I got the logical question from Brandon Smith in the comments about removing the assignment. First I need to re-assign the desktop (I have been building a VMUG presentation about PowerCLI & Horizon view so things got messed up)

the result:

Now what need to be done is setting the base.user to $null. I am going to do this by connecting to the machine service and utilize the machinehelper to update the userdata.

$machineservice=new-object vmware.hv.machineservice

We now need to connect to the machinehelper by doing a read on the machineservice. $machineservice.read will give us the info we need to be able to do this.

From this it becomes clear that we will need the services service and the machineid we want to edit. First let’s put the machine id into a variable.

$machineid=(get-hvmachine -machinename MACHINENAME).id

Now I will read the properties of this machineid and put this into the $machineinfohelper variable

$machineinfohelper=$machineservice.read($services1, $machineid)

Since I know the user property is under the base we will need to get the base first and then set the user. This done by doing getbasehelper() on the machineinfohelper and then do .setuser(user) on that but let’s see what’s under the getbasehelper first.

$machineinfohelper.getbasehelper() | gm

A lot of information but as said the one we need is setuser. To assign a desktop we will need to set this to a userorgroupid value (and that is what the vmware.hv.helper cmdlet does). To clear it we will need to set it to $null.

$machineinfohelper.getbasehelper().setuser($null)

At this point no changes have been made yet! We will need to apply this update first.

$machineservice.update($services1, $machineinfohelper)

And if we look at the horizon console the entitlement has been removed.

And the complete script:

$hvserver1=connect-hvserver connectionservername
$services1=$hvserver1.extensiondata
$machinename="MACHINENAME"
$machineid=(get-hvmachine -machinename $machinename).id
$machineservice=new-object vmware.hv.machineservice
$machineinfohelper=$machineservice.read($services1, $machineid)
$machineinfohelper.getbasehelper().setuser($null)
$machineservice.update($services1, $machineinfohelper)

As usual the script can be found on github.

Finding Horizon View local entitlements using PowerCLI

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.

 

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.

$spec = New-Object VMware.Hv.machinedeletespec
$spec.deleteFromDisk=$TRUE

$desktops=@()
$desktops=get-hvmachine -state $targetstate
$selectdesktop=@()
foreach ($desktop in $desktops){
    $selectdesktop+= New-Object PSObject -Property @{"Name" = $desktop.base.name
    "ID" = $desktop.id;
    }
}

$selectdesktop=write-menu -menu ($desktops.base.name) -header "Select the desktop you want to remove"
$removedesktop=$desktops | where {$_.base.name -eq $selectdesktop}


try {
	$services1.machine.machine_delete($removedesktop.id, $spec)
	#$services1.machine.machine_reset($removedesktop.id, $spec)	
	write-host "$selectdesktop will be marked for deletion" -ForegroundColor Green
}
catch {
	write-host "Error deleting $selectdesktop" -ForegroundColor Red
}

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

Update

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.

https://github.com/Magneet/Various_Scripts/blob/master/remove_faulty_VDI_desktop.ps1

https://github.com/Magneet/Various_Scripts/blob/master/remove_multiple_faulty_VDI_desktops.ps1

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.

switch ($source)
		{
			VIRTUAL_CENTER {$sourceoutput="vCenter Managed Desktop"}
			FULL_CLONES {$sourceoutput="Full Clones"}
			VIEW_COMPOSER {$sourceoutput="Linked Clones"}
			INSTANT_CLONE_ENGINE {$sourceoutput="Instant Clones"}
			UNMANAGED {$sourceoutput="Non-vCenter Desktops"}
			RDS {$sourceoutput="RDS Desktops"}
			{$_ -eq "VIRTUAL_CENTER" -AND $pool.type -eq "Automated"} {$sourceoutput="Full Clones"}
			{$_ -eq "VIRTUAL_CENTER" -AND $pool.type -eq "MANUAL"} {$sourceoutput="Manually Added vCenter Managed Desktops"}
			default {$sourceoutput="No Source data available"}
		}

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.

	if ($pool.type -eq "Automated"){
		$Automaticassignment=$pool.AutomatedDesktopData.UserAssignment.AutomaticAssignment
		switch ($Automaticassignment)
		{
			$TRUE {$Automaticassignmentoutput="Automatic"}
			$FALSE {$Automaticassignmentoutput="Manual"}
			default {$Automaticassignmentoutput="No Assignment Status Available"}
		}
		$Pooloverview+=New-Object PSObject -Property @{"Name" = $pool.base.name;
			"Displayname" = $pool.base.DisplayName;
			"Description" = $pool.base.Description;
			"Status" = $poolstatusoutput;
			"Provisioning" = $ProvisioningStatusoutput;
			"Type" = $pool.type;
			"Source" = $sourceoutput;
			"User_Assignment" = $pool.AutomatedDesktopData.UserAssignment.userassignment;
			"Assignment_Type" = $Automaticassignmentoutput;
			}
		}
	elseif ($pool.type -eq "MANUAL"){
		$Automaticassignment= $pool.manualdesktopdata.UserAssignment.AutomaticAssignment
		switch ($Automaticassignment)
		{
			$TRUE {$Automaticassignmentoutput="Automatic"}
			$FALSE {$Automaticassignmentoutput="Manual"}
			default {$Automaticassignmentoutput="No Assignment Status Available"}
		}
		$Pooloverview+=New-Object PSObject -Property @{"Name" = $pool.base.name;
		"Displayname" = $pool.base.DisplayName;
		"Description" = $pool.base.Description;
		"Status" = $poolstatusoutput;
		"Provisioning" = $ProvisioningStatusoutput;
		"Type" = $pool.type;
		"Source" = $sourceoutput;
		"User_Assignment" = $pool.manualdesktopdata.UserAssignment.UserAssignment;
		"Assignment_Type" = $Automaticassignmentoutput;
			}
		}

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.

	elseif ($pool.type -eq "RDS"){
		$source=($services1.farm.farm_get($pool.rdsdesktopdata.farm)).source
		$ProvisioningStatus=($services1.farm.farm_get($pool.rdsdesktopdata.farm)).automatedfarmdata.VirtualCenterProvisioningSettings.enableprovisioning
		switch ($source)
		{
			VIEW_COMPOSER {$sourceoutput="Linked Clones RDS Hosts"}
			INSTANT_CLONE_ENGINE {$sourceoutput="Instant Clones RDS Hosts"}
			default {$sourceoutput="Manually Added RDS Hosts"}
		}

		switch ($ProvisioningStatus)
		{
			$True {$ProvisioningStatusoutput="Enabled"}
			$False {$ProvisioningStatusoutput="Disabled"}
			default {$ProvisioningStatusoutput="N/A"}
		}

		$Pooloverview+=New-Object PSObject -Property @{"Name" = $pool.base.name;
		"Displayname" = $pool.base.DisplayName;
		"Description" = $pool.base.Description;
		"Status" = $poolstatusoutput;
		"Provisioning" = $ProvisioningStatusoutput;
		"Type" = ($services1.farm.farm_get($pool.rdsdesktopdata.farm)).type;
		"Source" = $sourceoutput;
		"User_Assignment" = "N/A";
		"Assignment_Type" = "N/A";
			}
		}

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.

# Start of Settings
# End of Settings

$Pooloverview=@()
foreach ($pool in $pools){
	$poolstatus=$pool.DesktopSettings.Enabled 
	$ProvisioningStatus=$pool.AutomatedDesktopData.VirtualCenterProvisioningSettings.enableprovisioning
	$source=$pool.source
	switch ($poolstatus)
		{
			$True {$poolstatusoutput="Enabled"}
			$False {$poolstatusoutput="Disabled"}
			default {$poolstatusoutput="No Pool Status available"}
		}

	switch ($ProvisioningStatus)
		{
			$True {$ProvisioningStatusoutput="Enabled"}
			$False {$ProvisioningStatusoutput="Disabled"}
			default {$ProvisioningStatusoutput="No Pool Provisioning Status available"}
		}

	switch ($source)
		{
			VIRTUAL_CENTER {$sourceoutput="vCenter Managed Desktop"}
			FULL_CLONES {$sourceoutput="Full Clones"}
			VIEW_COMPOSER {$sourceoutput="Linked Clones"}
			INSTANT_CLONE_ENGINE {$sourceoutput="Instant Clones"}
			UNMANAGED {$sourceoutput="Non-vCenter Desktops"}
			RDS {$sourceoutput="RDS Desktops"}
			{$_ -eq "VIRTUAL_CENTER" -AND $pool.type -eq "Automated"} {$sourceoutput="Full Clones"}
			{$_ -eq "VIRTUAL_CENTER" -AND $pool.type -eq "MANUAL"} {$sourceoutput="Manually Added vCenter Managed Desktops"}
			default {$sourceoutput="No Source data available"}
		}

	if ($pool.type -eq "Automated"){
		$Automaticassignment=$pool.AutomatedDesktopData.UserAssignment.AutomaticAssignment
		switch ($Automaticassignment)
		{
			$TRUE {$Automaticassignmentoutput="Automatic"}
			$FALSE {$Automaticassignmentoutput="Manual"}
			default {$Automaticassignmentoutput="No Assignment Status Available"}
		}
		$Pooloverview+=New-Object PSObject -Property @{"Name" = $pool.base.name;
			"Displayname" = $pool.base.DisplayName;
			"Description" = $pool.base.Description;
			"Status" = $poolstatusoutput;
			"Provisioning" = $ProvisioningStatusoutput;
			"Type" = $pool.type;
			"Source" = $sourceoutput;
			"User_Assignment" = $pool.AutomatedDesktopData.UserAssignment.userassignment;
			"Assignment_Type" = $Automaticassignmentoutput;
			}
		}

	elseif ($pool.type -eq "MANUAL"){
		$Automaticassignment= $pool.manualdesktopdata.UserAssignment.AutomaticAssignment
		switch ($Automaticassignment)
		{
			$TRUE {$Automaticassignmentoutput="Automatic"}
			$FALSE {$Automaticassignmentoutput="Manual"}
			default {$Automaticassignmentoutput="No Assignment Status Available"}
		}
		$Pooloverview+=New-Object PSObject -Property @{"Name" = $pool.base.name;
		"Displayname" = $pool.base.DisplayName;
		"Description" = $pool.base.Description;
		"Status" = $poolstatusoutput;
		"Provisioning" = $ProvisioningStatusoutput;
		"Type" = $pool.type;
		"Source" = $sourceoutput;
		"User_Assignment" = $pool.manualdesktopdata.UserAssignment.UserAssignment;
		"Assignment_Type" = $Automaticassignmentoutput;
			}
		}	

	elseif ($pool.type -eq "RDS"){
		$source=($services1.farm.farm_get($pool.rdsdesktopdata.farm)).source
		$ProvisioningStatus=($services1.farm.farm_get($pool.rdsdesktopdata.farm)).automatedfarmdata.VirtualCenterProvisioningSettings.enableprovisioning
		switch ($source)
		{
			VIEW_COMPOSER {$sourceoutput="Linked Clones RDS Hosts"}
			INSTANT_CLONE_ENGINE {$sourceoutput="Instant Clones RDS Hosts"}
			default {$sourceoutput="Manually Added RDS Hosts"}
		}

		switch ($ProvisioningStatus)
		{
			$True {$ProvisioningStatusoutput="Enabled"}
			$False {$ProvisioningStatusoutput="Disabled"}
			default {$ProvisioningStatusoutput="N/A"}
		}

		$Pooloverview+=New-Object PSObject -Property @{"Name" = $pool.base.name;
		"Displayname" = $pool.base.DisplayName;
		"Description" = $pool.base.Description;
		"Status" = $poolstatusoutput;
		"Provisioning" = $ProvisioningStatusoutput;
		"Type" = ($services1.farm.farm_get($pool.rdsdesktopdata.farm)).type;
		"Source" = $sourceoutput;
		"User_Assignment" = "N/A";
		"Assignment_Type" = "N/A";
			}
		}
}

$Pooloverview | select Name,Displayname,Description,Status,Provisioning,Type,Source,User_Assignment,Assignment_Type
$Title = "Overview of all Pools"
$Header = "Overview of all Pools"
$Comments = "Gives an overview of the general status of all pools"
$Display = "Table"
$Author = "Wouter Kursten"
$PluginVersion = 0.1
$PluginCategory = "View"

And a screenshot of the result:

New VMware fling: View Client Resizer

I must have missed i during the holiday season but VMware has released a new fling: the View Client Resizer. It’s a simple fling that let’s you easily select any resolution you want to check your VMware Horizon View environment on to see how it behaves. The steps below I have done on a 2-screen setup.

  1. First you go to https://labs.vmware.com/flings/view-client-resizer and download the zip file
  2. Next unpack the zip file
  3. Start the executable
  4. Start the Horizon View client and open a VDI session
  5. Push refresh in the tool and it wil show the active sessions in the pulldown menu
  6.  
  7. Click resize and the session wil go to the top left corner of the Primary monitor in that resolution.

You can pick any of the default resolutions or make one up (smartphone resolutions for example ) as long as the x is between the digits with a minimum right now it seems of 800*600

 

Beware of MS KB3170455 with Windows 7 floating desktops

Yes I know 3170455 was released last summer but early last month when I released our new golden image we ran into a problem with this update. What happened was that users had problems with some printers. When adding them they got this warning:

8787-image-9_76cbef13

(This is an example picture, I believe Xerox has proper drivers now)

And when they logged in to a fresh desktop they couldn’t print and when we checked their printer it said it needed drivers.

923154

What I found was that this only happened with drivers of the non packaged type. Microsoft has been pushing to use packaged drivers ever since Windows Vista came out but apparently some manufacturers stil use older style not supported drivers. This is easily checked when you go into Print management and have included the column packaged.

2016-12-11-19_45_17-beheer-desktop

Microsoft has been giving these warnings for a while but up until this kb there was a workaround by setting this group policy setting:

Computer Configuration>Policies> Administrative Templates>Printers>Point and Print Restrictions from Not Configured to Disabled or enabled with some settings.

2016-12-11-19_37_12-beheer-desktop

With this KB installed and probably also with he other kb’s for other OS mentioned in the accompanying security bulletin: https://technet.microsoft.com/library/security/MS16-087 Windows ignores this setting and gives the warning anyway. For most systems clicking the allow once won’t be a big issue but when you have floating desktops where the printers get added every logon this is an issue so please be aware of this!