To specify interface you want to capture traffic on, run:ĬaptureInterface='' To get the list of interfaces, and GUID’s (you can also use names), run: The capture interface is used to identify the interface you want to capture traffic on, pretty straightforward. You can do that with the netsh trace command as well. When running other packet capture apps in the past, I typically want to know a specific IP type and address, particularly when troubleshooting client/server connectivity issues. I didn’t use Scenarios and Providers in my initial tests, but I can see clear benefits for future troubleshooting scenarios. Using these parameters, the trace will only collect specific events/components of the network stack, for example, limiting the trace to items that only relate to Microsoft file sharing: There are additional parameters called “Scenarios” and “Providers” that you can add to the netsh trace command (like pre-built filters) to troubleshoot specific issues. Netsh trace start capture=yes Scenarios/Providers So how does the process work? Let me give you some high level points: Basic Netsh Trace Command Sure enough, the capture ran and I was able to copy the capture file to my laptop, open it up, and review it! Just an FYI, if you need to load the trace file into another application, it can be exported as a PCAP and loaded into another program. Within 10 minutes of reading the article, I downloaded the referenced Microsoft Message Analyzer application to my laptop (and only my laptop), and completed a netsh trace capture using native tools on a test server. Let me walk you through my experience taking this solution on a test drive. Of course, this assumes you are using Windows Server 2008 R2 or higher and/or Windows 7 or higher – if you’re not, we have bigger problems. Thankfully, there is a better way to troubleshoot: use network shell (netsh) and Microsoft Message Analyzer. On many occasions, I have found myself in situations where I needed to troubleshoot a server, and the natural course of action was to install an application (like Wireshark) or think of an elegant troubleshooting method that added time to issue resolution and more complexity overall.Īs server admins we should despise unnecessary complexity. Personally, I thought the article had to be a joke. The other day, I was reading through the InfoSec Community Forums on the SANS website, and I came across an interesting article, titled: “ No Wireshark? No TCPDump? No Problem!“.

Wireshark portable not running