- 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 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:
[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 resolved in SCOM 2019 UR1.