UIM users for alarm processing configuration SDGTW
Article ID: 131010
Updated On:
Products
DX Unified Infrastructure Management (Nimsoft / UIM)
Issue/Introduction
In previous versions of the sdgtw probe, the userid for alarm processing (the assigned_to userid) as specified in the individual service desk profiles. In the latest version(s) it has been moved up to the top level and removed from the individual profiles. This design/configuration change has made it impossible to simultaneously use multiple service desks and route different alarms from different systems to alternate service desks. The primary use case is having a dev, test, and production service desk instance, for example Service Now, and having a single UIM instance monitoring production, dev, and test systems. Nrmally, auto operator profiles would be created to assign different userids based on whether the device was test, dev, or prod which would dictate which service desk the incident is created in. With the current configuration at the top level, while multiple userids can be configured (comma separated), all the incidents are created in the one service desk that is configured as the default service desk. The userid for alarm processing configuration needs to be moved back to the individual profiles so that the above use case can be accounted for as well as the use of multiple service desk vendors.
This design/configuration change has made it impossible to simultaneously use multiple service desks and route different alarms from different systems to alternate service desks. The primary use case is having a dev, test, and production service desk instance, for example Service Now, and having a single UIM instance monitoring production, dev, and test systems. Nrmally , auto operator profiles would be created to assign different userids based on whether the device was test , dev, or prod which would dictate which service desk the incident is created in. With the current configuration at the top level, while multiple userids can be configured (comma separated), all the incidents are created in the one service desk that is configured as the default service desk. The userid for alarm processing configuration needs to be moved back to the individual profiles so that the above use case can be accounted for as well as the use of multiple service desk vendors.
This design/configuration change has made it impossible to simultaneously use multiple service desks and route different alarms from different systems to alternate service desks. The primary use case is having a dev, test, and production service desk instance, for example Service Now, and having a single UIM instance monitoring production, dev, and test systems. Nrmally , auto operator profiles would be created to assign different userids based on whether the device was test , dev, or prod which would dictate which service desk the incident is created in. With the current configuration at the top level, while multiple userids can be configured (comma separated), all the incidents are created in the one service desk that is configured as the default service desk. The userid for alarm processing configuration needs to be moved back to the individual profiles so that the above use case can be accounted for as well as the use of multiple service desk vendors.
Environment
UIM 8.51, 9.0.2
sdgtw probe version 2.01
sdgtw probe version 2.01
Resolution
This still works in the sdgtw 2.10 version.
No need to use an Auto Operator (unless it is to assign the alarms).
For example, create 3 service desk rules in the sdgtw configuration.
To route based on the "assigned_to" and value, then select the appropriate service now profile in the sdgtw configuration.
No need to use an Auto Operator (unless it is to assign the alarms).
For example, create 3 service desk rules in the sdgtw configuration.
To route based on the "assigned_to" and value, then select the appropriate service now profile in the sdgtw configuration.
Feedback
Yes
No
Powered by
