Introduction
BlackBerry Workspaces is an Enterprise File Sync and Share solution (EFSS) that is used for secure file storage, synchronization and sharing, basically content collaboration with internal and external users. The most distinctive features of Workspaces is file level security through advanced digital rights management (DRM) that apply online and offline.
Scenario
I just had a customer that wants to run BlackBerry Workspaces plugin for Windows in a VDI environment. Coming from an extensive EUC background, I knew exactly what needs to be done for Workspaces in terms of prerequisites to be supported in a non-persistant VDI environment or even a pure RDS environment for that matter so on with the testing.
Challenge
Challenge number one is that Workspaces agent plugin does not install on server operating systems out of the box so if the plan was to publish it as a remote application (on RDSH servers not Windows 10 multi-OS which is only on Azure), the plan is ruined.
Challenge number two was that Workspaces agent plugin installs in user profile AppData and that does not work in VDI non-persistent environments (well there are workarounds but nothing supported or optimal).
Methodology
For any VDI environment, that being Citrix, VMware, Microsoft, Awingu, Frame or others, running non-persistent machines with profile management would require that applications installed on the base image be installed in Program Files or any other system folder except User Profile.
Any application installed in user profile will be bound to that user only on top of that it is going to roam with the (roaming) profile which is not optimal. We can just use SCCM, startup script, and/or other tools to push the App installation for every new user on logon to any VDI machine, which technically works but is not optimal, not supported, and performance wise will be a nightmare.
Publishing an application remotely requires it be installed on a remote desktop services session host server that being Server 2016 or Server 2019. Well if your using Windows Virtual Desktops with Windows 10 Enterprise Multi-Session OS then yes it works fine but that is bound to Azure for now.
Workspaces agent plugin does not install on an Server OS out of the box and honestly I did not tests if it works on Windows 10 Enterprise Multi-Session OS so aside from installing it on the base image, there is nothing more than can be done to publish this application remotely.
Solution (Get it Done Mode)
Having worked as a solution architect around VDI, SDN, HCI, and Cloud for the last couple of years, I was always introduced with customer requirements that do not, out of the box, map with product features/offerings per se so I always tried figuring out a way to make things work before googling or getting in touch with respective vendors.
The workaround here was to use Workspaces Web App which is a fully functional browser version of Workspace that is even more comprehensive than the installable plugin. To do that in a matter that is user friendly, I published IE in kiosk mode and locked it down to the Workspaces tenant URL after integrating Workspaces with ADFS for seamless SAML SSO.
The kiosk mode was too much because it opened in full screen mode with no option to minimize except with commands so I published standard IE pointing to Workspaces URL then used registry keys (pushed down through GP or Citrix WEM or VMware DEM) to lock down IE tabs and address bar plus applying all IE security stuff to make it practically useless except for Workspaces.
The end result was pretty seamless from an end user perspective and served the ultimate desired outcome of my customer regardless of the path taken.
Solution (Vendor Mode)
Jet lagging, I decided to go through our cases repositories to find a similar case that has been resolved with VDI in mind but found none. I then enhanced my search to just include command line install of Workspaces just to go over the available switches and voila !!! We do have two switches that would solve both problems when it came to publishing the app remotely and having it work optimally in a non-persistent VDI profile managed environment.
Solution for problem one was an command-line switch for Workspaces that enabled it to install on a server operating system. Solution for problem two was an command-line switch that enabled VDI mode which practically just means install in Program Files rather than User Profile. Easy enough, this is the command line installation on the RDSH server for the msi-installer which can be downloaded from here:
msiexec /i WorkspacesPluginSetupMsi.msi ALLOWSERVER=1 ALLUSERS=1 VDI=1 SIGNINSERVER=YOUR WORKSPACES WEB ADDRESS /L*V “%APPDATA%\WatchDoxSetup.log”
Now this application can be published directly as a remote application using any VDI broker you are using and can be installed on base images as well for compatibility with profiles management solutions for non-persistent VDI.
Profile Management
If you are using any type of remote virtual application and/or desktop solution, Microsoft FSLogix should be your go for a profile management solution with all due respect to other products out there. Every VDI environment should have FSLogix … !
Case and point is that if you want users to maintain their synced Workspaces in virtual applications/desktops while using FSLogix profile container, there is nothing to be configured. When using published Workspaces agent plugin, it will just work out of the box since the container includes the whole profile as a virtual disk rather than independent network files/folders. More so, you do not need custom symbolic links configured for them Workspaces synced workspace folders to roam virtual desktops and applications.
If using Citrix Profile Management, VMware Dynamic Environment Manager, and/or Folder Redirection ( Do Not FR AppData, I Beg You !!!) then you need to add the following folders to be synced with the profile (make sure they are not part of exclusions as well):
\Roaming\WatchDox
\Roaming\Adobe
\Roaming\Macromedia
\Roaming\Microsoft
Also when using the profile management tools mentioned above and want the user synced workspace folders to roam virtual desktops then symbolic links need to be applied so that C:\Users\%username%\WatchDox is translated to \\ProfilesFQDN\%username%\WatchDox\ (FSLogix attaches itself as the c:\users using a local vdh so does not require symbolic links). You can use any policy management tool to push the same on user login and make sure it is delayed around 30 seconds until the profile has completely loaded:
set wshShell= Wscript.CreateObject(“WScript.Shell”)
‘Sync symlink
strCommand = “mklink /d “”C:\Users\%username%\WatchDox”” “”\\ProfilesShareFQDN\%username%\WatchDox\”” ”
RunCommand = wshShell.Run(“cmd.exe /c ” & strCommand, 1, vbTrue)‘Sync Archive symlink
strCommand = “mklink /d “”C:\Users\%username%\WatchDoxArchive”” “”\\ProfilesShareFQDN\%Users%\WatchDoxArchive\”” ”
RunCommand = wshShell.Run(“cmd.exe /c ” & strCommand, 1, vbTrue)
Conclusion
Both ways are supported and work like a charm so it depends on how you want your users to interact with Workspaces. I am a big fan of the web version given the SaaS world we live in and easy user experience but again requirements dictate functionality not the other way around so keep that in mind.