Jump to content


Photo

Lots of auto restored printers

Started by Joshua Post , 17 May 2013 - 07:34 PM
27 replies to this topic

Joshua Post Members

Joshua Post
  • 35 posts

Posted 17 May 2013 - 07:34 PM

We have an issue from time to time with end users having slow login times, and then we see over 150 printers auto restored from the client. We have checked the end user's computers, and these printers do not exist, so they are not being auto created, and the comment even shows Auto Restored.

We get many copies of the "Microsoft XPS Document Writer" and "Microsoft Office Document Image Writer" when this happens, along with some printers that start with "lynx" followed by a name that isn't our users. I've attached a screenshot showing the printers created by two of our clients on the same server.

After some amount of time this seems to stop, but I haven't found a rhyme or reason yet. We do set a PRNFlag registry entry to allow administrators to see all printers and to disable printer creation for certain drivers, like the XPS Document Writer
[HKEY_LOCAL_MACHINE\SOFTWARE\Citrix\Print]
"DefaultPrnFlags"=dword:10004000

I cant seem to figure it out, and when it happened to the 5th user, I decided I needed help. I thought originally this was only happening to Secure Gateway users, but in the screenshot you can see one of the users is using AD18 as a computer name and not a WI name.

Attached Files



Joe Robinson Moderators

Joe Robinson
  • 1,075 posts

Posted 17 May 2013 - 11:13 PM

Do these look like printers that might belong to a different session? I'm asking because I have raised a bug with Tech Support and it is currently with a developer. The problem is with Citrix Print Manager (cpsvc). When a user logs on, and CPSVC creates a printer, it should be removed when the user logs off. However, if cpsvc stops for any reason, the printer will not get removed. This happens even if cpsvc is restarted.

This may be the same bug, as I noticed that the names of your Web Interface clients do not match up.

The easiest way to test this is to log in and let it autocreate. Stop CPSVC and then start it. Now log out and back in and you should see duplicate printers, but the session information will be wrong.

I could be totally off base here, but I thought I would share just in case.



Joshua Post Members

Joshua Post
  • 35 posts

Posted 20 May 2013 - 09:54 PM

I don't think it is the same issue. They don't appear to be from another session of any of my users. None of the names match any of our associates or devices



Joshua Post Members

Joshua Post
  • 35 posts

Posted 05 June 2013 - 04:48 PM

Any other thoughts?



Marek Dresler Citrix Employees

Marek Dresler
  • 952 posts

Posted 11 June 2013 - 07:41 AM

Hi Joshua,

Please review and follow the below article.

http://support.citrix.com/article/CTX117805 - How to Disable Autorestored and Autoretained Printers

Regards,
Marek



Michael Duncan Members

Michael Duncan
  • 1 posts

Posted 10 July 2013 - 07:56 PM

I am seeing this unusual problem also...lots of "Auto Restored Client printers" which do not exist within our enviroment and we also do not know how they are getting created.

I have been researching the "DefaultPrnFlags" key that Marek mentions but am hesitant to change make this change in the Production environment. Our current default setting is 0x00004000 which allows administrators to view/modify sessions printers.

Has anyone had any luck with this?

Attached Files



Joshua Post Members

Joshua Post
  • 35 posts

Posted 15 July 2013 - 09:53 PM

I added the flag to disable autoretained and autorestored printers 0x80000000 and I didn't have any side effect. I don't see any extra printers during the last few days
http://support.citrix.com/article/CTX119684

This is what I use:

Windows Registry Editor Version 5.00

;Disables printer creation for specific drivers via Universal Print Driver
;http://support.citrix.com/article/CTX110343
;Also allows administrators to see all printers
;http://support.citrix.com/article/CTX119684

;Updated 6/12/2013 from 10004000 to 90004000
;This will prevent auto-restored and auto-retained printers

[HKEY_LOCAL_MACHINE\SOFTWARE\Citrix\Print]
"DefaultPrnFlags"=dword:90004000



Markus Korhonen Members

Markus Korhonen
  • 12 posts

Posted 27 June 2014 - 09:31 AM

Hi!

 

We have very similar problem where some users get up to 200 printers (from clients we do not know of) in their printers!
Above reg hack ([HKEY_LOCAL_MACHINE\SOFTWARE\Citrix\Print] "DefaultPrnFlags"=dword:90004000) has been tested without result.

 

What is causing this and how can we fix it?

Cheers!

Edit: The profiles have also been deleted so these printers are retained/created in a new profile aswell.



Joshua Post Members

Joshua Post
  • 35 posts

Posted 27 June 2014 - 03:10 PM

Markus, are you on XenApp 4.5 or 5 with Server 2003??  The certainly fixed it for us after a restart of the print spooler and Citrix Print Management service.



Jeremy Leasure Members
  • #10

Jeremy Leasure
  • 5 posts

Posted 10 July 2014 - 12:15 AM

I have written a blog post about the mysterious Lynx printers. Although the root problem is still unresolved, I did manage to dig a little deeper.

 

http://www.travisrunyard.com/2014/07/09/lynx-auto-restored-xenapp-printers/



Mathias Schüler Members
  • #11

Mathias Schüler
  • 3 posts

Posted 18 September 2014 - 10:33 AM

Hello,

 

I have the same problem with strange printers in user sessions. Another odd thing is that it depends on which client the user logs on from. I cannot figure out how to get rid of this behaviour.

 

Have you found a solution?

 

//Mathias



Jürgen Müller Members
  • #12

Jürgen Müller
  • 55 posts

Posted 07 November 2014 - 10:04 AM

Hi,

we have the same problem. In the Citrix User Policies you can set: Retained and restored Client Printers.

The default value is allowed. At the moment we are testing with the value "probhibited".

This link describes the situation very good :-)

http://www.travisrunyard.com/2014/07/09/lynx-auto-restored-xenapp-printers/

 

Best regards

 

Jürgen



David Lang Members
  • #13

David Lang
  • 4 posts

Posted 29 December 2014 - 02:24 PM

I have the problem specifically with the Microsoft XPS Document Writer on XenApp 6.5 on Windows Server 2008 R2.  I have disabled all printer auto creation and the XPS printer still is created.  The administrators can see all printers and these keep coming back.  

 

I am waiting for the test results now, but it looks like for the XPS printer, you have to remove the printers and delete the driver to disable auto creation for that printer.

 

I used the printer management tool to bulk delete the printers that were auto created and then deleted the driver for the printers.

 

David



Cheryl Dugan Members
  • #14

Cheryl Dugan
  • 211 posts

Posted 20 August 2015 - 05:02 PM

I want to do both of the following:

 

1. Block drivers on the compatibility list.

2. Disable auto-created and auto-retained printers.

 

How the hell do I do both with just one key?



Konrad Ruess Members
  • #15

Konrad Ruess
  • 2,925 posts

Posted 15 September 2015 - 04:17 PM

Hi Nathan,

 

Quite an old thread you are jumping on...

 

Use farm policies to disable auto-creation and printer properties retention, use printer driver compatibility settings to block unwanted drivers. Both can be found in CMC / CPS.

 

BfN,

Konrad



Jacques Bensimon Members
  • #16

Jacques Bensimon
  • 42 posts

Posted 23 September 2015 - 06:38 PM

The problem with the policy to disable the creation of "auto retained and auto restored printers" as a solution to the mysterious "auto restored printers" issue is that the first kind ("auto retained") is in fact *useful* and only the second kind ("auto restored") is the problem, and nobody I know 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 XenApp's "ICA Client Printer Configuration" utility, a great tool to provide users in combination with the policy to only auto-create their client default printer, and it's useful to allow them to be remembered and re-created in future sessions].

 

Jacques.



J.R. van Doornik Members
  • #17

J.R. van Doornik
  • 28 posts

Posted 07 December 2015 - 02:47 PM

Recently built 2 Windows 2008 machines (because we still have apps that are 32 bit, and can't handle the 64 bit environment at all), with XenApp 5 on there. Patched fully, and released for testing. One print policy was requested to add our default printer to the mix.

 

Now in some instances (and not always) certain users get shown a list of printers in the order of 150/200 items. I for one as an administrator do NOT get a list of printers. One other user sometimes gets it if he logs in as an administrator and sometimes when he logs in as a regular users. Tho it's known sometimes he gets just those printers he wants. Another application-administrator logs in as a regular user, and has also reported getting the dreaded flood of printers.

 

The list exists of (and this is just a highlight reel):

 

The standard printer we want to add to the system

Microsoft XPS Document Writer from rosborn (user does not exist on our network!)

Microsoft XPS Document Writer from cfritz (user does not exist on our network!)

Microsoft XPS Document Writer (from SAP_ALL-I04745) in session 23 (the server doesn't even HAVE 23 sessions running, nor is the client a known client on our network!)

Microsoft XPS Document Writer (from ) in session 72 (No 72 sessions active, and a printer from nowhere?)

Client/NSN-INTRA-RAGUGANE#/Microsoft XPS Document Writer (That client name is bogus. It does not exist on our network!)

lunxramyak (hell if I know what this is supposed to be)

lynxkavik (again, see above)

 

I've been informed that every now and then it also occurs on our XenApp 6.5 environment, but that's a lot less substantial. I have yet to verify that this actually happens. I know it happens on our XenApp 5.0 environment, which by now is some 2 months old if that, and is still being tested before being shifted into production.

 

Do note that our XenApp 5 environment is still running production on some Windows 2003 servers, which have never exhibited the problem. So policy-wise I'm not THAT keen to change things.

 

For now I've deleted all local printers on the server (which included the (by now hated) XPS printer), so the server can't get it from there anymore.

 

I also altered our print policy to delete all XPS printers, and all lynx* printers (which I hope will kill the majority of printers, tho I'm not sure the delete will work as advertised yet), and altered our default printer in the policy, to utilize the FQDN instead of just the servername, which may cure the 1106 and 4098 eventids the servers are tossing every now and then.

 

Biggest hassle with this is that we have certain users remotely that will jump on the server, rapidly go to their application, and hit print. Since the server is still enumerating / creating printers, it foregoes the creation of the users redirected printer, and the user doesn't get his print. Plus, having more than the required amount of printers is bound to cause confusion among the users.

 

If anyone has any insight in the cause (or even better, a solution!) I look forward to hearing it.



Jacques Bensimon Members
  • #18

Jacques Bensimon
  • 42 posts

Posted 07 December 2015 - 04:51 PM

In reply to J.R. van Doornik's question:

 

(1) The source of the issue lies on the client machines.  Deleting the key HKCU\Software\Citrix\PrinterProperties eliminates the creation of the unwanted printers in sessions running from that client (at the cost of losing any ICA client printer settings the user may have selected within sessions).  You can be more surgical in deleting specific subkeys of that key rather than the whole key, but that's a tedious endeavor.

 

(2)  If you don't use "Auto Retained Printers" in your environment (i.e. if you don't make the "ICA Client Printer Configuration" utility available to your users to select additional ICA printers beyond what your print policies auto-create), then the easiest solution is to enable the policy to disable all "Auto Retained AND Auto Restored" printers (the latter being the problematic "ghost printers").  If your version of XA doesn't have that policy, some of the previous entries in this thread discuss the use of the print flags Registry entry to achieve the same result.

 

Jacques.



J.R. van Doornik Members
  • #19

J.R. van Doornik
  • 28 posts

Posted 08 December 2015 - 09:15 AM

Thanks... I'll forward the registry key wipe on the clients to my two colleagues that have indicated having seen the problem. I'll leave the policy with the delete of printers in place too, for them to check if the problem isn't shown with that in place, and have the registry keys as a fallback if they so choose.

 

Still... I'm left with the feeling this might be a symptom remedy, and not a fix for the underlying problem. If nothing else I'm intrigued where the weird loginnames and devicenames are coming from.

 

I'm pretty sure they do not indicate a hack of sorts, seeing that some of the lynx-printernames were EXACTLY the same as in Jürgen Müllers blog, which leads me to believe it might be some sort of 'test setting' that Citrix hardcoded into the system to test stuff or something. That's all speculation tho. Plus, I wouldn't know why it would occur on some workstations and not on others, or sometimes it would show up, while other times it's non-existent.

 

Not like I can call Citrix, and ask around about XenApp5, when it's no longer supported.



Jacques Bensimon Members
  • #20

Jacques Bensimon
  • 42 posts

Posted 16 February 2016 - 04:43 PM

I'll tell you what:  I'm getting fed up with this problem, and with Citrix's silence on something that's existed since at least XA 5.0 (still seeing it consistently in XA 6.5 farms in multiple different environments), so I'm going to open up a case and pursue it.  For many of my clients, the option to disable "auto retained and auto restored printers" is not acceptable because they *like* auto-retained printers, as I do.  I wouldn't be so annoyed if there were separate policies to disable each one of these two types of "persistent" printers, but lumping them together into a single policy forces the issue to the foreground.

 

I'll update this thread if and when I get anywhere with Citrix.

 

Jacques.