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
