How to Test Restore Readiness for Microsoft 365 Data Using Synology Tools

Backup is only as useful as its ability to restore. This guide offers step-by-step instructions on how to test restore readiness for Microsoft 365 workloads (Exchange Online, SharePoint, OneDrive, and Teams) using Synology tools.

By the end of this article, you will be able to secure business-critical data and ensure that your organization can recover data reliably and quickly during incidents.

How to test restore readiness

Method 1: Validate Synology Active Backup for Microsoft 365

📌 Use Cases: Ideal for testing user-level and workload-level restores (Exchange, SharePoint, OneDrive, Teams)

📌 Prerequisites:

• Synology NAS with Active Backup for Microsoft 365 (ABM365)
• Configured and completed backup tasks
• DSM and ABM365 updated to the latest version

Steps:

1. Launch Synology Active Backup for Microsoft 365 from your NAS interface.
2. Navigate to Task List to confirm backup status:
   • Check job results and latest run time.
   • Confirm backup size and success/failure status.
3. Open the Restore Portal.
4. Sign in using either:
   • Global Admin credentials
   • Delegated restore permissions
5. Select a workload:
   • Exchange mailbox
   • OneDrive file
   • SharePoint site
   • Teams message
6. Choose a restore point and preview the item
7. Execute the restore and verify:
   • Correct item/content restored
   • Permissions and structure preserved
   • No data corruption or visibility issues

💡 Tip: Use the preview pane to validate item-level accuracy before restoring.

Method 2: Automate readiness checks via PowerShell or REST API

📌 Use Cases: This method is useful when you need to schedule health checks or proactive reporting on failed or idle backup jobs.

📌 Prerequisites:

• PowerShell 5.1+ installed (Check your PowerShell Version)
• Synology API token access
• Network access to the Synology DSM

Steps:

1. Open PowerShell as an admin.
2. Execute this command:

Connect-VB365

Get-VBOJobSession | Where-Object { $_.Status -ne “Success” } |

Format-Table Name, Status, EndTime

3. Alternatively, in Synology, execute this bash script:

curl -X POST https://yourdiskstation:5001/webapi/entry.cgi \

-d “api=SYNO.Backup.M365.Status&version=1&method=list” \

-H “X-SYNO-TOKEN: your-session-token”

4. Add scheduling or alerting via:
   • Windows Task Scheduler
   • Synology Task Scheduler
   • NinjaOne workflow automation

💡 Tip: Alert triggers include jobs that fail, don’t run within 24-48 hours, or generate incomplete objects.

Method 3: Track restore tests using Registry keys

📌 Use Cases: Great if you want to track restore frequency per device or tenant. You can also use this method as a supplement for audit compliance with internal SLAs or regulatory mandates.

📌 Prerequisites:

• Local admin access to Windows Registry
• Backup system with accessible test records
• Script runner (such as NinjaOne, PowerShell task)
• It is highly recommended that you back up your Windows Registry. Incorrect configurations can lead to system instability.

Steps:

1. Press Win + R, type regedit, and click Enter.
2. Go to: HKEY_LOCAL_MACHINE\SOFTWARE\Org\BackupRestoreValidation
3. Create the following values:
   • LastRestoreTestDate (String) = “2025-07-01T18:00:00Z“
   • ToolUsed (String) = “Synology ABM365“
4. Use automation (like via NinjaOne or PowerShell) to:
   • Read keys and check for overdue tests.
   • Update values when tests are performed.
   • Trigger alerts if testing is overdue.

💡 Tip: Export registry entries to a central log server or compliance dashboard.

Method 4: Enforce endpoint backup policies via Group Policy (for Synology clients)

📌 Use Cases: This method is useful to prevent accidental file deletions, enforce volume shadow copy (VSS) usage, or protect endpoints used in hybrid restore scenarios.

📌 Prerequisites:

• Windows domain environment with Group Policy access
• Synology agent installed (if backing up local files too)

Steps:

1. Press Win + R, type gpedit.msc, and click Enter.
2. Go to: Computer Configuration > Administrative Templates > System > Windows File Protection
3. Enable the following values:
   • Do not allow users to remove critical system files
   • Require Volume Shadow Copy for all local backups
4. Apply GPO to relevant organizational units (OUs).
5. Use gpresult or audit logs to verify GPO application.

💡 Note: Even if you’re not backing up endpoint files to Synology, these settings prevent critical data loss during accidental overwrite or ransomware recovery.

Method 5: Verify backup file accessibility via CMD or CLI

📌 Use Cases: This method ensures your backups are not just “logged” but physically accessible and usable. This method allows you to quickly check the presence and size of the backup file.

📌 Prerequisites:

• File system access to backup directories
• Network or mount access (SMB, iSCSI) for Synology shares

Steps:

A. For Synology Backup shares (via SMB)

1. Execute this command:

net use Z: \\synology\m365backup

dir Z:\backups\user01

B. Automate scripts to:

• Check file timestamps and sizes.
• Confirm the availability of recent snapshots.
• Log or alert if missing or undersized.

💡 Tip: Watch out for incomplete .vbcat files or missing OneDrive/Teams folders, which could signal failed backups or expired credentials.

Additional considerations when you test backup readiness

Restore scope

• Always test both full and granular restores (e.g., an entire mailbox vs. a single email).
• Simulate real-world incidents: corrupted SharePoint folder, deleted Teams chat, etc.

Credential expiration

• OAuth and Graph API tokens typically expire every 1–2 years.
• Schedule credential renewals and API permission audits every 12 months.

Licensing

• Synology Active Backup limits access to certain features without license activation.
• Backup jobs may run, but restore rights can silently lapse. Make sure to validate them often.

Multi-tenant management (for MSPs)

• Track restore tests per client using:
  • Metadata tagging (e.g., in NinjaOne or restore job notes)
  • Timestamp logging (via Registry)
  • Tenant-scoped dashboards for reporting

💡 Tip: While testing once is helpful, it is always better to automate restore readiness to minimize risks. This is also a crucial consideration in any data backup and recovery plan.

⚠️ Things to look out for

Troubleshooting common restore issues

Access denied during Synology Restore

This can happen from misconfigured Graph API scopes or expired OAuth tokens. To resolve this, reauthorize the Microsoft 365 connector from within DSM.

Always ensure the application token has the necessary delegated permissions (such as Mail.ReadWrite, Sites.ReadWrite.All, etc.) and hasn’t expired.

Synology Restore portal won’t load

This is often a sign of DSM version compatibility issues or improper SSL/TLS settings. To resolve this, ensure the Synology DiskStation Manager (DSM) is updated to a version compatible with your current Microsoft 365 environment.

Additionally, confirm that HTTPS binding is properly configured for secure access. In environments where HTTP access is disabled or redirected incorrectly, the portal may fail to load entirely.

Missing items in the restore selection

This may indicate that the data was never indexed properly or that a backup job skipped key objects due to misconfiguration. This can happen when users are newly licensed, moved between groups, or excluded via filtering.

To resolve this, rerun the backup manually and check the logs for any skipped users or error messages. Also, confirm that indexing is enabled for all workloads.

Restore times out or freezes

This usually indicates performance issues with the backup repository or excessive network latency. Try isolating the restore operation to a faster disk or temporarily moving the job to a high-availability volume. For Synology, ensure your NICs are properly bonded or assigned and that your iSCSI or SMB connections are stable.

How NinjaOne can help unify restore readiness across tenants

• PowerShell script deployment: Easily push scripts to validate Synology job status, test for failed backups, and report on restore history across endpoints and tenants.
• Registry auditing: NinjaOne can scan and report on custom registry keys (e.g., LastRestoreTestDate) to confirm whether local admins or agents have completed restore tests within defined intervals.
• Custom dashboards: NinjaOne gives you centralized visibility into backup job health, the last successful restore per tenant or device, and gaps in testing frequency or object coverage.
• Cross-tenant alerting: The platform automatically triggers alerts when restore validations are overdue, backups fail silently, or when OAuth tokens or licenses are nearing expiration.
• Workflow automation: Link restore readiness checks to tickets, logs, or alerts. Integrate restore validation events into compliance reporting flows or SLA documentation.

Test restore readiness with the right tools

To state the obvious, backups are useless if they cannot be restored. That’s why testing restore readiness isn’t optional; it’s essential. This guide gave you the tools, techniques, and automation pathways to ensure that your Microsoft 365 is not just backed up, it’s recoverable.

Related topics:

• 8 Tips on Keeping Your Data Backups Secure
• Rethinking Backup and Redefining Resilience
• Backup Configuration
• Complete Guide to Data Backup & Recovery
• Top Veeam Competitors & Alternatives in 2025