Turn product knowledge into field performance.

You are not going to rip out Intune and I would not propose it. The question is where your operations still fall back to scripts, spreadsheets, or a second console — third-party patching, cross-platform servers, remote support with real session context, and one asset record that agrees with reality. Those gaps are where this earns its keep, alongside Intune rather than instead of it.

Probably it does, on the feature list. Feature grids all say yes. What I would rather compare is what it costs you to answer three questions: why is this machine configured this way, when was this patch actually applied everywhere, and can you prove the last restore worked. If your answers are fast, you have a good platform and I will say so.

Then do not migrate it. The question is not which PSA wins, it is where device counts, ticket time, and contract terms reconcile today, and who does that reconciliation by hand. That seam is where the hours and the margin leak, and it is fixable without touching your PSA.

SCCM is extremely capable inside the domain. The two questions I would ask are what happens to a device that has not touched your network in three weeks, and what your macOS and Linux story looks like. Those are usually the edges where the model strains, not the core.

Sometimes they are right. Tell me exactly what they said and I will tell you whether it is true, partly true, or out of date — and if it is true I will tell you what we do instead so you can judge whether that matters for your environment.

The agent is outbound-only over TCP 443 with no inbound port and no listening service on the endpoint. That is usually a narrower ask than the VPN or jump-host model already in place. One thing I will disclose up front: where a third-party vendor only publishes update payloads over anonymous FTP or HTTP, the agent may fall back to those after repeated HTTPS attempts fail.

Fair. So the question is what comes off. Count what is on a typical laptop today — RMM, AV, backup, monitoring, inventory. If this is purely additive I understand the resistance. If it removes two or three, that is a different conversation and it is one worth having with actual numbers.

Depends entirely on the scope. Monitoring is read-only. Control opens remote sessions. Management can run scripts on endpoints — which is arbitrary code execution across the estate, so a Management-scoped secret should be handled as a domain-admin-equivalent credential. Almost nothing legitimately needs Management and Control together.

They are not published per endpoint, and I am not going to invent one. Integrators consistently report throttling that requires batching and caching. What I would propose is measuring it in your tenant during the POC and writing down what we observe, so you design against evidence instead of a marketing figure.

That needs a precise answer rather than a confident one, so let me get you the current instance and data-handling documentation for your region rather than paraphrasing it. What I can tell you now is that backup uses region-specific storage, so the region your tenant sits in is a real architectural decision, not a detail.

It does, and that is a fair thing to interrogate. Background Mode runs under the Windows SYSTEM account on a separate minimal desktop, which is what lets maintenance happen without touching the user's session. The controls that matter are who can start a session, what is logged, and role scoping — that is where I would focus the review rather than on the account itself.

The right frame is which functions are control-plane dependent and which are not. Anything requiring the console — new policy assignment, remote sessions, reporting — needs the service. Locally scheduled behaviour continues. What I would not do is give you a hand-waved answer, so let me get you the documented behaviour and their status history rather than improvising.

It is genuinely less compositional, and I would not pretend otherwise. What you get back is determinism — one effective object per device, so 'why is this machine like this' is one click instead of an afternoon. Variation is authored through parent-and-child policies at design time rather than resolved at evaluation time.

No, and I would not sell it to you as one. What this does is posture and remediation — is protection present, healthy, current, is encryption actually on, is there more than one AV product fighting on the same box. Your EDR stays where it is.

Depends on the controller, and this is worth checking before we go further. RAID Health covers Dell through PERCCLI and HP through the HPSSACLI utility, driven by Event ID. HP Mega RAID is explicitly excluded. What are you running?

Yes, through Apple Business Manager or Apple School Manager, and Android Enterprise on the other side. The important part: if you are not enrolled in those programmes today, that is a prerequisite project and it is independent of which MDM you choose. No MDM can substitute for it.

For enrolment, almost certainly — the floors are iOS 10 and later and all iPadOS versions. The subtlety is Declarative Device Management, which needs iOS or iPadOS 17 or macOS 14. Below that, devices still enrol and are still managed, they just fall back to standard MDM behaviour rather than the newer autonomous model.

Some of it, and it is worth testing rather than assuming. Background Mode is a minimal desktop under SYSTEM — file browser, disk manager, registry editor, event viewer, service manager, PowerShell and CMD all run there. Anything depending on the signed-in user's profile, profile-bound tokens, or GPU may not launch.

Yes, but through a different mechanism — agentless NMS policies over SNMP and ICMP, since a switch cannot run an agent. It is a genuinely separate policy type with its own condition set, not the endpoint agent pointed at network gear.

I am not going to quote you a figure from memory on something with a compliance requirement behind it. The public documentation index does not state exact retention periods or revision counts, so let me confirm it in the tenant and come back to you in writing today.

Then compare the whole cost, not the line item. Count the tools it replaces, the hours spent on manual reporting and reconciliation, and the licences you stop paying for. If it is still more expensive on that basis, it is more expensive, and I will tell you that.

It is lock-in, and consolidation always is — that is the trade you are being asked to make. The mitigations that actually matter are API access to your own data, documented export paths, and keeping your system of record clear. Let us write down the exit path during architecture review rather than discovering it later.

Then this is not a this-quarter conversation and I will not pretend it is. What is useful now is knowing what would have to be true at renewal for you to look seriously. If we build toward that, you evaluate with evidence instead of under time pressure.

Starting narrow is a sound way to buy. The one thing to be clear-eyed about is that most of the value comes from shared device context — patch state next to asset record next to ticket. A single module works, it just will not demonstrate the thing that makes the platform different.

Ungoverned automation is dangerous and you are right to resist it. What makes it safe is boundaries: a bounded reversible action, a ring it runs in first, a maintenance window, evidence of what it did, and a defined stop condition. Automate the known and escalate the ambiguous — the goal is not to automate everything.

Then you are choosing speed over soak, and that is a legitimate choice — it just needs to be explicit. A real ring model with a soak between each does not fit in 72 hours. You can have fast, or you can have staged validation. Pretending you have both is how a bad patch reaches everyone in a day.

That is the most common reason good projects do not happen, and it is real. The counter is to scope the first phase to one thing that gives time back rather than a full cutover — usually reporting or patch evidence, because those are pure manual hours today. If phase one does not return more hours than it costs, we should not do phase two.

Then let us write the submission together rather than hoping. What that board wants is blast radius, rollback, the network posture, the pilot population, and evidence from the pilot. If we can produce all five from a controlled ring, you are submitting a documented change rather than a proposal.

It is a fair worry and often the correct reason to say no. The honest test is whether the first phase removes more manual work than it creates in administration. If it does not, do not buy it. That is a measurable question and we should answer it before you commit, not after.

The heritage is real, and I would rather address it than dodge it. The relevant question is whether the operating requirements hold: multi-level delegation, scoped administration, change windows, audit evidence, integration, and reporting. The same organization, location, and device hierarchy that separates client estates is what enforces delegation in a large enterprise.

When did you look, and what was missing? That matters because ITAM and PSA only reached general availability in 12.0. If your evaluation predates that, you evaluated a genuinely different product — and if the gap you found is still a gap, I would rather tell you that than waste your time.

I can send one, and it will tell you almost nothing — every vendor's grid says yes to every row. What actually separates platforms is behaviour at your scale: what happens when settings disagree, what an alert looks like at three in the morning, how long it takes to prove something to an auditor. Give me twenty minutes at a whiteboard and you will score the matrix better afterwards.

Keep it. Detection is not the problem you have. The question is what happens after the report — who remediates, on what schedule, and how you prove the finding actually closed. That gap between detection and closure is where the risk lives, and it is usually owned by a different team than the scanner.

Microsoft protects the service and its availability. What it does not do is give you granular, customer-controlled recovery of something deleted months ago, or a departed user's mailbox after the retention window closed. Replication is not recovery, and retention is not the same as restore.

You do not, from a demo, and you are right to distrust one. The only real answer is a POC scoped to your environment with a success criterion written down before we start — a testable statement with a number and a date. If we miss it, you should not buy.