Have you verified that the file, "C:\Program Files\Kaseya\Agent\BackupExecPlugin\BEMSE_Agent.exe", exists? Have you tried uninstalling and reinstalling the plugin?
This procedure runs fine - Install - Install Agent 1.0 for Backup Exec Plug-In
Audit runs good
"Gather Backup Exec Summary Data" - fails on step 6. I checked the server and I see "C:\Program Files\Kaseya\Agent\BackupExecPlugin", it has one file in it " LastReported.ini"
I uninstalled the plug in and reinstalled
@GConnors: It seems the procedure "Install Agent 1.0 for Backup Exec Plug-in" might have had failed. The file "C:\Program Files\Kaseya\Agent\BackupExecPlugin\BEMSE_Agent.exe" is expected to exist alongwith lot of other files.
1. Can you let me know whether the add/remove programs window (on BE media server that is in question) shows the "Agent 1.0 for Backup Exec Management Plug-in for Kaseya" as a installed software?
2. Please share the log files from the "%AllUsersProfile%\Application Data\Symantec\Backup Exec Management Plug-in for Kaseya\Logs" folder from BE media server in question. One of the log in this folder might have info about the cause of the issue.
3. In Kaseya console, browse to "Symantec Backup Exec" module/tab, go to "Plug-in Exceptions" UI. Do you see any error listed pertaining to the media server machine in question?
Regards,Ramesh BupathySymantec Corporation
any update? I was at the Kaseya Connect conference 2012 and they had version 1.4 I believe. I'm at 1.0, is there a number I can call for support?
I noticed your post in another thread community.kaseya.com/.../73375.aspx and assumed that you are facing the same issue.
If you are facing the same issue as discussed in the thread 73375, here is the update:
The fix has been included in v1.1 plug-in release which will be available for customers in couple of weeks as part of First Availability (FA) program. You have to sign up for getting the v1.1 plug-in early through FA program. If you wish to get the issue addressed by upgrading your current v1.0 to v1.1 plug-in, let me know. We can have you signed up in the FA program by contacting you.
If you need Symantec technical support contact information, please visit www.symantec.com/.../techsupp_contact_phone.jsp
Is it possible to read out the currently running jobs?
We rely on the module to create SQL Reporting for Customer Reporting. Currently this outputs only the finished or failed backups...
@Michael: The Backup Exec plug-in v1.0 (and also v1.1 that will be released in next few days) do not gather the status information of currently running jobs (like 'queued', 'assigned', 'running' etc.) from the Backup Exec media servers. It can report only on job history (i.e. jobs which have status such as 'succeeded', 'failed', 'missed', 'cancelled', 'succeeded with exceptions' etc.)
Please help me to understand your requirement more in detail so that we can see whether this capability can be considered in a future release. If the SQL report contains the currently running jobs along with its status as well then the status will be quickly out of date (within next few minutes or hours) as the status will change once the job is finished. Can you let me know who will be the consumer of this report and what would be the purpose of this report?
We use the SQL data for both customer reporting and IT management purpose.
Via SQL Reporting we distribute a daily mail containing the current status of backups, including failed, exceptions, cancelled etcetera.
When the report is made as the Kaseya Module works at this very moment, we get an empty box, which looks as the backup has not run at all, while it is running at the moment.
I know that the gathering of the backups, gathers all the data, including the running state of backups. This is why I was hoping there could be an extra export field which contains the Running backups.
@Michael you could use BEMCMD to query if jobs are running. You'd have to incorporate this into a procedure then pickup the results using Kaseya but it could be done.
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).
@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.
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?
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).
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.
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.
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 ;-)
@Markus Schuller: Thanks for letting us know this. We really appreciate it! We will do our best!!
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
Please find more comments on this thread: http://community.kaseya.com/xsp/f/114/p/14840/75407.aspx#75407
Ramesh Bupathy | Symantec Corporation
Is there more news on the Kaseya Symantec Backup Exec Module?
I am hoping for an update on the development if there is any.. :)
Copyright © 2012 Kaseya International Limited. All rights reserved. Kaseya and the Kaseya k-bug logo are among the trademarks or registered trademarks owned by or licensed to Kaseya International Limited. All other brand and product names are or may be trademarks of, and are used to identify products or services of, their respective owners.