Video Screencast Help

How to Troubleshoot when the Bindview schedules fail.

Created: 20 Mar 2013 • Updated: 27 Mar 2013
Language Translations
Chaitali's picture
+8 8 Votes
Login to vote

How to Troubleshoot in scenarios where the Bindview schedules fail.

 

Scope:

This technical article is applicable to the following items which are scheduled:

- Queries in RMS (Windows, Unix, Oracle, SQL, Exchange)

- Tasklists in RMS (Windows, Unix, Oracle, SQL, Exchange)

 

Significance:

In the data collection tool for Control Compliance Suite – also popularly known by its legacy name – BindView RMS, the users can schedule queries and task lists (group of queries and/or baseline queries). Upon completion, the user can then have the reports exported to various locations or mailboxes of the intended recipients.

However, the notification feature – where the recipients and the administrator of the scheduled queries are notified in case of events when the schedules fail is not  present. 

At the later point in time, after finding that the schedules have failed to run, most of the Windows queries can be run back in time. However, most of the database and Unix servers and files queries cannot be ran back in time.

This is way it is important to review the status of the scheduled queries or task list items on a daily basis. By doing this, the administrator can re-run the missing schedule reports on the same day or when desired.

 

Process:

Location of the logs for scheduled queries or tasklists:

The logs for the RMS schedules (queries and tasklists) are in text format. The logs can be found at the following location on the machine where the BindView Information Server BVIS is installed.

By default the logs are located on C: drive at the location:

\Program Files (x86)\Symantec\RMS\data\<User Name>\ScheduleLogs

Or at the location given above on the drive on which the RMS directory resides.

 

Note that the name of each log file corresponds to the name of the schedule in RMS.

For instance the schedule job name – there will be a corresponding log file. At any given point in time, there will be only one log file for one RMS schedule for its latest run.

 

Technical details:

This log file will be created at the time the windows schedule finishes.

The way RMS schedules work is as follows:

After a user creates schedules from task list or query items or baselines, the schedules are visible in the RMS console “Schedules” folder. These schedules in turn point to the task list or query items or baselines which are selected at the time when the RMS schedule is created. For the date and time part of the schedule where the creator of the schedule specifies the date and time when the schedule should actually run, BindView leverages the Windows Scheduler.

You will notice that for each schedule which is seen in the RMS console, there is a windows schedule job which is present in the windows scheduler. You can see this by going to the BindView Information server under Control Panel, go to Schedule Tasks. This will open the Task Scheduler window. You will notice the BindView jobs inside the Task scheduler Library. You will also be able to see the status of the jobs, the time when the job last ran, the next run time of the job and whether it was a one time only schedule.

These log files are automatically overwritten by the new log files after the respective schedule re-runs.

 

At the schedule logs location\Program Files (x86)\Symantec\RMS\data\<User Name>\ScheduleLogs

You will see that at any given point in time, one schedule in RMS has a corresponding one schedule log file from its latest run.

As soon as the schedule starts its next run for any particular job, its corresponding existing file is replaced by a new, latest schedule log file.

 

A typical schedule log file for a schedule which fails to run may have any of the following error messages:

Error Message 1:

Export Grid: Excel 97-2003 export to Exchange mailbox - Failed.

Unable to decrypt password. Reason Error 0x80090005 during CE::SetEncryptionKey call to ::CryptImportKey!.  This error can occur if the BindView Information Server machine's default (unnamed) machine-wide RSA keyring has been changed since you last saved (encrypted) your export credential, or if you have moved your 'BV' database over from a different BVIS machine.  You must re-enter your export credential using User Manager.

OR

Error Message 2:

Export Grid: MS SQL Server export to ADO Data Provider; Table name=ContactsReportwithemail - Failed.

Failed to logon user (User_Name) because either the user does not exist or the password is incorrect.

OR

Error Message 3:

Export Grid: Excel 97-2003 export to Disk file; Export filename=<location> - Failed.

Error in Exporting: Unable to export to (<Location>).  Either the destination path does not exist or you don't have sufficient permissions.  Please verify your export credentials in the Export Settings tab inside User Manager.  Additional diagnostic information may be present in the following error text from the export format: Unable to open a record-set from the result-set database (User_name\Data\BVT_4852d4eg99e6859286a1c8f456f7b96b) due to error (Can't open recordset: Syntax error in ORDER BY clause.).  The query-string used was (SELECT * FROM Table1 order b).

Schedule logs will give you detailed information on why the schedule failed - whether the failure is related to export, whether it is due to failed credentials or whether it is caused due to any other factor.

 

Query schedule Vs Tasklist schedule:

The failures in the queries inside a schedule are recorded at location: Drive:\Program Files (x86)\Symantec\RMS\data\<User Name>\ScheduleLogs only if the schedule is created directly from the query.

The failures in the tasks inside a schedule are recorded at the location mentioned above. The failures of the queries inside scheduled tasks appear in teh task status monitor window of RMS after the task finishes. On failure the task list shows up ont he task monitor as a red square. You can double-click on the failed task to see the details of why the task failed and which queries the task failed on.

 

Thank you for taking time and reading through this technical article.