SCOM – Migration Tips

SCOM – Migration Tips

Spread the love

Hello folks! Today I would like to give you some SCOM migration tips.

SCOM migration tips

  • Our best friend for the designs is the “Sizing Help Tool” (link). With this Excel file, entering the number of agents, we can quickly know how much disk we should need in our Ops DB and DW DB and give us an idea of the hardware and amount of Management we are going to need, BUT, keep in mind that these recommendations are the minimum recommend, so if it recommend to you a Management Server with 4GB of RAM, trust me, put 8 GB of RAM.
  • I don’t recommend a Management Server with more than 1.800 agents or 2.000, the Microsoft’s recommendations are 3.000 as the maximum but in my experience, this amount of agents in only one Management Server request us a lot of hardware resources. On the other hand, we should distribute a number of servers in two or more Management Server to avoid a single point of failure and in this way ensure a service SLA of 99%.
  • Remember as we saw in a previous post that for the Operational Database, we must ensure that all time has between 40% and 50% free disk space, otherwise, we will begin to notice performance disadvantages, and for the Datawarehouse with 10% free space we would be all right. I do not recommend self-growth, instead, it is better to allocate all the necessary space leaving the percentages mentioned above free. In case of no option, set up the auto-growth in 500MB would be the best.
  • Port 5723 is used for Windows Servers and 1270 is used for Linux servers. Remember to check that you don’t have connectivity issues through this port when you want to migrate them.
  • Uninstall the agents in the old console – Install the agents in the new one. If you don’t do that, you will see that the agent will start to report on both environments, duplicating alerts (if email notification is configured could be a mess) and it is likely that some servers will have performance problems.
  • Again, as I said in other posts, never import all the Management Pack at once, upload one by one, ensure to create a custom Management Pack per each default one, and if you can per each version too (Custom SQL 2008, Custom SQL 2012, Custom SQL 2014, etc instead of Custom SQL server with all the overrides).
  • The first thing that we are going to see is a ton of alerts, events collections, etc. Disable every monitor/rule/Discovery that you don’t need. For example, you are monitoring Mount Points for Server 2008 and not for 2016? Enable the Discovery only for the class 2008 and disable it for 201. This little thing will improve a lot your performance.
  • Understand what the Management Pack do before import it. Something that I use to do is: Import the Management in a Lab Environment, read the MP context with MP Viewer (Read this post) create a Custom MP and disable everything that I am not going to use, once everything is as I want, I import both in the Production Environment.
  • Documentation!! Is very, and really, very important to have a repository where you document all the change you did, how you solve a specific issue, everything you think is important, because believe it or not, is really probably that you are not going to work in the same place Administering SCOM all your life, so you must leave a legacy, where anyone who comes after you can continue to maintain the platform as it should.

I will add more things as I remember, but basically this is the basis of all migration (at least the one that has worked for me the last 8 years of apprenticeship).

I hope this will be usefull for all and let me know your thoughts!

Matias Caniglia

Leave a Reply

Your email address will not be published. Required fields are marked *