ctxfarmer

continue reading…

continue reading…

continue reading…

continue reading…

I installed XenServer 5.6 SP2 today in my lab.  No problems!  Looks like Citrix addressed the Realtek RTL8111/8168B issues from XenServer FP1.

Get-WmiObject Win32_NetworkAdapter | Where-Object {$_.NetConnectionStatus -eq 7} | % {$_.Disable()}

Here’s a Powershell script that can be used to perform a simple unattended installation of the Citrix Web Interface. 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.

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
}

I get this error message when I use Invoke-Command to execute a script block on a remote server.

Invoke-Command –Credential (Get-Credential) –ComputerName MyRemoteServer –ScriptBlock {Get-Date}

I set $PSSessionOption.NoMachineProfile=$true to fix the problem before executing Invoke-Command.

$PSSessionOption.NoMachineProfile=$true
Invoke-Command –Credential (Get-Credential) –ComputerName MyRemoteServer –ScriptBlock {Get-Date}

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.

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