Monitor Citrix License Usage With PowerShell

WMI in Windows Server is a treasure trove of information and well worth investigating, particularly when needing to run reports against many servers. In addition it is possible for third-parties to make use of WMI and store their own information in there. This is true of a recent requirement I had to monitor Citrix Licensing.

Whilst it’s obviously critical to purchase enough licenses for Citrix that you need, its also important to not have too many lying around not in use, since you’ll be wasting money.  Given that Citrix Licensing is based on concurrency you may have different usage patterns at the time of day, month or year.

Contained within the WMI Namespace ROOT\CitrixLicensing is a class Citrix_GT_License_Pool. In this class you can find details for registered licenses and how many are in use. The PowerShell cmdlet Get-WMIObject can be used to retrieve this information. Once you have it you could save the report into a CSV file, write an entry to an event log or send an email alert.

The below example will generate an email alert when then level of licenses in use goes over 90%. The email will contain basic details of how many licenses are currently in use.

<#
.SYNOPSIS
 Report on Citrix License Usage
.DESCRIPTION
 Report on Citrix License Usage
.NOTES
 Authors:Jonathan Medd
.PARAMETER CitrixLicenseServer
 Name of Citrix License Server
.EXAMPLE
 Get-CitrixLicenseUsage -CitrixLicenseServer Server01
#>
param (
 [parameter(Mandatory=$True,HelpMessage='Name of Citrix License Server')]
 $CitrixLicenseServer
 )

# Get Citrix Licensing Info from WMI
$LicensePool = Get-WmiObject -class "Citrix_GT_License_Pool" -Namespace "ROOT\CitrixLicensing" -ComputerName $LicenseServer

# Calculate licenses in use, total number of licenses and percentage currently in use
$InUseNum = ($LicensePool | Measure-Object -Property InUseCount -sum).Sum
$InstalledLicNum = ($LicensePool | Measure-Object -Property Count -sum).Sum
$PercentageNum = [math]::round(($InUseNum/$InstalledLicNum)*100,2)

# Check the usage and send an email if over 90%
if ($PercentageNum -lt 90)
{
}
else
{
Send-MailMessage -To "user@domain.com" -Subject "Citrix License Server Statistics For $CitrixLicenseServer" -Body "The below is the current status of the license server:`n`nInstalled Licences: $InstalledLicNum`n`nLicences In Use: $InUseNum`n`nPercentage: $PercentageNum%" -SmtpServer "smtpserver" -From "user@domain.com"
}

sdf

Running Outlook 2003 in TS or Citrix and Planning an Upgrade to Exchange 2010?

Outlook 2003 is listed as a supported client for Exchange 2010 with the following caveats:

• Clients running Outlook 2003 don’t use RPC encryption, which RPC Client Access requires by default. You will either need to turn off the RPC encryption requirement or configure Outlook 2003 to use RPC encryption. However, Outlook 2007 and later versions are automatically compatible with the change to RPC Client Access because they support RPC encryption by default. For more information, see Understanding RPC Client Access.
• On clients running Outlook 2003, you may notice that folder updates don’t occur automatically in a timely manner. This situation occurs because User Datagram Protocol (UDP) notifications aren’t supported in Exchange 2010. For more information about resolving this issue, see Knowledge Base article 2009942, In Outlook 2003, e-mail messages take a long time to send and receive when you use an Exchange 2010 mailbox. However, Outlook 2007 and Outlook 2010 are automatically compatible with this change.

Having now witnessed the impact of the second issue it could cause you a big issue if you are running Outlook 2003 in Terminal Services or Citrix. The KB article 2008842 suggests two options:

• Make a registry interval to reduce the polling time from 60 seconds to a lower value, 10 is the minimum
• Use Outlook’s Cached Exchange mode

Having made the registry change down to 10 seconds the phrase from above ‘…..folder updates do not occur in a timely manner’ is pretty diplomatic! I think most people could live with an email sitting in the Outbox for a few seconds or being delivered within seconds rather than instantaneously. However, deleting an email and it then not dissapearing for up to 10 seconds is a real issue. It feels like it didn’t work, so naturally you press the delete key again and this time you are presented with an error because that item no longer exists. The whole experience with this refresh issue is pretty poor.

Whilst Outlook’s Cached Exchange mode is a very common deployment method for laptops and desktops (if not the standard these days) you cannot use it when running Outlook 2003 in Terminal Services or Citrix.

The final option is an upgrade to Outlook 2007 / 2010 which might not be a big deal in some organisations, in others it will involve significant work and planning.

It appears that there is unlikely to be a better fix either. Further details already written up very well here.

Update 05/11/2010

The KB article has been updated to reflect the fact that the minimum value can actually be set to 5 seconds not 10. Whether that is an acceptable value for your environment is another matter.

Update 01/02/2010

So it looks like enough customer pressure has been placed and the Exchange Team have just announced that UDP support for Outlook 2003 will be available for Exchange 2010 in Roll-up 3 for SP1. This means you can now consider Outlook 2003 in Terminal Services as a viable client for Exchange 2010 again.

Virtualising Citrix on VMware

I was lucky enough to take on a project initially started and blogged about by my co-host on the Get-Scripting podcast Alan Renouf.

In summary, his posts were mainly around the design decision of whether to go for VM’s with one or two vCPU’s and how many Citrix users you could support per VM.  Following on from his initial testing using Citrix Edgesight we ran a pilot with a few different scenarios and it turned out that the best performance with the highest number of Citrix users per VM came out to be a VM with 2 x vCPU’s; a conclusion which didn’t really match the initial testing, I guess you can’t beat real users doing real work and the sometimes crazy things they get up to pushing the boundries of performance.

A number of other decisions were also made at this time, most of which contributed to other significant cost savings on top of those we were going to achieve simply by reducing the number of physical boxes used to host the Citrix environment.

Something else which came out of the pilot was a decision to store the VM’s on local storage not SAN. Whilst this obviously reduces the flexibility offered by a virtualisation solution with shared storage, which gives options like VMotion, DRS etc, the cost savings gained by using local storage were very significant. Not only did we have none of the charges associated with SAN storage (fibre cards, cabling, switch ports, SAN disk) we could deploy the hosts with ESX Foundation licenses. From a redundancy and maintenance point of view we designed it so that we could afford to lose more than one host for a period of time and still have enough capacity to provide a good service.

We deployed four VM’s per ESX host, i.e. 8 cores available to 8 x vCPU’s. (Note: I have recently read Duncan Epping’s post around how many cores you should specify when using CPU affinity. It makes for interesting reading, thankfully we are not currently seeing any issues around what might arise from this)

During the pilot and the early part of the rollout we found we were able to happily achieve around 45 users per VM, i.e. up to 180 per ESX host with CPU levels on the host comfortably averaging below the 75% mark. As the rollout progressed and we retired the physical Citrix boxes the levels attracted by each VM were more typically around the 40 users mark, i.e. approx 160 users per physical host.

This was because we were able to replace three physical Citrix boxes with one ESX host containing four Citrix VM’s, so a 3 – 1 reduction physical, but a 25% increase in the number of Citrix servers which obviously means you naturally attaract less users per Citrix server with a consistent number of users.  However, since we deployed 2 x vCPU machines it also meant cost savings with half the required Windows VM’s over the original plan to deploy 1x vCPU VM’s which would have meant eight Citrix VM’s per host.

One issue we did experience was that of vCPU peaks from rogue user processes which would hog all the CPU for significant periods of time and give a bad experience to other users on that VM. This was believed to happen previously in the physical Citrix deployemnt, but was more easily masked by the availability of physical cores. Most typically these processes would be Internet Explorer, quite often accessing Flash based content. To mitigate this issue we used some application threading software on each VM to set maximum levels for CPU usage per user process. This performed very well by limiting these processes to a certain amount of vCPU and consequently not impacting other Citrix users’ performance – the decision to use 2 x vCPU’s in a VM helped here too, the 1x vCPU VM’s in the pilot really suffered with this problem.

Counting the Number of Sessions Per Citrix Server

Whilst monitoring some newly provisioned Citrix servers running on VMware hosts today, I soon became very bored with manually checking how many sessions were on each Citrix VM as the load on each one increased, whilst trying to get it to the optimum level.

I knew it was possible to use Powershell to connect with Citrix servers, but had never really looked into it before. Not surprisingly it turned out to be very straightforward.

By using some technology known as MFCom we can connect with the Citrix farm and get some cool information out.

In the below example we create a new com object using MFCom, then initialise the connection. We are then able to access some methods and properties of that object. In this case we are looking at the Sessions property, we group all of the results by ServerName and then produce some output with the name and number of sessions on that Citrix box.

$farm = New-Object -com "MetaframeCOM.MetaframeFarm"$farm.Initialize(1)$farm.Sessions | Group-Object ServerName | Sort-Object name | Format-Table Name,Count -auto

which will give you something like:

Name Count

CitrixServer01 38
CitrixServer02 45
CitrixServer03 41

This would return all of the servers in the farm. In this particular instance I only wanted a particular selection of servers, so I stored them in a text file, got PS to read that file and then filter the query by only looking at servers in that list.

$servers = Get-Content c:\scripts\servers.txt

$farm = New-Object -com "MetaframeCOM.MetaframeFarm"$farm.Initialize(1)$farm.sessions | Where-Object {$servers -contains $_.ServerName} | Group-Object ServerName | Sort-Object name | Format-Table Name,Count -auto

Once again Powershell very easily gets rid of a really dull manual task.

If you wish to take this a step further check out Powershell MVP Brandon Shell’s blog where he has loads of Powershell / Citrix examples.

http://bsonposh.com/archives/tag/citrix