Hey now, I wonder who you are pointing at here........ I don't really agree with you Deji. You don't have to know what you are looking at for it to help. It certainly makes you more productive if you have some idea of what you are looking at but many times I don't know what I am looking at and I am just looking for errors being thrown in the trace that don't get floated up properly through the application (or sometimes at all). Examples of that are rampant in tools that use LDAP and don't float up the extended errors when they are encountered. You get some pathetic message from the app and see a very explanatory extended error in the trace in clear text.
The other thing you can do is look at a trace that works and look at one that doesn't and try to pinpoint the differences. This is one of the most common things I do for one off broken things. Does it work as admin but not as normal user, what do you see in the trace? Oh a remote registry access that fails with access denied? Oh a network file that you can't read? Oh a nice access denied for an LDAP Update? Etc etc etc. I think a lot of it really comes down to how much do you know about how Windows and networking works by itself and how much do you want to learn? Getting a network sniffer out and watching what happens on the wire is a great way to see how this all works. It is also a great way to find symptoms prior to them becoming full blown issues. Multiple times I have just spent some time poking around and found servers broadcasting like mad that shouldn't have been and contacting the owners and they find a virus or something on it. On the class aspect... Anyone here take the Enterprise Class for NT4? Anyone recall the section on netmon and network tracing? Anyone stay awake for it and find it something you could actually take and use going forward? Probably very few if any. It is very difficult, in my opinion, to "teach" network monitoring and how to do it and what to look for. The attempts I have seen have all been based in some way shape or form off one of the networking models which tends to fall flat on its face as well. You don't really need to know the OSI model to use a network monitor and see issues. Things like a WINS resolution failing or DNS resolution failing stick out pretty well. About the only thing better would be if the network tools flagged those packets in blinking red text or something. If someone wants to learn how to use network monitor software, load it and try to run it; personally I recommend ethereal. I think it blows netmon out of the water at the moment. If you use a command line version you might find it a bit difficult to use and learn, more than likely you will use a GUI version and you slowly point and click and work through it. Is it the best time to learn how to do network tracing when your server is on fire or your network is puked? Probably not, this is why I recommend people to regularly pull a network tracing tool up and look at what is going across the wire. You will learn a ton just doing that. Ping a server, what traffic do you see? Did it resolve in WINS or DNS or through broadcast? What if you net use? The basics are these 1. Load the program. 2. Start the program. 3. Maybe try to browse the help. 4. Look for some button that seems to indicate a way to start capturing, it might be start, run, new, etc. 5. You might need to select what network interface you are capturing on. You need to know which one to use. 6. Let it capture packets for a while and stop the trace 7. The trace should pop up, scroll through and look at what is happening. Don't get overwhelmed, everything happens one packet at a time. Ethereal is cool because it has a quick filter that will quickly just show you what traffic is involved with a single stream. Just select right click on a packet and click follow stream. You don't need to know a thing about display filters or capture filters to start. Those things just help you later as you get better and better and want to narrow the traffic down you are looking at. I would argue initially you want to look at all of the packets anyway so you have an idead of what is there. If you start out all filtered, you don't know what you are missing. And yes, often missing packets are just as important to notice as packets that are there. It tends to take more experience to notice that though if you send a packet to one machine and don't get a response, that tends to be pretty obvious. Obviously though this is a good case of looking at a good and bad trace side by side. If worse comes to worse. Get a capture of things working correctly and then when it breaks, pull out the trace of it going correctly and look to see what is different now. I think network tracing should be done by every application/load integrator and admin. There are many issues that never would have hit production if the original people implementing and/or designing the proof of concept or pilot would have simply looked at a network trace of the app running and noticed it was doing things they wouldn't have expected like talking to servers it shouldn't be talking to etc. joe -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Wednesday, February 09, 2005 1:18 AM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Remote Assistance Without pointing fingers, or mentioning "short" names, here's my stance on sniffing traffic for diagnosis. It is a GREAT concept IF you know what you are looking for. Merely firing up Netmon/Ethereal and such will not be productive without the necessary capabilities to discern and interpret the traffic. I know, because I was a victim. Took me a 3-hour call and escalations to MS before I could resolve a whacky (OK, unique) problem where Exchange insisted on doing NetBIOS name calls when I expected it to do FQDN during a migration project. RASDIAG saved my life, thanks to the MS dude. So, is there any interest in putting together something along the line of "Capturing and Interpreting Network Traffic 101"? I volunteer to be an active participant in the project. I think this will help many of our audience on this list and beyond. Sincerely, Dèjì Akómöláfé, MCSE+M MCSA+M MCP Microsoft MVP - Directory Services www.readymaids.com - we know IT www.akomolafe.com Do you now realize that Today is the Tomorrow you were worried about Yesterday? -anon ________________________________ From: [EMAIL PROTECTED] on behalf of Rick Kingslan Sent: Tue 2/8/2005 9:24 PM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Remote Assistance I'd load NetMon or Ethereal on both machines and capture the traffic. Filter on the names / IPs of the two machines involved, just to reduce the noise to just the important bits. I suspect this will most likely uncover the problem much quicker than anything else you could likely do. -rtk ________________________________ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Cothern Jeff D. Team EITC Sent: Tuesday, February 08, 2005 4:46 PM To: ActiveDir@mail.activedir.org Subject: [ActiveDir] Remote Assistance Windows XP SP2 machines I have followed the guidance in kb301527 <http://support.microsoft.com/kb/301527> The windows Firewall is turned off completely. Both machines are in the same domain. A Domain admin on one XP machine is trying to offer assistance to another XP machine. I put the machine name in and hit connect and it errors out saying connection failed. Cannot find any information in the event log. I am able to connect to \\machinename\C$ <file:///\\machinename\C$> so definitely have admin rights. Anyone have any other ideas not put into the above KB article? List info : http://www.activedir.org/List.aspx List FAQ : http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/List.aspx List FAQ : http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/
