Sounds easy enough right? Rebooting your XenDesktop Site’s application servers. When your Site isn’t that big and you don’t have a few hundred machines running or you have to deal with 24/7 shifts and so on, it can be fairly straightforward. I don’t want to spend to much time on why we would want, or need, to reboot our machines on a weekly or perhaps daily basis etc. a lot of factors come into play and there’s really no ‘one size fits all’. You could be using App-V or Citrix provisioning Services for example, both caching data which you would like to clear from time to time. Or perhaps the underlying Windows OS, when physically installed, might need a refresh every once in awhile, which we all know it does! Fact of the matter is, reboots are a given and need to be thought trough to keep operations running as smooth as possible. Make sure to finish the article, there is a question on the Citrix build-in reboot tooling, maybe you can help me out!
A necessary evil
Again, why we need to reboot doesn’t really matter, eventually there will come a time, even if you don’t think things trough on forehand, when a reboot will be your only way out. Fortunately, in practice, like the responsible admins we are, we prefer to handle proactive as apposed to reactive because in most cases reactive will mean that the damage is already done. So when we design our Sites we also have to think about a reboot schedule of some sort, but I’m sure you are able to figure this one out by your self. If not, than you probably have an exotic and or large Site to deal with which makes it even more interesting.
It’s all about Delivery groups
A lot will depend on the way your Site is designed, for example, the number of Delivery Groups, including the amount of servers, applications and users they hold will play an important role in how you will design and apply your reboot policy. Custom scripts, more often than not, as well as the build-in XenDesktop restart feature will use a Delivery Group, and thus the machines ‘bound’ to it, as a target for rebooting purposes. This means that you will have to create a reboot schedule for every Delivery Group present (and the machines assigned to it) and active in your Site. There is a lot to consider, to give you an idea: which servers need to be rebooted first, probably the ones without any active sessions right? Do we ‘drain’ our machines from users sessions, and if so, how do we go about it? What about Maintenance mode? What if there are no ‘user-less’ machines, so they all have active sessions? We probably can’t reboot all machines at once, so do we keep a certain percentage ‘online’ at all times? What percentage, which machines? And so on.
Yes, I know
Last week a (short) blog on rebooting CTX machines also appeared on the Citrix Blogs site, give it a read here. No, this isn’t a spin-off, I had already written this article for about 80%. Never the less, it might turnout to be a good add-on. Check out the comment section as well, they’re spot on.
Community first
First of all, let me introduce a fellow community member, his name is Shaun Ritchie and he has spend a great deal of time developing a so called Rolling reboot script for XenDesktop 7, you’ll find it here, looks awesome! Which automatically brings me to the first method we can use in rebooting our machines, custom made scripts. By the way, I also need to mention Carl Webster (scripting guru) here, I believe Shaun used some of his work to start out with and took it from there. As you will see, Shaun has taken a great deal of the above mentioned considerations into account, like rebooting the machines without any active sessions first for example. Since I’m not that big on scripting, coding etc. I won’t go into any details, it goes without saying that if you want to use a similar solution you will have to spend some time getting to know the scripts you are going to run.
I mean, you need to know and understand, at least to some extend, what happens underneath the covers to be able support the solution you are implementing. And beside, you probably will have to change and adjust certain parameters to make it fit your environment before you start your dry-runs and take it into production. Needles to say that, although Shaun’s script is an excellent example, you can create and apply all sorts of variations. I’ve also seen examples of relatively simple PowerShell scripts targeting the server individually, segregating them from their Delivery Groups by using two or more text files, let’s just say that there are multiple roads that lead to Rome. These text files are filled with the machine names we’d like to reboot, which will be called upon by the script. This way they can be rebooted in two, or more, intervals.
Alternatives and the build-in scheduler
Another approach would be to schedule a ‘per machine’ reboot using the Windows task scheduler, but this will only work if your Site isn’t to big, with regards to the administrative overhead this will cause. I guess using SCCM or a similar solution will also work, you can get as creative as you like. However, one thing these solutions, including the script mentioned, don’t offer is a notification message, informing your users what is about to happen and asking them if they would like to log off, saving their work and telling them that they have another 1, 5 or 15 minutes (these are the only options you have when using the build-in reboot tooling) to do so! Let’s have a look.
A closer look
Again, it’s configured on a per Delivery Group basis. Right click the Delivery group for which you would like to configure a reboot schedule and choose ‘Edit Delivery Group’ as shown below:
It will get you here, notice that I’ve already selected the ‘restart Schedule’ down below:
Now this is where it gets interesting. Up till now it all looked pretty straight forward right? You select the restart schedule, select yes in that you would like to automatically restart the machines, next you decide to restart your machines on a daily basis or every Monday, Tuesday etc… I’ve also mentioned the restart notification message, you can fill in your own text but you are still bound to the 1, 5 or 15 minutes, have a look for your self.
Additional groups?
The interesting part is the ‘restart additional groups every:’ option. Restart all machines at once is a no brainer, it will do just that. But what about the additional groups every 30 minutes or hour, two hours etc? What additional groups?! Can we divide the machine assigned to our Delivery groups into separate reboot groups? And where would we do so? The answer is, no we can’t! Several people have tried to figure out what this setting is about, but information is very limited if at all available. Before I show you what I’ve found, let me ask you, do you know how this works, what kind of algorithm is involved, which logic is applied?
Apparently these groups are actually two groups, the ‘system’ will decide which machines end up in which group and will eventually boot the machines in those groups accordingly. This is what one of the Citrix engineers had to say about it:
It will make sure that not all machines are rebooted at the same time, instead it will only reboot a subset of servers within the Delivery Group so there will always be a few machines available to avoid a total application outage. Also, it will wait for the rebooted systems to come back online and register themselves with the Delivery Controller. Once it has confirmed that the restarted machines are again registered it will continue to reboot the rest of the servers.
You will find the whole discussion here, although it’s not much of a discussion to be honest. Here you will find the official Citrix documentation on configuring the reboot schedule for a server OS machine Delivery Group. As you’ll see , not much useful info in there.
Wrap up
Of course we also have to deal with draining our machine from users and prohibit logon’s etc. before we can start rebooting them. Or you can just reboot them and see what happens :-) I’ll cover this in one of my future posts. I’m sure I left out some valid options with regards to rebooting our machines, so please feel free to add any ideas you might have, the same goes for any documentation you might have found explaining some of the above subjects. What will work best for you depends on your situation, configuration and overall needs, but I think the above could point you in the right direction and gives you something to think about!
