I am sure someone will correct me but...no.

A server can either be an available server or not for a published app.  You would have to create a secondary app to give the group of people that are in a disconnected state and manage that manually.  Not pretty.

Hello,

Instead of removing the Server from a Published App, I would try the following.

1. Create a new workload evaluator with a "Number of Users" Counter

2. Set the Max number of Users to  0

3. Assign this Workload Evaluator directly to the Terminal Server that you wish to Disable.

This should stop new connections but allow existing disconnected sessions to re-connect.

There are certain setups where this method won't work - but give it a go, it might be ideal for you.

Thanks, Andrew.

Hi Andrew!

We tried this, but it did not work... I created a "Workload Evaluator" with the counter "Number of Users" to a "Max Value" of 0... Users without disconnected sessions were still able to logon to the server where I applied this Workload Evaluator (are currently using 2 terminal servers with a published desktop).

Regards,

Alexander

Hi!

Yes, that would be a solution, but it's not pretty as you said.. 

// Alexander

I sure, had... Changed it to "Not specified", will give it another try and report back.. 

// Alexander

I'm sorry to say that the connection broker does not detect if the server is "draining".... It sends client to that server despite beeing drainstopped (change logon /drain).

You only get the usual "Remove logins are currently disabled". 

// Alexander

I always drainstop the servers from the server itself

Enable, disable, or drain session logins.

CHANGE LOGON {/QUERY | /ENABLE | /DISABLE | /DRAIN | /DRAINUNTILRESTART}

  /QUERY    Query current session login mode.
  /ENABLE   Enable user login from sessions.
  /DISABLE  Disable user login from sessions.
  /DRAIN    Disable new user logons, but allow reconnections to existing sessions.
  /DRAINUNTILRESTART    Disable new user logons until the server is restarted, but allow reconnections to existing sessions.

How do you handle it in combination with vWorkspace connection broker?

// Alexander

If you have a Workload evaluator on the published app, this may override the W.E applied at the TS level. 

The conenction broker should automatically determine if a TS server is accepting connections.

I haven't done much with the CB yet as I am working on a migration from the microsoft RDS, but putting any of my systems into drain mode doesn't cause me any issues at all with applications or logins...

I would assume the Quest one is just as smart as it needs to be able to handle a Server thats gone offlne without being in Drain mode too...(ie, someone shutting down the server)

Hitting the same issue as you. Can you let me know what OS you're testing with?

Hmm, so my cunning plan isn't nearly as cunning as I hoped!  I'll do some testing here

No ,not according to my tests..  It would be interesting to hear about you results.

I'm running the tests on Windows Server 2008 R2 only.

// Alexander