Launching script on startup regardless of login Win 2012 r2

[Warren]

Goal: Have compiled script launch, and include> additional scripts upon startup regardless of user login.

Problem: I have compiled exe shortcut in Startup folder, but vps sits there and does nothing after reboot until I connect via RDP client (Administrator login happens automatically upon connection). RDP client will disconnect automatically every time connection is lost (like during a reboot), so there is a built in issue where despite rebooting, machine will not run script until I manually intervene. Even if I could somehow get the RDP client to constantly try to reconnect, I have too many vps to connect to all simultaneously, so solution needs to be on the Windows server side allowing the script to run regardless of login.

Troubleshooting: I have tried running shell:Common Startup to make startup item universal. This appears to have no effect. I have been reading up about task scheduler and the "Run whether user is logged in or not" option, but this raises new questions:

1) Am I on the wrong track here? Is there no way to do this without using the Task Manager?

2) Some reading has revealed issues that pop up if the item being run via Task Scheduler with "Run whether user is logged in or not" checked is interactive in any way (like can pop up dialogs) It would seem that a MS script would fall under this category, no? I came across the following statement in a discussion about unattended excel automation:

"Whenever you run a thing unattended under "Run whether user is logged on or not" there is no user interface. Meaning that the app runs with a hidden desktop, we cannot do anything about it. For example, we cannot dismiss an error message, or do anything else."

I have already contacted my vps providers to see if there is some solution that constantly attempts to reconnect when disconnected on their end (thus logging back in if logged out.). This is looking like a dead end, though, so the solution needs to be on the end of getting the script to launch regardless.

Hopefully I am overthinking this, and there is a simple best practice that allows me to run a script automatically upon startup regardless of login.

[Marcus Tettmar]

I'm afraid this is all down to how RDP works, and how it is designed to work. Microsoft, (in their infinite wisdom ) made RDP so that when you close it the session is logged out. Even when you simply minimize RDP the remote session is locked. Just starting your server does NOT log it in. Just as if you power on your local server it will sit waiting at the log on prompt - until you type the password it will do nothing - equally with a remote server you need to connect to RDP to log in but then the issue is it will log out when you close the RDP client. Only once you've connected via RDP will it log in. Macro Scheduler requires a user console to automate a UI and a UI does not exist until a session is connected - until Windows is logged in.

See:
http://help.mjtnet.com/article/30-why-d ... es-session

There was a way to make RDP *not* disconnect when you close it, but leave it sat at the desktop:
https://arstechnica.com/civis/viewtopic.php?t=342574

I can't vouch for whether this still works or not - I wouldn't be surprised if Microsoft "plugged" this a long time ago.

What people usually do to get around this is simply ditch Remote Desktop and use a different product such as VMWare/VSphere instead, or some version of VNC. However, you may be at the mercy of your provider if you are using a cloud service and may need them to do something their end at the physical server to make this possible.

[Warren]

Wow. So this may even be a much bigger issue than I thought. It never occurred to me that my scripts would stop working just because I disconnected the client.

I'm using Royal TSX as my connection client. It's a plugin based system, so I'm currently using the RDP plugin, but I believe I could switch over and use VNC (which is also supported by provider).

Will read up, and see about switching over, but assuming I can get it rewired for VNC, are all of these issues then resolved, or some remain?

EDIT: Apparently, switching to VNC is possilbe, but a major undertaking as there appears to be no mechanism to convert the existing connection profiles. It looks like I would have to manually recreate every single connection profile and all of it's settings. That alone is at least an entire day of work, so can you think of anything else I should know or look into before banging my head against that wall?

In the meantime, I'll try setting up a test connection for one of the vps using the vnc plugin.

[Marcus Tettmar]

I believe the VMWare Remote client leaves the user console logged on if you just close it, only disconnecting if you tell it. This is how it works on a client site anyway. Last time I used VNC it had an option to not log out the user when you disconnected.

[Marcus Tettmar]

Try this disconnect script from an RDP session before you try anything else:
https://arstechnica.com/civis/viewtopic.php?t=342574

Create a shortcut to that command line and run that instead of closing RDP. It should close RDP without logging out the user.

One way to test it is to make a simple macro like this:

Wait>5
Run>notepad.exe
WaitWindowOpen>Untitled - Notepad
Wait>0.5
Send>Hello World

Run that and immediately disconnect. Wait 10 seconds and then log back in again.

If the user session is logged out no text will get sent to the Notepad window and Notepad won't generate a UI until you log back in. So when you log in again you should see an empty notepad window.

If you have been successful in closing RDP without it logging out the user then the script should work.

Please understand this is all down to how Windows works. Windows does not create any user interface elements - not even windows - when it is locked or logged out. And you can't automate something that doesn't exist. Windows and other objects don't get created until you log back in again - EVEN IF the app is running. RDP is an extension of Windows and mimics being in front of a real console. So until you log in THERE IS NO CONSOLE and when you close it you are LOGGING OUT. So without an active RDP session THERE IS NO USER INTERFACE.

So before going down the route of using an alternative remote technology try the script in the link above. If it works it will chuck you out of RDP without logging out the user session.

[Warren]

I can try that tomorrow... though I'm still not clear if it would solve all the issues even if it does work. Even if I can keep connection once active, I still have the startup issue, no?

I converted a couple connections from RDP to VNC as a test, and all I can say is "wow." I forgot just how laggy and awful every VNC connection I had ever used was in comparison. I've been firing up 100 RDP connections at a time, and every one of them is much higher resolution, and much snappier than a single VNC connection. The software I am using allows for none of the display customization, etc in VNC that it does with RDP. Not sure if that is protocol limitation or not.

Anyway, in the interest of making sure I pick the right path, I should mention that while I am not married to Royal TS(x) (my remote connection client), it does provide plugins for RDP, VNC, TeamViewer, VMware, and a few others. Any reason I should be looking into anything outside of RDP or VNC from a running MS scripts in the absence of logins perspective? Perhaps even some completely other kind of unattended access software?

For instance, there seem to be two issues. One is launching the script on startup as opposed to login, and the other is having the script persist despite connection interruptions, right? I came across the following today which seems like it might be on the right track?

AeroAdmin can be run in OS user-free space (before user login) so that you can reboot the remote computer and still have the ability to access it remotely.

[Marcus Tettmar]

To be honest I'm not sure I can help with any of that, as it's outside my realm of experience. I know that VNC is slow. I think VMWare would be a better solution.

[Warren]

OK.

Your feedback has been tremendously helpful. I know it's a lot of questions, and some of them are only indirectly related to running MS, but ultimately getting it right boils down to the scripts working as intended or not.

I'm getting as much feedback as I can from my provider, but ultimately, this stuff sits halfway between your world and theirs, so I've started just trying different systems to see how they work. MS aside, I've been very happy with RDP.

Yesterday, I tried 3 VNC clients (slow and laggy even with few machines), and contacted a half dozen other types of unattended access software companies. I'm just going to buckle down for the next couple days and try everything I can find to see what provides the best solution. I'll post some findings here when finished in case it helps someone similarly trying to find a better than VNC solution for allowing scripts to run on remote or virtual machines despite connection.

[JRL]

Perhaps I'm missing something?

Why don't you RDP in when you want to work on a system. That way your lag and resolution are good. Then when you finish up, VNC to the same system, log in to the desktop and close the VNC session leaving the desktop unlocked and ready for the scheduled executable to do it's thing. You could probably write a script to do all this logging in and out for you.

[Marcus Tettmar]

But also, you still haven't said whether you've tried the simple little disconnect script I sent a link to twice now. That could be all you need. So I just tried it myself on an Amazon Windows Server 2012 instance and it works.

Here's another link which also talks about this method, with some additional detail:
https://superuser.com/questions/355935/ ... al-console

Here's what I did to test it.

1. I opened a command prompt as admin and typed:
qwinsta

This showed me that session 2 is the one I was connected with. So I then wrote:
%windir%\System32\tscon.exe 2 /dest:console

My RDP session then disconnected.

2. I reconnected with RDP and created this test macro in Macro Scheduler:

Wait>10
Run>Notepad.exe
WaitWindowOpen>Untitled - Notepad
Wait>0.5
Send>Hello World

3. I saved and closed this macro and then RAN it.

4. Quickly, before the 10 seconds was up, I switched to the admin command prompt and reran (by pressing up arrow so I didn't have to rewrite it):
%windir%\System32\tscon.exe 2 /dest:console

5. I then waited for my RDP window to close and then sat and waited about 15 seconds to be sure.

6. I logged back in with RDP.

7. On my desktop I could see Notepad open with the text "Hello World" in it.

This proves that the user console was not logged out or locked - if it was Macro Scheduler would not have been able to send that text to Notepad.

So this should be all you need to do. Create a batch file for this disconnect command. Make a shortcut to it on the desktop and give it admin privileges in the shortcut options. Then when you disconnect from RDP in future, instead of closing RDP as you would normally, run this batch file via the shortcut. RDP will close but the remote console will stay active, meaining a UI will exist that can be automated.

Please try this test before spending any more time back and forth looking at other technology!

[Warren]

OK. I definitely appreciate the brainpower.

I may be wrong, but my concern was that while that may work in cases where the machine is already running and connected, and I control whether I disconnect normally or by executing the command...

... that there are a great many times where I do not have that level of control including:

1) Machine shuts down and does not automatically reboot due to system maintenance or other failure on provider's end (happens at least every other day, and automatically disconnects RDP along with it. Currently, it's just wasted time until I send manual boot command and reconnect RDP)

2) RDP disconnects automatically due to temporary connection issue (I have vps spread out in datacenters all over the world to hedge against simultaneous systemic failure, and this happens literally dozens of times a day)

3) Due to a number of factors, script when functioning correctly instructs each machine to reboot multiple times daily. Back to the issue of being disconnected until RDP is manually reinstated.

4) Human or other error. If either I accidentally click on the machine name in my client causing it to disconnect, or some function of the client sends a command to disconnect it without my being aware, then RDP will be disconnected, and command not executed.

5) Normal functioning of the client app. App automatically disconnects all rdp sessions upon close, or if the laptop battery dies, or a host of other circumstances. This could be avoided by manually closing each session via command as I go, but this negates the purpose of having the client app in the first place since that would mean they are disconnected from RDP client, and I can no longer open and close them all with a single command, have an visual overview of hundreds of machines at a time, etc.




Anyway, those were my concerns. Perhaps there is a way rather than setting it up as a user clickable shortcut to instead launch it on startup via task scheduler and have it persist even if the RDP session disconnects disconnect remotely or takeover with the RDP disconnect as a trigger. I guess something like that could work, but as described, I'm seeing the above issues which is why I've been looking into unattended access solutions that are designed from inception to fix these exact problems. Anything that is error or failure prone in any way will only become a much larger problem as I triple the number of machines over the next few months.

So far, I've had disappointing results since nothing is as tidy an interface as Royal TS(x) with large numbers of remote computers organized in a single embedded window with a visual overview. Still waiting for word from my provider about whether VMWare interface might work.

If the above issues are things that can be overcome allowing full error-free unattended access regardless of login (or logging me in automatically without manual reconnect) but allowing me to use existing RDP client interface as described, then yes, I should be digging into that instead.

[Marcus Tettmar]

Wouldn't most of those things apply whatever technology you use and even if not a remote machine? If any server reboots due to an error youd still need to log it in to ensure a user session no?

[Warren]

Some claim to log you back in automatically and/or reboot/reconnect upon disconnect. Details differ beyond that point.

I'm already in the midst of testing 3 purpose built solutions whose devs responded to queries I sent yesterday (including one that is designed to also remotely monitor other items like high ram or cpu usage across thousands of machines).

Call it paranoia, but I already went through all this once a couple years back before picking Royal TS(x) with RDP plugin which was the best solution for my needs at the time. Since I know I'm going to grow the network significantly soon, it's much less work to take a day or two now finding the right solution to guarantee smooth MS functionality than it will be to have second thoughts or pitfalls for not handling all issues as fully as possible when the network is three times the size.

That being said, Yes, RDP fix could be the key and is definitely a consideration that will be looked at soon once I've finished evaluating the solutions I've already installed and can focus on it.

[Warren]

oops. dbl post.

[Warren]

I've had a family member in the hospital for the past week, so unable to use the workstation, but lots of time to read up, and run a few small scale tests.

Yes, looks like the RDP hack does allow persistent UI, bu the limitations of my RDP client end up causing problems (sessions often terminate without me choosing to terminate them, and there is no way to automatically reconnect upon either reboot or severed connection.

After quite a bit of research, I can see that I will likely move towards some form of RMM solftware to remotely monitor and manage a network. I've actually demo'd 8 different RMM suites for limited tests (not wired to control hundreds of machines), and Goverlan is looking to be in my likely future, but due to a list of features beyond the scope of this thread. It's got a list of mind bending features I had no idea were possible. Even beyond that, I can see that I will eventually want to move toward renting bare metal servers, and managing my own VM clusters from a central console that replaces the Solus panel, the remote access client, and provides monitoring, and software/script tracking/deployment.

Back to the present, though, the two issues relating to MS are the persistence of the UI, and the ability to run scripts on startup.

Royal TS dev got back to me with a string find/replace scheme that converts my corrent RDP client into a VNC client. It's not as elegant, but it will do for now, and the VNC client persists connections across restarts automatically, so I don't even need to click to regain the connection.

If it does disconnect, though, or the entire client crashes severing all connections or similar, I've found a little program called AutoLogon for Windows that encrypts and stores the admin password so it can automatically login upon startup. I've tried it on a few machines, and i'm not seeing any issues thus far. It is still pass protected, so I don't think it changes anything in terms of security, and the password is encrypted if someone did access the registry. (Auto login solution on Microsoft site involves unencrypted password stored in registry) Unless I'm missing something, it should not pose any new risks, but just behaves as if the session is attended by user from startup and allows the scripts to run within Admin user space.

So... while I can see a much more complex road ahead as the network grows, I think this problem is solved for now, and with a simple shortcut to script launcher exe in the startup folder. It may have worked as well to use the task scheduler to launch a script on startup regardless of login, but I'm not sure what sort of issues might have popped up trying to run the script in a user-free space (before login), and then connecting as a user while that script is running. Just sounds problematic, so I think autologon followed by auto script launch as admin while using connection protocol that auto-reconnects and doesn't disable UI upon disconnection sounds like a winner for now.