Hosting Adobe Acrobat DC on Citrix Non-persistent RDSH with FSLogix App Masking | A Walk-through

Environment 

• 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 

Introduction

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

Microsoft FSLogix

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) 

Get the offline standalone installation from here. At the time of writing this blog, a direct link was published here for Acrobat DC Pro. 

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 

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.

HKLM\SOFTWARE\WOW6432Node\Google\Chrome\Extensions\efaidnbmnnnibpcajpcglclefindmkaj

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. 

Key path:

HKEY_CLASSES_ROOT\SOFTWARE\Adobe\Acrobat\Exe\ 

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:

Acrobat_Pro_DC_Config.txt 

.pdf, Acrobat.Document.DC
.pdfxml, Acrobat.pdfxml
.acrobatsecuritysettings, Acrobat.acrobatsecuritysettings
.fdf, Acrobat.FDFDoc
.xfdf, Acrobat.XFDFDoc
.xdp, Acrobat.XDPDoc
.pdx, PDXFileType
.api, Acrobat.Plugin
.secstore, Acrobat.SecStore
.sequ, Acrobat.Sequence
.rmf, Acrobat.RMFFile
.bpdx, AcrobatBPDXFileType

Acrobat_Reader_DC_Config.txt

.pdf, AcroExch.Document.DC
.pdfxml, AcroExch.pdfxml
.acrobatsecuritysettings, AcroExch.acrobatsecuritysettings
.fdf, AcroExch.FDFDoc
.xfdf, AcroExch.XFDFDoc
.xdp, AcroExch.XDPDoc
.pdx, PDXFileType
.api, AcroExch.Plugin
.secstore, AcroExch.SecStore

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. 

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: 

Registry: HKEY_CURRENT_USER\Software\Adobe\

Files and Folders: %Appdata%\Adobe\*

Enjoy!