Windows Networking / PowerShell

Inspecting Local Windows Network Configuration with Get-KTNetworkConfig

Collect a structured snapshot from the affected Windows computer before attempting remediation. Move from the real symptom to local configuration evidence, interpret it carefully, state its limits, and choose the next diagnostic step.

Written by Published Last reviewed

Estimated Time

15–20 Minutes

Difficulty

Beginner / Intermediate

Technologies

Windows / NetTCPIP / PowerShell

Release

Get-KTNetworkConfig v1.0.0

What the tool does

Capture the active local configuration as evidence.

Get-KTNetworkConfig calls Get-NetIPConfiguration on the local Windows computer, evaluates configurations whose associated adapter reports Up, and returns one structured PowerShell object for each retained configuration.

The script accepts no parameters. It performs local discovery only and does not modify network configuration, write files, test connectivity, contact remote systems, collect credentials, or prove that any network service works.

When to use it

Start with the reported symptom, then preserve the local state.

Use the snapshot when a technician needs to understand which active adapters, addresses, gateways, DNS servers, and network profiles Windows currently reports before selecting a narrower test.

Real symptom

Define what failed

Record the affected computer, user-visible behavior, destination, application, time, expected result, and whether the problem is continuous or intermittent.

Local evidence

Collect without changing

Run the script on the affected Windows computer and retain the objects long enough to compare the configuration with the reported path.

Next decision

Choose a targeted check

Use the evidence to decide whether the next question concerns DNS, routing, a destination port, VPN state, DHCP, domain dependencies, or the application itself.

Requirements and safety boundary

Confirm the platform before running the script.

PowerShell

Windows PowerShell 5.1 or PowerShell 7 on Windows

The built-in NetTCPIP module and Get-NetIPConfiguration must be available. Linux and macOS are not supported.

Privilege

Administrator rights are normally unnecessary

Ordinary local discovery normally works for a standard user, although organizational controls can restrict access.

Signature

Verify and review first

The release is not Authenticode-signed. Verify its SHA-256 value and review the source before execution.

Do not weaken execution policy

Do not bypass or globally change PowerShell execution policy. After checksum and source review, targeted Unblock-File may be appropriate only for this downloaded script when RemoteSigned blocks it.

Download and checksum verification

Confirm the exact release before running it.

Step 1

Download the versioned package or script

Keep the README and checksum manifest with the release so its source, security boundaries, and approved hash remain available during review.

Download the ZIP Download the script

Supporting files: release README and SHA-256 manifest.

Step 2

Compare the script with the approved SHA-256 value

$expected = (Select-String -LiteralPath .\SHA256SUMS.txt -Pattern '  Get-KTNetworkConfig.ps1$').Line.Split()[0]
$actual = (Get-FileHash -LiteralPath .\Get-KTNetworkConfig.ps1 -Algorithm SHA256).Hash
$actual -eq $expected

The result must be True. The approved script SHA-256 is:

EADA2BBDDE5C0B62BB97D82D4DB4A70259CB8CC8DC9D65CA9D52E9384FF2C5C1

If the comparison is false, stop. Do not run the file.

Step 3

Review the source and use targeted unblocking only if needed

Confirm that the script has an empty parameter block, calls local Get-NetIPConfiguration, keeps only associated adapters reporting Up, and emits the documented eight-property objects.

Unblock-File -LiteralPath .\Get-KTNetworkConfig.ps1

Use this command only after verification and only when the downloaded script is blocked under RemoteSigned. It is not a substitute for organizational policy.

Running the script

Store the structured objects for deliberate review.

$networkConfig = & .\Get-KTNetworkConfig.ps1
$networkConfig

The script accepts no parameters. Do not add computer names, credentials, destinations, export paths, or remote-session arguments; they are not part of this release.

$networkConfig |
    Select-Object InterfaceAlias, InterfaceIndex, Adapter, IPv4Address,
        IPv6Address, IPv4Gateway, DnsServers, NetProfile

Select-Object changes only the caller's display or downstream selection. The script itself returns ordinary structured objects and does not format or export them.

Understanding the output

Read all eight properties together.

Scalar

InterfaceAlias

The Windows interface alias. It may be $null and can reveal local naming conventions.

Scalar

InterfaceIndex

The local integer interface index. It identifies the interface only in the observed computer's current context and may be $null.

Scalar

Adapter

The associated adapter description. It may identify physical, virtual, or VPN technology and may be $null.

String array

IPv4Address

Zero or more reported IPv4 addresses. An empty array means no value was available in this snapshot.

String array

IPv6Address

Zero or more reported IPv6 addresses. Presence or absence alone does not prove IPv6 path health.

String array

IPv4Gateway

Zero or more reported IPv4 next-hop values. Configuration does not prove reachability or route selection.

String array

DnsServers

Zero or more configured DNS-server addresses. A listed resolver is not proof that it responds or answers correctly.

Scalar

NetProfile

The reported network-profile name. It may be $null and does not prove trust, reachability, or application health.

Array-valued properties

Preserve multiple values instead of flattening them.

IPv4Address, IPv6Address, IPv4Gateway, and DnsServers are System.String[] arrays. Missing multivalue information appears as an empty array; missing scalar information appears as $null.

foreach ($item in $networkConfig) {
    [pscustomobject]@{
        InterfaceAlias = $item.InterfaceAlias
        IPv4Count      = $item.IPv4Address.Count
        GatewayCount   = $item.IPv4Gateway.Count
        DnsServerCount = $item.DnsServers.Count
    }
}

This read-only projection helps distinguish no reported value from one or several values without changing the collected objects or joining arrays into ambiguous text.

Synthetic example

Read the snapshot as configuration evidence—not a health verdict.

The following documentation-only values use reserved example address ranges and do not represent a customer or production environment.

InterfaceAlias : Lab Ethernet
InterfaceIndex : 12
Adapter        : Synthetic Ethernet Adapter
IPv4Address    : {192.0.2.20}
IPv6Address    : {2001:db8::20}
IPv4Gateway    : {192.0.2.1}
DnsServers     : {192.0.2.53, 2001:db8::53}
NetProfile     : Example Lab

Observation

Windows reported one retained configuration

The associated adapter reported Up, and the object contains address, gateway, DNS, and profile values at collection time.

Inference

The configuration is relevant to the symptom

If the reported application should use this interface, these values identify plausible DNS and routing dependencies for the next check.

Unknown

No service has been tested

The snapshot does not show whether the gateway, resolvers, destination, VPN, domain, Internet, or application can actually be reached.

Common evidence patterns

Explain the observation before deciding what it means.

Several objects

More than one adapter reports Up

Ethernet, Wi-Fi, VPN, and virtual adapters can coexist. Multiple objects are not automatically a fault; determine which path relates to the symptom.

No gateway value

The array is empty

Some active adapters do not need an IPv4 default gateway. Preserve the observation and compare it with the adapter's intended role.

Several DNS servers

Configuration provides multiple resolvers

The list does not reveal which resolver answers a particular query, whether answers agree, or whether any resolver is reachable.

No returned objects

No configuration met the retained-state rule

The script returns no objects when no configuration has an associated adapter reporting exactly Up. That result alone does not identify the cause.

Evidence limits

Separate what the output proves from what remains unknown.

What it proves

A local observation was returned

For each emitted object, the script observed an associated adapter reporting Up and normalized the available eight properties at that time.

What it does not prove

Configuration is not end-to-end health

The output does not prove that DNS resolution, routing, Internet access, domain health, DHCP, VPN connectivity, or application connectivity works.

What remains unknown

The path and service still need testing

The snapshot omits route selection, DNS query results, destination-port tests, prefix length, DNS suffix, computer name, and remote-system evidence.

Privacy and ticket handling

Redact local network details before sharing.

Interface names, adapter descriptions, IP addresses, gateways, DNS servers, and network-profile names can reveal internal design, products, providers, or organizational naming.

Do not paste raw output into public channels

Keep the original evidence only in an authorized case location. For tickets or escalation, include the minimum relevant properties, redact identifiers that the recipient does not need, identify the collection time, and state that the values came from one local snapshot.

Escalation and next diagnostic steps

Choose one check that answers the next unresolved question.

DNS question

Test the specific name and resolver path

Use the published Test-KTDNS procedure when the next question is whether an authorized resolver returns the expected record type and value.

Open the DNS tutorial

Path or port question

Define the destination before testing

Record the source interface, destination name or address, protocol, and port. Then use an approved route or connectivity test without treating ping or DNS alone as application proof.

Domain dependency

Correlate DNS and Active Directory evidence

Use the domain-health investigation when client DNS, locator records, secure channel, controller health, replication, or time may affect the symptom.

Open the domain-health guide

Escalate before changing configuration when ownership is unclear, the evidence suggests widespread impact, the affected path involves VPN or security controls, a production outage is active, compromise is suspected, or remediation would change addresses, DNS, gateways, routes, adapters, profiles, services, or organizational policy.

Related KrippyTech resources

Continue from local evidence to a focused investigation.

Downloads

Verify the published files

Use the versioned ZIP and direct release links from the KrippyTech Downloads page.

Open Downloads

Learning hub

Windows & Hybrid

Connect local configuration evidence with DNS, Active Directory, server, and hybrid troubleshooting paths.

Open Windows & Hybrid

Method

MSP University

Use the understand, investigate, resolve, and verify sequence without jumping from symptom to change.

Review the learning path

Official Microsoft references

Verify the underlying Windows and PowerShell behavior.

Get-NetIPConfiguration

Microsoft's reference for retrieving local IP network configuration through the NetTCPIP module.

Read Microsoft Learn

Unblock-File

Microsoft's guidance for reviewing and removing the Internet-zone mark from a specific downloaded file.

Read Microsoft Learn

PowerShell execution policies

Microsoft's explanation of policy scopes, precedence, signing behavior, and RemoteSigned.

Read Microsoft Learn