Aloha - getting code to run on FOH from BOH

[posnut]

We want to do some maintenance tasks on FOH machines without actually going to FOH machines to run code. Is it possible, via config settings, to get the FOH client (Table Service) to run some EXE located on the BOH file share?

If not, does the FOH TS client happen to load any DLLs or run any EXEs from the BOH file share already? In which case, we could stub/replace those and use that as a chance to get "some code" running on those FOH PCs.

My current test setup only allows me to run FOH and BOH on the same PC, so I can't easily test this myself. FOH does load a ton of DLLs from the "bin" folder, but in my case that is also the BOH bin folder.

 

[ClayTaco]

Look into using winrs to open a remote cmd shell. From there you could run executables.
If you wanted the program to run regularly you could set up a task.

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.

 

[AlohaRoss]

Aloha maps a Z drive from FOH to BOH as part of Aloha. Take advantage of that. If you are using the Floor plan you can add a button to launch an application. as long as you have the application you want to launch along with any supporting files it should launch.

the path would be z:\bootdrv\Folder with your application

on boh add the folder and files to the shared bootdrv folder.

AlohaRoss

http://www.needaholahelp.com

3rd Party support

 

[posnut]

Thanks AlohaRoss. However, I do already use tsbuttons.cfg to add a button that runs my app from the shared drive. What I'm looking for now is a way to have it run without any interaction on the FOH system. I know I could install a service or something the first time they click the button... but I'd like something fully automated if possible, so that I don't have to require end-users to "do something" (even as simple as pressing a button) on each FOH terminal. Can be a hassle if a location has 20+ terminals.

 

[MenulinkMan]

If you want no user interaction, why not use the windows task scheduler to kick off the task at a specific time?

 

[AlohaRoss]

If you are using RAL, you could push a one time batch file to load your code, or leave it to load each time Aloha loads

AlohaRoss

http://www.needaholahelp.com

3rd Party support

 

[posnut]

@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:

http://www.tek-tips.com/viewthread.cfm?qid=1689293

-- 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.

 

[ClayTaco]

I'd love to see your piggyback solution when you get it working. That's not something I've tried before, but it could be handy in the future. Good luck!

 

[AlohaRoss]

Here is the script I have used to install a service

SchTasks /Create /RU username /RP userpassword /SC Hourly /TN killer /TR c:\speedup.bat /ST 09:00

hourly is when I want it to run
Killer is the name of the task
c:\speedup.bat is the name of the file to call
ST is when I want the first task to run.

After that this service runs every hour.
in this case speedup.bat was a batch file. I was having issues with NTVDM.exe taking over all cpu processes bring system to a crawl.
Speedup.bat was just taskkill /IM ntvdm.exe /f
At the top of each hour if ntvdm started it would be forced closed. Made a huge difference. Most of the Win7 machines I support started getting this issue around the same time as Win10 update came out KB3035833

Use RAL to install on next refresh and you are done. No other interaction would be needed. RAL installs the TASK and the task starts the program all with no user intervention


AlohaRoss

http://www.needaholahelp.com

3rd Party support