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.
Introduction
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.
Printers
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.
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?
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!
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!
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.
The correct printer that the user is entitled to will work just fine.
If the user tries to double click on the printer in Devices and Printers they will get an Access is denied error.
Conclusion
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.
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:
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!
