Scripts to Monitor XenDesktop

 

To ensure our XenDesktops are up and functional for the day I have created a morning check script perform this task. The check will look for:

  • UNREGISTERED MACHINES
  • REGISTERED MACHINES
  • MACHINES IN MAINTENANCE MODE
     

Ideally we will only see machines that in the REGISTERED category. Here is the PowerShell script that was created and run from the Desktop Delivery Controller

Reference

XenDesktop Monitoring: Desktop Availability

http://blogs.citrix.com/2012/10/27/xendesktop-monitoring-desktop-availability/

 

#
# XenDesktop Monitoring: Desktop Availability
# Created March 1 2013 – Trevor Svienson
# Written by – Miguel Contreras Citrix
# Load Citrix PowerShell modules
#

# Set-ExecutionPolicy RemoteSigned

#
# Load the XenDesktop Snapins
#

Asnp Citrix.*

#
# Check VMs that failed to reboot
#

$badVMs = Get-BrokerDesktop -PowerActionPending $false -PowerState On -SummaryState Available -WillShutdownAfterUse $true -MaxRecordCount 5000
If ($badVMs)
{
   foreach($vm in $badVMs)
   {
      New-BrokerHostingPowerAction -MachineName $vm.HostedMachineName -Action ‘Reset’
   }
}

#
#Check for VMs in maint mode and unregistered, and send email report
#

$recipients = "alert.citrix@svi-virtualsolutions.com"
$fromEmail = "XenDesktopProd@svi-virtualsolutions.com"
$server = "mail.svi-virtualsolutions.com"
$time = Get-Date ?format d

[string]$unregisteredVMs = (Get-BrokerDesktop -MaxRecordCount 5000 | ? {($_.RegistrationState -eq ‘Unregistered’) -and ($_.PowerState -eq ‘On’)} | select HostedMachineName,DesktopGroupName,LastDeregistrationReason | ft -wrap -autosize | Out-String)

[string]$registeredVMs = (Get-BrokerDesktop -MaxRecordCount 5000 | ? {($_.RegistrationState -eq ‘Registered’) -and ($_.PowerState -eq ‘On’)} | select HostedMachineName,DesktopGroupName,LastDeregistrationReason | ft -wrap -autosize | Out-String)

[string]$maintenanceModeVMs = (Get-BrokerDesktop -MaxRecordCount 5000 | ? {$_.InMaintenanceMode -eq ‘True’} | select HostedMachineName,DesktopGroupName,LastDeregistrationReason | ft -wrap -autosize | Out-String)

[string]$emailBody = "UNREGISTERED MACHINES `n`n`n $unregisteredVMs" + "REGISTERED MACHINES `n $registeredVMs" + "`n" + "MACHINES IN MAINTENANCE MODE `n $maintenanceModeVMs"

#
#Send it off
#

send-mailmessage -from $fromEmail -to $recipients -subject "XenDesktop Prod Daily Check $currentTime" -body $emailBody

Here is the end result via email:

UNREGISTERED MACHINES
REGISTERED MACHINES
HostedMachineName DesktopGroupName LastDeregistrationR
eason
—————– —————- ——————-
WINDOWS764MCS01 MCS – Pooled  Windows 7 x64 AgentShutdown
WINDOWS764MCS02 MCS – Pooled  Windows 7 x64 AgentShutdown
WINDOWS764MCS03 MCS – Pooled  Windows 7 x64 AgentShutdown
WINDOWS764MCS04 MCS – Pooled  Windows 7 x64 AgentShutdown
WINDOWS764MCS05 MCS – Pooled  Windows 7 x64 AgentShutdown
WINDOWS764MCS06 MCS – Pooled  Windows 7 x64 AgentShutdown
WINDOWS7UAT999 MCS – Windows 7 x64 – Master AgentShutdown
WINDOWS764NPX001 VDI – Windows 7 x64 – AssetGen Prod AgentShutdown
WINDOWS764NPX002 VDI – Windows 7 x64 – AssetGen Dev AgentShutdown
WINDOWSMCS101 MCS – Pooled  Windows XP x86 AgentShutdown
WINDOWSMCS103 MCS – Pooled  Windows XP x86 AgentShutdown
WINDOWSMCS104 MCS – Pooled  Windows XP x86 AgentShutdown
WINDOWSMCS105 MCS – Pooled  Windows XP x86 AgentShutdown
WINDOWSMCS107 MCS – Pooled  Windows XP x86 AgentShutdown
WINDOWSMCS108 MCS – Pooled  Windows XP x86 AgentShutdown
WINDOWSMCS998 MCS – Windows XP x86 – Master ContactLost
WINDOWSVDIPRD001 VDI – Windows XP x86 – Image Now AgentShutdown
WINDOWSVDIPRD002 VDI – Windows XP x86  ContactLost
MACHINES IN MAINTENANCE MODE
HostedMachineName DesktopGroupName LastDeregistrationR
eason
—————– —————- ——————-
WINDOWSMCS107 MCS – Pooled  Windows XP x86 AgentShutdown
WINDOWSMCS108 MCS – Pooled  Windows XP x86 AgentShutdown

 

The script calls CheckForVMsInMTCMode.ps1 is located on the DDC in C:\tools folder. The script is run as a scheduled task which launches at 7 am daily.

Here is how the task is configured on the DDC:

Inside the daily task this is the Action. Simply launches PowerShell and then a command argument for launching the file:

SNAG-0059

Here is a more closer look at the argument:

SNAG-0060

Also remember to add the "rights" to run the file.

image

Testing the Script

In order to get this to work I ran some tests to see if this would work. A good references to do this is

Weekend Scripter: Use the Windows Task Scheduler to Run a Windows PowerShell Script
http://blogs.technet.com/b/heyscriptingguy/archive/2012/08/11/weekend-scripter-use-the-windows-task-scheduler-to-run-a-windows-powershell-script.aspx

SNAG-0064

From the DDC I opened a run command and typed this

SNAG-0065

As you can see from the screen cap above I was receiving an "Insufficient administrative privilege" message which simply meant I did not have enough privileges to run the XenDesktop cmdlet. I had to elevate my privileges in order for this to complete from the run command. I also had to do the same in the daily task:

image

Another reference to run PowerShell from a daily task.

Run PowerShell Scripts from Task Scheduler
http://community.spiceworks.com/how_to/show/17736-run-powershell-scripts-from-task-scheduler

BSOD, PVS, XenServer and Pooled Desktop

 

I was investigating as to why I had a VM that was not registering with the DDC during a morning check. When I checked the XenCenter console I observed this message:

XenCenter_2013-11-01_08-46-43

After some investigation I found I was not the only one having this issue:

http://forums.citrix.com/thread.jspa?threadID=305300

Based on the advice given in the forum I found that in  DHCP the IP was being assigned but eventually the BSOD was happening.

Remote%20Desktops_2013-11-01_08-36-33

I could not locate another VM with the same IP. So to correct issue I:

  • Deleted the above IP assigned in DHCP
  • I then created a reservation for the VM by doing a standard reservation in DHCP:

image

 

image

  • Once I did this I restarted the VM and the Desktop resumed normal operation.
  • As well based on the user forum I also changed the DHCP scope to an Unlimited lease time.

 

image

XenApp AppCenter Snap-in Permissions granted via GPO’s

 

Another example where GPO preferences are awesome – Citrix AppCenter Administrative delegation

I granted the helpdesk access to AppCenter via group membership <domain>\citrix_desktop director. However when users launch the application they would get this message:
 

gpo1
 

What this indicates is that the MMC policy snap-in restrictions was happening that are locked down on the XenAppp server. Not everyone has MMC access due to it being a shared desktop and non admins should not have access to certain .msc snap-ins such as Diskmgmt.msc or eventvwr.msc to name a couple.
What we need to do is allow the snap-in features to work for managing XenApp to a certain group of users which we do this via group policy. After some research I found the snap-ip ID’s for Citrix XenApp AppCenter as well as the related snap-ins. They are:

AppCenter Snapin : {00000009-E873-47a9-B9C9-10B2A50327CB}

XenApp Extension : {46BADCE7-337E-4834-9800-3244567688FC}

Citrix Hotfix Inventory Extension : {8E917BCC-05C5-4aeb-8EF7-0842397BB0ED}

Single Sign-On Console : {E93B8960-45DB-4418-84CA-B4364FB9676A}

I open GPO management and now add entries for all ID’s above under:
HKU\ Software\Policies\Microsoft\MMC\{00000009-E873-47a9-B9C9-10B2A50327CB}

gpo2

In the end it looks like this  as here is are the preferences configured in the GPO
 
 gpo3

I also only target certain groups as I don’t want everyone to have this in their profile

image

 

Once the user logged back on and the preferences applied they were able to launch the MMC but there were still underlying permissions within XenApp:
 
 image
 

The permissions within XenApp did not allow them to discover items in the farm. So I granted permission in the Farm for access. This group will need Admin access to administer the farm but one can limit what is managed per group or user.

 
 image