Jump to content
Welcome to our new Citrix community!
  • 1

What good is maintenance mode?


Joe Pawlicki

Question

XD7.1=Server OS+Published apps

It appears to me that maintenance mode is unable to do what I want: take a machine out of rotation so it can be patched, etc.  The scenario is this: a delivery group with three machines serving applications; put machine A into maintenance mode so it won't accept new connections; notify users on that server to close apps & logout/login; once all users/sessions have bled off the server, take it down for maintenance.

 

The problem is that when users close apps and logout of StoreFront, their disconnected session remains on the server, and upon login Citrix will happily put them back on that server, even though it's in "maintenance mode".  Docs indicate this is the designed behavoir.  How could this ever work in any practical way?  I can't just notify users and wait for sessions to bleed off the server; I now have to coordinate among ALL users, make sure they ALL logoff and stay logged off, until I can manually remove all those disconnected sessions, and only then have them login and launch apps again.

 

Am I missing something, and has anyone found a practical way to use this for, you know, doing actual maintenance?

 

Thx.

Link to comment

Recommended Posts

  • 0

Answer from technical support is that this is the designed behavior.  It's bad design, but at least it works as coded, I guess.  So, my "maintenance mode" is now an unceremonious forced reboot, and "sorry" to the affected users.

What difference does it make? If they were unable to reconnect (like you could set in XA6.5) then they would lose their session and have to start with a new one anyways. Simply put the delivery group  or VDA into maintenance mode and wait for them to drian off. If you need to move faster send them a message and force a log off.

Link to comment
  • 0

What difference does it make?

 

Either you're misunderstanding, or I am.

 

If if worked like it used to, or like other rational technologies such as load balancers do, I could do the following:

  1. Notify users on the affected server that they should save their work, and logout/login as soon as they're able.
  2. They could log right back in WHEN THEY'RE READY, because they'd get assigned to a healthy server.
  3. I could watch sessions drain, then perform the required maintenance on the server.

Instead, here's what I have to do:

  1. Notify users on the affected server that they should save their work, and logout, BUT NOT LOG BACK IN.
  2. Somehow communicate with potentially dozens of users on that server, to get them all saved out of their applications and logged out AT THE SAME TIME.
  3. Somebody's away from their desk, or not answering their phone?  Too bad, we all wait.  Or else, I unceremoniously dump them out of whatever work they were doing, and we repair the damage later.
  4. Only when I've got everybody off, and waiting for me, can I take the system down so that nobody can get reconnected to a previous session.
  5. Now I once again communicate with dozens of people that they can log back in and get assigned to a healthy server.

If you don't see a difference between the two scenarios, perhaps I could suggest a career at Citrix.  I don't know if your suggestion re: the ENTIRE delivery group is serious, but it's certainly worse.  And if I have to resort to forcing logoffs - or unceremonious server reboots - then my question remains: What the hell good is "maintenance mode"?

Link to comment
  • 0

Why are the sessions disconnecting? Normally if the user closes the published app then the session also closes. If not, what process is keeping the session open?

 

That, for us, is the $250,000 question.  Why is XenDesktop 7.1 so bug-ridden that I'm spending weeks troubleshooting basic functionality such as session creation & teardown?  Read thru some of these forums, and you'll see similar problems going back YEARS, with tech support often taking the stance of "talk to Microsoft".

 

If this worked as it's supposed to, I'd have a highly-available collection of app servers, where my users are logging in/out and running applications to their hearts' content.  And I could perform required maintenance as required, without laughable approaches such as "wait until the weekend to take a system down", or "just kick everybody off".

  • Like 1
Link to comment
  • 0

Either you're misunderstanding, or I am.

 

If if worked like it used to, or like other rational technologies such as load balancers do, I could do the following:

  1. Notify users on the affected server that they should save their work, and logout/login as soon as they're able.
  2. They could log right back in WHEN THEY'RE READY, because they'd get assigned to a healthy server.
  3. I could watch sessions drain, then perform the required maintenance on the server.

Instead, here's what I have to do:

  1. Notify users on the affected server that they should save their work, and logout, BUT NOT LOG BACK IN.
  2. Somehow communicate with potentially dozens of users on that server, to get them all saved out of their applications and logged out AT THE SAME TIME.
  3. Somebody's away from their desk, or not answering their phone?  Too bad, we all wait.  Or else, I unceremoniously dump them out of whatever work they were doing, and we repair the damage later.
  4. Only when I've got everybody off, and waiting for me, can I take the system down so that nobody can get reconnected to a previous session.
  5. Now I once again communicate with dozens of people that they can log back in and get assigned to a healthy server.

If you don't see a difference between the two scenarios, perhaps I could suggest a career at Citrix.  I don't know if your suggestion re: the ENTIRE delivery group is serious, but it's certainly worse.  And if I have to resort to forcing logoffs - or unceremonious server reboots - then my question remains: What the hell good is "maintenance mode"?

Obviously one of us is confused.

#1....why can't they log back in/ If you put the VDA into maintenance mode its not going to allow new sessions and they will get a session from a VDA not in maintenance mode.

 

#2 I don't see how this is different than 6.5. If session are disconnected you'll have to log them off. If users are active then tell them to log off (after you put the VDA in maint. mode) and log back in. They will get to a new VDA.

 

#3 How is this different on 6.5? If they are away or disconnected then you will have to deal with their session and potential data loss.

 

#4 see above. I don't know why you need have everyone off and staying logged out.

 

#5 Same as #4.

Link to comment
  • 0

Because, in 7.1, when a user logs out, their Disconnected session remains.  If they log back in, they will be assigned to that same server, even though it's in maintenance mode.  THIS is the problem I'm describing.  In previous versions there were options for maintenance mode to disallow only new connections OR BOTH new and existing/disconnected.

 

Got it?  If they're allowed to re-connect to their disconnected session on the "bad" server, they'll start working again and I'll be right back to an ungraceful booting of users mid-application when I take the server down.  Someone at Citrix engineering decided they no longer needed to allow this option, hence, the answer from tech support that this is "working as designed" in 7.1.

 

Again, I think if you'll carefully read the two scenarios I outlined above, you'll understand what a problem this can be for a production environment with many users.  Just to reiterate, this is with server OS and published apps only.

Link to comment
  • 0

Because, in 7.1, when a user logs out, their Disconnected session remains.  If they log back in, they will be assigned to that same server, even though it's in maintenance mode.  THIS is the problem I'm describing.  In previous versions there were options for maintenance mode to disallow only new connections OR BOTH new and existing/disconnected.

 

Got it?  If they're allowed to re-connect to their disconnected session on the "bad" server, they'll start working again and I'll be right back to an ungraceful booting of users mid-application when I take the server down.  Someone at Citrix engineering decided they no longer needed to allow this option, hence, the answer from tech support that this is "working as designed" in 7.1.

 

Again, I think if you'll carefully read the two scenarios I outlined above, you'll understand what a problem this can be for a production environment with many users.  Just to reiterate, this is with server OS and published apps only.

 

How can a user have a disconnected session if they log out? If a user logs off there is no more session. If they disconnect then the session state is disconnected. If you have users logging off and there session doesn't end then you have a completely different issue you need to look at.

Link to comment
  • 0

While I appreciate folks' willingness to help, these forum threads are often a frustrating exercise in trying to explain the issue repeatedly.

 

"If a user logs off there is no more session"  Correct ONLY if XD7.1 works as intended.  See other threads regarding bug LA5197, and sessions that remain forever in a disconnected state; again, such issues have existed with Citrix for many years, regardless of the cause(s).

 

The removal of a disconnected session is supposed to be user-configurable via timeouts.  One may wish to have disconnected sessions remain available for a time because, during normal use, it eliminates the performance penalty of session re-creation.  One may not ALWAYS want immediate destruction of disconnected sessions.

 

Regardless, the point is that whatever the user session timeouts are, or whatever other issues may be preventing session removal, Citrix made the conscious decision to REMOVE functionality that would've allowed for a usable "maintenance mode".

  • Like 1
Link to comment
  • 0

While I appreciate folks' willingness to help, these forum threads are often a frustrating exercise in trying to explain the issue repeatedly.

 

"If a user logs off there is no more session"  Correct ONLY if XD7.1 works as intended.  See other threads regarding bug LA5197, and sessions that remain forever in a disconnected state; again, such issues have existed with Citrix for many years, regardless of the cause(s).

 

The removal of a disconnected session is supposed to be user-configurable via timeouts.  One may wish to have disconnected sessions remain available for a time because, during normal use, it eliminates the performance penalty of session re-creation.  One may not ALWAYS want immediate destruction of disconnected sessions.

 

Regardless, the point is that whatever the user session timeouts are, or whatever other issues may be preventing session removal, Citrix made the conscious decision to REMOVE functionality that would've allowed for a usable "maintenance mode".

 

Ok, so let me get this straight. Your complaining about a feature that's is working as designed (maintenance mode) because some other component is broken? I would focus my efforts with Citrix on fixing the hung/disconnected sessions issues you're rather than hoping they will change the maintenance mode feature.

Link to comment
  • 0

Great, maybe they'll provide a setting called "perfect stability mode", which gives the user a checkbox.  It doesn't actually DO anything, but if the checkbox works, then it's functioning as designed!

 

I'd happily accept either solution: a stable session creation/removal process, or the return of a previous feature that allows some administrative flexibility, and takes about one line of code.  However, given the years-long history Citrix has with session operations being broken, and the number of cases I currently have open to try to get to the bottom of this, I won't hold my breath for either.

 

This thread is now, officially, pointless.

  • Like 1
Link to comment
  • 0

I know exactly the issue you complain about and one would think if its in maintenance mode the sessions should not be able to reconnect, but was designed this way and is technically working as designed. I don't agree with it, but it is what it is for now. However, when I have used logoff, I just go in and remove any session that is hung in disconnect. That situation is rare though on my end. I also have a script that removes disconnected sessions after 10 minutes. I find it more reliable than session timeouts (Mainly because I control the code.)

Link to comment
  • 0

Is it possible that the XenDesktop controller stops updating session state information for disconnected 'app' sessions once a server (or workstation VDA) is put into maintenance mode?

 

I had a situation yesterday where I put a catalog of XP VM's (running a legacy 'vm hosted' app) into the maintenance mode so I could bring a new replacement catalog online.  There was one user who had a disconnected session to an XP VM in the old catalog when I did this.  Today the user could not launch the legacy app and received a message saying "the desktop you are trying to connect to is in maintenance mode", and when I checked in Studio, it still showed the disconnected session from yesterday.  All the other users who were already logged off the old catalog were able to launch their app today from the new catalog without any problems. 

 

We have a 2 hour timeout configured for disconnected sessions and this has been working fine for the XP and 2008R2 VM's (but needed a patch for 2012R2).  I opened the VM console of the respective XP VM in the old catalog and it didn't show any user as being logged on.  Once I shut this VM down, then the disconnected session disappeared from Studio and the user could now launch their app via the new catalog.

 

It kind of looks like the XenDesktop controller didn't update the session state once the session had been logged off (via timeout) because the VM was in maintenance mode.  I haven't noticed this issue occurring for published desktops, so maybe it is limited to 'published apps' that are running from either server or workstation VDA's.

Link to comment
  • 0

I've seen session staying in disconnected state because of a process keeping them active, I had this with an sccm 2012 agent component running a process in each user session, and also with Symantec endpoint protection v12.1 doing the same (and consume 40mb per session extra), registry changes solved the behavior, when no process is keeping a session active we have no remaining disconnected sessions in xd7.1.
what is concerning the maintenance mode behavior this is clear.
tnx, _i

Link to comment
  • 0

I may have missed it, but if it hasn't already been posted, (and 7.7/8 may be different)... the alternative is a regkey change on the server. I create 3 regkey shortcuts on a Server VDI which drains users... it uses Microsoft's process and it allows admin access still.

Use this to drain users, change value to 00000001 to drain until next reboot and 00000000 to disable drain. It works instantly and I've given up on all other methods of draining users...

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server]

"TSServerDrainMode"=dword:00000002

 

For draining Citrix Delivery Controllers, remove it from the list of load balanced CDC's, (it won't kill existing sessions), and for Store fronts load balanced on Netscaler, disable the node from Netscaler that points to your Store front server.... it's not ideal but it works...

 

It would be nice for Citrix to wrap up all this tricks into a GUI setting from Studio but till then...

Link to comment
  • 0

I feel like Joe (and his duplicate account Joseph) should read the actual documentation which clearly outlines this behavior. This isn't unexpected or abnormal. For servers it is behaving as "Prohibit Logons Only" like it does for XenApp 6.x

 

User connectivity is affected as follows when in maintenance mode:

  • With Server OS machines, users can connect to existing sessions but cannot start new sessions.
  • With Desktop OS and Remote PC Access machines, users cannot connect or reconnect once the machine is in maintenance mode. If they are already connected, then they stay connected until they next disconnect or log off.

 

https://docs.citrix.com/en-us/xenapp-and-xendesktop/7-5/cds-manage-delivery-groups-wrapper/cds-put-desktop-into-maintenance-mode-rho.html

 

 

God forbid we actually read documentation before having a temper tantrum on the forums! If sessions are being held active when a user closes their application he should be reviewing the processes running and make the appropriate modifications to LogOffCheckSysModules which should clean them up. 

 

Or you know, do Provisioning or MCS and work on your Maintenance VM.

Link to comment
  • 0

Also, regarding Jason's post, it appears his solution behaves exactly like Maintenance Mode does.

 

 

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

 

 

 

Maintenance Mode (what Joe is complaining about) behaves identically to setting that value to '2'

Link to comment
  • 0

"I feel like Joe ... blah, blah, blah"

 

 

Wow, apparently others have also come across this limitation and decided to resurrect a two-year-old thread.  Glad to see folks have found creative ways of trying to overcome this silly limitation.
 
God forbid Chris (if that's his actual name!) should actually read thru the thread and understand it, before chiming in with a completely useless link.  No point in trying to summarize here, yet again, how this poor design combined with broken features creates a completely avoidable problem.  For many, including Citrix technical support, "functioning as designed" is the ultimate get-out-of-jail-free card, regardless of how flawed that design may be, or how much the design may have eliminated functionality that existed previously.
 
And if you'd care to give me any details on a duplicate account, I'd happily look into it; there isn't one that I recall, and I have nothing to hide, whatever nefarious motive you're attempting to imply or how you might get off on trying to devolve a technical discussion into some personal gutter.
 
Cheers.

 

Link to comment
  • 0

Hi Joe! The account comment was just a funny thing I noticed, they have different join dates so you've either got an imposter or in fact have duplicate accounts.

 

http://discussions.citrix.com/user/12499736-joe-pawlicki/

 

http://discussions.citrix.com/user/12535719-joseph-pawlicki/

 

Not sure how that link was useless though, it very clearly lays out the expected/designed behavior of maintenance mode for Server OS with a 7.x VDA. 

Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...