I think you can target machines with unshared printers in the PMC. Thanks, Brian Desmond [EMAIL PROTECTED]
c - 312.731.3132 > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:ActiveDir- > [EMAIL PROTECTED] On Behalf Of Albert Duro > Sent: Monday, August 28, 2006 10:11 AM > To: ActiveDir@mail.activedir.org > Subject: Re: [ActiveDir] Printers & AD GUI > > I figured out where the disconnect is in this discussion. You see, I'm > the sole IT of a small org, barely over the SBS size, and I have to do > *everything*. I had overlooked the fact that those of you who are at > the top of a large IT pyramid have to leave the management of printers > to lower admins, techs, and even users. I can't do that. If an > unshared printer needs management, I have to either drill through the > browse list, or travel to the workstation and disrupt the user. > It would be just great if the AD printer list could make printers > shared but invisible (to all but the owner and Admin). Kinda like > Exchange mailboxes, which can still be used and managed even when > invisible. > Maybe the aforementioned Printer Management Console offers something > like that - I haven't checked it out yet. But surely this couldn't be > an unreasonable wish. > > ----- Original Message ----- > From: "joe" <[EMAIL PROTECTED]> > To: <ActiveDir@mail.activedir.org> > Sent: Sunday, August 27, 2006 8:47 PM > Subject: RE: [ActiveDir] Printers & AD GUI > > > > 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 > > > 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
