Parts 5 and Part 6 of this series, both look at some nice GUI-based tools to analyze web and network traffic. The good thing about these tools is that they allow you to analyze things from the comfort of an application window.
However, one needs not to discard some powerful command line base tools that have been around since the early days of DOS - and that's Disk Operating System, not DOS as in Dos Equis (XX). Today, I will talk about NETSH and NET
Netsh (Network Shell) is a command-line scripting utility that allows you to, either locally or remotely, display or modify the network configuration of a computer that is currently running. Netsh also provides a scripting feature that allows you to run a group of commands in batch mode against a specified computer. Netsh can also save a configuration script in a text file for archival purposes or to help you configure other servers.
With the Netsh.exe tool, you can direct the context commands you enter to the appropriate helper, and the helper then carries out the command. A helper is a Dynamic Link Library (.dll) file that extends the functionality of the Netsh.exe tool by providing configuration, monitoring, and support for one or more services, utilities, or protocols. The helper may also be used to extend other helpers.
You can use the Netsh.exe tool to perform the following tasks:
• Configure interfaces.
• Configure routing protocols.
• Configure filters.
• Configure routes.
• Configure remote access behavior for Windows-based remote access routers that are running the Routing and Remote Access Server (RRAS) Service.
• Display the configuration of a currently running router on any computer.
• Use the scripting feature to run a collection of commands in batch mode against a specified router.
So, how does this all apply to the Web Client?
WCF services and clients can communicate over HTTP and HTTPS. The HTTP/HTTPS settings are configured by using Internet Information Services (IIS) or through the use of a command-line tool. When a WCF service is hosted under IIS, HTTP or HTTPS settings can be configured within IIS (using the inetmgr.exe tool). If a WCF service is self-hosted - like Session Service, for example - HTTP or HTTPS settings are configured by command-line entries.
At the minimum you will want to configure a URL registration, and add a Firewall exception for the URL your service will be using. Fortunately, this configuration is done for us by the InstallShield application when running the installation of the Web Client runtime services components.
In the Web Client world, we use NETSH to check for namespace reservations and look at how ports are configured in relation to SSL certificates issued.
To display discretionary access control lists (DACLs) for the specified reserved URL or all reserved URLs, proceed to type from the command-line:
NETSH HTTP SHOW URLACL
To determine how ports are configured, type the following from the command-line:
NETSH HTTP SHOW SSLCERT
If the Web Client installation process went well, the Certificate Hash assigned to each port used by Session Service (port 48650), Session Central Service (port 48651), and Runtime Service (port 48652) should match the thumbprint value of the certificate in IIS, as displayed by the show sslcert option.
|Certificate hash on each listening port must match that of the certificate in IIS|
For more information on configuring HTTP and HTTPS transports for WCF, take a look at the following MSDN library article:
For more information on how to configure a port with an SSL certificate, take a look at the following MSDN library article:
Netstat (network statistics) is a command-line tool that displays network connections (both incoming and outgoing), routing tables, and a number of network interface (network interface controller or software-defined network interface) and network protocol statistics. It is used for finding problems in the network and to determine the amount of traffic on the network as a performance measurement.
The specific entry we want to run from the command-line in a Web Client environment is as follows:
This will return a list of ports that are in use and the process and application using them. If you want to select a port of your own choosing when installing Web Client, you will want to verify that the post is available and it is allowed through the firewall as necessary.
For more information on netstat, take a look at the following TechNet article:
The Web Client Diagnostic tool, which I talked about in Part 4 of this series collects these two pieces of information (among other command-line tools ran) as part of the data collection procedures performed when opening a Web Client support case.
Until next post!
Mariano Gomez, MVP