Lynx Auto Restored XenApp Printers
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):
Quick review of relevant Citrix printing
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.
September 23, 2015 6:29 pm @ 18:29
It’s incredible that after all these years, the issue still exists and the only (not sure if temporary) solution is to delete the users’ HKCUSoftwareCitrixPrinterProperties (or relevant subkeys thereof) on the client machines. The problem with the policy to disable the creation of “auto retained and auto restored printers” is that the first kind (“auto retained”) is *useful* and only the second kind (“auto restored”) is the problem, and as far as I know nobody purposefully creates this second kind. It would be great if there were *separate* policies for disabling each of these two kinds of printers. [“auto retained” are the additional ICA client printers that a user “requests” using “ICA Client Printer Configuration”, a great tool to provide users in combination with the policy to only auto-create the client default printer].
I wish I knew what piece of Citrix code (ICA client? print manager service? …?) does (or did at some point) contain all these references to foreign usernames and printers and clients and gateways, etc. — somebody got hacked somewhere along the line and is being quiet about it!
March 22, 2017 2:14 pm @ 14:14
I have the exact same issue as you, down to the name of the bogus printers !
This is an old topic, but did you manage to fix the issue or hear from Citrix ?
This is driving me mad !
March 22, 2017 4:06 pm @ 16:06
Unfortunately, no. If you have a support contract with Citrix could you try opening a case with them and let me know? I would appreciate it even though this is an old/mystery issue. If you don’t figure it out I wouldn’t sweat it as it seems to be some sort of software conflict between the clients computer and the XenApp server.
March 23, 2017 8:54 am @ 08:54
Thanks for your quick reply !
I’m gonna try what you suggested in your article and see if it helps. We have so many (fake) printers (I counted more than 400 the other day) that sometimes users cannot access their (real) client-side printers anymore !
I’ll let you know in case we decide to open an official case with Citrix.
July 10, 2018 9:50 am @ 09:50
Hey did you end up opening that case with Citrix?
July 10, 2018 10:06 am @ 10:06
Nope, we pretty much gave up on that and are in the process of upgrading to Windows 2016 and XenApp 7.9.
April 4, 2017 7:30 am @ 07:30
I’ve only just started seeing this on my client’s XenApp farm. They have XA6.0 with the R02 Hotfix pack and only just started seeing this issue in the last couple of days. I’m only seeing only of the LYNX printers: LYNXCKempbell
But a mass of Microsoft XPS Document Writers using the Citrix Universal Printer driver.
Each time I delete the auto created printers they come back. Checked Citrix User policy and we do have autocreate and restore configured for all client printer objects. I’ve changed this to only the default and going to see if this changes anything. I’ve also set the HKLMSOFTWARECitrixPrint DefaultPrnFlags to (hexidecimal) 90004000 as per other posts on this issue.
You’re still the only google result for LYNXCKempbell + Citrix which I find bizarre!
July 10, 2018 9:52 am @ 09:52
Sweet, I just tried out searching “LYNXCKempbell + Citrix” and you’re right, I am still the only hit. Long live Sysinfo.io!!!