I have been a long time fan of FSLogix. Kevin Goodman and team delivered not only a kick ass product that is super simple to work with and deploy but also one that had an immediate value add for every organization lucky enough to be a customer.
Whenever I have talked about FSLogix at conferences, I have referred to them as the Kings of keeping it simple.
App Masking was my first adventure with FSLogix but as you may see on my site, I later branched out into their great Profile Containers solution too.
Fslogix included in RDS CAL. Very nice 😀. #microsoftIgnite #IgniteTheTour #rds #FSLogix pic.twitter.com/IKwU24FPij
— Koos van Duijvenbode 🇪🇺🇳🇱 (@KoosvD) March 21, 2019
Now that FSLogix has been acquired by Microsoft and it has been announced that the entire product suite will soon be available for pretty much all enterprise customers, I figured it might be timely to revisit App Masking and talk about some real world examples of where it has helped me.
Of course, you could load all of your apps into a fat image and use FSLogix to hide the applications selectively for the different users who log in, that’s a use case that was marketed many years ago. In my opinion, that has limited appeal to me when working in medium to large sized organizations but there is still plenty of interesting use cases. For example:
Use Case 1.) Publishing an application through Citrix Storefront only and NOT to the desktop
Do you currently deploy your Citrix published applications to the user’s desktop and start menu? Have you ever had a particular application that you wanted to make available remotely through Storefront without a shortcut on the desktop or start menu?
There is a way to do this with multiple Storefront Stores and filters but that’s convoluted, in my opinion and since you most likely will soon own FSLogix, I’d like to show you an easy way.
First, in order to use App Masking you’ll want to install the FSLogix Apps agent. It’s a straight forward install, accepting all defaults is fine for this example. This same agent is required for Profile Containers and the Office 365 Containers, with additional settings required via GPO or registry to enable that functionality.
On a VM or machine that has the Citrix published application shortcut you’d like to hide on it’s desktop or in it’s start menu, install the FSLogix Apps RulesEditor and launch it. Next, create a new rule and give it a name. In my case, I named it Hide-CitrixMidas as the app I wanted to hide is my Citrix published Midas app. I opted to create a new blank rule rather than using the Scan feature or the Browse to the Program Files Directory feature, which both work great if the app you want to mask is locally installed, in this case it’s a Citrix published app so I’m not worried about hiding many directories, registry, printer etc.
Instead, in this blank rule, I click on the + option in the menu, select Directory/Registry from the dropdown and browse to the path of the Start Menu shortcut. Before saving, I replace my username with * to ensure it works for everybody and not just me.
I also click Rule Set does apply to user/group and ensure it’s set to apply to Everyone as in this case I wish to hide the Citrix published shortcut for everyone when on a company workstation. Remember, I just want Midas to be accessed via Storefront.
Once the rule files have been deployed to the C:\Program Files\FSLogix\Apps\Rules directory on a machine with the FSLogix Apps agent installed, immediately the shortcut disappears from view. You will notice the Midas directory is missing above. You’ll just have to trust me that it was there to begin with 🙂
Midas is now only available via Storefront.
I have worked in environments in the past, in the early days of 7.x where the Citrix team published to Storefront and to a Citrix Applications directory in the start menu which became confusing when the same application was locally installed and available in Citrix. Creating rules to hide one or the other based on AD Group membership is also possible with FSLogix and is also very simple to achieve.
Use Case 2.) App-V Scheduler + FSLogix = WIN
I’m a huge fan of App-V Scheduler. In the majority of App-V environments I have worked with, I have deployed either through SCCM or the App-V Full Infrastructure or more often than not, both. I have rambled at length in previous blogs about the fact SCCM with App-V is not a good solution for non-persistent machines. I have also ranted about how the App-V Full Infrastructure is incredibly limited. My preference in my environment is to use App-V Scheduler for my App-V deployments.
App-V Scheduler has a Managed setting, which allows you to deploy your App-V applications with user and/or global publishing. Global publishing has a higher app compatibility success rate than user publishing. In terms of App-V Scheduler it also makes things much easier, there is no messing about with assigning applications to groups or trying to keep track of how the apps are published.
You can just set it to Unmanaged, it will publish everything in your App-V Content share to your targeted machines and publish them all globally. In a previous article, I highlighted the fact when you publish globally on a shared machine it means all users can see the contents of that application BUT thanks to FSLogix, that doesn’t have to matter. FSLogix App Masking works with App-V applications! You can simply mask the app from anyone who should not have access to it.
You get a much simpler App-V deployment with App-V Scheduler, a higher chance of your App-V apps working with global publishing and the ability to restrict access thanks to FSLogix but wait! There’s more! Keep reading to find out how you can use App-V to deploy your FSLogix rules.
3.) App-V Scheduler + Shared Desktops\WVD\VDI + FSLogix = WIN
Microsoft appears to be going all in with the shared desktop model for Windows 10 with their Windows Virtual Desktop announcement. The acquisition of FSLogix helps them execute a shared desktop perfectly. You can install apps and then mask from those who shouldn’t get it, you can use the Profile Containers to ensure Office 365 functions optimally and of course your user’s data and application settings roam. Almost everything you need to support multiple users on a Shared Desktop.
Even if you’re not looking at WVD right now, maybe you’ve got XenDesktop or Horizon Virtual Desktops for full personal virtual desktops and you find yourself struggling to provide applications like licensed apps that should not be available to all users of your desktop pool. Not all apps work well through RDSH and not all apps can be delivered with App-V, ThinApp or any other appvirt product (except of course Numecent Cloudpaging which can deploy anything because it’s awesome).
In this case what do you do? How do you get the app to just the users who need it in a large desktop pool? Spin off a new pool just for those users who need that licensed app? What and have another parent VM to patch? Are you crazy? Now you can just install the app into the pool and use FSLogix to mask from those who are not licensed. Simples!
Now For the Fun Part
I had a use case that was perfect for FSLogix recently. Not in VDI but in a Citrix Shared Desktop. Most of my applications are sequenced in App-V and delivered as published applications through Citrix Virtual Apps, even on my Shared Desktop. The Shared Desktop is essentially pretty bare since the majority of apps are just shortcuts delivered by Citrix Workspace App.
When working on a desktop migration, SnagIt came up on the list and was pretty limited for certain licensed users.
SnagIt works great as an App-V sequenced app but it’s not a good candidate to run as a published application, as it’s a tool that should run whenever you hit print screen. Users also want to take screenshots on their desktop, not on the Citrix VDA!
In this case, I would deploy my App-V sequenced SnagIt with App-V Scheduler to the desktop. I would of course then use FSLogix to ensure only the users with a valid license can see it. One problem here, I don’t have SCCM on my non-persistent machines because as mention earlier it sucks in that scenario. How do I deploy my rules? Do I have to open up my vdisk and drop the files in and redeploy the image? If so, I’m out!!
I decided to use App-V to deliver the rules on a per app basis. Check this out!
Deploying FSLogix Rules with App-V
First, I ensured my SnagIt App-V app was globally published and mounted on my machine that had the FSLogix RulesEditor installed.
I started once again with a blank rule and in this case added my App-V Package Store directory and the .lnk files for the shortcuts rather than just the TechSmith Start Menu folder (this was incase different users have Camtasia in the same folder, I don’t want to inadvertently hide that). I went into HKCR and one by one added all of the SnagIt registry for the shell extensions…this bit was long and tedious because this app has a lot of file types it supports.
FSLogix lets you save as a template, I may remove the App-V directories and share just the HKCR reg for anybody who wants it.
Update: Thanks to Brandon Mitchell for the suggestion to run a Scan on a machine with the app installed. That should work for my needs as the App-V registry is located in the same spot as the local install. I will then just remove the File and Folder hiding rules and add my App-V Package Store and shortcut hiding rules.
In my earlier example, I just hid a published application’s shortcuts from Everyone. This time, I want to hide this App-V app from everyone EXCEPT those in my AppVSnagIt AD Group. I configured as seen above and saved those rules.
Now for the magic! I have my rule files. I have my sequenced SnagIt ready to go.
These next steps may vary depending on your preference. If I wanted to, I could open my sequenced app and add in the FSLogix Rules plus a script and set the App-V app to copy the files from the VFS to the local C:\Program Files\FSLogix\Apps\Rules directory when the app is added to the client but I decided not to do that.
Here’s what I did! I created a simple PowerShell script that checks to see if the FSLogix Rules directory exists and if it does, it copies my rules files from a Rules folder that I place with my App-V sequenced SnagIt on the App-V Content Share. I then save my script into a Scripts folder on the Content Share. You can make your script much more robust. This is just an example.
I then made my DeploymentConfig.xml and added a MachineScript using PowerShell.exe to run the PowerShell script.
Note: if you wish to execute scripts from a file share in App-V, you’ll need to EnableScripts for App-V on the client and ensure Domain Computers has read and execute permissions on your Scripts and Rules folders.
If you use App-V Scheduler like me, you’ll want to make sure your client is configured to automatically run your custom deployment configuration file when one is detect on the share and also ensure the XML is saved as a .appd. If you do not have App-V Scheduler and use the App-V Full Infrastructure with your VDI or Shared Desktops, you’ll want to add the configuration XML via the App-V Management Console. It’s always smart to first backup your app\default config file before doing that.
If you use PowerShell for testing or deployment, you can try this out:
Add-AppVClientPackage <path to .appv> -DynamicDeploymentConfiguration <path to your Deployment Configuration.xml> | Publish-AppVClientPackage -Global | Mount-AppVClientPackage
The result! If you have the FSLogix agent installed and are in the group that the rule should not apply to, SnagIt appears and works as expected. If you are not in the group, it will not appear for you. If you do not have FSLogix installed, it won’t see the directory and will not copy the rules to the machine.
If you’d like you could add a script to run on Remove that delete the files but that depends on your environment and your preference.
