Re: RE : RE: RE : RE: [ActiveDir] AD LDAP Logging.
Check out the TechNet Webcast: Active Directory Performance Measurement and Troubleshooting—Level 300 at http://www.microsoft.com/events/series/adaug.mspx. On 6/10/06, Yann <[EMAIL PROTECTED]> wrote: Hello, Gil, very very very usefull informations that u provided at DEC ad performance session. I just finished to study it. I highly recommend it because of videos that well explanied how to use spa, logman,etc..!. I'm eager to test your troubleshooting on monday ! :) A few questions... 1) Will spa comsumes lots of resources when starting analyze and generating reports ? 2) Can spa analyzes other DCs from one w2k3 box dedicated spa ? or must i install spa on each boxes that i want to trend ? 3) Could I see possible LDAP problem connectivities ("dirty" LDAP disconnections...) between my DC and a client ? 3) Can i schedule the analyzes for a few days to be sure to track ldap pb? and will it consumes hight resources ? Thanks, Yann Gil Kirkpatrick <[EMAIL PROTECTED]> a écrit : You can use SPA, or you can use logman and tracerpt to get detailed LDAP stats. SPA does a lot of analysis for you and diagnoses several classes of AD perf problems. Tracerpt will give you a fairly raw look at all the LDAP traffic. I covered all three in my DEC AD Performance session (which I didn't actually deliver at DEC :). Its available on the NetPro website at http://www.netpro.com/community/medialibrary.cfm. -gil From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Steve Linehan Sent: Friday, June 09, 2006 11:50 AM To: ActiveDir@mail.activedir.org Subject: RE: RE : RE: [ActiveDir] AD LDAP Logging. It is true that SPA is not localized but I believe the French version will be ok. The problem comes about with the localization of the perfmon data. If you have problems post back and we can try a few work arounds because we are only really interested in the trace data at this point which should not be impacted. Thanks, -Steve From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Yann Sent: Friday, June 09, 2006 11:31 AM To: ActiveDir@mail.activedir.org Subject: RE : RE: [ActiveDir] AD LDAP Logging. Thank you for your answer Steve. I will install spa on monday and see if i can log some ldpa activities (errors, connections pb,etc...). Will this version of spa work on a w2k3 sp1 French version ? Regards, Yann Steve Linehan <[EMAIL PROTECTED]> a écrit : I would suggest taking a look at Server Performance Advisor (SPA), assuming these are Windows Server 2003 DCs and using it to collect and analyze the data for the DCs in question. This tool combines performance counters and the tracing data that Joe is referring to which will allow you to get very detailed information on what is occurring. This tool will give you a peak into the new performance and monitoring capabilities that we are adding into the next versions of the OS. It will also give you hints on what we believe the performance problems are. One of these days when I get a chance I will try to write a blog entry on all of the things you can do with SPA. By the way it also collects information for other server roles as well such as IIS giving you tremendous amounts of detail found no where else. Yes event tracing is the future of not only performance monitoring but debugging difficult issues. You can download SPA from here: http://www.microsoft.com/downloads/details.aspx?FamilyID=09115420-8c9d-46b9-a9a5-9bffcd237da2&DisplayLang=en Thanks, -Steve From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joe Sent: Friday, June 09, 2006 9:35 AM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] AD LDAP Logging. Unfortunately the logging is very basic, it will not log LDAP errors from anything I have seen. This is something I have asked for from MSFT as well, very detailed LDAP logging like you can enable with some of the other directories. Usually I hear a response of use event tracing but I haven't gotten had a chance to really dig deep into that yet to see how useful it will be. It depends on the code is displaying error messages bit possibly a query timed out? That could be indicative of a very poor query. By default, if a query goes more than 2 minutes, it will get dropped. -- O'Reilly Active Directory Third Edition - http://www.joeware.net/win/ad3e.htm From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Yann Sent: Friday, June 09, 2006 9:42 AM To: ActiveDir@mail.activedir.org Subject: Re : [ActiveDir] AD LDAP Logging. Good point Joe. I will use perfmon to monitor the health of my DC. An nother question. The Web app timed out with this generic error "the serveur is down", where "the server" = mydc. At the time of the web app timed out, i saw no er
RE : RE: RE : RE: [ActiveDir] AD LDAP Logging.
Hello, Gil, very very very usefull informations that u provided at DEC ad performance session. I just finished to study it. I highly recommend it because of videos that well explanied how to use spa, logman,etc..!. I'm eager to test your troubleshooting on monday ! :) A few questions... 1) Will spa comsumes lots of resources when starting analyze and generating reports ? 2) Can spa analyzes other DCs from one w2k3 box dedicated spa ? or must i install spa on each boxes that i want to trend ? 3) Could I see possible LDAP problem connectivities ("dirty" LDAP disconnections...) between my DC and a client ? 3) Can i schedule the analyzes for a few days to be sure to track ldap pb? and will it consumes hight resources ? Thanks, Yann Gil Kirkpatrick <[EMAIL PROTECTED]> a écrit : You can use SPA, or you can use logman and tracerpt to get detailed LDAP stats. SPA does a lot of analysis for you and diagnoses several classes of AD perf problems. Tracerpt will give you a fairly raw look at all the LDAP traffic. I covered all three in my DEC AD Performance session (which I didn't actually deliver at DEC :). Its available on the NetPro website at http://www.netpro.com/community/medialibrary.cfm. -gil From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Steve LinehanSent: Friday, June 09, 2006 11:50 AMTo: ActiveDir@mail.activedir.orgSubject: RE: RE : RE: [ActiveDir] AD LDAP Logging. It is true that SPA is not localized but I believe the French version will be ok. The problem comes about with the localization of the perfmon data. If you have problems post back and we can try a few work arounds because we are only really interested in the trace data at this point which should not be impacted. Thanks, -Steve From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of YannSent: Friday, June 09, 2006 11:31 AMTo: ActiveDir@mail.activedir.orgSubject: RE : RE: [ActiveDir] AD LDAP Logging. Thank you for your answer Steve. I will install spa on monday and see if i can log some ldpa activities (errors, connections pb,etc...). Will this version of spa work on a w2k3 sp1 French version ? Regards, YannSteve Linehan <[EMAIL PROTECTED]> a écrit : I would suggest taking a look at Server Performance Advisor (SPA), assuming these are Windows Server 2003 DCs and using it to collect and analyze the data for the DCs in question. This tool combines performance counters and the tracing data that Joe is referring to which will allow you to get very detailed information on what is occurring. This tool will give you a peak into the new performance and monitoring capabilities that we are adding into the next versions of the OS. It will also give you hints on what we believe the performance problems are. One of these days when I get a chance I will try to write a blog entry on all of the things you can do with SPA. By the way it also collects information for other server roles as well such as IIS giving you tremendous amounts of detail found no where else. Yes event tracing is the future of not only performance monitoring but debugging difficult issues. You can download SPA from here:http://www.microsoft.com/downloads/details.aspx?FamilyID=09115420-8c9d-46b9-a9a5-9bffcd237da2&DisplayLang=en Thanks, -SteveFrom: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joeSent: Friday, June 09, 2006 9:35 AMTo: ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] AD LDAP Logging. Unfortunately the logging is very basic, it will not log LDAP errors from anything I have seen. This is something I have asked for from MSFT as well, very detailed LDAP logging like you can enable with some of the other directories. Usually I hear a response of use event tracing but I haven't gotten had a chance to really dig deep into that yet to see how useful it will be. It depends on the code is displaying error messages bit possibly a query timed out? That could be indicative of a very poor query. By default, if a query goes more than 2 minutes, it will get dropped. --O'Reilly Active Directory Third Edition - http://www.joeware.net/win/ad3e.htm From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of YannSent: Friday, June 09, 2006 9:42 AMTo: ActiveDir@mail.activedir.orgSubject: Re : [ActiveDir] AD LDAP Logging.Good point Joe. I will use perfmon to monitor the health of my DC. An nother question. The Web app timed out with this generic error "the serveur is down", where "the server" = mydc. At the time of the web app timed out, i saw no errors about ldap connections between my dc and the zope server. With the Field Engineering set to 5 and if the web app timed-out, will a LDAP error appear in my eventlogs that stat
RE: RE : RE: [ActiveDir] AD LDAP Logging.
You can use SPA, or you can use logman and tracerpt to get detailed LDAP stats. SPA does a lot of analysis for you and diagnoses several classes of AD perf problems. Tracerpt will give you a fairly raw look at all the LDAP traffic. I covered all three in my DEC AD Performance session (which I didn't actually deliver at DEC :). Its available on the NetPro website at http://www.netpro.com/community/medialibrary.cfm. -gil From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Steve LinehanSent: Friday, June 09, 2006 11:50 AMTo: ActiveDir@mail.activedir.orgSubject: RE: RE : RE: [ActiveDir] AD LDAP Logging. It is true that SPA is not localized but I believe the French version will be ok. The problem comes about with the localization of the perfmon data. If you have problems post back and we can try a few work arounds because we are only really interested in the trace data at this point which should not be impacted. Thanks, -Steve From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of YannSent: Friday, June 09, 2006 11:31 AMTo: ActiveDir@mail.activedir.orgSubject: RE : RE: [ActiveDir] AD LDAP Logging. Thank you for your answer Steve. I will install spa on monday and see if i can log some ldpa activities (errors, connections pb,etc...). Will this version of spa work on a w2k3 sp1 French version ? Regards, YannSteve Linehan <[EMAIL PROTECTED]> a écrit : I would suggest taking a look at Server Performance Advisor (SPA), assuming these are Windows Server 2003 DCs and using it to collect and analyze the data for the DCs in question. This tool combines performance counters and the tracing data that Joe is referring to which will allow you to get very detailed information on what is occurring. This tool will give you a peak into the new performance and monitoring capabilities that we are adding into the next versions of the OS. It will also give you hints on what we believe the performance problems are. One of these days when I get a chance I will try to write a blog entry on all of the things you can do with SPA. By the way it also collects information for other server roles as well such as IIS giving you tremendous amounts of detail found no where else. Yes event tracing is the future of not only performance monitoring but debugging difficult issues. You can download SPA from here: http://www.microsoft.com/downloads/details.aspx?FamilyID=09115420-8c9d-46b9-a9a5-9bffcd237da2&DisplayLang=en Thanks, -Steve From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joeSent: Friday, June 09, 2006 9:35 AMTo: ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] AD LDAP Logging. Unfortunately the logging is very basic, it will not log LDAP errors from anything I have seen. This is something I have asked for from MSFT as well, very detailed LDAP logging like you can enable with some of the other directories. Usually I hear a response of use event tracing but I haven't gotten had a chance to really dig deep into that yet to see how useful it will be. It depends on the code is displaying error messages bit possibly a query timed out? That could be indicative of a very poor query. By default, if a query goes more than 2 minutes, it will get dropped. -- O'Reilly Active Directory Third Edition - http://www.joeware.net/win/ad3e.htm From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of YannSent: Friday, June 09, 2006 9:42 AMTo: ActiveDir@mail.activedir.orgSubject: Re : [ActiveDir] AD LDAP Logging. Good point Joe. I will use perfmon to monitor the health of my DC. An nother question. The Web app timed out with this generic error "the serveur is down", where "the server" = mydc. At the time of the web app timed out, i saw no errors about ldap connections between my dc and the zope server. With the Field Engineering set to 5 and if the web app timed-out, will a LDAP error appear in my eventlogs that stated a disconnection occured ? Thanks for taking time to reply, Cheers, Yann - Message d'origine De : joe <[EMAIL PROTECTED]>À : ActiveDir@mail.activedir.orgEnvoyé le : Vendredi, 9 Juin 2006, 2h25mn 26sObjet : RE: [ActiveDir] AD LDAP Logging. When you change that threshhold you are specifying how expensive you want the query to be before AD reports it. Changing "Expensive" to 1, according to the docs means that as soon as a query has to look at one or more entries it will be logged. So when
RE: RE : RE: [ActiveDir] AD LDAP Logging.
It is true that SPA is not localized but I believe the French version will be ok. The problem comes about with the localization of the perfmon data. If you have problems post back and we can try a few work arounds because we are only really interested in the trace data at this point which should not be impacted. Thanks, -Steve From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Yann Sent: Friday, June 09, 2006 11:31 AM To: ActiveDir@mail.activedir.org Subject: RE : RE: [ActiveDir] AD LDAP Logging. Thank you for your answer Steve. I will install spa on monday and see if i can log some ldpa activities (errors, connections pb,etc...). Will this version of spa work on a w2k3 sp1 French version ? Regards, Yann Steve Linehan <[EMAIL PROTECTED]> a écrit : I would suggest taking a look at Server Performance Advisor (SPA), assuming these are Windows Server 2003 DCs and using it to collect and analyze the data for the DCs in question. This tool combines performance counters and the tracing data that Joe is referring to which will allow you to get very detailed information on what is occurring. This tool will give you a peak into the new performance and monitoring capabilities that we are adding into the next versions of the OS. It will also give you hints on what we believe the performance problems are. One of these days when I get a chance I will try to write a blog entry on all of the things you can do with SPA. By the way it also collects information for other server roles as well such as IIS giving you tremendous amounts of detail found no where else. Yes event tracing is the future of not only performance monitoring but debugging difficult issues. You can download SPA from here: http://www.microsoft.com/downloads/details.aspx?FamilyID=09115420-8c9d-46b9-a9a5-9bffcd237da2&DisplayLang=en Thanks, -Steve From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joe Sent: Friday, June 09, 2006 9:35 AM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] AD LDAP Logging. Unfortunately the logging is very basic, it will not log LDAP errors from anything I have seen. This is something I have asked for from MSFT as well, very detailed LDAP logging like you can enable with some of the other directories. Usually I hear a response of use event tracing but I haven't gotten had a chance to really dig deep into that yet to see how useful it will be. It depends on the code is displaying error messages bit possibly a query timed out? That could be indicative of a very poor query. By default, if a query goes more than 2 minutes, it will get dropped. -- O'Reilly Active Directory Third Edition - http://www.joeware.net/win/ad3e.htm From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Yann Sent: Friday, June 09, 2006 9:42 AM To: ActiveDir@mail.activedir.org Subject: Re : [ActiveDir] AD LDAP Logging. Good point Joe. I will use perfmon to monitor the health of my DC. An nother question. The Web app timed out with this generic error "the serveur is down", where "the server" = mydc. At the time of the web app timed out, i saw no errors about ldap connections between my dc and the zope server. With the Field Engineering set to 5 and if the web app timed-out, will a LDAP error appear in my eventlogs that stated a disconnection occured ? Thanks for taking time to reply, Cheers, Yann - Message d'origine De : joe <[EMAIL PROTECTED]> À : ActiveDir@mail.activedir.org Envoyé le : Vendredi, 9 Juin 2006, 2h25mn 26s Objet : RE: [ActiveDir] AD LDAP Logging. When you change that threshhold you are specifying how expensive you want the query to be before AD reports it. Changing "Expensive" to 1, according to the docs means that as soon as a query has to look at one or more entries it will be logged. So when you turn down that value, you are telling it to log pretty much everything. That being said, unless you have changed your schema, objectclass isn't indexed and a filter with no indexed attributes is generally considered inefficient unless it is properly scoped. The fact that you are returning 58 of 63 entries means that that isn't too bad, but just the same, I would work on getting the query changed to using an indexed attribute or more likely, because so many apps/scripts screw up around objectclass, indexing objectclass AND getting the query changed. When you see big noticable deltas in how long the same query takes to run, it is usually a couple of things that could be at fault, possibly Eric wil
RE : RE: [ActiveDir] AD LDAP Logging.
Thank you for your answer Steve. I will install spa on monday and see if i can log some ldpa activities (errors, connections pb,etc...). Will this version of spa work on a w2k3 sp1 French version ? Regards, YannSteve Linehan <[EMAIL PROTECTED]> a écrit : I would suggest taking a look at Server Performance Advisor (SPA), assuming these are Windows Server 2003 DCs and using it to collect and analyze the data for the DCs in question. This tool combines performance counters and the tracing data that Joe is referring to which will allow you to get very detailed information on what is occurring. This tool will give you a peak into the new performance and monitoring capabilities that we are adding into the next versions of the OS. It will also give you hints on what we believe the performance problems are. One of these days when I get a chance I will try to write a blog entry on all of the things you can do with SPA. By the way it also collects information for other server roles as well such as IIS giving you tremendous amounts of detail found no where else. Yes event tracing is the future of not only performance monitoring but debugging difficult issues. You can download SPA from here: http://www.microsoft.com/downloads/details.aspx?FamilyID=09115420-8c9d-46b9-a9a5-9bffcd237da2&DisplayLang=en Thanks, -Steve From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joeSent: Friday, June 09, 2006 9:35 AMTo: ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] AD LDAP Logging. Unfortunately the logging is very basic, it will not log LDAP errors from anything I have seen. This is something I have asked for from MSFT as well, very detailed LDAP logging like you can enable with some of the other directories. Usually I hear a response of use event tracing but I haven't gotten had a chance to really dig deep into that yet to see how useful it will be. It depends on the code is displaying error messages bit possibly a query timed out? That could be indicative of a very poor query. By default, if a query goes more than 2 minutes, it will get dropped. -- O'Reilly Active Directory Third Edition - http://www.joeware.net/win/ad3e.htm From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of YannSent: Friday, June 09, 2006 9:42 AMTo: ActiveDir@mail.activedir.orgSubject: Re : [ActiveDir] AD LDAP Logging. Good point Joe. I will use perfmon to monitor the health of my DC.An nother question. The Web app timed out with this generic error "the serveur is down", where "the server" = mydc.At the time of the web app timed out, i saw no errors about ldap connections between my dc and the zope server. With the Field Engineering set to 5 and if the web app timed-out, will a LDAP error appear in my eventlogs that stated a disconnection occured ? Thanks for taking time to reply, Cheers, Yann - Message d'origine De : joe <[EMAIL PROTECTED]>À : ActiveDir@mail.activedir.orgEnvoyé le : Vendredi, 9 Juin 2006, 2h25mn 26sObjet : RE: [ActiveDir] AD LDAP Logging. When you change that threshhold you are specifying how expensive you want the query to be before AD reports it. Changing "Expensive" to 1, according to the docs means that as soon as a query has to look at one or more entries it will be logged. So when you turn down that value, you are telling it to log pretty much everything. That being said, unless you have changed your schema, objectclass isn't indexed and a filter with no indexed attributes is generally considered inefficient unless it is properly scoped. The fact that you are returning 58 of 63 entries means that that isn't too bad, but just the same, I would work on getting the query changed to using an indexed attribute or more likely, because so many apps/scripts screw up around objectclass, indexing objectclass AND getting the query changed. When you see big noticable deltas in how long the same query takes to run, it is usually a couple of things that could be at fault, possibly Eric will pipe in with more. The first is that the DC is tied up with something else and just can't give you the proc time, the other is that it has to go to disk instead of pulling from cache. Either way you should be looking at your perf counters to see how the DC is performing. I tend to really look at disk counters because that is where it often falls down at. Things like disk queue and and number of read ops for the DIT drive (write ops are usually a rounding error except during heavy population periods) are the things I immediately focus on. Just seeing the number of read ops doesn't help, you have to understand your disk architecture because on some systems 500 read ops may be just fine, but on others it could be over what the disk system is capable of sustaining s
RE: Re : [ActiveDir] AD LDAP Logging.
Perfomon trace logs will generate the raw binary trace data but it has to be processed. The easiest way to get at this data is to use SPA which will collect the binary trace data and process it into human readable format. Thanks, -Steve From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Yann Sent: Friday, June 09, 2006 10:09 AM To: ActiveDir@mail.activedir.org Subject: Re : [ActiveDir] AD LDAP Logging. Ok thanks. When you said "..use event tracing ...", do you mean using Perfmon Trace Logs ? - Message d'origine De : joe <[EMAIL PROTECTED]> À : ActiveDir@mail.activedir.org Envoyé le : Vendredi, 9 Juin 2006, 4h34mn 33s Objet : RE: [ActiveDir] AD LDAP Logging. Unfortunately the logging is very basic, it will not log LDAP errors from anything I have seen. This is something I have asked for from MSFT as well, very detailed LDAP logging like you can enable with some of the other directories. Usually I hear a response of use event tracing but I haven't gotten had a chance to really dig deep into that yet to see how useful it will be. It depends on the code is displaying error messages bit possibly a query timed out? That could be indicative of a very poor query. By default, if a query goes more than 2 minutes, it will get dropped. -- O'Reilly Active Directory Third Edition - http://www.joeware.net/win/ad3e.htm From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Yann Sent: Friday, June 09, 2006 9:42 AM To: ActiveDir@mail.activedir.org Subject: Re : [ActiveDir] AD LDAP Logging. Good point Joe. I will use perfmon to monitor the health of my DC. An nother question. The Web app timed out with this generic error "the serveur is down", where "the server" = mydc. At the time of the web app timed out, i saw no errors about ldap connections between my dc and the zope server. With the Field Engineering set to 5 and if the web app timed-out, will a LDAP error appear in my eventlogs that stated a disconnection occured ? Thanks for taking time to reply, Cheers, Yann - Message d'origine De : joe <[EMAIL PROTECTED]> À : ActiveDir@mail.activedir.org Envoyé le : Vendredi, 9 Juin 2006, 2h25mn 26s Objet : RE: [ActiveDir] AD LDAP Logging. When you change that threshhold you are specifying how expensive you want the query to be before AD reports it. Changing "Expensive" to 1, according to the docs means that as soon as a query has to look at one or more entries it will be logged. So when you turn down that value, you are telling it to log pretty much everything. That being said, unless you have changed your schema, objectclass isn't indexed and a filter with no indexed attributes is generally considered inefficient unless it is properly scoped. The fact that you are returning 58 of 63 entries means that that isn't too bad, but just the same, I would work on getting the query changed to using an indexed attribute or more likely, because so many apps/scripts screw up around objectclass, indexing objectclass AND getting the query changed. When you see big noticable deltas in how long the same query takes to run, it is usually a couple of things that could be at fault, possibly Eric will pipe in with more. The first is that the DC is tied up with something else and just can't give you the proc time, the other is that it has to go to disk instead of pulling from cache. Either way you should be looking at your perf counters to see how the DC is performing. I tend to really look at disk counters because that is where it often falls down at. Things like disk queue and and number of read ops for the DIT drive (write ops are usually a rounding error except during heavy population periods) are the things I immediately focus on. Just seeing the number of read ops doesn't help, you have to understand your disk architecture because on some systems 500 read ops may be just fine, but on others it could be over what the disk system is capable of sustaining so you start backing up. As a quick rule of thumb I start with the assumption that each spindle that is part of the volume gives you 100 IOPS capability. That can be generous so if you are on the edge keep that in mind, but if you are at 20 OPS and you have 8 spindles in a RAID 0+1 it is unlikely disk is your bottleneck[1] and the disk queues should bear that out. Of course I tend to focus on disk because I memory is almost always boosted up there because most people realize how important RAM is but only folks who think about Exchange tend to think about disk and the only guideline I have seen from MSFT recommends 3 RAID-1 sets for anything above several thousand users which I don't feel is very good. Again, as a general rule I would rather see a single RA
RE: [ActiveDir] AD LDAP Logging.
I would suggest taking a look at Server Performance Advisor (SPA), assuming these are Windows Server 2003 DCs and using it to collect and analyze the data for the DCs in question. This tool combines performance counters and the tracing data that Joe is referring to which will allow you to get very detailed information on what is occurring. This tool will give you a peak into the new performance and monitoring capabilities that we are adding into the next versions of the OS. It will also give you hints on what we believe the performance problems are. One of these days when I get a chance I will try to write a blog entry on all of the things you can do with SPA. By the way it also collects information for other server roles as well such as IIS giving you tremendous amounts of detail found no where else. Yes event tracing is the future of not only performance monitoring but debugging difficult issues. You can download SPA from here: http://www.microsoft.com/downloads/details.aspx?FamilyID=09115420-8c9d-46b9-a9a5-9bffcd237da2&DisplayLang=en Thanks, -Steve From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joe Sent: Friday, June 09, 2006 9:35 AM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] AD LDAP Logging. Unfortunately the logging is very basic, it will not log LDAP errors from anything I have seen. This is something I have asked for from MSFT as well, very detailed LDAP logging like you can enable with some of the other directories. Usually I hear a response of use event tracing but I haven't gotten had a chance to really dig deep into that yet to see how useful it will be. It depends on the code is displaying error messages bit possibly a query timed out? That could be indicative of a very poor query. By default, if a query goes more than 2 minutes, it will get dropped. -- O'Reilly Active Directory Third Edition - http://www.joeware.net/win/ad3e.htm From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Yann Sent: Friday, June 09, 2006 9:42 AM To: ActiveDir@mail.activedir.org Subject: Re : [ActiveDir] AD LDAP Logging. Good point Joe. I will use perfmon to monitor the health of my DC. An nother question. The Web app timed out with this generic error "the serveur is down", where "the server" = mydc. At the time of the web app timed out, i saw no errors about ldap connections between my dc and the zope server. With the Field Engineering set to 5 and if the web app timed-out, will a LDAP error appear in my eventlogs that stated a disconnection occured ? Thanks for taking time to reply, Cheers, Yann - Message d'origine De : joe <[EMAIL PROTECTED]> À : ActiveDir@mail.activedir.org Envoyé le : Vendredi, 9 Juin 2006, 2h25mn 26s Objet : RE: [ActiveDir] AD LDAP Logging. When you change that threshhold you are specifying how expensive you want the query to be before AD reports it. Changing "Expensive" to 1, according to the docs means that as soon as a query has to look at one or more entries it will be logged. So when you turn down that value, you are telling it to log pretty much everything. That being said, unless you have changed your schema, objectclass isn't indexed and a filter with no indexed attributes is generally considered inefficient unless it is properly scoped. The fact that you are returning 58 of 63 entries means that that isn't too bad, but just the same, I would work on getting the query changed to using an indexed attribute or more likely, because so many apps/scripts screw up around objectclass, indexing objectclass AND getting the query changed. When you see big noticable deltas in how long the same query takes to run, it is usually a couple of things that could be at fault, possibly Eric will pipe in with more. The first is that the DC is tied up with something else and just can't give you the proc time, the other is that it has to go to disk instead of pulling from cache. Either way you should be looking at your perf counters to see how the DC is performing. I tend to really look at disk counters because that is where it often falls down at. Things like disk queue and and number of read ops for the DIT drive (write ops are usually a rounding error except during heavy population periods) are the things I immediately focus on. Just seeing the number of read ops doesn't help, you have to understand your disk architecture because on some systems 500 read ops may be just fine, but on others it could be over what the disk system is capable of sustaining so you start backing up. As a quick rule of thumb I start with the assumption that each spindle that is part of the volume gives you 100 IOPS capability. That can be generous so if you are on the edge keep that in mind, but if you are
Re : [ActiveDir] AD LDAP Logging.
Ok thanks. When you said "..use event tracing ...", do you mean using Perfmon Trace Logs ? - Message d'origine De : joe <[EMAIL PROTECTED]>À : ActiveDir@mail.activedir.orgEnvoyé le : Vendredi, 9 Juin 2006, 4h34mn 33sObjet : RE: [ActiveDir] AD LDAP Logging. Unfortunately the logging is very basic, it will not log LDAP errors from anything I have seen. This is something I have asked for from MSFT as well, very detailed LDAP logging like you can enable with some of the other directories. Usually I hear a response of use event tracing but I haven't gotten had a chance to really dig deep into that yet to see how useful it will be. It depends on the code is displaying error messages bit possibly a query timed out? That could be indicative of a very poor query. By default, if a query goes more than 2 minutes, it will get dropped. -- O'Reilly Active Directory Third Edition - http://www.joeware.net/win/ad3e.htm From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of YannSent: Friday, June 09, 2006 9:42 AMTo: ActiveDir@mail.activedir.orgSubject: Re : [ActiveDir] AD LDAP Logging. Good point Joe. I will use perfmon to monitor the health of my DC. An nother question. The Web app timed out with this generic error "the serveur is down", where "the server" = mydc. At the time of the web app timed out, i saw no errors about ldap connections between my dc and the zope server. With the Field Engineering set to 5 and if the web app timed-out, will a LDAP error appear in my eventlogs that stated a disconnection occured ? Thanks for taking time to reply, Cheers, Yann - Message d'origine De : joe <[EMAIL PROTECTED]>À : ActiveDir@mail.activedir.orgEnvoyé le : Vendredi, 9 Juin 2006, 2h25mn 26sObjet : RE: [ActiveDir] AD LDAP Logging. When you change that threshhold you are specifying how expensive you want the query to be before AD reports it. Changing "Expensive" to 1, according to the docs means that as soon as a query has to look at one or more entries it will be logged. So when you turn down that value, you are telling it to log pretty much everything. That being said, unless you have changed your schema, objectclass isn't indexed and a filter with no indexed attributes is generally considered inefficient unless it is properly scoped. The fact that you are returning 58 of 63 entries means that that isn't too bad, but just the same, I would work on getting the query changed to using an indexed attribute or more likely, because so many apps/scripts screw up around objectclass, indexing objectclass AND getting the query changed. When you see big noticable deltas in how long the same query takes to run, it is usually a couple of things that could be at fault, possibly Eric will pipe in with more. The first is that the DC is tied up with something else and just can't give you the proc time, the other is that it has to go to disk instead of pulling from cache. Either way you should be looking at your perf counters to see how the DC is performing. I tend to really look at disk counters because that is where it often falls down at. Things like disk queue and and number of read ops for the DIT drive (write ops are usually a rounding error except during heavy population periods) are the things I immediately focus on. Just seeing the number of read ops doesn't help, you have to understand your disk architecture because on some systems 500 read ops may be just fine, but on others it could be over what the disk system is capable of sustaining so you start backing up. As a quick rule of thumb I start with the assumption that each spindle that is part of the volume gives you 100 IOPS capability. That can be generous so if you are on the edge keep that in mind, but if you are at 20 OPS and you have 8 spindles in a RAID 0+1 it is unlikely disk is your bottleneck[1] and the disk queues should bear that out. Of course I tend to focus on disk because I memory is almost always boosted up there because most people realize how important RAM is but only folks who think about Exchange tend to think about disk and the only guideline I have seen from MSFT recommends 3 RAID-1 sets for anything above several thousand users which I don't feel is very good. Again, as a general rule I would rather see a single RAID 0+1 (or even better if you don't care about faul tolerance a RAID 0) or RAID-5 than 3 RAID-1's. But this is all just recanting a zillion conversations we have had here on the list about disk layouts. joe [1] Virtualization really screws with this from the disk standpoint because you need to look at counters for the physical machine and while your DC may not be generating many read ops, if other virtual machines are, you could be slowed down considerably by those without the Read Ops reflecting much on the individual DC. -- O'Reilly Active Directory
RE: [ActiveDir] AD LDAP Logging.
Unfortunately the logging is very basic, it will not log LDAP errors from anything I have seen. This is something I have asked for from MSFT as well, very detailed LDAP logging like you can enable with some of the other directories. Usually I hear a response of use event tracing but I haven't gotten had a chance to really dig deep into that yet to see how useful it will be. It depends on the code is displaying error messages bit possibly a query timed out? That could be indicative of a very poor query. By default, if a query goes more than 2 minutes, it will get dropped. -- O'Reilly Active Directory Third Edition - http://www.joeware.net/win/ad3e.htm From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of YannSent: Friday, June 09, 2006 9:42 AMTo: ActiveDir@mail.activedir.orgSubject: Re : [ActiveDir] AD LDAP Logging. Good point Joe. I will use perfmon to monitor the health of my DC. An nother question. The Web app timed out with this generic error "the serveur is down", where "the server" = mydc. At the time of the web app timed out, i saw no errors about ldap connections between my dc and the zope server. With the Field Engineering set to 5 and if the web app timed-out, will a LDAP error appear in my eventlogs that stated a disconnection occured ? Thanks for taking time to reply, Cheers, Yann - Message d'origine De : joe <[EMAIL PROTECTED]>À : ActiveDir@mail.activedir.orgEnvoyé le : Vendredi, 9 Juin 2006, 2h25mn 26sObjet : RE: [ActiveDir] AD LDAP Logging. When you change that threshhold you are specifying how expensive you want the query to be before AD reports it. Changing "Expensive" to 1, according to the docs means that as soon as a query has to look at one or more entries it will be logged. So when you turn down that value, you are telling it to log pretty much everything. That being said, unless you have changed your schema, objectclass isn't indexed and a filter with no indexed attributes is generally considered inefficient unless it is properly scoped. The fact that you are returning 58 of 63 entries means that that isn't too bad, but just the same, I would work on getting the query changed to using an indexed attribute or more likely, because so many apps/scripts screw up around objectclass, indexing objectclass AND getting the query changed. When you see big noticable deltas in how long the same query takes to run, it is usually a couple of things that could be at fault, possibly Eric will pipe in with more. The first is that the DC is tied up with something else and just can't give you the proc time, the other is that it has to go to disk instead of pulling from cache. Either way you should be looking at your perf counters to see how the DC is performing. I tend to really look at disk counters because that is where it often falls down at. Things like disk queue and and number of read ops for the DIT drive (write ops are usually a rounding error except during heavy population periods) are the things I immediately focus on. Just seeing the number of read ops doesn't help, you have to understand your disk architecture because on some systems 500 read ops may be just fine, but on others it could be over what the disk system is capable of sustaining so you start backing up. As a quick rule of thumb I start with the assumption that each spindle that is part of the volume gives you 100 IOPS capability. That can be generous so if you are on the edge keep that in mind, but if you are at 20 OPS and you have 8 spindles in a RAID 0+1 it is unlikely disk is your bottleneck[1] and the disk queues should bear that out. Of course I tend to focus on disk because I memory is almost always boosted up there because most people realize how important RAM is but only folks who think about Exchange tend to think about disk and the only guideline I have seen from MSFT recommends 3 RAID-1 sets for anything above several thousand users which I don't feel is very good. Again, as a general rule I would rather see a single RAID 0+1 (or even better if you don't care about faul tolerance a RAID 0) or RAID-5 than 3 RAID-1's. But this is all just recanting a zillion conversations we have had here on the list about disk layouts. joe [1] Virtualization really screws with this from the disk standpoint because you need to look at counters for the physical machine and while your DC may not be generating many read ops, if other virtual machines are, you could be slowed down considerably by those without the Read Ops reflecting much on the individual DC. -- O'Reilly Active Directory Third Edition - http://www.joeware.net/win/ad3e.htm From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of YannSent: Friday, June 09, 2006 5:31 AMTo: ActiveDir@mail.activedir.orgSubject: Re : [ActiveDir] AD LDA
Re : [ActiveDir] AD LDAP Logging.
Good point Joe. I will use perfmon to monitor the health of my DC. An nother question. The Web app timed out with this generic error "the serveur is down", where "the server" = mydc. At the time of the web app timed out, i saw no errors about ldap connections between my dc and the zope server. With the Field Engineering set to 5 and if the web app timed-out, will a LDAP error appear in my eventlogs that stated a disconnection occured ? Thanks for taking time to reply, Cheers, Yann - Message d'origine De : joe <[EMAIL PROTECTED]>À : ActiveDir@mail.activedir.orgEnvoyé le : Vendredi, 9 Juin 2006, 2h25mn 26sObjet : RE: [ActiveDir] AD LDAP Logging. When you change that threshhold you are specifying how expensive you want the query to be before AD reports it. Changing "Expensive" to 1, according to the docs means that as soon as a query has to look at one or more entries it will be logged. So when you turn down that value, you are telling it to log pretty much everything. That being said, unless you have changed your schema, objectclass isn't indexed and a filter with no indexed attributes is generally considered inefficient unless it is properly scoped. The fact that you are returning 58 of 63 entries means that that isn't too bad, but just the same, I would work on getting the query changed to using an indexed attribute or more likely, because so many apps/scripts screw up around objectclass, indexing objectclass AND getting the query changed. When you see big noticable deltas in how long the same query takes to run, it is usually a couple of things that could be at fault, possibly Eric will pipe in with more. The first is that the DC is tied up with something else and just can't give you the proc time, the other is that it has to go to disk instead of pulling from cache. Either way you should be looking at your perf counters to see how the DC is performing. I tend to really look at disk counters because that is where it often falls down at. Things like disk queue and and number of read ops for the DIT drive (write ops are usually a rounding error except during heavy population periods) are the things I immediately focus on. Just seeing the number of read ops doesn't help, you have to understand your disk architecture because on some systems 500 read ops may be just fine, but on others it could be over what the disk system is capable of sustaining so you start backing up. As a quick rule of thumb I start with the assumption that each spindle that is part of the volume gives you 100 IOPS capability. That can be generous so if you are on the edge keep that in mind, but if you are at 20 OPS and you have 8 spindles in a RAID 0+1 it is unlikely disk is your bottleneck[1] and the disk queues should bear that out. Of course I tend to focus on disk because I memory is almost always boosted up there because most people realize how important RAM is but only folks who think about Exchange tend to think about disk and the only guideline I have seen from MSFT recommends 3 RAID-1 sets for anything above several thousand users which I don't feel is very good. Again, as a general rule I would rather see a single RAID 0+1 (or even better if you don't care about faul tolerance a RAID 0) or RAID-5 than 3 RAID-1's. But this is all just recanting a zillion conversations we have had here on the list about disk layouts. joe [1] Virtualization really screws with this from the disk standpoint because you need to look at counters for the physical machine and while your DC may not be generating many read ops, if other virtual machines are, you could be slowed down considerably by those without the Read Ops reflecting much on the individual DC. -- O'Reilly Active Directory Third Edition - http://www.joeware.net/win/ad3e.htm From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of YannSent: Friday, June 09, 2006 5:31 AMTo: ActiveDir@mail.activedir.orgSubject: Re : [ActiveDir] AD LDAP Logging. Hello Tony, Very usefull information ! Thanks. i enabled this config: 15 Field Engineering to 5 Expensive Search Results Threshold to 1 Here are the LDAP operation, : 1644 INFORMATIONAL NTDS General Fri Jun 09 09:55:16 2006 childdomain\user1 Internal event: A client issued a search operation with the following options. Client: 11.22.33.44 Starting node: OU=MyOU OU=myou1 DC=childdomain DC=parentDomain DC=root DC=fr Filter: (objectClass=user) Search scope: subtree Attribute selection: givenName sAMAccountName sn Server controls: Visited entries: 63 Returned entries: 58 Followed by this: 1139 INFORMATIONAL NTDS LDAP Fri Jun 09 09:55:16 2006 childdomain\user1 Internal event: Function ldap_search completed with an elapsed time of 16 ms. => for 63 visited entries, only 58 are returned and the ldap search lasted 16 ms (Sometimes the ldap search took 140 ms.
RE: [ActiveDir] AD LDAP Logging.
When you change that threshhold you are specifying how expensive you want the query to be before AD reports it. Changing "Expensive" to 1, according to the docs means that as soon as a query has to look at one or more entries it will be logged. So when you turn down that value, you are telling it to log pretty much everything. That being said, unless you have changed your schema, objectclass isn't indexed and a filter with no indexed attributes is generally considered inefficient unless it is properly scoped. The fact that you are returning 58 of 63 entries means that that isn't too bad, but just the same, I would work on getting the query changed to using an indexed attribute or more likely, because so many apps/scripts screw up around objectclass, indexing objectclass AND getting the query changed. When you see big noticable deltas in how long the same query takes to run, it is usually a couple of things that could be at fault, possibly Eric will pipe in with more. The first is that the DC is tied up with something else and just can't give you the proc time, the other is that it has to go to disk instead of pulling from cache. Either way you should be looking at your perf counters to see how the DC is performing. I tend to really look at disk counters because that is where it often falls down at. Things like disk queue and and number of read ops for the DIT drive (write ops are usually a rounding error except during heavy population periods) are the things I immediately focus on. Just seeing the number of read ops doesn't help, you have to understand your disk architecture because on some systems 500 read ops may be just fine, but on others it could be over what the disk system is capable of sustaining so you start backing up. As a quick rule of thumb I start with the assumption that each spindle that is part of the volume gives you 100 IOPS capability. That can be generous so if you are on the edge keep that in mind, but if you are at 20 OPS and you have 8 spindles in a RAID 0+1 it is unlikely disk is your bottleneck[1] and the disk queues should bear that out. Of course I tend to focus on disk because I memory is almost always boosted up there because most people realize how important RAM is but only folks who think about Exchange tend to think about disk and the only guideline I have seen from MSFT recommends 3 RAID-1 sets for anything above several thousand users which I don't feel is very good. Again, as a general rule I would rather see a single RAID 0+1 (or even better if you don't care about faul tolerance a RAID 0) or RAID-5 than 3 RAID-1's. But this is all just recanting a zillion conversations we have had here on the list about disk layouts. joe [1] Virtualization really screws with this from the disk standpoint because you need to look at counters for the physical machine and while your DC may not be generating many read ops, if other virtual machines are, you could be slowed down considerably by those without the Read Ops reflecting much on the individual DC. -- O'Reilly Active Directory Third Edition - http://www.joeware.net/win/ad3e.htm From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of YannSent: Friday, June 09, 2006 5:31 AMTo: ActiveDir@mail.activedir.orgSubject: Re : [ActiveDir] AD LDAP Logging. Hello Tony, Very usefull information ! Thanks. i enabled this config: 15 Field Engineering to 5 Expensive Search Results Threshold to 1 Here are the LDAP operation, : 1644 INFORMATIONAL NTDS General Fri Jun 09 09:55:16 2006 childdomain\user1 Internal event: A client issued a search operation with the following options. Client: 11.22.33.44 Starting node: OU=MyOU OU=myou1 DC=childdomain DC=parentDomain DC=root DC=fr Filter: (objectClass=user) Search scope: subtree Attribute selection: givenName sAMAccountName sn Server controls: Visited entries: 63 Returned entries: 58 Followed by this: 1139 INFORMATIONAL NTDS LDAP Fri Jun 09 09:55:16 2006 childdomain\user1 Internal event: Function ldap_search completed with an elapsed time of 16 ms. => for 63 visited entries, only 58 are returned and the ldap search lasted 16 ms (Sometimes the ldap search took 140 ms...). Questions: Would the IDs 1644 + 1139 tell me that the web app. is performing Inefficient and Expensive LDAP Query to my DC ? Thanks for advices, Yann Message d'origine De : Tony Murray <[EMAIL PROTECTED]>À : ActiveDir@mail.activedir.orgEnvoyé le : Mercredi, 7 Juin 2006, 11h16mn 33sObjet : RE: [ActiveDir] AD LDAP Logging. Hi Yann One option would be to enable logging of all LDAP searches against the DC. http://www.activedir.org/article.aspx?aid=97 Tony PS. Were just loading a new version of the site, so it might take a few minutes before you can load the page. From: [EM
Re : [ActiveDir] AD LDAP Logging.
Hello Tony, Very usefull information ! Thanks. i enabled this config: 15 Field Engineering to 5 Expensive Search Results Threshold to 1 Here are the LDAP operation, : 1644 INFORMATIONAL NTDS General Fri Jun 09 09:55:16 2006 childdomain\user1 Internal event: A client issued a search operation with the following options. Client: 11.22.33.44 Starting node: OU=MyOU OU=myou1 DC=childdomain DC=parentDomain DC=root DC=fr Filter: (objectClass=user) Search scope: subtree Attribute selection: givenName sAMAccountName sn Server controls: Visited entries: 63 Returned entries: 58 Followed by this: 1139 INFORMATIONAL NTDS LDAP Fri Jun 09 09:55:16 2006 childdomain\user1 Internal event: Function ldap_search completed with an elapsed time of 16 ms. => for 63 visited entries, only 58 are returned and the ldap search lasted 16 ms (Sometimes the ldap search took 140 ms...). Questions: Would the IDs 1644 + 1139 tell me that the web app. is performing Inefficient and Expensive LDAP Query to my DC ? Thanks for advices, Yann Message d'origine De : Tony Murray <[EMAIL PROTECTED]>À : ActiveDir@mail.activedir.orgEnvoyé le : Mercredi, 7 Juin 2006, 11h16mn 33sObjet : RE: [ActiveDir] AD LDAP Logging. Hi Yann One option would be to enable logging of all LDAP searches against the DC. http://www.activedir.org/article.aspx?aid=97 Tony PS. We’re just loading a new version of the site, so it might take a few minutes before you can load the page. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of YannSent: Thursday, 8 June 2006 6:39 a.m.To: ActiveDir@mail.activedir.orgSubject: [ActiveDir] AD LDAP Logging. Hello , I need advices about troubleshooting LDAP connections to one of my DC in my AD2k3. An application named ZOPE running on a linux box accesses my DC. Users use a web page, via ZOPE application, that connect to my DC to list users information. Sometimes, users are disconnected to my DC and the admin that is responsible for the ZOPE app. called me to resolve this issue. What are the different steps to tshoot possible problem with LDAP connections to my DC ? Thanks in advance for help, Yann __Do You Yahoo!?En finir avec le spam? Yahoo! Mail vous offre la meilleure protection possible contre les messages non sollicités http://mail.yahoo.fr Yahoo! Mail This communication, including any attachments, is confidential. If you are not the intended recipient, you should not read it - please contact me immediately, destroy it, and do not copy or use any part of this communication or disclose anything about it. Thank you. Please note that this communication does not designate an information system for the purposes of the Electronic Transactions Act 2002.
Re: [ActiveDir] AD LDAP Logging.
Tony Murray wrote: Hi Yann One option would be to enable logging of all LDAP searches against the DC. http://www.activedir.org/article.aspx?aid=97 This is useful information. Wish I would have had it on Monday when our MIT KDC/KCA was having problems getting info out of AD. Ended up using tcpdump to watch the connections. Couldn't see the actual queries as they were encrypted. al Hello , I need advices about troubleshooting LDAP connections to one of my DC in my AD2k3. An application named ZOPE running on a linux box accesses my DC. Users use a web page, via ZOPE application, that connect to my DC to list users information. Sometimes, users are disconnected to my DC and the admin that is responsible for the ZOPE app. called me to resolve this issue. What are the different steps to tshoot possible problem with LDAP connections to my DC ? Thanks in advance for help, Yann __ Do You Yahoo!? En finir avec le spam? Yahoo! Mail vous offre la meilleure protection possible contre les messages non sollicités http://mail.yahoo.fr Yahoo! Mail This communication, including any attachments, is confidential. If you are not the intended recipient, you should not read it - please contact me immediately, destroy it, and do not copy or use any part of this communication or disclose anything about it. Thank you. Please note that this communication does not designate an information system for the purposes of the Electronic Transactions Act 2002. -- Al Lilianstrom CD/CSS/CSI [EMAIL PROTECTED] 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] AD LDAP Logging.
Hi Yann One option would be to enable logging of all LDAP searches against the DC. http://www.activedir.org/article.aspx?aid=97 Tony PS. We’re just loading a new version of the site, so it might take a few minutes before you can load the page. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Yann Sent: Thursday, 8 June 2006 6:39 a.m. To: ActiveDir@mail.activedir.org Subject: [ActiveDir] AD LDAP Logging. Hello , I need advices about troubleshooting LDAP connections to one of my DC in my AD2k3. An application named ZOPE running on a linux box accesses my DC. Users use a web page, via ZOPE application, that connect to my DC to list users information. Sometimes, users are disconnected to my DC and the admin that is responsible for the ZOPE app. called me to resolve this issue. What are the different steps to tshoot possible problem with LDAP connections to my DC ? Thanks in advance for help, Yann __ Do You Yahoo!? En finir avec le spam? Yahoo! Mail vous offre la meilleure protection possible contre les messages non sollicités http://mail.yahoo.fr Yahoo! Mail This communication, including any attachments, is confidential. If you are not the intended recipient, you should not read it - please contact me immediately, destroy it, and do not copy or use any part of this communication or disclose anything about it. Thank you. Please note that this communication does not designate an information system for the purposes of the Electronic Transactions Act 2002.