Personally, I think one of the most important things it offers is the ability to create and apply different reboot schedules for a group of servers hosting the same resources so that not all of them reboot at the same time, or on the same day, regardless of whether they belong to a common Worker Group.
With XenApp/XenDesktop 7.x, we lose some of this flexibility. We can still configure scheduled reboots for our Delivery Groups, but these settings apply to all servers in the group and it does not allow to segment machines within the group so they can be rebooted on different days or times. There is also no option for disabling logons ahead of times to let the servers drain before being rebooted.
This, as you can imagine, could be a bit problematic.
To address this issue, I created a reboot script a little while ago that provides the functionality I was looking for at the time. In summary, the script enables maintenance mode on the machines I want to reboot (let’s call them targets) and lets them drain for 24 hours. After 24 hours the script will cycle through the targets and reboot any machines that have no sessions and will send alerts to users who still have sessions on the targets encouraging the user to log off. The script will repeat this every 5 minutes for 30 minutes. After the 30 minutes are up, any targets that have not been rebooted will be rebooted whether there are users on them or not.
A few things about the script:
- The script requires that you provide the name of the Delivery Group the machines belong to.
- The script assumes all machine names have a 3-digit number at the end of the name (number of digits can be easily changed if needed).
- The script requires that you provide the parity of the machines (odd or even) to know which machines in the delivery group specified will be rebooted.
- In order to run the script automatically, you need to create Scheduled Tasks in one of the Delivery Controllers. This can be done manually on the Delivery Controller or via GPO.
- You will need a Scheduled Task for every group of machines to be rebooted (e.g. Delivery Group #1 – Even, Delivery Group #1 – Odd, …, Delivery Group #n – Even, Delivery Group #n – Odd).
- Instructions on how to run the script can be found in the script’s comments.
- This solution is OS agnostic.
Last, but most certainly not least…
This software / sample code is provided to you “AS IS” with no representations, warranties or conditions of any kind. You may use, modify and distribute it at your own risk. CITRIX DISCLAIMS ALL WARRANTIES WHATSOEVER, EXPRESS, IMPLIED, WRITTEN, ORAL OR STATUTORY, INCLUDING WITHOUT LIMITATION WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, TITLE AND NONINFRINGEMENT. Without limiting the generality of the foregoing, you acknowledge and agree that (a) the software / sample code may exhibit errors, design flaws or other problems, possibly resulting in loss of data or damage to property; (b) it may not be possible to make the software / sample code fully functional; and (c) Citrix may, without notice or liability to you, cease to make available the current version and/or any future versions of the software / sample code. In no event should the software / code be used to support of ultra-hazardous activities, including but not limited to life support or blasting activities. NEITHER CITRIX NOR ITS AFFILIATES OR AGENTS WILL BE LIABLE, UNDER BREACH OF CONTRACT OR ANY OTHER THEORY OF LIABILITY, FOR ANY DAMAGES WHATSOEVER ARISING FROM USE OF THE SOFTWARE / SAMPLE CODE, INCLUDING WITHOUT LIMITATION DIRECT, SPECIAL, INCIDENTAL, PUNITIVE, CONSEQUENTIAL OR OTHER DAMAGES, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. Although the copyright in the software / code belongs to Citrix, any distribution of the code should include only your own standard copyright attribution, and not that of Citrix. You agree to indemnify and defend Citrix against any and all claims arising from your use, modification or distribution of the code.
The script is available here.
UPDATE: my colleague Robert Woelfer put together another scripted reboot solution which you can find here. He takes a different approach by not using the delivery controllers to handle the reboots and managing the reboot schedules through AD.
Until next time!
Migs
Architect | Americas Consulting