<< Click to Display Table of Contents >> Navigation:  Modules > Asset Management > Client Operations - Workstation Data Assistant > Self-Healing: Remediation

If the ActiveX is available in catch point screens in the environment, and if there is an alternate software delivery capability (such as Altiris or SCCM), then the MIE can be set up to detect issues with the WDA and perform an automated remediation.

Certain catchpoint screens will invoke the ActiveX’s WDA Remediation routine, which checks for conditions that can affect the WDA. The ActiveX reports back any issues to the MIE, where a housekeeping routine checks for the statuses, and, if any issues are found, schedules a WDA Remediation Task to run on the workstation. The WDA Remediation Task, when run on the workstation, checks for problems with the WDA and corrects them. This might involve simply starting the ESIScheduler service, or it may involve re-installing the WDA application, depending on what conditions are found by the remediation task. Conditions checked by the WDA include a registry check, checks on the ESIScheduler service, for the existence of executable files that make up the WDA, and so forth.

The ActiveX does not remediate any WDA issues, primarily because the ActiveX runs under the control of a browser and under the credentials of the logged-on user, and therefore typically will not have the required privileges to perform remediation. Instead, the ActiveX sends up an error string based upon conditions that may impact the WDA, and, later, a task is delivered, via APS, to perform the remediation. This task will have all the necessary privileges to perform whatever actions are required to remediate the WDA issues.

It is not necessary for the remediation task itself to examine the error code(s) returned by the ActiveX. The fact that the remediation task finds itself running on the user’s workstation implies that there were one or more issues with the WDA. It is generally only necessary for the WDA Remediation task to determine if the ESIScheduler service is installed and running. If the service is installed but not running, the remediation task can start the service. If the service is not installed, the remediation task should simply invoke the MSI to install the WDA, which should be included as part of the remediation task package.

The remediation program needs to be set up as a package to be delivered using an alternate software delivery capability (such as SCCM or Altiris), and the package and program GUIDs (or other proper identifiers) must be entered into the MIE as part of a Run Once task under the Clients (WDA) Manage Tasks menu of the MIE. To set up the remediation task, create a new task of type “Executable, no notification,” and give the task a name, such as “WDA Remediation.” The name given to the task must also be set in the agentRemeidationTask setting. The task should not be assigned a software package (leave at the default value of “-Only required for install tasks-“). Do not assign an install task to this task. The “How to run” setting should be set to “Once.” Under the “Alternate Delivery Method” settings, select the delivery method - either “APS (Altiris)” or “APS (SCCM)”, and enter the Package GUID and Program GUID, if APS (Altiris) is selected.

An error string is returned by the ActiveX, which is then stored in the assets table of the MIE, where the WDA Remediation Task, running under housekeeping, checks the string and, if necessary, schedules the WDA Remediation Package to run on that asset. The error string is a comma-delimited list of error codes that is generated from the concatenation of error codes computed from running the various checks.

The first check performed is a test of the registry to see if the SchedulerBaseURL setting is defined. If this setting is not defined, the error code ErrNoBaseURL is added to the error string.

Next, checks for processes are made.  A check is made to see if the ESIScheduler process is running. If not, the error code ErrNoSchedProcessRunning is added to the error string, and a check is made to see if the ESITray process is running, and, if not, the error code ErrNoTrayProcessRunning is added to the error code string.

Next, there are checks made to see if the ESIScheduler service is installed and is configured correctly. These checks are made using standard Windows API calls. If the service does not exist, the error code ERrNoSchedServiceExists is added to the error code. At this time, the ActiveX also determines the version number of the existing service, which is sent up to the MIE, where the WDA Remediation Housekeeping routine can use the value to determine if the scheduler service is up-to-date. The ESIScheduler service needs to be configured with Startup Type as Automatic, and its Log On setting needs to be configured as Local System account. If either setting is not correct, the ActiveX appends the string ErrSchedServiceInvalidConfig to the error string.

Next, the ActiveX checks for the existence of various components of the WDA by checking for the existence of certain EXE files. As these EXE files are checked for their existence, the version numbers of these EXE’s are discovered, and later sent up to the MIE along with any error codes discovered. The EXE’s that are looked for are ESITray.EXE, WDAConsole.EXE, ESIInstaller.EXE, and ESIScan.EXE. The corresponding error codes sent up if any of these EXE’s do not exist are ErrNoTrayEXE, ErrNoConsoleEXE, ErrNoInstallerEXE, and ErrNoScannerEXE.