90% of network administrators often work to diagnose and resolve a wide variety of failures. Although no one likes trouble, the trouble is always to find the door. Only with superb diagnostic skills can you respond quickly in an emergency and keep your network running smoothly. When you are faced with the challenge of network failure, first ask yourself a few simple questions: Where have you changed? Has this problem been encountered before? If so, when is it? Is it possible to let the problem reappear? User What special operations have you done? Have other users encountered the same problem?

Next try to isolate the problem, each time to eliminate some of the factors that may cause the problem, and gradually find out the real source of the problem. For example, if a workstation cannot connect to the server, then determine if it is a network problem or a problem with the workstation itself. If you can quickly be sure that the problem is with the workstation itself, you've ruled out a large percentage of the factors that can cause problems, and it's a big step toward the root cause of real failure. Even if you can't find a solution, you have to find foreign aid, and isolation will save you a lot of time.

To illustrate the general process of diagnosing network failures, this article exemplifies several failure scenarios, some of which are common minor problems, and some of which are more difficult. When you encounter a similar problem, you can follow the example in this article, ask yourself a few simple questions, gradually isolate the problem, and finally find the real source of the problem.

Failure 1. The domain server that failed to find the verification password

There is no doubt that you must have encountered a situation where when you are sitting on a workstation and ready to log in to the network, Windows reports that the domain server used to verify the password cannot be found. To resolve this failure, first determine if the problem is on the network, workstation, or server. Start with the following questions:

→Where has it changed? Have you changed the network recently, and these changes may cause current problems? Have you added new servers, removed existing servers, changed switches or HUBs? Have you added or reduced domain controllers, Is the member server promoted to DC (domain controller) or vice versa?

→ Is there a similar problem with other workstations?

→ Is the server running?

After checking, you found that the workstation has been running smoothly before, other workstations have not encountered similar problems, and the server is normal. According to the fault phenomenon, it can basically be determined that the fault is on the workstation itself. Next, to make sure that the workstation is out of order, try the following questions:

→ Can the workstation ping to the server?

→ Has the workstation obtained an IP address?

Detections indicate that the workstation can ping to the server, but the Ping operation sometimes times out, indicating that there is only intermittent communication between the workstation and the server. Execute the ipconfig/renew command on the command line and execute it several times. The workstation sometimes updates the IP address, sometimes not. This is a symptom of intermittent communication between the workstation and the server.

Now the network connection of the problem workstation is changed to another workstation. The new workstation cannot be connected to the network at the location of the problem workstation, and the problem workstation can successfully connect to the network from another network location. It is now clear that there is a problem with the cable or the hub where the problem workstation is located.

Remove the end of the network cable connected to the Hub at the fault location and connect it to another Hub. The fault persists. It is now certain that the cable is the culprit causing the failure.

Fault 2, Windows service can not start

On a Windows 2000 server, some services are set to start without a local system account. After restarting the Windows 2000 server once, I found that these services did not start. I had to manually open the service, re-enter the password, and then start the service. Each time you re-enter your password, you receive a message saying: <username> has been granted permission to log in as a service.

To resolve this failure, first answer the following questions:

→Where has it changed? Has anyone modified the server?

→ Has this service been started before?

→ Is the user name and password correct?

The query modification record found that the server is a DC and was not a member of the domain controller organizational unit (OU, OrganizationalUnit). These services have been able to start smoothly before moving out of the OU. In addition, the user name and password used to start these services are legal. Further research found that members of the domain controller OU have some special permissions, including permissions to log in as a service. When the server in question goes out of the OU, the server loses those permissions. What you need to do now is to restore the server's permissions.

To grant permissions to the server, follow these steps:

→ Open the Active Directory Users and Computers snap-in in the Management Console (MMC) and open the Properties dialog for the Domain Controllers OU.

→ On the Group Policy page, click Default Domain Controller Policy, and then click Edit to open the Group Policy Manager.

→ Expand Computer Configuration / Windows Settings / Security Settings, expand "Local Policies", and then click "User Rights Assignment".

→ In the right pane, right-click "Log in as a service" and select the menu "Security".

→ Add the user account used to start the service to the policy (Figure 1), and click “OK” when finished.