Share via

Monitoring on MABS alerts in Window server

Rajneesh Saraswat 0 Reputation points
2026-05-24T08:28:01.4+00:00

Hi Team,

I created anew MABS Environment for MABS and i want to implement the monitoring form OpsRamp.

So i need help in getting the different parameters like Event ID , Windows services to monitor which will send alarms when anything going to be faulty or an issue in backup.

Azure Backup
Azure Backup

An Azure backup service that provides built-in management at scale.

3 answers

Sort by: Most helpful
Most helpful Newest Oldest
  1. Suchitra Suregaunkar 14,435 Reputation points Microsoft External Staff Moderator
    2026-05-25T12:05:36.7233333+00:00

    Hello Rajneesh Saraswat Setting up external monitoring for MABS is a practical approach. While MABS doesn't publish a standalone list of "Event IDs to monitor," Microsoft does provide documented guidance on the event logs, services, and log paths you can leverage with OpsRamp.

    Windows Event Logs to Ingest in OpsRamp:

    MABS writes operational data to specific event logs that OpsRamp can pick up:

    • MABS Alerts event log — This is the primary log for backup job alerts. To enable it, open the MABS Administrator Console → Monitoring → Action → Options → Alert Publishing → Enable "Publish Active Alerts". Once enabled, all active alerts requiring user action are written to this event log on the MABS server.
    • CloudBackup → Operational — Located under Event Viewer → Applications and Services Logs → CloudBackup → Operational. This captures Azure (cloud) backup operation events and errors, which is useful if you're offloading backups to a Recovery Services vault.

    Application log — General DPM/MABS events are also written to the standard Windows Application event log, so it's worth monitoring for Source: DPM or Source: MABS entries there as well.

    In OpsRamp, configure event-based alert policies filtering on Error and Warning severity levels from these log sources.

    Windows Services to Monitor:

    As per the official MABS troubleshooting guide, these services are critical for MABS to function. If any of them stop, backup operations will fail , so monitor their running state in OpsRamp:

    Service Why It Matters
    Microsoft Azure Recovery Services (cbengine/obengine) Handles cloud backup to Azure Recovery Services Vault. The troubleshooting doc explicitly states: "Ensure Microsoft Azure Recovery Services is running (in Service console). If necessary, restart and retry the operation."
    -------- --------
    Microsoft Azure Recovery Services (cbengine/obengine) Handles cloud backup to Azure Recovery Services Vault. The troubleshooting doc explicitly states: "Ensure Microsoft Azure Recovery Services is running (in Service console). If necessary, restart and retry the operation."
    SQL Server Agent Runs scheduled SQL jobs for MABS. The doc states: "Ensure that the SQL Agent service is running and set to automatic in the MABS server."
    DPMRA (DPM Protection Agent) Runs on each protected server and handles data transfer to the MABS server. Located at Program Files\Microsoft Azure Backup Server\DPM\DPM\bin\dpmra.exe.
    MSDPM (DPM Service) The core MABS/DPM engine on the MABS server itself.
    SQL Server instance (MSSQLSERVER or named instance) Hosts the DPMDB database — without it, MABS cannot function.

    Log File Paths for File-Based Monitoring:

    If OpsRamp supports file-based log ingestion, these are the documented log locations:

    • MABS activity logs: %ProgramFiles%\Microsoft Azure Backup Server\DPM\DPM\Temp\ (look for *.errlog files, e.g., MSDPMCurr.errlog)
    • MARS Agent logs: C:\Program Files\Microsoft Azure Backup Server\DPM\MARS\Microsoft Azure Recovery Services Agent\Temp\ (look for CBEngineCurr.errlog)

    You can locate the exact install path using: 

    Reg query "HKLM\Software\Microsoft\Microsoft Data Protection Manager\Setup" /v Installpath

    The recommended way to monitor MABS at scale is through System Center Operations Manager (SCOM) using the DPM Management Packs. These packs provide centralized health monitoring, SLA-based alerting, and performance trending for DPM/MABS servers. If your environment has SCOM and it integrates with OpsRamp, that would be the most comprehensive approach.

    Reference:

    Hope this helps! If you have follow-up questions about configuring any specific alert in OpsRamp, feel free to ask.

    Thanks,
    Suchitra.

    Was this answer helpful?

    0 comments
  2. kagiyama yutaka 3,605 Reputation points
    2026-05-24T08:40:07.4933333+00:00

    I think the item for monitoring is the “MABS Alerts” Event IDs 33222 and 33223 and the state of the DPMRA service.

    Was this answer helpful?

    0 comments

  3. AI answer

    2026-05-24T08:28:19.6766667+00:00

    For Microsoft Azure Backup Server (MABS), monitoring is typically done through:

    1. Built‑in MABS alerts (via email/SMTP)
    2. Operations Manager (SCOM) alerts
    3. Windows Event Logs (which OpsRamp can ingest)
    4. Windows services and performance counters

    From the provided information, the following monitoring points are available.

    1. Use MABS alerting and email notifications
    • In the MABS Administrator Console:
      1. Go to Monitoring > Action > Options.
      2. Configure SMTP Server: server name, port, and a valid “From” email address.
      3. Under Authenticated SMTP server, configure the domain account that matches the “From” address.
      4. Use Send Test E-mail to verify.
      5. Then go to Options > Notifications and select:
        • Critical, warning, informational alerts
        • Status of instantiated recoveries
      6. Add recipient addresses under Recipients.
    • With MABS V4 UR1/UR1 Refresh, Windows and Basic SMTP authentication are supported for email reports and alerts, so any SMTP provider that supports Basic Auth can be used.

    OpsRamp can then monitor the mailbox or the SMTP relay, or you can use these alerts as a reference to correlate with event logs.

    1. Publish alerts to Operations Manager (SCOM) and consume via OpsRamp If SCOM is in place and integrated with OpsRamp, use SCOM as the primary source of health/alert data for MABS:
    • In the MABS Administrator Console:
      1. Go to Monitoring > Action > Options > Alert Publishing.
      2. Enable Publish Active Alerts.
    • Once enabled:
      • All existing MABS alerts that require user action are written to the MABS Alerts event log on the MABS server.
      • The Operations Manager agent installed on the MABS server forwards these alerts to SCOM.
    • OpsRamp can then ingest SCOM alerts (including severity, source, and description) instead of directly parsing all MABS logs.
    1. Windows services and performance monitoring For core MABS health, monitor the Windows services and their performance using a “Windows Service”–type template (in SCOM or equivalent in OpsRamp):
    • The Windows Service template discovers and monitors a given Windows service across servers and can:
      • Monitor running state of the service.
      • Monitor CPU utilization of the service.
      • Monitor memory usage of the service.
      • Collect events for service state changes.
    • Performance thresholds available in the template:
      • Generate alert if CPU usage exceeds a specified percentage.
      • Generate alert if memory usage exceeds a specified MB threshold.
      • Configure Number of samples (e.g., 2–3) to avoid noise.
      • Configure Sample Interval (e.g., 5–15 minutes) to balance responsiveness and overhead.
    • The template also creates a class that can be targeted by additional monitors/rules, such as:
      • Event-based monitors for specific Windows events raised by MABS or related services.

    In OpsRamp, mirror this by:

    • Monitoring the key MABS and SQL services (for example, the MABS service and SQL instance hosting DPMDB) for:
      • Service stopped / not running
      • High CPU
      • High memory
    • Using event-based policies to trigger alerts when MABS Alerts or related event logs show error/warning entries.
    1. Event logs and alert content
    • When Alert Publishing is enabled, MABS writes actionable alerts to the MABS Alerts event log.
    • SCOM’s Windows Service template can be extended to:
      • Target the MABS service class and create rules/monitors that look for specific event IDs or text in the MABS Alerts log.
    • OpsRamp can ingest the same event log and trigger alerts based on:
      • Log source: MABS Alerts
      • Severity: Error/Warning
      • Event ID or message pattern (for example, failures in initial replication, synchronization, or recovery jobs).
    1. Backup strategy and database protection monitoring
    • The MABS database (DPMDB) is critical; its backup status should be monitored:
      • If backing up DPMDB to Azure from MABS, monitor the success/failure of those backup jobs via MABS alerts and MABS Alerts event log.
      • If backing up via other methods (storage pool, SQL backups), monitor the corresponding SQL backup jobs and their events.
    • In OpsRamp, ensure:
      • Alerts are raised when DPMDB backup jobs fail or are skipped.
      • Capacity and performance of the storage pool and Azure backups are monitored (via MABS alerts and underlying infrastructure metrics).
    1. SharePoint farm protection monitoring (if applicable) If MABS is protecting SharePoint farms (on-prem or Azure Stack):
    • MABS monitors initial synchronization and subsequent backups.
    • Use the same mechanisms:
      • Email notifications for critical/warning/informational alerts and recovery status.
      • Alert Publishing to MABS Alerts event log, then SCOM/OpsRamp.
    • Configure OpsRamp to:
      • Watch for SharePoint-related backup failures in MABS Alerts.
      • Raise incidents when initial replication or scheduled backups fail or are delayed.

    Summary of key items for OpsRamp

    • Windows services:
      • Monitor MABS core services and SQL services (running state, CPU, memory).
    • Event logs:
      • MABS Alerts event log (after enabling Alert Publishing) for backup/restore/protection group issues.
      • Optionally, SQL Server and System/Application logs for underlying platform issues.
    • Email/SMTP:
      • Configure MABS email notifications; optionally integrate with OpsRamp via email-based alert ingestion.
    • SCOM integration (if present):
      • Use SCOM’s Windows Service template and MABS management pack (if deployed) and let OpsRamp consume SCOM alerts.

    References:

    AI-generated content may be incorrect. Read our transparency notes for more information.

    Was this answer helpful?

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.