@ClayTaco - not sure I can count on winrs to always be configured to work. It could be an option if possible to configure, without major network changes, and at the server side only. In some cases, maybe a lot, wouldn't it require changes to each FOH terminal also? Like if they aren't currently setup as a domain, or maybe other issues. In my general Windows experience, any of the tools that allow you to "remotely run code" via admin options, usually don't work without extra setup on the client side, for security reasons. But that's only for general built-in stuff, not always for program specific config, like Aloha.
@AlohaRoss -- This is all the info I could find on RAL so far:
-- It seems like something that each FOH would have already been setup to use, and if not setup, would require changes on each FOH system to get working? If so, that breaks my requirement of not needing to "go to" (or remote control) each FOH system. I'll research this more, seems like a solid option if possible to configure at BOH only.
@MenulinkMan - Windows task scheduler would need to be configured at each FOH box, which breaks my requirement of not needing to go to each FOH terminal to do setup.
RE: @ClayTaco's "The FOH does run things off of the share but piggybacking off of the code is a really bad idea, not to mention its a lot more trouble than its worth." -- I think this might still be my best option, as it sounds like it might be the only way to not require any setup at the FOH and work under the widest range of setups. In the past when I've done this, it has been pretty robust as long as I target a DLL that is not likely to change the functions it exports, or the filename. As long as those 2 things don't change, and my stub just proxies everything to the real DLL, it should continue to work even if the code inside the DLL changes from one version to the next. A COM DLL, which Aloha has a lot of, is usually an ideal target, because they usually never export anything except the few required COM entry points. I'm still trying to get a setup with FOH and BOH separate so I can figure out which DLLs the FOH loads from the BOH (vs from local drive) in these setups. The main tricky part is that my stub DLL is likely to be overwritten by Aloha upgrades, but I have a service running on the BOH box already that can simply watch for that and put the stub back as needed. I also don't mind telling system admins to do some extra steps when upgrading, as long as everything is BOH and nothing done at FOH.
Edit: Almost forgot my manors.. THANKS! To everyone, some really valuable info here.
