Unsolved
This post is more than 5 years old
13 Posts
0
598
Duplication of devices in Schedule Maintenance
We have discovered that it is possible in SAM 7.2.0.22 to duplicate devices in Scheduled Maintenance. For example, I select a particular switch and place it in maintenance using the Schedule Maintenance function. Then select the same switch and repeat the process, but set a different, overlapping schedule (I did not try duplicating the same exact schedule). Both subsequent InMaint alerts remain in the SAM console with the same Event Name, Name, and Class. However if I Acknowledge either one of them, the alert clears, and the device itself comes out of maintenance (In Maintenance = No), but the remaining maintenance alert remains. When you Acknowledge that one, it only sets Ack = Yes and sets the owner name. The alert is not cleared.
This occurred when one NOC operator placed a device in maintenance without realizing it had already been set by someone else.
Is there a way around avoiding duplicating scheduled maintenance? Is there a fix (or feature) due in an upcoming release? I did not find anything in the release notes/patch README for SAM 7.2, 8.0, or 8.1.
Thanks.
Steve
popeye2
18 Posts
0
August 2nd, 2010 17:00
Hello Steve,
I too have come across this issue recently during testing, and I believe that this is now addressed by CQ 387650 listed in the fix list of the SAM 8.1 release notes. I have pasted the accompanying problem description below:
New notification instances have the InMaintenance flag set to TRUE
when the object is not in maintenance mode. The Maintenance
adapter is not putting the Class "SNMP" event in maintenance.
Notifications are not having the InMaintenance flag set to TRUE when
the object is in maintenance mode.
Mis-management of the inMaintenance flag for an object can lead to the inconsistent scenarios like these. I would think that multiple/overlapping maintenance schedules should not be allowed, but this could only be tracked via this inMaintenance flag.
Even so, if convenient, there is still merit in raising a service request for your software level. There could be another root cause at play here which has not yet been discovered.
Kind Regards,
Louie Cavaliere
EMC Global Services