Configuration Manager depends
on basic network services such as connectivity and name resolution to
work properly. Network-related issues are a common source of problems
that can
affect Configuration Manager service delivery. The next sections look
at some typical issues you may encounter related to network
dependencies. When troubleshooting, it is important to keep an open
mind. Some issues caused by incorrect security settings, for example,
can produce very similar symptoms to network issues.
Among the common network-related issues that can affect Configuration Manager are the following:
Network configuration issues
Basic connectivity problems
Name resolution issues
Blocked or unresponsive ports
Timeout issues
The following sections briefly describe a few of the many tools and techniques for troubleshooting these types of issues.
Network Configuration Issues
If you suspect that the TCP/IP networking on one
of your systems is not working correctly, you can log on to the system
and enter the following at the command prompt (Start -> Run, and then
type cmd):
You should see a list of the installed network
adapters with IP addresses and other IP configuration data. If no IP
address or only an autoconfiguration IP address is displayed, the
network components are either not configured or not functioning
properly. If this occurs when the IP address configuration is set to
obtain an IP address automatically, this means the machine was unable to
contact a DHCP server.
If the machine has one or more valid IP
addresses, you can test TCP/IP functioning by entering the following two
commands at the command prompt:
In both cases, you should see a series of replies, such as the following:
Reply from 127.0.0.1: bytes=32 time=9ms TTL=128
If you receive a request timed out message, TCP/IP networking on the machine is not working properly.
The
NetDiag.exe utility, which you can download from Microsoft’s website,
can be used to diagnose (and in some cases fix) a wide variety of
network configuration issues.
Basic Connectivity Problems
Basic connectivity problems occur if
Systems are not physically connected;
There is a hardware or software problem on one of the systems or an intermediate device;
The packets are not correctly routed between the systems.
To start troubleshooting basic connectivity, log
on to one of the affected systems and ping the system with which it has
problems communicating. To do this, open a command prompt (Start ->
Run, and then type cmd) and enter the following command:
Ping <IP address of target system>
In most cases, you should get a response showing
the time it took to get a reply to the ping request and other
statistics. If the system is not responding, you may get one of the
following messages:
Request timed out—
This simply means that you did not get a response in the expected time.
In some cases, the target system may have been configured not to
respond to a ping. You can test this on the target system by pinging its
own IP address to make sure it is responding. If you suspect that the
ping request timed out because of slow network conditions, you can try
increasing the timeout value from the default value of 1 second. As an
example, Ping -w 5000
<IP address of target system> will wait 5,000 milliseconds (5 seconds).
Destination Host Unreachable or Destination Network Unreachable— This is generally a response from a router indicating that no route is defined to the host or subnet.
Name Resolution Issues
Most Configuration Manager components rely on
DNS for name resolution. In some cases, ConfigMgr also uses NetBIOS name
resolution. Once again, you can use the ping command as a quick test of
name resolution. At the command prompt, enter
Ping
<FQDN of target system>
For example:
Ping bluebonnet.sccmunleashed.com
Ping
<hostname of target system>
For example:
Ping bluebonnet
Ping
<NetBIOS name of target system>
For example:
Ping \\bluebonnet
In each case, these commands should return a response showing the correct IP of the target system, such as the following:
Pinging bluebonnet.sccmunleashed.com [192.168.5.4] with 32 bytes of data:
If DNS name resolution fails, you can troubleshoot this using the NSlookup command described at http://support.microsoft.com/kb/200525. To troubleshoot NetBIOS name resolution using Nbtstat and other methods, see KB article 323388 (at http://support.microsoft.com/kb/323388).
It’s also useful to test pinging the known IP address of the target
machine—if that works then you have narrowed the issue to some sort of
name resolution–related issue.
An additional DNS problem that sometimes occurs
is an incorrect referral. Incorrect referrals occur when a hostname is
used instead of an FQDN, and the wrong domain name is appended due to
the DNS suffix search order. This typically results in “access denied”
errors. If you see unexpected “access denied” errors, try pinging the
site system using both the hostname and the FQDN to make sure they
resolve to the same address.
Blocked or Unresponsive Ports
A common source of connectivity problems
involves ports blocked by intermediate devices such as routers or
firewalls. In other cases, the port may simply not be listening on the
system to which you are trying to connect. To identify problems with
specific ports. You can then attempt to connect to the specific port on the
target system using the telnet command. For example, to verify that you
can connect to the Trivial File Transfer Protocol (TFTP) Daemon service
(port 69) on PXE service point Dabney.SCCMUnleashed.com, open a command prompt (Start -> Run, and then type cmd) and enter the following:
Telnet Dabney.SCCMUnleashed.com
69
If telnet is
successful, you will receive the Telnet screen with a cursor. If the
connection fails, you will receive an error message.
When a connection to a port fails, first verify
that the service is listening on the appropriate port. On the machine
that should receive the connections, enter the command netstat –a to list all connections and listening ports.
If the port is not shown, verify that all system requirements and prerequisites are met.
If the port displays as enabled, check all network firewall logs for dropped packets.
Refer to your network team or vendor firewall
documentation for procedures for checking firewall logs. Also, check the
Windows Firewall logs and settings (see http://technet.microsoft.com/en-us/network/bb545423.aspx) and any third-party security software that performs intrusion detection and prevention.
Additional tools are available for troubleshooting port status issues, such as the following:
Going to www.microsoft.com/downloads and searching for PortQry will bring up links for both these tools.
|
To test client connectivity to an MP, you can try entering the following URLs in the client’s web browser.
For mixed mode clients:
http://<MP>/sms_mp/.sms_aut?mplist http://<MP>/sms_mp/.sms_aut?mpcert
For native mode clients:
https://<MP>/sms_mp/.sms_aut?mplist https://<MP>/sms_mp/.sms_aut?mpcert
Note that <MP> is either the IP address or the name of the management point. If a name is used, the name should be one of the following:
The NetBIOS name for mixed mode clients Either
the short name or the FQDN for intranet clients in native mode,
depending on how the management point name is specified in the site
properties The FQDN for Internet clients
In each case, the first URL (the one ending in
“mplist” in the preceding examples) should return an XML-formatted list
of management points or a blank page, whereas the second URL (ending in
“mpcert”) should return a string of characters corresponding to the
management point certificate. Any error messages or other unexpected
return values indicate a problem communicating with the management
point.
|
Timeout Issues
The
response times you see from the ping command can help you to confirm
network performance problems that could be causing connections to time
out. In some cases timeouts are configurable; however, if timeouts are a
frequent problem, you should review your server placement and network
configuration to see if improvements can be made.
