Loading

×Sorry to interrupt
This page has an error. You might just need to refresh it.
[NoErrorObjectAvailable] Uncaught ReferenceError: addCTracking is not defined
Failing descriptor: {markup://c:KM_ArticleThemeLayout}

Refresh

Cookie Preference Center

General Information on cookies

When you visit our website, we use cookies to ensure that we give you the best experience. This information does not usually directly identify you, but it can give you a more personalized web experience. Because we respect your right to privacy, you can choose not to allow some types of cookies by clicking on the different category headings to find out more and change your settings. However, blocking some types of cookies may impact your experience on the site and the services we are able to offer. Further information can be found in our

Cookie Policy.

Strictly Necessary

Strictly Necessary

Always Active

Strictly Necessary

Strictly necessary cookies are always enabled since they are essential for our website to function. They enable core functionality such as security, network management, and website accessibility. You can set your browser to block or alert you about these cookies, but this may affect how the website functions. For more information please visit www.aboutcookies.org or www.allaboutcookies.org.

Cookie Details‎

Performance

Performance

Performance

Performance cookies are used to analyze the user experience to improve our website by collecting and reporting information on how you use it. They allow us to know which pages are the most and least popular, see how visitors move around the site, optimize our website and make it easier to navigate.

Cookie Details‎

Please confirm your settings by refreshing the page.

Functional

Functional

Functional

Functional cookies help us keep track of your past browsing choices so we can improve usability and customize your experience. These cookies enable the website to remember your preferred settings, language preferences, location and other customizable elements such as font or text size. If you do not allow these cookies, then some or all of these services may not function properly.

Cookie Details‎

Advertising

Advertising

Advertising

Advertising cookies are used to send you relevant advertising and promotional information. They may be set through our site by third parties to build a profile of your interests and show you relevant advertisements on other sites. These cookies do not directly store personal information, but their function is based on uniquely identifying your browser and internet device.

Cookie Details‎

Advertising Cookies

Consent Leg.Interest

Select All Vendors

Select All Vendors

Select All Hosts

Select All

Clear Filters

Information storage and access

Apply

Confirm My Choices Reject All Allow All

My Subscriptions

Loading

Knowledge Base

ViPR SRM/Watch4Net: Upgrade from 3.7.X or 4.0.X to 4.1 causes Alert Definition Duplication (502037)

Last Updated: 5/29/2020Categories: TroubleshootingTotal Views: 3390Language:
English

Subscribe to get an email
newsletter with new updates

Please provide article feedback:

Symptoms

ViPR SRM/Watch4Net: Upgrade from 3.7.X or 4.0.X to 4.1 causes Alert Definition Duplication

When an upgrade from 3.7.X or 4.0.X to 4.1 the alert definitions for Dell, IBM SVC, Isilon, VNX and VPLEX SP s are duplicated mainly due to rename/restructure of definitions. The upgrade doesn't take care of the Deleted/renamed Alert definitions and they come back in the upgraded setup. As a result of this, post upgrade to 4.1 we will see two definitions for the same alert and this leads to duplicate alerts, mails and 3rd party traps

Cause

Upgrade from 3.7.X or 4.0.X to 4.1 causes Alert Definition Duplication

Resolution

Option 1: As documented in the upgrade guide, follow below steps:
Following steps need to be followed after the core upgrade has been done and before the Solution Pack upgrade to fix the problem:

Step 1: [Optional] Take a back-up or copy the existing alert definitions.
This can be done by exporting "Alert definitions" from the Alerting Frontend.
It will export all the alert definitions of all SPs that are present. You can also select the SP folder name and export to take a back-up of alert definitions related to that SP only.
Step 2:[Optional] Take a back-up of the alerting-context.xml file. This can be done by navigating to Centralized-Management >> Logical           Overview >> Backends >> Alerting Backend. Under the Configuration Files, you can copy the alerting-contexts.xml. This will contain contexts for all the alert definitions for all SPs, so please edit it as per the alert definitions which are required.
Step 3: Navigate to Centralized Management.
Step 4: Click Solution Packs > Storage > Solution Pack Name.
Step 5: Remove the Pre-configured alerts block using the trash can icon. This step will delete all the alert definitions for the SP.
Step 6: Click SOLUTIONPACK CENTER.
Step 7: Select the Solution Pack from the Browse and Install Solution Packs window.
Step 8: Click Install.
Step 9: Ensure that the Pre-configured alerts component is selected and click Next.
Step 10: Click Install.

Option 2: Automated script to take care of this scenario. (please reference the attachments for the script which includes a readme file for instrcutions)

The script performs some pre-checks and will disable the old and deprecated alert definitions and hide them from being seen in the UI. This will take care of upgrade paths, 3.7/3.7.1/3.7.2-4.1,  4.0/4.0.1/4.0.2/4.0.3 - 4.1

Version Specific Scripts:

Linux/vApp - AlertDefLookup.txt, normalizeAlertDefs.sh
Windows  -   AlertDefLookup.txt, normalizeAlertDefs.ps1

What it does

It will disable the alert definition present in the lookup file and hide them. This is the scenario we intend to reach to avoid duplicate definitions. The lookup file - AlertDefLookup.txt  will take care of upgrade paths, 3.7/3.7.1/3.7.2-4.1,  4.0/4.0.1/4.0.2/4.0.3 - 4.1 AlertDefLookup.txt   is a common file for any upgrade and for both windows and linux based OS.

The script will take a backup of the existing alerting.xml in format   alerting.xml_ <mmddyy>_<hhmmss> format, e.g. - alerting.xml.062117_152015
This needs to be executed on the Primary Backend server where alerting.xml resides. Alerting-Backend needs to be restarted post script execution.

Execution steps.
Windows
"Usage: powershell.exe -file normalizeAlertDefs.ps1  [path to alerting.xml] AlertDefLookup.txt"
"Example : powershell.exe -file normalizeAlertDefs.ps1 C:\APG\Backend\Alerting-Backend\Default\conf\alerting.xml AlertDefLookup.txt"

Binary/vApp
"Usage: ./normalizeAlertDefs.sh [path to alerting.xml] AlertDefLookup.txt"
"Example : ./normalizeAlertDefs.sh /opt/APG/Backend/Alerting-Backend/Default/conf/alerting.xml AlertDefLookup.txt"

Please Note: Kindly verify ctrl+M characters(New line characters in windows) in the file if the file is transfered from windows to Linux.

Follow below steps if you find ctrl+M characters

vim -b AlertDefLookup.txt
press escape.
Type -- :/%s/^M//g
To get ^M   Use ctl+V+M.
save file

Detectable by VMware SkylineTM

Actions

Copy

link to clipboard
copied!

Print

Language:
English

Attachments

Additional Resources

No results for undefined

Ask The Community

Get answers quickly from VMware experts in the community

Post Subject

CONTINUE IN COMMUNITIES

Related Products:

Related Versions:

VMware Smart Assurance - Watch4Net/M&R

Take Our Survey

Support Assistant