This is the second version of the reboot framework for XenApp/XenDesktop Server OS VDAs. If you’d like a refresher on the first version, please revisit our previous blog post.

First, I’d like to summarize the framework conditions:

  • No single instance to control the reboots. Thus, not creating reboot schedules for VDAs on the Controllers.
  • Flexibility to create reboot groups as much as required. For example, perform multiple reboots of a certain Machine Catalog over a whole week, resulting in seven reboot groups for a single Machine Catalog.
  • Configuration of the reboot schedule through Active Directory and Group Policy mechanisms.
  • Choice, whether users are forced to logoff prior to the reboot, or if the reboot will delay until the last user logs off.
  • No dependency on the server naming scheme.
  • Support for all Microsoft Windows Server Operating Systems XenApp / XenDesktop can utilize.
  • Disable logon for new sessions but allow reconnect to existing once.
  • Send messages prior reboot to the existing sessions.
  • Configure the delays (reboot messages, logoff and reboot) through parameters, which are handed over to the script.
  • Ensure all servers of a certain group are not rebooted at the same time.
  • Support for all provisioning methods offered by XenDesktop – Machine Creation Services, Provisioning Services and 3rd party tools like ESD.
  • No additional software to install on the VDAs.

Now, let’s have a closer look at the 2nd version of the framework:

Despite slightly different configuration parameters, the main difference between the first and the second version of the framework is the support of all provisioning methods offered by XenApp and XenDesktop. While the first version has no support for Machine Creation Services (MCS), the second version now has support for all provisioning methods including MCS.

The following changes and enhancements where made compared to the first version:

  • Support for MCS.
  • Support for delaying the first message sent to the users.
  • Detailed logging information and adding appending log functionality instead of overwriting the existing one.
  • Option to choose whether to restart the VDA immediately after last session logs off or to wait till the end of reboot cycle.

Since MCS provisioned VDAs require the reboot to be initiated by a Delivery Controller in order to reset the cache disks, this version of the reboot framework leverages the XenApp and XenDesktop SDK instead of RDS PoSH Cmdlets. Hence, this version supports all of the Server Operating Systems XenApp and XenDesktop maintain.

Note: There is no requirement to install the SDK on the VDA, since every VDA will establish a remote PoSH connection to the Delivery Controller the VDA is registered with. However, this approach requires a service account to allow the VDA to execute maintenance tasks like enabling maintenance mode, sending user messages and rebooting machines.

The framework contains three (3) scripts

1) CreateAESKey.ps1

Since a service account is required for this script to initiate a remote PoSH session with a Delivery Controller, a password is required, as well. To avoid saving the password in plain text within the script, I’m providing a script to create an encrypted password for the service account.

The “CreateAESKey” script will create a key to encrypt the password. The key is saved in a dedicated key file within the root directory of the script.

2) CreateAESPassword.ps1

The “CreateAESPassword” script will use the key file created with the “CreateAESKey” script, to encrypt the password. The password is saved in a dedicated password file within the script root directory.

3) FMAServerOSVDAReboot.ps1

The second version of the reboot framework. The script requires the key and the password files described above. Both files are expected to be stored in the framework script root directory. However, file paths can be changed within the code of the script. The service account name is specified within the code as well.

Note: Both files, the password file and the key file, allow decryption of the service account password. Hence, I highly recommend to limit access to both files through NTFS file permissions. Furthermore, Microsoft Windows file access auditing policies can be configured to further enhance security for both files.

The following tasks are performed by the reboot script:

  • Enable maintenance mode for the VDA. No new sessions are initiated; existing sessions can be reconnected.
  • Through a configurable interval, the existing sessions will receive periodic messages to inform users about the pending reboot.
  • Based on the configuration, either the user logoff is enforced after the reboot cycle time or the users receive messages until the last session gets logged off.
  • 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.

Note: Each VDA reads the Delivery Controller information from the registry to spread load across all Controllers of the site. Every time a remote PoSH command needs to be launched, a remote session is established with the Delivery Controller and closed after sending the command.

Now, let’s cover the requirements of the framework

The following minimum permissions within the XenApp / XenDesktop site are required for the service account, to perform the Server OS VDA reboots:

  • Enable/disable maintenance mode of a machine
  • Perform power operations on Windows Server machines
  • Perform session management on machines

As mentioned earlier, each VDA initiates a remote PoSH session with the Delivery Controller the VDA is registered with. Please note, that by default, the maximum number of remote sessions is limited by Microsoft. To address this limit, I introduced a random delay prior initiating the remote session to better spread the load of the VDA server groups on the Controllers. However, larger environments might require to increase the allowed number of remote sessions on the Controllers. In addition to that, Microsoft also uses an overall limit for all remote sessions as well as a quota for each shell plugin. Depending on which limit has the smaller number, that limit will apply. So please make sure, to set all limits accordingly. Please find an example on how to set the limit to support up to 100 remote sessions:

  • Set-Item WSMan:localhostShellMaxShellsPerUser 100
  • Set-Item WSMan:localhostPluginmicrosoft.powershellQuotasMaxShells 100
  • Set-Item WSMan:localhostPluginmicrosoft.powershellQuotasMaxShellsPerUser 100
  • Restart-Service winrm

To allow remote PoSH sessions, the service account needs proper rights on the Delivery Controller:

  • Add the service account to the local group “Remote Management Users” on each Delivery Controller

Finally, let me provide some details regarding deployment and configuration:

I personally prefer to deploy files – in this case the script, key and password file – with Group Policy Preferences (GPP). This ensures that each VDA downloads the current version of the script from a central share.

Modifying the membership of the Delivery Controllers “Remote Management Users” group can be achieved by GPP easily.

The task scheduler can be 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 appropriate VDAs. The cool thing about targeting, it’s quite flexible. For example, you can use Organizational Units (OU) or Active Directory Security Groups to assign the proper scheduler to a server Group.

Example action without forced logoff:

“C:WindowsSystem32WindowsPowerShellv1.0powershell.exe” -ExecutionPolicy RemoteSigned -File <path to script> -FirstMsgDelay 600 -MsgDelay 600 -RebootDelay 300 -ForceLogoff 0 -ImidiateRestart 0

Example action with forced logoff:

“C:WindowsSystem32WindowsPowerShellv1.0powershell.exe” -ExecutionPolicy RemoteSigned -file <path to script> -RebootCycle 3600 -FirstMsgDelay 600 -MsgDelay 600 -LogoffDelay 300 -RebootDelay 300 -ForceLogoff 1 -ImidiateRestart 0

Script command line parameters:

  • RebootCycle
    • Disable logon prior to the reboot sequence.
    • Default cycle is 1 hour (3600 seconds).
    • Only relevant if ForceLogoff = 1
  • FirstMsgDelay
    • Delay first user message in seconds.
    • Default delay is 0 minutes.
  • MsgDelay
    • Delay between user messages in seconds.
    • Default delay is 10 minutes (600 seconds).
  • LogoffDelay
    • Delay between last user messages and forced user logoff.
    • Default delay is 5 minutes (300 seconds).
    • Only relevant if ForceLogoff = 1
  • RebootDelay
    • Delay between forced user logoff and server reboot.
    • Default delay is 5 minutes (300 seconds).
  • ForceLogoff
    • Choose whether session logoff is enforced (1) or not (0).
    • Default is no enforcement (0).
  • ImmediateRestart
    • Choose whether restart will occur immediately if no sessions are found on server (1) or not (0).
    • Default is wait till end of reboot sequence (0).

Script parameters (need to be set within the code):

  • Log file and log directory.
  • Delay values for remote session and random start.
  • Message title and body for user messages.
  • Key and password file for the service account.
  • Service account name.

The script can be downloaded here.

Hope this might be useful for you as well.

Until next time!

Robert Woelfer
Principal Consultant | Citrix Consulting Central and Eastern Europe

P.S.! So we can 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.

YES BANNER