Menu Close

SCOM 2019 is HERE!



QuickStart Guide:

Official announcement:

  • SCOM 2019 went GA on March 14th 2019.
  • The Semi-Annual Channel (1801/1807) will not be continued.
  • New features and fixes will come in Update Rollups every 6 months.

So now we get the best of both worlds….  new features added every 6 months just like SAC, but Long Term Servicing (5 years of mainstream support and 5 years of Extended Support) without the limited 18 month support of each release in Semi-Annual Channel.  Only one branch to deal with supporting, patching, etc.

I’m really happy about this direction….. and it makes a lot of sense for Microsoft and for customers.

SCOM 2016, SCOM 1801, or SCOM 1807 can all be directly upgraded to SCOM 2019.

Direct In-place upgrade paths:



  • Q:  What OS versions will be supported for SCOM 2019 Server roles?
  • A:  Windows Server 2016 and 2019.  LINK
  • Q:  What versions of SQL server will be required for SCOM 2019 Server roles?
  • A:  SQL 2016 and SQL 2017 are supported.  LINK
  • Q:  What Windows OS versions are supported as a monitored Agent for SCOM 2019?
  • A:  Windows Server 2019, 2016, 2012R2, and Windows 10.
  • Note:  According to the current documentation – there is no support for Windows Server 2008, 2008R2, or 2012LINK
  • Q:  What previous SCOM Versions can be upgraded in place to SCOM 2019?
  • A:  SCOM 2016, 1801, and 1807 only.  LINK
  • Q:  In a side by side migration to a new SCOM 2019 management group, what SCOM versions can coexist in a supported fashion?  (i.e… agents of one version communicating with management servers of another version?
  • A:  SCOM 2016, 1801, and 1807 can coexist with SCOM 2019 deployments.  LINK
  • Q:  Are any capacity and scale changes coming in SCOM 2019?
  • A:  No, these are consistent with SCOM 2016.  LINK
  • Q:  Should I upgrade in place from SCOM 2016/1801/1807, or do a side by side migration to a new management group and new VM’s?
  • A:  This depends on your current situation and your goals.  The first and most important decision factor is are all your SCOM infrastructure server roles (including SQL servers) running on Windows Server 2016 at a minimum, and SQL 2016 at a minimum?  If not – you cannot in-place upgrade until you meet the minimum supported requirements.  If you do, the in place upgrade will be the simplest solution.  If you are running on previous OS or SQL versions, you will have to evaluate how much work this will be to migrate all your servers roles, versus deploying a new management group and “starting over”.
  • Q: Can SCOM 2012R2 be in-place upgraded directly to SCOM 2019?
  • A:  No.  You would need to first upgrade to SCOM 2016 as an interim step, per:  LINK
  • Q:  Do I need new management packs for SCOM 2019?
  • A:  No, any MP that worked in SCOM 2012 or SCOM 2016 should work fine in SCOM 2019.  However, you should regularly do a review of your MP’s in use and update them to current versions.

 If you have ANY feedback on this release, PLEASE open a UserVoice submission at



  1. Rick Bywalski

    Well if you think about it the 1801 upgrade was like a reinstall. 1807 was a little better but its is still no where near as easy as SCCM. This does kind of make sense from a support point of view

    • kevinholman

      No, not directly. You would need to upgrade to SCOM 2016 first, or just do a side by side migration. Upgrades would be a pain as the OS and SQL version upgrades would be a lot of work

  2. Rick Bywalski

    Reading this again and not much is changing they just moved the branch release to being included in roll ups

  3. Tim Mason

    This is great news and it’s good to know that Microsoft have actually listened to their customers for once. I’m just about to design a SCOM upgrade for a customer and removing SAC saves me from having a big headache on being forced to go in one direction or another. Having this LTSC/SAC split just didn’t make any sense for the kinds of business clients I have.

  4. Michael Reinders

    Will SCOM 2019 still work with currently installed agents on WS 2008/2008R2/2012? Or will all of those agents stop working/reporting up to the management servers/DB?


    – Michael

    • Kevin Holman

      Technically – you could leave those 2008/2008R2/2012 agents running a SCOM 2012R2 or SCOM 2016 agent, and they will connect and communicate just fine to a SCOM 2019 management server. It just won’t be “supported” by Microsoft. However, many customers did this with Server 2003 agents reporting to SCOM 2016 management servers.

  5. Rick Bywalski

    Seems a little soon to not support the agent on a window 2008 R2 environment it has not got EOL yet. I may have to rethink going to 2019 for a while since I still have a lot of 2008 R2 out there.

    • Kevin Holman

      Windows Server 2008 and Windows Server 2008R2 both fall out of Extended Support in 10 short months, by Jan/2020. This will likely not hinder many customers as most are or should be deep into projects removing this OS from their infrastructure this year.

    • Kevin Holman

      I was also quite surprised to see this, and I am requesting formal confirmation from the Product Group. I am hoping this is a documentation mistake. I recommend filing customer feedback here if this is a major concern:

        • Kevin Holman

          Not yet…. but I can confirm it is not a doco mistake. How do you feel this will impact adoption of SCOM 2019? Would it be a suitable workaround if we supported 2012 connected to SCOM 2019 but using the SCOM 2016 agent?

  6. Rick Bywalski

    What about RHEL 6 we still have a lot of that. We do have an ongoing project to upgrade but need to know what our options are now. We were part way through going to 2016 and planned to just do an in place upgrade to go to 2019 as soon as it released. No RHEL 6 could impact that. For 2008 R2 we have left I could just deploy out the 2016 Agent with SCCM and move on until the server is retired. Any work around for RHEL 6.

  7. JJ

    Hello, i think only support from ms will not be available for 2008 Server. Yesterday i installed enviroment with Scom 2019 and was able to push agents to 2008R2 Server and all works properly.

    2019 Agent Multihome with SCOM 2019 and SCOM 2012R2 works also perfekt.

  8. Coen van Dijk

    Is using SCOM 2019 in combination with an old agent version supported? This would enable me to monitor Windows 2008 R2 by using an old agent version.

  9. David

    I’ll be replacing my network’s SCOM 2012R2 with this version. We have 300 endpoints that we’ll be monitoring. About 40% servers, and 60% network devices. 20% of the devices are at a remote site with a 200 Mbps bandwidth connection. I have used the SCOM sizing tool, but Microsoft’s lowest recommendations are based on 500 servers and 100 network devices. I will be using virtual servers, and i am trying to scale down the deployment to something more reasonable to fit my network. The previous deployment consisted of a single Management Server with a SQL Server hosting the Operations Management , the Data Warehouse, and the Reporting Server databases. I am planning on installing the Web Console, which wasn’t installed before. When attempting to install the Web Console on the 2012R2 Management Server we ran in to issues with alerts not being sent out. I was thinking about doing a similar implementation this time around, but with 8 cores and 32GB ram for each server this time around. What would you recommend?

    • Kevin Holman

      I always recommend 2 MS for any production deployment, to provide higher availability. For something of your size, 2 MS on VM’s, each with 4 CPU and 8GB of memory should be sufficient. Anything more than 16GB memory on the MS will be a waste in your size. For the SQL server, with all of them combined together (which is fine for this sizing) I’d want 8 CPU and 32GB RAM.

      • David

        Thanks. Documentation recommends installing the web console on the server that host the Reporting database, but with all the dbs on one server, would it make more sense to put the web console on one of the management servers?

        • Kevin Holman

          That recommendation is dumb, IMHO. It is an archaic continuation from when we had to install IIS on SSRS for the reporting web site. That ended around SQL 2008 but the models never changed. I install the web console on the first two management servers I deploy to a customer, as a standard. That gives the opportunity for high availability to the web console, and reduces authentication issues caused by authentication delegation.

          • David

            What do you think about the recommendation to host the SCOM dbs on their own server? Would it be still be unwise to host them on a server with SCCM dbs even if more resources are allocated?

  10. Kevin Holman

    The recommendation to not share with other DB’s is solid – but it depends on the size of the environment. If one database is really busy and transactional, it can rob performance from other DB’s sharing the instance. In smaller companies at smaller scale it will be OK, but you’d need to ensure you are adding a lot of resources to SQL. In general, I advise against it. SQL standard license is included in System Center licensing for this very reason…. you can deploy as many SQL standard edition instances as needed, as long as they are dedicated only to System Center.

Leave a Reply

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