Citrix Chained Reboot Scripts, now supporting XenApp 5, 6, 6.5 and XenDesktop 7.0, 7.1, 7.5, 7.6, and 7.7!

Share Button

Updated 12/28/2015: Revision 8 validated for XenApp and XenDesktop 7.7 support!

Click Accept to Download:

 I Accept the Terms and Conditions provided on the Copyright and Disclaimer page.

In zero-downtime 24/7 environments with shift employees, customers rarely want users to be notified of scheduled or mandatory XenApp server reboots. As a result, most of these environments have reboots disabled or this process is done manually. Unfortunately, this isn’t a good process since the XenApp servers are susceptible to memory leaks which can lead to failure and poor performance. By utilizing the included Chained reboot scripts, environments can take advantage of N+1 overallocation by processing a single server reboot while maintaining the user load on remaining systems. This has been done in such a way that users are not kicked off the system for scheduled reboots.  Instead, the server is removed from load balancing until all sessions have been logged off. Once all sessions have been logged off, the server will go down for a reboot.

After the reboot has been processed, a procedure will validate that the server has returned from the reboot properly and the load has reevaluated under 5000. This way, if there are any servers that do not return from a reboot, the script will stop processing subsequent server reboots. The script will process through all servers in the farm until all servers have rebooted. Once completed, the script will loop infinitely, repeating this process as frequently the administrator desires (FARMLOOPINTERVAL). For example, if the administrator sets this variable to 72, the farm loop will not occur more than once every three days.

If the environment already has a Citrix Full Access service account, this account can be used to run the scripts as a scheduled task. Otherwise, an administrator will need to create a full access farm administrator account and assign local administrator rights to the XenApp servers. Domain admin privileges are not needed for this account. However, since the script assigns load evaluators to the servers in the farm, XenApp admin rights are needed. The scripts must be configured on a single server for each farm (Preferably the Zone Data Collector). In the case of XenDesktop, this script should be scheduled from a Delivery Controller. This server will manage the reboot processes for all other servers in the farm, excluding the local server from which the script is run. 

Feedback welcomed. Enhancements and bug fixes upon request using the comments section below!

1.1.1       Introduction

The included scripts were built for either XenApp 5 or earlier farms supporting MFCOM (VBScript), XenApp 6 supporting the new PowerShell syntax (PowerShell), or XenApp 6.5 also supporting PowerShell.  Additionally, the script has been updated to support XenApp and XenDesktop 7.0, 7.1, 7.5, 7.6, and 7.7 sites. The procedure is the same for both scripting architectures enabling administrators to configure a single server in the farm (Preferably the Zone Data Collector) that will manage the reboot process for all other servers. In the current build, the script performs the following functions:

-       The script checks to see if the script is already running (Since Task Scheduler is not smart enough to prevent multiple instances from spawning)

-       The script checks to see if the NoLogon load evaluator already exists. If it does not already exist, the script will create the load evaluator. (XenApp 5 and 6 only)

-       Excluding servers specified in the comma separated global variable, the script creates an alphabetized array of all the servers in the farm and work through the array in sequential order.

-       When worker groups are specified in the comma separated global variable, the script will process multiple worker groups simultaneously. (XenApp 6 and 6.5 only)

-       When MaxServers global variable is defined, the script will process multiple servers within a worker group simultaneously. (XenApp 6 and 6.5 only)

-       When EnableSMTP is set to $true, additional variables are required for SMTP server location and authentication settings. E-mail notifications will be sent in addition to the application event log. (XenApp 6 and 6.5 only)

-       Unless the RebootThisServer is set to true, the script will bypass the local server so it will not inadvertently process a reboot against itself. If the RebootThisServer variable is set to true, the script will process the local server only after all other servers have been processed.

-       The script will then perform the following process for any server that is online:

  • Assign the NoLogon (Or whichever name specified in the global declarations section) Load Evaluator to the server.  This is a bogus load evaluator that will prevent any subsequent sessions from being established.
  • Assess if there are any active sessions. As long as there are active sessions, loop back and check again every five minutes.
  • If there are no longer any active sessions, assign the original load evaluator back to the server.
  • Process the reboot procedure utilizing shutdown.exe against the server.
  • Wait for three minutes and check to see if the server has returned from the reboot process. If the server is back online, continue to loop until the load evaluator has reset under 5000.
  • Once the server is back online and the load is less than 5000, proceed to the next server in the array.

-       The script will then wait until the FarmLoopInterval timeout has expired (i.e. 24 hours) and start the loop through the array all over again.

-       With XenApp 6.5, the NoLogon load evaluator has been deprecated in favor of the ProhibitNewLogOnsUntilRestart procedure.

1.1.2       Revision Notes

Build 2014.12.03 Revision 8

-       Added support for XenApp and XenDesktop 7.5 and 7.6 sites.

-       Fixed bug causing script not to loop if duration was longer than 24 hours.

Build 2013.12.09 Revision 7

-       Added support for XenDesktop 7.0 and 7.1 sites.

Build 2012.11.26 Revision 6 (XenApp 6 and 6.5 only)

-       Added Worker Group logic to allow simultaneous processing of multiple worker groups. For example, if three worker groups are defined, a separate PowerShell thread will be initiated to process servers from each worker group simultaneously.

-       Added MaxServers variable to allow simultaneous processing of multiple servers within a worker group. For example if MaxServers is set to 4, the worker group will have up to 4 servers simultaneously processing at any point in time. It is recommended that the number of servers in a Worker Groups be sized to accommodate, for example N+4 given the scenario described.

-       Added SMTP notification logic to report status updates through e-mail in addition to the application event logs on the zone data collector. Several variables will need to be defined including EmailFrom, EmailTo, SMTPServer, SMTPUsername, and SMTPPassword. See script for configuration examples.

Build 2011.12.05 Revision 5

-       Added ExcludeServers global variable to enable Administrators to exclude farm servers from processing. To configure this feature, change the blank string (“”) to a comma separated list of farm servers to be excluded. This server list should reference the servers’ short names, exactly as they appear in the Citrix consoles, and is not case sensitive.

-       Changed NoLogon load evaluator to use Context Switching as this is a more solid way to ensure a permanent 10,000 load for XenApp 5 and 6.  This change does not apply to XenApp 6.5.

Build 2011.11.10 Revision 4

-       Released XenApp 6.5 compatible version utilizing the ProhibitNewLogOnsUntilRestart and removing syntax for the NoLogon load evaluator.

-       Added logic to process the local server after all subsequent servers have been processed.  This will only occur if the RebootThisServer variable is set to true.

Build 2011.2.7 Revision 3

-       Added logic to check for the existence of the NoLogon load evaluator.

-       If the NoLogin load evaluator does not already exist, create it.

-       Added logic to pull the currently assigned load evaluator before assigning the NoLogon load evaluator. This will ensure environments with server specific load evaluators continue to maintain these assignments.

Build 2010.10.22 Revision 2

-       Added additional logging to indicate how much time has elapsed since last farm loop.

-       Fixed comments section for PowerShell version.

-       Added Copyright tag lines to top and bottom of the scripts.

Share Button
  1. Joe DropkinJoe Dropkin09-09-2015

    How do you handle prelaunch sessions? I would like to make a distinction between ACTIVE sessions and prelaunch sessions.

    • Dane YoungDane Young09-14-2015

      Great question! Not sure how these sessions would be registered, but I’m sure we can figure out a way to adjust the script to handle these types of sessions. Let me know if you need more help researching adjustments to the script.

      Thanks!
      –youngtech

      • Joe DropkinJoe Dropkin09-16-2015

        Rather than check for the active sessions, check for active applications. If you replace $session value with the return of “(Get-BrokerSession | ? { $_.AppState -eq “Active” }).count” then a value of 0 indicates that no active applications are running and the server can be rebooted.

  2. RobertRobert06-22-2015

    Hi SK,

    I removed ‘@’ in line 125:
    $sessions = (get-brokermachine $server).SessionsEstablished

    and also changed line 147 to:
    Invoke-Expression “Shutdown.exe /m $dnsname /r /t 0 /c ‘Shutdown scheduled by Citrix farm chained reboot.'”

    Afterwards the script functioned as expected.

    Great work!!!! Thanke you Dane.

    • SKSK06-30-2015

      Hi Robert,

      i have made as suggested by you, but still its not working. FYI: I am using this script on XenApp 7.6 Farm but no luck

      Regards,
      Shekhar Reddy.

  3. LiamLiam06-18-2015

    Hey

    Everything appears to be working except for the reboot part
    My troubleshooting appears that it’s kicking off the

    New-BrokerHostingPowerAction -Action ‘Restart’ -MachineName $server

    which the server sits as ‘proccessing’

    Is there a way to bypass that method so it will be forced to use the

    Invoke-Expression “Shutdown.exe /m $dnsname /r /t 0 /c “”Shutdown scheduled by Citrix farm chained reboot.”””

    instead?

  4. JamesJames05-29-2015

    For some reason I can not get this to run properly on one of my Xenapp 6.5 farms. I have a second farm that it works as intended. Both scripts are configured identical. I have it running off of the ZDC. I see powershell.exe running but the servers just never reboot. Nothing in the event logs that I have found. Any help is much appreciated!

  5. SKSK05-21-2015

    hello Dane,

    i have placed this script on our XenApp 7.6 Farm. in Task scheduler script showing as running however servers are not getting rebooted. could you please let me know is there any permissions required to get the server rebooted or something i need to check

    Regards
    SK

1 17 18 19

Leave a Reply