Académique Documents
Professionnel Documents
Culture Documents
IN-DEPTH
I've made a living troubleshooting Active Directory since the Windows 2000 beta, and it's been an interesting ride. While much of my AD work has been smooth, the lack of troubleshooting resources has thrown in a few bumps. Troubleshooting is rarely covered in any standard training course, and administrators are usually left at the mercies of Microsoft's support site, Google, EventID.net and other similar sites. While these resources provide a wealth of data, you really need to do a lot of preliminary work and then search for specific problems on the Web. Along my journey, I've found a few shortcuts. The following are my top six AD troubleshooting tips. The best thing about these tips is that they're free. That's right: There's no need to buy thirdparty tools. All the tools noted here are either native to Windows 2003 or in Support Tools or the Resource Kit, and they're surprisingly powerful. These tips are loosely ordered from the most important to the ones that have a narrower focus.
Domain: Corp.net Corp-DC02 PASS WARN n/a Corp-DC03 PASS WARN n/a Corp-DC01 PASS WARN n/a Domain: EMEA.Corp.net FAIL EMEA-DC03 FAIL EMEA-DC02 FAIL EMEA-DC01 FAIL FAIL FAIL n/a n/a n/a
http://redmondmag.com/Articles/2009/07/01/6-Tips-for-Troubleshooting-Active-Directory.aspx?p=1
3/20/2014
Table 1. Enterprise DNS Infrastructure test results. In the sample output in Table 1, every DNS server -- which is usually also every domain controller (DC) -- in the forest is listed by domain. The cool thing about that is that it shows the domain configuration of the forest, which is very handy if you're a consultant or support engineer and not familiar with the environment. In reading the data in the table, the results are: PASS: The DNS server passed this particular test FAIL: The DNS server failed the test N/A: The test was not run. This is usually due to a previous test failing, so it makes no sense to test a dependant function, which will fail anyway. In Table 1, we see the value of this test. In a glance, I can see where my trouble spots are. In a multiple-domain forest, you must run this command with Enterprise Admin credentials, or you will get FAIL results on all tests for all DNS servers in domains for which you don't have privileges. This is what happened for the EMEA domain in Table 1. For further help, a complete, detailed list of the test results is available earlier in the report. For instance, I can go to the top of the report and search for Corp-DC02, and get details as shown in Figure 1. There's a lot of good information I've cut for brevity, but you can construct the DNS resolver configuration for each DNS server just from the data here. There's a lot of other data here as well. But the point is that this section shows why the forwarders test had an N/A in the summary in Table 1. Using this method, we can pick our way through all the warnings, failures and N/A results in the summary table. And, of course, the beauty is that you have all DNS servers in the forest in one nice text file generated from one command. This can be run even from a client that has DCDiag on it. Figure 1. Test results for domain controllers:
D C :T e s t D C 1 . W t e c . a d a p p s . c o m D o m a i n :W t e c . a d a p p s . c o m T E S T :A u t h e n t i c a t i o n( A u t h ) A u t h e n t i c a t i o nt e s t :S u c c e s s f u l l yc o m p l e t e d T E S T :B a s i c( B a s c ) M i c r o s o f t ( R )W i n d o w s ( R )S e r v e r2 0 0 3 , E n t e r p r i s eE d i t i o n( S e r v i c eP a c kl e v e l :2 . 0 )i ss u p p o r t e d N E T L O G O Ns e r v i c ei sr u n n i n g < s n i p > I Pa d d r e s si ss t a t i c I Pa d d r e s s :1 0 . 1 3 . 6 2 . 9 5 < s n i p > D N Ss e r v e r s : 1 0 . 1 3 . 6 2 . 1 0 5( < n a m eu n a v a i l a b l e > )[ V a l i d ] 1 0 . 1 3 . 6 2 . 9 5( < n a m eu n a v a i l a b l e > )[ V a l i d ]
http://redmondmag.com/Articles/2009/07/01/6-Tips-for-Troubleshooting-Active-Directory.aspx?p=1 2/6
3/20/2014
http://redmondmag.com/Articles/2009/07/01/6-Tips-for-Troubleshooting-Active-Directory.aspx?p=1
3/6
3/20/2014
2/18/2009 2/13/2009 1722 21:36 7:50 0 0 0 2/18/2009 0 21:37 2/18/2009 0 21:37 2/18/2009 0 21:37
3/20/2014
The 9 Internal Processing value is handy for getting additional details for DS events that indicate an internal error has occurred. This will often cause additional events that will aid in diagnosing the problem. It's common to set more than one of these values. For instance, in replication troubleshooting, it would be reasonable to enable 1 Knowledge Consistency Checker and 5 Replication Events. The 15 Field Engineering value will dump several additional events to the DS log. Unlike the other diagnostics, this one needs to be set to five to provide relevant data. Specifically, it will produce events 1644 and 1643, which report inefficient LDAP queries including the client who was the source of the query, the query string and the root of the query. This is important because one of the headaches related to AD is the Local System Authority Subsystem Service (LSASS) process using up enough resources to hang or crash a DC and cause client log-on delays. Inefficient LDAP queries by a user or by an application -- or even a Linux client log-on -- will put a heavier load on LSASS. Enabling this diagnostic will quickly identify the guilty party by name or IP address. Some admins leave this diagnostic permanently enabled to monitor a busy environment, but again, it will fill up the event logs and possibly hide or overwrite other important events in the DS log.
3/20/2014
Unfortunately, there's little information available on what acceptable thresholds are. The only one I've found that even addresses this is Microsoft's Branch Office Deployment guide. While there are many counters may or may not be familiar, I've only found a few that are significant: DRA Pending Replication Synchronizations: These are the directory synchronizations that are queued and are essentially replication backlog. Microsoft only says these values should be "as low as possible" and that "hardware is slowing replication." These could be indications that DC resources are at high utilization. LDAP Client Sessions: This is the number of sessions opened by LDAP clients at the time the data is taken. This is helpful in determining LDAP client activity and if the DC is able to handle the load. Of course, spikes during normal periods of authentication -- such as first thing in the morning -- are not necessarily a problem, but long sustained periods of high values indicate an overworked DC. LDAP Bind Time: This is the time in milliseconds needed to complete the last successful LDAP binding. Documentation says that this should be "as low as possible," but if you run the perfmon output through the Performance Analyzer of Logs (PAL) tool, it will flag 15 milliseconds as a warning threshold and 30 milliseconds as an error threshold. The fix is more resources: processor, memory and so on. (Note: PAL is an excellent performanceanalysis tool, and is available online.) In diagnosing the LSASS process, as in any performance analysis, a baseline must be established. A note on Microsoft's DS blog indicates that if a baseline is not available, use 80 percent. That is, the LSASS counters shouldn't indicate more than 80 percent consumption. Above 80 percent consumption indicates an overload condition, which could be a high LDAP query demand (see Tip No. 4) or general lack of server resources. The resolution is to increase resources or reduce demand, but be advised this has the potential to cause a performance hit in the domain. If you really want to solve your LSASS resource issues, put your DCs on x64 platforms with several processors and 32GB of RAM. You might be surprised at how much memory LSASS really can use. About the Author Gary is a Solution Architect in Hewlett-Packard's Technology Services organization and lives in Roswell, GA. Gary has worked in the IT industry since 1981 and holds an MS in Computer Aided Manufacturing from Brigham Young University. Gary has authored numerous technical articles for TechTarget (http://searchwindowsserver.techtarget.com), Redmond Magazine (www.redmondmag.com) and TechNet magazine, and has presented numerous times at the HP Technology Forum, TechMentors Conference and at Microsoft TechEd 2011. Gary is a Microsoft MVP for Directory Services and is the founder and President of the Atlanta Active Directory Users Group (http://aadug.org).
http://redmondmag.com/Articles/2009/07/01/6-Tips-for-Troubleshooting-Active-Directory.aspx?p=1
6/6