Hosting Adobe Acrobat DC on Citrix Non-persistent RDSH with FSLogix App Masking | A Walk-through
- Windows RDSH or VDI (non-persistant)
- Citrix Virtual Apps and Desktops (Any version)
- FSLogix App Masking
- Ivanti Environment Manager (or any equivalent solution)
- Citrix Provisioning Services (or any equivalent solution)
- Adobe Acrobat Pro DC – Named User License
- Adobe Acrobat Reader
It is common in many organisations to have a situation where a small subset of users require to use a paid for, licensed Adobe Acrobat DC, while the majority only require the free Adobe Reader. In this blog post, we will gather all the information to dynamically provision Acrobat and Reader with FSlogix App Masking, while managing FTA (File Type Association) on the fly.
First Things First – Installations
Assuming FSLogix is not part of the base image, you will need to download the latest version and install it. The beauty of FSLogix is the fact that it doesn’t require any infrastructure. It has been acquired by Microsoft and been made free for large spectrum of Microsoft License holders. If you have any of the following licenses, then FSLogix is free to use.
- Microsoft 365 E3/E5
- Microsoft 365 A3/A5/ Student Use Benefits
- Microsoft 365 F1
- Microsoft 365 Business
- Windows 10 Enterprise E3/E5
- Windows 10 Education A3/A5
- Windows 10 VDA per user
- Remote Desktop Services (RDS) Client Access License (CAL)
- Remote Desktop Services (RDS) Subscriber Access License (SAL)
See FSLogix Overview for more infomation
FSLogix is available for download here. For this scenario, we will be looking mainly at two of the three FSLogix components:
- Microsoft FSLogix Apps
- Application Masking Rule Editor
Follow the installation instructions here. They are straightforward.
Adobe Acrobat DC (2019)
Optionally, you may want to create your own customization on the package, Customization Wizard can be used. It can be found here.
Adobe has a guide for Virtual Environments deployments. A subsection of that has a specific XenApp/XenDesktop deployment guide
In this scenario, I am focusing on Named User Licensing method as it is the preferred activation method by Adobe.
Named User Licensing (NUL) requires the user to have internet access to “Sign In” when they first login and activate their entitlements.
To make sure the license can roam between sessions, the following switches should be used
Setup.exe /sALL /msi ROAMIDENTITY=1 ROAMLICENSING=1
Follow the Instructions here to complete the installation.
FSLogix App Masking Config
In a nutshell, App Masking controls who can “see” an application. An application can be assigned (available) to an AD user, AD group, computers, containers, etc.
In this scenario, We are assuming the origination has a dedicated AD group for users who are eligible to use Acrobat DC Pro. We will be using this AD group to mask the application in a bit later.
Run FSLogix Apps RuleEditor and start a new Rule Set File (.fxr)
Give it a name and save it in a temporary location. Click Scan
FSLogix now will go about discovering all directories/files, registry keys/values, etc..
Click the + sign to add Adobe PDF printer to the rules. it doesn’t get added automatically.
Hide the following key to prevent the auto installation of Adobe Acrobat Chrome Extension to everyone on the image.
Click on “Manage Assignments” and hide the rules from “Everyone” while adding the intended user group in. Don’t forget to add the admins group(s) so you always have visibility of all apps when needed.
Review everything and save the rules. 2 files will be saved: rule file (.fxr) and assignment file (.fxa).
If you installed FSLogix App Masking in the default location, then you will need to copy the above two files to C:\Program Files\FSLogix\Apps\Rules.
Once copied, the FSLoigx service will automatically detect the rules and apply them on the fly. Test logging in to the build machine using a user that is not in the assigment AD groups and confirm that Acrobat is not visible to it.
Other considerations before sealing the image
The “blessed” Adobe Application
If you happened to install Acrobat DC after Reader DC, then most likely Acrobat DC will take over as the default viewer for Web browsers. This is usually not a problem until App Masking comes into play. When users without Acrobat DC visibility open PDF files in the browser, then the browser will look for the default “blessed” Adobe client – in this case it is Acrobat DC. However, the location is not visible to the user.
So when users try and view PDFs in the browsers, the will get the below error:
The Adobe Acrobat/Reader selected for viewing PDF documents in browsers cannot be found at its installed location; it may have been moved or deleted.
Annoyingly , this can’t be changed form the application preference by going to Acrobat Reader DC – Edit – Preferences – Internet
The only way around this, is to make sure you change the value in the registry on the base image before sealing/provisioning as it’s a HKEY_CLASSES_ROOT key and has no equivalent under HKEY_LOCAL_MACHINE.
Change the “default” value data to your Reader DC location i.e.
“C:\Program Files (x86)\Adobe\Acrobat Reader DC\Reader\AcroRd32.exe”
Adobe reference can be found here
Adobe Optimizations for Visualized Environment VDI/RDSH
The following optimizations were shared by Salim Hurjuk on Slack – Thought it is worthwhile putting them up somewhere for everyone’s benefits
1. DisableMaintenance – 1 – HKLM
2. FeatureLockDown – bProtectedMode – 0 – Don’t enable protected mode – HKLM
3. FeatureLockDown – bShowEbookMenu – 0 – HKLM
4. FeatureLockDown – bUsageMeasurement – 0 – HKLM
5. FeatureLockDown – bPurchaseAcro – 0 – HKLM
6. FeatureLockDown – bUpdater – 0 – HKLM
7. FeatureLockDown – bToggleFTE – HKLM
8. FeatureLockDown – bShowScanTabInHomeView – HKLM
9. cServices – bToggleDocumentCloud – 1 – HKLM
10. cServices – bToggleWebConnectors – 1 – HKLM
11. cWelcomeScreen – bShowWelcomeScreen – 0 – HKLM
12. cSharePoint – bDisableSharePointFeatures – 1 – HKLM
13. bAutoSaveDocsEnabled – 0: Don’t autosave documents – HKCU
14. bAntialiasGraphics – 0 – HKCU
15. bAntialiasImages – 0 – HKCU
16. EULAAcceptedForBrowser – 1 – HKCU
17. EULA – 1 – HKCU
Setting File Type Association (FTA) on the fly
One of the main challenges in RDSH environment is managing File Type Association per user. Microsoft in the past years made it very difficult to set those settings per user. They introduced controls through GPO but all of them addressed the issue “Machine wide”.
This is a huge challenge in non-persisting RDSH setup. Thankfully, a genius called Christoph Kolbicz @_kolbicz managed to “reverse engineer” how Microsoft sets FTA and created a tool that can sets them per user.
Download the tool, save it on the image, and make it readable/executable by all users.
create two text files in the same location as the tool. Each file will have set of FTAs, one for Reader and one for Acrobat – based on Adobe documentations, I came up with the following two files:
Simply put, you will need to add a logon trigger/action, to call the tool and pass a list of FTAs based on the user’s membership of an AD group e.g. if the user is member of Adobe Reader AD group, call the tool and pass the FTA of Adobe Reader, on the other hand, if the user is a member of the Adobe Acrobat AD group, the pass the Acrobat DC FTAs, etc.
Ivanti (Appsense) Environment Manager makes this job easy by adding a logon trigger that runs in the user context:
Otherwise, you may want to use the following Powershell example and run it as a login script by Group Policy. Note: Make sure ActiveDirectory Module is available.
$user = "$env:UserName"
$Acrobat_pro_group = "SGCT Adobe Acrobat DC PRD"
if ((Get-ADUser $User -Properties memberof).memberof -like "CN=$Acrobat_pro_group*")
. SetUserFTA.exe "Acrobat_Pro_DC_Config.txt"
. SetUserFTA.exe "Acrobat_Reader_DC_Config.txt"
Roaming Settings and licenses
So many profile management solutions out there, but for folks who uses Ivanti (Appsense) User Personalization, despite the general belief that Adobe should be personalised as an “application”, and despite the fact that Ivanti forums lists an Acrobat XML template as an application, Ivanti is now recommending placing Adobe Acrobat/Reader under Windows personalizations.
It’s also strongly recommended that Adobe Reader / Acrobat be placed in a Windows Settings Group due to recently changes to how these programs operate with sandboxing. – Ivanti
From my experience with this, if Application Groups were used rather than Windows Settings Group, the Named User License roaming and SSO fails. i.e. users would need to re-authenticate every time they use a new session.
Regardless of the solution you are using to persist the settings, the following will need to be saved:
Files and Folders: %Appdata%\Adobe\*