Repository navigation
Get-NetTCPConnection not reporting ports correctly #3277
Description
Prerequisites
- Existing Issue: Search the existing issues for this repository. If there is an issue that fits your needs do not file a new one. Subscribe, react, or comment on that issue instead.
- Descriptive Title: Write the title for this issue as a short synopsis. If possible, provide context. For example, "Typo in
Get-Foocmdlet" instead of "Typo." - Verify Version: If there is a mismatch between documentation and the behavior on your system, ensure that the version you are using is the same as the documentation. Check this box if they match or the issue you are reporting is not version specific.
Links
Summary
Running Get-NetTCPConnection not reporting all ports correctly. Found 2 machines that report that ports 80 and 443 are only listening on IPv6 when they are in fact listening on IPv4 and IPv6. This was confirmed by bindings in IIS and netstat.
Details
I am using this to test ports on a webserver automatically.
Running netstat -ano | findstr /i ":80 :443" | findstr /i listening | findstr /v "::" reports that the ports are open for IPv4 - this is correct
When running get-nettcpconnection | where {$_.localport -eq "80" -or $_.localport -eq "443" -and $_.state -eq "Listen"} reports only the IPv6 ports are open.
I have verified these results by running get-nettcpconnection | where {$_.state -eq "listen"} | sort localport
port 135 is reporting for IPv4 and IPv6 but 80 and 443 dont.
Suggested Fix
No response
Activity
officedocspr5 commentedon Dec 8, 2023
To make it easier for you to submit feedback on articles on learn.microsoft.com, we're transitioning our feedback system from GitHub Issues to a new experience.
As part of the transition, this GitHub Issue will be moved to a private repository. We're moving Issues to another repository so we can continue working on Issues that were open at the time of the transition. When this Issue is moved, you'll no longer be able to access it.
If you want to provide additional information before this Issue is moved, please update this Issue before December 15th, 2023.
With the new experience, you no longer need to sign in to GitHub to enter and submit your feedback. Instead, you can choose directly on each article's page whether the article was helpful. Then you can then choose one or more reasons for your feedback and optionally provide additional context before you select Submit.
Here's what the new experience looks like.
Note: The new experience is being rolled out across learn.microsoft.com in phases. If you don't see the new experience on an article, please check back later.
First, select whether the article was helpful:
Then, choose at least one reason for your feedback and optionally provide additional details about your feedback:
Finally, select Submit and you're done!
lukedaemon commentedon Oct 22, 2026
Hello,
This issue can be reproduced on Windows Server 2022 and Windows 11, and I suspect it also affects other recent Windows operating system versions.
Example
Port 8200 is only an example; the same happens with other ports.
netstat -ano | find "8200"Get-NetTCPConnection -LocalPort 8200returns only:Querying the underlying CIM class directly gives the same result, so the gap is in the data source and not in the cmdlet's filtering:
Get-CimInstance -Namespace root/StandardCimv2 -ClassName MSFT_NetTCPConnection -Filter "LocalPort=8200"The .NET call returns both listeners and agrees with netstat:
[System.Net.NetworkInformation.IPGlobalProperties]::GetIPGlobalProperties().GetActiveTcpListeners() | Where-Object Port -eq 8200This issue was opened on March 14, 2023 and is still active/present.
Manuela Scanu (@scanum) could it be routed to the team that owns the NetTCPIP module? A cmdlet that silently under-reports listening ports gives a false sense of security in exactly the scenarios it is used for: monitoring and security audits (for example). So it becomes unuseful.
Thank you.