I'm running Server 2022 with a SET TEAM configured for my virtual machines, and I've had success in the past installing Wireshark directly on my DHCP VM. However, this time it's for our SQL production application, and a vendor has suggested using Wireshark to troubleshoot some crashing issues. Is it advisable to install Wireshark directly on the SQL VM, or would there be a better method? For instance, should I set up another VM for this purpose and use port mirroring instead? Any advice would be appreciated, thanks!
2 Answers
You might not even need to install anything to capture packets on Windows. There's a method to do captures without installing software. You can check out [this link](https://techcommunity.microsoft.com/blog/iis-support-blog/capture-a-network-trace-without-installing-anything--capture-a-network-trace-of-/376503), and after capturing, just convert it to the Wireshark format using etl2pcapng. That way, you can analyze it in Wireshark without affecting your production server.
In my experience, using a dedicated VM for packet capturing via port mirroring is the way to go. It keeps your production environment safer while freeing up resources. Installing Wireshark or using something like tcpdump on another Windows or Linux VM is often better than running it directly on the SQL server. That way, you're minimizing risks. Just keep in mind that port mirroring might induce some performance overhead on your SQL server, but it’s still a less risky option than running Wireshark directly. Also, do remember that Wireshark's installation might require a reboot, not necessarily for Wireshark itself but for its npcap dependency. If you're in a reverse proxy setup, another option could be to capture packets in-line between the proxy and the SQL server.
That sounds like a solid plan! If performance dips with port mirroring, you can always turn it off. Good luck during your maintenance window!
Actually, I've installed Wireshark + npcap without the reboot before, although it’s recommended. I've never had issues running it without rebooting.
This seems like a neat solution! We’re facing random crashes, often in the mornings. I hope this method helps track down the issue without too much hassle. I just had trouble with Wireshark freezing when I tried stopping a capture, so I’m eager to see if this works better!