none
Windows Server 2008 R2 Print Server Job Owner Issue

    Question

  • At the start of the year we rebuilt our server infrastructure from Windows Server 2003 R2 (Enterprise) to Windows Server 2008 R2 (Enterprise). Since then we've had a sporradic/rare unusual issue occur with our Print Server.

     

    Our Print Server is setup fairly simply, it's a standard Windows Server 2008 R2 Print Server, it has print drivers (64-bit) for our Xerox ApeosPort IV 5570 machines, and it runs Equitrac Office 4.2 for printer authentication and follow me printing. The servers that the users are printing from are Windows Server 2008 R2 Terminal Servers (2 in a Farm).

     

    The issue we encountered first was that in rare instances users printing and picking up jobs from their Follow-Me print bins on the printer would find that a job would be missing. Another user would come along and do some printing of their own and find the missing job in their own Follow-Me print bin instead.

     

    We originally thought that this was an Equitrac issue and worked closely with our printer support reps in an attempt to find the issue and fix it, but after many logs and months back and forth between Equitrac, our print support reps and ourselves we found that the issue wasn't with Equitrac but seemingly from the Windows Print Server itself.

     

    What we found was that in rare instances (Unfortunately it's rare and I haven't been able to replicate it on demand yet) when a user prints a job, the event log for the print server actually shows that the owner of the job was the LAST user that printed to that print server, not the current user.

     

    Our printer support reps found us an article which seemed to fit our scenario perfectly, but the article is only for Vista SP1 and Windows Server 2008 (Not R2). When we download and try to apply the hotfix (On the off chance that it might fix the issue) it comes up with an error stating that the hotfix is not applicable to this operating system (As expected).

     

    The article referenced above is: http://support.microsoft.com/kb/958741

     

    What we're both wondering now (Myself and our printer support reps) is that if this issue has potentially resurfaced in Windows Server 2008 R2 (Being that the article fits the scenario and symptoms perfectly) but has yet to be fixed, could someone assist us to solve this issue?



    Wednesday, August 17, 2011 8:22 PM

Answers

  • Hi,

     

    Please first make sure the Windows Server 2008 R2 is up to date with the latest security patches and Service Pack.

     

    If the problem continues, I suggest you disable Asynchronous RPC on the Terminal Server by adding the following registry entry:

     

    1.    In Registry Editor, locate the following subkey:

    HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows NT\Printers\

     

    2.    Right-click Printers, point to New, and then click DWORD.

    3.    Type EnabledProtocols.

    4.    Double click EnabledProtocols.

    5.    In the Value data box, type 6.

    6.    Close Registry Editor.

    7.    Restart the Spooler.

     

    Retest the problem.

     

    Hope this helps.

     

    Regards,

     

    Bruce

    Forum Support

    Please remember to mark the replies as answers if they help and unmark them if they provide no help. If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

     


    • Marked as answer by Bruce-Liu Wednesday, September 07, 2011 8:21 AM
    Friday, August 19, 2011 7:22 AM

All replies

  • Hi,

     

    Please first make sure the Windows Server 2008 R2 is up to date with the latest security patches and Service Pack.

     

    If the problem continues, I suggest you disable Asynchronous RPC on the Terminal Server by adding the following registry entry:

     

    1.    In Registry Editor, locate the following subkey:

    HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows NT\Printers\

     

    2.    Right-click Printers, point to New, and then click DWORD.

    3.    Type EnabledProtocols.

    4.    Double click EnabledProtocols.

    5.    In the Value data box, type 6.

    6.    Close Registry Editor.

    7.    Restart the Spooler.

     

    Retest the problem.

     

    Hope this helps.

     

    Regards,

     

    Bruce

    Forum Support

    Please remember to mark the replies as answers if they help and unmark them if they provide no help. If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

     


    • Marked as answer by Bruce-Liu Wednesday, September 07, 2011 8:21 AM
    Friday, August 19, 2011 7:22 AM
  • Hi Bruce,

    I've just put the registry keys into both Terminal Servers and restarted the spooler.

    I'll give it some time and see if the issue returns (I'm not able to reproduce this consistently as of yet).

    Will let you know how it goes.

     

    Sunday, August 21, 2011 11:11 PM
  • Hi,

     

    If there is any update on the problem, please feel free to let us know.

     

    Regards,

    Bruce

    Tuesday, August 23, 2011 10:28 AM
  • We had the same Problem with Pcounter. Pcounter ist a follow me printing solution. Nearly the same like Equitrac. Sometimes users got the printjobs from other owners. We also cannot reproduce it. I will tell our costumer from your solution and hope that it would be helpfull. Regards Stefan
    • Edited by Purdy15 Monday, January 09, 2012 7:37 AM
    Monday, January 09, 2012 7:32 AM
  • We had the same problem with SafeCom, also a follow-me solution. Reproduction is hard, we're trying this solution right now...

    Thanks, Leon

    Tuesday, January 17, 2012 10:32 AM
  • Hi Nice One,

    we have the same problem with an other FollowMe-Solution (Imagus from GeniusBytes).

    Does the solution from bruce works?

     

    Greetings, Maik

    Thursday, February 02, 2012 11:10 AM
  • UNIflow (NT-Ware) is also affected by this bug, our customer is really good at reproducing the problem but has not seen it since we added this option to the registry. We also suspect this bug is causing a similair issue with PDF995.

    Best regards,

    Marcel de Haas
    ApplicationNet BV, The Netherlands. 

    Thursday, February 02, 2012 9:02 PM
  • Hi

    Is this solution only for Terminal Server environment?

    Can you apply this on a "normal" printserver running 2008 R2 in a domain.

    We are having the same problem with a uniFlow installation.

    Regards

    /Lars-Gunnar

    Wednesday, April 04, 2012 7:56 AM
  • Hi Folks,

    Just to let you know we've been running with the solution provided since it was posted and we haven't had a occurrence of the issue since, so it's definitely fixed the issue for us.

    Whether or not this will work for your scenario Larlofve I'm not sure, as ours seemed to be related to multiple users on the same machine (Terminal Server), however Marcel who posted just before you mentioned their customer was running Uniflow as well and this fix also seems to have corrected the issue for them.

    Best bet would be to give it a try and see if the issue disappears for you or not, if it doesn't or something happens then at least it's relatively easy to reverse.

    Cheers,

    Wednesday, April 04, 2012 8:07 PM
  • I too have seen the wrong user name associated with Print Server events. For example: http://social.technet.microsoft.com/Forums/en-US/winserverprint/thread/33a7eccb-8600-485f-8045-ede078035c39

    Monday, April 09, 2012 6:44 PM
  • Hi Bruce,

    We are encountering the same problem with a uniFlow installation, so as you said to update the latest security patch, can you provide me the exactly patch number to fix this known issue?

    Thanks and Regards,

    Nick

    Thursday, December 20, 2012 12:00 PM
  • Hi,

    I noticed that the kb articel (kb958741) has been changed.

    The registry key mentioned before has been replaced by a hotfix.

    What is, in this case, the best thing to do? Use the registry setting or install the fix?

    Is it wise to apply the registry key even if I don't have the problem yet when I'am going to install a follow me print application?

    Thanks and regards,

    Jeroen

    Thursday, February 14, 2013 9:58 AM
  • Hi

    I am having the same problem at a XenApp 6.5 installation using UniFlow

    I have 5 XenApp 6.5 servers, Windows Server 2008 R2.

    My print server is a Windows Server 2008 R2.

    Do I need to at the registry change on the Citrix/Terminal servers or at the Print server?! I have tried the Print server and restarted the printspooler and everything was gone. All printers was gone, had to remove the registry again and restart the spooler to get them back.

    I really need some help with this so I hope you guys could answer my question.

    Thanks In Advance

    Christian Carlsen

    Monday, March 25, 2013 8:36 PM
  • Hi Christian,

    The registry update mentioned should only need to be applied to the Terminal Server, not the print server itself.

    We haven't used the hotfix yet ourselves, we're still running on the registry fix and everything has been working great since.

    Cheers,

    Tuesday, March 26, 2013 8:57 PM
  • Hi Nice One1

    Thanks alot for the answer, I will try making the registry settings for my citrix servers and restart the spooler then to test the next week. I will post my result in a week or two.

    Cheers

    Christian

    Friday, May 03, 2013 8:49 AM
  • Thanks alot Nice One1..

    Your solution did the job for me :-)

    Cheers

    Monday, June 10, 2013 9:51 AM
  • Hi,

    we got into this issue, too.

    Disabling RPCTCP and switching to enabledprotocols=6 solved the problem on 2008 R2 with the wrong print job owner.

    But switching to enabledprotocols decreases printing speed for SAP, Adobe Reader, ... users have to wait until the printjob is done (over WAN) and the applications seems to hang. For example, SAP Hardcopy without registry key < 1 sec, with enabledprotocols=6 >= 30sec to 90sec.

    Any more hints for this?

    Regards.

    Monday, July 22, 2013 11:22 AM
  • Using a XenApp 6.5 environment on Windows 2008 R2, using PCounter software for FollowMe printing has shown this issue to us as well.

    I've managed to find a specific application (which is old as heck) that consistantly prints as a wrong user. Even worse, in all cases it seems it sticks to my administrative account, even if the user using the application is not logged in as my administrative user. Even when I'm not administratively logged into the desktop of the XenApp server, the printjob seems to be tossed out as my administrative user. As a result the user doesn't see his/her printjobs, and worse, some potentially confidential printjobs have the possibility to end up with wrong users.

    The above registry fix was tried by me by letting the user login to the XenApp machine, try a test print (which listed the wrong user), then implement the registry key, restarting the spooler (which also restarted the Citrix print spooler component), and retrying the printing from the app. Unfortunatly this again went under the wrong name. I rolled the change back just to prevent any occurrance of the reply on July 22nd 2013, indicating a slowdown in printing performance.

    Microsoft seems to be unaware of the problem having resurfaced in 2008 R2, and are asking me to pay for a support ticket in order to accept the submission there might be a bug in their software.As it stands I'm still going to see if our printer supplyer (Toshiba) can provide a bit of leverage towards Microsoft to investigate this, otherwise it may well come down to forking over cash to get this thing sorted.

    Tuesday, November 12, 2013 10:27 AM