Citrix Blogs

XenApp and XenDesktop 7.x Server OS VDA Staggered Reboot

Robert Woelfer

Please note: This is the first version of the reboot framework. The 2nd version can be found here.

I recently came across a requirement to perform staggered reboots for XenDesktop 7.6 Server OS VDAs.

As most of you might be aware of, with XenApp and XenDesktop 7.x we streamlined the core product architecture to FlexCast Management Architecture (FMA). While FMA provides us with basic capabilities to perform automated reboots, there are still scenarios which need more flexible mechanisms and schedules.

I recently came across such a requirement to perform staggered reboots for Remote Desktop Session Hosts (RDSH), also known as Server OS VDAs. While there are some pretty good scripts out there, I finally decided to create my own solution as none of the scripts available were addressing all the requirements my customer had.

One of the solutions out there is a script written by my colleague Miguel Contreras, which can be found here. But I though it might be worth to share my script with you as well.

So, first some information regarding the requirements:

The script addresses all of the requirements mentioned above. First of all, the RDS logon mode on servers that are scheduled for reboot is set to drained until restart. This ensures that no new session is initiated, but users can reconnect to existing sessions. Through a configurable delay, the existing sessions will receive periodic messages to inform users about the pending reboot. Depending on the configuration, the user logoff is forced after the reboot cycle time, or the users receive a messages until the last session gets logged off, depending on your requirements. After the last user gets logged off, the server will perform the reboot. To ensure each server is rebooted at a different time within the reboot cycle, a random value is created and used as delay before the script will start with the reboot tasks.

To deploy the script to the VDAs, I prefer Group Policy Preferences (GPP). This ensures that each VDA downloads the current version of the script from a central share. The task scheduler is configured through GPP as well. By using the targeting mechanism of GPP, it is possible to use a single GPO to assign the different schedules to the VDAs. The cool thing about targeting is that it’s quite flexible. You can use Organizational Units (OU) or Active Directory Security Groups for example to assign the proper scheduler to a server group.

Note:
There is currently one limitation of this script. As each VDA will perform the reboot on its own, the Controller is not involved. Thus, Machine Creation Services (MCS) managed VDAs won’t reset their cache disk as the Hypervisor won’t receive any commands to do so. This results in supporting Provisioning Services (PVS) and 3rd party tools managed VDAs only for this script. Maybe I will provide an updated version to support MCS as well later on.

Another thing to mention is that Microsoft Windows Server 2008 R2 does not provide PowerShell Cmdlets for RDS, so I utilize the “Terminal Services Module” from CodePlex.

But now, let’s have a look on how to implement the solution:

  1. Provide a share to put the script on.
    I assume, I do not have to tell you how 😉
  2. Create a GPP entry to deploy the script on each of your VDAs.
    GPP is a great and flexible solution to modify your environment.
    I personally prefer GPP over logon scripts. Thus, I utilize it for this solution as well.
    Locate “Files” under the Computer Configuration:

    Create an “Update” or “Replace” action for the script file. Specify your central share and the local folder to copy the script to:
  3. Create a task scheduler for each of your server groups through GPP
    Again, this could be scripted as well. But I will use my favorite mechanism again.
    Locate the “Scheduled Tasks” under the Computer Configuration:

    Create a “Scheduled Task (At least Windows 7)” for each of the required reboot groups (e.g. Monday to Sunday):

    Provide the required information:
    Specify an account with appropriate privileges to reboot the server:
    “NT AUTHORITY\System”

    Set the appropriate trigger for each Scheduled Task:

    Set the action for each Scheduled Task:

    Example action without forced logoff:
    powershell.exe -ExecutionPolicy RemoteSigned –File “C:\Tools\RebootSchedule\ServerVDAReboot.ps1” -MsgDelay 600 -RebootDelay 300 -ForceLogoff 0

    Example action with forced logoff:
    powershell.exe -ExecutionPolicy RemoteSigned –File “C:\Tools\RebootSchedule\ServerVDAReboot.ps1” –RebootCycle 3600 -MsgDelay 600 -LogoffDelay 300 -RebootDelay 300 -ForceLogoff 1

    -RebootCycle = 3600
    Disable logon 1 hour prior to the reboot sequence (only if ForceLogoff = 1)
    -MsgDelay = 600
    Send user messages every 10 minutes
    -LogoffDelay = 300
    Force user logoff five minutes after last message was sent (not relevant if ForceLogoff = 0)
    -RebootDelay = 300
    Reboot VDA five minutes after last user logged off
    -ForceLogoff = 0
    No logoff is forced, reboot only if no user session on VDA

    Note:
    For Windows Server 2008 R2 specify the 32-bit “powershell.exe” (due to the Terminal Services Module from CodePlex):
    “C:\Windows\SysWOW64\WindowsPowerShell\v1.0\powershell.exe”

    For Windows Server 2012 R2 specify the 64-bit “powershell.exe”:
    “C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe”

    Set the Item-level targeting for each Scheduled Task:

    Either based on OU structure of your Active Directory:

    This of course requires appropriate OU design – e.g.:

    Or based on Active Directory Security Groups:

    Specify the appropriate Active Directory Security Group.

That’s it. Your VDAs are configured for the reboot schedule after the GPO has been applied. If you add new machines to your environment, simply put them in the appropriate OU or make them member of the desired Active Directory Security Group.

Last, but not least, to satisfy the legal guys:

Disclaimer Notice

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 can be downloaded here.

Hope this might be useful for you as well.

UPDATE: New version available with some code cosmetic and bug fixing.

Until next time!

Robert Woelfer
Principal Consultant | Citrix Consulting Central and Eastern Europe

Exit mobile version