Terminal Services

FishOnAHFishOnAH Member Posts: 55 ■■□□□□□□□□
I have a TS question...

BACKGROUND INFO
We have a 150 server Citrix farm and we occasionally need to down a server for maintenance or re-image via an Altiris scripted build. (Servers run Win2k3 Std w/SP2) What I usually do if users are logged into the server and I’m not wanting to kick them off, icon_twisted.gif I run “chglogon /disable” on that server. It’s a command that is a part of TS and prevents any new users from connecting to that server but allows users already connected to continue using their application(s). Once they are off, I down the box.

QUESTION
My question is after I re-image a server, (which involves a fresh install of Windows), logins are still disabled on the server. I have to “chglogon /enable” to re-enable them. This is not an issue at all for me, and it is really a good thing. I could easily add the command to the end of my build if I wanted to, but I don’t. I've always just been plain curious and never wanted to research it, what is it in our environment that is holding that setting to allow it to still apply after windows has been freshly installed?

Comments

  • ClaymooreClaymoore Member Posts: 1,637
    It should be stored in the session directory database (2003) or session broker database (2008 ). This is the same database that tracks user sessions and allows them to reconnect to previously disconnected sessions. I thought it sounded like an AD property, but the session drain state is evidently stored in a separate database.

    How to Configure Terminal Services Session Directory Service

    TS Session Broker Load Balancing Step-by-Step Guide
  • astorrsastorrs Member Posts: 3,139 ■■■■■■□□□□
    Claymoore wrote: »
    It should be stored in the session directory database (2003) or session broker database (2008 ). This is the same database that tracks user sessions and allows them to reconnect to previously disconnected sessions. I thought it sounded like an AD property, but the session drain state is evidently stored in a separate database.
    This won't apply as it's a Citrix farm and doesn't use the TS Session Broker.

    FishOnAH I'm going to take a wild guess here and suggest that one of the things you did prior to saving the master server image to the Altiris deployment server was disable logins... Perhaps it's the master server image that's your problem.

    Also I usually recommend creating an "Offline" load evaluator in Citrix and using that instead of disabling logins. It's not easy to tell which servers have logins disabled in the farm, but by using a load evaluator you can quickly look at the usage reports for load evaluators and determine which servers are in maintenance mode.

    Here's a blog post from about 5 years ago covering it: Using Off-Line Load Evaluators to Deal with Broken MetaFrame Servers - Guest Bloggers - BrianMadden.com

    You can easily adapt this to work with your Altiris re-imaging process by executing a script to set the appropriate load evaluator on boot - this is usually what I'll do when working with Ardence (Citrix Provisioning Server).
  • FishOnAHFishOnAH Member Posts: 55 ■■□□□□□□□□
    Astors-It is not something in the Altiris image, as if logins are enabled before I re-image the server, logins are enabled after I re-image the server.

    Claymoore-I took a glance in our OU that holds our Citrix servers and did not see the Session Directory Server policy enabled. (or in any policy in could inherit from).

    I appreciate your thoughts, I do plan to look into maybe creating an offline load evaluator in Citrix as it looks like it could be a better solution for us. Thanks for the article!

    Any other thoughts on the TS issue though?
  • astorrsastorrs Member Posts: 3,139 ■■■■■■□□□□
    FishOnAH wrote: »
    Astors-It is not something in the Altiris image, as if logins are enabled before I re-image the server, logins are enabled after I re-image the server.
    Okay I had to ask, sometimes it's the simple things we miss.When you re-image the server are you doing it from a copy of the same server or a generic image? For example:

    You shutdown SERVER01 and re-image it with a SERVER01 image?
    or
    You shutdown SERVER01 and re-image it with a generic SERVERxx image and then add it into the Citrix farm etc?

    If you're doing the 1st one that setting will be stored in the server's properties within the IMA datastore hence why it would be retained.

    If you're doing the 2nd one, are you deleting the old entry for that server from the farm prior to adding a new server into the farm with the same name?
  • FishOnAHFishOnAH Member Posts: 55 ■■□□□□□□□□
    "You shutdown SERVER01 and re-image it with a generic SERVERxx image and then add it into the Citrix farm etc?"
    --YES...but it joins the farm automatically.

    "If you're doing the 2nd one, are you deleting the old entry for that server from the farm prior to adding a new server into the farm with the same name?"
    --YES, we are doing the 2nd one, NO we do not delete the old entry for that server in the farm, joins during the build and never duplicates its self in the farm.

    It would be more a generic "image". I want to use the term image loosly as it is what I consider to be a scripted build that installs Windows Server 2003, installs various applications, installs Citrix PS4.5, updates, etc., etc. It is not anything like a ghost image or a snapshot of a server. The same scripted build works on a couple of different server models we have as the HP PSP for the two model of blades we have work with one another. The only thing that is different in the Citrix image versus our standard server image are the jobs in the build that install, configure, and update Citrix.

    Clear as mud? :)
  • astorrsastorrs Member Posts: 3,139 ■■■■■■□□□□
    Yeah it's clear. :)

    Since you're reusing the same name for the server, Citrix thinks it's the same machine. The IMA datastore doesn't use SID/GUIDs or anything special to track servers, just their name.

    Since you are disabling logins prior to shutting down the server it is inheriting the setting once it rejoins the farm. Since this is all scripted, why not execute a "chglogon /enable" at the end of all the scripts? That will solve your problem with a minimal amount of change to the environment.
  • FishOnAHFishOnAH Member Posts: 55 ■■□□□□□□□□
    Yeah, like I said, I could easily add a script to re-enable logins, I was just curious what was causing the server to retain the setting. "More of a how does it do this" question than a "how do I fix it" question. Just one of those deals I've been curious about.

    So, you are saying: "...it is inheriting the setting once it rejoins the farm." Are you saying it is the Citrix farm itself that is retaining that setting for the server?
  • astorrsastorrs Member Posts: 3,139 ■■■■■■□□□□
    FishOnAH wrote: »
    So, you are saying: "...it is inheriting the setting once it rejoins the farm." Are you saying it is the Citrix farm itself that is retaining that setting for the server?
    Yes, unless I'm mistaken the IMA datastore (Citrix farm database) stores it in addition to the registry setting on the server itself. That would at least explain the behavior you're seeing.
Sign In or Register to comment.