Its explained pretty decently if you go in the GPO Editor, Computer Config/Admin Templates/Printers.
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 4:46 PM > To: ActiveDir@mail.activedir.org > 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: ActiveDir@mail.activedir.org > 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: ActiveDir@mail.activedir.org > > 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: ActiveDir@mail.activedir.org > > 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 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
