Kaseya Community

Has anyone used the Symantec Backup Exec Management Plug-in for Kaseya?

  • Hi Michael,

    Sorry for the delayed response. Currently the Backup Exec plug-in does NOT gather the running state (i.e. the intermediate states such as Running, Queued etc.) of the backup jobs. It gathers the state only after job is completed (i.e. Final/definite states such as Succeeded, Failed, Succeeded with Exceptions, Cancelled, Missed etc.).

    It seems that you have created a custom report in SQL reporting server. But, I do not understand why you should see empty box in your SQL report. I expect that the report should still show the jobs that reached the final/definite states at the time your report is prepared (of course that depends on certain conditions/SQL query that is part of SQL report/RDL). Let me ask some more questions:

    1. Can you share more details about the conditions that you may have used in your SQL report? For example, is your report specifically designed to look for jobs that have intermediate states ONLY? Or is your report having a condition that the job end time must be later than 'x' date/time?

    2. Is that possible to schedule the 'report + daily mail' task to kick-off after a reasonable minutes/hours off the expected job end time? For example, if the jobs are scheduled to run nightly (say between 12am to 3am or so), could you schedule the 'report + daily mail' task to kick-off at 6am or so? I assume that the jobs would complete before 6am unless there is any serious issues (like BE service/job hung etc).

    Regards,
    Ramesh Bupathy
    Symantec Corporation

  • @Michael: Could you provide more details? That would help us to either find a reolution to your issue or evaluate whether this could be considered for a future release as an enhancement feature.

    Regards,
    Ramesh Bupathy
    Symantec Corporation

  • Hello Ramesh,


    I am sorry, due to my holiday I have not been able to reply yet.
     
    We have set up a SQL Reporting Server to create reports based on the "Gathered" information that the Backup Exec module for Kaseya inserts into Kaseya SQL DB.
    Based on this information, we provide a standard reporting by mail from this SQL reporting server which gives an idea of which backup has failed, which backup has succeeded and the other statuses.

    One thing we miss, is that backups that are currently running. The customer reads this information as his backup did not run, and perhaps will not run either.

    As far as I know with BEMCMD it actually is possible to extract the information, even if a backup is in the "running" state.(in process)

     

    Enclosed you will find an example.
    The customer would think 2 of his backups are not going to run, or have not run.


    I hope you do understand what I mean, and that this information is detailed enough?

  • @Michael:

    I can clearly understand your requirement after viewing the screenshot you had posted.

    As you said, fetching these intermediate states (such as 'Running') would be possible. These states will change very often hence we did not gather them. Let us share this requirement with our product team. Thanks Michael for taking time to share these details.

    Have you tried the below workaround? Can you share your comment on the same?

    Is that possible to schedule the 'report' task to run after a reasonable time after the expected job end time? For example, I assume that the backup jobs are scheduled to run nightly (say between 12am to 3am or so) and you have to send the report first thing in the morning (say by 7am) everyday. If so, could you schedule the 'report' task (on SQL Reporting Server) to run at 7am? The assumption is that the backup jobs would complete before 7amunless otherwise there is any serious issue (like BE service/job hung etc) and job did not complete until 7am. Importantly, ensure that BE plug-in's data gathering agent procedures also complete just before 7am (i.e. before report task's scheduled time).

    Regards,
    Ramesh Bupathy
    Symantec Corporation

  • Hello Ramesh,

    Thank you for your understanding.

    Your proposed workaround is actually the one we are using at this very moment.

    However, we are active for a lot of companies which, most of the times, do not own the latest hardware hence the long running backups (some actually are running their backup-from-disk-to-tape during the day to have a daily full backup.

    Also, we are running backups during the day on a fully new environment, which actually has the possibility to have backups run during the day.

    But... this is an other story ofcourse.

    At the current schedule,

    we gather the Backup Exec Summaries at 06:45AM every morning;

    we send the data from Kaseya SQL DB at 06:50AM every morning;

    we create the SQL Reporting reports at 07:00AM and intend to send this out to the customers immediately.

    This is quite tight, but it works perfectly. We really hope to have the running backups in the report, as the current overview creates more questions from the customers compared to the result we would like to have with it.

    Regards,

    Michael

  • Thanks Michael for confirming the workaround and also for sharing the difficulties around the workaround. Let me discuss this requirement with our product team. I will try my best to keep this thread updated if any information available on this.

    Regards,

    Ramesh Bupathy

    Symantec Corporation

     

     

  • Hi Ramesh,

    we do need the Status "running" in the Job History as well. We check daily all Backup Jobs from many customers and during day we gather information once per hour. We also think that is an important feature request to have the full information about the status of all jobs on a point of time.

    Please do your best ;-)

    Regards,

    Markus

  • @Markus Schuller: Thanks for letting us know this. We really appreciate it! We will do our best!!

    Regards,

    Ramesh Bupathy

    Symantec Corporation

  • I am getting this error message under the plugin exception and the agent is not being installed.

    1603 - Regular Install Mode - Agent installation failed. Run command 'net helpmsg 1603' for more information about this error.

    Any ideas? we are running k6.2 and the plugin is version 1.1. This happens on multiple endpoints.

  • I am receiving KaseyaAgent version not supported. Please advise, we are on 6.2

  • @rattrap:

    Please find more comments on this thread: http://community.kaseya.com/xsp/f/114/p/14840/75407.aspx#75407 

    Regards,

    Ramesh Bupathy | Symantec Corporation

  • @Symantec_Corp

    Hello Ramesh,

    Is there more news on the Kaseya Symantec Backup Exec Module?

    I am hoping for an update on the development if there is any.. :)

    Regards,

    Michael

  • Hi Michael,

    I was wondering if you would be able to share the SQL query you are using to generate your reports?  I am trying to create a report very similar to what you are using.

    Thanks,

    Eric

  • Hi Eric,

    Sure thing. We are however syncing the BackupExec Table to an separate SQL server.

    On that server we are running queries.

    I may need to clarify some stuff first, in order for you to understand how we have things set up.

    Took us some time to finish, but I am very satisfied as it is right now.

    Through a Backup Exec Standardisation project, we have based every backup on every customer on a policy. This does not work in BE 2012, but the main thing is that the Job names are in a standard way.

    Every morning we truncate the table on the local SQL server, and run a full import from the KServer DB.

    Using Kaseya VSA we are monitoring Eventlogs, so when BE has an error on a Job, we get an alert and are investigating the issue.

    This is because everything is automated through reports, and we have minimal time needed for backup checking.

    This all saves us around 1 hour work for 2 supporters every day!!

    -------

    insert into Table

    (JobName

    ,DeviceName

    ,FinalJobStatus

    ,StartTime

    ,machine_name

    ,Kb)

    (select

    JobName

    ,DeviceName

    ,FinalJobStatus

    ,StartTime

    ,Jobname as machine_name

    ,ByteCount as Kb

    from [KServer DB IP-Table]

    -------

    Then, we are extracting the Machine names from the Job name.

    as extra info, our jobnames are standardised using the following:

    01*SERVER-CUSTOMER-Daily Differential Backup

    first 2 digits stand for the backup numer, in case more than one backup is available.

    after the third digit, the servername

    then after the dash, the customer name

    and followed by the type of backup.

    -------

    UPDATE Table

    SET machine_name = right(machine_name, len(machine_name) -3)

    UPDATE Table

    SET machine_name = SUBSTRING(machine_name, 1, CHARINDEX('-', machine_name) - 1)  WHERE CHARINDEX('-', machine_name) > 0

    -------

    Using the other attributes which the BE module imports from the BE Servers, we translate Jobstatus to a Character:

    -------

    Use DB

    UPDATE Table

    set status = case

    WHEN finaljobstatus = 1 THEN 'C'

    WHEN finaljobstatus = 3 THEN 'E'

    WHEN finaljobstatus = 5 THEN 'H'

    WHEN finaljobstatus = 6 THEN 'F'

    WHEN finaljobstatus = 9 THEN 'M'

    WHEN finaljobstatus = 10 THEN 'M'

    WHEN finaljobstatus = 16 THEN 'R'

    WHEN finaljobstatus = 19 THEN 'G'

     ELSE NULL

       END

    -------

    Use DB

    UPDATE Table

    set customer = case

    WHEN jobname like '%111%' THEN 'Customer 1'

    WHEN jobname like '%222%' THEN 'Customer 2'

    else null

    end

    -------

    Then, I have thought of some way to work around the problem with backup jobs which start after 00:00, but should be visible on the report as running on the batch for the same job.

    Explaining: the jobs for tuesday evening start from 18:00PM, but may also run through the night, and eventually some backups also start on wednesday at for example 02:00AM. This would result in a weird looking report, showing some backups started on wednesday morning, as well as wednesday evening, double backups may confuse the customers.

    Eventually we translate bytecount to GB's

    -------

    update Table

    set Gb = (select CONVERT(DECIMAL(18,2), Kb/1073741824.0))

    -------

    Through SQL Reporting we have made a Report which contains the overview per day, resets on monday, so that the new backup overview starts on monday evening.

    It is not a Query which I can share, but I can perhaps share a .rdl file (SQL Reporting Report).



    Changed table name
    [edited by: Michael at 12:44 AM (GMT -7) on Jun 25, 2013]