Citrix Chained Reboot Scripts, now supporting Citrix Cloud, Citrix Virtual Apps and Desktops (CVAD), and XenApp/XenDesktop 5, 6, 6.5, and 7.x!

Share Button

Updated 2018.12.22: Revision 1.9 Now Supports Citrix Cloud!

One script now works with all current and modern versions of XenApp, XenDesktop, Citrix Virtual Apps and Desktops (CVAD), and Citrix Cloud Virtual Apps and Desktops Service from 7.0 and later, through 1811.

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.

Share Button
  1. KjetilKjetil12-19-2011

    Hi Dane! I have tried your script in our XA6-environment, but haven’t successfully rebooted any servers yet. The script is set up as a scheduled task from our primary ZDC as described in your documentation. When the task starts, the first server in the farm is assigned the “NoLogon” load evaluator, but then nothing else happens. I have not found any event log entries either, so I don’t know where it stops or what is happening. The scheduled task is run with a domain admin account, which is also a “full admin” in our XA6-farm. Any ideas how to troubleshoot this?

    • youngtechyoungtech12-19-2011

      Is it possible that you have sessions hanging out there for an extended period of time that aren’t bleeding off? You may want to check TSAdmin.msc and connect to the server that currently has the NoLogon LE assigned. If you see any sessions or users listed, this could be the reason it never reboots. This is by design.

      Let me know your results. Thanks,
      –youngtech

  2. RasmusRasmus12-19-2011


    Rick:

    As users log off and on 24×7, it is a real possibility that the rolling-reboot could be held up by one server, with users who work through the night.

    My concern exactly and the primary reason I’m not replacing our dumb reboot-regardless-of-running-sessions script with this.

    I really like the idea that it not only waits for a rebooted server to come online, but also checks that load has normalized to idle level, before proceeding with reboots.

    • youngtechyoungtech12-19-2011

      Rasmus,
      See my response to Rick above. Using this script shifts the paradigm that reboots only occur during the night. If you have your idle and disconnected session timeouts set properly no server should be hung longer than 24 hours. You just have to weigh all the advantages and disadvantages of using zero interruption logic and processes. Hope this helps,
      –youngtech

  3. JasonJason12-16-2011

    I believe I found the problem. The error was with line 135 –

    $EventLog.WriteEntry(“It has been ” + $intHours + ” hours since last loop. Waiting for another ” + [string]($FARMLOOPINTERVAL-$intHours) + ” hours.”,”Information”,”511″)

    After the first pass the variable $intHours is set to TimeSpan. Then after it loops through and attempts to write the log entry it cannot calculate $FARMLOOPINTERVAL – $intHours because of it hold all the TimeSpan values (hours, minutes, seconds, etc).

    In order to resolve my issue I changed the logic to $FARMLOOPINTERVAL – $intHours.Hours

    • youngtechyoungtech12-19-2011

      Thanks for the feedback Jason. I will take a look and see if I can reproduce this behavior and integrate your changes into the next revision. Hope it works well for your environment.
      –youngtech

  4. JasonJason12-14-2011

    I am running the script in a XenApp 6 environment and the “first pass” works as expected and I receive the event log indicating that, “It has been 0 hours since last loop. Waiting for another 24 hours.”

    Then the problem occurs, about 10 minutes after the above event log, the following error is logged, “Unhandled error has occurred in main program: The operation ‘[system.Int32] – [System.TimeSpan]’ is not defined. I have manually entered the portion of the script that calulates the Timespan without issue. Any suggestions are appreciated!

    Thanks,

    Jason

  5. Christina SChristina S12-09-2011

    Thanks! I did get a little help at narrowing down the issue from my brilliant husband who is well versed in programming! =)

Leave a Reply to Dane Young Click here to cancel reply.