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:
Q&A:
- Q: What OS versions are supported for SCOM 2019 Server roles?
- A: Windows Server 2016 and 2019. LINK
- Q: What versions of SQL server are supported for SCOM 2019 OpsDB, Warehouse, and Reporting Server roles?
- A: SQL 2016, SQL 2017, and SQL 2019 CU8 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 2008R2. LINK
- 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 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:
- 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.
[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
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 resolved in SCOM 2019 UR1.
Looking at that road map does not make me feel very happy Kevin 🙂
Talk about having second thoughts!
What’s not to like? I like everything about this!
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
Can we upgrade SCOM 2012 R2 to SCOM 2019?
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
Reading this again and not much is changing they just moved the branch release to being included in roll ups
Oh Yes, this is the right way to go.
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.
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
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.
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.
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”.
Windows Server 2012 support has been added/clarified. Only Windows Server 2008/2008R2 remain unsupported as their EOL is approaching soon.
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.
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.
Too soon? You do realize 2008 is a 12 year old operating system right? Wow, you would never make it in my shop. We are full CI/CR/CU and upgrafe our OS before 3 years is up. Bit my apps dont support new operating systems 🙁 FIND NEW APPS ITS 2020, GO CLOUD. This old way of how the line needs to die. Ive been doing this for 21 years now and SCOM for 10 and there are no other monitoring solutions with this much power at such low cost period. Get with the times man
No support for monitoring 2012?. Looks like I won’t be upgrading for a while.
Windows Server 2012 support has been added/clarified. Only Windows Server 2008/2008R2 remain unsupported as their EOL is approaching soon.
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?
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.
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.
This will work as a temporary workaround – https://techcommunity.microsoft.com/t5/Core-Infrastructure-and-Security/SCOM-and-APM-the-simplest-workaround/ba-p/323740
You should have fully read the documentation because the APM issue is a mute point, is not a bug and has a fully supported workaround.
“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?
“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.
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.
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.
Read. The. Documentation people
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.
Does it work? Yes. Is it supported? No – as this scenario received no testing.
Hello, you can use new agents this works. But only 64bit systems.
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?
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.
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?
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.
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?
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.
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?
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…
By the way we currently have 1807 and have this problem.
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
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.
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.
Thanks a lot for the input Kevin, always a great help!
I poked around looking for the upgrade guide/documentation and couldn’t find it.
https://docs.microsoft.com/en-us/system-center/scom/deploy-upgrade-overview?view=sc-om-2019
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!
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.
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
The migration would be the same as any upgrade…. deploy new management servers to replace the old ones. Migrate resources to the new management servers. Uninstall old management servers. Then perform a DB migration to new SQL servers if required, or perform an in place upgrade of SQL.
I have this for the MS: https://kevinholman.com/2016/02/03/checklist-removing-migrating-old-management-servers-to-new-ones/
The DB migration is part of our regular documentation.
Hi Kevin,
thank you for quick reply. I’ll check your points in the next weeks and create a migration plan.
Best regards
Birdal
Pingback:SCOM 2019: Fast track setup on an Azure VM – blog.johnjoyner.net
Pingback:SCOM 2019: Fast track setup on an Azure VM – blog.johnjoyner.net
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?
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.
Ok, thank you Kevin!
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?
Discovered (after reading the comments on https://kevinholman.com/2018/10/31/ur6-for-scom-2016-step-by-step/) that following the steps in the known issues section (but using the 1807 instead of the UR6 update to get the DLL) can workaround this issue.
Pingback:SCOM 2019 vs Azure Monitor: Which one to choose?-AnalyticOps Insights
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.
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” ?
Hi, thank you for this post.
Do we have any idea when the 500 HTTP error on reporting server will be fixed?
Thank you.
Hi Kevin,
do you have already experience running an older agent version on RHEL6 communicating to 2019?
Thanks,
Patrick
I don’t, sorry.
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
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.
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
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.
Thank you! appreciate your prompt response.
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.
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.
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!
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
SCOM will be always much more worse!
SCOM 2019 includes not only old bugs, but also new bugs in Web Console, and in Operartions Console!
https://social.technet.microsoft.com/Forums/en-US/3ad279ef-b007-4d2b-a1bc-b73047802b6c/bugs-paradise-named-microsoft-scom?forum=operationsmanagergeneral
Best regards
Birdal
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.
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.
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. ?
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.
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
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.
Hi Kevin,
I noticed from Microsoft’s documentation on supported Linux/Unix OS and found out that they have removed the support for HP-UX! It was there for SCOM 1807 but not present for SCOM 2019. Is this intended? I haven’t downloaded yet the MP for SCOM 2019 unix/linux but do you see any scx or oms agent for HP-UX?
https://docs.microsoft.com/en-us/system-center/scom/plan-supported-crossplat-os?view=sc-om-2019
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.
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
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?
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.
Thank you for answer the MSDTC question. Well yep were still in the SQL Old School here 😉
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.
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.
Does SCOM 2019 work with the Servicenow 2016 connector? Are you aware of anything in pipeline for official connector to Servicenow ?
Hi Kevin, Thanks for this great article. I have one little question that is not answered in the Q&A.
We are running SCOM 1807, so we have to upgrade to 2019 because the Semi-Annual Cycle is ending. Because our Windows OS (2012R2) is not supported anymore, we decided to install new servers instead of upgrading both the OS and SCOM.
Our approach is that we add our new servers to the excisting Management Group 1 by 1, and then delete the older MS.
Now the question is, do I have to install those new servers as SCOM 1807 first, and then upgrade them all at the same time. Or can I install them as SCOM 2019 right away, and later delete our SCOM 1807 MS’s. So to summarize my question, can SCOM 1807 and SCOM 2019 Management Servers co-excist in 1 Management Group. The reason why I have my doubts is because I don’t know what kind of Database changes will be made and if this will be a problem or not.
Thanks for your reply,
Raoul
You must install them as 1807, then start the upgrade. I would install all the new management servers, then shift roles, then remove the old management servers. I have a checklist which might help: https://kevinholman.com/2016/02/03/checklist-removing-migrating-old-management-servers-to-new-ones/
Thanks for the advice!
I don’t understand. The download link at the top of the page goes to an Evaluation type. I don’t want to evaluate. I want to upgrade directly from 1807 to 2019 in place. Is that evaluation link the same .exe to upgrade a licensed 1807?
You should get your official media from an official source then. There is almost zero Microsoft licensed software available for download that isnt eval. Every company has an internal source for getting access to their licensed software.
Hi Kevin,
We are managing SCOM infrastructure with 2000 agents (Includes Linux OS) managed with 10 Management Servers and also monitoring network devices. We are moving on-premise workloads to Azure.
And we are in-need of moving\Migrating SCOM 2012 R2 to Azure.
Please advice the best approach & practice to be followed to Migrate SCOM 2012 R2 to Azure and also share ideas.
Hi Kevin,
We are currently on SCOM 2007 R2 with Win OS 2008R2/Win 2012 agents reporting to host, we are planning on a upgrade near quick. which version would you recommend.
Also, we will be retiring all of the Win 2008 OS servers and replaced by 2016 Win OS.
I would do a simple side-by side migration to a new SCOM 2019 environment.
However those 2007R2 agents are not upgrade compatible…. so your agent strategy will be interesting to automate.
Hi Kevin,
First of all – thanks for your blog. Your articles over the years have been a constant source of help and knowledge.
We’ve got a reasonably small environment (approx. 160 VM’s), and we’ve been running the full System Center suite since 2009/10 – all versions along the way since 2007.
We upgraded to 2019 in the middle of last year and, doing it in a bit of a rush, ploughed ahead and worked out installation issues as we went. Anyhow – long story – but I’ve now got time to go back and try and tidy things up and one thing we have had problems with constantly is DPM crashing/slowness etc – in part because during the install we could not share the SSRS (2017) instance with other SC components, and with now SSRS it only lets you install a single instance, and hence we just installed a local SQL version and SSRS for DPM (on the DPM server) -> leading to a lot of the performance issues.
Looking again at it now – it still appears to be the same issue. You can only install a single default instance of SSRS 2017 on a server, and between the various System Centre components (DPM, OM, CM) there does not appear to be any way to utilise a shared SSRS installation – so the only option appears to be to build multiple VM’s just for running SSRS. In our case we are not too concerned about the performance of the reporting services, it’s more a practicality issue of the additional resource requirements (CPU/RAM etc) and maintaining multiple servers for what we have had running on a single VM historically (and performance wasn’t an issue).
So after all that, my question is – have I got this wrong and/or is it possible to get each of the SSRS requirements for the System Center suite running on the same VM with the latest versions?
Cheers
I’m not sure we ever supported sharing SSRS, and it is certainly not recommended in most cases. Especially for Operations Manager, as SCOM requires a dedicated SSRS deployment, because we remove the built in security model for SSRS and replace it with a customized security extension to make it integrate with our console and role based access. I would recommend each component of SSRS use a dedicated server, or install SSRS on your existing SQL server. For instance, in SCOM for smaller environments, I always install SSRS on the same SQL server hosting the OpsDB and DW. SQL standard licensing is included with system center, so the only real TCO here is a VM, if you are unwilling or unable to colocate SSRS on the SQL server itself.
Have you seen anything suggesting that SQL 2019 might be supported currently or soon?
Operations Manager 2019 supports SQL 2019 with CU8
Fixed article!
Kevin, love your articles
Engineers need to stop complaining about what does and doesnt work. Again, read the documentation it will answer all your questions and concerns. If not, Kevin will. If you do your due diligence before hand this thread wouldnt be so long. I reiterate to my engineers and architects READ! READ! READ! its part of the nature of the field. If you cant carve out an hour to read and note then you need to consider time management and prioritization. Get lunch 1 day a week, sit at your desk and read. It will save you a world of headaches and others as well. Never stop learning. Learn something new every day or consider a new field of work 🙂
Hi Kevin,
I already have SQL Server 2016 but it is hosted on Windows Server 2012 R2. This is supported as per documentation for SQL Server.
However, I’ve read some things that imply this is not supported by SCOM 2019 and that I will have to upgrade this SQL VM OS to 2016 minimum. Is this the case?
The supported configuration is here: https://docs.microsoft.com/en-us/system-center/scom/system-requirements?view=sc-om-2019#software-requirements-for-operations-manager-components
Windows Server 2016 is a minimum requirement for the OS for any SCOM server role per the document above, for SCOM 2019.
Hello Kevin,
If i’m opting for a side by side migration, Can i dual home linux agents ?
I have heard that people have gotten this to work, however, I have never worked with it so I do not know.
“A generic error occurred in GDI+.”
I cant seem to figure out what is causing this issue and/or how to resolve it.
Seems like it should be a pretty simple fix as it appears to be a permissions-related error.
The error appears only when I click on ‘Monitors’ under “Authoring > Management Packs”
Additional Inforation:
Application: Operations Manager
Application Version: 10.19.10050.0
Severity: Error
Message:
System.Runtime.InteropServices.ExternalException (0x80004005): A generic error occurred in GDI+.
at System.Drawing.Image.Save(String filename, ImageCodecInfo encoder, EncoderParameters encoderParams)
at Microsoft.EnterpriseManagement.Internal.UI.Authoring.Views.MonitorDetailsView.c__DisplayClass1.b__0(Object param0, ConsoleJobEventArgs param1)
at Microsoft.EnterpriseManagement.Mom.Internal.UI.Console.ConsoleJobExceptionHandler.ExecuteJob(IComponent component, EventHandler`1 job, Object sender, ConsoleJobEventArgs args)
Have you updated to UR2?
Is this when running the console on a management server, or anytime you open a console anywhere?
Hi Kevin, I have the same issue than Andy, and I receive that “Generic error in GDI+” when I execute a Generic Microsoft Availability report on a console (management server or PC), and I click on “Downtime periods”. It shows the data and metrics but the charts image fails. We have SCOM 2012 R2 (7.1.10226.0) . We know that it is pretty outdated, but it worked fine before and we got this issue after migration of SQL server to another one (same version but clean installation of SQL and SSRS). Could you help us? Thanks!!!
From the docs I’ve seen on Microsoft’s site for Endpoint and Configuration Manager, it appears that Microsoft isn’t selling any new licenses anymore for SCOM 2019 and only permits it to be used if previously purchased. Is this true. what if a public sector software assurance customer already has licenses for SCOM in use and want to deploy additional SCOM at different sites?
Hi Kevin,
Is it still possible to use SCOM2012 or 2016 agents to monitor Windows 2008R2 servers, connecting them to our new SCOM2019 environment?
Thanks.
Yes. I generally recommend using a SCOM 2016 agent as that is the “most current”. But I have tested both.
Hi Kevin,
I’m using SCOM 2019, I knew that SCOM 2019 is supported windows server 2012 R2, 2012 . However I added windows server 2012 R2 , everything is fine , state is healthy , except Windows Operating System column get status “Not Monitored”. I don’t know why. Can you help me fix it ? I have some windows OS 2012 R2 cannot upgrade 2016 due to specific servers. I also imported MP latest from microsoft link.
The most common reason for that is you are missing the Operations System Management pack for Windows Server 2012/R2. https://www.microsoft.com/en-us/download/details.aspx?id=9296
Or, you have the MP imported, but have not waited long enough for the OS to be discovered.
Or, there is an issue where the MP discovery is not working or running. (very rare)
Just started a new position, working on cleaning up a new side by side installation of 2019. Noticed in the admin section that the Operations Consoles have all the old 2012 severs list\ed. The 2012 management servers have been decommd but the DNS record is still up, any chance that is the problem? there doesn’t appear to be any way to remove them from the console.
There might be a remnant leftover from them – do they show up under “Agent Managed” or under “Management Servers” view in Administration? If so – delete them.
We recently updated SCOM 2019 management servers with UR3, and we are installing a web console on a separate server. We got an error during installation on web console “:Error:The management server is a different version than the current setup build. Please use a different management server or the correct version of setup. Server Version: 10.19.10475.0”. We cannot roll-back the management servers since it is already on production. Is there a way to install web console without checking the version?
This is covered in my blog post for UR3, in the KNOWN ISSUES section:
https://kevinholman.com/2021/03/31/ur3-for-scom-2019-step-by-step/
HI Kevin,
We need to move the SCOM on prem instance to SCOM VM servers on Cloud. What approach should we take.
Hi Kevin,
We are on SCOM 2019 in my work environment. The current setup with the SCOM Datawarehouse and Ops Mgr DB is 2 node clusters for each database. My SQL team wants to basically get rid of one of the clusters due to an issue it was experiencing and move both of those nodes from that cluster to the Ops Mgr DB cluster and those two nodes will have a seperate role then what the 2 nodes in the Ops Mgr cluster have. 2 nodes for the Ops Mgr DB and two nodes for the Datawarehouse on the same SQL cluster. Is that possible?
Each node and instance is still using the same names so it’s not like its performing a DB move from my understanding, so Im assuming that there wont be any issues with the SQL team doing this.
I hope I am explaining this in an understandable manner.
Thanks in advance for any help. I looked at the Microsoft SCOM 2019 documentation and didn’t see anywhere that said this wasn’t supported. I tried searching online and saw someone ask this on Reddit but I dont see any replies to the post so I wanted to ask you on here.
Thanks!