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.
Ping
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 [192.168.56.203] with 32 bytes of data: Reply from 192.168.56.203: bytes=32 time<1ms TTL=128 Reply from 192.168.56.203: bytes=32 time<1ms TTL=128 Reply from 192.168.56.203: bytes=32 time<1ms TTL=128 Reply from 192.168.56.203: bytes=32 time=1ms TTL=128 Ping statistics for 192.168.56.203: 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'''''' 192.168.56.203 {}''''''''' 32''' 1
CLIENT1 xplab'''''' 192.168.56.203 {}''''''''' 32''' 0
CLIENT1 xplab'''''' 192.168.56.203 {}''''''''' 32''' 0
CLIENT1 xplab'''''' 192.168.56.203 {}''''''''' 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.
NSLookup
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 Address:' 192.168.56.102 Name:''' xplab.jdhlab.local Address:' 192.168.56.203
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 Address:' 192.168.56.102 *** 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.
C:\>nslookup 192.168.56.203 Server:' coredc01.jdhlab.local Address:' 192.168.56.102 *** coredc01.jdhlab.local can't find 192.168.56.203: 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.
C:\>nslookup 192.168.56.203 Server:' coredc01.jdhlab.local Address:' 192.168.56.102 Name:''' xplab.jdhlab.local Address:' 192.168.56.203
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$ True PS C:\> test-path \\xplab\admin$ True
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: [192.168.56.202] 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 SERVICE_NAME: winmgmt TYPE'''''''''''''' : 20' WIN32_SHARE_PROCESS STATE''''''''''''' : 4' RUNNING (STOPPABLE, PAUSABLE, ACCEPTS_SHUTDOWN) WIN32_EXIT_CODE''' : 0' (0x0) SERVICE_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.
WinRM
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 WSManConfig: 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''''' : 192.168.56.102 WinRM'''''''''' : False LeaseExpires''' : 1/27/2011 9:22:58 AM DNSDomain'''''' : jdhlab.local MACAddress''''' : 08-00-27-AD-81-3E IPAddress'''''' : 192.168.56.203 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''''' : 192.168.56.102 WinRM'''''''''' : True LeaseExpires''' : 1/27/2011 9:22:58 AM DNSDomain'''''' : jdhlab.local MACAddress''''' : 08-00-27-AD-81-3E IPAddress'''''' : 192.168.56.203 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.
Comments