Menu Close

SCOM 2019 is HERE!

Download:  https://www.microsoft.com/en-us/evalcenter/evaluate-system-center-2019

Documentation:  https://docs.microsoft.com/en-us/system-center/scom/whats-new-in-om?view=sc-om-2019

QuickStart Guide:  https://kevinholman.com/2019/03/14/scom-2019-quickstart-deployment-guide/

Official announcement:  https://cloudblogs.microsoft.com/windowsserver/2019/03/07/coming-soon-microsoft-system-center-2019/

  • 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:

image

Q&A:

  • 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 http://aka.ms/SCOM

 

Known issues in SCOM 2019 GA

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

1.  Management Server installation fails when TLS 1.0 is disabled, and prerequisites for TLS 1.2 are missing.

    • On the first management server being installed, the UI will return a failure, and in the OpsMgrSetupWizard.log (found at C:\Users\<username>\AppData\Local\SCOM\LOGS), you see the following:

    [09:41:56]:    Info:    :Info:GetLocalizedAdminGroupName: Administrators Group Name is: BUILTIN\Administrators

    [09:42:12]:    Error:    :PopulateUserRoles: failed : Threw Exception.Type: System.ArgumentException, Exception Error Code: 0x80070057

    • On the any additional management servers being installed, this will show up by hanging on “Registering Management Server” and never completing.
    • This is caused by having TLS 1.0 disabled on the SCOM management server or SQL server. If TLS 1.2 is enforced or TLS 1.0 disabled, you must FIRST install the software prerequisites for TLS 1.2 for SCOM.

2.  When using an older version of SSRS 2017 for SCOM reporting, you are unable to browse directly to http://yourreportserver.yourdomain.com/Reports  This returns a 500 error.  This is an issue in SQL 2017 Reporting Services and is resolved using build 14.0.600.1274 or later at https://www.microsoft.com/en-us/download/details.aspx?id=55252

3.  When using SSRS 2017, you might see errors on a management server for event ID 31567 with description “Failed to deploy reporting component to the SQL Server Reporting Services server” and “extension is not allowed”.  This is apparently because of a new security restriction in later builds of SSRS 2017.  The workaround is to open SQL Management Studio, connect to your Reporting Services instance, open the Properties of the instance, Advanced, and add *.* to the list for “AllowedResourceExtensionsForUpload

4.  When using a scoped user profile, you might see a “500 – Internal server error” when using a state view in the Web Console.  You also will see the same bug that was in SCOM 2016 UR6 where state views may throw an error: Incorrect syntax near the keyword ‘CREATE’.  This bug was fixed in SCOM 2016 UR7 and is scheduled to be resolved for SCOM 2019 in SCOM 2019 UR1.

image

    86 Comments

    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?

      Thanks!

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

        • Martin

          hi i even have a server 2003 with 2012 agent running in test-SCOM 2019 works fine.So the agument of not upgrading to SCOM 2019 shood not be becaus of Agent support.

          • Kevin Holman

            You are correct in that it works fine. However, that configuration is not supported by Microsoft. So it is a question of vendor support, not one of “does it work or not”.

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

        • Mark Shimonek

          I opened a support ticket and confirmed that Microsoft will not be supporting monitoring Server 2012 with SCOM 2019.

          I got half way through implementing SCOM 2016 SAC before having to stop the rollout due to the APM bug. I work for an accounting firm with a heavy reliance on SharePoint and can’t take any chances with system stability. Most people have reported good results using the old agent/NOAPM workaround but, again, there is no guarantee.

          At this point, I am unable to continue implementing SCOM 2016 SAC due to the APM bug and i am unable to implement SCOM 2019 due to the lack of support for Server 2012. What do your recommend to your customers that need to support monitoring Server 2012+ using a supported configuration? My boss is a big Naggios fan and is recommending that I look at it. Are there other solutions you would recommend?

          • Kevin Holman

            The APM bug is a non-issue when you install with No-APM. There are other workarounds that have been posted as well.

            For customers who need a “Microsoft Supported” path to monitor Windows Server 2012 – you might consider using the Log Analytics agent (MMA). This agent currently supports Windows Server 2008R2 and later, and supports connecting a wide array of SCOM management group versions.

            If you are considering Nagios, which is open sourced, why would having official support be a show stopper for SCOM? The SCOM 2019 agent works fine with no known issues on Windows Server 2012, it just wasn’t part of the supported configuration testing for SCOM 2019, and very few customers have a lot of investments in WS2012, as most moved quickly to WS2012R2. Or, you could leave the SCOM 2016 agent on WS2012, and just connect it to your SCOM 2019 deployment, if you want a “supported” agent version.

            • Kyle

              the agent that is installed when connected to azure automation workspace does not honor the NOAPM setting, and Microsoft can push an update of that agent out any time they wish. This should definitely be changed to at least honor the setting that were there previously.

        • Mark Shimonek

          “The APM bug is a non-issue when you install with No-APM. There are other workarounds that have been posted as well.”

          I have read reports of people having problems even after installing with No-APM. Call me gun shy.

          “For customers who need a “Microsoft Supported” path to monitor Windows Server 2012 – you might consider using the Log Analytics agent (MMA)”

          I read that Microsoft had discontinued the use of SCOM internally in favour of this approach. Is this what you recommend?

          • Kevin Holman

            “I read that Microsoft had discontinued the use of SCOM internally in favour of this approach. Is this what you recommend?”

            Not at all. There was one division in Microsoft IT that published that article. SCOM is still the best solution for On-prem and Hybrid scenarios – for the ability to monitor heterogeneous, multi-vendor OS, hardware, 3rd party applications, in house developed apps, storage, network devices, etc – all in one place – in my opinion.

            I recommend opening a support case with Microsoft and/or filing a request at http://aka.ms/SCOM – pushing back on the no monitoring of WS2012 with SCOM 2019. If enough customers raise this as a concern – the PG might revisit this.

    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: http://aka.ms/SCOM

        • 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
      Birdal

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

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

    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 (https://docs.microsoft.com/en-us/system-center/scom/system-requirements?view=sc-om-1807#microsoft-monitoring-agent-operating-system) 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?

      Thanks,
      Patrick

    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.

      Thanks,
      Alaa

      • Kevin Holman

        I do not like in-place OS upgrades on servers. This can leave behind things in SCOM, and adds risk. I much prefer adding new management servers with WS2016 OS to replace old ones.

        To move from SCOM 2012R2 to SCOM 2016…. with the eventual target being SCOM 2019 – I would:

        1. Build new Management servers on Windows Server 2016. Migrate any special roles/services. Retire/Remove old management servers. https://kevinholman.com/2016/02/03/checklist-removing-migrating-old-management-servers-to-new-ones/
        2. Build new SQL servers on Windows Server 2016 and SQL 2016. Migrate your databases, and use the new reporting server. https://docs.microsoft.com/en-us/previous-versions/system-center/system-center-2012-R2/hh456421(v%3dsc.12)
        3. Upgrade/Replace any Gateway servers to Windows Server 2016.
        4. Upgrade SCOM to SCOM 2019.

        • Gordon

          Hi Kevin,

          Once again, thank you for all your contributions to … well, everything.

          Would this approach work if you wanted to upgrade OS to Windows Server 2019, e.g.:

          1. Build new MS on Windows Server 2019. Migrate any special roles/services. Retire/Remove old management servers.
          2. Build new SQL servers on Windows Server 2019 and SQL 2016. Migrate your databases, and use the new reporting server.
          3. Upgrade/Replace any Gateway servers to Windows Server 2019.
          4. Upgrade SCOM to SCOM 2016 and then SCOM 2019.

          or do you need to do OS upgrades to 2019 in 2 steps?

          1. Build new MS on Windows Server 2016. Migrate any special roles/services. Retire/Remove old management servers.
          2. Build new SQL servers on Windows Server 2016 and SQL 2016. Migrate your databases, and use the new reporting server.
          3. Upgrade/Replace any Gateway servers to Windows Server 2016.
          4. Upgrade SCOM to SCOM 2016.
          5. Build new MS on Windows Server 2019. Migrate any special roles/services. Retire/Remove old management servers.
          6. Build new SQL servers on Windows Server 2019 and SQL 2017. Migrate your databases, and use the new reporting server.
          7. Upgrade/Replace any Gateway servers to Windows Server 2019.
          8. Upgrade SCOM to SCOM 2019.

          Cheers

          • Kevin Holman

            If you are stuck on in place upgrades – moving from SCOM 2012 to SCOM 2019 is a pain – you’d need to do the 2-step process… to always be in a supported configuration. Upgrade guides and supported configurations are posted in our documentation.

    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.

      Cheers!

    25. Gabriel Mora

      Hi Kevin,

      Do you think that a SCOM 2019 Agent installed on a Windows 2008 R2 server will report into a SCOM 2012 R2 running on a UR14 infrastructure? Or this is a unsupported feature.

      Please let me know what you think, since this is for a client.

      Best Regards

    26. DRON CHAKRAVORTY

      Hi Kevin,

      I have an issue with one of my customers who has installed a scom agent on server wokstation(ie winserver 2016 1607 built ), the problem is its a 4gb ram workstation and becoz of scom agent201 or 2016 the memory utilization is reaching 98 %. its a IIS server and is connected through a gateway server. THe management serverf is 2012 r2 with ur 14.I have removed the symantec antivirus from the vm and tried still no go. Could you please guide me in the right direction on how to t/s this issue.If we remove the scom agent there is no memory utilization , it seems the agent is eating up the winrm service.Any ideas would be of great help.

      • Kevin Holman

        4GB of RAM on any OS will not have much memory available for any add-on or 3rd party software (including the SCOM agent), as the OS will consume nearly all the memory available. ESPECIALLY a server running IIS. IIS consumes a lot of memory itself, competing for resources with the OS.

        For limited memory servers like this, if you want monitoring, either add more RAM, or limit what SCOM is able to discover and monitor. I would disable the seed class discoveries for all add-on management packs, so you will only discover and monitor the OS, disks, CPU, etc… This will not require as many resources.

    27. ShashiKrishna

      Hello Kevin,
      I would like to understand more on the below points:

      Upgrade to 2019 will impact any existing Management Packs and will these work post upgrade without any issues ? Need your valid inputs and supporting articles.

      What all backups we can take like Management Packs etc before we start upgrade. any reference articles. ?

      • Kevin Holman

        Any MP that worked in a previous version of SCOM upgrade-able to SCOM 2019 should work the same. There are no schema changes to the XML.

        The Upgrade guide is my recommended reading for the upgrade process, in our documentation.

    28. Bala

      Hi Kevin,

      How the licensing structure for SCOM 2019 is? If we have procured license for SCOM 1801 or 1807. Is the same license can be applied once upgrading to SCOM 2019?

      Is there any license structure change for SCOM 2019 / System Center 2019

      • Kevin Holman

        I am not a licensing expert. However, generally if you have software assurance on System Center, you can deploy any version. 1801/1807 *required* software assurance, so if you were properly licensed for those versions, moving to SCOM 2019 is a non-issue.

      • Kevin Holman

        I don’t know any specifics not have access to those decisions. My conjecture would say it likely has something to do with Itanium processors being discontinued by Intel (which was the only platform supported) and most flavors being out of support by HP in 2020. But again, that’s only a guess. If a customer required this support, they should probably keep a SCOM management group around with SCOM 2016 which is a long term supported release.

    29. Bala

      In SCOM 2019 under Monitoring tab -> Microsoft Azure folder -> Other Azure Resource Inventory, the Subscription State says “Not Monitored” for Subscription IDs in my environment.

      I was able to add all the subscriptions successfully without errors.

      Why is the subscription state reading “Not monitored”?

      How can I troubleshoot this in SCOM 2019 for Azure subscription added successfully?

      And under Monitoring tab -> Office 365 -> Active Alerts ==> getting an alert with an description “An error occurred while sending the request.Endpoints message: Authorization failed”

      Please advice to where it went wrong while configuring Office 365 subscription and Azure in SCOM 2019

    30. Benny

      Hi Kevin! This question may not fit in, but i will give it a try. 🙂 I am wondering if SCOM 2019 needs MSDTC configured when the databases runs in a A/A clustered SQL 17 environment? As i understand MSDTC is only involved in explicit distributed transactions between more than one computer. If the SCOM DB instance is running on SQL-node1 and SCOM_DW DB instance and ACS DB instance are running on the other SQL node 2, do we need MSDTC configured in cases like that. Does SCOM have explicit distributed transactions between more than one computer?

      • Kevin Holman

        No, I am not aware of any such requirements for MSDTC specific to SCOM. Do you still really use failover clusters in SQL 2017? Everyone I work with has transitioned to Always On these days.

    31. kiran kumar reddy

      We are facing issue with SCOM 2019 Webconsole where when we try to open the Dashboard link, it throws error 0x800700b7 “Cannot add duplicate collection entry of type ‘add’ with unique key attribute ‘name’ set to ‘X-Content-Type-Options’ . Unlike SCOM 1801 we do not find “Webhost” folder under “C:\Program Files\Microsoft System Center\Operations Manager\WebConsole”. Please advise if any fix available.

      • Gyan

        Hi Kevin,

        We are also facing the same issue. Is SCOM dashboard URL is deprecated on SCOM 2019 and we can access the web-console and dashboard using the same URL?

        If yes, then we have second problem. We are not able to view the Topology/Data center dashboard in SCOM web console which are created on SCOM management console.

    Leave a Reply

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