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, 2012, and Windows 10.
  • Note:  the SCOM 2019 agent does not support Windows Server 2008 nor Windows Server 2008R2LINK
  • 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.  (It is likely possible that older versions of SCOM will communicate with SCOM 2019, but it isn’t a tested and supported scenario outside of what is documented)  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


Known issues in SCOM 2019 GA

The following are some issues brought to my attention from the community:

  1. When using SSRS 2017 for SCOM reporting, you are unable to browse directly to  This returns a 500 error.
  2. When using a scoped user profile, you might see a “500 – Internal server error” when using a state view in the Web Console.


  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 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.

    • Kevin Holman

      Windows Server 2012 support has been added/clarified. Only Windows Server 2008/2008R2 remain unsupported as their EOL is approaching soon.

  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

      Windows Server 2012 support has been added/clarified. Only Windows Server 2008/2008R2 remain unsupported as their EOL is approaching soon.

  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 poor, and outdated, IMHO. It is an old 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.

    • David

      Am I correct in assuming this applies to instances and not servers? Could we put the SCOM dbs on their own instance, but host them on a cluster that houses the SCCM db instance?

  11. John Terry

    Does the Web application transaction monitor retry count works now on this new version?

    80% of our monitoring is of those monitors and the bug of the retry count being ignored is a major pain of the product…

    • Kevin Holman

      It isnt really a bug, as it works exactly as designed. It is a retry count of the module, not of the workflow. Customers desire a retry count of the entire workflow after “x” number of retries – but that was never in the original design. I understand where you are coming from, however. Most customers have migrated away from the transaction monitors, to the Web App availability solution (which is much simpler) or using a custom solution which gives this capability to URL’s. If you want to see this specific enhancement to the Web Transaction monitor, I recommend formally requesting it here:

      • John Terry

        Never knew this was working as intended, honestlythought it was a bug, but even so, what do you mean it’s a retry count of the module and not of the workflow? I feel it isn’t retrying again on anything, we have even tested with wireshark and never see it retry after a failure, it just triggers an alert on first try.

        • Kevin Holman

          Hi John,

          The module attempts a connection to the URL, and waits for a response. If the request timed out/fails, it will immediately retry, up to the number of times in your configuration. However, customers looking at the UI assumed this was a retry of the workflow, meaning, check the URL every 2 minutes, but only generate an alert after 3 attempts of the workflow (6 minutes) have passed. It doesn’t work this way – it is the number of times the module will retry the unique URL connection, on a single execution of the workflow. I know it is misleading, and customers have requested this be changed to support retry count on the entire workflow, but the right way to get this done is for a customer to open a support case, and file this as a bug/DCR (design change request) for it to be considered.

  12. Aaron Phillips

    This is good news in the long term, but it now means i have until January to get Windows 2016 or 2019 up to upgrade SCOM before January!

    • Kevin Holman

      I assume you are running 1807 – which has 18 months of support – and therefore will expire in Jan 2020.

      This does give you the better part of a year to upgrade your OS and SQL versions for a supported SCOM 2019 upgrade. But I will agree – this is one of the reasons I advised my larger customers not to get on the semi-annual channel…. as Microsoft has a long history of dropping support for older OS and SQL versions, forcing you into OS and SQL upgrades much faster than existing planned cadences. I preferred LTSC on the old model, as even a forced change every 3 years can be more disruptive than customers would like.

  13. Birdal

    Hi Kevin,
    we deployed SCOM 1807 on Windows Server 2012 R2. Now, we must use Windows Server 2016 or Windows Server 2019 to deploy SCOM 2019. We have relatively complex SCOM environment.
    Is there any roadmap / steps for MIGRATION from SCOM 1807 to SCOM 2019?
    Best regards

  14. Pingback:SCOM 2019: Fast track setup on an Azure VM –

  15. Pingback:SCOM 2019: Fast track setup on an Azure VM –

  16. Martin

    Hello Kevin!

    The issues with SSRS 2017 giving 500 error, (i wish i read that earlier), about the known issues that you wrote. I have been spending ALOT of time trying to find out why/what i have possible done wrong…

    Are they any existing workarounds or any fix for that yet?

    Can you also please tell what software prereqs there is for a Windows 2016 server that should be a dedicated SCOM 2019 Report server?

    • Kevin Holman

      Not yet that I know of – it really looks like a SSRS issue, not SCOM – so it might be a wait until SSRS update comes. We will see.

      Software prereqs are all covered in my quickstart. Nothing required for a Report server except SSRS I believe.

  17. Ben M

    I’m still getting the scoped user “incorrect syntax near the keyword ‘create’” in the regular (not web) console, like what happened with SCOM 2016 UR6. Is this still a known issue?

  18. Pingback:SCOM 2019 vs Azure Monitor: Which one to choose?-AnalyticOps Insights

  19. Jason

    Kevin, the official doco for 1801/1807 ( suggests there is no agent support for Windows Server 2019, but there is for SCOM 2016 and SCOM 2019. Do you know if this is going to change?

    Moving from 1807 to SCOM 2019 isn’t really an option for us in the short term, yet our server guys are starting to develop Windows 2019 builds already.

    • Kevin Holman

      I don’t believe there is much effort to support Windows Server 2019 agents on SCOM 1807. While it works just fine, and nothing was added to SCOM 2016 in order to support WS2019 – the semi-annual channel was never designed to “add support” for anything. The semi annual channel was a commitment to upgrading your environment every 6 months. If you want a new feature or support – you move to the next version. 1807 has a maximum support lifecycle of 18 months, and expires in January 2020. The expectation is that customers would upgrade to SCOM 2019. I understand that with new versions – we drop support for old stuff (OS versions and SQL), and force support for new stuff (OS versions and SQL) and this was the reason I always advised my customers not to adopt the Semi Annual Channel unless they were committed to any change Microsoft came out with. This was always the risk with SAC.

      My advice is to upgrade to SCOM 2019. That is the natural path for anyone on the SAC. If you Migrate to SCOM 2019 – you might have a short term issue of old agents not supported. If you stay where you are at, your WS2019 agents aren’t supported and support for your version will expire soon. If you rebuild your environment as SCOM 2016 – you have the most options for long term support, but also the biggest pain. Personally, I’d just move to SCOM 2019 and leave old agents on WS2008 servers, until they are gone (which also lose support in Jan 2020)…. as you cannot stay on 1807 and have any support at all for much longer.

      So my question to you is – why is SCOM 2019 “not really an option” ?

  20. Alex Semibratov

    Hi, thank you for this post.
    Do we have any idea when the 500 HTTP error on reporting server will be fixed?

    Thank you.

  21. Patrick Seidl

    Hi Kevin,
    do you have already experience running an older agent version on RHEL6 communicating to 2019?


  22. Alaa

    Hi Kevin,

    We have SCOM 2012 R2. Several Management Servers running on Windows 2012 R2 Servers. SQL is 2012. We would like to upgrade our SCOM to 2019. So as a first hop, is it supported (after doing in-place upgrade of SCOM to 2016) to do an in-place upgrade of the OS to 2016? as this approach is expected to have less effort and time required to achieve.. Appreciate your advice.


  23. Emily Braun

    I have been reading a these comments and I do see the work around, but I have a question. We upgraded to 2019 and did not have any issues before then. Now that we have upgraded I have a user that tries to go to the website and gets an error that states “Incorrect sytnax near the word “create””.
    I am able to get to the website fine with my credentials, and I know nothing changed as far as credentials in the software. Is this part of the bug, or am I missing something else.

    • Kevin Holman

      Hi Emily –

      This is a known issue, and related to the bug noted in the article – for scoped users. This was first found in SCOM 2016, and was fixed in SCOM 2016 UR7. It should be slated to be fixed in SCOM 2019 UR1. There is likely a workaround or a private fix available, and I recommend opening a support case with Microsoft to get a definitive answer to this.

  24. Martin

    Hello! I think i may have found out an alternative way to migrate (side by side) from Scom 2012R2 to Scom 2019. Well it seems to work, because we just did it.

    In our old Scom 2012 environment we have 2008R2 OS on the MGMT Servers. Therefore we can not (inplace) upgrade to Scom 2016 because it require 2012 or later OS. With the new Scom 2019 environment we can not either upgrade the old 2012R2 agents because the new Scom 2019 agent requires a Scom 2016 agent or later to to upgrade.

    I also know that 2008R2 OS is not really supported but i have read that the the old 2012R2 agents on 2008R2 should be able to report fine to Scom 2019. I tested it first and correct it reported just fine to Scom 2019. That got me thinking. If this works, what about the Scom 1801 agent who is compatible with Scom 2012R2. So what if we first upgrade our Scom 2012R2 agents to 1801. Did it and it worked well. Still reporting well to the old Scom 2012R2 environment.

    After that we push installed the new Scom 2019 agent from the Scom 2019 environment to the servers with the Scom 1801 agent. It worked and now the Scom 2019 agent is installed on our 2008R2 servers and it reports fine to both Scom environments 2012R2 and 2019.

    In this way we can now actually have our old SCOM environment up and running when we configure the new one.

    Whit this method we can avoid the other way, who is 1. First install a Scom 1801 environment and (inplace) upgrade it to 2019. 2. We now dont need to first install Sql 2016 for 1801. We can instead go directly to Sql 2017 who is our choise for Scom 2019. I guess this method is not the supported one, but it really works and that is the most important thing now. We are soon closing the old Scom environment. Also all the 2008R2 servers are on there way out from our domain. That is good in case of future upgrade for the 2019 agent that maybe can give problems on 2008R2.


Leave a Reply

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