Comments
- 1-5 of 5
Thanks Chris.
I suspected that the addition of critical monitoring would complicate things for the programmers. However I did not think they would reduce functionality for convenience sake, which is what this looks like.It is not good practice to remove existing functionality in favour of new features, especially without notifying users of the changes. If this was by design, Ipswitch needs to share the info with us so that we don't spend hours undoing our changes and trying to determine if we are to submit a request for a feature change or a bug fix. Perhaps it should be a request to finish the job right.
Thanks for checking into this, Will.
I am trying to get my head around the ramifications of your scenario of placing 20 min poll on critical and 3 min on others. Granted, this is not ideal but should be technically possible.
I see it the same as what our practise has been in the past i.e. creating two devices, one with polling of 3 min, with 'up' dependancy on the other device, which has polling of 20 min. Doesn't appear to be a problem there but would be nice to consolidate devices into one with multiple polling and criticality.
By the way, it looks like this forum cannot handle multiple replies to comments. I get an error saying cannot post empty comment.
Further to this, it only appears to be disabled when you set a critical monitor for the device. Until Ipswitch fixes this, you will probably have to choose between dependence on a critical monitor for the device or independent poll intervals.
Same issue here with v14.
We had a similar requirement. We needed to assign different SMS recipients on a weekly basis or if sick etc. We also did not want the person doing the scheduling to have the ability to mess up things inside of WUG.
Our solution, although heavily customised for our use, works quite well. It ended up being a mixture of an asp page which runs on our intranet and reads and writes the different SMS numbers to the individual Action, which is included in different policies. As long as these individual actions (e.g. NetworkAdminLvl2) are not deleted, you should be able to refer to them by values found in ActionTypeData table. SQL.txt attached to show basic select and update queries.
Obviously there is more in the code to prevent corrupt data and give us more flexibility. We have three levels of notification (Email, SMS1 and SMS2) to escalate if the issue is not resolved. We also have different notification groups for certain devices or monitors. We named our policies something like 'NetworkAdmin-006-012-024' to show the group and the times in minutes for email, sms1 and sms2. The asp page has also had a bulk email button added, which sends an email out to every user and includes a list of who is currently rostered on.
SQL.txt (583 Bytes)