How to distribute a RES PowerFuse desktop via Microsoft RemoteApp

In this "How to" we use a Windows 2008 R2 (x64) server to explain how you can distribute/publish a RES PowerFuse 2008 desktop via RemoteApp.

Why would you use a RemoteApp for presenting a desktop when you can connect directly via RemoteDesktop(RDP) to the TerminalServer?
The main reason would be to offer load balancing via a Microsoft 2008 Server "Broker".

When configuring a RES PowerFuse 2008 desktop via RemoteApp using the RES PowerFuse Shell the desktop will appear as expected.

You simply have to add a RemoteApp and use the correct path to the Workspace Manager: pfwsmgr.exe

However, when using the RES PowerFuse Windows shell, only a file explorer will appear after launching the RES PowerFuse Desktop via RemoteApp:


This is what happens:
The pfwsmgr.exe is started and performs all configured logon tasks. Then explorer.exe is launched in shell mode in order to offer a desktop to the user. Actually, in general, it's not possible to start explorer.exe in shell mode explicitly. But if there is no running instance of explorer.exe, it will start in shell mode by default. Second instances will be started as file explorer. In this case, there is no instance running yet and explorer.exe should start in shell mode.

This is unwanted behavior in a RemoteApp as these are meant to run seamless on your (remote) desktop. When starting explorer.exe from a RemoteApp (i.e. when clicking an UNC path) you would like to have a File Explorer instead of (an extra) taskbar. This is understood by Windows and this results in a File Explorer instead of the expected Windows Shell. Starting explorer.exe as shell in a RemoteApp is not possible. The same behavior will occur when trying to present explorer.exe as an remote application to the user.

But it is possible to start a Remote Desktop as a RemoteApp:
This still does not solve our issue because in the Remote Desktop application properties, it is not possible to configure an "Initial program" meaning that RES PowerFuse can not be launched and you would still have an unconfigured desktop.

This is by design and easy to explain: Why would you run an application in Remote Desktop if you can use it in RemoteApp Directly!

Well... because we would like to run the RES PowerFuse Desktop using the RemoteApp functionality! Now we know why this does not work.. here's how we solve it!

Open mstsc.exe on the server running Remotte apps and on the tab programs fill in the path to pfwsmgr.exe. Fill in the correct FQDN/ip address and other configuration items. Save this RDP file.

Add this saved RDP file via Remotte app manager (you can browse directly to this file) and create a RDP file via the Remote apps Manager interface and, when needed publish it via the RD web Access interface.

Go to the RemotteApp manager-->Add RemoteApp Programs-->Browse to the location of the RDP file you just saved-->Choose open.

The saved RDP connection will look like this in the RemoteApp program:

When you start this RemoteApp you will get a RES PowerFuse Desktop and if configured you can use the Windows Shell.

By the way:
When using Windows 2008 Server you can setup a Remote Desktop Connection Broker (RD Connection Broker), formerly Terminal Services Session Broker (TS Session Broker). In this case, you do not have to start the RES PowerFuse desktop as a RemoteApp in order to have a broker with Load Balancing.

If you are using a Remote Desktop Broker, you can use a Remote Desktop and launch RES PowerFuse via a GPO: Go to User Configuration > Administrative Templates > System -> "Custom user interface", and fill in the correct path to pfwsmgr.exe.

Have fun!

Gerry de Bruijn
Paulina Adams

Troubleshooting RES Wisdom connections

When a RES Wisdom Agent appears to be offline in the RES Wisdom Management Console, while you are certain it is up and running, where do you begin troubleshooting?

A RES Wisdom Agent appears online in the RES Wisdom Management Console after succesfully discovering one or more Dispatchers and registering itself and logging on to the database. Since the Agent cannot communicate with the database directly, the ability to discover Dispatchers is crucial because they set up the connection to the database.




Dispatcher discovery can be done through Autodetect, a Dispatcher Address List or a combination of both. If you use Autodetect your network switches must support Multicast otherwise it will not work. The following troubleshooting actions can be performed in either discovery method.



To begin with, it couldn't hurt checking your network connectivity, so start by pinging your Dispatcher(s). If you are using a Dispatcher Address List instead of Autodetect, you should ping to the same name you are using in the Dispatcher Address List to avoid missing name resolution problems. For example, if you are using a NetBIOS name or FQDN in the Dispatcher Address List but you happen to know the IP address of the Dispatcher by heart, you shouldn't use the IP adress in the test because then you already resolved the name to an IP address and won't notice it if the Agent is not able to do so.

RES Wisdom Agents communicate with Dispatchers using port 3163 TCP so the next step is to check whether this comunication channel is open. This can be done rather easily by opening a command prompt on the Agent and typing the following command followed by enter: 'telnet DISPATCHER 3163', where DISPATCHER is the name of the Dispatcher according to the Dispatcher Address List. This test should return an empty Command Prompt window displaying nothing but a blinking cursor.

If this test is succesful the communication path between the Agent and the Dispatcher is in working order. If this test fails either the Dispatcher service is not running properly or there is something blocking the comunication. Restart the Dispatcher service and/or check for firewalls that block traffic to this port.

Next step is to check the Dispatcher Discovery process. For this process it is necessary to distinguish between the settings the Agent should have got (Global Settings), the settings the Agent received earlier (Agent Settings) and the settings the Agent is actually using (Agent registry) to try and find a Dispatcher.

The Global Settings can be found in the RES Wisdom Management Console and are the default settings for all Agents.

In the RES Wisdom Management Console it is possible to set custom settings on a per Agent basis so you should always check what settings the Agent has by double-clicking the Agent and view the Settings tab. Whenever an Agent is online it will check these settings regularly and overwrites its registry settings if necessary.

Whenever an Agent starts the Dispather Discovery process it uses the settings stored in the registry under HKEY_LOCAL_MACHINE\SOFTWARE\RES\Wisdom\AgentSo, at first an Agent needs to be able to connect to a Dispatcher with the settings stored in the registry. After connecting succesfully it will check whether its settings in the database have changed and overwrite the ones in the registry when needed. The Agent settings in the database can differ from the Global Settings.


With this in mind about 75% of the connection problems can be solved. For the remaining 25% we need to dig in a little deeper into the Dispatcher Discovery process but I will cover that in another blog article.


To be continued...