Run the executable and extract the files to a folder on your server. Then install the protocol stack by running setup.exe. If you are running Service Pack 2 or later (and hopefully you are), you have to perform some additional steps to get the installation to work. By default if you run the setup program it will complain about the system not being at Service Pack 1. Follow the directions on the following site to fix the problem: http://msdn.microsoft.com/downloads/sdks/platform/tpipv6/faq.asp.

Once you have the stack installed, you should follow the steps outlined in the graphical user interface instructions to configure it for a particular network connection (which also applies to Windows Server 2003).

Using a graphical user interface

1. Open the Control Panel.
2. From the Network Connections applet, double-click the connection you want to install IPv6 for.
3. Click the Properties button.
4. Click the Install button.
5. Select Protocol and click the Add button.
6. Select Microsoft TCP/IP version 6 and click OK.
7. Click Close.

Using a command-line interface

The following command installs the IPv6 stack. It must be run directly on the target server:

> netsh interface ipv6 install

If you need to run the command remotely, you can use the psexec command:

> psexec \\server01 netsh interface ipv6 install

Using VBScript

There is no scripting interface to install the stack, but you can shell out and run the netsh command as in the following example:

' This code installs the IPv6 on the computer the script is run from.strCommand = "netsh interface ipv6 install"

set objWshShell = WScript.CreateObject("WScript.Shell")

intRC = objWshShell.Run(strCommand, 0, TRUE)

if intRC <> 0 then

WScript.Echo "Error returned from running the command: " & intRC

else

WScript.Echo "Command executed successfully"

end if

IPv6 is the next generation TCP/IP protocol suite intended to replace IPv4. Adoption of IPv6 has been slow, but seems to be steadily gaining momentum. Fortunately, Windows Server 2003 provides better support for IPv6 than it did Windows 2000. For a good overview of IPv6 and how to configure the Windows client, see the following FAQ: http://msdn.microsoft.com/downloads/sdks/platform/tpipv6/faq.asp.

The Windows Server 2003 Resource Kit includes a new tool called linkspeed, which measures the connectivity between two hosts. You run the command from one system and target a remote system:

> linkspeed /s \\<ServerName>

> linkspeed /s <ServerDNSName>

Alternatively, you can specify the /dc switch to have it test the machine’s current domain controller:

> linkspeed /dc

I’ve tested linkspeed on Windows 2000. While it runs without fatal errors, it doesn’t produce consistent results. It works best when the target system is another Windows Server 2003 machine.

Finding the link speed between two hosts is often useful when troubleshooting network connectivity problems. For example, if a client is having problems authenticating to Active Directory, you should learn the link speed between the client and the domain controller with which it is authenticating. A slow speed, perhaps due to congestion, could be the cause. If you want to determine the average link speed between two hosts, you should run the linkspeed command several times over multiple days. The results for any particular run of linkspeed could vary significantly depending on what is happening in the network at that time.

Using a graphical user interface

1. Open the Control Panel.
2. From the Network Connections applet, open the connection you want to configure.
3. Click the Properties button.
4. Select Internet Protocol (TCP/IP).
5. Click the Properties button.
6. Click the Advanced button.
7. Click the Options tab.
8. Select TCP/IP filtering.
9. Click the Properties button.
10. Check the box beside Enable TCP/IP Filtering.
11. Select Permit Only for TCP Ports, UDP Ports, and/or IP Protocols.
12. Click the Add button.
13. Enter the port or protocol number and click OK.
14. Repeat the last couple of steps until you’ve entered all desired ports and protocols.
15. After you are done, close all the dialog screens by clicking either OK or Close.
16. You will be prompted to reboot for the changes to take effect.

Using a command-line interface

The following command enables TCP/IP filtering:

> reg add HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters /vEnableSecurityFilters /t REG_DWORD /d 1

You must reboot for the changes to take effect. To disable filtering, change /d 1 to /d 0.

Next, configure the protocols and ports you want to filter. This must be done on a per-interface basis. To configure this using the registry, you need to know the GUID assigned to the interface you want to modify. This is a sample interface entry:

HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\{07383FC4-FF4D-4E16-9DD6-C27061719D76}

To find out what adapter that corresponds with, you can use this command (on Windows Server 2003):

> wmic nicconfig get caption,settingid

Once you know the GUID of the interface, you can use the reg add command to modify the RawIPAllowedProtocols, TCPAllowedPorts, or UDPAllowedPorts values to filter what you want. Each of those values is of type REG_MULTI_SZ. Here is an example of setting protocols 25 and 80:

reg add HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\{07383FC4-FF4D-4E16-9DD6-C27061719D76} /v RawIPAllowedProtocols /t REG_MULTI_SZ /d 25\080

You can also use the WMIC utility to configure TCP/IP filtering. These two commands show you how:

> wmic /node:"<ServerName>" nicconfig call EnableIPFilterSec(1)> wmic /node:"<ServerName>" nicconfig where ipenabled=True call EnableIPSec

(<TCPPortList>),(<UDPPortList>),(<ProtoList>)

This command allows all TCP and UDP ports, but allows only protocols 80 (http) and 25 (smtp):

> wmic nicconfig where ipenabled=True call EnableIPSec (80,25),(0),(0)

Using VBScript

' This code enables IP Filtering for all adapters and configures' filtering for all IP-enabled adapters.

' ------ SCRIPT CONFIGURATION ------

strComputer = "."

arrTCPPorts = Array ( 0 )       ' Allow all TCP ports

arrUDPPorts = Array ( 0 )       ' Allow all UDP ports

arrProtos   = Array ( 80, 25 )  ' Allow only HTTP and SMTP

' ------ END CONFIGURATION ---------

set objWMI = GetObject("winmgmts:\\" & strComputer & "\root\cimv2")

set objAdapterConfig = objWMI.Get("Win32_NetworkAdapterConfiguration")

intRC = objAdapterConfig.EnableIPFilterSec( True )

if intRC = 0 then

WScript.Echo "IP Filtering for all adapters enabled"

elseif intRC = 1 then

WScript.Echo "IP Filtering enabled for all adapters, " & _

"but you must reboot for the changes to take effect"

else

WScript.Echo "There was an error enabling IP Filtering for all " & _

"adapters: " & intRC

end ifset colNAConfigs = objWMI.ExecQuery( _

"select * " & _

" from Win32_NetworkAdapterConfiguration " & _

" where IPEnabled = True" )

for each objNAConfig in colNAConfigs

intRC = objNAConfig.EnableIPSec( arrTCPPorts, arrUDPPorts, arrProtos )

if intRC = 0 then

WScript.Echo "IP Filtering configured for '" & _

objNAConfig.Description & "'"

elseif intRC = 1 then

WScript.Echo "IP Filtering configured for '" & objNAConfig.Description & _

"', but you must reboot for the changes to take effect"

else

WScript.Echo "There was an error configuring IP Filtering for '" & _

objNAConfig.Description & "': " & intRC

end if

next

Filtering by port or protocol can be useful in certain situations, but be aware of the limitations. A good example of when you might want to configure filtering is for external web servers. If your web server is running on the default HTTP port (80) and it is running no other networked application, then you only need port 80 open. But allowing only port 80 traffic also prevents the server from acting as a member in an Active Directory domain (which requires several ports to be open) and makes remote administration difficult because you can’t connect using the Terminal Services client. Obviously you can add these ports to the list you allow, but remember that if you do port/protocol filtering, you must have the ports/protocols open that are needed to support the machine.

1.  

   Open the Network Monitor tool (netmon.exe). Network Monitor is not installed by default. To install it:

    

   1. Go to the Control Panel and open the Add or Remove Programs applet.
   2. Click on Add/Remove Windows Components.
   3. Double-click on Management and Monitoring Tools.
   4. Check the box beside Network Monitor Tools and click OK.
   5. Click Next.
   6. Click Finish.

2.  

   The first time you start Network Monitor, you will be asked from which network interface you want to capture data. On Windows Server 2003, Microsoft finally made the list of interfaces to choose easy to distinguish because they labeled each one by its connection name (e.g., Local Area Connection). With Windows 2000, it doesn’t include that information in the label, so choosing an interface is almost a guessing game unless you know the MAC address prefix of your NIC card vendor. A trick you can use to narrow the list of interfaces is to disregard any that have a Dial-up connection setting marked as TRUE. After you’ve selected an interface, click OK.

3.  

   From the menu, select Capture > Start. If you don’t see the Network Utilization and Frames Per Second indicators fluctuating (a sign traffic is being captured), you likely picked the wrong interface in Step 2. If so, stop the capture by selecting Capture > Stop from the menu. Then select Capture > Networks. You’ll be presented with the same screen as in Step 2 that allows you to select the target interface.

4.  

   When you want to stop the capture, select Capture > Stop from the menu. Or if you want to immediately view the traffic, select Capture > Stop and View.

5.  

   If the captured data is too much to look at, you can filter it by selecting Display > Filter from the menu. From there you can enter Boolean expressions to limit what is displayed.

Using a command-line interface

The Windows Server 2003 Support Tools contains a new tool called netcap.exe that can capture packets to a file for viewing later in Network Monitor. Here is an example command line:

> netcap /C:d:\netcap.cap /N:1

This command captures packets on interface #1 and stores the output in d:\netcap.cap. To make sure you are capturing on the correct interface, view the netcap help information:

> netcap /?

At the very end, it displays the list of interfaces on the system and their associated numbers. To view the contents of the capture file, double-click it. This will launch the Network Monitor.

Network Monitor (NetMon) is not the most user-friendly tool, but it offers powerful features for collecting, filtering, and analyzing a network capture. For more on how to use some of the features of NetMon, see the MS KB articles listed in the See Also section.

One thing that is worth noting about NetMon is that it has a default buffer limit of 1 MB. After the data it captures exceeds 1 MB, it begins to overwrite the oldest packets using FIFO (first in, first out). You can increase the size of the buffer to a max of 1 GB. To increase the buffer, select Buffer Settings from the Capture menu. Enter the maximum number of megabytes and click OK.

If you are interested in an alternative to NetMon, Ethereal is one of the most popular network traffic analyzers and it is available free from the following site: http://www.ethereal.com/.

After you’ve checked the hardware, you can run several command-line tools to aid in troubleshooting connectivity issues. A good first step is to ping the target host, which can tell you if the remote host is reachable and how long it takes to reach it:

> ping <HostNameOrIP>

Here are some of the status messages you can receive from ping:

Reply

The host was reachable.

Request timed out

The target host either did not respond or there is no host configured with the corresponding IP address. You may also see this message if there is a lot of network latency between the two endpoints. You can work around this by using the -w option with ping and specifying the number of milliseconds to wait for each reply.

Unknown host

If you used a DNS name in the ping command, this indicates that the DNS name was not resolvable by the DNS client.

Destination unreachable

The ICMP traffic could not reach the network of the target host. This is often due to a routing problem on an intermediate router or a router being down.

If you’ve pinged a host and the request timed out or the host was unreachable, a good tool to try next is tracert, which attempts to trace a route from the source computer to the destination computer.

> tracert <HostNameOrIP>

This command shows you the path your data takes to get to the destination. If there are connectivity problems with a remote host, this command shows where the problem occurs.

If everything checks out, next run the netdiag command on the target system. netdiag provides a wealth of information about various network settings configured on the system along with information about DNS, Kerberos, and Active Directory connectivity. Use the /debug option to view detailed output. If you suspect authentication (Kerberos) to be a potential issue, run the kerbtray utility to ensure you have functioning Kerberos tickets.

If you are still having network problems, a good last step is to look at the network traffic to see if you can spot any obvious errors being transmitted.

The Sysinternals TCPView tool is a graphical interface that displays all of the active connections on a host. It displays all of the connection information you might need, including process name and ID, protocol, local address and port, and remote address and port. It is a real-time tool, so it shows connections that are terminating in red and new connections in green. You can close a connection by right-clicking it and selecting Close Connection. You can also kill the associated process by selecting End Process.

Using a command-line interface

The netstat command displays all established connections on a host:

> netstat

Use the -a option to view all open ports regardless of whether they are active. With the Windows Server 2003 version of netstat, you can view the process ID associated with connections by specifying the -o option.

The Sysinternals netstatp utility is the command-line version of TCPView. It displays similar information to netstat, but it shows the process name and ID associated with the connection by default:

> netstatp

Using VBScript

' This code produces output very similar to the 'netstat -an' command.' It requires that the target machine have SNMP and the WMI SNMP

' Provider installed.

' ------ SCRIPT CONFIGURATION ------

strComputerIP = "127.0.0.1"

' ------ END CONFIGURATION ---------

set objLocator = CreateObject("WbemScripting.SWbemLocator")

set objWMI = objLocator.ConnectServer("", "root/snmp/localhost")

set objNamedValueSet = CreateObject("WbemScripting.SWbemNamedValueSet")

objNamedValueSet.Add "AgentAddress", strComputerIP

objNamedValueSet.Add "AgentReadCommunityName", "public"

objNamedValueSet.Add "AgentWriteCommunityName", "public"WScript.Echo " Proto  Local Address   Foreign Address       State"

set colTCPConns = objWMI.Instancesof("SNMP_RFC1213_MIB_tcpConnTable",, _

objNamedValueSet )

for each objConn in colTCPConns        WScript.echo "  TCP   " & objConn.tcpConnLocalAddress & ":" & _

objConn.tcpConnLocalPort & _

"         " & objConn.tcpConnRemAddress & ":" & _

objConn.tcpConnRemPort & "       " & objConn.tcpConnState

next

set colUDPConns = objWMI.Instancesof("SNMP_RFC1213_MIB_udpTable",, _

objNamedValueSet )

for each objConn in colUDPConns

WScript.echo "  UDP   " & objConn.udpLocalAddress & ":" & _

objConn.udpLocalPort & "         *:*"

next

When you take a look at the list of open connections on a server, you may be surprised to see so many. Unless the server is extremely busy, most should be in the LISTENING state, which simply means the port is open and waiting for a connection. For more on the various states that a connection may be in, see MS KB 137984.

The following command displays all the static and dynamic routes on a system:

> route print

This command only shows routes that start with 64:

> route print 64.*

To add a temporary route (one that is erased after the system reboots), use this command:

> route ADD <Network> MASK <Mask> <Gateway> MEtrIC <Metric> IF <Interface#>

For example:

> route ADD 157.0.0.0 MASK 255.0.0.0 157.55.80.1 METRIC 3 IF 2

To add a permanent route, use the same command as before except include the -p switch. To delete a route, use this command:

> route DELETE <Network>

For example:

> route DELETE 157.0.0.0

Using VBScript

' This code prints similar information to the "route print" command.

' Since the Win32_IP4RouteTable class was first introduced in

' Windows Server 2003, this script does not work against a

' Windows 2000 server.

' ------ SCRIPT CONFIGURATION ------

strComputer = "."

' ------ END CONFIGURATION ---------

set objWMI = GetObject("winmgmts:\\" & strComputer & "\root\cimv2")

set colRoutes = objWMI.InstancesOf("Win32_IP4RouteTable")

for each objRoute in colRoutes    set colNetworkAdapters = objWMI.ExecQuery(_

                    "select * from Win32_NetworkAdapterConfiguration " & _

                    " where Interfaceindex = " & objRoute.InterfaceIndex )

    for each objNetworkAdapter in colNetworkAdapters

       for each strIP in objNetworkAdapter.IPAddress

          WScript.Echo "Interface: " & strIP

       next

    next

WScript.Echo "Network:   " & objRoute.Destination

    WScript.Echo "NetMask:   " & objRoute.Mask

    WScript.Echo "Gateway:   " & objRoute.NextHop

    WScript.Echo "Metric:    " & objRoute.Metric1

' Other properties you can display:

    ' WScript.Echo "Age: " & objRoute.Age

    ' WScript.Echo "Description: " & objRoute.Description

    ' WScript.Echo "Information: " & objRoute.Information

    ' WScript.Echo "Interface Index: " & objRoute.InterfaceIndex

    ' WScript.Echo "Metric 2: " & objRoute.Metric2

    ' WScript.Echo "Metric 3: " & objRoute.Metric3

    ' WScript.Echo "Metric 4: " & objRoute.Metric4

    ' WScript.Echo "Metric 5: " & objRoute.Metric5

    ' WScript.Echo "Name: " & objRoute.Name

    ' WScript.Echo "Protocol: " & objRoute.Protocol

    ' WScript.Echo "Status: " & objRoute.Status

    ' WScript.Echo "Type: " & objRoute.Type

WScript.Echo

next

' This code shows how to add a route.

' Since the Win32_IP4RouteTable class was first introduced in

' Windows Server 2003, this script does not work against a

' Windows 2000 server.

' ------ SCRIPT CONFIGURATION ------

strComputer = "."

' ------ END CONFIGURATION ---------

set objLocator = CreateObject("WbemScripting.SWbemLocator")

set objWMI = objLocator.ConnectServer(strComputer, "root/CIMv2")

set objR = objWMI.get("Win32_IP4RouteTable").SpawnInstance_( )

objR.Destination = "64.0.0.0"

objR.NextHop = "64.102.57.1"

objR.Mask = "255.0.0.0"

objR.InterfaceIndex = 65539

objR.Metric1 = 22

objR.Protocol = 1

objR.Type = 4

objR.Put_( )

Wscript.Echo "Successfully created route"

If networks are designed properly, system administrators shouldn’t have to worry much about how traffic is being routed. Nevertheless, in certain situations where the network is not fully routed or you are experiencing routing issues, you may need to dig into a server’s routing tables. You can also add static routes to temporarily get traffic flowing the way you want to or force it to go a certain way. However, I do not recommend configuring permanent static routes if you can avoid it. This type of manual configuration if often overlooked or forgotten and can be a headache to track down later unless the configuration changes are well known by all that are maintaining the server.

In the following command, replace <HostName> with the name of the host whose site you want to find.

> nltest /server:<HostName> /DsGetSite

To force a computer to use a particular site, modify the registry as follows:

> reg add HKLM\System\CurrentControlSet\Services\Netlogon\Parameters /v SiteName /t

REG_SZ /d <SiteName>

Using VBScript

Although you cannot use it directly from a scripting language such as VBScript, Microsoft provides a DsGetSiteName method that can be used by languages such as Visual Basic and C++ to retrieve site coverage information. In fact, the nltest command shown in the CLI solution is a wrapper around this method.

The IADsTools interface provides a wrapper around this method.

set objIadsTools = CreateObject("IADsTools.DCFunctions")

strSite = objIadsTools.DsGetSiteName("<HostName>")

Wscript.Echo "Site: " & strSite' This code forces the host the script is run on to use a particular site

' ------ SCRIPT CONFIGURATION ------

strSite = "<SiteName>"   ' e.g., Raleigh

' ------ END CONFIGURATION ---------

strNetlogonReg = "SYSTEM\CurrentControlSet\Services\Netlogon\Parameters"

const HKLM = &H80000002

set objReg = GetObject("winmgmts:root\default:StdRegProv")

objReg.SetStringValue HKLM, strNetlogonReg, "SiteName", strSite

WScript.Echo "Set SiteName to " & strSite

Each domain controller has a server object that is contained within a site. Clients are differentthey are associated with a site based on their IP address, and the corresponding subnet that it matches is in the Subnets container. The client site information is important because it determines which domain controller it will authenticate against. If the client’s IP address does not match a subnet range of any of the subnets stored in Active Directory, it will randomly pick a site to use, which means it could authenticate against any domain controller in the domain.

Finding the site that contains a client is an important first step when troubleshooting authentication delays or errors. If a client is experiencing significant delays, it could be that the client is authenticating with a random site because it is on a new subnet that has yet to be added to Active Directory. This may also result in a client authenticating over a slow WAN link.

You can bypass the part of the DC Locator process that determines a client’s site by hardcoding it in the Registry. This is generally not recommended and should primarily be used as a troubleshooting tool. If a client is experiencing authentication delays due to a misconfigured site or subnet object, you can hardcode its site so they temporarily point to a more optimal location (and domain controller).

The following command displays the contents of the local DNS cache:

> ipconfig /displaydns

And this clears that cache:

> ipconfig /flushdns

The following command causes the local host to reregister its DNS records via dynamic DNS:

> ipconfig /registerdns

Using VBScript

' This code flushes the local DNS cache.  There are no scripting

' interfaces designed to do this so I have to shell out and run

' the ipconfig /flushdns command.

strCommand = "ipconfig /flushdns"

set objWshShell = WScript.CreateObject("WScript.Shell")

intRC = objWshShell.Run(strCommand, 0, TRUE)

if intRC <> 0 then

   WScript.Echo "Error returned from running the command: " & intRC

else

   WScript.Echo "Command executed successfully"

end if' This code registers DNS records for the local host.  There are

' no scripting interfaces designed to do this so I have to shell

' out and run the ipconfig /registerhdns command.

strCommand = "ipconfig /registerdns"

set objWshShell = WScript.CreateObject("WScript.Shell")

intRC = objWshShell.Run(strCommand, 0, TRUE)

if intRC <> 0 then

   WScript.Echo "Error returned from running the command: " & intRC

else

   WScript.Echo "Command executed successfully"

end if

The Windows operating system maintains a name resolution cache of DNS records that the system has queried. This cache is maintained in memory and speeds up future requests for the same record. Each record has an associated time-to-live value. This setting informs clients of the maximum amount of time to cache that particular record. After the time-to-live period expires, Windows removes the record from its cache.

The Windows name resolution cache is maintained by the DNS Cache (DnsCache) service. You can prevent records from being cached by stopping this service (and disabling it if you never want records to be cached again). If you are getting strange results when querying DNS, you may want to view the local DNS cache to see if you are accessing locally cached records instead of what is current on the DNS Server.

The /registerdns option of ipconfig attempts to dynamically reregister DNS records for all IP addresses configured on the system. The DHCP Client (Dhcp) service does the DNS reregistration, so if that service is disabled, the /registerdns option won’t work (even if all addresses are statically configured).

To configure the DNS suffix, do the following:

1. From the Control Panel, open the System applet.
2. Select the Computer Name tab (Network Identification tab on Windows 2000).
3. Click the Change button (Settings button on Windows 2000).
4. Click the More button.
5. Enter the suffix under the Primary DNS suffix of this computer heading.
6. Check the box beside Change primary DNS suffix when domain membership changes if you want the suffix to change to the name of the Active Directory domain the computer joins.
7. Click OK until all the windows are closed. You will be prompted to reboot for the changes to take effect.

To modify the list of DNS servers used during name resolution, configure how unqualified names are resolved, and configure DNS dynamic registration, do the following:

1. From the Control Panel, open the Network Connections applet.
2. Double-click the connection you want to modify.
3. From this screen you can configure whether to use the DNS servers obtained through DHCP or to manually enter them. In the latter case, you can enter preferred and alternate DNS servers.
4. To configure the other DNS settings, click the Advanced button.
5. Select the DNS tab.
6. From this screen you can configure additional DNS servers to use during resolution, configure how unqualified names are handled, set a DNS suffix for this connection, and configure DNS registration for this connection.
7. When you are done, click OK until all screens are closed.

Using a command-line interface

To view the current DNS configuration for all connections on the local machine, run this command:

> netsh int ip show dns

To make a connection using DHCP-specified DNS settings, use this command:

> netsh int ip set dns "<ConnectionName>" dhcp

Here is an example:

> netsh int ip set dns "Local Area Connection" dhcp

To make a connection using a specified DNS server for name resolution, use this command:

> netsh int ip set dns "Local Area Connection" static <IPAddress>

Here is an example:

> netsh int ip set dns "Local Area Connection" static 10.0.0.1

This command allows you to specify only one DNS server for name resolution.

With the same command, you can also configure whether the connection registers the host’s name under the primary DNS suffix or the connection-specific suffix. To register just the primary DNS suffix, append “primary” to the end of the command. To register both, append “both.” To register nothing, append “none.” Here is an example:

> netsh int ip set dns "Local Area Connection" static 10.0.0.1 primary

With Windows Server 2003 Active Directory, you can now configure most DNS client settings via Group Policy. Windows 2000 Group Policy allowed you to only configure the primary DNS suffix (Computer Configuration > Administrative Templates > System > DNS Client > Primary DNS Suffix).

With Windows Server 2003, you can configure the DNS suffix, dynamic updates settings, search list, and DNS servers used for name resolution among many other settings. These settings can be found by navigating the following path of a Group Policy Object: Computer Configuration > Administrative Templates > Network > DNS Client.