MacroScheduler Usage in Data Center for Virtual Machines

[ClearPhoenix]

Hello everyone;

I'm looking for some suggestions on how to make use of MacroScheduler now that we are moving to a Virtual Server infrastructure.

I've been using MS for a few years now to automate various accounting processes that are basically just point and click operations, but take a lot of time waiting between processes, so not a good use of a persons valuable time, exactly what MS is for

Now we are moving to a data center, and MS cannot do auto logins so there goes macro scheduling.

I know and understand why MS doesn't work *through* an RDP session, however, it does work fine *on* an RDP session.
*through* being MS installed on local computer trying to do things to the windows presented in the RDP session window.
*on* being connected to a server via RDP and the MS software is actually installed on the remote machine.

I think I've come up with a dirty work around by having MS installed on a local computer, and it has a scheduled macro that just opens up an RDP session to my virtual machine on the data center, then that login on the VM actually has MS installed too, so now that there is an actual session that exists, macros can then run from there, and of course that log in opens MS as a start up task.

While looking around in the products section, (prompted by the September bonus upgrade email that was sent out) I see that there is the Remote Controller, but would that allow 1 install to tell another install to log in? I'm guessing that is a no as the remote install would have to be running to receive the request in the first place.

I guess the question here is, what kinds of things have other MS users done or tried to do in Virtual Environments?

[Marcus Tettmar]

Macro Scheduler's sole reason for existing is to automate UIs. To do that the UI has to be present. For a UI to be present Windows needs to be logged in and unlocked.

When you disconnect an RDP session, the remote session locks. That causes the UI to cease to exist. The automation would then fail.

Therefore many of our clients use VNC instead. RealVNC or UltraVNC. It can be set to NOT lock the session when it disconnects. Problem solved.

But another solution is just to put your regular old desktop in the data centre and have it set to never log out. No doubt what you are doing now except the desktop is in your office rather than in a data centre. Its location doesn't change how it works. There's little benefit in using a server when what you are actually doing is automating something designed for an end-user - you want a desktop environment and a regular old PC is therefore more than ample. However, using a server makes sense if you have dozens of such desktop automations as then there's a cost benefit in using one server; or if you are wanting to use virtual environments (though each virtual environment could just be a desktop OS).

If you want to automate your UIs, and presumably by now you have a strong business case for doing so (it's saving you a ton of time and money) then you need infrastructure that will allow you to leave the session logged in. You can't do your automation on a locked or logged out Windows profile. It's that simple. You need the tools for the job. Yet I still get people saying they want the benefits of automation but somehow expect it to work when Windows isn't logged in. You can't use a hammer to cut a tree in half.

But ..

1. Regarding automating *through* RDP - well you CAN but only visually - image recognition / sending mouse/keys etc. So you there will be some things you can't do with Macro Scheduler local to the thing you are automating.

2. Macro Scheduler does have AutoLogon but that won't work in a virtual environment.

[ClearPhoenix]

Hello Marcus;

Thank you very much for such a timely response, I must say the support for your product is amazing!

I completely understand that a session needs to exist for your software to function, as it operates against a UI, and in no way am I trying to get around that.

I understand the limitations regarding an RDP session with regards to this; thanks for the information regarding VNC, I may need to look deeper into that.

However, our virtual systems in the data center are on a shared service; our servers are VMs; and we cannot co-locate physical hardware there without additional cost. (although at least on a normal desktop there, the auto-logon features would work...)

I did try to run our software on a local machine which connects to our databases through our VPN, however the increase in process operation time made it impossible to use (it took almost 400% longer to run in that scenario).

What I did get working last night, and it seams to work alright actually, is this.

1) Install Macro Scheduler on a Windows 10 PC here in the office. (Sched A)
2) Install Macro Scheduler on the Windows Server 2008R2 Virtual Machine in the data center. (Sched B)

Sched A:
I created a single macro on this PC that opens an RDP session to the server.
This macro waits until the mstsc.exe process terminates.
After the RDP session closes, the macro locks/logs out the PC again.

Sched B:
On the server I created a macro that I added to the StartUp folder for the user, this macro copies over a folder from the TSclient C drive that is full of trigger files.
The various macros that exist on this server install do not have schedules, they all execute based on trigger files.

This way, Sched A initiates a log on, and when Sched B starts it pulls all the triggers over, thus the triggers initiate whichever macro was supposed to start.

It requires a double install, and an extra PC as a "middle man", but it's functional, and functional is all anyone really cares about lol

Thanks again for such a great product, and even greater support. Keep up the amazing work!