Inherited Permissions for Printers

[Paul Hadfield]

All,

I realise this is a printing question, but I think it's probably more GPO/AD
related too.

Is there any way that permissions for locally installed printers on a
Windows 2000 Advanced server can be set to inherit in the same way that
files and folders can? E.g. when someone creates a new local printer, I want
to be able to specify what the default security permissions will be set to.

We have a Windows 2000 domain with print queues set up locally on Windows
2000 Advanced Server member servers. I'm trying to set up our member servers
so that when a member of the domain security group "IT Helpdesk Staff"
creates a new local printer, the correct permissions are automatically
assigned to it and all the IT staff needs to do is add the relevant User
groups with print access.

The domain secirity group "IT Helpdesk Staff" has only domain user rights
but is also a member of the local Power Users group on the Windows 2000
member servers, and so has full permissions to create new printers locally.

Thanks again,
Paul.

 

[Chriss3 [MVP]]

Hello Paul,
Good question. Yes it's possible to inheritance the Security (ACL) from the
computer object in the Active Directory, since all printers published in
active directory is child objects to it's host/computer/server.

You can give the "IT Helpdesk Staff" Full Control of child objects of type
PrinterObjects or just Add / Remove Printer Objects. You should see an entry
for the Printer Operators group with rights Add / Remove Printer Objects in
the ACL list on the computer/host/server object in AD.

Have a look at this KB, How to view printers within the ADUC MMC.
http://support.microsoft.com/support/kb/articles/Q235/9/25.ASP

--
Regards
Christoffer Andersson
Microsoft MVP - Directory Services

No email replies please - reply in the newsgroup

 

[Herb Martin]

Hello Paul,
Good question. Yes it's possible to inheritance the Security (ACL) from the
computer object in the Active Directory, since all printers published in
active directory is child objects to it's host/computer/server.

I don't think so. The Printer's so published are not
"children" of the computer object for several reasons
but the most important is that Computer objects are
NOT containers.

Also note, the Computer object in AD will not get
you permissions to the actual PRINTER (queue)
anyway.

Also, since these are local printers they may not
even be published in AD.

You can give the "IT Helpdesk Staff" Full Control of child objects of type
PrinterObjects or just Add / Remove Printer Objects. You should see an entry
for the Printer Operators group with rights Add / Remove Printer Objects in
the ACL list on the computer/host/server object in AD.

Unless I am totally wrong about this, there is no
place to "inherit permissions" on the PRINTER
(queue) share objects themselves since they have
no parent.

I.E., you still won't be able to print.

A Restricted Group MIGHT help but the group
used will need to be one that is already assigned
by default, or there must be another way to give
this group the requisite permissions.

A startup script might wrap this stuff up by
enumerating Print shares etc.....

 

[Chriss3 [MVP]]

What I see this works, at least for Add/Remove Printers right. All objects
are possible containers from my view. Local printers are by default
published in the directory. Have you tried this solution?

--
Regards
Christoffer Andersson
Microsoft MVP - Directory Services

No email replies please - reply in the newsgroup
------------------------------------------------
http://www.chrisse.se - Active Directory Tips

Hello Paul,
Good question. Yes it's possible to inheritance the Security (ACL) from the
computer object in the Active Directory, since all printers published in
active directory is child objects to it's host/computer/server.

I don't think so. The Printer's so published are not
"children" of the computer object for several reasons
but the most important is that Computer objects are
NOT containers.

Also note, the Computer object in AD will not get
you permissions to the actual PRINTER (queue)
anyway.

Also, since these are local printers they may not
even be published in AD.

You can give the "IT Helpdesk Staff" Full Control of child objects of
type
PrinterObjects or just Add / Remove Printer Objects. You should see an entry
for the Printer Operators group with rights Add / Remove Printer Objects in
the ACL list on the computer/host/server object in AD.

Unless I am totally wrong about this, there is no
place to "inherit permissions" on the PRINTER
(queue) share objects themselves since they have
no parent.

I.E., you still won't be able to print.

A Restricted Group MIGHT help but the group
used will need to be one that is already assigned
by default, or there must be another way to give
this group the requisite permissions.

A startup script might wrap this stuff up by
enumerating Print shares etc.....

 

[Herb Martin]

What I see this works, at least for Add/Remove Printers right. All objects
are possible containers from my view. Local printers are by default
published in the directory. Have you tried this solution?

No, I was long under the impression that neither
users nor computer (accounts) were containers.

If fact, if this is correct, neither are groups. (They
are lists, i.e., that have a property which lists
other security principles.)

I am confused by what you say about "Add/remove
printers right" -- the AD object is NOT the same as
the Printer (queue) share.

Are you saying that having permissions on the Computer
object lets you add a Printer (in AD) under that Computer
hierarchically?

Are you saying that having permissions (somewhere)
would let you INSTALL/Create the printers on
computers and/or create a share from those printers
or otherwise manage the queue?

 

[Joe Richards [MVP]]

Computers, groups, and users are definitely container objects. See below, that
shows all of the objects that can be instantiated below the user, group, and
computer objects in my forest which is pretty standard.

ADUC by default shows users, groups, and computers as nodes instead of as
branches but you can override this by selecting view | Users, Groups, and
Computers as Containers.

Those objects just aren't normally considered containers by most people, this is
mostly propogated by the default ADUC view.

Any AD ACLs can be inherited to the sub objects of these objects just like in
any AD inheritence. Question would come down to what specific permissions are
needed and are they AD permissions on the Queue object or local server permissions.

joe




[Tue 01/11/2005 12:49:26.08]
F:\temp\delete>adfind -schema -f
"|(systemPossSuperiors=user)(possSuperiors=user)" -dn

AdFind V01.25.01cpp Joe Richards ([email protected]) December 2004

Using server: 2k3dc02.joe.com
Directory: Windows Server 2003
Base DN: CN=Schema,CN=Configuration,DC=joe,DC=com

dn:CN=NTFRS-Subscriptions,CN=Schema,CN=Configuration,DC=joe,DC=com
dn:CN=RID-Set,CN=Schema,CN=Configuration,DC=joe,DC=com
dn:CN=Class-Store,CN=Schema,CN=Configuration,DC=joe,DC=com

3 Objects returned


The command completed successfully.


[Tue 01/11/2005 12:49:36.90]
F:\temp\delete>adfind -schema -f
"|(systemPossSuperiors=computer)(possSuperiors=computer)" -dn

AdFind V01.25.01cpp Joe Richards ([email protected]) December 2004

Using server: 2k3dc02.joe.com
Directory: Windows Server 2003
Base DN: CN=Schema,CN=Configuration,DC=joe,DC=com

dn:CN=Service-Connection-Point,CN=Schema,CN=Configuration,DC=joe,DC=com
dn:CN=ms-Exch-Exchange-Admin-Service,CN=Schema,CN=Configuration,DC=joe,DC=com
dn:CN=ms-Exch-MDB,CN=Schema,CN=Configuration,DC=joe,DC=com
dn:CN=ms-Exch-MTA,CN=Schema,CN=Configuration,DC=joe,DC=com
dn:CN=ms-Exch-Protocol-Cfg-Shared,CN=Schema,CN=Configuration,DC=joe,DC=com
dn:CN=Intellimirror-SCP,CN=Schema,CN=Configuration,DC=joe,DC=com
dn:CN=Ipsec-Filter,CN=Schema,CN=Configuration,DC=joe,DC=com
dn:CN=Ipsec-ISAKMP-Policy,CN=Schema,CN=Configuration,DC=joe,DC=com
dn:CN=Ipsec-Negotiation-Policy,CN=Schema,CN=Configuration,DC=joe,DC=com
dn:CN=Ipsec-NFA,CN=Schema,CN=Configuration,DC=joe,DC=com
dn:CN=Ipsec-Policy,CN=Schema,CN=Configuration,DC=joe,DC=com
dn:CN=ms-Exch-Storage-Group,CN=Schema,CN=Configuration,DC=joe,DC=com
dn:CN=ms-DS-App-Configuration,CN=Schema,CN=Configuration,DC=joe,DC=com
dn:CN=ms-DS-App-Data,CN=Schema,CN=Configuration,DC=joe,DC=com
dn:CN=ms-ieee-80211-Policy,CN=Schema,CN=Configuration,DC=joe,DC=com
dn:CN=ms-Exch-Protocol-Cfg-Shared-Server,CN=Schema,CN=Configuration,DC=joe,DC=com
dn:CN=ms-Exch-RAS-Stack,CN=Schema,CN=Configuration,DC=joe,DC=com
dn:CN=DSA,CN=Schema,CN=Configuration,DC=joe,DC=com
dn:CN=ms-Exch-TP4-Stack,CN=Schema,CN=Configuration,DC=joe,DC=com
dn:CN=ms-Exch-Transport-Stack,CN=Schema,CN=Configuration,DC=joe,DC=com
dn:CN=MSMQ-Configuration,CN=Schema,CN=Configuration,DC=joe,DC=com
dn:CN=ms-Exch-X25-Stack,CN=Schema,CN=Configuration,DC=joe,DC=com
dn:CN=ms-Exch-Private-MDB,CN=Schema,CN=Configuration,DC=joe,DC=com
dn:CN=ms-Exch-Local-DXA,CN=Schema,CN=Configuration,DC=joe,DC=com
dn:CN=NTFRS-Subscriptions,CN=Schema,CN=Configuration,DC=joe,DC=com
dn:CN=ms-Exch-Public-MDB,CN=Schema,CN=Configuration,DC=joe,DC=com
dn:CN=Print-Queue,CN=Schema,CN=Configuration,DC=joe,DC=com
dn:CN=Application-Process,CN=Schema,CN=Configuration,DC=joe,DC=com
dn:CN=Remote-Storage-Service-Point,CN=Schema,CN=Configuration,DC=joe,DC=com
dn:CN=Application-Version,CN=Schema,CN=Configuration,DC=joe,DC=com
dn:CN=RID-Set,CN=Schema,CN=Configuration,DC=joe,DC=com
dn:CN=Class-Store,CN=Schema,CN=Configuration,DC=joe,DC=com
dn:CN=Connection-Point,CN=Schema,CN=Configuration,DC=joe,DC=com
dn:CN=RRAS-Administration-Connection-Point,CN=Schema,CN=Configuration,DC=joe,DC=com
dn:CN=Service-Administration-Point,CN=Schema,CN=Configuration,DC=joe,DC=com

35 Objects returned


The command completed successfully.


[Tue 01/11/2005 12:49:49.99]
[Tue 01/11/2005 12:51:03.97]
F:\temp\delete>adfind -schema -f
"|(systemPossSuperiors=group)(possSuperiors=group)" -dn

AdFind V01.25.01cpp Joe Richards ([email protected]) December 2004

Using server: 2k3dc02.joe.com
Directory: Windows Server 2003
Base DN: CN=Schema,CN=Configuration,DC=joe,DC=com

dn:CN=Class-Store,CN=Schema,CN=Configuration,DC=joe,DC=com

1 Objects returned


The command completed successfully.


[Tue 01/11/2005 12:51:30.56]
F:\temp\delete>

 

[Chriss3 [MVP]]

Hey Joe.

I have a comment for "Any AD ACL's can be inherited to the sub objects of
these objects just like in any AD inheritance"

Exchange doesn't follow the guidelines for permission and inheritance. Some
Permissions must be added at the exactly right level to have inheritance
effect else it will be ignored, even if the right are assigned explicit to
the object it self.

--
Regards
Christoffer Andersson
Microsoft MVP - Directory Services

No email replies please - reply in the newsgroup
------------------------------------------------
http://www.chrisse.se - Active Directory Tips

Computers, groups, and users are definitely container objects. See below,
that shows all of the objects that can be instantiated below the user,
group, and computer objects in my forest which is pretty standard.

ADUC by default shows users, groups, and computers as nodes instead of as
branches but you can override this by selecting view | Users, Groups, and
Computers as Containers.

Those objects just aren't normally considered containers by most people,
this is mostly propogated by the default ADUC view.

Any AD ACLs can be inherited to the sub objects of these objects just like
in any AD inheritence. Question would come down to what specific
permissions are needed and are they AD permissions on the Queue object or
local server permissions.

joe




[Tue 01/11/2005 12:49:26.08]
F:\temp\delete>adfind -schema -f
"|(systemPossSuperiors=user)(possSuperiors=user)" -dn

AdFind V01.25.01cpp Joe Richards ([email protected]) December 2004

Using server: 2k3dc02.joe.com
Directory: Windows Server 2003
Base DN: CN=Schema,CN=Configuration,DC=joe,DC=com

dn:CN=NTFRS-Subscriptions,CN=Schema,CN=Configuration,DC=joe,DC=com
dn:CN=RID-Set,CN=Schema,CN=Configuration,DC=joe,DC=com
dn:CN=Class-Store,CN=Schema,CN=Configuration,DC=joe,DC=com

3 Objects returned


The command completed successfully.


[Tue 01/11/2005 12:49:36.90]
F:\temp\delete>adfind -schema -f
"|(systemPossSuperiors=computer)(possSuperiors=computer)" -dn

AdFind V01.25.01cpp Joe Richards ([email protected]) December 2004

Using server: 2k3dc02.joe.com
Directory: Windows Server 2003
Base DN: CN=Schema,CN=Configuration,DC=joe,DC=com

dn:CN=Service-Connection-Point,CN=Schema,CN=Configuration,DC=joe,DC=com
dn:CN=ms-Exch-Exchange-Admin-Service,CN=Schema,CN=Configuration,DC=joe,DC=com
dn:CN=ms-Exch-MDB,CN=Schema,CN=Configuration,DC=joe,DC=com
dn:CN=ms-Exch-MTA,CN=Schema,CN=Configuration,DC=joe,DC=com
dn:CN=ms-Exch-Protocol-Cfg-Shared,CN=Schema,CN=Configuration,DC=joe,DC=com
dn:CN=Intellimirror-SCP,CN=Schema,CN=Configuration,DC=joe,DC=com
dn:CN=Ipsec-Filter,CN=Schema,CN=Configuration,DC=joe,DC=com
dn:CN=Ipsec-ISAKMP-Policy,CN=Schema,CN=Configuration,DC=joe,DC=com
dn:CN=Ipsec-Negotiation-Policy,CN=Schema,CN=Configuration,DC=joe,DC=com
dn:CN=Ipsec-NFA,CN=Schema,CN=Configuration,DC=joe,DC=com
dn:CN=Ipsec-Policy,CN=Schema,CN=Configuration,DC=joe,DC=com
dn:CN=ms-Exch-Storage-Group,CN=Schema,CN=Configuration,DC=joe,DC=com
dn:CN=ms-DS-App-Configuration,CN=Schema,CN=Configuration,DC=joe,DC=com
dn:CN=ms-DS-App-Data,CN=Schema,CN=Configuration,DC=joe,DC=com
dn:CN=ms-ieee-80211-Policy,CN=Schema,CN=Configuration,DC=joe,DC=com
dn:CN=ms-Exch-Protocol-Cfg-Shared-Server,CN=Schema,CN=Configuration,DC=joe,DC=com
dn:CN=ms-Exch-RAS-Stack,CN=Schema,CN=Configuration,DC=joe,DC=com
dn:CN=DSA,CN=Schema,CN=Configuration,DC=joe,DC=com
dn:CN=ms-Exch-TP4-Stack,CN=Schema,CN=Configuration,DC=joe,DC=com
dn:CN=ms-Exch-Transport-Stack,CN=Schema,CN=Configuration,DC=joe,DC=com
dn:CN=MSMQ-Configuration,CN=Schema,CN=Configuration,DC=joe,DC=com
dn:CN=ms-Exch-X25-Stack,CN=Schema,CN=Configuration,DC=joe,DC=com
dn:CN=ms-Exch-Private-MDB,CN=Schema,CN=Configuration,DC=joe,DC=com
dn:CN=ms-Exch-Local-DXA,CN=Schema,CN=Configuration,DC=joe,DC=com
dn:CN=NTFRS-Subscriptions,CN=Schema,CN=Configuration,DC=joe,DC=com
dn:CN=ms-Exch-Public-MDB,CN=Schema,CN=Configuration,DC=joe,DC=com
dn:CN=Print-Queue,CN=Schema,CN=Configuration,DC=joe,DC=com
dn:CN=Application-Process,CN=Schema,CN=Configuration,DC=joe,DC=com
dn:CN=Remote-Storage-Service-Point,CN=Schema,CN=Configuration,DC=joe,DC=com
dn:CN=Application-Version,CN=Schema,CN=Configuration,DC=joe,DC=com
dn:CN=RID-Set,CN=Schema,CN=Configuration,DC=joe,DC=com
dn:CN=Class-Store,CN=Schema,CN=Configuration,DC=joe,DC=com
dn:CN=Connection-Point,CN=Schema,CN=Configuration,DC=joe,DC=com
dn:CN=RRAS-Administration-Connection-Point,CN=Schema,CN=Configuration,DC=joe,DC=com
dn:CN=Service-Administration-Point,CN=Schema,CN=Configuration,DC=joe,DC=com

35 Objects returned


The command completed successfully.


[Tue 01/11/2005 12:49:49.99]
[Tue 01/11/2005 12:51:03.97]
F:\temp\delete>adfind -schema -f
"|(systemPossSuperiors=group)(possSuperiors=group)" -dn

AdFind V01.25.01cpp Joe Richards ([email protected]) December 2004

Using server: 2k3dc02.joe.com
Directory: Windows Server 2003
Base DN: CN=Schema,CN=Configuration,DC=joe,DC=com

dn:CN=Class-Store,CN=Schema,CN=Configuration,DC=joe,DC=com

1 Objects returned


The command completed successfully.


[Tue 01/11/2005 12:51:30.56]
F:\temp\delete>


--
Joe Richards Microsoft MVP Windows Server Directory Services
www.joeware.net

No, I was long under the impression that neither
users nor computer (accounts) were containers.

If fact, if this is correct, neither are groups. (They
are lists, i.e., that have a property which lists
other security principles.)

I am confused by what you say about "Add/remove
printers right" -- the AD object is NOT the same as
the Printer (queue) share.

Are you saying that having permissions on the Computer
object lets you add a Printer (in AD) under that Computer
hierarchically?

Are you saying that having permissions (somewhere)
would let you INSTALL/Create the printers on
computers and/or create a share from those printers
or otherwise manage the queue?

 

[Herb Martin]

Computers, groups, and users are definitely container objects. See below, that
shows all of the objects that can be instantiated below the user, group, and
computer objects in my forest which is pretty standard.

Well, then Chris and you haved taught me
something since I firmly believed that all
of the security principles were Leaf Objects
and not containers.

ADUC by default shows users, groups, and computers as nodes instead of as
branches but you can override this by selecting view | Users, Groups, and
Computers as Containers.
Interesting.

Those objects just aren't normally considered containers by most people, this is
mostly propogated by the default ADUC view.

Ok, but I really believed they were somehow marked
as Leaf Objects.

Any AD ACLs can be inherited to the sub objects of these objects just like in
any AD inheritence.

Sure, if they are true containers then this would
be expected.

Question would come down to what specific permissions are
needed and are they AD permissions on the Queue object or local server

permissions.

Now, if you guys are telling me that this somehow
affects the PRINTERS (the QUEUES) on the computers
I am really going to be shocked.

 

[Joe Richards [MVP]]

I don't think I follow what you mean Chris, could you expand on this?

For specific AD permissioning on Exchange objects, Exchange has no choice but to
follow the permissioning, however if Exchange is doing its own processing of
permissions concerning functionality internal to Exchange, that it can do. But
this is the same as the question about the whether the AD Permissions affecting
the queue itself on the server versus just the AD Queue object. If there is
something on the server checking the AD perms the AD perms would have whatever
impact that sever process specified, if not there would be no linking.

But again, I am not completely clear about what you are saying and a specific
example would be great.

joe

 

[Chriss3 [MVP]]

Shared Resources, such the printer queues or shared folders permission are
not related to shared folder or printer objects in Active Directory, if you
not want to, by reading SecurityDesscriptors from AD and apply them to the
permission of the shared resource. Adding/Removing Printers in the directory
can be delegated as the way I described. I was not clear and should pointed
the solution of using the permission of the printer object in AD to the
resource are not an easy task. You can use restricted groups and put the "IT
Helpdesk Staff" into the Printer Operators group.

The multivalued attribute possibleInferiors holds the object classes that
can be possible child objects of an object class. I have once put the
printer as a child objects to users. then I can create printer objects as
child object of user accounts. You get some problem with port mapping I
think, but it works.

--
Regards
Christoffer Andersson
Microsoft MVP - Directory Services

No email replies please - reply in the newsgroup

 

[ptwilliams]

I too am very intrigued by this thread, but didn't quite grasp that last
post. Can you try that again please?

Cheers!

--

Paul Williams

http://www.msresource.net/
http://forums.msresource.net/

Shared Resources, such the printer queues or shared folders permission are
not related to shared folder or printer objects in Active Directory, if you
not want to, by reading SecurityDesscriptors from AD and apply them to the
permission of the shared resource. Adding/Removing Printers in the directory
can be delegated as the way I described. I was not clear and should pointed
the solution of using the permission of the printer object in AD to the
resource are not an easy task. You can use restricted groups and put the "IT
Helpdesk Staff" into the Printer Operators group.

The multivalued attribute possibleInferiors holds the object classes that
can be possible child objects of an object class. I have once put the
printer as a child objects to users. then I can create printer objects as
child object of user accounts. You get some problem with port mapping I
think, but it works.

--
Regards
Christoffer Andersson
Microsoft MVP - Directory Services

No email replies please - reply in the newsgroup

 

[Paul Hadfield]

All,

As Herb has pointed out (and I should have mentioned in the first place) the
printer queues on the Windows 2000 member server in question are not
published in active directory. Neither are they shared. They are accessed
purely by the users that happen to be logged on to that local server at the
time via Terminal Services.

At the moment, when a member of IT Helpdesk Staff creates a new printer
queue, the default security permissions are:
Administrators = FC
Creator Owner = Manage Docs
Everyone = Print
Power Users = FC

I'm basically looking for an easy way to remove both the Creator Owner and
Everyone groups so that a newly created print queue will only have the
Administrators and PowerUsers group in the security permissions.

This way when new print queues are created and the permissions have been
'forgotten' about, no users will be able to print and someone will have to
call the IT HelpDesk to have this resolved - as opposed to Everyone being
able to use the printer and then jobs from Glasgow appearing on printers in
London for example. (Not that I am at all implying that members of the IT
HelpDesk Staff group have short term memory issues...)

Thanks again,
Paul.

Hello Paul,
Good question. Yes it's possible to inheritance the Security (ACL) from the
computer object in the Active Directory, since all printers published in
active directory is child objects to it's host/computer/server.

I don't think so. The Printer's so published are not
"children" of the computer object for several reasons
but the most important is that Computer objects are
NOT containers.

Also note, the Computer object in AD will not get
you permissions to the actual PRINTER (queue)
anyway.

Also, since these are local printers they may not
even be published in AD.

You can give the "IT Helpdesk Staff" Full Control of child objects of
type
PrinterObjects or just Add / Remove Printer Objects. You should see an entry
for the Printer Operators group with rights Add / Remove Printer Objects in
the ACL list on the computer/host/server object in AD.

Unless I am totally wrong about this, there is no
place to "inherit permissions" on the PRINTER
(queue) share objects themselves since they have
no parent.

I.E., you still won't be able to print.

A Restricted Group MIGHT help but the group
used will need to be one that is already assigned
by default, or there must be another way to give
this group the requisite permissions.

A startup script might wrap this stuff up by
enumerating Print shares etc.....

 

[Joe Richards [MVP]]

I don't think you can modify the default queue perms like that. You should
probably look into possibly scripting the queue installations or at least set up
a script for checking/setting permissions that maybe runs nightly or hourly on
the servers.

 

[Herb Martin]

All,

As Herb has pointed out (and I should have mentioned in the first place) the
printer queues on the Windows 2000 member server in question are not
published in active directory. Neither are they shared. They are accessed
purely by the users that happen to be logged on to that local server at the
time via Terminal Services.

At the moment, when a member of IT Helpdesk Staff creates a new printer
queue, the default security permissions are:
Administrators = FC
Creator Owner = Manage Docs
Everyone = Print
Power Users = FC

I'm basically looking for an easy way to remove both the Creator Owner and
Everyone groups so that a newly created print queue will only have the
Administrators and PowerUsers group in the security permissions.

On it's face removing Creator/Owner sounds silly
and the creator owner can ALWAYS change the
permissions on an owned object even with no other
(or even DENY all) permissions.

Changing the Everyone group defaults sounds like
a useful goal.

How about a Startup script that just enumerates and
fixes up the permissions on any print queues?

This way when new print queues are created and the permissions have been
'forgotten' about, no users will be able to print and someone will have to
call the IT HelpDesk to have this resolved -

Maybe best is to make the Users members of USERS
instead of Power Users (or <ugh> Administrators)
or just remove the ability to create printers from
Power Users.

Then they have to cal the Help Desk to start.

as opposed to Everyone being
able to use the printer and then jobs from Glasgow appearing on printers in
London for example. (Not that I am at all implying that members of the IT
HelpDesk Staff group have short term memory issues...)

Or just teach users not to share (or use permissions
correctly...)

 

[Paul Hadfield]

"How about a Startup script that just enumerates and fixes up the
permissions on any print queues?"


I'm not sure how I would go about writing a script to do this - can you give
me any pointers? My primary goal is to remove the Everyone group from all
print queues and this seems to be the best idea so far.

Cheers,
Paul.

 

[Herb Martin]

"How about a Startup script that just enumerates and fixes up the
permissions on any print queues?"


I'm not sure how I would go about writing a script to do this - can you give
me any pointers? My primary goal is to remove the Everyone group from all
print queues and this seems to be the best idea so far.

If you don't already write a few scripts this would
be a big "chunk" to learn all at once, and unfortunately
the commands available natively (and flexibility) varies
by OS version/type.

Naively (it's not perfect) you can get a list of Print shares this way:

net share | find "Spooled"

On XP+ you can use PrnMngr to do (some of the) work.

Using things like VBS/WMI/ADSI you can do this stuff.

SetAcl.exe free from SourceForge.net can do it, but it has
a really complex command line.

Someone who does this everyday might have a pre-built
suggestion -- I would have to write something and much
of that would depend on which clients and server OS's
you have.

 

[Paul Hadfield]

Thanks for this - I'm not sure that the NET command will help me as the
local printer queues are not shared.

I've had a quick look at the SetACL program on SourceForge and that look
like it might be the easiest solution. Only problem is that is is an .ocx
not an .exe that can be run at the command line (as far as I can see after a
quick 60 second look at it that is). Maybe I'll have to blow the dust of VB6
and write a small utility to interface with it.

Thanks again for you input,
Paul.

 

[Herb Martin]

Thanks for this - I'm not sure that the NET command will help me as the
local printer queues are not shared.

Does not matter -- we were talking about doing this
in the context of a Startup script which runs locally
on each machine.

I've had a quick look at the SetACL program on SourceForge and that look
like it might be the easiest solution. Only problem is that is is an .ocx
not an .exe that can be run at the command line (as far as I can see after a
quick 60 second look at it that is).

There is also an exe. They split it for script (language)
purposes) to make it more flexible.

Maybe I'll have to blow the dust of VB6
and write a small utility to interface with it.

You can do that or just use straight batch with
the exe version.