Automatic Scaling of Remote Desktop Session Hosts in Azure Virtual Machines

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

Hello,

Been running this script and have a potential issue. It seems that the script sets all session hosts servers to drain until after reboot. This means that for the servers that don't shut down over night new connections aren't ever allowed.

I've had a good look through the script and can't see where they are re-enabled or any servers are excluded from being drained.

Thanks,

Marcus

Hello Marcus
We too get something odd happening on occasion.
It seems from the logs that it does the following:-

1) Puts the server into drain mode
2) Inform users to log off
3) Log users off
4) check if there are no users logged in and then shutdown server
5) shut down and decrement running servers by 1
6) repeat

The problem is with step 4 (line 681) if for any reason all users are not logged off then the server remains in drain mode but the number of running servers does not decrement by one therefore continues to shut all the servers down leaving the gateway with no servers left to service requests!

I am going to remove the check and force the server to shutdown anyhow 
i.e. comment lines 681, 682 and 711