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. TyronTyron09-11-2016

    Hello Dane,
    Thank you for this amazing script!
    If possible, I would like to suggest the change below. With this code, you will check if the same script was called (not only check for any Powershell). That way, if some other admin logs into the server and forgets the Powershell console open, it won’t impact the execution of the scheduled task.

    Remove this:
    $processes=0
    $powershells = @(get-process | Where {$_.ProcessName -eq “powershell”}) # Query all running processes to see if Powershell is running
    foreach ($p in $powershells) {$processes+=1} # Validate that there is already a powershell instance running

    Add this:
    $processes=((Get-CimInstance Win32_process -Filter “name = ‘powershell.exe'” | where {$_.CommandLine -match $MyInvocation.MyCommand.Name} | measure).count)

  2. Jesse TJesse T06-29-2016

    Trying to implement this into our XenApp 6.5 farm, the script will go through and process servers in the farm disabling logons but never actually reboots the servers.

  3. MatthewPMatthewP06-09-2016

    Hi Dane, Great script and works 99.999%

    The problem I am having is that I cannot only get it to reboot a single server per delivery group at a time, How can i get it to reboot more servers?

    I have 220 (110 per site) servers that I need to run this against and so far has taken 4 hours and only done and reboot 87 per site.

    I have the the reboot interval set to 5 and the maxservers set to 10 but it only seems to do one at a time and does not move on until it is finsihed

    Thanks

    • jasonjason08-26-2016

      I am having the same issue, XenApp 7.6 LTSR CU1. It will only reboot one server at a time, even though I have it set to 5 for max servers. I tested it in my lab which is on the same version and its doing the same thing. This worked previously with the original 7.6 release. Is there anyway we can get an updated script that fixes this functionality? It would be greatly appreciated!
      Thanks!

1 18 19 20

Leave a Reply