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
  • Hi Did anyone get anywhere with this? I'm seeing the same issue and it looks like lots of people are having the same issue. Some users are on Win7 Some are Citrix / Terminal Server. Some have printer management software, Equitrac Follow you etc. Windows 2008 and Windows 2008 R2 seem to be the constant. There doesn't seem to be any official line from MS other than the old out of date KB article quoted above. Our environment is Citrix on 2003 printing using Equitrac using 2008 R2 print servers. Users have Citrix desktops, Win 7 devices but I have only seen the issue on a Citrix Desktop printing via a Citrix published app. I have not found a way to reproduce it yet. Has anyone got anywhere with this? I am concerned about the impact turning off Asynchronous RPC as we have no way of telling without making the change on the live systems. Any advice welcomed Thanks David
    Monday, August 17, 2015 11:37 AM
  • Nope... Problem still intermittantly pops up with us.

    Luckily the majority of misdirected printjobs are tossed under my administrative account and thus are never going to get out of the queue (which cleans up old prints after 72 hrs automagically). I'm guessing my administrative account is used since I was the one to install the software (under said account) and it kind of runs back home to mommy if it doesn't know what to do. Every once in a while a job still jumps users tho. But as the above already stated, it's intermittant, and almost impossible to replicate.

    I know of two users that get an XLS document, and try printing it, and running into the issue with my administrative account. Seems Excel is keeping some record of the printdata saved in the file itself too, which may interfere with the printing behavior, tho after applying the registry keys Microsoft has for preventing print informatuon to be saved in the XLS file, it seems it STILL has the problem intermittantly.

    Other than that I've seen it occur from Outlook, for which accessing the printer-settings, and just looking through all the tabs (including the one that identifies the user) seems to clear the issue up.

    Lastly I was informed that our ERP package also had the issue of dumping data to my administrative account, and the application-team informed me that this was likely due to using certain quick-keys to print and thus not going through the 'whole approved print dialog process'.

    All in all, I'm guessing there is a bug in 2008/2008R2. I'm unsure if the bug has replicated onward to 2012/2012R2, but I'm guessing if I want to be rid of it, I'm looking at a new installation of the printserver, and a printer-migration path to get 2008/2008R2 out of the printing path.

    By now I've gotten nearly to the point where I'm just accepting it manages to trip up every now and then.

    Monday, August 17, 2015 12:00 PM
  • Cheers Neko Unfortunately we use Equitrac and it's not supported on a 2012 cluster so might be stuck with 2008 for a while. It's not ideal if users are expecting "Secure Printing" I also wonder if it's in 2012 :-/ Can I ask what your environment is that displays the issue: Clients etc Win7 or Citrix / TS. I will investigate the application side a bit more to try and reproduce it. I'd love to know the impact not using AsRCP would be. I may have to go down this route. Thanks David
    Monday, August 17, 2015 3:14 PM
  • Citrix XenApp 6.5 (built on 2008R2 servers) with terminals mostly. Tho it also happens on FAT clients that are on either Windows 7 (rare that I've heard of it) or Windows 8.1 (I know one of my direct collegues has issues with that). 

    Still... Everything printed is pushed through the queue on the 2008 R2 printserver. All over the universal printerdriver that is on there.

    Monday, August 17, 2015 6:38 PM