Unmanage Now / Mute Alerts silently fails for limited accounts that do not have the "Allow Real-Time Polling" permission in SolarWinds Platform

6/29/2026 7:52 PM

6/30/2026 3:21 PM

After upgrading the SolarWinds Platform, users with limited (non-administrator) accounts report that the "Unmanage Now" and scheduled maintenance actions appear to run successfully but the affected objects never transition to the Unmanaged state. The same behavior can occur with "Mute Alerts" and with remanage operations performed through the API (SWIS).

The issue only appears for accounts configured with a specific permission combination:

• "Allow Node Management Rights" = No
• "Allow Account to Unmanage Objects & Mute Alerts" = Yes
• "Allow Real-Time Polling" = No (located under the Performance Analysis Settings section)

When a user with this combination opens a Node Details page and selects Maintenance Mode → Unmanage Now, the web console briefly reports success, but the object's status does not change to Unmanaged. Administrator accounts, and accounts that also have "Allow Real-Time Polling" enabled, are not affected.

The trigger permission configuration is shown in Figure 1.

Figure 1: Account "Define Settings" page showing the permission combination that triggers the issue — node management rights disabled, unmanage/mute rights enabled.

When the action fails, an entry similar to the following is recorded in ActionsExecution.log on the main polling engine (values such as account name, dates, and schedule names are environment-specific):

2026-01-01 09:15:42,123 [64] ERROR SolarWinds.Orion.Core.Actions.ActionExecutorBase - (null)  Action [Action: ID: , ActionType: MaintenanceWindow, Title: , Description: , Enabled: True, Order: 0, Approved:  , Context: EnviromentType: ScheduledTask, ScheduleName:Unmanage Now 20260101_091542,  AccountID: sample_user, StartTime: 1/1/2026 9:15:42 AM, EndTime: 1/1/9999 1:00:00 AM, Reason: ] execution has failed.
System.ServiceModel.FaultException`1[SolarWinds.InformationService.Contract2.InfoServiceFaultContract]: Orion.Nodes.Unmanage failed, check fault information.
Access to Orion.Nodes.Unmanage verb denied. (Fault Detail is equal to InfoServiceFaultContract, ErrorCode=00000014, UserMessage='Access to Orion.Nodes.Unmanage verb denied.' [ SolarWinds.Data.AccessDeniedException: Access to Orion.Nodes.Unmanage verb denied.
   at SolarWinds.InformationService.Core.InformationService.Invoke[T](String entity, String verb, Action`1 setupParameters, Func`2 extractReturnValue) ] ).

Key symptoms to confirm a match:

• The "Unmanage Now" / "Mute Alerts" action reports success in the web console, but the object stays managed.
• The affected account has unmanage/mute rights but does not have node management rights or real-time polling rights.
• The log shows Access to Orion.Nodes.Unmanage verb denied with ErrorCode=00000014.
• The same operation works correctly for an administrator account, or after enabling "Allow Real-Time Polling" for the affected account.

Network Performance Monitor

The SolarWinds Platform information service (SWIS) evaluates access in two stages: an entity-level Invoke permission must be granted before the verb-level rules (such as Unmanage and Remanage) are evaluated.

In affected versions, the entity-level Invoke permission for the relevant objects (for example Nodes, Volumes, and Interfaces) was tied to the real-time polling permission. As a result, an account that had the unmanage/mute right but did not have the real-time polling right (or full node management rights) failed the entity-level Invoke check before the unmanage verb rule could be evaluated — causing the "Access to Orion.Nodes.Unmanage verb denied" error even though the account was explicitly allowed to unmanage objects.

This is a permission-evaluation regression: the unmanage capability should not depend on the presence of the real-time polling permission.

There are two options: a permanent fix (recommended) and an immediate workaround.

Option 1 — Upgrade to a fixed version (recommended)

Upgrade the SolarWinds Platform to a version that contains the corrected permission evaluation (2026.2.1 or later). After upgrading, an account with only the unmanage/mute right is able to unmanage and remanage objects through both the web console and the API, without requiring the real-time polling permission. 

Option 2 — Workaround (grant Allow Real-Time Polling)

If an immediate upgrade is not possible, enable the "Allow Real-Time Polling" permission for the affected account or group. This satisfies the entity-level Invoke check and allows the unmanage/mute action to complete.

1. Go to Settings → All Settings → Manage Accounts.
2. Select the affected account or group (you can start with a single account to validate).
3. Click Edit.
4. Expand the Performance Analysis Settings section and set "Allow Real-Time Polling" to Allow (see Figure 2).
5. Click Submit.

Figure 2: Setting "Allow Real-Time Polling" to Allow under Performance Analysis Settings on the account edit page.