Skip to content

Archive

Category: XenApp

continue reading…

continue reading…

continue reading…

There’s a great blog post on the Citrix community website that provides answers to FAQs related to the XenApp CTP. The blog provides the following code to find down or disconnected sessions.

$sessions = Get-XASession
foreach($session in $sessions){
    if($session.Protocol -eq "Ica" -and $session.State -ne "Listening" -and $session.State -ne "Active")
    {
        Write-Host $session.SessionName $session.ServerName $session.AccountName $session.BrowserName $session.State $session.Protocol
    }
}

I decided to test the code out but I only got a list of disconnected sessions.

I modified the code to display all sessions on “MyServer”.

Get-XASession | where-object{$_.ServerName -eq "MyServer"} | ft SessionId,SessionName,ServerName,AccountName,State -AutoSize

I ran the code against a server with a hung down session. I got a list of active and disconnected sessions which is similar to the output from the “Citrix blog” script. The down session and the RDP/ICA “listeners” weren’t returned from the command.

I modified the code…

Get-XASession -ServerName "MyServer" | ft SessionId,SessionName,ServerName,AccountName,State -AutoSize

Now I get a list with the listeners and the down session!

Here’s a comparison of the output.

image

If you’re looking for down sessions make sure you use “Get-XASession -ServerName MyServer”.

Here’s the final tweaked code.

$servers = Get-XAServer -onlineonly -zonename MyZone
foreach($server in $servers){
  $sessions = Get-XASession -ServerName $server
  foreach($session in $sessions){
    if($session.Protocol -eq "Ica" -and $session.State -ne "Listening" -and $session.State -ne "Active"){
      Write-Host $session.SessionName $session.ServerName $session.AccountName $session.BrowserName $session.State $session.Protocol
}

Here’s an interesting scenario.

You have a XenApp farm with a published desktop and you need to take down half of the servers for maintenance.  You decide to remove half of the servers from the published desktop and wait for users to trickle off the servers.  You monitor the farm for the next couple of hours and notice the session count for the removed servers is going down.

Everything seems to be going as planned until users start reporting they are not able to logon.

image

You investigate and find that users with disconnected sessions are reporting the problem. 

The problem started when the servers were removed from the published application.

“When attempting to reconnect to a disconnected session in which the server hosting the disconnected session was removed from the list of configured servers. It does not matter if the session was disconnected before or after the server in question was removed from the list of configured servers. When removing a server from a published application, the administrator has made a choice for that application to be disabled from be accessed. Allowing the reconnection to a disconnected session in this scenario, would contradict the administrative action. Administrators should send a message to all users of this application on a given server(s) to save the work and logoff, manually reset the sessions, or connect to the sessions and perform a graceful logoff before removing the server from the application.” CTX106920

To fix the problem add the removed servers back to the published desktop and use a load evaluator to put the servers in “maintenance mode”.

A “maintenance” or “lockdown” load evaluator can be used to increase a XenApp server’s load to 10,000.  XenApp servers with a load of 10,000 are considered fully loaded so new sessions will be directed to servers with a lower load.  The best part is that users will still be able to reconnect to disconnected sessions even if the server load is 10,000.  We can use Powershell to create the load evaluator.

New-XALoadEvaluator -LoadEvaluatorName LOCKDOWN -MondaySchedule 00:00-00:00 -TuesdaySchedule 00:00-00:00 -WednesdaySchedule 00:00-00:00 -ThursdaySchedule 00:00-00:00 -FridaySchedule 00:00-00:00 -SaturdaySchedule 00:00-00:00 -SundaySchedule 00:00-00:00

Assign the load evaluator to your server(s).

Set-XAServerLoadEvaluator -ServerName MyServer -LoadEvaluatorName LOCKDOWN


I created a new farm last week using “chfarm”.  The farm was successfully created but I noticed the new farm was missing administrators.

XenApp Management Console no administrators

I didn’t think it was a problem until I tried to add a farm administrator and I got the error “Could not create administrator”.

A quick search on Google found a CTX article (CTX114603) which provided a workaround.

1. Add a server running Presentation Server 4.0 to the server farm and use the Presentation Server Console to add administrators.

2. Remove the server, if needed. In fact, the Presentation Server 4.0 does not need to be added. It is sufficient to use the Presentation Server Console on a server running Presentation Server 4.0 and simply point it to a Presentation Server 4.5 server.

Really? Presentation Server 4.0?  I can’t even download PS 4.0 because it’s end-of-life. 

Now what? Powershell to the rescue! 

Install the XenApp CTP and use New-XAAdministrator to create a new administrator.

New-XAAdministrator –AdministratorName DOMAIN\User –AdministratorType Full

It’s recommended to elevate the zone election preference on at least two servers in large XenApp farms.  One server’s zone election preference should be set to “most preferred” and the other should be set to ”preferred”.  Most “Citrix people” will refer to those XenApp servers with elevated zone election preferences as the “zone data collectors” or “data collectors”.  The remaining servers in the zone should be set to a lower zone election preference (usually “not preferred”).

More info on IMA and Zone Data Collector Communication

The XenApp Advanced Configuration Tool allows you to change the zone election preference one server at a time. I got tired of torturing myself and figured out how to change the election preference for multiple XenApp servers with Powershell.

Example:

I have a zone with two data collectors.  The data collectors are named XenAppDC01 (most preferrred) and XenAppDC02 (preferred).  I’ve added XenAppDS01 to XenAppDS05 to the farm.  The following Powershell command will move servers that start with “XenAppDS” to “MyZone” and set the election preference to “not preferred”.

Get-XAServer | Where-Object{$_.ServerName.StartsWith("XenAppDS")} | Set-XAServerZone -ZoneName MyZone -ElectionPreference NotPreferred

It looks like this bug is still present in CTP3.


I believe I found a bug in the XenApp Powershell Commands (CTP2) that deletes the farm license server name and changes the port to 7168.

Edgesight alerted us that our XenApp servers were unable to communicate with the license server.

Checked the farm settings and found the following:

Who changed the farm license server setting?!  Someone’s about to feel the swift justice of configuration logging.  And the configuration log said…

WHAT?  This can’t be right.  The config log says I made the change to the farm license server setting!  I did some testing and found the configuration logs were correct.  I did make the change with some help from a bug in the Powershell XenApp commands.

I was running some XenApp Powershell commands this morning and was able to recreate the bug with the following command:

Get-XAServer -zone yourzone -OnlineOnly | Get-XAServerConfiguration

Bye, bye farm license server setting.

Powershell script to check logical disk space across a XenApp farm.  XenApp Powershell commands are required.

#Author: Phil Lindsey
#Website: http://www.ctxfarmer.com
#Last Modified: 11/4/2010

#.\Get-XADiskSpace.ps1 -zone (ZoneName)
param(
  [string]$zone=""
)

Add-PSSnapin Citrix* -ErrorAction SilentlyContinue
$servers = Get-XAServer -ZoneName $zone –OnlineOnly
$all = @()
foreach($server in $servers){
  $all += gwmi -ComputerName $server Win32_logicalDisk | Select-object SystemName,caption,freespace
}
$all | Sort-Object caption,systemname,freespace | out-gridview