Feature Request - Start VM On Connect - Startup Related Servers

We appreciate your feature request—community input is essential to our ongoing development.

Next steps:
     • We will review your suggestion and update its status during the evaluation process.
     • If further clarification is needed, we'll contact you via comments.

We also encourage others to contribute through feedback and voting.

Lonnie Thibodeaux I love the idea of this, but unfortunately this simply isn't currently possible.  With “Start on Connect” the start of the AVD host takes place immediately directly in Azure as this is a native Azure function.  This is not a Nerdio task that takes place, so the visibility on the Nerdio-side of this is not present.   Nerdio simply wouldn't have a chance to get critical server VMs started (Domain controllers) for authentication as the AVD host VM start would kick off before Nerdio could catch the AVD host VM status to trigger a start of the server VM.   Hoping this helps clarify the “hurdle” with this, but please let me know if you have any questions. Thank you!

Hi Chuck Mikuzis 

I appreciate your feedback.
I guess I muddied the idea when I included ‘domain controller'. I can understand where that should be up before starting the AVD host…and they would be, as most DCs would be on 24/7. More focused on starting related file / app servers. So does that change your feedback? 

So if it can't be done via a Scripted Action or Azure Runbook in conjunction with ‘Start on Connect’…can I: 
* Leave the script in Scripted Actions or Azure Runbooks and access it from inside the AVD VM…or
* if I was to define the script locally or setup thru Group Policy in the AVD Host Startup script area of a GPO, and the script executes on the AVD VM at startup, would that script be able to read the Inherited Vars?
I hope that makes sense.

Thanks for you feedback
Lonnie

I think I know where your mind is at, Lonnie. I tried going down the same path a few years back.
Like Chuck mentioned, because “Start VM on Connect” is native Azure functionality, we're unable to inject any automations if something else is starting the VM.

You could work around it, like you said, with "Pre-Staging the Host(s), by using an Azure Runbook scripted action with a “VM is Started” task so it could start other Azure VMs. However, you'll likely run into a “Chicken vs Egg” scenario where the Host Pool will start and that will trigger the other VMs to start, but the Host will likely be running before the other VMs. Obviously, you could script a reboot of the Host after the VMs are up, but that could cause some delays with the uses being able to login.

I think it'll ultimately come down to the user experience and what they consider to be “acceptable” vs “a hinderance” 🤔
 

So if I am understanding it correctly, because the first session host in the pool starts with “start on connect” instead of auto-scale, none of the Nerdio automation gets to play, correct?   We don't use a lot of tasks in the “Started” section, vs “Created”, so I believe this is why we never ran into this on our un-reserved pool scenarios.   Interesting, and good to know.   Would it be worth a tooltip in the VM Deployment window when setting those scripts, warning that “on Started” scripted actions don't apply when “Start on Connect” executes the start, or these only apply when Auto-Scale starts the VM?

I wish I had spotted this sooner.   I have several prospects that have had a strong desire to be very ‘frugal’ and we bounced around a few of these ideas.  These prospects are ones who start out, looking for RDS-esque hosting of a particular application that they use infrequently (an hour or two a day, a couple times a week).   Not significant enough for full time  hosting, and therefore “pay for what you use” in public cloud is a good fit.  Ultimately we landed on a middle of the road approach - nothing reserved, start on connect enabled, and a scheduled start/stop of the related application servers.    The application servers run during defined windows, say - business hours.   But we could get cheaper in this theory:

In our case, we landed on the theory that if we needed to push costs down further, we would explore putting a script in to run on startup (on the os of the session host) that carefully triggers an azure runbook via managed identity, to start the application server VM in azure.   It waits for it to return a running status before putting a messagebox on the screen for the user saying the application server is ready to go.    And we leave the scheduled stop in place for the app servers, Auto-scale to bring down the session host when no longer in use.  We could probably do the same thing in reverse, a logout script of sorts that then deallocates the app server.

We do something similar in an internal pool used for sales demo's, but haven't reached a point where we felt the need to shave the cost down that little bit further.   That said, in all my spare time, this would be a fun little exercise, just how finely could a pool be tuned to minimize costs.   Other than disk costs, refine this theory out and there could be a solution that could be awful close to “AVD and some IaaS by the Hour".   If Nerdio could orchestrate that configuration, now we would -really- be talking. 

It is worth noting that current capacity constraints in some regions on the cheaper VM sku's, could hamper this even further.  One would need to build some type of ‘intelligent capacity extender’ type logic, into the azure runbook.

Ok, I apologize for being noisy, but I had another idea.   It isn't necessarily in Nerdio (though could be a feature request?)

An azure runbook that checks for a state other than ‘deallocated/stopped/failed’ session hosts, and if a running session host is found, checks related app servers state.  If found to be also not running, start said application server.  Runbook could be scheduled at appropriate intervals, since it is simple, could run every few minutes, 5 or 10 at most?

It isn't fool-proof to have the app server online by the time the user connects, but provided the application services themselves don't take abnormally long times to start, could do just the trick.

If this holds water, could this be a way for Nerdio to achieve the same result?     Could also be done in reverse, if no session hosts are running, deallocate the application server. 

Seems much cleaner than what I wrote previously, and another method for Nerdio to add value to NMM.