When a particular client connected to our published application, XenApp auto restored a number of client printers with a name starting with “lynx” and “LYNX”. The policy was set to auto-create the client’s default printer only so why was it auto restoring multiple printers? The lynx* printers do not even exist on the client’s PC and we do not have any users with names matching the printers. This has to be one of the strangest things I’ve seen so far in XenApp 6.5 with Hotfix Rollup Pack 3 (XA650W2K8R2X64R03). I searched Google and found this post on the Citrix discussions which describes the exact same thing I was seeing. Just too bad some of the posts are unresolved! After doing more digging, here’s what I found:
Here is a list of the exact names (google returned 0 results for the names):
Autocreated Printers: Client local or network printers that appear for the user within an ICA session and use the ICA protocol to send a print job. Autocreated printers use the ICA printer naming convention.
Autorestored Printers: A manually created client printer attached to a standard client printer port. This kind of printer can be created by an administrator or power user running the Add Printer wizard and manually creating a local printer that is attached to a standard client printer port. These printers are deleted when logging off and re-created when logging on.
Autoretained Printers: These are client printers that are added by the user within an ICA session through the Add Printer wizard by browsing and connecting to printers enumerated through the client network print provider. When re-creating a retained printer, all Citrix policies except the autocreation policy are respected. This means that retained client printers are created exactly as the autocreation policy would have selected them. Such printers continue to be re-created with every logon from the same client until the client printer within the session is deleted manually or the remembered printer connection is removed from the client’s properties store. On a Windows client, the properties store can be found in the user profile under
Client Printers: Any printer available to a user before an ICA session is launched.
- Client Local Printer: Printers that are physically connected to client devices through LPT, COM, or TCP ports.
- Client Network Printer: A network printer that appears in the Printers and Faxes folder of a client device and is managed by a print server. This differs from a print device attached to a standard TCP/IP port.
Citrix Print Manager Service (cpsvc.exe): Provides printer management for all ICA sessions including printer policy enforcement, driver installation, client printer port management, auto-creation of network and client printers, and printer/port cleanup when logging off.
Because I read this Citrix post, I knew someone out there in this world was also seeing these auto restored lynx printers with the same names. I thought maybe a bug in XenApp 6.5? A bug in the Citrix Print Manager Service (CpSvc.exe)? A bug in the Citrix Receiver on the client? Since it was only happening to one client out of many it’s hard to tell where the fault lies, although I am suspecting it is the Citrix Print Manager Service. One of the problems troubleshooting Citrix issues is that most of the time, as a sysadmin, we only touch the server. There really isn’t a way to do any client-side configuration outside of XenApp configurable properties such as deleting/adding local printers on the client’s PC without utilizing remote session software such as Citrix GoToMeeting. And we can’t just tell the user to re-image their PC.
After re-creating the users profile on the server, and using GoToMeeting to delete and re-create the client’s local printers the problem was still there!
My next step was to look at the users profile on the server. I loaded the users registry hive from the old user profile I had renamed earlier in order to create a fresh profile for the user during my initial troubleshooting. Let’s have a looksie:
What the heck is going on?
Find the users SID with PowerShell and look at live hive:
$name = “pdiscordia” (New-Object System.Security.Principal.NTAccount($name)).Translate([System.Security.Principal.SecurityIdentifier]).value
I’m convinced that the issue is a bug in the Citrix Print Manager Service, but until I get my hands back on the client PC I won’t be able to do further digging. Because the lynx printers seem to be somehow associated with the Microsoft XPS Document Writer driver, I have decided to prohibit retained and restored client printers.
In addition, put the Microsoft XPS Document Writer in the shithouse by utilizing the XenApp policy called Printer driver mapping and compatibility, and manually delete all of the lynx* printers.
If you have additional information regarding the Lynx printer phenomenon, please post a comment below! Your feedback is greatly appreciated.
When you're a little too careless about virtualizing your domain controllers, cloning, migrating, backing up and restoring, returning from vacation… Read More
Systemd is new service manager for Linux. It's a replacement for all previous init systems (SysV/SysVinit & Ubuntu's Upstart) and… Read More