FSLogix with App-V

By Rory Monaghan


Other FSLogix and App-V Content

In a previous blog post, I mentioned a great article by Duncan Murdoch around App-V and FSLogix integration, I encourage you guys to check it out. In another post by Duncan, he covered the possibility of just using global publishing for all of your App-V applications. The benefit of global publishing is that there’s a higher rate of compatibility than with user publishing, the downside is that everybody on the system gets the application published to them. With FSLogix you can selectively mask the applications from users who you do not wish to access them to get around the issues presented with global publishing. Check out that post for more.


In my post, I wanted to come at this from a slightly different angle. In my popular decision matrix post, I cover ways to overcome the current limitations with App-V. For some of the limitations like drivers and COM+ component services, I suggest extracting those components and scripting an install to put those locally on the machine. That script runs as part of the deployment config file and installs when the application is added to the App-V client machine. That works great, however with many using App-V customers deployingnon-persistent virtual desktops, maybe adding those drivers is a performance concern with their current deployment strategy.

If they use certain tools like App-V Scheduler or RES Automation Manager, it may be less of a concern. If using the App-V Full Infrastructure, that’s very limited and you may need some help. In that case, it may be better to to extract those drivers and COM+ component services and just add them to the image. What happens then?…well, all of a sudden you hit the problem that all drivers are exposed to every user, that’s far from desirable and just like how FSLogix can help reign in your globally published App-V applications, it can also help with those drivers and components.


In this post, I’ll use the example of printers! This is the most common limitation I hit with App-V. Many applications use their own custom print drivers. If I add all of these to the image, somebody could launch their Adobe Reader and try to print to say my Foxit Reader virtual printer….very quickly, you could have all kinds of funky behavior on your hands.

Screen Shot 2016-07-31 at 10.01.33 PM

In the above screenshot, you can see I have a few different printers available. I even have two different Foxit printers. In this example, I’ll focus on my Evernote printer. What if I only want my group to use Foxit Reader and certainly don’t want them trying to print from Reader using the Evernote driver!? How do I stop them from doing this and possibly causing all kinds of issues?

Screen Shot 2016-07-31 at 10.06.01 PM


I can use FSLogix Rules Editor to create a new rule to hide the printer and assign that rule to whatever set of users or machines that I want!

Note: If I was talking about network printers, I could even create a rule based on my network!

Screen Shot 2016-07-31 at 10.06.17 PM

Creating the rules couldn’t be simpler! And deploying them is a breeze. You just ensure the tiny rule files are present within the FSLogix rules folder. Simplicity is what FSLogix is all about!

Screen Shot 2016-07-31 at 10.56.04 PM


When a user who is not entitled to use the Evernote printer attempts to use it from Reader, they receive the above error and cannot continue with that printer.

Screen Shot 2016-07-31 at 10.59.27 PM


The correct printer that the user is entitled to will work just fine.

Screen Shot 2016-07-31 at 10.15.43 PM


If the user tries to double click on the printer in Devices and Printers they will get an Access is denied error.


I went for the most likely culprit for this blog post, printers! This is a great value add for a non-persistent VDI project. I would love to see improvements in future releases of FSLogix which may actually completely remove visibility of the printers but for now removing the functionality is pretty good.

Screen Shot 2016-07-31 at 11.20.03 PM







I attempted to follow the logic of removing a printer via the registry, only with FSLogix I just created hiding rules for the reg keys rather than deleted them. I think the missing ingredient is that after you delete the registry, you restart the spooler and then the printer disappears:

Screen Shot 2016-07-31 at 11.21.50 PM


Maybe right now, this is such a low level system function that the hiding rule doesn’t work for the check performed by Windows on the printers and devices but maybe some day it can!


Let's make virtualization easier!

Be amongst the first to know when I publish new reviews, guides and tools to simplify your projects.

By signing up, you agree to our Terms of Use and acknowledge the data practices in our Privacy Policy. You may unsubscribe at any time.