Unmanage Indefinitely

Oddly enough, I don't like these.  I would rather the "Mute Now" and "Unmanage Now" buttons to default to 24 hours, with that duration possibly settable somewhere.  I *do* like the ability to mute or unmanage indefinitely, but I want it to take a bit more effort.  It will be all too easy to "Mute Now", perform the maintenance ... and then forget to un-mute.

I suppose it's time to set up a daily report of all muted and un-managed nodes and check each day to make sure that nothing is turned off that shouldn't be.  That's probably a good idea anyway, but it didn't really seem necessary until now.

That is perfect!  I was struggling trying to find a way to do this efficiently.

Use Manage Nodes and sort by status, or for all entity types you can use a report like this one: Current Muted Alerts (v4)

How do you find these after they are set? 

For my example, we have some with the new Maintenance Mode "Mute Now" set, but don't really have a way to find them again later in the sea of nodes in our system.

I am sure something is set in the database, but how can we do a Report of Search for it?  I can see the "Unmanaged" node object for when a device is unmanaged, but what about muted?

This was delivered as part of NPM v12.1 which released 3/14/2017.  Now, when you use the new Maintenance Mode "Mute Now" and "Unmanage Now" options, the nodes are muted or unmanaged indefinitely.

Accompanied by a field requiring the user to provide a reason for the unmanage, yes.

We use the "99" on the last two digits of the year method for the UnManage Until value.  All nodes with an UnManageUntil value in the year 2099 are considered to be "permanently" UnManaged.

I don't understand why anyone would vote no to any suggestion. I think they should remove the vote down option.

We have a custom property for PROD, DEV, QA type of systems and some alerts are based upon that.  To work around this we essentially added another possible value to put that node into a holding pattern.

No alerts but we still gather statistical data.  This is great for new nodes that are not ready for primetime or a previously production node that is sidelined for a period of time before being retired so we can do some

performance comparisons to the new server. 

Being able to unmanage for an indefinate period of time has it's uses....but from some things I have seen and heard, NPM does not like for things to be "not polled" for long periods of time. Openview didn't care how long something was not managed.

One potential disadvantage I see is if something falls out of DNS or is changed <never seen that happen before>.  There would need to be a way to track that especially for a static ip based node.

When I unmanage a device I simply change the last two digits of the year listed for the end date to 99.  I figure that a device unmanaged until 2099 is about as indefinite as I'm going to get...