Automatic Symptom Resolution Sequence (An Example)

Here’s an example of how a real problem would be resolved automatically by the ReSOFT Client. In this scenario, the local DART database does not have the DART, but the master DART database does.

The problem we will use as an example is one taken from the Microsoft Knowledge Base, article Q130710.

Symptom: The user attempts to send a message using Microsoft Exchange, and receives an error dialog saying "The message recipient's mailbag does not exist or is busy. Contact your administrator."

Cause: The post office is located on a Novell 3.11 server does not immediately respond to the "File Open" request from Exchange (perhaps it is doing a backup). This causes Exchange to repeat the request, which gets the server into a state where it always responds with a "File Already Open" failure. The underlying cause of the error is a problem with the long filename support on the server.

Solution: The preferred solution is to install a patch available from Novell, or to upgrade the server to version 3.12 or higher. A workaround for the problem is to disable long filename support on the ReSOFT client.

The problem first occurs when the customer attempts to send mail and gets the error message

• The ReSOFT Client running on the end-user's desktop detects the symptom by trapping the error message and begins the symptom resolution process
• The ReSOFT Client initiates the diagnostic DART related to email. One of these diagnostic procedures attempts to open the post office file and fails. This initiates several other tests of the network connectivity, but none of them result in an attempted solution
• All the events detected leading up to, and at the time of the symptom, and diagnostic actions and data collected by the ReSOFT client are stored in the event log database. In this example, the solution of this symptom is not in the local DART database but is in the master DART database located at the support provider's.
• At some point, depending on the frequency with which it is configured to check for DART database updates (as frequently as once per minute), the ReSOFT client initiates a DART database update. In this instance, the DART client discovers that new DART have been added to the master DART database since the last scheduled update for this end-user site.
• The new DART are downloaded to the end-user site. The ReSOLV client then closes the Internet connection and adds the new DART to the local DART database.
• The next time the symptom occurs, execution of the newly added DART that solves this symptom is automatically triggered, and the symptom is resolved. The "symptom" part matches: the server is a Novell 3.11 server, the attempt to open the post office file returns a "File Already Open" failure, and long filename support is enabled on the ReSOLV Client. The "solution" part of the pair is applied: the registry key "HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\VxD\NWREDIR" is edited, and a binary value "supportlfn" is added with a value of 0

The system is restarted (after confirming with the end-user). After the restart, access to the post office file is tested again and verified. The end-user is notified that a workaround has been applied. The end-user re-tries sending the email with Exchange, and it works correctly.

If, at some later date, the "supportlfn" value is deleted or altered, the newly added DART will detect that the server is a Novell 3.11 server, and long filename support is enabled. It will then restore the registry key without any intervention by the customer, having the effect of "silently" repairing the problem before it happens.