From: [EMAIL PROTECTED] on behalf of joe
Sent: Sun 2006-08-27 23:46
To: [email protected]
Subject: RE: [ActiveDir] Printers & AD GUI
Oh no kidding Brian... I had never heard that about the
pruning... I hate to
ask this, but is there any documentation on that? That
would totally explain
some things various folks have asked me about DCs
spinning up dialup
connections at WAN sites every 8 hours...
joe
--
O'Reilly Active Directory Third Edition -
http://www.joeware.net/win/ad3e.htm
-----Original
Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]
On Behalf Of Brian Desmond
Sent: Sunday, August 27, 2006 2:25 PM
To:
[email protected]
Subject: RE: [ActiveDir] Printers & AD
GUI
Right. The computer is responsible for managing the print queue
objects.
Any changes you make on the print server are reflected on the
published
queue. Everytime the spooler service starts it confirms that the
queue
objects for published printers are all still in the
directory.
There is a thread that runs on every DC by default which
prunes printer
objects. It attempts to contact the print server every eight
hours and
if it can't after two intervals (8 hours by default) the printer
objects
get deleted. If you move the printers out from under the
computer
objects, then the pruning thread is the only way they will get
cleaned
up unless you do it yourself.
Thanks,
Brian
Desmond
[EMAIL PROTECTED]
c - 312.731.3132
>
-----Original Message-----
> From: [EMAIL PROTECTED] [mailto:ActiveDir-
> [EMAIL PROTECTED]
On Behalf Of joe
> Sent: Sunday, August 27, 2006 10:20 AM
> To:
[email protected]
> Subject: RE: [ActiveDir] Printers & AD
GUI
>
> Print Queue objects are created by default under the
computer on which
> the printers are shared from. It is, in fact, IMO, an
extremely
logical
> way of handling it since you don't have to worry
about delegating
> permissions to print admins, the computer itself can
create/delete
them
> as necessary. MSMQ Queues are handled the same way
as lots of objects,
> in my default R2 forest this is a list that can be
handled this way
>
> applicationVersion
> classStore
>
comConnectionPoint
> dSA
> indexServerCatalog
>
intellimirrorSCP
> ipsecFilter
> ipsecISAKMPPolicy
>
ipsecNegotiationPolicy
> ipsecNFA
> ipsecPolicy
>
msDFSR-LocalSettings
> msDS-App-Configuration
> msDS-AppData
>
msieee80211-Policy
> mSMQConfiguration
> mS-SQL-OLAPServer
>
mS-SQL-SQLServer
> nTFRSSubscriptions
> printQueue
>
remoteStorageServicePoint
> rpcGroup
> rpcProfile
>
rpcProfileElement
> rpcServer
> rpcServerElement
>
rRASAdministrationConnectionPoint
> serviceAdministrationPoint
>
serviceConnectionPoint
> serviceInstance
> storage
>
Volume
>
>
> As for why they are third class citizens in AD...
I expect it is
> because they are. I haven't done excessive investigation
into how
> printers are handled but I expect the print queue objects in AD
are
> simply reflections of the actual print queues on the servers. I
don't
> expect you actually manage anything in AD for them, you manage
them on
> the server/ws and then the print spooler updates any info it
wants in
> AD. Certainly you find them in AD but that just tells the
underlying
> software where to go look and the software goes to that print
queue
> directly on that server. I am pretty confident that if you delete
a
> print queue object in AD the print queue will work continue to
work
> fine on the server still, you just can't locate it via the
AD.
> Contrast that with users, groups, computers, and other objects
I
expect
> you consider first class citizens. If you delete those types
of
> objects, you will find they no longer work at all. :) You will
note
> that when you create a queue, you get the option to publish it to
the
> directory, it isn't mandatory, not required, it is simply an
option.
>
> joe
>
>
> -----Original
Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]
On Behalf Of
> [EMAIL PROTECTED]
> Sent: Sunday, August 27,
2006 10:44 AM
> To: [email protected]
> Subject:
[ActiveDir] Printers & AD GUI
>
> After 6 years of working with
AD I just realized that when you unshare
> a printer it becomes invisible
and unmanageable. I guess I always knew
> this in the back of my head, but
it never hit home until I tried
> cleaning up the printer list. Why
are printers third-class citizens
of
> AD, without a container or a OU
to their name? The only way to
> remotely manage unshared printers
is through the browse list, which is
> a pain.
> Am I missing
something? Are there other approaches to this? (no
> megabucks
solutions, please)
> List info : http://www.activedir.org/List.aspx
>
List FAQ : http://www.activedir.org/ListFAQ.aspx
>
List archive: http://www.activedir.org/ml/threads.aspx
>
>
List info : http://www.activedir.org/List.aspx
>
List FAQ : http://www.activedir.org/ListFAQ.aspx
>
List archive: http://www.activedir.org/ml/threads.aspx
List
info : http://www.activedir.org/List.aspx
List
FAQ : http://www.activedir.org/ListFAQ.aspx
List
archive: http://www.activedir.org/ml/threads.aspx
List
info : http://www.activedir.org/List.aspx
List
FAQ : http://www.activedir.org/ListFAQ.aspx
List
archive: http://www.activedir.org/ml/threads.aspx
This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you.
