none
Grant "Manage Documents" permissions to end users

    Question

  • Windows Server 2008 R2

    I'm having a hard time trying to grant some end users the ability to cancel print jobs on network printers.  I created a global security group called "PrintOps", and added the end users in it.  Then, I RDP'd into the print server, opened up the Print Management console > Print Servers > and right-clicked on PRINT01 (local).  Then, I clicked on Security, and added "PrintOps".  I granted the following: Print, Manage Printers, Manage Documents, and View Server.  Finally, a restarted the Print Spooler service, and had a end user try it.  On their Windows 7 SP1 workstations, they opened Devices and Printers, double-clicked the network printer, tried to Cancel the document in queue, but received "Access Denied".  

    After this happened, I went back to PRINT01, and looked at the printers' Security tab.  The "PrintOps" security group wasn't in there.  Therefore, I added to each printer the security group, and granted the following: Print, Manage documents, and Manage this printer.  I restarted the print spooler service on PRINT01, and then had an end user try again -- "Access Denied".  The end user has restarted the workstation, and has logged off/on.  

    Finally, I added "PrintOps" to the C:\WINDOWS\System32\spool\printers folder, and granted it Full Control.  This permission was inherited to all subfolders and files.  Again, I restarted the print spooler service, and had the end user try again.  Same result: "Access Denied".  

    Am I missing something here?

    Saturday, September 21, 2013 8:24 AM

Answers

  • I reconfirmed your configuration and set up a server the same way.  It works as it is supposed to.  If the jobs were added before you made the configuration changes, then I would think it would not work but any new job can be deleted by the Security groups users.  I'm using a domain security group. 

    And you have 2008R2 not 2008 SP2?  I don't recall when these changes got reverse engineered for Server 2008.


    Alan Morris Windows Printing Team

    Tuesday, October 01, 2013 11:05 PM

All replies

  • Odd.  I didn't get a response about this issue yet.  Can someone assist?
    Monday, September 23, 2013 5:36 PM
  • The Windows 7 machine should be using PrintManagement.msc to remotely manage the shares. 

    The users should delete any connection to the print server other than the ones they use to print, then reboot the client machine (or stop and restart spooler).

    You are setting this up correctly.  Although permissions to \spool\printers is not required.  I assume you have reviewed the TechNet article for this.

    http://technet.microsoft.com/en-us/library/jj190062.aspx


    Alan Morris Windows Printing Team


    Monday, September 23, 2013 6:38 PM
  • Thank you for your response, Alan Morris.

    I tried using the PrintManagement.msc console on the Windows 7 notebook, and I got the same "Access Denied" message under the end user's account. 

    I'm reviewing the TechNet article, but I don't see much difference in what I've done. 

    Could a certain type of Group Policy applied on the user level be causing this issue?

    Thursday, September 26, 2013 7:43 PM
  • There are no print specific group policies that impact the configuration.  My only thought is if the print server is also a domain controller where DCPROMO alters default security permissions.


    Alan Morris Windows Printing Team

    Friday, September 27, 2013 6:05 PM
  • I would validate with just one user account.  Once you get this working for one user, expand to the full security group. 

    Alan Morris Windows Printing Team

    Friday, September 27, 2013 6:07 PM
  • No, the print server is not a domain controller.
    Monday, September 30, 2013 12:43 AM
  • Yeah, even with just one user, it still doesn't work...

    I'm very confused as to why it isn't working...

    Monday, September 30, 2013 11:10 PM
  • I reconfirmed your configuration and set up a server the same way.  It works as it is supposed to.  If the jobs were added before you made the configuration changes, then I would think it would not work but any new job can be deleted by the Security groups users.  I'm using a domain security group. 

    And you have 2008R2 not 2008 SP2?  I don't recall when these changes got reverse engineered for Server 2008.


    Alan Morris Windows Printing Team

    Tuesday, October 01, 2013 11:05 PM
  • It's Windows Server 2008 R2.

    When I made this change, there were print jobs already in the print queue.  I didn't think it mattered, to be honest.  I haven't tried a sending a new print job and see if the user can cancel the document.  

    The security group I used was Global (not Domain Local, or Universal).  


    Thursday, October 03, 2013 11:40 PM
  • Send the next job. Then you can mark this thread as answered


    Alan Morris Windows Printing Team

    Thursday, October 03, 2013 11:53 PM
  • Sorry about not replying back.  I was able to confirm that the users were able to cancel "new" print jobs, but not "old" print jobs (before privilege was elevated). 

    Thank you for all your assistance, Alan Morris from the Windows Printing Team!

    Tuesday, October 15, 2013 1:33 PM
  • You are welcome.  It makes sense to me regarding the security permission on existing print jobs.  Thanks for closing down on the issue with the reply.

    Alan Morris Windows Printing Team

    Tuesday, October 15, 2013 7:33 PM