[ActiveDir] [OT] CHKDSK NTFS.SYS bugs = Security descriptor issue / resolved
Hello ActiveDir, I know this is out of topic, but it I think this is a non common issue to know about. I just came across a bug on ntfs.sys. It made chkdsk reporting many errors on security descriptors like this: Replacing invalid security id with default security id for file 1396371. Replacing invalid security id with default security id for file 1396372. Replacing invalid security id with default security id for file 1429033. Fixing mirror copy of the security descriptors data stream. Security descriptor verification completed. Windows found problems with the file system. Run CHKDSK with the /F (fix) option to correct these. At the beginning I just thought about data corruption. I just opened a call to pss to get the good way to handle it (it's on a MSCS cluster). In fact, this is a ntfs.sys bug, that should raise with 4 Millions of File or an MFT of 4GB. We have 1,6 Millions of files. original: http://support.microsoft.com/default.aspx?scid=kb;EN-US;913034 The Chkdsk.exe utility incorrectly identifies and resets security descriptors in Windows Server 2003 New one: http://support.microsoft.com/default.aspx?scid=kb;en-us;915691 FIX: The system stops responding during high disk activity on a computer that is running Windows Server 2003 the last version of ntfs.sys is 5.2.3790.2655 MS gave us an internal tool get trough this SD issue. You can read the full story on my blog: http://lordoftheping.blogspot.com Regards, Mathieu CHATEAU http://lordoftheping.blogspot.com 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
[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
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
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
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
[ActiveDir] Add folder with quota to existing mailboxes - via scripting or tool
Does anybody know what is the 'best' way to add automatically a folder to existing mailboxes and set aquota on that same folder? We would like all our users to get a foldercalled "private" added to the root of their mailbox and if possible, a quota to be set to that folder. Can this be done by scripting easily or is there perhaps even a tool which is capable of doing this? This also counts for new, still to be created users. I mean, every user that will be created will have to have that certain folder added to his or her mailbox. Offcourse this could be done by running the script a couple of times a day, checking if the folder exists allready and if not, adding it. Or perhaps it can even byrealised the moment a userhas been created. Any ideas are greatly appreciated.
Re: [ActiveDir] Add folder with quota to existing mailboxes - via scripting or tool
Hello Victor,
you will at least need an account that can access all mailboxes (not a domain admins one)
(or give a script to everyone that they will execute)
To my knowledge, quota is mailbox based. You may set up a special retention on this folder.
sample _vbscript_ to create the private folder
set olApp = CreateObject("Outlook.Application")
set inbox = olApp.GetNamespace("MAPI").getDefaultFolder(6)
set temp5 = inbox.folders.add("Private",6)
hope it helps,
Regards,
Mathieu CHATEAU
http://lordoftheping.blogspot.com
Sunday, August 27, 2006, 8:57:03 PM, you wrote:
Does anybody know what is the 'best' way to add automatically a folder to existing mailboxes and set a quota on that same folder?
We would like all our users to get a folder called "private" added to the root of their mailbox and if possible, a quota to be set to that folder.
Can this be done by scripting easily or is there perhaps even a tool which is capable of doing this?
This also counts for new, still to be created users. I mean, every user that will be created will have to have that certain folder added to his or her mailbox.
Offcourse this could be done by running the script a couple of times a day, checking if the folder exists allready and if not, adding it. Or perhaps it can even by realised the moment a user has been created.
Any ideas are greatly appreciated.
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
[ActiveDir] OT - Redirect Incoming Mail on Exchange 2003
I am running Exchange 2003 SP2 and have a question about mail forwarding. I would like to forward all mail from a specific domain to an outside e-mail address. So, when a message comes in from [EMAIL PROTECTED], the message is automatically forwarded to [EMAIL PROTECTED]. Is this possible using built-in Exchange functionality? If not, can anyone recommend a product that can do this? I have been looking at GFI Mail Essentials for other purposes, but cannot ascertain whether or not it can do this for me. I would appreciate any help that can be provided. Thanks, Dan DeStefanoInfo-lution Corporation[EMAIL PROTECTED]http://www.info-lution.comOffice: 727 546-9143FAX: 727 541-5888 If you have received this message in error please notify the sender, disregard any content and remove it from your possession.
RE: [ActiveDir] Add folder with quota to existing mailboxes - via scripting or tool
You cant do per folder quotas. If youve got a lot of mailboxes thats going to be slow going with that code (but it will work). Exchange 2007 and Outlook 2007 add a feature which will accomplish what you want. Thanks, Brian Desmond [EMAIL PROTECTED] c - 312.731.3132 From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mathieu CHATEAU Sent: Sunday, August 27, 2006 3:04 PM To: Victor W. Cc: ActiveDir@mail.activedir.org Subject: Re: [ActiveDir] Add folder with quota to existing mailboxes - via scripting or tool Hello Victor, you will at least need an account that can access all mailboxes (not a domain admins one) (or give a script to everyone that they will execute) To my knowledge, quota is mailbox based. You may set up a special retention on this folder. sample _vbscript_ to create the private folder set olApp = CreateObject(Outlook.Application) set inbox = olApp.GetNamespace(MAPI).getDefaultFolder(6) set temp5 = inbox.folders.add(Private,6) hope it helps, Regards, Mathieu CHATEAU http://lordoftheping.blogspot.com Sunday, August 27, 2006, 8:57:03 PM, you wrote: Does anybody know what is the 'best' way to add automatically a folder to existing mailboxes and set a quota on that same folder? We would like all our users to get a folder called private added to the root of their mailbox and if possible, a quota to be set to that folder. Can this be done by scripting easily or is there perhaps even a tool which is capable of doing this? This also counts for new, still to be created users. I mean, every user that will be created will have to have that certain folder added to his or her mailbox. Offcourse this could be done by running the script a couple of times a day, checking if the folder exists allready and if not, adding it. Or perhaps it can even by realised the moment a user has been created. Any ideas are greatly appreciated. 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
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://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:
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: [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:
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'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
Re[2]: [ActiveDir] Add folder with quota to existing mailboxes - via scripting or tool
Hello Victor,
If the folder already exist, it will simply do nothing, except going into errors..
need to add a on error resume next or test if the folder exist before.
will create in the inbox, as a subfolder
I don't see your goal with this folder...except if you turn special rights on it.
may ask them to put it [private] in the subject instead (it will work for the sent folders)
Regards,
Mathieu CHATEAU
http://lordoftheping.blogspot.com
Sunday, August 27, 2006, 10:26:59 PM, you wrote:
VW
VW
VW Thanks Mathieu, nice.
VW
VW
VW
VW Does this create a folder in the root of the mailbox?
VW
VW Access all mailboxes you say, that sounds logical. I know that
VW domain admins indeed dont actually have the full mailbox access (they have some denies).
VW
VW
VW
VW What if a user already has the folder, does this script take this into account?
VW
VW
VW
VW Again thanks.
VW
VW
VW
VW
VW
VW Victor
VW
VW
VW From: Mathieu CHATEAU [mailto:[EMAIL PROTECTED]
VW Sent: zondag 27 augustus 2006 22:04
VW To: Victor W.
VW Cc:ActiveDir@mail.activedir.org
VW Subject: Re: [ActiveDir] Add folder with quota to existing
VW mailboxes - via scripting or tool
VW
VW
VW Hello Victor,
VW
VW
VW
VW you will at least need an account that can access all mailboxes (not a domain admins one)
VW
VW (or give a script to everyone that they will execute)
VW
VW
VW To my knowledge, quota is mailbox based. You may set up a special retention on this folder.
VW
VW
VW sample _vbscript_ to create the private folder
VW
VW set olApp = CreateObject("Outlook.Application")
VW
VW set inbox = olApp.GetNamespace("MAPI").getDefaultFolder(6)
VW
VW set temp5 = inbox.folders.add("Private",6)
VW
VW
VW hope it helps,
VW
VW
VW Regards,
VW
VW Mathieu CHATEAU
VW
VW http://lordoftheping.blogspot.com
VW
VW
VW Sunday, August 27, 2006, 8:57:03 PM, you wrote:
VW
VW
VW
VW
VW Does anybody know what is the 'best' way to add
VW automatically a folder to existing mailboxes and set a quota on that samefolder?
VW
VW We would like all our users to get a folder called
VW "private" added to the root of their mailbox and if possible, a
VW quota tobe set to that folder.
VW
VW
VW
VW Can this be done by scripting easily or is thereperhaps
VW even a tool which is capable of doing this?
VW
VW
VW
VW This also counts for new, still to be created users.I
VW mean, every user that will be created will have to have that
VW certainfolder added to his or her mailbox.
VW
VW Offcourse this could be done by running the script a
VW couple of times a day, checking if the folder exists allready and
VW if not,adding it. Or perhaps it can even by realised the
VW moment a user has beencreated.
VW
VW
VW
VW Any ideas are greatly appreciated.
VW
VW
VW
VW
VW
VW
VW
VW
VW
VW
VW
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] OT - Redirect Incoming Mail on Exchange 2003
If you know how to code, event sink is your option. Sincerely, _ (, / | /) /) /) /---| (/_ __ ___// _ // _ ) /|_/(__(_) // (_(_)(/_(_(_/(__(/_ (_/ /) (/ Microsoft MVP - Directory Services www.akomolafe.com x-excid://3277/uri:http://www.akomolafe.com - we know IT -5.75, -3.23 Do you now realize that Today is the Tomorrow you were worried about Yesterday? -anon From: Dan DeStefano Sent: Sun 8/27/2006 2:27 PM To: activedir@mail.activedir.org Subject: [ActiveDir] OT - Redirect Incoming Mail on Exchange 2003 I am running Exchange 2003 SP2 and have a question about mail forwarding. I would like to forward all mail from a specific domain to an outside e-mail address. So, when a message comes in from [EMAIL PROTECTED], the message is automatically forwarded to [EMAIL PROTECTED] Is this possible using built-in Exchange functionality? If not, can anyone recommend a product that can do this? I have been looking at GFI Mail Essentials for other purposes, but cannot ascertain whether or not it can do this for me. I would appreciate any help that can be provided. Thanks, Dan DeStefano Info-lution Corporation [EMAIL PROTECTED] http://www.info-lution.com http://www.info-lution.com/ Office: 727 546-9143 FAX: 727 541-5888 If you have received this message in error please notify the sender, disregard any content and remove it from your possession. 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: ActiveDir@mail.activedir.org Sent: Sunday, August 27, 2006 8:20 AM Subject: RE: [ActiveDir] Printers AD GUI Print Queue objects are created by default under the computer on which the printers are shared from. It is, in fact, IMO, an extremely logical way of handling it since you don't have to worry about delegating permissions to print admins, the computer itself can create/delete them as necessary. MSMQ Queues are handled the same way as lots of objects, in my default R2 forest this is a list that can be handled this way applicationVersion classStore comConnectionPoint dSA indexServerCatalog intellimirrorSCP ipsecFilter ipsecISAKMPPolicy ipsecNegotiationPolicy ipsecNFA ipsecPolicy msDFSR-LocalSettings msDS-App-Configuration msDS-AppData msieee80211-Policy mSMQConfiguration mS-SQL-OLAPServer mS-SQL-SQLServer nTFRSSubscriptions printQueue remoteStorageServicePoint rpcGroup rpcProfile rpcProfileElement rpcServer rpcServerElement rRASAdministrationConnectionPoint serviceAdministrationPoint serviceConnectionPoint serviceInstance storage Volume As for why they are third class citizens in AD... I expect it is because they are. I haven't done excessive investigation into how printers are handled but I expect the print queue objects in AD are simply reflections of the actual print queues on the servers. I don't expect you actually manage anything in AD for them, you manage them on the server/ws and then the print spooler updates any info it wants in AD. Certainly you find them in AD but that just tells the underlying software where to go look and the software goes to that print queue directly on that server. I am pretty confident that if you delete a print queue object in AD the print queue will work continue to work fine on the server still, you just can't locate it via the AD. Contrast that with users, groups, computers, and other objects I expect you consider first class citizens. If you delete those types of objects, you will find they no longer work at all. :) You will note that when you create a queue, you get the option to publish it to the directory, it isn't mandatory, not required, it is simply an option. joe -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Sunday, August 27, 2006 10:44 AM To: ActiveDir@mail.activedir.org Subject: [ActiveDir] Printers AD GUI After 6 years of working with AD I just realized that when you unshare a printer it becomes invisible and unmanageable. I guess I always knew this in the back of my head, but it never hit home until I tried cleaning up the printer list. Why are printers third-class citizens of AD, without a container or a OU to their name? The only way to remotely manage unshared printers is through the browse list, which is a pain. Am I missing something? Are there other approaches to this? (no megabucks solutions, please) List info : http://www.activedir.org/List.aspx List FAQ: http://www.activedir.org/ListFAQ.aspx List archive: http://www.activedir.org/ml/threads.aspx List info : http://www.activedir.org/List.aspx List FAQ: http://www.activedir.org/ListFAQ.aspx List archive: http://www.activedir.org/ml/threads.aspx List info : http://www.activedir.org/List.aspx List FAQ: http://www.activedir.org/ListFAQ.aspx List archive: http://www.activedir.org/ml/threads.aspx
Re: [ActiveDir] Printers AD GUI
thank you Carlos, I'll give that a try - Original Message - From: Carlos Magalhaes [EMAIL PROTECTED] To: ActiveDir@mail.activedir.org 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
But if a printer is not shared out to the network, is it a network device? It can only be used on the local machine. Do you want every local printer on every single machine in a company showing up in the directory? Consider a large multinational with hundreds of thousands of desktops and thousands with local printers that aren't shared. Then you want a printer with a certain capability in a certain site and you look and find one in the directory but it isn't actually shared out. You try to print to it, you can't. You call IT. They look into it and chase it to an exec who is like piss off. :) You tell the person they can't use it and they get snotty because everyone is better and more important than IT. :) Horrible escalations. :) You could always create your own printqueue objects for your non-shared printers. It sounds like they would get zilched back out of the directory from the process Brian mentioned unless you disable the pruning. The other issue would be the manadatory attribute for the share name but you could give it would be if it were shared. I don't know what this would buy except that you can see them when browsing AD. -- O'Reilly Active Directory Third Edition - http://www.joeware.net/win/ad3e.htm -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Albert Duro Sent: Sunday, August 27, 2006 10:24 PM To: ActiveDir@mail.activedir.org Subject: Re: [ActiveDir] Printers AD GUI You will note that when you create a queue, you get the option to publish it to the directory, it isn't mandatory, not required, it is simply an option of course, but ONLY if you share them. As soon as you stop sharing them, POOF both you and Brian essentially said that yeah printers are not full AD objects, and that's the way it is. But wasn't the promise of AD to bring ALL network objects (in the prosaic sense) into the manageability fold? There's no question that AD is vastly improved over NT as far as printers go, but I'd like to see the promise fulfilled. - Original Message - From: joe [EMAIL PROTECTED] To: ActiveDir@mail.activedir.org Sent: Sunday, August 27, 2006 8:20 AM Subject: RE: [ActiveDir] Printers AD GUI Print Queue objects are created by default under the computer on which the printers are shared from. It is, in fact, IMO, an extremely logical way of handling it since you don't have to worry about delegating permissions to print admins, the computer itself can create/delete them as necessary. MSMQ Queues are handled the same way as lots of objects, in my default R2 forest this is a list that can be handled this way applicationVersion classStore comConnectionPoint dSA indexServerCatalog intellimirrorSCP ipsecFilter ipsecISAKMPPolicy ipsecNegotiationPolicy ipsecNFA ipsecPolicy msDFSR-LocalSettings msDS-App-Configuration msDS-AppData msieee80211-Policy mSMQConfiguration mS-SQL-OLAPServer mS-SQL-SQLServer nTFRSSubscriptions printQueue remoteStorageServicePoint rpcGroup rpcProfile rpcProfileElement rpcServer rpcServerElement rRASAdministrationConnectionPoint serviceAdministrationPoint serviceConnectionPoint serviceInstance storage Volume As for why they are third class citizens in AD... I expect it is because they are. I haven't done excessive investigation into how printers are handled but I expect the print queue objects in AD are simply reflections of the actual print queues on the servers. I don't expect you actually manage anything in AD for them, you manage them on the server/ws and then the print spooler updates any info it wants in AD. Certainly you find them in AD but that just tells the underlying software where to go look and the software goes to that print queue directly on that server. I am pretty confident that if you delete a print queue object in AD the print queue will work continue to work fine on the server still, you just can't locate it via the AD. Contrast that with users, groups, computers, and other objects I expect you consider first class citizens. If you delete those types of objects, you will find they no longer work at all. :) You will note that when you create a queue, you get the option to publish it to the directory, it isn't mandatory, not required, it is simply an option. joe -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Sunday, August 27, 2006 10:44 AM To: ActiveDir@mail.activedir.org Subject: [ActiveDir] Printers AD GUI After 6 years of working with AD I just realized that when you unshare a printer it becomes invisible and unmanageable. I guess I always knew this in the back of my head, but it never hit home until I tried cleaning up the printer list. Why are printers third-class citizens of AD, without a container or a OU to their name? The only way to remotely manage unshared printers is through the browse list, which is a pain. Am I missing
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: ActiveDir@mail.activedir.org Sent: Sunday, August 27, 2006 8:20 AM Subject: RE: [ActiveDir] Printers AD GUI Print Queue objects are created by default under the computer on which the printers are shared from. It is, in fact, IMO, an extremely logical way of handling it since you don't have to worry about delegating permissions to print admins, the computer itself can create/delete them as necessary. MSMQ Queues are handled the same way as lots of objects, in my default R2 forest this is a list that can be handled this way applicationVersion classStore comConnectionPoint dSA indexServerCatalog intellimirrorSCP ipsecFilter ipsecISAKMPPolicy ipsecNegotiationPolicy ipsecNFA ipsecPolicy msDFSR-LocalSettings msDS-App-Configuration msDS-AppData msieee80211-Policy mSMQConfiguration mS-SQL-OLAPServer mS-SQL-SQLServer nTFRSSubscriptions printQueue remoteStorageServicePoint rpcGroup rpcProfile rpcProfileElement rpcServer rpcServerElement rRASAdministrationConnectionPoint serviceAdministrationPoint serviceConnectionPoint serviceInstance storage Volume As for why they are third class citizens in AD... I expect it is because they are. I haven't done excessive investigation into how printers are handled but I expect the print queue objects in AD are simply reflections of the actual print queues on the servers. I don't expect you actually manage anything in AD for them, you manage them on the server/ws and then the print spooler updates any info it wants in AD. Certainly you find them in AD but that just tells the underlying software where to go look and the software goes to that print queue directly on that server. I am pretty confident that if you delete a print queue object in AD the print queue will work continue to work fine on the server still, you just can't locate it via the AD. Contrast that with users, groups, computers, and other objects I expect you consider first class citizens. If you delete those types of objects, you will find they no longer work at all. :) You will note that when you create a queue, you get the option to publish it to the directory, it isn't mandatory, not required, it is simply an option. joe -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Sunday, August 27, 2006 10:44 AM To: ActiveDir@mail.activedir.org Subject:
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: ActiveDir@mail.activedir.org Sent: Sunday, August 27, 2006 8:20 AM Subject: RE: [ActiveDir] Printers AD GUI Print Queue objects are created by default under the computer on which the printers are shared from. It is, in fact, IMO, an extremely logical way of handling it since you don't have to worry about delegating permissions to print admins, the computer itself can create/delete them as necessary. MSMQ Queues are handled the same way as lots of objects, in my default R2 forest this is a list that can be handled this way applicationVersion classStore comConnectionPoint dSA indexServerCatalog intellimirrorSCP ipsecFilter ipsecISAKMPPolicy ipsecNegotiationPolicy ipsecNFA ipsecPolicy msDFSR-LocalSettings msDS-App-Configuration msDS-AppData msieee80211-Policy mSMQConfiguration mS-SQL-OLAPServer mS-SQL-SQLServer nTFRSSubscriptions printQueue remoteStorageServicePoint rpcGroup rpcProfile rpcProfileElement rpcServer rpcServerElement rRASAdministrationConnectionPoint serviceAdministrationPoint serviceConnectionPoint serviceInstance storage Volume As for why they are third class citizens in AD... I expect it is because they are. I haven't done excessive investigation into how printers are handled but I expect the print queue objects in AD are simply reflections of the actual print queues on the servers. I don't expect you actually manage anything in AD for them, you manage them on the server/ws and then the print spooler updates any info it wants in AD. Certainly you find them in AD but that just tells the underlying software where to go look and the software goes to that print queue directly on that server. I am pretty confident that if you delete a print queue object in AD the print queue will work continue to work fine on the server still, you just can't locate it via the AD. Contrast that with users, groups, computers, and other objects I expect you consider first class citizens. If you delete those types of objects, you will find they no longer work at all. :) You will note that when you create
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: ActiveDir@mail.activedir.org Sent: Sunday, August 27, 2006 8:20 AM Subject: RE: [ActiveDir] Printers AD GUI Print Queue objects are created by default under the computer on which the printers are shared from. It is, in fact, IMO, an extremely logical way of handling it since you don't have to worry about delegating permissions to print admins, the computer itself can create/delete them as necessary. MSMQ Queues are handled the same way as lots of objects, in my default R2 forest this is a list that can be handled this way applicationVersion classStore comConnectionPoint dSA indexServerCatalog intellimirrorSCP ipsecFilter ipsecISAKMPPolicy ipsecNegotiationPolicy ipsecNFA ipsecPolicy msDFSR-LocalSettings msDS-App-Configuration msDS-AppData msieee80211-Policy mSMQConfiguration mS-SQL-OLAPServer mS-SQL-SQLServer nTFRSSubscriptions printQueue remoteStorageServicePoint rpcGroup rpcProfile rpcProfileElement rpcServer rpcServerElement rRASAdministrationConnectionPoint serviceAdministrationPoint serviceConnectionPoint serviceInstance storage Volume As for why they are third class citizens in AD... I expect it is because they are. I haven't done excessive investigation into how printers are handled but I expect the print queue objects in AD are simply reflections of the actual print queues on the servers. I don't expect you actually manage anything in AD for them, you manage them on the server/ws and then the print spooler updates any info it wants in AD. Certainly you find them in AD but that just tells the underlying software where to go look and the software goes to that print queue directly on that server. I am pretty confident that if you delete a print queue object in AD the print queue will work continue to work fine on the server still, you just can't locate it via the AD. Contrast that with users, groups,
