Launching script on startup regardless of login Win 2012 r2

[Warren]

Tried again today doing this both with RDP signoff procedure or with VNC, an having issues with both. I may just be having a dyslexic moment, but...

Not quite claear if autologon by itself fixes the problem since it does create logged in user (and therefore UI?) without RDP connection.

Or is it that it doesn't matter because once RDP makes connection, it takes over that session, and forces logout.

If so, would multiple admin accounts solve this?

EDIT: Did a bunch of digging and found this discussion of running a second dummy rdp session on server editions. Could something like this be done?

[Marcus Tettmar]

I think - and I need to make it clear this is not my domain at all - there is a very big difference between a remote session and a local session. I think AutoLogon will create a session which you can only see locally - i.e. literally by being sat in front of the physical machine with a monitor hooked up to it. Connecting via RDP will create a different session. Same user, different sessions.

[Warren]

Assuming that's true, that creates a conflict for starting the script in autologin session, then connecting to view? So script would be running in wrong session?

I do know this: I've put an exe in the startup folder, then used autologin and told it to restart. After waiting and then reconnecting via RDP, I can see the MessageModal that resulted from the execution of the script. That script didn't require UI interaction, though. Is there a different test I should use that requires persistent UI elements or something else that highlights the potential isssue? Same test like for disconnect hack described earlier?

All I really care about is that it can launch the apps, and click the browser buttons in my absence. I could be wrong, but it appears I can do that prior to connecting. If I can do that much, then any other details may be moot. Also worth noting that imacros chrome extension has no problem pressing buttons within browser after rdp disconnect, and sesion has clearly persisted in my absense, so just for clarity... that's because it didn't need UI elements specifically? It's always just worked.

Anyway, with the autologin, I think it's more the issue of what happens after I disconnect from RDP... which is why I posted that link. It appears to be a solution other UI based script dev used by forcing a second dummy RDP connection (on Windows Server editions) to therefore never force user logoff since the dummy connection never disconnects, so lock is never triggered.

I think I follow that much. It's specifically your side of things, or how the scripting protocol interacts with it that's over my head.

[Marcus Tettmar]

Not sure what you mean by "your side of things" or "scripting protocol". It's simple. To automate a UI the UI needs to be there. a UI is only there when a user session is active. Not logged out. Not locked. Active.

To verify whether that's the case after your AutoLogon create a simple test script like this:

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

Have that set to run on startup instead of your MessageModal. Test your reboot procedure or whatever you need to do to make the autologon work without you being remoted in. Wait a minute or so and then connect via RDP.

If you see the Notepad window open with the text "Hello World" in it then it worked - the UI must have been active.

But you may just see Notepad open with nothing in it. In which case there was no console when the script ran. The Notepad window is generated by Windows AFTER You connect. While the script can RUN Notepad, Windows won't create a UI for it unless a user is logged in and active.

This isn't "our end of things". This is how Windows works. This is how Microsoft designed Windows to work. We, nor any of our competitors, can provide a solution to automate a UI that doesn't exist or there's no input console present. And Windows has made sure a UI doesn't exist and there is no input console active when a user is not logged in (or is locked out).

[Warren]

Thx. I'll test this when I get a chance. That's not exactly what I meant, though. When I said "Your end of things" I was referring to the specifics of which session the script is running in vs sessions for the remote, the dummy RDP, etc. It appears to me that the dev in the link has provided a fix for the RDP issue for those using Windows server editions.

What I'm having trouble with is interpreting what exactly are his proprietary terms vs how that would play out with MS. For instance,

When automating user interface, **** needs to run in an interactive Window Station. To learn about Windows sessions, stations and desktops, check out these Microsoft articles:

Sessions, Desktops and Windows Stations
Remote Desktop Sessions

While Front Office Robots use the existing interactive session of the logged in user, in order for BackOffice Robots to run unattended, a Windows session is maintained by the ***** robot service running in the (non interactive) Session 0. The service requires Windows credentials to open an interactive session and to monitor it, reopening it if somehow gets disconnected.

So, unless I've missed it, you don't use terms like "Front Office Robot"or "Back Office Robot". Unless I'm missing some other whole layer of meaning, and "back office" essentially just means stuff that runs unattended, then it would seem that the fix to the entire RDP problem lies here:

Using FreeRdp to create a virtual Remote Desktop session that **** manages internally. On a Windows Workstation there can be only one RDP session, but on a Windows Server there can be many sessions for different users or even for the same user. On Windows Server and for multiple robot accounts per machine, loginToConsole should be set to false becaue the console session cannot be shared simultaneously by more robots.

This is what I was referring to. He says that the scripting protocol (wrong word? He refers specifically to his scripting product) manages the dummy RDP session. That's the part I'm asking about. It occurs to me that MS can likely do the same, but not sure what the bit looks like where MS "manages the virtual Remote Desktop session internally"

[Marcus Tettmar]

Macro Scheduler runs on the user's desktop. It has to in order to automate a UI. Trying hard not to repeat myself here I think I HAVE answered how Macro Scheduler works. It needs to run on a user console in order to automate the user's UI. So it runs inside a users profile, on the desktop. Not sure I can help with the link you mention - which appears to be a competitors product - though it appears he's linked to Microsoft to provide additional clarification on the terminology. As for how competitors describe their product, or scripting language, or script engine, or whatever other terms they use you'd need to ask them.

[Warren]

VNC proving very buggy, so DAYS of RDP testing later:

Hundreds if not thousands of permutations on the technique of keeping a second (dummy to localhost) connection active have failed. Lockout still occurs. Only 2 references I could find anywhere to anyone working this out, and they're both vague on the details. Daisy-chain method (A connects to B connects to C) would work in theory, but creating MORE actual connections in my scenario seems ill advised.

For similar reasons, the tscon solution as presented fails in my case. With hundreds of connections to servers all over the globe, unintended disconnections are simply a fact of life. Fortunately, I see that the Task Scheduler has an option to trigger upon session disconnect.

Triggering tscon in this way (must use session 1 for 2012 server edition vs session 0 as most instructions reference) does appear to nearly instantly reconnect. I'm not entirely sure if the lockout actually occurs or not since technically, session rejoin is being triggered by the disconnect which precedes the lockout.

It appears to be working well, but brings up some MS questions:

1) Could this be done directly with MS (listen for disconnect event)?

2) If so, are there specific reasons why it would be better to do it with Task Scheduler or MS?

3) If TS is the way to go, should I just follow Microsoft instructions regarding burning and importing xml file, etc. or is there some more efficient way to script distribution (importing file to task scheduler) that I'm misssing? Trying to learn to use more system commands and avoid pressing buttons when possible as a rule.

Oh, and yes, the autologon ad described earlier does work as intended, so I can now confirm that scripts are running with UI both pre and post remote connection via RDP, and I can reconnect, drop connection, etc as often as I like and nothing breaks (so far).

[Warren]

Trying to copy to other machines was proving problematic due to TS forcing username read as computername/username. Since computername is different every time, it was causing issues. Since it's doing it for me without apparent ability to override manually or easy way to add wildcard. It was taking too much time to work out, so quicker to just script something to create task per machine. It's inelegant, and I'm sure I could do better if I dug into command line options for TS, etc. but it gets the job done.

It assumes 2012, thus the 2012 option and session 1 instead of session 0 for older machines. Also assumes ingle user (no need to specify session number, can just use session 1). Also note that you must enact for specific user. Selecting for all users won't allow reconnection. Not entirely sure why. Also note that the bit at the end is just authorizing the task with your admin password (needs to be switched in for yours), and that the authorization modal appears to be named "Task Scheduler"just like another open window already is, so there's probably a better way to manage that. This is just the quickest take that I could get to function:

Code: Select all

Run>control.exe schedtasks
WaitWindowOpen>Task Scheduler
SetFocus>Task Scheduler
MoveWindow>Task Scheduler,0,0
UIClick>Task Scheduler,Action
Wait>1
UIClick>Task Scheduler,Create Task...
WaitWindowOpen>Create Task
SetFocus>Create Task
UIClick>Create Task,Name:
Send>maintainSessionRDP
//Run whether user is logged on or not
Press Tab*3
Press Down
//Run with highest priveleges
Press Tab*2
Press Space
//Configure for Windows 2012r2
Press Tab*2
Press Up*2
UIClick>Task Scheduler,Triggers
//Triggers Tab
Press>Tab*4
Press Right
Wait>1

//SetFocus>Create Task
//UIClick>Create Task,{"New..."}
Press Tab
Press Enter
WaitWindowOpen>New Trigger
SetFocus>New Trigger
//On disconnect from user section
Wait>1
Press Down*7
Wait>1

//For specific (current) user
Press Tab*3
Press Down

//Press OK
Press Enter

//Actions Tab
SetFocus>Create Task
Press Shift
Press Tab*2
Release Shift
Press Right

//Press New...
Press Tab*2
Press Enter

WaitWindowOpen>New Action
SetFocus>New Action
Wait>1
Press Tab
Send>{"tscon.exe"}
Press Tab*2
Send>1 /dest:console
Press Enter
Wait>1

SetFocus>Create Task
Press Tab*3
Press Enter

Wait>3
UIFocus>Task Scheduler,Password:
Send>%yourPassword%
Press Enter
Wait>1

CloseWindow>Task Scheduler

There's a tiny visual glitch at the moment of reconnection, but otherwise I don't notice any issues. I expanded the test script given earlier to demonstrate persistence over time as you connect and disconnect. Here is my test:

Code: Select all

Run>Notepad.exe
WaitWindowOpen>Untitled - Notepad
Let>count=1
Repeat>count
  Wait>5
  Send>{(%count%*5)+" seconds"}
  Send>CR
  Let>count=count+1
Until>count,100

It just keeps counting and updates output in Notepad every 5 seconds. If you disconnect for 10 seconds or so and come back, if there is a gap in the numbrers, then UI disappeared. If it never misses a count (by 5's), then everything worked.

Everything seems at least roughly settled at this point between this and autologon plugin to start user UI session before RDP connection (on startup rather than connection). If it does turn out that this switch causes any glitches in scripts trying to execute at the moment of switch, then I'll revisit the dummy concurrent connection fix. Otherwise, it's looking solved, and I can use RDP again which seems downright luxurious in comparison to VNC.