(By "clean boot," all I could do was disable all non-Microsoft services.
#Xps document writer printer pdf#
For fun, I tried setting the MS PDF printer to use the CutePDF driver and that resulted in a 4.4MB PRN file when trying to printĪ test page, so the problem appears to be within the MS XPS & PDF drivers themselves as they seem to be getting good data. I need the XPS writer to work though as I have applications that need it. I also installed CutePDF to test and that works perfectly. Yes, I have the exact same problem with the MS PDF printer as with the MS XPS printer: zero-byte output files.
Browse to Printing > Drivers…Įdit the “Printer Driver Mapping and Compatibility” option and click the Add button…Įnter the name of the printer driver (“Microsoft XPS Document Writer”) and set the policy to create the printer with the universal driver only.Hello. In this case, there is a separate policy that controls printers. Let’s open up our Citrix user policies in Group Policy Management.
Fortunately Citrix, drawing on their experience in working around Microsoft’s various incarnations of FAIL, has provided us a very nice solution: The Citrix XPS Universal Printer driver.
We need to force the user’s session mapped XPS Document Writer to use a different driver that doesn’t invite them to surf the web from our datacenter.
#Xps document writer printer windows#
We could remove the XPS driver package, but if you are allowing automatic installation of native drivers on your Citrix servers, Windows will just reinstall it. If he views the Preferences for this printer, he will get the exact same properties window he got before. You’ll notice the user has a session mapped local printer for the XPS Document Writer on his machine. Let’s take a second look at the print dialog box the user sees. The script will forcibly delete the printer for everyone. This can easily be done from an administrative shell with the commmand:Ĭscript C:\Windows\System32\Printing_Admin_Scripts\en-US\prnmngr.vbs -d -p “Microsoft XPS Document Writer” First, unless you really need it, uninstall the Microsoft XPS Document Writer. But chances are there are some published applications that require a browser launch, even if it is only intermediate. In some environments, it is practical to just set file-level permissions on the Internet Explorer executable and deny access to everyone. The user has no access to a published desktop or a command line or “Run” prompt. I used group policies to strip away the bells and whistles and enforce additional restrictions on the user. You may have also noticed that, in this case, the user’s access was severely restricted even within Internet Explorer. Even server admins are not immune from falling victim to a zero-day exploit while on the web. There are other good reasons to block or regulate web access from your Citrix servers as well. How do we fix this? As I’m sure you’ve already considered, web filtering would be a good idea to mitigate the damage an Internet-bound user can mete out on your infrastructure. Your user is now on Youtube watching how-to videos about other great ways to elevate his privilege and bog down your pristine XenApp 6 server with garbage. NOT! Let’s watch some videos!” A few more clicks, and… Your user thinks, “XML Paper Specifiation Overview? This looks interesting. Your user, of course, has an irresistable urge to click the link. “Go online” are two words you do not want your users to see on a Citrix server. Then one day, when your user goes to print something, he is looking at the print dialog and notices this “Microsoft XPS Document Writer” printer as an option. Your user is happily working in your published, seamless application via XenApp 6 running on Windows Server 2008 R2, and life is good.
0 kommentar(er)
