Introduction
“I choose a lazy person to do a hard job. Because a lazy person will find an easy way to do it.”
– Bill Gates
Many people know that I am a big supporter of laziness in IT (and I wrote about it before, too). Lazy approach is actually very hard – it requires a lot of effort to learn how to minimize the amount of work and to be more effective. As you can imagine, it’s very time consuming in short term. In my case, I prefer to automate repetitive or time consuming tasks, but there are also other methods how you can save some time.
One of the reasons why people are creating blog posts is to have a simple way to answer questions that are being asked by many different customers. When customer asks you a question, you can either spend a lot of time discussing the topic, or ideally point him to existing article where the topic is being explained. When such article doesn’t exist, it’s best time to create one!
Drain maintenace
When dealing with environment that is shared by multiple users, concept of drain-mode maintenance is very important. Drain-mode maintenance is used in scenarios where you cannot move the resources – two most typical examples are VMs that are hosted on local storage (without storage motion capability) and scenario where single operating system is providing environment for multiple users (session motion is technically not possible – don’t want me to get started talking about mutexes and semaphores). You want to have ability to put such resource into drain-mode – leave existing sessions intact (this includes the ability to reconnect to disconnected session), but redirect all new incoming requests to another resource. Once all existing VMs\sessions are gone, you can proceed with the resource (whether it’s XenApp server or physical host).
When dealing with customers that are migrating from older versions of XenApp, assignment of load evaluators is one of the common topics (together with impact of worker groups on their environment). To explain the background – in the past, it was very common to create custom load evaluator (often called “No New Logons” or “Maintenance”) that will report full load (10000) when assigned to server. There were typically three reasons why customers preferred this method:
- Since LE assignment was stored in data store, you could assign it to server that was offline
- Custom LE will reject new sessions, however it will allow you to reconnect to your existing session
- Custom LE will affect only ICA connections, but RDP connection for administrators will still be allowed
XenApp 6.5 approach to maintenance
With XenApp 6.5, ability to directly assign load evaluators to specific servers was removed, instead you’re assigning load evaluators to whole group of servers. This approach is required in order to support dynamic provisioning and ability to manage group of servers as single entity. However, customers are looking for a way how to put a single server into maintenance mode.
This functionality is provided in XenApp 6.5 by logon mode control. It simply allows you to specify few different settings (below information was taken from our official documentation):
- Allow logons and reconnections. Enable all logons, reconnections, and session sharing (default setting).
- Prohibit logons and reconnections. Reroute all logons, reconnections, and session sharing to other servers.
- Prohibit logons only. Reroute new connections and session sharing, but allowing users to reconnect to disconnected sessions. This state persists until you change it manually.
- Prohibit logons until server restart. Reroute new connections and session sharing, as above, but after restarting the server, the setting automatically changes back to Allow logons and reconnections.
While logon control allows you to configure drain maintenance (disabling new logons, while keeping ability to reconnect to existing sessions), there are however some concerns that are very common:
- These settings are just using “change logon” command, so you can apply them only to the online server
- Setting drain mode will disable all connections, including RDP access for maintenance purposes
The common mistake is that XenApp is just using RDS logon mode. The confusion partially comes from the fact that XenApp logon mode and RDS logon mode are in sync – so when you change the RDS logon mode, this change is automatically replicated to data store (and other way around).
Ability to use RDP
When you disable access to the server, you might want to use RDP to connect to such server (for example to fix some issues). However, if you try to RDP, you will get following screen:
This is expected behavior – however, you can still use admin RDP to connect to such server (MsTsc /Admin). RDP access is disabled for regular users, but it’s still possible for administrator to connect to server in drain mode.
Ability to disable access to offline server
Logon mode for RDP is per-server configuration that is stored in registry. Configuration of logon mode is stored in registry in two different locations:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\TSServerDrainMode
0 = Allow all connections
1 = Allow reconnections, but prevent new logon until reboot
2 = Allow reconnections, but prevent new logon
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\WinStationsDisabled
0 = Enabled
1 = Disabled
When server is in drain mode, WinStationDisabled is always 0 (enabled).
Now the interesting part is that XenApp logon control is actually managed through data store and is updated using LHC synchronization notification. So when you change the logon mode in console, this change is actually not immediately done on the registry of the target machine. When XenApp server is offline and you change the logon mode, it will get notification from data store during boot and automatically apply the logon mode that you’ve configured in the console. This allows you to change logon mode even while server is offline.
Temporary drain mode (Prohibit logons until server restart) is however available only when server is online.
Logon Mode in PowerShell
Especially in larger and more dynamic environments, it’s very common to automate the whole maintenance process. If you want to automate assignment of logon modes, there are two commands that you can use:
To assign logon mode to server:
Set-XAServerLogOnMode -LogOnMode $LogonMode -ServerName $Server
Since logon mode is enumeration, you can use this universal method to get all allowed values:
[Enum]::GetValues(“Citrix.XenApp.Commands.LogOnMode”)
To save you some time, I’m also going to list all allowed values for $LogonMode:
- AllowLogOns
- ProhibitNewLogOnsUntilRestart
- ProhibitNewLogOns
- ProhibitLogOns
To get logon mode assigned to server, it’s one of the properties of the regular server object:
$(Get-XAServer -ServerName $Server).LogonMode
Summary
- Usage of custom load evaluator was just a workaround to provide required functionality in older versions of XenApp, however with availability of logon modes there is no reason to use the old approach
- Administrators still get RDP access to disabled servers to perform administrative tasks
- Since logon mode is implemented through IMA, it is possible to disable server even if it’s offline
Posted in Citrix Blogs
