Citrix Chained Reboot Scripts, now supporting Citrix Cloud, Citrix Virtual Apps and Desktops (CVAD), and XenApp/XenDesktop 5, 6, 6.5, and 7.x!
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.
Dane,
Great script. Just have a couple of issues. We have many, many farms. From 4.5 to 6.5. ON the 6.5 farm we have several farms that we need to set with different configurations. I have configured a script to run against a couple of worker groups for one app. But if i try to run another script with different configurations on the same ZDC, it won’t run because the powershell.exe is running. Any ideas on how to get around that?
I also have a problem with the script that is running. Some of the notifications work fine, up to the point where it says that there are no users on the server. From that point on the email notifications, such as the server is rebooting and the server is back up and running, will not go out. The Event log entry will work, but the email for that same event doesn’t work. I can’t find any difference in the commands in the script that do work vs. the ones that don’t work. Any suggestions on what to look for there?
Thanks,
Michael Boggan
I really like what you have done with this script. I have had this sitting on the shelf since Rev5 waiting for some time to see how it would work in our environments. I have loaded the two versions (6.0 and 6.5) on some test farms, and i am noticing something consistent between the two scripts (present with Rev6 and 7). what we are seeing is the script will set a server to prohibit logons (or nologon LE) like it should and wait for the reboot until all users have logged off. but if at least 1 user is logged on it will continue after the 30 min window and attempt to process the next server and start over again once the FarmLoop interval has passed. While i understand the logic of this, what can occur (and has in testing) is if multiple servers have 1 user logged in, it can create a scenario where more servers than the ‘MAXSERVERS’ variable are set to prohibit logons. As in the case of our small test farms (consisting of two servers in each farm)
First scenario: server 1 launches script via scheduled task, but has a user logged in. script correctly processes server 2 and it successfully reboots. After 30 min, server 1 is tagged for reboot and set to prohibit logons, FARMLOOPINTERVAL passes, server 1 has not rebooted but is still prohibiting logons and reboots start again on server 2. (i suspect it would start again on the entire farm if it was larger)
second scenario: server 1 launches script via scheduled task, has users logged in. script starts to process on server 2 but server 2 has users logged in, so it only set to prohibit logons. After 30 min, server 1 starts to get processed but because a user is logged in, it too is only set to prohibit logins. after FARMLOOPINTERVAL passes, process starts over again. no server reboots, all are set to prohibit logons.
the only modifications made for testing was to set the SMTP/Email so it would work and Set the REBOOTTHIS SERVER to true and FARMLOOPINTERVAL to 1 hour. Granted this is a short window but it is a test lab and.so i could see it work within a reasonable time frame
Do you have any suggestions for the following:
– modification of the script (or variable) so it will sit on one server till the reboot is complete; once done then it could move on to the next server.
I am ok with controlling the looping by setting it as a scheduled task. With no one logged into the servers the script works as expected since it handles hosting server last, the reboot of the hosting server prevents any loops.
Thanks for the perfect script!
I did not use a service account that was local admin on all XA servers, so the reboot command (shutdown.exe) returned an Access Denied. The script does not check if the server has really been rebooted. It continues after 60 seconds and reports the load is under 5000 and continues. But the server still has the status “Prohibit Logons”. After a few hours all XA server were “handled” and they did not accept any sessions accept for one XA server ;).
Maybe it is possible to add a check before the serverload check to see if the server is still not accepting sessions. Or even better: check the errorlevel of the shutdown (reboot) command.
I now use an account that has local admin permissions on all servers, so it is working!! This is just for people like me not using an domain admin user..
Build 2012.11.26 Revision 6: There is an error in the following comparison:
} while ($intHours.Hours -lt $FARMLOOPINTERVAL) # Compare to see if the time elapsed is less than the farm loop interval
It should be:
} while ($intHours.TotalHours -lt $FARMLOOPINTERVAL)
$intHours is a timespan object. The .hours-method will for instance return 3 hours if the timespan object is 1 day and 3 hours – alas if $FARMLOOPINTERVAL is 24 or greater, then the while loop continues for ever.
Thanks Bjorn. This has been fixed, try downloading again.
–youngtech
The XenApp 5 link is broken, were these files removed?