Removing the old 5.7 MP (dependencies problem)

[Jarv]

Just as a follow up to my question on updating 5.7 to 6.0 I now have an issue with how I am going to remove the old MP if anyone could point me in the right direction to understand how to solve this?.. (I haven’t done the upgrade yet)

For some reason when I look at my old MP dependencies I have a number of unsealed management packs that depend on the nworks MP.

These unsealed MP’s tend to be for distributed applications, custom (home-made) service and processor monitors. However I can’t see how nworks has been “wrapped” up into these as most are targeted at Windows server or something like that.

I have edited the XML of each of the MP’s and while I can see the nworks MP as a dependency there is no mention again of the MP in the code itself? Wonder if anyone could help explain this? And if I edited the XML directly, took out the nworks dependency and re-imported what is the worst that could happen??

Many thanks

[sergey.g]

Hello Steve,

I saw similar situations in our internal labs. Sometimes this could happen when you created an override or an object or some other entity which depends on nworks MP and then removed such a customization. In this case SCOM still keeps the reference, unfortunately this is by design.

And looks like you are already on the right track with fixing that. Export MP, remove a reference, import MP back (I would recommend to change the version of this modified MP). If there are indeed any dependencies - SCOM will tell you during the import, just keep a copy of the original MP to make sure you have a backup in case you need to try removing the reference once again.

Let me know if you have any other issues or questions with respect to removing 5.7 MP.
Thanks.

[Jarv]

Thanks Sergey, I am going through and removing the references and re-importing with a new version number

I noticed we do have one override that targets the "nworks vmware collector services" for the monitoring host private bytes threshold setting and sets this to 1610612736. Would this be something that was previously documented by veeam to do as part of the install do you know? I am tempted to get rid of it before I do my upgrade next week but worried I will damage something with the existing infrastructure until that time. Perhaps I should remove it after the 6 upgrade and before I remove the 5.7?

[sergey.g]

Hi Steve,

You are safe to remove any of your old 5.7 overrides - they do not affect v6. In V6 we've implemented those overrides in a different way (as a recovery action, so that you don't need to worry about that at all).

Thanks.

[Jarv]

Sergey, I have done the upgrade and managed to remove the old dependencies and therefore the old MP however I have a couple of issues I didnt run into in my test environment..

Firstly I have 2 managmenent servers and each of these has a collector running (the upgrade went fine the service sems to be OK). However if I look only one of them is currently listed and its collector version is still showing 6.0.0.1421 even though I patched it. Will the other appear over time and the versions correct?

Also I just want to understand the "Configure health service" task. In the install manual it is quite clear to run this as part of a standalone installation (under step 3 - import veeam management packs). However I can find no reference to having to run this when doing an upgrade? Should I in fact be running this task against both of my collectors?
(EDIT: Should add the reason I ask this is I have a warning that says "Veeam Collector: Health Service Recommended configuration monitor" - with the description saying the collector is not optimally configured)

thanks

[sergey.g]

Hi Steve,

I need to check what we have in documentation, maybe we need to fix some things. You need to run the task on a management server, so obviously this is the case for stand-alone installation, but it should also be the case for any collector installed on a management server.

With respect to discovery of your collectors - this job is running not very often (I think once a day), so I would recommend to restart the SCOM agent service on those servers. Do it for both servers and then check the version number for both, let me know if you still see issues with them.

Thanks.

[Jarv]

Thanks for the quick reply.. I am going to restart the health service on the MS/Collector server that is not getting picked up at the moment. Will let you know how that goes.

To be clear on the documentation. On page 24 it has a side "Note" saying the configure health service task will not run automically on the management server. However I am installing via the upgrade on page 31/32 and see no reference to this so wasnt sure if perhaps the upgrade actually did this for you.

thanks

[sergey.g]

Hi,

Thank you very much for the tip, we'll fix the documentation.

Let us know if you still have any issues or any additional questions.

Thanks