Yes, once traffic is encrypted things are messy as well as any RPC traffic.

Kerberos and DNS and LDAP calls which should comprise the majority of the
troubleshooting around DCs are all relatively nice and "easy" to
troubleshoot with Network traces.

Once you have narrowed the scope of the problem, then a dive into KBs could
very well be required. But at least the scope of the search has been so
reduced that you don't start with "it could be anything". 

If MS would release a nice RPC parser for netmon that would be a great thing
to have as then almost everything you do off of a machine that wasn't
otherwise be encrypted could fairly easily be translated and worked out. 

Quite seriously, we use netmon traces at least once every two weeks to knock
down an issue. It usually ends up finding configuration issues or DNS/DHCP
servers not responding properly (again generally configuration issues), etc.
Sometimes it discovers that a problem isn't really a problem, it is some
worm/virus that we didn't previously know about and the scanners aren't
catching. 

Also in general network traces are a good thing to do to gauge the health of
your network as most networks are wide open and people can set up anything
they want. I have seen sites running IPX for instance and when I reported it
to them to ask why they end up finding people running gaming systems that
were eating up considerable bandwidth. You find network devices that
misbehave and for some reason keep sending out broadcasts or multicasts or
arping a lot. You can find machines that have malware installed on them as
the machines broadcast to resolve various names they shouldn't be trying to
resolve. 

It is good to watch your network packets occasionally because that is one of
the first places a bad guy is going to go look as well. What secrets are you
giving away unknowingly?

  joe



-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Tony Murray
Sent: Saturday, February 14, 2004 3:51 AM
To: [EMAIL PROTECTED]
Subject: RE: [ActiveDir] Domain Naming Server FSOM

It's certainly a good suggestion, Joe.  The only thing I would say is that
network traces are not (at least in my experience) self-evident.  Generally
you can work out part of the picture, but much of it involves referring to
KBs and Whitepapers and some of it is just plain guess work.  It gets even
further complicated the more applications you have accessing AD.  And then
there's encrypted traffic to take into consideration.

Tony

-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of joe
Sent: Samstag, 14. Februar 2004 03:33
To: [EMAIL PROTECTED]
Subject: RE: [ActiveDir] Domain Naming Server FSOM

This is an excellent case to do a network trace. People may be getting sick
of me saying this but it cuts out all of the guesswork of the other 15 or so
posts. Slap the server on a shared hub or plug into your mirror port and do
a trace of the logon while the other DC is down or rebooting or whatever
case you find causes the slowness. You will most likely see requests
directed to this server and you have to then just figure out what kind of
requests they are and why they would be going to that server. Much better
than trying to guess around what kind of configuration you have. You could
possibly find it with this guessing but generally that involves changing
things until it works which is always bad news. 

Get a trace, tell us what kind of traffic is going to that rebooting box and
not being responded to. 

   joe

 

-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Salandra, Justin A.
Sent: Wednesday, February 11, 2004 1:14 PM
To: ActiveDir (E-mail)
Subject: [ActiveDir] Domain Naming Server FSOM

I have noticed that logons take an enourmous amount of time on non DC
Windows 2000 Servers if the Server running the Domain Naming Master is
rebooting.  Why is this?

Justin A. Salandra, MCSE
Senior Network Engineer
Catholic Healthcare System
212.752.7300 - office
917.455.0110 - cell
[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> 

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/

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/

Reply via email to