Automatic Scaling of Remote Desktop Session Hosts in Azure Virtual Machines

Looking at this script, it's a bit confusing on time zone. This script actually pulls the time from the local machine which is adjusted for the selected time zone, not UTC as the documentation suggests. Please correct this. 

2/12/2018 8:06:42 AM - [Info] Starting RDS Scale Optimization: Current Date Time is: 02/12/2018 08:06:42
2/12/2018 8:06:42 AM - [Error] Failed to retrieve RDS collections: The specified FQDN  is not valid.

Please suggest.

You must use a domain account with permissions to manage the RDS Farm. 

This Script put all servers in drain mode and shutdown one by one. Could you change this please? Or send me what I need to change?

Is it possible to upgrade the script with an exclusion variable for a collection? Currently the script runs against all collections, i would like to provide the names of the collections that need to be scaled.

the same with the hosts, would be nice if we can mark a server within the collection as 'excluded' within the count.

We noticed some strange behaviour. The script sometimes sets all availabe servers in drain mode and starts trurning servers off until only 4 (our setting) are kept running. But those server will stay in drain mode.

Anyone know how the logic works of this script. For example we have 11 session host servers. I told it to leave 3 servers on during off peak hours. I went to server 1 saw someone was logged on, put server to drain, then asked them to log off. Which the user did. They then logged into another server. The script then went to that server and told them to log off yet again. 

I would have expected the script to enumerate which 3 servers have the most load, set the other to drain. Then proceed to the servers with the least logged in users. then ask them to log off. This way they would get put back on to a server which will stay on?

At the moment it just goes through each server in turn turning them off 1 by 1. Until it leaves the last 3 on......

This crashes on line 329 in an Azure ARM environment.
>>$Deployment=Get-AzureDeployment -ServiceName $CloudServiceName -ErrorAction Stop

As far as I can see there is no ARM equivalent of the Get-AzureDeployment cmdlet. Does anyone have an alternative? Cheers!

Blair,

Have you tried get-azurermresourcegroupdeployment? I think that's the cmdlet

It appears based on many of the comments that these scripts were written for the ASM sutf. I'm unclear if Clark is still with Microsoft or "maintaining" these scripts, has anyone updated this to ARM?

I have the same issue as Marcus, I tested this script tonight and it left the last server standing in drain mode.  Good thing I checked or there would have been trouble in the morning.

Ideally, it would put servers in drain mode based on who has the fewest connections as another poster suggested until the MinimumNumberOfRDSH is reached, but not put the last server in drain mode!  Anybody figure out how to fix that yet?

As a temporary measure I just disabled putting servers in drain mode by changing line 603 from <-NewConnectionAllowed NotUntilReboot> to <-NewConnectionAllowed Yes>

Set-RDSessionHost -SessionHost $sessionHost.SessionHost -NewConnectionAllowed Yes -ConnectionBroker $ConnectionBrokerFQDN -ErrorAction Stop

I'd still love to hear if anybody was able to address that issue :-)

A little more intelligence would be good when shutting down servers in off-peak periods i.e. leave servers running that have the most "active" sessions.  At the moment it is quite intrusive as we shut down servers that may have active sessions and leave servers running that have none !

We have a cluster of 6 nodes and it takes about 20 minutes to shut down them due to the log off wait time incurred as each one is processed

Would be useful if all servers were processed together,
i.e. put all servers into drain mode together, send them all a warning about shutdown, wait for specified period then shut down.

At the moment, the user gets disconnected so waits 2 minutes (they are told to do this) logs in again only to find that server starts shutting down too.  The end-user gets frustrated therefore can we do something more scalable?

Thanks