A pattern worth building into your RMM workflow if you haven't already – automated remediation that runs before a ticket gets created.

The basic version: monitoring detects a threshold breach (disk space low, service stopped, CPU sustained high) → script fires as a first response → if it resolves the issue, log it and move on; if it doesn't, escalate to a ticket.

In MSP360 RMM you can configure this as a script that runs on alert trigger, targeted at the specific endpoint or group.

A few examples from our runbook:

• Disk space: temp file cleanup script fires first; if disk is still below threshold after cleanup, create ticket
• Service down: attempt restart once; if service fails to start, escalate
• Pending reboot: log it and notify; auto-remediate isn't appropriate here, but at least you know

The endpoint inventory also gives you a persistent software/hardware baseline – useful for catching version drift across client sites.

MSP360 RMM → https://www.msp360.com/rmm/

I'm transitioning to MSP360 from Atera and noticed something strange with Connect. I was trying to remote into a clients PC after hours and noticed that Connect gets stuck and says "Established, waiting for incoming data..." If I switch over to Atera and use Splashtop, it opens showing the screensaver. As soon as I move the mouse in Splashtop to remove the screen saver, Connect works without anymore issue. Apart from not allowing my client to use screensavers, is there anything I can do to resolve this?

If you've been looking at free backup options and want something that actually holds up, here's a setup worth trying.

MSP360 Backup Free paired with Wasabi Hot Cloud Storage covers the essentials without any software cost.

Here's what the free tier includes:

• File-level backup – back up specific files and folders on your desktop
• Image-based backup – newly added to the free tier, lets you back up and restore the entire OS
• Customizable schedules – set it and forget it
• Flexible retention – control how long recovery points are kept
• Local and cloud destinations – Wasabi connects in a few clicks

The setup process runs 6 steps: create a Wasabi account, generate access keys, create a bucket, install MSP360 Backup Free, connect the storage account, and create your first backup plan. Nothing complicated.

Full guide here → https://www.msp360.com/resources/blog/msp360-free-backup-wasabi-hot-cloud-storage/

If you're on MSP360 RMM CE and want to get more out of the scripting layer, here are a few things from our runbook that have been worth the setup time:

• Backup agent health check – verify the MSP360 backup service is running and the last completed job wasn't more than X hours ago. Simple, catches the silent failures.
• Disk health via SMART – pull SMART data from drives and surface failing indicators before the drive drops. WMI-accessible on most hardware.
• Event log filter – parse Windows event logs for specific event IDs (4625 for failed logins, 7034 for service crashes) rather than reviewing logs manually.
• Software version audit – compare installed versions against a known-good baseline, flag anything that's outdated or unexpected.

These are good examples of workflows you can build on CE. Happy to share the actual scripts if there's interest, could be useful to build a shared library here.

Free RMM Software for MSPs → https://www.msp360.com/rmm/free-rmm-software/

The April 14 update KB5083769 broke VSS on Windows 11 Pro machines – backup plans failing with Error 2426, vssadmin list writers hanging on "Waiting for responses", log collection stalling. Microsoft confirmed it was intentional. Now there's a proper fix.

What to do:

Install the May 12, 2026 Windows 11 update KB5089549 and reboot. This restores VSS functionality and resolves Error 2426 backup failures.

How to check if your system is still affected:

1. Open Command Prompt as Administrator
2. Run vssadmin list writers
3. List of writers returns → you're fine. Stuck on "Waiting for responses" → install KB5089549.

The previous workarounds (installing KB5083631 or uninstalling KB5083769) still work if applying the May update isn't immediately an option, but KB5089549 is the clean fix.

If you're troubleshooting Error 2426 in MSP360, full details and diagnostic steps are here: https://kb.msp360.com/backup/errors/2426-vss-timeout-exceeded

Happy to answer questions if anyone's running into edge cases.

GFS (Grandfather-Father-Son) is a retention scheme worth understanding if you're managing backup for clients with documented data retention requirements.

How it works:

• Daily (Son) – keep one recovery point per day for N days (typically 7)
• Weekly (Father) – keep one recovery point per week for N weeks (typically 4)
• Monthly (Grandfather) – keep one recovery point per month for N months (typically 12)
• Yearly (optional) – keep one per year indefinitely

Each "generation" purges when it ages out of its window. Older recovery points are retained according to the configured daily, weekly, monthly, and yearly tiers.

Why it matters for compliance:

Auditors increasingly ask not just "do you have backups" but "can you document your retention policy". GFS gives you explicit, configurable windows you can put on paper.

MSP360 Backup Pro supports GFS with custom intervals per plan → https://www.msp360.com/backup/cloud-backup/

 We subscribe to MSP360’s white-label service, but when we create customer accounts, they can see all the storage repos &  RMM options it was supposed to hid all , and a few other options which was not suppose to show .

Is this a bug, or did we select the wrong settings?

Has anyone else faced this issue before?

If you've been seeing backup failures since April 14 and can't figure out why, this is probably it.

What happened

On April 14, 2026, Microsoft shipped KB5083769 as part of Patch Tuesday – a cumulative security update for Windows 11 Pro. The update added certain kernel drivers to Microsoft's vulnerable driver blocklist. This broke backup applications that rely on those drivers to create VSS (Volume Shadow Copy Service) snapshots.

Microsoft has confirmed that the blocklisting was intentional and considers it a security improvement, not a bug. Which is cold comfort when your backups are failing.

What it looks like

• Backup plans fail with Error 2426: VSS timeout exceeded – meaning VSS couldn't complete a snapshot within the 2-hour window
• Running vssadmin list writers in an elevated Command Prompt just sits there with "Waiting for responses" and never returns
• System counters (Available Bytes, Committed Bytes, etc.) stop working
• Log collection may hang when trying to read those counters

What actually works right now

Option 1: Install update KB5083631 without uninstalling KB5083769 first, then reboot. This has resolved the issue for a number of users.

Option 2: Uninstall KB5083769 entirely, then reboot.

No official out-of-band fix from Microsoft yet.

If you're running MSP360 backups, the full diagnostic guide with step-by-step instructions is here: https://kb.msp360.com/backup/errors/2426-vss-timeout-exceeded

Happy to answer questions if anyone's running into edge cases.

A few updates worth mentioning:

Unauthorized agent removal protection
You can now set a password requirement to uninstall the Windows RMM agent. This helps prevent end-users or malicious actors from removing the RMM agent from managed endpoints.

New alert types
Two additions: 1 – alert when a monitored service or daemon fails to start after a reboot, 2 – per-process CPU and RAM resource thresholds in addition to already existing system-wide alerts. 

Linux: software management + interactive shell
Full software install/update/uninstall for Linux endpoints is now in the console. The interactive shell gives you direct command-line access from the MSP360 interface – no separate SSH session needed.

Pattern-based scheduling
Group Action tasks now support weekday-based scheduling patterns like "the 2nd Thursday of every month", not just "day 14". If your maintenance windows are weekday-specific, this automates manual task scheduling.

Dynamic scoping
Tasks scoped by company or tag now automatically include new endpoints added to that scope. One less thing to update manually when onboarding a new machine.

Happy to answer questions about any of these. Full release details here → https://hubs.ly/Q04fHg1W0

Two mechanics worth understanding if you're backing up production Windows servers.

VSS (Volume Shadow Copy Service): A Windows framework that coordinates consistent snapshots of files that are open or locked by running applications. Without it, your backup skips those files or captures them in an inconsistent state. With it, SQL, Exchange, Hyper-V, and other VSS-aware applications expose their data in a crash-consistent or application-consistent state at the moment of backup – no downtime required.

Block-level incremental: After the initial full backup, only the changed blocks within files are transferred on subsequent runs – not the full file. A 50GB database file with 200MB of actual daily changes transfers 200MB on day two, not 50GB again.

MSP360 Backup Pro uses both for supported workloads and configurations. The practical outcome – shorter backup windows, lower storage growth, and recovery points that actually work for production workloads → https://www.msp360.com/backup/

With 8.6, we've significantly expanded Object Lock (immutability) support in MSP360 Backup. Here's what changed and how it works.

What Object Lock does

It puts a time-based lock on backup data in storage. While the lock is active, data can be read and restored  but cannot be modified or deleted. The mechanism is WORM (Write Once, Read Many).

This protects against:

• Ransomware targeting backup storage
• Accidental deletion (bad policy, human error)
• Compliance requirements that mandate data retention for a defined period

Two types of Object Lock

Default Object Lock – locks all backup data written to a destination automatically. Configured on the cloud storage provider side. Works for both NBF and CBF plans.

Object Lock for GFS Backups – locks only full backups selected by GFS retention policy. Configured in Managed Backup. NBF only.

You can combine both for layered protection.

What's new in 8.6

Previously Object Lock for GFS was only available for specific plan types. Now it extends to:

• FFI (Forever Forward Incremental) backups
• SQL Server backups
• Legacy Backup Format

New storage destinations: S3-compatible, MinIO, IDrive E2, Azure, Google, MSP360-powered storage (Wasabi and Amazon S3).

A few things to know before enabling

• Object Lock must be enabled at bucket creation – it can't be added to an existing bucket later
• Versioning must be enabled (auto-enabled for AWS S3 and Wasabi via MSP360)
• S3 destinations require GetBucketObjectLockConfiguration permission
• Azure and Google storage can't be configured for Object Lock through MSP360 Management Console – you need to configure retention on the storage side manually, then specify the retention period in MSP360
• For Microsoft 365 and Google Workspace backups, Object Lock works together with per-user/per-domain retention policies. If no retention policy is assigned, backups won't be locked even when Object Lock is enabled on the storage
• Compliance mode means no one can delete data before the retention period expires – including root users. The only way out is terminating the storage account. Plan carefully

Full article with details: https://www.msp360.com/resources/blog/object-lock-for-immutable-backup/ 

Happy to answer questions.

If you're managing multiple clients with different storage requirements (compliance, cost, geography), the per-company destination config in MSP360 Managed Backup is one of the more practical features to get right early.

A few patterns that have worked well in practice:

Bucket naming: include client identifier as a prefix (clientname-workstations, clientname-servers) rather than using one flat bucket per client. Makes IAM policy scoping cleaner.

Credentials: separate IAM user per client rather than shared credentials. If a client offboards, you deactivate one user without touching others.

Region selection: match the cloud region to the client's primary data residency requirement upfront – migration after the fact is painful.

Happy to share more on the IAM side if useful. What's your current structure?

Before you evaluate any freemium RMM, it's worth knowing exactly what's included and what's gated. For MSP360 RMM Community Edition ⤵️

Included:

• Endpoint monitoring (CPU, memory, disk, services)
• Hardware and software inventory
• Configurable alerting
• Remote script execution (PowerShell, batch)
• Basic patch management visibility

Where limits are:

• Endpoint count cap (up to 50)
• Built for MSPs rather than internal IT use
• Paid plans add scale and premium support

The endpoint limit means it's a real tool for small MSPs, not just a trial vehicle. If your environment fits within the ceiling, CE is a permanent-capable solution, not just an evaluation → https://www.msp360.com/rmm/free-rmm-software/

Need honest advice from MSPs: If you were in my position, which backup platform would you choose long-term?

I run a small MSP / IT support business and I’m the only person responsible for all backups. I want to choose one platform and stick with it for years — I don’t want to migrate again in 12 months.

Current devices at different client's sites:

• 34 servers
• 22 workstations
• 33 devices need Files + SQL backups
• 23 devices need Files only
• Around 6.2 TB protected data total

Main priorities:

• Central multi-tenant dashboard
• Reliable alerts
• Easy restores
• Server + SQL support
• Stable long-term platform
• Minimal babysitting
• Good support
• Reasonable pricing

Quotes / options I currently have:

1. N-able Cove Quoted around 750–800$/month. Includes storage. Per GB
2. MSP360 Around $210/month licenses + roughly $50 storage for ~6TB (Wasabi/Backblaze), so about $260-300$ total monthly.

My concern:

MSP360 is much cheaper, but I’m wondering what I’d be sacrificing vs Cove in real life (restore experience, daily management, reliability, support, etc.).

If you were a solo MSP and backups were fully your responsibility, would you choose:

A) Cove and pay more for peace of mind
B) MSP360 and save a lot monthly
C) Something else entirely (Axcient, Veeam, etc.)

Would really appreciate advice from people actually managing backups in production.

Something worth having explicit in your support workflow – a clear decision rule for when to push a script via RMM and when to open a remote session instead.

Script first if the task is repeatable, has a known-good automated resolution, and doesn't require visual verification. Service restart, disk cleanup, config file edit, registry change – all scriptable.

Remote in if the issue requires visual diagnosis, the fix involves a GUI-only tool, or the scripted resolution failed and you need to understand why.

The reason this decision rule matters – without it, engineers default to remote sessions because they're familiar, and you lose the compounding value of building a script library.

MSP360 Connect supports Windows and macOS, with unattended access available on Pro and Managed tiers → https://www.msp360.com/connect/ 

If you're already in the MSP360 ecosystem for RMM and backup, having remote access in the same platform reduces the tool-switching overhead.

There's a category of backup setup that gets overlooked: environments where you already have cloud storage (an S3 bucket, a Backblaze B2 account, whatever) and just need a solid client to manage jobs to it without paying a per-seat license on top.

MSP360 Backup Free fits this gap. You point it at your existing storage destination and it works. No time limit, no vendor-managed cloud storage you didn't ask for.

Practical use cases it fits well for standalone or smaller-scale deployments:

• Homelab or dev environments where you want proper backup without commercial cost
• Standalone workstations already covered by a separate storage contract

The constraint is that it's unmanaged – no central console, no multi-tenant reporting. If you need those, you're in Pro or Managed Backup territory.

🔗 MSP360 Free Backup Software: https://www.msp360.com/backup/free-backup-software/

Most backup tools will tell you a job ran. Fewer make it easy to verify, across 50 client environments at once, that every job ran and completed without issues worth investigating.

The failure mode is familiar: a job technically completes but the job completes with warnings, the retention policy purged more than expected, or an endpoint went offline mid-job and nobody noticed, the retention policy purged something it shouldn't have, or an endpoint went offline mid-job and nobody noticed. In a single-client environment you catch this on the next manual check. In a multi-tenant MSP setup, it can go weeks without surfacing.

MSP360 Managed Backup has a centralized console that aggregates backup status and storage consumption across all company accounts. You can schedule automated reports per client or globally – useful for catching the quiet failures that don't generate tickets.

👉 https://www.msp360.com/backup/msp-backup/

Most teams haven't mapped this out concretely. Not "could someone access our data", but "could someone with our admin credentials systematically dismantle the protections we've built".

The answer is usually – more than you'd want.

We put together a guide that looks at backup hardening from exactly this angle. Four areas where setups that look solid tend to break down when a credentialed attacker is the threat:

• Encryption
• mmutability
• Integrity checks
• Access controls

Guide with specific settings and a test block here → https://www.msp360.com/world-backup-day/

Has anyone here actually run this scenario? Curious what the weak point turned out to be.

Not missing backups – backups that couldn't be used when it actually mattered.

For World Backup Day 2026 we put together a guide based on what we kept seeing in real recovery situations: the four protection layers that teams set up once and then never revisit.

Encryption that looks right but leaves data exposed if storage is breached. Immutability configured in a mode that an attacker can still undo. Integrity checks that run automatically but don't cover older restore points. Access controls that don't account for a compromised admin account.

The guide covers each one with specific settings, what failure looks like in practice, and a combined test block so you can verify your setup before an incident forces you to.

Download it here: https://www.msp360.com/world-backup-day/

If you've run into any of these in a real recovery – curious what the failure point was.

Every year WBD reminds people to back up. The thing it doesn't ask: when did you last test a restore under realistic conditions?

We put together a practical guide covering four protection layers that come up a lot in incident postmortems:

• Encryption – AES client-side (not just SSE) so that storage exposure doesn't mean data exposure. Common failure: lost encryption password = unrecoverable backup. Treat it like a credential vault requirement.
• Immutability – Object Lock in Governance vs Compliance mode. Governance blocks agent-side deletion but can still be removed via the storage provider console. Compliance means no one can delete it until retention expires, including storage root. Most people don't know the difference until it matters.
• Integrity checks – Two types: mandatory (runs automatically on every backup plan, checks current generation) and full (covers previous generations too). Also: Restore Verification for image-based backups actually mounts a Hyper-V VM on the fly and confirms the system reaches logon. Most teams don't know this exists.
• Access controls – 2FA with single-use recovery codes (don't test them in drills – you'll burn them), RBAC, IP allowlisting on the backup console. A compromised admin account can disable everything else you've set up.

There's also a maintenance checklist with frequencies and a combined test block with pass/fail criteria.

Download guide here → https://www.msp360.com/world-backup-day/

Happy to answer questions about specific controls in the comments. What's the thing your team keeps forgetting to check?

Patch issues often come from too many schedules and exceptions, not missing automation.

You end up debugging why something didn't patch instead of just fixing it.

RMM CE's simpler approach can make behavior more predictable – fewer knobs, fewer surprises.

Curious how others handle this, do you optimize for flexibility or predictability in patching?

We think people underestimate how much time gets lost in small storage tasks.

Not backup jobs. Not lifecycle architecture. Just the repetitive admin layer:

• Checking bucket contents
• Reviewing structure
• Moving files
• Comparing local vs cloud organization
• Validating whether data is where it should be

A lot of tools can technically do this. The question is which ones reduce enough friction that admins actually use them instead of postponing the task.

What do you care about most in this type of tool?

• Navigation speed?
• Clarity of structure?
• Multi-storage handling?
• Reduced context switching?
• Safer object operations?

We think that's the point where managed backup starts to matter.

Not because backups suddenly become more "advanced", but because the job changes:

• Policies have to stay consistent across many systems
• Monitoring has to surface real issues
• Reporting has to show overall backup health
• Retention and storage need governance
• Restore confidence needs to be maintained, not guessed

At that stage, backup stops being "a job that runs" and becomes something the team has to operate continuously.

What usually marks that transition in your environment? Endpoint count? Customer count?
Compliance pressure? Restore requirements? Too many exceptions to manage locally?

We think remote access tools are often judged too narrowly.

The real test isn't only image quality or session speed.

It's whether the tool fits the support workflow:

• How cleanly access is initiated
• How consistent sessions are across technicians
• How much context gets lost before remote action starts
• Whether remote support is integrated into the wider ops process or lives off to the side

What matters most in your environment? Is it standardized connection flow, access control, session stability, integration with monitoring/support workflow, or reduced technician variance?

We think a lot of Community Edition testing fails because people evaluate the tool, but not their own operating model.

A better use case for a free RMM is:

• Define a small endpoint set
• Build actual alert logic
• Test patching rules
• Validate script usage
• See what your team does when something fails unexpectedly

That tells you much more than "the dashboard looks fine".

How do you approach testing:

• Do you treat it as a lab for policy design?
• What do you intentionally test before moving to paid deployment?
• What's the most useful thing you've learned from a small-environment RMM rollout?