How to alert on Wireless Access Point

This means that they cannot be alerted on by SolarWinds Platform Alerts. We can modify the configuration to change this behavior. When we make the changes we alert on the AP's.
 

Follow the instructions for your NPM version.

If the APs are not removed after following these steps, it could be due to the device recording the details of the AP rather than dropping the data.

NPM 11.5.3 and earlier 
 

NOTE: SolarWinds strongly recommends that you create a backup of the following file:

C:\Program Files (x86)\SolarWinds\Orion\Wireless\SolarWinds.Wireless.Collector.dll.config

Modify the CONFIG file using a text editor:

• Find the following key:

<add key="RemoveDisappearedAPs" value="True" />

• Change the key to the following:

<add key="RemoveDisappearedAPs" value="False" />

• Save the changes.
• Restart Orion Services.

The functionality works in the following way:

•  When the AP disappears from the controller's SNMP, it's removed from NPM.
•  An AP which disappears cannot be alerted as it gets removed from the Database.
• When an AP disappears from the WLC's SNMP, the Access Point goes into an Unknown State in NPM.
• If the AP appears on another WLC, it will appear as a new Access Point.
• When the AP comes back to the old WLC again, the once disappeared AP is marked as UP again.
• An alert can be triggered for when an AP goes into an Unknown State (Disappeared) and reset the alert when the AP reports in Up status.

NPM 12.0 to SolarWinds Platform 2024.4

• Go to the Orion Web Console.
• Change the URL to: 
  • http://YOUR IP OR HOSTNAME/Orion/Admin/AdvancedConfiguration/Global.aspx
• Do not make any configuration changes to any entries in the Setting pages unless advised to by SolarWinds Support or another document in the SolarWinds Success Center. Changing settings could have negative consequences in your environment.
• Find the Wireless Section.
• De-select the setting for RemoveDisappearedAPs as per the below screenshot.
• Save the changes.
• Restart Orion services in Orion Services Manager.

If the above steps work you will then need to manually remove any AP's that go to unknown status since they will no longer be automatically removed by NPM. You will need to do the following:

   1. Remote into the Main Orion server
   2. Open Database Manager
   3. Go to table [dbo].[Wireless_AccessPoints]
   4. Enter the query: 

-- Scripts are not supported under any SolarWinds support program or service.
-- Scripts are provided AS IS without warranty of any kind. SolarWinds further
-- disclaims all warranties including, without limitation, any implied warranties
-- of merchantability or of fitness for a particular purpose. The risk arising
-- out of the use or performance of the scripts and documentation stays with you.
-- In no event shall SolarWinds or anyone else involved in the creation,
-- production, or delivery of the scripts be liable for any damages whatsoever
-- (including, without limitation, damages for loss of business profits, business
-- interruption, loss of business information, or other pecuniary loss) arising
-- out of the use of or inability to use the scripts or documentation.

SELECT TOP 1000 * FROM [dbo].[Wireless_AccessPoints] where IPAddress = 'the_ip_to_remove"

   5. Click Enable Table Editing
   6. Right-click and select delete on any rows which need to be removed

SolarWinds Platform 2024.2 and later

In environments with redundant WLC configurations (primary + secondary controller), standard Thin AP alerts can generate false positives when an AP fails over from one controller to another. NPM 2024.2 introduced two new SQL-based out-of-box alerts specifically for these environments.

Both alerts are disabled by default and must be manually enabled.

New alerts:

1. [Advanced] Thin AP Disappeared from WLC

• Waits for 2 consecutive poll rounds before triggering, ensuring the secondary WLC has been polled before concluding the AP is truly gone.

• If the AP reappears on the secondary WLC within 2 poll rounds → no alert fires (AP failed over correctly).

• If the AP does not appear on any WLC within 2 poll rounds → alert fires.

2. [Advanced] Thin AP Down

• Triggers when AP status = Down, correctly handling primary ↔ secondary controller transitions.

• Clears on the primary and creates a new alert on the secondary if the AP moves controllers while down.

Additional setting:

• TriggerThinApDisappearedEventByCollectorService — Allows suppression of the legacy "Thin AP disappeared" event to prevent conflicts with the new advanced alert logic. Configure in Admin > Advanced Configuration > Wireless.

Recommended steps:

1. Go to Alerts & Activity > Alerts > Manage Alerts

2. Search for "[Advanced] Thin AP"

3. Enable both alerts

4. If you experience duplicate alerting from the legacy "Thin AP disappeared" event, disable TriggerThinApDisappearedEventByCollectorService in Advanced Configuration.

Note: Starting NPM 2025.1, these advanced alerts work in conjunction with the DisappearedAccessPointsTimeToLive TTL setting for best results.

SolarWinds Platform 2025.1 and later

A new DisappearedAccessPointsTimeToLive setting was added to the Advanced Configuration. This setting allows you to define the time period during which APs will continue to be stored in the SolarWinds Platform database after disappearing. So, if you don't want to store disappeared APs permanently in the database and at the same time want to have enough time to trigger an alert that APs disappeared and investigate this, then you can set an appropriate time via this setting. APs will be removed from the database only after this time.
How the new DisappearedAccessPointsTimeToLive setting coexists with the RemoveDisappearedAPs setting in the Advanced Configuration: 

NOTE
DisappearedAccessPointsTimeToLive setting is evaluated during each processing round. For example, if DisappearedAccessPointsTimeToLive is set to 25 minutes and the poll interval is 10 minutes then it will work in the next way:

12:00 - WLC reports about AP1
12:10 - WLC stopped reporting about AP1 => AP1 marked as disappeared => LastReported = 12:00
12:20 - AP1 didn't reappear so Collector keeps storing it
12:30 - AP1 didn't reappear so Collector will delete it only now during processing round because CurrentPollTime(12:30) - LastReported > DisappearedAccessPointsTimeToLive

SolarWinds Platform 2025.2 and later

In SolarWinds Platform 2025.2, the out-of-box "Thin AP is down" alert template was corrected to monitor the Thin AP directly, rather than the Wireless Controller.

• Previous behavior: The alert fired when the WLC that had at least one connected AP went down — it was monitoring the controller, not the AP.

• New behavior: The alert fires when ThinAccessPoint.accessPointState = Down, regardless of WLC state.

What this means: If you are on 2025.2 or later, you can use the updated OOB "Thin AP is down" alert template directly — no need to build a custom alert from scratch. The alert will correctly trigger for the specific AP that is down, independent of the WLC's health status.

Recommended steps:

1. Go to Alerts & Activity > Alerts > Manage Alerts

2. Search for "Thin AP is down"

3. Verify the trigger condition shows: ThinAccessPoint — accessPointState — is equal to — Down

4. Enable the alert and configure your notification actions

Recommended configuration by version