My Fieldnotes are quick, unrefined notations and reflections from the field. Content may be obvious and unnecessary to some, useful to others.The main purpose is for them to be used as a searchable notebook.These Notes are not to be seen as a manual, a how-to or a set ofinstructions, but rather a collection of thoughts, reflectionsand experiences from my field-work. Abstract Upgrades from OpsMgr (SCOM) 1801 to 1807 is generally a safe operation. Can be done using Windows Update if you want to, but I would suggest only letting Management Servers, Reporting Servers and Web Console servers pre-load the update for a controlled update at a suitable time. I general, the updates goes smooth, but you still have to run the SQL-script(s) and import the updated Management Packs provided with the update. This should be done directly after updating the last Management Server. Links Official Documentation Download Location Announcement Blog What’s New! - Webinar Recording List of fixes Notes Updating the Management Servers Fairly quick update, may need a restart afterwards. On occasion, especially if the patch has to wait on shutting down the management server services (healthservice, omsdk, cshost) due to backlogs or high load, it might fail at replacing the binaries. You will notice this as the management server will go grey in the SCOM Console and you might find connectivity errors in the OperationsManager eventlog. If this happens, can be fixed by simply applying the patch again after a reboot.
A Collection of OpsMgr Upgrade Fails I’ll be frank on this one; Microsoft really dropped the ball on the 1801 setup program. No upgrade or update has been this ridden with faults and obscure errors, not even the infamous SCOM 2007 SP1 setup. And this is not only errors that will abort the installation, they will actively remove your existing SCOM Components and cause a restore, either from snapshot/checkpoint or from backup. MAKE SURE YOUR BACKUPS ARE WORKING!!! Rollbacks don’t work in 1801, at all. You have been warned. Here’s my list of the issues I’ve seen and wrestled so far. .NET 3.5 Pre-requisites Although neither SCOM 2016 nor 1801 actually has a .NET 3.5 requirement, the setup think it does. The Prerequisute checker isn’t aware though, meaning it will happily try to upgrade and then fail. And, boy, does it fail spectacularly! When the upgrade failes, it’s supposed to perform a rollback, and reading the setup log it actually do try. Unfortunatly, the “rollback” will remove any existing SCOM Roles in the server. O_o Yes, thats right. Your Management Server is no longer a Management Server! Workaround Make sure all SCOM Management Servers have .NET Framework 3.5 installed before attempting an upgrade.