RE: [ActiveDir] Printers & AD GUI
Yes, but you can exclude machines which don't have printers attached. Don't know what your network is like but most of our machines don't have a local printer - they're networked from servers - so the standard browse list has loads of machines which don't have printers. Steve -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Albert Duro Sent: 29 August 2006 15:51 To: ActiveDir@mail.activedir.org Subject: Re: [ActiveDir] Printers & AD GUI good stuff, Steve, thanks. But isn't all this really a duplication of what the Browse List already does? - Original Message - From: "Steve Rochford" <[EMAIL PROTECTED]> To: Sent: Tuesday, August 29, 2006 4:46 AM Subject: RE: [ActiveDir] Printers & AD GUI I'd guess it depends why you're wanting to manage a printer but if it's in response to someone reporting some kind of problem with their printer then you can just sit at your computer and type \\ into explorer. You'll then see the "printers and faxes" folder - double click that and you'll have access to the printer(s)installed even if they're not shared. I don't think it's much more work than connecting through the AD GUI. If you don't know the name of the computers with printers then it wouldn't be too hard to use a WMI script to build a database of computers and their printers - this could then feed a web page listing them and you just click on the name to connect in the same way as typing the name above. If most of your machines are on all the time and there are not too many then the web page could even do a live query of each machine to get the printer details. Steve -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Albert Duro Sent: 28 August 2006 16:11 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. 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
Re: [ActiveDir] Printers & AD GUI
good stuff, Steve, thanks. But isn't all this really a duplication of what the Browse List already does? - Original Message - From: "Steve Rochford" <[EMAIL PROTECTED]> To: Sent: Tuesday, August 29, 2006 4:46 AM Subject: RE: [ActiveDir] Printers & AD GUI I'd guess it depends why you're wanting to manage a printer but if it's in response to someone reporting some kind of problem with their printer then you can just sit at your computer and type \\ into explorer. You'll then see the "printers and faxes" folder - double click that and you'll have access to the printer(s)installed even if they're not shared. I don't think it's much more work than connecting through the AD GUI. If you don't know the name of the computers with printers then it wouldn't be too hard to use a WMI script to build a database of computers and their printers - this could then feed a web page listing them and you just click on the name to connect in the same way as typing the name above. If most of your machines are on all the time and there are not too many then the web page could even do a live query of each machine to get the printer details. Steve -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Albert Duro Sent: 28 August 2006 16:11 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. 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
RE: [ActiveDir] Printers & AD GUI
I'd guess it depends why you're wanting to manage a printer but if it's in response to someone reporting some kind of problem with their printer then you can just sit at your computer and type \\ into explorer. You'll then see the "printers and faxes" folder - double click that and you'll have access to the printer(s)installed even if they're not shared. I don't think it's much more work than connecting through the AD GUI. If you don't know the name of the computers with printers then it wouldn't be too hard to use a WMI script to build a database of computers and their printers - this could then feed a web page listing them and you just click on the name to connect in the same way as typing the name above. If most of your machines are on all the time and there are not too many then the web page could even do a live query of each machine to get the printer details. Steve -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Albert Duro Sent: 28 August 2006 16:11 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. 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
Re: [ActiveDir] Printers & AD GUI
(mind if I offer this up as a suggestion for the Centro guys?) Please. And thank you. And yes, I am aware of the several ways of managing printers remotely, but let's face it, they're all kludges. - Original Message - From: "Susan Bradley, CPA aka Ebitz - SBS Rocks [MVP]" <[EMAIL PROTECTED]> To: Sent: Monday, August 28, 2006 12:56 PM Subject: Re: [ActiveDir] Printers & AD GUI Attach remotely via TS or RDP to that remote computer. There are many ways to manage stuff remotely. (mind if I offer this up as a suggestion for the Centro guys?) Albert Duro wrote: 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: 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: 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 a
Re: [ActiveDir] Printers & AD GUI
Attach remotely via TS or RDP to that remote computer. There are many ways to manage stuff remotely. (mind if I offer this up as a suggestion for the Centro guys?) Albert Duro wrote: 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: 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: 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
RE: [ActiveDir] Printers & AD GUI
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: > 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: > > 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 >
RE: [ActiveDir] Printers & AD GUI
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: ActiveDir@mail.activedir.org
> 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: ActiveDir@mail.activedir.org
> 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 th
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: 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: 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 s
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: ActiveDir@mail.activedir.org
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: 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
Re: [ActiveDir] Printers & AD GUI
(btwyeah yeah I know.. I suck at lurking as usual) Susan Bradley, CPA aka Ebitz - SBS Rocks [MVP] wrote: 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: 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: 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 qu
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: 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: 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. jo
RE: [ActiveDir] Printers & AD GUI
Title: RE: [ActiveDir] Printers & AD GUI http://support.microsoft.com/kb/246906/ http://support.microsoft.com/kb/234270/ Met vriendelijke groeten / Kind regards, Ing. Jorge de Almeida Pinto Senior Infrastructure Consultant MVP Windows Server - Directory Services LogicaCMG Nederland B.V. (BU RTINC Eindhoven) ( Tel : +31-(0)40-29.57.777 ( Mobile : +31-(0)6-26.26.62.80 * E-mail : From: [EMAIL PROTECTED] on behalf of joeSent: Sun 2006-08-27 23:46To: ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] Printers & AD GUI Oh no kidding Brian... I had never heard that about the pruning... I hate toask this, but is there any documentation on that? That would totally explainsome things various folks have asked me about DCs spinning up dialupconnections 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 DesmondSent: Sunday, August 27, 2006 2:25 PMTo: ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] Printers & AD GUIRight. The computer is responsible for managing the print queue objects.Any changes you make on the print server are reflected on the publishedqueue. Everytime the spooler service starts it confirms that the queueobjects for published printers are all still in the directory.There is a thread that runs on every DC by default which prunes printerobjects. It attempts to contact the print server every eight hours andif it can't after two intervals (8 hours by default) the printer objectsget deleted. If you move the printers out from under the computerobjects, then the pruning thread is the only way they will get cleanedup 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 extremelylogical> way of handling it since you don't have to worry about delegating> permissions to print admins, the computer itself can create/deletethem> 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 Iexpect> 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 pr
RE: [ActiveDir] Printers & AD GUI
Not if pruning is disabled, no. -- Original Message -- From: "joe" <[EMAIL PROTECTED]> Reply-To: ActiveDir@mail.activedir.org Date: Mon, 28 Aug 2006 01:20:09 -0400 Even if the pruning is disabled? -- 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: Monday, August 28, 2006 12:25 AM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Printers & AD GUI It would get killed if the share didn't actually exist 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:48 PM > To: ActiveDir@mail.activedir.org > 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: > 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 > >
RE: [ActiveDir] Printers & AD GUI
Even if the pruning is disabled? -- 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: Monday, August 28, 2006 12:25 AM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Printers & AD GUI It would get killed if the share didn't actually exist 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:48 PM > To: ActiveDir@mail.activedir.org > 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: > 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 se
RE: [ActiveDir] Printers & AD GUI
It would get killed if the share didn't actually exist 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:48 PM > To: ActiveDir@mail.activedir.org > 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: > 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 > softw
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: 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 real
Re: [ActiveDir] Printers & AD GUI
thank you Carlos, I'll give that a try - Original Message - From: "Carlos Magalhaes" <[EMAIL PROTECTED]> To: Sent: Sunday, August 27, 2006 7:47 AM Subject: Re: [ActiveDir] Printers & AD GUI Hello there, have you had a look at the Windows Server 2003 R2 Printer Management Console, I think this will solve your issue (still doesn't make printers first class citizens though ;)) Carlos [EMAIL PROTECTED] wrote: 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
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: 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
RE: [ActiveDir] Printers & AD GUI
It's not well documented. The best source I found is the whitpaper: Integration of Windows 2000 Printing with Active Directory http://www.microsoft.com/windows2000/docs/printad.doc Here's an extract. "The pruning service, which runs on each domain controller, performs this automatic removal of non-existent printers. The printer pruner periodically checks each print server for orphaned printers, and if a printer is not detected, the pruner deletes it. The pruner checks only those print servers that are in the same site as the domain controller on which the pruning service is running. Group Policy settings are used to control the behavior of the printer pruner (see the Role of Group Policy section earlier in this paper). By default, if the pruner cannot detect a printer three times in a row at eight-hour intervals, it assumes that the entry is no longer valid and deletes it." The key here is that the pruner will attempt to connect to print queues on print servers, so this could well explain why you see the remote links coming up (assuming the remote sites have print queues but no DCs). More information in this article I wrote a while back: http://www.windowsitpro.com/Windows/Article/ArticleID/41104/41104.html Tony -- Original Message -- From: "joe" <[EMAIL PROTECTED]> Reply-To: ActiveDir@mail.activedir.org Date: Sun, 27 Aug 2006 17:46:28 -0400 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'
RE: [ActiveDir] Printers & AD GUI
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
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
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
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
Re: [ActiveDir] Printers & AD GUI
Hello there, have you had a look at the Windows Server 2003 R2 Printer Management Console, I think this will solve your issue (still doesn't make printers first class citizens though ;)) Carlos [EMAIL PROTECTED] wrote: 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
