RE: [ActiveDir] exchange one more time(ot)
I just tested this, I sent to [EMAIL PROTECTED] and watched Exchange query DNS for the MX record, an SOA record was returned, it then queried the A record and got that and fired the message off. If it isn't working, then I expect it is in the name res area as Hunter is indicating as well. From: [EMAIL PROTECTED] on behalf of Coleman, Hunter Sent: Mon 9/26/2005 9:34 PM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] exchange one more time(ot) Why should Exchange not think that servername.domain.tld is a domain? Can you resolve servername.domain.tld from the Exchange server? How about from the smarthost? From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tom Kern Sent: Monday, September 26, 2005 5:32 PM To: ActiveDir@mail.activedir.org Subject: Re: [ActiveDir] exchange one more time(ot) when i had the smtp connector point to dns, it failed with remote host did not respond. when pointing to a smarthost it worked. maybe exchange while sending to [EMAIL PROTECTED], thinks servername.domain.tld is a domain and when it gets a nxdomain from domain.tld, it fails? no? sillier things have been know to occur with exchange... thanks On 9/26/05, joe [EMAIL PROTECTED] wrote: From my experience it should work fine. It doesn't have to know if the right hand side is a domain or host IP, it simply needs to try and look it up in DNS. I believe it will try an MX lookup and failing that, fall back to a host record lookup. A simple test would be to enable SMTP on some machine in your domain, make sure there is a host record for the given name and then send a message to it, you should see the message hit your configured drop folder. joe From: [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED] On Behalf Of Tom Kern Sent: Saturday, September 24, 2005 2:12 AM To: ActiveDir@mail.activedir.org Subject: Re: [ActiveDir] exchange one more time(ot) how does it figure out its a literal addy and not a domain? how does it know the RHS is not a domain name and fail trying to look it up? or does it fail and then go up the list to the other part of the name? I'd like to know because i can't find any exchange docs on it. there's nothing in the app log. i'll turn up diag logging.. mail didn't start flowing untill i changed the connector to point to a smart host rather than dns. until then, it just sat in the queue. the error in the queue was remote destatination did not respond. Thanks On 9/23/05, Al Mulnick [EMAIL PROTECTED] wrote: Exchange should be able to deliver to a literal address as long as it is not its own. That's a valid and a common address in SMTP. Check the logs to see what the failure is. There's a lot of possibilities as to why it may not get to its destination. Al From: [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] ] On Behalf Of Tom Kern Sent: Friday, September 23, 2005 3:07 PM To: activedirectory Subject: [ActiveDir] exchange one more time(ot) If i set up a contact with the server name in the addy as in [EMAIL PROTECTED], will the message get delivered or will exchange think servername.domain.tld is the domain name and throw an error? Just a question i'm throwing out because an archive solution is giving me that kind of contact to send mail to and its not getting there. I have a feeling its because of that and i should just create a connector to forward to that addy as a smarthost but i want to confirm with you guys that i can't write an address in that form and expect exchange(or any smtp server?) to deliver the mail. thanks winmail.dat
RE: [ActiveDir] Script to check on GCs response/health?
Title: [ActiveDir] Script to check on GCs response/health? One quick and fairly easy method to partially do this is to set up a simple script that does a basic query (say against the schema which should be quick but not say a rootdse query) and have a baseline acceptable time frame for the response. I have done this in the past and found choked up GCs (specifically in relation to Exchange) using a little perl and a little adfind. Versus hardcoding GCs set up a dedicated Exchange site. This protects you main site from Exchange and Exchange from everything else. I.E. If Exchange tears down a DC, Exchange suffers. If something else tears down a DC, Exchange should be fairly protected as it shouldn't be a DC Exchange is using.ALSO and this is a point I have a strong opinion of. Most GCs can go down and things don't care, authentication will work, etc.Exchange GCs can't generally do this. This means that you can keep certain GCs in mind for monitoring and your response to them going offline. At the widget factory I worked for there were only a few GCs I cared about going down in terms of speed to get them back up and running. The Exchange GCs and the PDC's. The other DC's/GCs we cared about but we weren't running in the middle of the night because of them. Anyway, set up a script that you specify a list of GCs or (better) takes a site or list of sites and then goes into a loop. In the loop it gets a list of GCs or DCs, it then does a basic schema query that will return some subset of objects and attributes. Unless you are going against a GC across some slow wires, any query should be back in a second or less for an idle DC. As you load up you will see 1,2,3,6,8 second responses. Once you hit 20+ seconds on a query, you really need to be looking at things. You get to 30 seconds and you most certainly have Exchange queue backups and probably store hangs. If you are monitoring this and you are normally at 3-4 seconds at main load and you hit 10 seconds consistently on a GC, then you page on that and start chasing. joe From: [EMAIL PROTECTED] on behalf of Thommes, Michael M.Sent: Thu 11/11/2004 11:59 AMTo: [EMAIL PROTECTED]Subject: [ActiveDir] Script to check on GCs response/health? In our environment we have lots of GCs, most of which I don't control.While I run a dcdiag report each morning that checks the overall healthof my domain including whether a DC is advertising itself as a GC, wesee issues once in a while when a process does a GC discovery action andends up on a "bad" one, e.g., not available, busy, slow network, maybepermissions, etc.The other day our Exchange cluster was running like a dog since after areboot, it hooked itself up with a GC that was not performingparticularly well. As a solution for that particular problem, we wereable to hardcode into the Exchange servers specific GCs that I know workwell. Has anyone developed a script that checks on the health of GCfunctionality or dealt with this issue some other way? Thanks inadvance!Mike ThommesList info : http://www.activedir.org/mail_list.htmList FAQ : http://www.activedir.org/list_faq.htmList archive: http://www.mail-archive.com/activedir%40mail.activedir.org/
RE: RE: [ActiveDir] Indexing an attribute
Title: RE: RE: [ActiveDir] Indexing an attribute All I said is I take showers. Didn't say I actually used soap and washed while there. :o) Mostly I put the shower head on beat and let it thunk me on the neck in hopes of knocking me out. joe From: [EMAIL PROTECTED] on behalf of [EMAIL PROTECTED]Sent: Wed 11/10/2004 12:36 PMTo: [EMAIL PROTECTED]Subject: RE: RE: [ActiveDir] Indexing an attribute I second that :-pSincerely,Dèjì Akómöláfé, MCSE+M MCSA+M MCP+IMicrosoft MVP - Directory Serviceswww.readymaids.com - we know ITwww.akomolafe.comDo you now realize that Today is the Tomorrow you were worried aboutYesterday? -anonFrom: [EMAIL PROTECTED] on behalf of Mulnick, AlSent: Wed 11/10/2004 9:22 AMTo: [EMAIL PROTECTED]Subject: OT: RE: [ActiveDir] Indexing an attributeReally, we should amend that to 'Joe *says* he maintains good hygiene.' Justto be accurate and all.Al-Original Message-From: [EMAIL PROTECTED][mailto:[EMAIL PROTECTED]] On Behalf Of Tony MurraySent: Wednesday, November 10, 2004 4:05 AMTo: [EMAIL PROTECTED]Subject: Re: [ActiveDir] Indexing an attributeI just realised that legacyExchangeDN was a bad example to pick in my emailbelow because the syntax is "Case Insensitive String" and not "DistinguishedName". I guess this is to support the ADCDisabledMail value, which isclearly not DN format.Sorry Joe :-)TonyPS. This has been a great thread. I learned that linked attributes areindexed by default and that Joe maintains good bodily hygiene!-Original Message-From: Tony Murray [mailto:[EMAIL PROTECTED]]Sent: Dienstag, 9. November 2004 15:54To: [EMAIL PROTECTED]Subject: RE: [ActiveDir] Indexing an attribute You still won't be able to do wildcard searches because it is a DNattribute.You can still use a wildcard where the beginning of the value is known, e.g.((|(objectclass=contact)(objectclass=group))(|(legacyExchangeDN=/o=MyCo/ou=MyOU/*)(legacyExchangeDN=ADCDisabledMail*)(isDeleted=TRUE)))I think this is where the indexing would help.Tony-- Original Message --From: "joe" [EMAIL PROTECTED]Reply-To: [EMAIL PROTECTED]Date: Tue, 9 Nov 2004 06:03:07 -0800You will have a little DIT growth, creation of new mailboxes might beimpacted a little in terms of speed as insertion of the attribute might be atrifle slower (nothing you would notice I expect unless doing a ton of newcreations quickly with MT C code and still you could blame it on the RUSfaster than blaming it on the indexing).Anything that searched on that attribute would possibly be more efficient orbe quicker.You still won't be able to do wildcard searches because it is a DNattribute.What are you looking to get out of it? Or to put it another way, why do youthink you should do it?Overall in the end, MS and pretty much anyone is going to say you need totest it in your test lab with a comparable test data set as production toreally know specifically what it will do. joe _From: [EMAIL PROTECTED][mailto:[EMAIL PROTECTED]] On Behalf Of Holland Matthew BCGBSent: Tuesday, November 09, 2004 4:36 AMTo: [EMAIL PROTECTED]Subject: [ActiveDir] Indexing an attributeHi all,Does anyone know the potential impact of indexing an attribute in ActiveDirectory? The attribute is HomeMDB, it's Single Valued and is a member ofthe PAS (We have approx 17,000 Mail Enabled User objects in ActiveDirectory).Cheers,MattySent via the WebMail system at mail.activedir.orgList info : http://www.activedir.org/mail_list.htmList FAQ : http://www.activedir.org/list_faq.htmList archive: http://www.mail-archive.com/activedir%40mail.activedir.org/Sent via the WebMail system at mail.activedir.orgList info : http://www.activedir.org/mail_list.htmList FAQ : http://www.activedir.org/list_faq.htmList archive: http://www.mail-archive.com/activedir%40mail.activedir.org/List info : http://www.activedir.org/mail_list.htmList FAQ : http://www.activedir.org/list_faq.htmList archive: http://www.mail-archive.com/activedir%40mail.activedir.org/List info : http://www.activedir.org/mail_list.htmList FAQ : http://www.activedir.org/list_faq.htmList archive: http://www.mail-archive.com/activedir%40mail.activedir.org/
RE: [ActiveDir] Indexing an attribute
I sit corrected. :o) I guess what I meant is that a linked attribute is used as an implied indexed attribute for queries in K3. Might be interesting to just have the engine light the indexed flag of any attributes that are linked and clear all confusion in K3. On another topic,I know everyone on the list is jealous, I actually met ~Eric face to face today. He looks amazingly like Tom Cruise. joe From: [EMAIL PROTECTED] on behalf of Eric FleischmanSent: Wed 11/10/2004 5:56 PMTo: [EMAIL PROTECTED]Subject: RE: [ActiveDir] Indexing an attribute Thats not entirely true either, but close. A more accurate statement: the index is not used _by query processor_ in 2k, but is in 2k03. The index is used by other things in AD in 2k, like a simple read of the member attribute of a group. ~Eric From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joeSent: Wednesday, November 10, 2004 6:03 AMTo: [EMAIL PROTECTED]Subject: RE: [ActiveDir] Indexing an attribute Note what he indicates though. Indexed for free due to the nature of being a linked attribute, ***but the index isn't used unless it is on Windows Server 2003 AD***. I actually spoke to ~Eric about this in the past and it had completely slipped my mind when discussing here. The whole idea is that someone at MS realized, hey wait, basicallyall of the linking info needed for these attributes is already available and so theyenhanced the engine to take advantage of it. This is just one more reason to use Windows Server 2003 for your Domain Controllers. But again, use the BL if it is possible for you. Much much faster. joe From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Holland Matthew BC GBSent: Wednesday, November 10, 2004 2:08 AMTo: [EMAIL PROTECTED]Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]Subject: RE: [ActiveDir] Indexing an attribute Interesting, I didnt realize HomeMDB is indexed for free! Although, as you mentioned, it seems to make sense to use homeMDBBL. Thanks for your help! Matty From: Eric Fleischman [mailto:[EMAIL PROTECTED] Sent: 09 November 2004 20:51To: [EMAIL PROTECTED]Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]Subject: RE: [ActiveDir] Indexing an attribute HomeMDB need not be indexed. Linked values are implicitly indexed and those indexes will be used by QP in 2k03 out of the box. If you run it with STATS spew, youll see that the index type is L, for linked. ~Eric From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of listmailSent: Tuesday, November 09, 2004 11:10 AMTo: [EMAIL PROTECTED]; [EMAIL PROTECTED]Cc: Eric Fleischman; [EMAIL PROTECTED]Subject: RE: [ActiveDir] Indexing an attribute First off, your initial query isn't optimal. ObjectClass user is not a valid objectcategory attrib, it would be converted to objectcategory=person which includes contacts, inetorgpersons, and contacts. A good solution there, IMHO, is to index objectclass and go a search with objectclass=user. For the second piece, concerning what you do for homeMDB, if you are looking at all users across the board, I would switch it around and do it from the back end (shush Al - security term, I am sitting here in Microsoft Conference Center listening to Mike Nash and thinking security). Anyway, anytime you have to do something with all of the Exchange users based on their database/sg/server I look at the homeMDBBL attribute. That is an attribute in the Exchange config info section under the Exchange server objects and you can go from taking many minutes to gather the homeMDB info to seconds. The more I think about it though, the less I think you will get a performance benefit for indexing homeMDB or any DN based attrib. joe From: [EMAIL PROTECTED] on behalf of Holland Matthew BC GBSent: Tue 11/9/2004 10:55 AMTo: [EMAIL PROTECTED]Cc: 'Eric Fleischman'; [EMAIL PROTECTED]Subject: RE: [ActiveDir] Indexing an attribute The gain we are seeking is to speed up the LDAP query. The background: We have a scheduled process that populates groups with members based upon matching results from LDAP queries for department, location and country-name (c) Example: Search filter for country mycountry is ((objectCategory=user)(c=mycountry))) Results from query populate a group called mycountry-allusers Although location was indexed, c and department so the process was unacceptably slow as we use the domain root as a SearchBase, hence we decided to index these two attributes which solved the problem! Now we have a new requirement to populate groups with members based upon the Mail Storage Group /Server hence we want to query the HomeMDB attribute. Or course, this is again slow due to the attribute not being indexed. This raised a small concern of indexing a DN attribute and what the impact of this would be. It would be great to get your thoughts, let me know (after your next shower maybe ;-)). Thanks for your help!
RE: [ActiveDir] Indexing an attribute
Title: RE: [ActiveDir] Indexing an attribute Not for this one. homeMDB is a true AD DN attribute like say member. AsI understand it, it is stored not as a string but as a pointer (which is why I wonder how much help indexing will give...)that is why it auto updates when you change the name of the object. legacyExchangeDN isn't a real DN to AD. Take a look at the attribs definition in the schema, contrast with homeMDB. You can't wildcard the real DN attribs. The string form is constructed. joe From: [EMAIL PROTECTED] on behalf of Tony MurraySent: Tue 11/9/2004 9:53 AMTo: [EMAIL PROTECTED]Subject: RE: [ActiveDir] Indexing an attribute You still won't be able to do wildcard searches because it is a DN attribute.You can still use a wildcard where the beginning of the value is known, e.g.((|(objectclass=contact)(objectclass=group))(|(legacyExchangeDN=/o=MyCo/ou=MyOU/*)(legacyExchangeDN=ADCDisabledMail*)(isDeleted=TRUE)))I think this is where the indexing would help.Tony-- Original Message --From: "joe" [EMAIL PROTECTED]Reply-To: [EMAIL PROTECTED]Date: Tue, 9 Nov 2004 06:03:07 -0800You will have a little DIT growth, creation of new mailboxes might beimpacted a little in terms of speed as insertion of the attribute might be atrifle slower (nothing you would notice I expect unless doing a ton of newcreations quickly with MT C code and still you could blame it on the RUSfaster than blaming it on the indexing).Anything that searched on that attribute would possibly be more efficient orbe quicker.You still won't be able to do wildcard searches because it is a DNattribute.What are you looking to get out of it? Or to put it another way, why do youthink you should do it?Overall in the end, MS and pretty much anyone is going to say you need totest it in your test lab with a comparable test data set as production toreally know specifically what it will do. joe _From: [EMAIL PROTECTED][mailto:[EMAIL PROTECTED]] On Behalf Of Holland Matthew BCGBSent: Tuesday, November 09, 2004 4:36 AMTo: [EMAIL PROTECTED]Subject: [ActiveDir] Indexing an attributeHi all,Does anyone know the potential impact of indexing an attribute in ActiveDirectory? The attribute is HomeMDB, it's Single Valued and is a member ofthe PAS (We have approx 17,000 Mail Enabled User objects in ActiveDirectory).Cheers,MattySent via the WebMail system at mail.activedir.orgList info : http://www.activedir.org/mail_list.htmList FAQ : http://www.activedir.org/list_faq.htmList archive: http://www.mail-archive.com/activedir%40mail.activedir.org/
RE: [ActiveDir] Indexing an attribute
First off, your initial query isn't optimal. ObjectClass user is not a valid objectcategory attrib, it would be converted to objectcategory=person which includes contacts, inetorgpersons, and contacts. A good solution there, IMHO, is to index objectclass and go a search with objectclass=user. For the second piece, concerning what you do for homeMDB, if you are looking at all users across the board, I would switch it around and do it from the back end (shush Al - security term, I am sitting here in Microsoft Conference Center listening to Mike Nash and thinking security). Anyway, anytime you have to do something with all of the Exchange users based on their database/sg/server I look at the homeMDBBL attribute. That is an attribute in the Exchange config info section under the Exchange server objects and you can go from taking many minutes to gather the homeMDB info to seconds. The more I think about it though, the less I think you will get a performance benefit for indexing homeMDB or any DN based attrib. joe From: [EMAIL PROTECTED] on behalf of Holland Matthew BC GBSent: Tue 11/9/2004 10:55 AMTo: [EMAIL PROTECTED]Cc: 'Eric Fleischman'; [EMAIL PROTECTED]Subject: RE: [ActiveDir] Indexing an attribute The gain we are seeking is to speed up the LDAP query. The background: We have a scheduled process that populates groups with members based upon matching results from LDAP queries for department, location and country-name (c) Example: Search filter for country mycountry is ((objectCategory=user)(c=mycountry))) Results from query populate a group called mycountry-allusers Although location was indexed, c and department so the process was unacceptably slow as we use the domain root as a SearchBase, hence we decided to index these two attributes which solved the problem! Now we have a new requirement to populate groups with members based upon the Mail Storage Group /Server hence we want to query the HomeMDB attribute. Or course, this is again slow due to the attribute not being indexed. This raised a small concern of indexing a DN attribute and what the impact of this would be. It would be great to get your thoughts, let me know (after your next shower maybe ;-)). Thanks for your help! Matty From: joe [mailto:[EMAIL PROTECTED] Sent: 09 November 2004 15:22To: [EMAIL PROTECTED]Cc: 'Eric Fleischman'; [EMAIL PROTECTED]Subject: RE: [ActiveDir] Indexing an attribute You know though as I took a shower and thought about this[1]. This is a DN attribute, I am wondering if indexing may not help a lot or at all; not that I implied it would be any great help below. I look forward to reading a response from the likes of Dean or ~Eric and what they have to say. joe [1] Yes sick I know. I would read books in the shower too if I could figure out a way to keep the pages dry. Showers area huge waste of time, right behind commuting if you drive yourself though I refuse to take short showers both for the benefit of those around me and because I feel hot showers are the culmination of great western civilization. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joeSent: Tuesday, November 09, 2004 6:03 AMTo: [EMAIL PROTECTED]Subject: RE: [ActiveDir] Indexing an attribute You will have a little DIT growth, creation of new mailboxes might be impacted a little in terms of speed as insertion of the attribute might be a trifle slower (nothing you would notice I expect unless doing a ton of new creations quickly with MT C code and still you could blame it on the RUS faster than blaming it on the indexing). Anything that searched on that attribute would possibly be more efficient or be quicker. You still won't be able to do wildcard searches because it is a DN attribute. What are you looking to get out of it? Or to put it another way, why do you think you should do it? Overall in the end, MS and pretty much anyone is going to say you need to test it in your test lab with a comparable test data set as production to really know specifically what it will do. joe From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Holland Matthew BC GBSent: Tuesday, November 09, 2004 4:36 AMTo: [EMAIL PROTECTED]Subject: [ActiveDir] Indexing an attribute Hi all, Does anyone know the potential impact of indexing an attribute in Active Directory? The attribute is HomeMDB, its Single Valued and is a member of the PAS (We have approx 17,000 Mail Enabled User objects in Active Directory). Cheers, Matty
RE: [ActiveDir] Indexing an attribute
It is linked. homeMDB and homeMDBBL. Not using adfind will not irritate me at all. Go ahead and use dsquery... oh wait, that doesn't do search stats. Use search.vbs... oh oops... I guess you are stuck with ldp if you don't use adfind. ;oP joe From: [EMAIL PROTECTED] on behalf of Dean Wells Sent: Tue 11/9/2004 11:57 AM To: Send - AD mailing list Subject: RE: [ActiveDir] Indexing an attribute First and foremost, I assume the attribute in question isn't linked ... there, I've asked the obvious. Assuming it is not; that's an interesting question. I can't say that I've thought about this before. AD would be performing minor trickery if indexing were to help since attributes using DN syntax are maintained internally using the DNT ... not that the trickery required is hard to do but I don't know if it would since I haven't tried. In all honesty, I don't hold out much hope but I also don't have a large enough DIT to hand at the moment to test against. One idea did jump out at met though ... perhaps you'd like to try a few iterations of the query below - ((objectcategory=person)(homeMDB=GUID=04F46C422FC4AA4190D2B2096CD6946D)) ... obviously, replace the GUID I've used above with the GUID of the DN you are querying upon. I'd like to see the results using the search stats control (1.2.840.113556.1.4.970) for accuracy (you could use Joe's ADFIND tool if you like but let's not ... it'll almost certainly irritate him :-) The iterations of the above query would be something along the lines of - 1. Query with search stats using the DN - record results 2. Query with search stats using the GUID (syntax above) - record, compare and post the results back here :) ... (now for the part that'll require courage or no courage at all and a suitable lab environment) 3. Index the attribute - wait for the index to complete construction - you can determine completion by checking the DS event log for something along the lines of: An index on the attribute index ID index name was created 4. repeats steps 1 2 - record, compare and post the results back here Deano -- Dean Wells MSEtechnology * Email: [EMAIL PROTECTED] http://msetechnology.com http://msetechnology.com/ From: Holland Matthew BC GB [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 09, 2004 10:55 AM To: [EMAIL PROTECTED] Cc: 'Eric Fleischman'; [EMAIL PROTECTED] Subject: RE: [ActiveDir] Indexing an attribute The gain we are seeking is to speed up the LDAP query. The background: We have a scheduled process that populates groups with members based upon matching results from LDAP queries for department, location and country-name (c) Example: Search filter for country 'mycountry' is ((objectCategory=user)(c=mycountry))) Results from query populate a group called mycountry-allusers Although location was indexed, c and department so the process was unacceptably slow as we use the domain root as a SearchBase, hence we decided to index these two attributes - which solved the problem! Now we have a new requirement to populate groups with members based upon the Mail Storage Group /Server hence we want to query the HomeMDB attribute. Or course, this is again slow due to the attribute not being indexed. This raised a small concern of indexing a DN attribute and what the impact of this would be. It would be great to get your thoughts, let me know (after your next shower maybe ;-)). Thanks for your help! Matty From: joe [mailto:[EMAIL PROTECTED] Sent: 09 November 2004 15:22 To: [EMAIL PROTECTED] Cc: 'Eric Fleischman'; [EMAIL PROTECTED] Subject: RE: [ActiveDir] Indexing an attribute You know though as I took a shower and thought about this[1]. This is a DN attribute, I am wondering if indexing may not help a lot or at all; not that I implied it would be any great help below. I look forward to reading a response from the likes of Dean or ~Eric and what they have to say. joe [1] Yes sick I know. I would read books in the shower too if I could figure out a way to keep the pages dry. Showers are a huge waste of time, right behind commuting if you drive yourself though I refuse to take short showers both for the benefit of those around me and because I feel hot showers are the culmination of great western civilization. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joe Sent: Tuesday, November 09, 2004 6:03 AM To: [EMAIL PROTECTED] Subject: RE: [ActiveDir] Indexing an attribute You will have a little DIT growth, creation of new mailboxes might be impacted a little in terms of speed as insertion of the attribute might be a trifle slower (nothing you would notice I expect unless doing a ton of new creations quickly with MT C code and still you could blame it on the RUS
RE: [ActiveDir] Indexing an attribute
Keep up you old guy, I recommended that Dean you need to be in Redmond. Hop a plane. :o) joe From: [EMAIL PROTECTED] on behalf of Dean WellsSent: Tue 11/9/2004 12:24 PMTo: Send - AD mailing listSubject: RE: [ActiveDir] Indexing an attribute OK, so is there a reason that I'm missing as to why we can't use the BL'd attribute? -- Dean Wells MSEtechnology* Email: dwells@msetechnology.com http://msetechnology.com From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of listmailSent: Tuesday, November 09, 2004 12:19 PMTo: [EMAIL PROTECTED]; Send - AD mailing listSubject: RE: [ActiveDir] Indexing an attribute It is linked. homeMDB and homeMDBBL. Not using adfind will not irritate me at all. Go ahead and use dsquery... oh wait, that doesn't do search stats. Use search.vbs... oh oops... I guess you are stuck with ldp if you don't use adfind. ;oP joe From: [EMAIL PROTECTED] on behalf of Dean WellsSent: Tue 11/9/2004 11:57 AMTo: Send - AD mailing listSubject: RE: [ActiveDir] Indexing an attribute First and foremost, I assume the attribute in question isn't linked ... there, I've asked the obvious. Assuming it is not; that's an interesting question. I can't say that I've thought about this before. AD would be performing minor trickery if indexing were to help since attributes using DN syntax are maintained internally using the DNT ... not that the trickery required is hard to do but I don't know if it would since I haven't tried. In all honesty, I don't hold out much hope but I also don't have a large enough DIT to hand at the moment to test against. One idea did jump out at met though ... perhaps you'd like to try a few iterations of the query below - ((objectcategory=person)(homeMDB=GUID=04F46C422FC4AA4190D2B2096CD6946D)) ... obviously, replace the GUID I've used above with the GUID of the DN you are querying upon. I'd like to see the results using the "search stats" control (1.2.840.113556.1.4.970) for accuracy (you could use Joe's ADFIND tool if you like but let's not ... it'll almost certainly irritate him :-) The iterations of the above query would be something along the lines of - 1. Query with search stats using the DN - record results 2. Query with search stats using the GUID (syntax above) - record, compare and post the results back here :) ... (now for the part that'll require courage or no courage at all and a suitable lab environment) 3. Index the attribute - wait for the index to complete construction - you can determine completion by checking the DS event log for something along the lines of: "An index on the attribute index ID index name was created" 4. repeats steps 1 2 - record, compare and post the results back here Deano -- Dean Wells MSEtechnology* Email: dwells@msetechnology.com http://msetechnology.com From: Holland Matthew BC GB [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 09, 2004 10:55 AMTo: [EMAIL PROTECTED]Cc: 'Eric Fleischman'; [EMAIL PROTECTED]Subject: RE: [ActiveDir] Indexing an attribute The gain we are seeking is to speed up the LDAP query. The background: We have a scheduled process that populates groups with members based upon matching results from LDAP queries for department, location and country-name (c) Example: Search filter for country mycountry is ((objectCategory=user)(c=mycountry))) Results from query populate a group called mycountry-allusers Although location was indexed, c and department so the process was unacceptably slow as we use the domain root as a SearchBase, hence we decided to index these two attributes which solved the problem! Now we have a new requirement to populate groups with members based upon the Mail Storage Group /Server hence we want to query the HomeMDB attribute. Or course, this is again slow due to the attribute not being indexed. This raised a small concern of indexing a DN attribute and what the impact of this would be. It would be great to get your thoughts, let me know (after your next shower maybe ;-)). Thanks for your help! Matty From: joe [mailto:[EMAIL PROTECTED] Sent: 09 November 2004 15:22To: [EMAIL PROTECTED]Cc: 'Eric Fleischman'; [EMAIL PROTECTED]Subject: RE: [ActiveDir] Indexing an attribute You know though as I took a shower and thought about this[1]. This is a DN attribute, I am wondering if indexing may not help a lot or at all; not that I implied it would be any great help below. I look forward to reading a response from the likes of Dean or ~Eric and what they have to say. joe [1] Yes sick I know. I would read books in the shower too if I could figure out a way to keep the pages dry. Showers area huge waste of time, right behind commuting if you drive yourself though I refuse to take short showers both for the benefit of those around me and because I feel hot showers are the culmination of great western civilization. From: [EMAIL PROTECTED] [mailto:[EMAIL
RE: [ActiveDir] LDP does not return modifyTimeStamp attribute...
Because you didn't request it. That one needs to be specifically requested, you can instead use whenChanged which is returned in the default * set. joe From: [EMAIL PROTECTED] on behalf of ADSent: Tue 11/9/2004 4:24 PMTo: [EMAIL PROTECTED]Subject: [ActiveDir] LDP does not return modifyTimeStamp attribute... Does anyone know why LDP does not return the modifyTimeStamp attribute?
RE: [ActiveDir] LDP does not return modifyTimeStamp attribute...
Nope. Not every attribute is returned. I don't know personally what the logic is that specifies what is returned and what isn't. I would like to think it is something you can query out of the schema but I have never seen anything to substantiate that thought. It is easy to see it in action though, query the schema on 2K and do the same on K3. You will certain attribs on certain objects returned in 2K but not in K3, you have to ask for them meaning that MS backed out the default return set. Why I don't know but helped someone with an App that blew up because of it. I don't recall exactly what the attribute was though, I purposely forgot it so I could have enough room in my head to remember the thing about ntsecuritydescriptors... What about ntsecuritydescriptors you ask? ntsecuritydescriptor should be on every object but when have you seen a query where you didn't specifically specify you needed it that it did get returned? Answer, you have to ask for it. With adfind you would do something like adfind -b somebase -f somefilter * ntsecuritydescriptor That will return what I call the * set (star set) and also the ntsecuritydescriptor attribute. I started to talk to ~Eric about this once before but I don't think we ever got to the part of the discussion concerning how it was determined what is returned and what isn't. joe From: [EMAIL PROTECTED] on behalf of ADSent: Tue 11/9/2004 6:00 PMTo: [EMAIL PROTECTED]Subject: RE: [ActiveDir] LDP does not return modifyTimeStamp attribute... Hmm, I am a little bit confused joe. I did not ask for msExchAlObjectVersion but it returns it anyways. Isn't LDP suppose to return every attribute that is set for a an object? Thanks From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of listmailSent: Tuesday, November 09, 2004 4:31 PMTo: [EMAIL PROTECTED]; [EMAIL PROTECTED]Subject: RE: [ActiveDir] LDP does not return modifyTimeStamp attribute... Because you didn't request it. That one needs to be specifically requested, you can instead use whenChanged which is returned in the default * set. joe From: [EMAIL PROTECTED] on behalf of ADSent: Tue 11/9/2004 4:24 PMTo: [EMAIL PROTECTED]Subject: [ActiveDir] LDP does not return modifyTimeStamp attribute... Does anyone know why LDP does not return the modifyTimeStamp attribute?
RE: [ActiveDir] LDP does not return modifyTimeStamp attribute...
Understoodon the constructed. Though it makes you wonder why that one is and whenChanged isn't. :o) How about the overall more general question, is there a way to ascertain what would and wouldn't be displayed? For instance, isthere something "query-able" that tells me ntsecuritydescriptor would or wouldn't be displayed. joe From: [EMAIL PROTECTED] on behalf of Eric FleischmanSent: Tue 11/9/2004 6:19 PMTo: [EMAIL PROTECTED]Subject: RE: [ActiveDir] LDP does not return modifyTimeStamp attribute... In this case: Dn: CN=Modify-Time-Stamp,CN=Schema,CN=Configuration,DC=corp,DC=microsoft,DC=com 1 lDAPDisplayName: modifyTimeStamp; 1 systemFlags: 0x814 = ( FLAG_ATTR_IS_CONSTRUCTED | FLAG_SCHEMA_BASE_OBJECT | FLAG_DOMAIN_DISALLOW_RENAME ); Constructed attributes are only returned 1) If requested AND 2) if requested in a base search against the object ~Eric From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of listmailSent: Tuesday, November 09, 2004 5:16 PMTo: [EMAIL PROTECTED]; [EMAIL PROTECTED]Subject: RE: [ActiveDir] LDP does not return modifyTimeStamp attribute... Nope. Not every attribute is returned. I don't know personally what the logic is that specifies what is returned and what isn't. I would like to think it is something you can query out of the schema but I have never seen anything to substantiate that thought. It is easy to see it in action though, query the schema on 2K and do the same on K3. You will certain attribs on certain objects returned in 2K but not in K3, you have to ask for them meaning that MS backed out the default return set. Why I don't know but helped someone with an App that blew up because of it. I don't recall exactly what the attribute was though, I purposely forgot it so I could have enough room in my head to remember the thing about ntsecuritydescriptors... What about ntsecuritydescriptors you ask? ntsecuritydescriptor should be on every object but when have you seen a query where you didn't specifically specify you needed it that it did get returned? Answer, you have to ask for it. With adfind you would do something like adfind -b somebase -f somefilter * ntsecuritydescriptor That will return what I call the * set (star set) and also the ntsecuritydescriptor attribute. I started to talk to ~Eric about this once before but I don't think we ever got to the part of the discussion concerning how it was determined what is returned and what isn't. joe From: [EMAIL PROTECTED] on behalf of ADSent: Tue 11/9/2004 6:00 PMTo: [EMAIL PROTECTED]Subject: RE: [ActiveDir] LDP does not return modifyTimeStamp attribute... Hmm, I am a little bit confused joe. I did not ask for msExchAlObjectVersion but it returns it anyways. Isn't LDP suppose to return every attribute that is set for a an object? Thanks From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of listmailSent: Tuesday, November 09, 2004 4:31 PMTo: [EMAIL PROTECTED]; [EMAIL PROTECTED]Subject: RE: [ActiveDir] LDP does not return modifyTimeStamp attribute... Because you didn't request it. That one needs to be specifically requested, you can instead use whenChanged which is returned in the default * set. joe From: [EMAIL PROTECTED] on behalf of ADSent: Tue 11/9/2004 4:24 PMTo: [EMAIL PROTECTED]Subject: [ActiveDir] LDP does not return modifyTimeStamp attribute... Does anyone know why LDP does not return the modifyTimeStamp attribute?
Re: [ActiveDir] Domain Local Group
In mixed mode, Domain Local Groups have scope only on Domain Controllers like with NT4. In Native mode, any machine in the domain can use the groups. What exactly can they be used for? Can I create a DLG and add global groups and assign permissions? Can I assign sql2000 permissons According to this article, I should be able to... Or am I reading it wrong? http://msdn.microsoft.com/library/default.asp?url=/library/en-us/modcore /html/deconWindowsNTSQLServerLogins.asp I created a dlg and assigned it to a db and it didn't work. I am in mixed mode. Does that affect it? Sp2 affect it? Thanks for any info Jenn List info : http://www.activedir.org/mail_list.htm List FAQ: http://www.activedir.org/list_faq.htm List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/mail_list.htm List FAQ: http://www.activedir.org/list_faq.htm List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/
