Launching local apps (App Launcher)

 Table of Contents

• Introduction
• Requirements
• Installation
• Instruction file
  • id
  • target
  • args
• Additional info

Introduction

It's possible to launch local applications from your Workspace using the Workspace 365 App Launcher. The App Launcher enables more convenient configuration and management of local applications for admins. This also simplifies the deployment by the created MSI and allows you to set parameters on these applications. Consequently, users can easily start local apps from their Workspace.

In "Launching Local applications" we've described how you can launch local applications with some Windows Registry edits. We make use of the URI handlers within the OS. For the Workspace 365 App Launcher, we make use of the same protocol. But for admin it's much easier to create and deploy these instructions to launch local applications including parameters.

Back to top

Requirements

The Workspace 365 App Launcher consists of two files;

• Workspace 365 App Launcher.msi
• Intructions.xml

The Workspace 365 App Launcher.msi including the Instructions.xml must be deployed on the target client(s). For the Windows App Launcher you need an Windows OS. You can configure the instructions file for the desired applications.

Back to top

Installation

The Workspace 365 App Launcher is an .msi file which comes together with the instruction file. The .msi is handling the commands given from the Workspace. Make sure that this file and the instruction file is running and available on all clients.

The install path of the client is:

"C:\Program Files (x86)\Workspace 365 App Launcher"

The .msi can be installed silently. You can deploy this via e.g. Intune or any other app deployment application which you are using. 

Back to top

Instruction file

The instruction file is the file where you configure the local application and optional parameters.

The instruction file is written in xml. Each instruction has an "id" and a "target" ("args" are optional).

<?xml version="1.0" encoding="utf-8" ?>
<Instructions>
 <Instruction id="b9faf4fa-c260-423c-8713-1ceff5870c1f" target="%windir%\system32\calc.exe" />
 <Instruction id="6060d3d9-e01f-4caa-b2ac-891c3efd3f14" target="%ProgramFiles%\Microsoft Office\Office11\Excel.exe" />
 <Instruction id="2e1f829a-fa00-4456-909e-4f7759c718c2" target="%windir%\Explorer.exe" args="/root,&quot;%UserProfile%&quot;" />
</Instructions>

id

The Instruction id is the link to the Workspace. In the Workspace you can add a new app type: Local app.

When adding the new app type, you can fill in the Instruction id.

This instruction id is the GUID configured in the instruction file. This can be a custom GUID. You can create one yourself from e.g. https://www.guidgenerator.com/online-guid-generator.aspx

target

The target field is the field where you determine which target you want to start. We can run everything that you can run from the known "Windows Run" as well e.g. https://www.maketecheasier.com/20-run-commands-windows/. This can be as well custom targets to own Line of Business(LOB) applications.

You can configure Excel the following way:

<Instruction id="6060d3d9-e01f-4caa-b2ac-891c3efd3f14" target="%ProgramFiles%\Microsoft Office\Office11\Excel.exe" />

This way you will start the local Excel from the Program files path. If this file is not present, nothing will happen.

args

We can even add arguments/parameters to the targets we're configuring. For example, if you would like to start Windows Explorer with a certain folder/mapping we can do the following:

<Instruction id="2e1f829a-fa00-4456-909e-4f7759c718c2" target="%windir%\Explorer.exe" args="/root,&quot;C:\Workspace 365 Support&quot;" />

This will start Windows Explorer with the C:\Workspace 365 Support folder.

Please note that you need to precisely configure the arguments. As you see in the example above, we need to place quotes because the path contains spaces. But we only support xml encoded args.

"C:\Workspace 365 Support" 

Will become;

"C:\Workspace 365 Support"

Back to top

Additional info

The process we run is x86. When using a system variable like "%ProgramFiles%", for x86 processes it will point to the "Program Files (x86)" path while if you open it in windows explorer on an x64 OS it will open the "Program Files" folder. I.e. it might work if you copy the file path in windows explorer, but not if you launch it through the launcher. In this scenario "%ProgramW6432%" should be used.

Sysnative is a virtual folder, a special alias, that can be used to access the 64-bit System32 folder from a 32-bit application or script. For example, if you want to specify the target folder from a 32-bit application such as Snipping tool, the target would be:

<Instruction id="53ccf473-4c3d-56cd-1020-cd96693c563k" target="C:\Windows\Sysnative\SnippingTool.exe" />

If you need to do any troubleshooting because you will receive an error:

You can click  "open logs folder" or navigate to

"AppData\Roaming\Workspace 365 App Launcher\logs"

06-01-2020 12:00 CET - Since version of Google Chrome (77.0.3865.90), you will get a pop-up notification every time you want to launch a local app. This is due to changes made in Google Chrome.  We can prevent this by adding the w365-launcher url to the URLWhitelist of Chrome by adding this reg file on the local client;

Google Chrome

Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Google\Chrome\URLWhitelist]
"1"="w365-launch:*"

Microsoft Edge

Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Edge\URLAllowlist]
"1"="w365-launch:*"

We're looking into ways to add it by default in the installer.

Common issue - Snipping tool

// if the build platform of this app is x86 use C:\windows\sysnative
if(!Environment.Is64BitProcess) 
   System.Diagnostics.Process.Start("C:\Windows\sysnative\SnippingTool.exe");
else
   System.Diagnostics.Process.Start("C:\Windows\system32\SnippingTool.exe");

The problem is in your build platform (x86) and the automatic redirection of the folder C:\Windows\System32\ on 64-bit OS'es.

Basically, for several reasons, in vista/windows 7 64-bit OS'es when a 32 bit application try to access to C:\Windows\System32\ it is automatically redirected to the folder called C:\Windows\SysWOW64\. Hence, you cannot start snippingtool.exe because it is not present in that folder.

The only way is to use C:\Windows\sysnative\ and bypass the redirection.

Back to top