Citrix XenApp 6.5 Custom Session Policy for Change Management and Reboot

This question comes up often enough to justify a short article regarding notification of Citrix users during change window or scheduled downtime.
 
This article demonstrates the versatility of Citrix Policies in XenApp 6.5. Consider a scenario where a change is required at 5PM on Sunday to some or all Citrix application hosting servers. The Citrix environment is 24x7.
 
This article assumes that Citrix Best Practice and Microsoft Best Practices implemented for version 6.5 XenApp. XenApp hosting servers are organized using Citrix Worker Groups. Worker Groups are bound to Published Applications and Active Directory Domain Local Groups bound to the Published Application. This article assumes basic best practices:

1. Domain Local Groups assigned to Published Applications (not users direct)
2. Worker Groups representing Silo servers created and associated servers bound (added)
3. Citrix Policies configure to Worker Groups.

 
The simplest approach is to create a custom Citrix Policy for server reboots. The policys allows you to place servers in maintenance mode, send custom messages to users, and reboot the servers starting at a precise time, and they can be combined with Worker Groups to allow for granular control of reboots by server role.

Consider downloading the Powershell SDK for 6.5 to automate this sequence: https://www.citrix.com/downloads/xenapp/sdks/powershell-sdk.html

Using custom user policies, computer policies, Worker Groups and session load metrics it is possible to create custom criteria for disabling server logins (or maintenance mode), alerting users, logging off disconnected sessions, and more. The users that are disconnected would not be able to log off so the assumption is the users that connected at the time will log off as indicated by the custom warning message. The message pops up on the user screen each time and they must click OK to acknowledge the message.

The strategy begins with an Empty WORKER GROUP. Right click > Create Worker Group > WG_SUNDAY_CHANGE_WINDOW_SERVERS.

WORKER GROUP
LOAD EVALUATOR
Beginning in the Application Console > Load Evaluator > New > SUNDAY-CHANGE-WINDOW-12AM 
Click box next to SCHEDULING.

This Load Evaluator will be bound to the Citrix Policy that is bound to the WORKER GROUP. It is important to understand that adding this evaluator stipulates when the servers are not unavailable. The schedule should reflect this so it can be active at all times on the Worker Group by way of Citrix Policies.

Click Add > MONDAY THROUGH FRIDAY > ALL DAY. Next, SATURDAY > ALL DAY. This setting is bound to a Policy. We need to set hours of operation to Monday through Saturday all day. Anything bound to this policy allows login Monday to Saturday ALL DAY.  However, Sunday login disabled.  You can refine this from all day to a few hours.  If your change window is Sunday 1AM to 4PM modify the Sunday hours accordingly.  You have set a hours of operations, essentially.   If your change window is 4 hours every Sunday then this is where you can define those specific hours of availability.

Any servers added to this Worker Group will have this Load Evaluator assigned using Citrix Policy bound to the Worker Group. Any servers dropped in that Worker Group would become unavailable on Sunday. You can refine this time on Sunday further using aformentioned steps. These servers can remain in the worker group indefinitely.  As stated prior, you have set hours of operation when servers allow login and published applications work.  

Or, you can add servers to the worker group the day before the change window and remove them after the change window. 

There are two types of Citrix policies: Computer and User. First define the Computer policy that will bind to the Change Window Worker Group. 

In the Application Console > Policies Section, create a custom Computer Policy > Policies > Computer Tab > New > "Change-Weekend-Reboot-Schedule"

Add and configure the SERVER SETTINGS > LOAD EVALUATOR NAME > Select the Load Evaluator just created.

This step binds the Load Evaluator that defines "Hours of Operation" to any servers added to the worker group as ALL DAY Monday to Saturday.  

Click on "Settings" tab > Scroll down to REBOOT BEHAVIOR > Add each setting one at a time:

Starting with the first setting "Reboot Custom Warning" > Set to "Enabled". This activates the ability to send a warning message. If you define the message but do not enable it then it will not work properly.


The next setting is "Reboot Custom Warning Message". This is the message you want users to see and there are options to modify when they start and how often they appear. For now, the assumption is notification and time to log off. A sample message:
"This server is now in maintenance mode, please save work and logoff. This is a scheduled maintenance window so be advised that your session will logoff automatically at a predetermined time."


Next, REBOOT LOGIN DISABLE TIME stipulates when you first disable logins prior to your start time. You have the option of up to 60 minutes per policy. Citrix allows for more than one policy. You can combine policies for more granular control. For this demonstration, this setting is 60 minutes prior to reboot.  The next setting is the time of reboot where this setting enables a "Window" where logins are disabled and users are asked (then possibly forced) to logoff.


The next logical setting is REBOOT SCHEDULE TIME of HH:MM AM or PM. This is when the server is placed in "Maintenance" mode or in equivalent terms "Disabled Logins". This is not to be confused with Maintenance mode from the VMWare perspective or other meanings. The goal here is the automation of disabling any new logins and using the prior settings to control user sessions on the server. Then schedule updates and reboots.

Next, REBOOT SCHEDULE START DATE is set to the date of the intended change. In this example we have used Sunday 2/14/2016. Logins will be disabled at 12AM. At that time the first message is sent to users asking them to logoff within sixty minutes.


Next, set the REBOOT WARNING INTERVAL. The timer starts at 12AM, so sixty minutes prior to 12AM logins are disabled and the message is sent to users. Set the option to send that same message every 1, 3 5, 10, or 15 minutes.


Next is REBOOT WARNING START TIME, not to be confused with REBOOT LOGON DISABLE TIME above. This setting provides additional control allowing you to set the start time


At this point, the server reboot is scheduled for 12AM. 60 minutes prior to reboot the REBOOT WARNING START TIME is 60 minutes starting at 11PM. The REBOOT LOGIN DISABLE TIME also set to 60 minutes prior - 11PM. Users would get a warning every 15 minutes with the REBOOT WARNING INTERVAL set to every 15 minutes.

The last view settings in this section enable these policies or "Activate".

REBOOT WARNING TO USERS
SCHEDULED REBOOTS

Before creating the USER POLICY enable the ICA Keepalive to activate the user disconnect and reset settings. Without these enabled user session timeouts do not function correctly.

Click NEXT to finalize the Computer Policy

Next, select the Worker Group (Add) to the policy. Click ADD to the right of Worker Group > ADD> Mode: ALLOW > Check ENABLE THIS FILTER ELEMENT > Click BROWSE > Locate the Worker Group > Double Click > OK

This completes the first phase of the Computer policy. UNCHECK "Enable this policy". This is to prevent any policies being applied before we set the final priority or user policies.


USER POLICY
Next we need to create the corresponding user policy that is applicable to Users. Start by creating a new User policy named USER-POLICY-SUNDAY-CHANGE-WINDOW. Notice I don't leave spaces between names? This helps alleviate errors with Powershell CMDLETS that you can easily use to quicken these steps. XenApp 6.5 supports remote management using Powershell.

For now click NEXT and scroll down to SESSION LIMITS. This article assumes your concurrent sessions are optimized already using Citrix Policies per my article Maximize Citrix Concurrent Licensing To Reduce Cost – Session Timeouts - 3 Millon Dollar Cost Save.

A critical part of the strategy here is the Worker Group created earlier. Servers can reside in more than one Worker Group. Citrix Policies can bind to more than one Worker Group. This scenario works best when times are set in stone regarding the changes. Policies use a weighing system called "Priority" and there is the option to enable or disable a policy.

A quick note: These policies, servers and worker groups can be managed using Powershell rather than GUI.

A Policy that leverages the Session Timeout strategy mentioned above requires this policy have a HIGHER PRIORITY, with 1 being the highest. Whichever policy is at the top has the highest priority.

Proceed to the next screen, SESSION LIMITS section - here are the settings:

ENABLE

SET TO 5 MINUTES
Add the servers requiring notification of change to maintenance mode to the single Worker Group now bound to the USER and COMPUTER policies. Customize settings as required.

Move the USER policy to Highest Priority of 1.  
Do the same for Computer Policy
Add the servers ready for changes the day before. Most of this can be scripted but is not covered in this writing.

Sunday, you have a Window at 12AM (just an example) where at this point all IDLE sessions were disconnected and disconnected sessions reset and no one is able to login starting Sunday morning 12AM. This makes those servers unavailable and gives users plenty of time to save their work and logoff.