Solved

CV11FR20 SCOM Alerting issue

  • 27 January 2021
  • 7 replies
  • 184 views

Userlevel 3
Badge +8

Hi guys, quick question:

 

A few months ago I updated a customer environment to FR20. Recently we found that SCOM Alerting did not work anymore.

 

After investigating we found that the GalaxySCOM.csv file contents looked complete different than it did before. After deleting that file, it got recreated and contents looked OK again. And SCOM Alerting was working again.

 

Is this a known issue?

icon

Best answer by Stuart Painter 27 January 2021, 13:16

View original

7 replies

Userlevel 4
Badge +7

Hello!

Sorry to hear you experienced this - I can confirm this is a known issue and was fixed with Hotfix 2861. This means going forward that if you were to upgrade to FR20 + install MR 28 which this hotfix is part of, the issue would resolve.

I can see this issue is also resolved going forward (FR21+).

Regarding the content - it will have been the same but it was actually caused by an encoding issue.

Userlevel 7
Badge +15

Hi pdijkgraaf

I’m sorry this has caused an issue and alerts may have been missed for a period of time. It is due to a change in character encoding from SP20, I will request documentation is updated to list this change and list the known issue.

This issue only occurs where an existing Galaxy.csv file was created with a different character encoding, e.g. ANSI, then from SP20 SCOM output uses Unicode. If unicode characters are appended to the existing file, this results in the file containing invalid characters.

The hotfix resolves this situation by creating a new Galaxy.csv file if an existing one is found, to avoid appending unicode characters to an existing file the may have been created with a different character encoding set.

So, this hotfix essentially automates the workaround you have already implemented to detect the presence of any existing Galaxy.csv file and if so, ensure new Galaxy.csv is used from SP20 onwards.

Thanks,

Stuart

Userlevel 7
Badge +15

Hi pdijkgraaf

Thanks for the constructive feedback, I’ll feed this into the appropriate channels internally.

I believe the issue you are referring to was due to a Microsoft change that has now resolved in Commvault with official hotfixes.

This is clearly a hot topic and there is already Community activity on this:

We are currently working on more documentation to share as well.

Thanks,

Stuart

Userlevel 7
Badge +15

To round off this thread, our Documentation team will be publishing a new known issue into documentation under:
Expert > What’s New FR20 > Known Issues > Alerts and Notifications >

SCOM Alerts May Not Work After Upgrade to Service Pack 20

With the resolution: To fix this issue, apply the Maintenance Release 11.20.32 on your Service Pack 20 installation.

This isn’t live yet, but will be published on the next Documentation update cycle.

Thanks,

Stuart

Userlevel 7
Badge +15

Hi pdijkgraaf, thanks for the question.

There is an issue where SCOM alerts might have issues with unicode characters.

This can occur for some existing GalaxySCOM.csv files created using ANSI character encoding set and this results in the file having invalid characters after updating to SP20 when new characters are appended using Unicode characters.

The workaround in this case is to do exactly as you have already, rename, move or remove the existing GalaxySCOM.csv and allow a new one to be generated which uses unicode encoding going forward.

Thanks,

Stuart

Userlevel 3
Badge +8

Hi Stuart, thanks for this! Consider the matter closed. :-)

 

As a bit of constructive feedback: we believe in general Commvault should be more forthcoming in communicating potentially critical issues. Another example of this is the fact that in MS365, Teams Chat History folder was moved and not protected by Commvault by default and no alert/error was given. There is/was an Additional Setting for this, but one would only be informed about this though Support, after the issue probably already occurred.

Userlevel 3
Badge +8

Hi Edd and Stuart, thanks for confirming! :-)

Can you share more details on the fix? Does it revert the encoding (which may force us to perform the workaround of deleting the file, again), or does it fix it in a different manner?

Also, the customer wonders why such an important issue was not posted in documentation.commvault.com under “Known Issues” for FR20, or another form of proactive alerting.

Now they were left without proper alerting for a few months without knowing, which could have caused critical issues in their environment.

Thanks again!

Reply