Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

We host a bunch of ASP.NET sites on an IIS7 server. Occasionally, we'd like to be able to log HTTP POST data to troubleshoot problems. IIS lets us log the query string, but not the POST data - at least, we haven't found a way.

Do you think it's safe to use Wireshark (or Netmon or another sniffer) on a production server? My gut feeling says "no" but I'd like to hear what others think.

It would be better to use port mirroring, and run the sniffer on a different box on the same switch. Unfortunately though, all the servers on that switch are production servers... so we'd have to affect one of them.

Thanks for your help,

share|improve this question
up vote 7 down vote accepted

Microsoft Pro Support will often request that you install Netmon on a production server to help track down problems. If MSFT themselves want you to use a packet capture utility (in this case, Netmon) on a production server then that's a good indication that it's okay. (I suppose there's at least a few logical fallacies in that statement, but it sounded good to me. =) ) To my knowledge, there is nothing destabilizing about placing a packet capture utility on a production server.

Personally, I would use Netmon on a Windows server over Wireshark. The first reason is because in my experience Pro Support will not support Wireshark captures. The second reason is because... well... I like Netmon better, but that's subjective. =)

share|improve this answer
+1 for NetMon. It happens to be my personal favorite as well. – joeqwerty Nov 24 '09 at 20:58
Great minds... and all that implies. =) – Wesley Nov 24 '09 at 21:00
Thanks - I'll definitely try it out. I'm used to Wireshark but I have to admit it has a pretty ugly UI :). And if MS says NetMon is safe for production use, I'll take their word for it... – Richard Beier Nov 24 '09 at 21:07
Netmon rocks and if you really have to (for some odd reason) you can export the capture to wireshark (although I've not met anyone that's gone back to wireshark after using netmon) – Jim B Nov 25 '09 at 4:48
The question was whether there are any problems with having a network capture software on your production server... Choosing netmon over wireshare is purely subjective. I use both and find that Microsoft can accept captures made from Wireshare just as easily as Netmon captures. – Dscoduc Nov 28 '09 at 20:04

IMHO, there's no inherent risk or harm in running a packet capture program on a production server. In many cases, the problem is such that you need to run it on the "source" server to determine the cause of the problem.

share|improve this answer

It sounds like you want something like SmartSniff .

Wireshark will do the job since it also uses WinPcap, but I think Smart Sniff is a lot simpler and easier to use if your not doing advanced tracing.

alt text

share|improve this answer
I couldn't get anything that uses raw sockets to work on Server 2008. Does smartsniff use raw sockets? Have you used it on Server 08? – Wesley Nov 24 '09 at 20:57
SmartSniff looks interesting - I'll check it out. – Richard Beier Nov 24 '09 at 21:08
I'm almost certain I tried SmartSniff on a SBS 2008 machine and it wouldn't work for the above reason. – Wesley Nov 24 '09 at 21:15
afaik, SmartSniff can use raw sockets, winpcap, or the microsoft monitor driver so you might as well use wireshark or netmon. – joeqwerty Nov 25 '09 at 0:48
raw sockets is not required by SmartSniff. it will also work with WinPCap. – djangofan Nov 25 '09 at 1:18

Our environment prevents network capture solutions on production servers for the primary reason that you don't want it to be overly easy for tier'd admins to perform network captures.

The actual files necessary to run WireShark and/or NetMon don't themselves present much of a risk, rather the ability of admins to perform captures can be considered a risk.

share|improve this answer

If you consider staff running sniffs a risk - security, performance or outside their skill level you have a greater problem.

You WANT staff to know how to do things like this - it makes them think better and it raises the level of questions they bring to the table - unless of course you are afraid of job security by having server folks be able to read SRC/DST data.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.