In a separate upcoming post I will document our trials and security tribulations with Horizon Software and their Village Merchant Point of Sale system (i.e. cash registers with additional functionality).  Village Merchant is a SQL-based, 32-bit and, by the looks of the UI, a legacy Visual Basic app.

The two problems that I had to solve were:

1. Installing legacy software on a shared-user Terminal/Remote App server.
2. Running a RemoteApp executable from a remote (non-local) file share.

Solving Problem #1

To install, we had to go-back-in-time to something I had tried years ago and had forgotten.
“Use the CHANGE USER Command to Switch to Install Mode in Windows 2000 Terminal Services”.  Ironically, this commands lives on today.  Screenshots courtesy of this Microsoft blog page.

Switch Terminal Services to Install Mode

1. Launch an elevated command prompt
2. At the command prompt, type

   change user /install

3. Press ENTER. The following message appears:

   User session is ready to install applications.

4. Type exit, and then press ENTER.
5. You are now in Change User Mode so go install programs or change settings that you want to propagate to all users.  Add or remove the programs that you want.

Switch Terminal Services to Execute Mode

1. Again, launch an elevated command prompt
2. At the command prompt, type

   change user /execute

3. Press ENTER. The following message appears:

   User session is ready to execute applications.

4. Type exit, and then press ENTER.
5. You are now in Change User Mode so go install programs or change settings that you want to propagate to all users.  Add or remove the programs that you want.

That solved problem #1.  All users could manually launch the application.  And by “manually” I mean you had to launch the “MERCHANT.EXE” from the remote file share on the Horizon server from the full desktop UI.

Solving Problem #2

Again, the “MERCHANT.EXE” executable resides on another server and is accessed via SMB file share using the full UNC path.  E.g. \\<FQDN server name>\<shared name>\merchant.exe.

The problem is that in Windows Server 2012 R2, remote or non-local applications cannot be published by RemoteApps.  This challenge led me to this post at SpiceWorks on using a locally saved batch file to launch the remote executable.  Brilliant.

I created a local batch file (e.g. C:\<folder>\remoteapp.bat) all users could access and it contained one simple line:

@echo off
echo.
echo.
echo Launch Horizoning, please wait up to 10 seconds. . . .
echo.
echo.
PING -n 7 127.0.0.1 >nul
start "" "\\<FQDN server name>\<shared name>\merchant.exe" /MAX

The start command dates back to the OS/2 and 16-bit Windows days.  It launches an application from a command prompt; simple enough.  See here if you if you want to get fancy on window sizing, processor priority, etc.  The “ping” command resolved issues where Horizon would launch but not accept keyboard/mouse input.

When adding the remoteapp.bat batch file on the RemoteApp server, I also used the full UNC path; e.g. \\<RemoteApp server FQDN>\<folder>\remoteapp.bat (even though its a local batch file, if you ever add additional RemoteApp servers for your Collection, they will know where to locate the batch file).  Enjoy launching remote applications using RemoteApp.