Step 7: Implement and Test the Solution

With the plan in place, you should be ready to implement a solution-that is, apply the patch, replace the hardware, plug in a cable, or implement some other solution. Ideally, your first solution would fix the problem, although unfortunately this is not always the case. If your first solution does not fix the problem, you need to retrace your steps and start again.

It is important that you attempt only one solution at a time. Trying several solutions at once can make it unclear which one actually corrected the problem.

TIP: A common and mandatory step that you must take when working on servers and some mission-critical workstations is to develop a rollback plan. The purpose of a rollback plan is to provide a method to get back to where you were before attempting the fix. Troubleshooting should not make the problem worse. Have an escape plan!

After the corrective change has been made to the server, network, or workstation, it is necessary to test the results. Never assume. This is where you find out whether you were right and the remedy you applied actually worked. Don't forget that first impressions can be deceiving, and a fix that seems to work on first inspection might not have corrected the problem.

The testing process is not always as easy as it sounds. If you test a connectivity problem, it is not difficult to ascertain whether your solution was successful. However, changes made to an application or to databases are typically much more difficult to test. It might be necessary to have people who are familiar with the database or application run the tests with you in attendance. For example, suppose that you troubleshoot an accounting program installed in a client/server configuration. Network clients access the accounting program and the associated data from the server. Recently, all network accountants receive only outdated data when using the application. You, being a network administrator and not an accountant, may have never used the program and therefore cannot determine the outdated data from current data. Perhaps you don't even know how to load the data in the application. How can you possibly determine whether you have corrected the problem? Even from this simple example, we can see that the process of testing results may require the involvement of others, including end users, managers, other members of the IT team, support professionals associated with third-party applications, and so on.

NOTE: When you complete a fix, test it as thoroughly as you can before informing users of the fix. Users would generally rather wait for a real fix than have two or three false starts.

In an ideal world, you want to fully test a solution to see whether it indeed corrects the problem. However, you might not know whether you were successful until all users have logged back on, the application has been used, or the database has been queried. As a network administrator, you will be expected to take the testing process as far as you realistically can, even though you might not simulate certain system conditions or loads. The true test is in a real-world application.

TIP: Virus Activity Keep in mind when troubleshooting a network or systems on a network that the problem might be virus-related. Viruses can cause a variety of problems that often disguise themselves as other problems. Part of your troubleshooting toolkit should include a virus repair disk with the latest virus definitions. Indicators that you might have a virus include increased error messages and missing and corrupt files.