Remote Capture with Message Analyzer and Windows 8.1

With the introduction of Windows 8.1, we have an amazing new feature which lets Message Analyzer capture messages remotely. This feature was introduced with Windows 8.1 and Server 2012 R2. From any client, down to Windows 7 (which requires a few components to be installed), you can attach to a remote target, configure how you want to capture, even from individual Virtual Machines, and pipe that traffic back to the client to be seen in near real-time.

Supported Systems

Here are a list of supported systems. The target machine is the one you remotely connect to which sends data to the capturing client. It does not need to have Message Analyzer installed. The client is where you initiate the connection from Message Analyzer and receive the remote traffic.

  • Remote Capture Target – Windows Server 2012 R2, Windows 8.1, Windows 8.1 RT.
  • Remote Capture Client – Windows Server 2012 R2, Windows 8.1, Windows 8, Windows Server 2012, Windows 8, Windows Server 2008 R2 (requires WMF 3.0), Windows 7 (requires WMF 3.0).

Supported Capture Scenarios

  • Both client and server being domain-joined
  • Both client and server being in workgroup
  • Client is domain-joined and server in workgroup.
  • Client in workgroup and server is domain-joined is supported but IPSec needs to be disabled on the server, so this is not a recommended scenario.

Using Remote Capture

Once you’ve installed Message Analyzer, you’ll need to log out and back in, or run with Administrative privileges. You’ll need to connect to the machine using a hostname. We don’t support using an IP Address directly in the dialog. If you need to access a machine by IP Address, please update your local Host files first, then use the hostname you added in the dialog. We need the hostname for authentication. If not this will cause issues receiving the traffic and result in an RPC error 87, even though you’ll be able to enumerate the configuration.

Now you are ready to start a new session, so go to the File backstage, and select Capture/Trace. Next select “Connect to Remote Host” using the drop down.


Enter the hostname and administrator credentials, if needed. If credentials are not provided, your logon credentials are used.


Under “Trace Scenarios”, we apply a template called Remote Link Layer. This adds the provider for the NDIS packet capture driver which is use to capture on the target machine. You can add other providers to the list to capture data from remote components as well. The only caveat here is that for now, the list is generated based on the local machine.


Next you configure the NDIS Packet Capture provider by pressing the “configure” link next to the Microsoft-Windows-NDIS-PacketCapture provider. It’s possible you’ll need to scroll over to find it, depending on your screen resolution. This opens a WMI channel to the target, which retrieves information about the machine.


This brings up a dialog which lets you see all of the physical and virtual network connections available on the machine. You can select which you want to capture on, thus giving you the ability to narrow the traffic down to a client running on a specific Virtual Machine.

You can also configure IP Addresses, Ports, and other low level filtering to further narrow down the traffic to capture. Also the message is truncated by default. You can imagine that trying to send all the data twice on the network could affect your traffic thus creating a Heisenberg effect with the problem you are investigating. So truncation helps limit this feedback issue.

Truncation also affects how the data is parsed. It limits parsing to certain protocols up to the TCP/UDP Payload. Another advantage is that the things parse and filter faster because we don’t have to be so complete or do reassembly. If you need more thorough parsing, then you can set the truncation length to zero which will enable the full parsing set. But this means more data on your network and parsing/filtering will be slower.


Now start the trace and you see messages start to flow in to Message Analyzer. You can reconfigure at any time to select different interfaces to inspect and apply different filters.

A Cool Feature Reborn

Long ago, with Network Monitor 2.x, we were able to capture traffic remotely from a client. And due to architecture changes, that feature was lost. Now with Message Analyzer and the move to the Cloud and Virtual machines, being able to remotely capture is more critical than ever. In future blogs we will go into even greater detail about some of the troubleshooting techniques for this truncated traffic, and delve into more of the options for filtering and configuration. And as always, we have published some addition documentation about Remote Capture on TechNet.

More Information

To learn more about some of the concepts described in this article, see the following topics in the Message Analyzer Operating Guide on TechNet:

These topics also include information about source computer configuration requirements and how to use the Microsoft-Windows-NDIS-PacketCapture Advanced Settings dialog to do the following:

  • Specify remote adapters on which to capture data, including virtual machines (VMs) that are serviced by a remote Hyper-V-Switch.
  • Configure special filters such as EtherType and IP Protocol Numbers.
  • Specify NDIS layer and Hyper-V-Switch layer packet filters and stack traversal paths.

Comments (3)
  1. David Dionne says:

    Ahhhh, this is such great news. Excellent job Paul.

  2. Anonymous says:

    Today’s (Networking) Tip… This amazing feature lets Message Analyzer capture messages remotely. This

  3. Anonymous says:

    Applies to: Windows 10 Windows Server 2012 R2 Windows 7 Windows Server 2012 Windows 8 Windows Server

Comments are closed.

Skip to main content