A browser‑based operations console for SCOM

No. Pulse is a second front end for the management group you already run. Your management servers, agents, management packs, databases and data warehouse stay exactly as they are. Pulse reads and writes through the Operations Manager SDK, the same interface the Operations console uses, so anything you change in Pulse is visible in the console and the other way round.

No. There is no Pulse agent. Nothing is installed on your monitored computers, and nothing changes about how your existing SCOM agents report.

On one Windows server, which can be a dedicated server or a management server. A dedicated server does not need the Operations console; where a management server or the console is already on the host, Pulse uses that installation, so it always matches your management group. Windows Server 2016 or later, .NET Framework 4.6.2 or later (in-box on every supported version), and IIS with ASP.NET 4.x and Windows Authentication, which setup installs if they are missing.

Operations Manager 2016 UR7 and later, 2019, 2022 and 2025. SCOM 2012 R2 is not supported.

No. Pulse caches the SCOM data it works with in an embedded database on the Pulse server itself, so there is no database server to provision and nothing is installed on your SQL estate. That cache is substantial — it mirrors alerts, objects, groups, management packs, rules, overrides, agents, roles and performance samples — and it lives on local disk; see the requirements above for where it sits and how it is backed up. It does not create anything in your SCOM databases either: changes to grooming settings go through the Operations Manager SDK, exactly as the console’s Database Grooming dialog does. When the service account can read the Operations Manager database, Pulse reads alerts, objects, health and performance from it directly, which is faster and lighter on the management server; otherwise it reads through the SDK and behaves the same. Historic charts read the data warehouse when you enable them. The web tier never opens a SQL connection at all.

For historic performance charts, the service account needs db_datareader (or the OpsMgrReader role) on the data warehouse database, plus TCP to that SQL instance from the Pulse server only. Pulse finds the warehouse from SCOM’s own management-group settings through the SDK, so nobody types a server name, and if the warehouse is moved Pulse follows it. Leave the warehouse feature off and none of this applies — live charts are unaffected. The operational-database size view needs VIEW DATABASE STATE; without it that one card is unavailable and nothing else changes.

Windows Authentication. Nobody is asked to type a password into Pulse — the browser presents the signed-in Windows identity, the way the SCOM web console does.

By your SCOM user roles, and nothing else. A person sees what their roles cover and may do what each role’s profile allows — the same answer the Operations console gives. Read-Only Operator sees and cannot act; Operator works alerts, maintenance, tasks, diagnostics and recoveries; Advanced Operator adds overrides; Author adds class-wide overrides and group authoring; a SCOM Administrator is the only kind of Pulse administrator. On SCOM 2022 and later, Read-Only Administrator and custom roles made from Delegated Administrator are honoured permission by permission. Signing in on its own grants nothing: someone in no SCOM user role can sign in and sees nothing, and is told why. To give someone access, add them to a SCOM user role.

The Pulse application does not. No CDN, no external fonts, no telemetry. It is designed to run on a network that has no outbound path at all.

Yes. A sealed management pack ships with the product, under the install folder, along with notes on importing it. It is deliberately not imported for you, because importing changes your management group. Pulse runs fine without it.

Management pack authoring and the distributed application designer; creating Run As accounts and rotating their passwords; editing company knowledge; complex group formulas; sealed management pack export; the network and UNIX/Linux discovery wizards; connector configuration; SCOM and SSRS reporting; and deploying gateways and management servers. The full list is on this page under “What still needs the console”.

Because every action Pulse performs is queued as a record and retained for the audit trail, so a password would be written to disk. Pulse edits everything about a Run As account except the secret — the profile it is bound to, the agents it is distributed to, its name, description, and deleting it — and the write endpoint rejects a request that carries a password rather than silently discarding it. Creating accounts and rotating passwords stay in the console on purpose.

Download the package, install it, and leave the licence key blank. A 30-day trial starts automatically — there is no key to request and nothing to activate. A key can be pasted in later from the License page without a restart.

They overlap on maintenance windows and nothing else. The Maintenance Mode Scheduler does that one job, and it costs less. Pulse covers maintenance as one workflow among alerts, health, performance, overrides, administration and dashboards. If scheduling windows is your whole requirement, the Scheduler is the better-value fit. A Pulse licence includes the Maintenance Mode Scheduler at no extra charge for as long as Pulse is active, and if you already have a Scheduler subscription, the unused part is credited against Pulse.

An annual subscription, priced by the number of agents in your management group — the same model as the rest of the SCOM2K7 range. $5,000 a year up to 500 agents, $8,500 up to 1,500 and $12,000 up to 4,000; above 4,000 we quote, from $20,000. One licence covers the whole management group, with unlimited users and no named-user seats. A 3-year subscription paid up front carries a 10% discount and holds the price for the term. The first three tiers can be bought online, and nothing about the trial depends on any of it.