Add-NetEventPacketCaptureProvider: PowerShell Packet Capture

When You Need Packets and Can’t Install Anything

A financial services client we support had intermittent TCP resets appearing on a Windows Server 2022 application node. No packet analyzer on the box, and getting approval to install third-party software in that environment takes days. We needed something native. Add-NetEventPacketCaptureProvider is exactly that — built into Windows Server via the NetEventPacketCapture module since Server 2012 R2, no installs, no reboots, no change management tickets for software deployment.

My take: Wireshark is great, but for quick triage on locked-down Windows Server environments — financial services, healthcare, government — native PowerShell packet capture is the right first move. Installing agents mid-incident adds variables you don’t want.

Session First: New-NetEventSession

Before you can add a packet capture provider, you need a session. The session defines where captured data gets written and how large the output file can grow.

New-NetEventSession -Name "PktCapSession" -LocalFilePath "C:\Captures\capture.etl" -MaxFileSize 512

MaxFileSize is in MB. 512 is a solid starting point — enough headroom for most diagnostic captures without risking a full disk. I covered the full parameter set for New-NetEventSession in an earlier post on network event capture in PowerShell if you need more detail on session configuration options.

Add-NetEventPacketCaptureProvider: Core Usage

This cmdlet attaches a Remote Packet Capture provider to your session. The provider hooks into the Windows protocol stack and logs traffic as Event Tracing for Windows (ETW) events.

Add-NetEventPacketCaptureProvider -SessionName "PktCapSession" `
    -Level 4 `
    -CaptureType BothPhysicalAndSwitch `
    -TruncationLength 128

Level controls verbosity. Level 4 is informational — it captures what you need for most diagnostics. Level 5 is verbose and will fill your ETL file in minutes on any busy interface. Start with 4 unless you have a specific reason not to.

CaptureType controls where in the stack the capture happens:

• Physical — physical NIC traffic only
• Switch — virtual switch traffic only
• BothPhysicalAndSwitch — captures at both layers simultaneously

TruncationLength caps each captured packet to a fixed byte size. 128 bytes gets you full headers — source and destination IPs, ports, TCP flags. Enough for most connection-level diagnostics. If you need full payload inspection, remove the parameter entirely. On a 1G or 10G link, file sizes will grow fast without truncation in place.

Filtering by IP Address

For the financial services engagement, we only needed traffic involving two specific application servers. The IpAddresses parameter scopes the capture to those hosts directly.

Add-NetEventPacketCaptureProvider -SessionName "PktCapSession" `
    -IpAddresses @("10.10.5.44", "10.10.5.45") `
    -Level 4 `
    -TruncationLength 256

IpAddresses accepts an array. Specify as many hosts as you need. Note that this parameter filters on individual IPs — there is no built-in CIDR subnet syntax. For subnet-level scoping, either enumerate the relevant hosts or filter the ETL output post-capture.

Filtering by Protocol

For protocol-specific captures, IpProtocols takes protocol numbers directly. TCP is 6, UDP is 17.

Add-NetEventPacketCaptureProvider -SessionName "PktCapSession" `
    -IpProtocols @(6) `
    -Level 4

You can combine IpAddresses and IpProtocols in the same command. They apply as AND conditions — traffic must match both filters to be captured.

Targeting a Specific NIC

On hosts with multiple adapters, scope your capture to the relevant interface using Add-NetEventNetworkAdapter after setting up the provider. Getting the adapter identifier right matters here — I wrote about the distinction between InterfaceAlias and InterfaceDescription in this post on targeting NICs in PowerShell. That difference becomes relevant fast when you’re scripting captures across a fleet where adapter aliases and descriptions don’t consistently match.

Hyper-V Hosts: Add-NetEventVFPProvider

On Hyper-V hosts, the standard packet capture provider does not see east-west traffic between VMs running on the same host. That traffic transits through the Virtual Filtering Platform (VFP) inside the virtual switch — it never touches the physical NIC.

For those environments, use Add-NetEventVFPProvider instead:

Add-NetEventVFPProvider -SessionName "PktCapSession" `
    -Level 4 `
    -DestinationIPAddresses @("192.168.10.0/24") `
    -TCPPorts @(443, 8080)

VFP supports filter dimensions the standard provider does not: source and destination MAC addresses, VLAN IDs, GRE keys, TCP and UDP ports individually, and tenant IDs for multi-tenant environments. Useful when you’re working in SDN deployments or tracking down overlay network issues between VMs that share a virtual switch.

If you need to scope further to individual VM NICs, Add-NetEventVmNetworkAdapter adds a virtual network adapter as a filter on the provider:

Add-NetEventVmNetworkAdapter -SessionName "PktCapSession" -VMNetworkAdapterName "WebServer-NIC1"

Call it multiple times to add multiple adapters. Use Get-NetEventVmNetworkAdapter to verify what’s currently attached, and Get-NetEventVmSwitch to confirm which Hyper-V virtual switches are in scope for the capture.

Starting and Stopping the Capture

# Start
Start-NetEventSession -Name "PktCapSession"

# Reproduce the issue, then stop
Stop-NetEventSession -Name "PktCapSession"

The ETL file at your LocalFilePath is ready once you stop the session. On Windows Server 2019 and later, pktmon can convert ETL files to PCAP format for Wireshark analysis. On earlier versions, Microsoft Network Monitor handles it — Message Analyzer is deprecated since 2019 but still functional if you have it.

For captures you can’t watch in real time — scheduled overnight diagnostics, remote sessions, unattended runs — the -AsJob flag on session cmdlets keeps your terminal free. That pattern is covered in the PowerShell -AsJob post; same approach applies here.

Modifying an Existing Provider

If you need to adjust provider settings after creation, Set-NetEventPacketCaptureProvider handles that without tearing down the whole session.

Set-NetEventPacketCaptureProvider -SessionName "PktCapSession" `
    -TruncationLength 512 `
    -MultiLayer $true

MultiLayer enables simultaneous capture at multiple protocol stack layers. You see what arrives at the NIC versus what gets passed upward through the stack — useful when you suspect a driver, offload, or filtering issue is modifying packets between capture points. This parameter is one of the less-documented features in the module and has been genuinely useful on engagements where packet content was changing somewhere between the wire and the application.

Note: CaptureType cannot be changed on a running session. Stop the session first if you need to switch capture layers.

Cleanup

Remove-NetEventSession -Name "PktCapSession"

Always remove sessions after captures. They don’t consume significant resources when idle, but they accumulate and will cause name conflicts if you reuse session names in future captures or automated scripts.

Full Capture Workflow

Here’s the complete sequence from the financial services engagement:

# Create session with 1GB cap
New-NetEventSession -Name "AppDiag" `
    -LocalFilePath "D:\Captures\appdiag.etl" `
    -MaxFileSize 1024

# Add packet capture provider — TCP only, scoped to two application servers
Add-NetEventPacketCaptureProvider -SessionName "AppDiag" `
    -IpAddresses @("10.10.5.44", "10.10.5.45") `
    -IpProtocols @(6) `
    -Level 4 `
    -TruncationLength 256 `
    -CaptureType Physical

# Start
Start-NetEventSession -Name "AppDiag"

# ... trigger the issue ...

# Stop and cleanup
Stop-NetEventSession -Name "AppDiag"
Remove-NetEventSession -Name "AppDiag"

Session was up and capturing within three minutes of the call. ETL on the file share a few minutes after that. No software installs, no change management overhead, no waiting on a vendor agent rollout.

Caveats

Level 5 on a 10G interface fills 1GB in under two minutes. Level 4 is the right default for almost every scenario — adjust up only if you have a specific ETW keyword requirement that demands it.

ETL is not natively readable in Wireshark. Plan your analysis workflow before you start the capture, especially in environments where installing additional tools requires approval cycles that may outlast the incident window.

The NetEventPacketCapture module requires local administrator rights. In environments operating under Zero Trust architecture with strict privileged access controls, confirm the necessary permissions are in place before attempting captures on production nodes — and document the authorization.

On Server Core installations, verify the module is present before building your scripts:

Get-Module -ListAvailable -Name NetEventPacketCapture

During the same engagement, we also reviewed the client’s Microsoft 365 backup configuration — when you’re already deep in a Windows Server environment for infrastructure triage, it makes sense to check adjacent systems while you have the access and context.

Full parameter reference is in the PowerShell documentation for the NetEventPacketCapture module. There are more cmdlets in this module than most admins realize — WFP capture providers, ETW provider management, session modification — worth reading through if you work with Windows Server networking regularly.

If you need help building out network diagnostics workflows or want a review of your infrastructure monitoring posture, get in touch with our team.