But if a printer is not shared out to the network, is it a network device? It can only be used on the local machine.
Do you want every local printer on every single machine in a company showing up in the directory? Consider a large multinational with hundreds of thousands of desktops and thousands with local printers that aren't shared. Then you want a printer with a certain capability in a certain site and you look and find one in the directory but it isn't actually shared out. You try to print to it, you can't. You call IT. They look into it and chase it to an exec who is like piss off. :) You tell the person they can't use it and they get snotty because everyone is better and more important than IT. :) Horrible escalations. :) You could always create your own printqueue objects for your non-shared printers. It sounds like they would get zilched back out of the directory from the process Brian mentioned unless you disable the pruning. The other issue would be the manadatory attribute for the share name but you could give it would be if it were shared. I don't know what this would buy except that you can see them when browsing AD. -- O'Reilly Active Directory Third Edition - http://www.joeware.net/win/ad3e.htm -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Albert Duro Sent: Sunday, August 27, 2006 10:24 PM To: ActiveDir@mail.activedir.org Subject: Re: [ActiveDir] Printers & AD GUI >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 of course, but ONLY if you share them. As soon as you stop sharing them, POOF both you and Brian essentially said that yeah printers are not full AD objects, and that's the way it is. But wasn't the promise of AD to bring ALL network objects (in the prosaic sense) into the manageability fold? There's no question that AD is vastly improved over NT as far as printers go, but I'd like to see the promise fulfilled. ----- Original Message ----- From: "joe" <[EMAIL PROTECTED]> To: <ActiveDir@mail.activedir.org> Sent: Sunday, August 27, 2006 8:20 AM 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
