Average time to read: 7 minutes

powerIcon

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

Community1First 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:

Reboot 1

It will get you here, notice that Iโ€™ve already selected the โ€˜restart Scheduleโ€™ down below:

Reboot 2Now 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:

Reboot 3It 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!

Bas van Kaam on FacebookBas van Kaam on LinkedinBas van Kaam on Twitter
Bas van Kaam
Bas van Kaam
Field CTO EMEA by day, author by night @ Nerdio
Father of three, EMEA Field CTO @ Nerdio, Author of the book Van de Basis tot aan Meester in de Cloud, Co-author of the book Project Byte-Sized and Yuthor of the book: Inside Citrix โ€“ The FlexCast Management Architecture, over 500 blog posts and multiple (ultimate) cheat sheets/e-books. Public speaker, sport enthusiastยญยญยญยญยญยญยญยญ: above-average runner, 3 x burpee-mile finisher and a former semiprofessional snooker player. IT community participant and initiator of the AVD User group Community world wide.
, , ,


3 responses to “How to: Rebooting your XenDesktop 7.x application servers.”

  1. Ryan Massey Avatar

    Per the document: http://docs.citrix.com/en-us/xenapp-and-xendesktop/7-6/xad-build-new-enviroment/xad-dg-create/xad-dg-manage-machines.html

    “In the Restart additional groups every drop-down, Indicate whether all servers should be restarted at once, or how much time should be allowed to restart every server in the Delivery Group.

    For example, assume a Delivery Group has five servers, a Restart first group at time of 13:00 (1:00 pm), and a Restart additional groups every selection of 1 hour. That duration (60 minutes) is divided by the number of machines (five), which yields a restart interval of 12 minutes. So, the restart times are 1:00 pm, 1:12 pm, 1:24 pm, 1:36 pm, and 1:48 pm. This gives all five machines the chance to complete their restart at the end of the specified interval (1 hour).”

    Meaning that if the document is to be trusted for 7.6 and the discussion post wrong, then the setting is worded poorly.

    1. Bas van Kaam Avatar

      Yes, I agree. Thanks man.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Search

About

Lorem Ipsum has been the industrys standard dummy text ever since the 1500s, when an unknown prmontserrat took a galley of type and scrambled it to make a type specimen book.

Lorem Ipsum has been the industrys standard dummy text ever since the 1500s, when an unknown prmontserrat took a galley of type and scrambled it to make a type specimen book. It has survived not only five centuries, but also the leap into electronic typesetting, remaining essentially unchanged.

Categories

Gallery

Verified by MonsterInsights