Yeah the feature is SBS only but now the R2 printer widget does the same thing, basically.
Thanks, Brian Desmond [EMAIL PROTECTED] c - 312.731.3132 > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:ActiveDir- > [EMAIL PROTECTED] On Behalf Of Grillenmeier, Guido > Sent: Monday, August 28, 2006 4:41 AM > To: [email protected] > Subject: RE: [ActiveDir] Printers & AD GUI > > > I forget if this is unique to SBS's AD setup or what..... but any > > network attached printer will automatically get attached to each > > workstation that is set up with the /connectcomputer wizard > > I'm pretty sure this is unique to SBS - at least I would hope - nothing > like adding thousands of printer queues automatically to each > workstation :) > > However, while we're discussing printer topics, it may be worth to > point out that Win2003 R2 has added a nice feature to automatically > distribute printer queues to computers via GPO. This is certainly > useful for branchoffices to auto-deploy specific shared printers to all > machines in a branch office site (incl. traveling users...) > > This features is integrated with R2's Print Mgmt Console (PMC). It > attaches printer queue information to an existing GP object: > CN=PushedPrinterConnections underneath > CN=System,CN=Policies,CN={GPO},CN=Machine or > CN=System,CN=Policies,CN={GPO},CN=User (you will see a new node in the > GP editor called "Deployed Printers" on the R2 machine where the PMC is > installed). Your AD schema needs to have been updated to the R2 schema. > PMC is also installed automatically on any Longhorn Server to which you > add the Print Server role. > > Note that the printer connections listed in the GPO are not added to > the clients by magic just because the GPO applies to them. For Windows > XP (and Windows Server 2003) clients, you have to run a specific > machine startup script or user logon script (pushprinterconnections.exe > from > %WinDir%\PMCSnap) in the GPO. If you deploy to users, they must have > the rights to install printers... Vista (and LH server) do not require > the use of a script, as they have the logic to push the printer > connections built in. Afaik, there is no support to push the queues to > Win2000 clients. > > Naturally, it has been possible for years to push printer queues to > clients via scripts, but if you have a pure WinXP client environment > doing so via the PMC and GPOs could be quite attractive and reduce the > cost for maintenance of the scripts - especially for branch offices... > > /Guido > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Susan Bradley, > CPA aka Ebitz - SBS Rocks [MVP] > Sent: Monday, August 28, 2006 9:08 AM > To: [email protected] > Subject: Re: [ActiveDir] Printers & AD GUI > > The only printers up in my GUI AD are the ones hanging off the server > with an IP address. > > Each workstation has a local printer and the last thing I'd want is to > have ...about 15 to 20 various versions of Laserjet 6L, 1100s and what > not in the printer drop down for everyone to buzz me and say "which one > is my local printer again?" > > I forget if this is unique to SBS's AD setup or what..... but any > network attached printer will automatically get attached to each > workstation that is set up with the /connectcomputer wizard > > http://msmvps.com/blogs/bradley/archive/2005/01/23/33632.aspx > > joe wrote: > > 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: [email protected] > > 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: <[email protected]> > > 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: [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 > > > > > 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
