A long, long time ago, managing Windows computers was a pretty simple task because most machines existed as stand-alone systems with dedicated resources like printers. Networking, if it existed, was simple and basic. Or course today we have much more complex environments which means there are many opportunities for problems. In this article I want to discuss some key networking tools and checks that should help you identity potential problems before they become serious and ensure a smooth running network.
One word before we get started: I'm assuming that all the systems you are checking are only using a single IPv4 network interface, presumably a desktop computer. You can use everything I'm going to cover to check a server with multiple network cards and IP addresses, but it might require a few extra steps on your part. I'm also going to assume you are running in a domain environment and running these checks with administrator credentials. They aren't required for some tests, but it's just as easy to use the same credential for everything.


Often the first network check is a 'ping'. This is the process of sending a special packet to a network address. The packet uses ICMP (Internet Control Message Protocol) to test network connectivity. When the remote computer receives this ping, it sends a response. The traditional tool is PING.EXE which is run from a command prompt. You can ping either a computer name or an IP address.
C:\>ping xplab
Pinging xplab.jdhlab.local [] with 32 bytes of data:
Reply from bytes=32 time<1ms TTL=128
Reply from bytes=32 time<1ms TTL=128
Reply from bytes=32 time<1ms TTL=128
Reply from bytes=32 time=1ms TTL=128
Ping statistics for
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 1ms, Average = 0ms
The response merely means the networking stack is working. There is no guarantee that the operating system is functioning normally. More on that later. The best you can tell from this is that the computer is up and connected to the network.
Windows PowerShell offers a similar tool, the Test-Connection cmdlet. Again, specify a computer name or IP address.
PS C:\> Test-Connection xplab
Source' Destination IPV4Address'' IPV6Address Bytes Time(ms)
------' ----------- -----------'' ----------- ----- --------
CLIENT1 xplab'''''' {}''''''''' 32''' 1
CLIENT1 xplab'''''' {}''''''''' 32''' 0
CLIENT1 xplab'''''' {}''''''''' 32''' 0
CLIENT1 xplab'''''' {}''''''''' 32''' 1
The Source property is the name of the computer I am running this from, and Destination is the remote desktop. As you see, pretty similar results. It is possible that desktop firewalls may be configured to not respond to ICMP requests or pings so don't assume no reply means the computer is down or there is a problem. But assuming firewalls aren't an issue you'll receive errors if the computer is not running or if there are other problems such as name resolution.


Every computer in your Active Directory domain should be registered automatically with the DNS infrastructure that supports your domain. This should be automatic. Regardless, a computer without a valid name entry can run into problems or may be difficult to manage. The command line tool to test this is NSLOOKUP.EXE.
C:\>nslookup xplab
Server:' coredc01.jdhlab.local
Name:''' xplab.jdhlab.local
A name and address means the record in the forward lookup zone exits. Otherwise you would have received an error like this:
C:\>nslookup foo
Server:' coredc01.jdhlab.local
*** coredc01.jdhlab.local can't find foo: Non-existent domain
The forward lookup record is just one half of the name resolution check. While not required, a reverse look up record should exist. This record takes an IP address and returns the name.
Server:' coredc01.jdhlab.local
*** coredc01.jdhlab.local can't find Non-existent domain
Uh-oh. It would seem I'm missing a reverse lookup record.

Figure 1 Missing Reverse Lookup
Once corrected, I now get the expected NSLOOKUP result.
Server:' coredc01.jdhlab.local
Name:''' xplab.jdhlab.local

RPC Connectivity

This is the type of connectivity that Windows computers had before TCP/IP became the networking standard. However, it is still vital because most remote management tools require RPC (Remote Procedure Call) connectivity. I'm going to lump a few things together in this category because in my experience they are related.
One easy way to test that you have RPC connectivity is to use the Computer Management console to connect to a remote computer. I take a short cut and click Start, Run, then type compmgmt.msc /computer:xplab. Assuming XPLAB is running and RPC is ok, I should get the computer management console.
Another test is to verify that the administrative shares exist. When File and Print sharing is enabled, which you often need for remote management, you should also get at least 2 hidden shares designed for administrators. The root of C:\ is shared as C$ and the Windows directory is shared as Admin$
C:\>dir \\xplab\c$
 Volume in drive \\xplab\c$ has no label.
 Volume Serial Number is 540A-24D4

 Directory of \\xplab\c$

12/10/2010' 08:07 AM''' ''''''''' 6d0a9979688d692da4562fcc1da3
12/21/2010' 11:01 AM'''''''''' 346,294 acme.txt
12/09/2010' 03:06 PM'''''''''''''''' 0 AUTOEXEC.BAT
12/09/2010' 03:06 PM'''''''''''''''' 0 CONFIG.SYS
12/10/2010' 07:48 AM''' ''''''''' Documents and Settings
01/17/2011' 04:02 PM''' ''''''''' Program Files
12/22/2010' 03:55 PM''' ''''''''' scripts
12/21/2010' 02:49 PM''''''''''' 10,986 test.txt
12/19/2010' 05:21 PM''' ''''''''' WINDOWS
12/22/2010' 04:01 PM''' ''''''''' work
'''''''''''''' 4 File(s)''''''' 357,280 bytes
'''''''''''''' 6 Dir(s)'' 4,636,114,944 bytes free
C:\>dir \\xplab\admin$
 Volume in drive \\xplab\admin$ has no label.
 Volume Serial Number is 540A-24D4

 Directory of \\xplab\admin$

12/19/2010' 05:21 PM''' ''''''''' .
12/19/2010' 05:21 PM''' ''''''''' ..
12/10/2010' 08:46 AM''' ''''''''' $NtUninstallKB968930$
01/17/2011' 03:31 PM'''''''''''''''' 0 0.log
12/09/2010' 09:54 AM''' ''''''''' addins
12/10/2010' 08:14 AM''' ''''''''' AppPatch
04/14/2008' 07:00 AM'''''''''''' 1,272 Blue Lace 16.bmp
12/10/2010' 02:30 PM'''''''''''''' 369 certmmc.log
04/14/2008' 07:00 AM''''''''''' 82,944 clock.avi
If I can see these shares then I know I should be able to remotely manage these computers. In PowerShell, this is even easier because I can use the Test-Path cmdlet.
PS C:\> test-path \\xplab\c$
PS C:\> test-path \\xplab\admin$
The last RPC-related task I might run is to use the NBTSTAT.EXE command line tool.
C:\>nbtstat -a xplab
Local Area Connection 2:
Node IpAddress: [] Scope Id: []
NetBIOS Remote Machine Name Table
Name'''''''''''''' Type'''''''' Status
XPLAB''''''''' <00>' UNIQUE''''' Registered
XPLAB''''''''' <20>' UNIQUE''''' Registered
JDHLAB'''''''' <00>' GROUP'''''' Registered
JDHLAB'''''''' <1E>' GROUP'''''' Registered
JDHLAB'''''''' <1D>' UNIQUE''''' Registered
..__MSBROWSE__.<01>' GROUP'''''' Registered
MAC Address = 08-00-27-84-C5-DC
The parameter is case-sensitive. Use 'a when using a computer name and 'A when using an IP address. The result shows me the associated Netbios names as well as the MAC address, ie the network adapter's physical address, which I think is a real bonus. If fact, sometimes this is such a handy piece of information that you might also use the GETMAC.EXE command line tool
C:\>getmac /s xplab
Physical Address''' Transport Name
=================== ====================================================
08-00-27-84-C5-DC'' \Device\Tcpip_{D9EEAE75-BAAA-4F84-896A-0F9032818EA3}

Windows Management Instrumentation

Perhaps no technology is more important to Windows management than WMI (Windows Management Instrumentation). It is important to verity that the WMI service is running and that you can query the WMI repository. If the wingmt service is not running, you will almost certainly run into problems. You can remotely check the service status using the SC.EXE command line tool.
C:\>sc \\xplab query winmgmt
TYPE'''''''''''''' : 20' WIN32_SHARE_PROCESS
STATE''''''''''''' : 4' RUNNING
WIN32_EXIT_CODE''' : 0' (0x0)
CHECKPOINT'''''''' : 0x0
WAIT_HINT''''''''' : 0x0
You can also use Windows PowerShell and the Get-Service cmdlet.
PS C:\> get-service winmgmt -ComputerName xplab
Status'' Name'''''''''''''' DisplayName
------'' ----'''''''''''''' -----------
Running' winmgmt''''''''''' Windows Management Instrumentation
By the way, this does not require PowerShell 2.0 or remoting on the remote computer, but it does require RPC connectivity.
Or you can use the graphical Services management console to connect to the remote machine and verify. I typically use the command shortcut services.msc /computer:COMPUTERNAME to launch and connect. Thus to check XPLAB I'd run services.msc /computer:xplab. Using the GUI you're looking for the Windows Management Instrumentation service.
A running service is only half of WMI. We also need to verify we can get information. One way to test is to use the WBEMTest utility. Launch it from Start-Run with the command wbemtest.

Figure 2 Launching WBEMTest

Click the connect button.

Figure 3 Connecting to a remote machine

In the Namespace field, enter computernamerootcimv2. The connection will be made with your current credentials which should have administrator rights on the remote computer. Optionally, you can enter in an alternate credential for User. Use the format domainusername. Then enter a password. You can leave everything else as is. Assuming everything is configured property, you should get something like Figure 4. Any errors should be clear enough to guide you in troubleshooting.

Figure 4 A Successful WMI Connection

Now let's execute a query. Click the Query button and enter a WMI query like 'Select * from win32_OperatingSystem'. Then click Apply.

Figure 5 A WMI Query

Assuming a valid query, you should get a result like Figure 6.

Figure 6 A WMI Query Result

At this point I've verified that WMI is running correctly on XPLAB. If you want to see the details, double click an entry in the Query Result window.

Figure 7 A WMI Object

To exit, simple close all the windows. An easier way to test WMI is to use Windows PowerShell and the Get-WMIObject cmdlet. Here's the same result but with an easy one-line command.
PS C:\> Get-WmiObject win32_operatingsystem -ComputerName xplab
SystemDirectory : C:\WINDOWS\system32
Organization''' : JDHLab
BuildNumber'''' : 2600
RegisteredUser' : Jeff
SerialNumber''' : 76487-341-0533244-22849
Version'''''''' : 5.1.2600
In this situation I'm not so much interested in the result as much as that I successfully returned something.


One final network check which is vital if you are planning on leveraging the remoting features in PowerShell 2.0 is to verify that WinRM is configured and running. There are two components you will want to test. First, the WinRM service must be running. Again, we'll use the Get-Service cmdlet.
PS C:\> get-service winrm -ComputerName xplab
Status'' Name'''''''''''''' DisplayName
------'' ----'''''''''''''' -----------
Running' winrm''''''''''''' Windows Remote Management (WS-Manag...
The other piece of the puzzle is to verify the WS-MAN protocol using the Test-WSMan cmdlet.
PS C:\> test-wsman -ComputerName xplab
wsmid'''''''''' : http://schemas.dmtf.org/wbem/wsman/identity/1/wsmanidentity.xsd
ProtocolVersion : http://schemas.dmtf.org/wbem/wsman/1/wsman.xsd
ProductVendor'' : Microsoft Corporation
ProductVersion' : OS: 0.0.0 SP: 0.0 Stack: 2.0
You should get a result. To verify the WinRM configuration use the command line tool WinRM like this:
C:\>winrm get winrm/config -machine:xplab
Or use PowerShell. First connect to the remote computer.
PS C:\> Connect-WSMan xplab
This will create a new container in the WSMAN PSDrive.
PS C:\> cd wsman:
PS WSMan:\> dir
ComputerName''''''''''''''''''''''''''''''''' Type
------------''''''''''''''''''''''''''''''''' ----
xplab'''''''''''''''''''''''''''''''''''''''' Container
localhost'''''''''''''''''''''''''''''''''''' Container
You can look at different settings with a simple DIR command.
PS C:\> dir wsman:xplab
WSManConfig: Microsoft.WSMan.Management\WSMan::xplab
Name''''''''''''''' Value''''' Type
----''''''''''''''' -----''''' ----
MaxEnvelopeSizekb'' 150''''''' System.String
MaxTimeoutms''''''' 60000''''' System.String
MaxBatchItems'''''' 32000''''' System.String
MaxProviderRequests 4294967295 System.String
Client'''''''''''''''''''''''' Container
Service''''''''''''''''''''''' Container
Shell''''''''''''''''''''''''' Container
Listener'''''''''''''''''''''' Container
Plugin'''''''''''''''''''''''' Container
ClientCertificate''''''''''''' Container
PS C:\> dir wsman:xplab\client
Name'''''''''''' Value Type
----'''''''''''' ----- ----
NetworkDelayms'' 5000' System.String
URLPrefix''''''' wsman System.String
AllowUnencrypted false System.String
Auth'''''''''''''''''' Container
DefaultPorts'''''''''' Container
TrustedHosts'''' *'''' System.String
PS C:\> dir wsman:xplab\listener
WSManConfig: Microsoft.WSMan.Management\WSMan::xplab\Listener
Name''''''''''''''''''''' Type'''''''''''''''' Keys
----''''''''''''''''''''' ----'''''''''''''''' ----
Listener_641507880''''''' Container''''''''''' {Address=*, Transport=HTTP}
If all of this checks out with error, then PowerShell remoting should work for you.

A PowerShell Alternative

If you are like me, you don't necessarily want to manually have to run each of these network tests, tools and checks. Wouldn't it be nicer to have a command line tool so you could check the network health of a computer at a glance? I thought so which is why I wrote a PowerShell function called Get-NetworkStatus. You can download the complete file here.
This PowerShell script takes one or more computer names as parameters, or you can pipe a collection of names to it. The script runs through all of the tests I've discussed in this article in addition to a few other useful tidbits such as DHCP lease information. It then writes a custom object to the pipeline. Here's an example.
PS C:\> S:\Get-NetworkStatus.ps1 XPLAB
CShare''''''''' : False
Computername''' : XPLAB
LeaseObtained'' : 1/19/2011 9:22:58 AM
WMI'''''''''''' : False
AdapterHostname : xplab
Ping''''''''''' : True
AdminShare''''' : False
DHCPServer''''' :
WinRM'''''''''' : False
LeaseExpires''' : 1/27/2011 9:22:58 AM
DNSDomain'''''' : jdhlab.local
MACAddress''''' : 08-00-27-AD-81-3E
IPAddress'''''' :
ReverseLookup'' : True
DNSHostName'''' : XPLAB.jdhlab.local
I ran this command from another computer. I can tell that I have some issues with this machine that might cause problems later on such as a lack of access to administrative shares. It also looks like I can't get remote service information. Once I've corrected the misconfigurations on XPLAB, running my script again shows everything in order.
PS C:\> S:\Get-NetworkStatus.ps1 XPLAB
CShare''''''''' : True
Computername''' : XPLAB
LeaseObtained'' : 1/19/2011 9:22:58 AM
WMI'''''''''''' : True
AdapterHostname : xplab
Ping''''''''''' : True
AdminShare''''' : True
DHCPServer''''' :
WinRM'''''''''' : True
LeaseExpires''' : 1/27/2011 9:22:58 AM
DNSDomain'''''' : jdhlab.local
MACAddress''''' : 08-00-27-AD-81-3E
IPAddress'''''' :
ReverseLookup'' : True
DNSHostName'''' : XPLAB.jdhlab.local
Because this is PowerShell, you can incorporate it into more complex expressions. I leave you with an example that queries my Desktop computer organizational unit using the Active Directory module, then testing every computer. If the computer replies to a ping, then all of the network status information is exported to a CSV file.
PS C:\> import-module ActiveDirectory
PS C:\> Get-ADComputer -Filter * -SearchBase "OU=Desktops,DC=jdhlab,DC=local" |
>> Foreach {S:\Get-Networkstatus $_.Name} | Where {$_.Ping} |
>> Export-CSV -Path C:\Work\Desktop-Net-Report.csv -NoTypeInformation
This will take a while to run so you might prefer to use a background job. But the end result is CSV file you can open in Microsoft Excel for further reporting or analysis.