KB Article for OpsMgr: https://support.microsoft.com/en-us/help/4514877/update-rollup-8-for-system-center-2016-operations-manager
Download catalog site: http://catalog.update.microsoft.com/v7/site/Search.aspx?q=4514877
Updated UNIX/Linux Management Packs: https://www.microsoft.com/en-us/download/details.aspx?id=29696
Recommended hotfix page: https://kevinholman.com/2009/01/27/which-scom-hotfixes-should-i-apply/
Key fixes:
- Fixed: CPU Spike issues because of workflows running on all agents at the same time is addressed through script optimization and removing the sync time.
- Fixed: Maintenance mode state changes which are recorded in MaintenanceModeStage table requires grooming when table grows. If the table is large, grooming takes longer and the operation times out with SQLTimeOut exception.
- Fixed: If a group is renamed in a Management pack, then console shows the new value but Powershell command Get-SCOMGroup returns the old name of group. Database Updates functionality was inconsistent for SCOM group renaming through MP and SCOM Console.
- Fixed: Reporting – Historical data does not appear, if input reporting end time is before group creation time. With this fix, historic data for a group (if data is available for objects in the group) would be displayed irrespective of group creation time.
- Fixed: If the registry key under “Computer\HKey_Local_Machine\Software\Microsoft\Microsoft Operations Manager\3.0\Setup\UseMIApi” is set and a Unix/Linux Script task without a parameter is executed then this task fails.
- Improvement: Sometimes SQL stored procedure “p_SelectForNewTypeCache” takes long time to complete, and SDK service fails to start. This is fixed and above SQL stored procedure will complete faster now.
- Fixed: In some customer scenarios where SCOM monitors a large number of virtual machines hosted on a single Host, the disk I/O could possibly spike once per hour. Every hour the HealthService.exe of each Virtual machine writes to the page file. If a large number of VM’s all boot/initialize at the same time, this could cause the paging to occur simultaneously. A registry key and a set of values are now provided to disable the memory trimming and control the frequency if impacted. The general recommendation is to disable Memory trimming in the SCOM agent, by creating these registry keys on all agents – if you are impacted by this. This will defer to the OS for memory trimming on demand.
Key: HKLM\SOFTWARE\Microsoft\Microsoft Operations Manager\3.0\Setup\MemoryTrimming
REG_DWORD Decimal Value: Enable
SCOM default existing registry value: (not present)
SCOM default value in code = 1
Enable = 0 (trimming is disabled) Enable = 1 (trimming is enabled)REG_DWORD Decimal Value: DelayInSeconds
Time period in seconds the agent waits after initializtion to start trimming
SCOM default existing registry value: (not present)
SCOM default value in code = 120REG_DWORD Decimal Value: PeriodInSeconds
Recurring period in seconds at which the working set should be trimmed
SCOM default existing registry value: (not present)
SCOM default value in code = 3600
Minimum value = 3600 Maximum value = 4294967295
NOTE: I get this question every time we release an update rollup: ALL SCOM Update Rollups are CUMULATIVE. This means you do not need to apply them in order, you can always just apply the latest update. If you have deployed SCOM 2016 and never applied an update rollup – you can go straight to the latest one available.
Let’s get started
From reading the KB article – the order of operations is:
- Install the update rollup package on the following server infrastructure:
- Management Servers
- Audit Collection Server (ACS)
- Web Console Servers
- Gateway Servers
- Operations Console Servers
- Reporting Server
- Apply SQL scripts
- Manually import the management packs
- Apply Agent Updates
- Update Nano Agents
- Update Unix/Linux MP’s and Agents
WHOA Nelly
Before we get started – you should verify that your SQL rights are correct to support Scheduled Maintenance Mode. When SCOM 2016 shipped this was not configured, and subsequent updates in UR1, UR6, and now UR8 changed the way this works. Scheduled MM still has a dependency to the SQL Agent, to calculate the next run time of a schedule. However, the schedules themselves are now contained in the OperationsManager database to better support AlwaysOn and Database move scenarios.
Essentially, you need to:
- Open SQL Management studio
- Connect to the SQL instance that hosts your OperationsManager database
- Select your SQL login for the Management Server Action account, choose properties.
- Select “User Mappings”, and Add/verify a user mapping to the MSDB database.
- In this user mapping – select public, SQLAgentOperatorRole, SQLAgentReaderRole, SQLAgentUserRole
- Now, open the properties for the SQL login for the SDK/DAS account.
- Select “User Mappings”, and Add/verify a user mapping to the MSDB database (you may already have one).
- In this user mapping – select public, SQLAgentOperatorRole, SQLAgentReaderRole, SQLAgentUserRole
Note: If you have never configured these rights, you might see failures in the SCOM logs about not being able to synchronize scheduled maintenance jobs, or you might see issues with creating new Schedule Maintenance failing, locking up the console, or even creating large numbers of duplicate jobs.
Repeat this on any SQL instances that are part of a SQL AlwaysOn Availability Group for your OperationsManager database, if applicable.
Management Servers
It doesn’t matter which management server I start with. I simply make sure I only patch one management server at a time to allow for agent failover without overloading any single management server.
I can apply this update manually via the MSP files, or I can use Windows Update. I have 2 management servers, and I always recommend a manual installation on management servers, I DO NOT recommend ever using Windows Update. My first management server holds 3 roles, and each must be patched: Management Server, Web Console, and Console.
The first thing I do when I download the updates from the catalog, is copy the cab files for my language to a single location, and then extract the contents.
Once I have the MSP files, I am ready to start applying the update to each server by role.
***Note: You MUST log on to each server role as a Local Administrator, SCOM Admin, AND your account must also have System Administrator role to the SQL database instances that host your OpsMgr databases.
My first server is a Management Server, Web Console server, and has the OpsMgr console installed, so I copy those update files locally, and execute them per the KB, from an elevated command prompt:
This launches a quick UI which applies the update. It will bounce the SCOM services as well. The update usually does not provide any feedback that it had success or failure…. but you MIGHT see a reboot prompt. You can choose “No” and then reboot after applying all the SCOM role updates.
You can check the application log for the MsiInstaller events to show completion:
Log Name: Application
Source: MsiInstaller
Event ID: 1036
Description: Windows Installer installed an update. Product Name: System Center Operations Manager 2016 Server. Product Version: 7.2.11719.0. Product Language: 1033. Manufacturer: Microsoft Corporation. Update Name: System Center 2016 Operations Manager Update Rollup 8 Patch. Installation success or error status: 0.
You can also spot check a couple DLL files for the file version attribute:
Next up – run the Web Console update:
Lastly – install the Console Update (make sure your console is closed):
You can check help/about in the console:
Additional Management Servers:
Apply the UR updates for Server, Web Console, and Console roles as needed for all additional management servers. You should only patch one management server at a time to allow for graceful failover of agents and to keep resource pools stable.
Updating ACS (Audit Collection Services)
One of my management servers is also my ACS Audit Collection Server role. I will apply the update for that:
Note the above image states “Operations Manager 2012”. This is a known issue. Ignore it.
Updated files:
Updating Gateways:
Generally I can use Windows Update or manual installation. I will proceed with manual:
The update launches a UI and quickly finishes.
Then I will spot check the DLL’s:
I can also spot-check the \AgentManagement folder, and make sure my agent update files are dropped here correctly:
***NOTE: You can delete any older UR update files from the \AgentManagement directories. The UR’s do not clean these up and they provide no purpose for being present any longer.
Updating Reporting:
On your server that hosts the SCOM Reporting role, run the update:
Apply the SQL Scripts
In the path on your management servers, where you installed/extracted the update, there are TWO SQL script files. One for the Operations Database, and one for the Warehouse Database.
%SystemDrive%\Program Files\Microsoft System Center 2016\Operations Manager\Server\SQL Script for Update Rollups
(note – your path may vary slightly depending on if you have an upgraded environment or clean install)
Operations Database update:
First – let’s run the script to update the OperationsManager (Operations) database. Open a SQL management studio query window, connect it to your Operations Manager database, and then open the script file (update_rollup_mom_db.sql). Make sure it is pointing to your OperationsManager database, then execute the script.
You should run this script with each UR, even if you ran this on a previous UR. The script body can change so as a best practice always re-run this.
Click the “Execute” button in SQL mgmt. studio. The execution could take a considerable amount of time and you might see a spike in processor utilization on your SQL database server during this operation.
I have had customers state this takes from a few minutes to as long as an hour. In MOST cases – you will need to shut down the SDK, Config, and Monitoring Agent (healthservice) on ALL your management servers in order for this to be able to run with success.
IF YOU GET AN ERROR – STOP! Do not continue. Try re-running the script several times until it completes without errors. In a production environment with lots of activity, you will almost certainly have to shut down the services (sdk, config, and healthservice) on your management servers, to break their connection to the databases, to get a successful run.
Data Warehouse database update:
Next – let’s run the script to update the OperationsManagerDW (Warehouse) database. Open a SQL management studio query window, connect it to your OperationsManagerDW database, and then open the script file (UR_Datawarehouse.sql). Make sure it is pointing to your OperationsManagerDW database, then execute the script.
You should run this script with each UR, even if you ran this on a previous UR. The script body can change so as a best practice always re-run this.
Manually import the management packs
There are 36 management packs in this update! Most of these we don’t need – so read carefully.
The path for these is on your management server, after you have installed the “Server” update:
\Program Files\Microsoft System Center 2016\Operations Manager\Server\Management Packs for Update Rollups
However, the majority of them are Advisor/OMS, and language specific. Only import the ones you need, and that are correct for your language.
This is the initial import list:
What NOT to import:
The Advisor MP’s are only needed if you are connecting your SCOM environment to Microsoft Operations Management Suite / Log Analytics cloud service, which is very rare (Previously known as Advisor, and Operations Insights)
DON’T import ALL the languages – ONLY ENU, or any other languages you might require.
The Alert Attachment MP update is only needed if you are already using that MP for very specific other MP’s that depend on it (very rare)
The IntelliTrace Profiling MP requires IIS MP’s and is only used if you want this feature in conjunction with APM.
So I remove what I don’t want or need – and I have this:
#Note: If the “Install” button is greyed out – this means you might already have one or more of these MP’s with the same version installed. Find it by scrolling through each one, the console will tell you if you already have the same version.
Update Agents
Agents should be placed into pending actions by this update for any agent that was not manually installed (remotely manageable = yes):
If your agents are not placed into pending management – this is generally caused by not running the update from an elevated command prompt, or having manually installed agents which will not be placed into pending by design, OR if you use Windows Update to apply the update rollup for the Server role patch.
You can approve these – which will result in a success or failure message once complete:
You normally can verify the PatchLevel by going into the console and opening the view at: Monitoring > Operations Manager > Agent Details > Agents by Version
I *strongly* recommend you take a look at this community MP, which helps see the “REAL” agent number in the Administration –> Agent Managed view console:
https://kevinholman.com/2017/02/26/scom-agent-version-addendum-management-pack/
And my SCOM Management Group Management MP, which will help show you REAL UR levels based on a better discovery. This has long been a pain point in SCOM:
https://kevinholman.com/2017/05/09/scom-management-mp-making-a-scom-admins-life-a-little-easier/
Update UNIX/Linux MPs and Agents
You can get the current Unix/Linux MP updates here: https://www.microsoft.com/en-us/download/details.aspx?id=29696
The current version of these MP’s for SCOM 2016 UR8 is 7.6.1092.0 – and includes agents with version 1.6.2-343
Make sure you download the correct version for your SCOM deployment version:
Download, extract, and import ONLY the updated Linux/UNIX MP’s that are relevant to the OS versions that you want to monitor. Here is the FULL list:
In my environment – I only monitor RedHat and Universal Linux distributions, so this is my pared down list of MP’s to update:
This will take a considerable amount of time to import, and consume a lot of CPU on the management servers and SQL server until complete.
Once it has completed, you will need to restart the Healthservice (Microsoft Monitoring Agent) on each management server, in order to get them to update their agent files at \Program Files\Microsoft System Center 2016\Operations Manager\Server\AgentManagement\UnixAgents
You should see the new files dropped with new timestamps:
Now you can deploy the Linux agent updates:
Next – you decide if you want to input credentials for the SSH connection and upgrade, or if you have existing RunAs accounts that are set up to do the job (Agent Maintenance/SSH Account)
If you have any issues, make sure your SUDOERS file has the correct information pertaining to agent upgrade:
https://kevinholman.com/2016/11/11/monitoring-unix-linux-with-opsmgr-2016/
Update the remaining deployed consoles
This is an important step. I have consoles deployed around my infrastructure – on my Orchestrator server, SCVMM server, on my personal workstation, on all the other SCOM admins on my team, on a Terminal Server we use as a tools machine, etc. These should all get the matching update version.
Review:
Now at this point, we would check the OpsMgr event logs on our management servers, review the Management Group Health dashboard, check for any new or strange alerts coming in, and ensure that there are no issues after the update.
Known Issues:
1. The “Operations Manager” Event log on SCOM servers is forced back to the default value of 16MB after you apply UR8. If you customized this value on Management Servers (and I recommend doing this) to a larger value such as 60-100MB, this value will be set back to 16MB. This will result in a Management Server event log that is too small for best practices, and you should set this back to your previously modified value.
2. Customized registry values might be wiped out by UR8 and reset to default values. For instance, one of the things I change on SCOM *Management servers*, is the registry value at “HKLM\SYSTEM\CurrentControlSet\services\HealthService\Parameters\Persistence Checkpoint Depth Maximum”. This is forced back to a default value of 20971520 after you apply the Update Rollup. I recommend this value be set to 104857600 on SCOM management servers. There could be others. If you customize Registry settings on SCOM Agents or Management Servers, you should verify them after applying any Update Rollup as part of your testing, and make a plan to automate fixing them if necessary.
3. UR8 will overwrite the registry path at “HKLM\SOFTWARE\Microsoft\Microsoft Operations Manager\3.0\Setup\InstallDirectory” and modify this path to the C: drive, even when the SCOM Agent is installed to some other drive letter, such as the E: drive. This can break some automations. You should correct this registry entry via MP automation if this affects you.
4. The ACS update shows “Operations Manager 2012” in the UI but is actually for SCOM 2016.
MemoryTrimming Issue – Wow! I had logged a ticket about this exact behaviour over a year and a half ago. Nice to see it was finally acknowledged.
Hi Kevin,
Great article, as always. I do have one question however: I know that the URs should be cumulative, but the release notes state very clearly – as they did with UR7 – that you must have the Server part of UR2 installed. The UR6 notes state that this is only necessary if you want to be able to roll back UR6 at a later time. The notes for UR7 and UR8 no longer mention the “only if you want to roll back” bit, they just state the Server UR2 must be installed.
I’m 99% sure this is a documentation thing, but can you ask the team to look into this?
I have tried to make this clear as I can. I have also given this feedback to the product group many times. UR2 is NOT a prerequisite. UR2 simply fixed a bug in rolling back/uninstalling a UR. ANY UR after UR2 also contains this fix. It is such a miniscule scenario, I don’t even give it credence to document. In 13 years of supporting SCOM, I have never seen a need to “uninstall” a rollup, and this is technically impossible anyway, once you import the MP’s or run the SQL scripts, it would be unsupported to roll back a management server or GW UR.
I can confirm what Kevin says. I have just upgraded from 2016 RTM straight to UR8 by following the instructions on this page without issue.
Hey Kevin,
do you know, when the UR1 for SCOM 2019 will be released?
I don’t know for sure, but I believe we will see it early in 2020.
Hey Kevin,
Thank you for the great Guide!
We have one small problem when we rollout scom agents on our Linux Clients. The update overwrites all our security settings in the omiserver.conf file. For example it enables SSLv3 again by default. We therefore would have to manually change all config files on all Servers again (we have a few different conf files so we cant just rollout one for all).
Is there any way to keep old omiserver.conf settings when upgrading scom agents on Linux?
Hi Kevin,
We are having high Memory usage (process name MonitoringHost.exe) in 2016 UR8, any troubleshooting steps you can recommend.
What is “high” ?
On management servers, or agents?
hello sorry if I posted this in the wrong section, I have scom 2016, running on server 2016 and sql 2016 is installed on another 2016 server on the same domain, scom web console is installed on sver 2016 all on the same domain, everything is working except the scom web page. I am getting error on i/e, firefox and chrome This page isn’t working is currently unable to handle this request. HTTP ERROR 500. I saw a thread saying app pool, and another one saying the credentials, and another saying the spn, I tried everything except the spn, if its that where exactly do I adjust that?
%SystemDrive%\Program Files\Microsoft System Center 2016\Operations Manager\Server\SQL Script for Update Rollups only has one sql script – for the mom db. the data warehouse script is not there. why might this be?
i notice you did not import the ‘system center core library” MP. mine says it’s version 7.0.8437.13. when i import it, it says 7.0.8437.12 is imported. then it fails to import with this error.
System Center Core Library could not be imported.
If any management packs in the Import list are dependent on this management pack, the installation of the dependent management packs will fail.
Database error. MPInfra_p_ManagementPackInstall failed with exception:
[MP ID: 7cfc5cc0-ae0a-da4f-5ac2-d64540141a55][MP Version: 7.0.8437.13][MP PKT: 31bf3856ad364e35] Database error. MPInfra_p_ManagementPackInstall failed with exception:
Invalid column name ‘DisplayName’.
Transaction count after EXECUTE indicates a mismatching number of BEGIN and COMMIT statements. Previous count = 2, current count = 0.
I’m confused. I did import System Center core Library in my example. .12 was from UR6, so this leads me to believe you are upgrading an environment that was UR6 previously.
Sometimes I see these random failures on a MP import. I like to close the console, re-open, and attempt to import only that MP. Make sure you are not importing a language specific version, and you dont have some old language specific versions already imported.
yes, I was on ur6.
maybe i’m looking in the wrong place. in your import management pack section, you have an “initial list”, which contains system center core library 7.0.8437.13, system center internal library 7.0.8437.13, and windows cluster library 7.0.8437.13.
then in your “what not to import” there is a “So I remove what I don’t want or need – and I have this:” screenshot. in that screenshot, there are only MPs with 7.2.12213.0. i don’t see system center core library 7.0.8437.13, system center internal library 7.0.8437.13, or windows cluster library7.0.8437.13.
I had my error importing system center core library 7.0.8437.13 in two different management groups.
You are right – I was on UR7 which also contained .13 of this update, therefore they could not be imported when I installed UR8.
I dont know of any issues with installing them though – upgrading from .12 Can you try upgrading only that one alone?
UR8 for SCOM 2016 contains two scripts. This started with UR7. Are you sure you are running UR8, from an elevated command prompt?
the sql script thing was a false alarm. I naively trusted my patching administrator, again. ur8 had not actually been installed yet, and I was still on ur6. 🙂
it still fails if i only install that one MP. i’ve tried repeatedly from different consoles in different management groups. same database error.
Kevin, hi.
Looks like UR8 SQL is broken…
update_rollup_mom_db.sql drops and (re-) creates the p_ManagementPackFinishInstall stored procedure.
Here it uses MT.DisplayName in lines 3219-3224 and based on the MG here I see column DisplayName_55270A70_… for MT_UINameSpace$Group tables (probably classes in general).
Once I replace the wrong entry in the UR8 SQL, run it (so it replaces the wrong SP) I can successfully import MPs again.
See https://social.technet.microsoft.com/Forums/de-DE/2d5592aa-e26c-47d7-8306-d21301f19789/database-error-mpinfrapmanagementpackinstall-failed?forum=operationsmanagermgmtpacks
Thanks and cheers,
Patrick
Hi Patrick,
Please explain this line “Once I replace the wrong entry in the UR8 SQL, run it (so it replaces the wrong SP) I can successfully import MPs again”. What “wrong entry” are you referring to? What needs to be exactly updated in the SP.
Thanks,
Kevin, do you perhaps know what was done to rectify the above UR8 MP import issue?
I have scom 2016 and just applied UR8. I have unix/Linux servers that previously had 1.6.2-340 agents. When I downloaded the MPs and brought over the new agent version 1.6.2-343, I did an “–upgrade” on the package. When I do this, the agent stops running and will not restart. Usually when I upgrade, the agent will continue running. I have done this many times before with no issues. Can you point me in the right direction to fix this?
PS – this is only happening on the UNIX agents upgrade – the Linux agents I have all upgraded correctly with no issues.
Hi Kevin,
Do you have any guidance on applying the UR for management servers using SCCM?
My guidance would be “don’t do that”.
There are so few management servers in most companies. The patch needs to not be applied simultaneously, these patches can have failures that require immediate investigation, etc. I’d always recommend a manual patching/update experience for SCOM updates at this point and time.
For agents, SCCM updates are great. For server infrastructure, I’d follow a manual approach for now. We only ship these updates twice a year, and most customers do not stay current. If you did great and applied a UR once a year, is automation that valuable?
Thanks Kevin, What if you were just making them available via SCCM, but still manually triggering the update from the client on each MS allowing to do first server, web…. Would you still recommend against this? The only reason i am thinking of this is easy of transferring the updates as I have about 48 servers that need file copied across different domains.
That number does not include servers needing SCOM agents updates. Just Management(server/web/report) and Gateway servers
Yeah, that would probably be ok. As long as you patch one server at a time, agents can fail over, resource pools stay stable, etc. Should be fine to use SCCM in that scenario. Then ensure you also do the SQL script updates, and the MP imports soon after.
Thanks Kevin, Out of interest, does the server update doing anything to the DB’s or that were the sql scripts come in.
The server update does hit the DB. The main thing I see fail is the flip the agents into Pending Management for an update. This will always fail when using WU/SCCM because the update is running as Local System on the management server and this account wont have a high level of rights to the database (if any). Not a big deal as you will do agent updates using SCCM/WU.
Good day .
The OM and DW databases are installed on the same server.
I do according to your instructions.
After running the SQL script, I get an error:
Msg 1105, Level 17, State 2, Procedure p_ManagementPackFinishInstall, Line 2 [Batch Start Line 2763]
Could not allocate space for object ‘sys.sysmultiobjrefs’. ‘Clst’ in database ‘OperationsManager’ because the ‘PRIMARY’ filegroup is full. Create disk space by deleting unneeded files, dropping objects in the filegroup, adding additional files to the filegroup, or setting autogrowth on for existing files in the filegroup.
Apr 6 2020 5:19 PM [ERROR] ErrorLine: 13 ErrorMessage: Could not allocate a new page for database ‘OperationsManager’ because of insufficient disk space in filegroup ‘PRIMARY’. Create the necessary space by dropping objects in the filegroup, adding additional files to the filegroup, or setting autogrowth on for existing files in the filegroup. Error_Procedure: p_MaintenanceScheduleMigrateExistingSchedulesLogs ErrorSeverity: 17 ErrorState: 1
Msg 1101, Level 17, State 1, Procedure p_MaintenanceScheduleMigrateExistingSchedulesLogs, Line 13 [Batch Start Line 6025]
Could not allocate a new page for database ‘OperationsManager’ because of insufficient disk space in filegroup ‘PRIMARY’. Create the necessary space by dropping objects in the filegroup, adding additional files to the filegroup, or setting autogrowth on for existing files in the filegroup.
Your database is full. This is not supported. The OperationsManager DB requires a minimum of 50% free space at all times in order to remain supported.
Microsoft SQL Server 2016 (SP2-CU11) (KB4527378) version – 13.0.5598.27 (X64) Nov 27 2019 18:09:22 Copyright (c) Microsoft Corporation Standard Edition (64-bit) on Windows Server 2016 Standard 10.0 (Build 14393 🙂 (Hypervisor)
After increasing the size of the database, I started the script on a new one, but received the following error:
Not enough rights. But I run the script on behalf of the user who installed the server
Msg 4902, Level 16, State 1, Line 17
Cannot find the object “dbo.MaintenanceModeSchedule” because it does not exist or you do not have permissions.
Msg 4902, Level 16, State 1, Line 23
Cannot find the object “dbo.MaintenanceModeSchedule” because it does not exist or you do not have permissions.
Msg 4902, Level 16, State 1, Line 29
Cannot find the object “dbo.MaintenanceModeSchedule” because it does not exist or you do not have permissions.
Msg 4902, Level 16, State 1, Line 35
Cannot find the object “dbo.MaintenanceModeSchedule” because it does not exist or you do not have permissions.
Msg 4902, Level 16, State 1, Line 41
Cannot find the object “dbo.MaintenanceModeSchedule” because it does not exist or you do not have permissions.
Msg 4902, Level 16, State 1, Line 47
Cannot find the object “dbo.MaintenanceModeSchedule” because it does not exist or you do not have permissions.
Msg 4902, Level 16, State 1, Line 53
Cannot find the object “dbo.MaintenanceModeSchedule” because it does not exist or you do not have permissions.
Msg 4902, Level 16, State 1, Line 59
Cannot find the object “dbo.MaintenanceModeSchedule” because it does not exist or you do not have permissions.
Msg 4902, Level 16, State 1, Line 65
Cannot find the object “dbo.MaintenanceModeSchedule” because it does not exist or you do not have permissions.
Msg 4902, Level 16, State 1, Line 71
Cannot find the object “dbo.MaintenanceModeSchedule” because it does not exist or you do not have permissions.
The module ‘p_EmptyStagingTables’ depends on the missing object ‘dbo.p_EmptyTypeDefintionStagingTables’. The module will still be created; however, it cannot run successfully until the object exists.
The module ‘p_EmptyStagingTables’ depends on the missing object ‘dbo.p_EmptyCategoryStagingTables’. The module will still be created; however, it cannot run successfully until the object exists.
The module ‘p_EmptyStagingTables’ depends on the missing object ‘dbo.p_EmptyMonitoringStagingTables’. The module will still be created; however, it cannot run successfully until the object exists.
The module ‘p_EmptyStagingTables’ depends on the missing object ‘dbo.p_EmptyConfigurationGroupStagingTables’. The module will still be created; however, it cannot run successfully until the object exists.
The module ‘p_EmptyStagingTables’ depends on the missing object ‘dbo.p_EmptyTemplatesStagingTables’. The module will still be created; however, it cannot run successfully until the object exists.
The module ‘p_EmptyStagingTables’ depends on the missing object ‘dbo.p_EmptyPresentationTypesStagingTables’. The module will still be created; however, it cannot run successfully until the object exists.
The module ‘p_EmptyStagingTables’ depends on the missing object ‘dbo.p_EmptyPresentationStagingTables’. The module will still be created; however, it cannot run successfully until the object exists.
The module ‘p_EmptyStagingTables’ depends on the missing object ‘dbo.p_EmptySDWarehouseStagingTables’. The module will still be created; however, it cannot run successfully until the object exists.
The module ‘p_EmptyStagingTables’ depends on the missing object ‘dbo.p_EmptyReportingStagingTables’. The module will still be created; however, it cannot run successfully until the object exists.
The module ‘p_EmptyStagingTables’ depends on the missing object ‘dbo.p_EmptyLanguagePackStagingTables’. The module will still be created; however, it cannot run successfully until the object exists.
The module ‘p_EmptyStagingTables’ depends on the missing object ‘dbo.p_EmptyResourceStagingTables’. The module will still be created; however, it cannot run successfully until the object exists.
The module ‘p_FindObjectsNotInSnapshot’ depends on the missing object ‘dbo.p_FindTypeDefintionObjectsNotInSnapshot’. The module will still be created; however, it cannot run successfully until the object exists.
The module ‘p_FindObjectsNotInSnapshot’ depends on the missing object ‘dbo.p_FindCategoriesNotInSnapshot’. The module will still be created; however, it cannot run successfully until the object exists.
The module ‘p_FindObjectsNotInSnapshot’ depends on the missing object ‘dbo.p_FindMonitoringObjectsNotInSnapshot’. The module will still be created; however, it cannot run successfully until the object exists.
The module ‘p_FindObjectsNotInSnapshot’ depends on the missing object ‘dbo.p_FindConfigurationGroupsNotInSnapshot’. The module will still be created; however, it cannot run successfully until the object exists.
The module ‘p_FindObjectsNotInSnapshot’ depends on the missing object ‘dbo.p_FindTemplatesNotInSnapshot’. The module will still be created; however, it cannot run successfully until the object exists.
The module ‘p_FindObjectsNotInSnapshot’ depends on the missing object ‘dbo.p_FindPresentationTypesNotInSnapshot’. The module will still be created; however, it cannot run successfully until the object exists.
The module ‘p_FindObjectsNotInSnapshot’ depends on the missing object ‘dbo.p_FindPresentationObjectsNotInSnapshot’. The module will still be created; however, it cannot run successfully until the object exists.
The module ‘p_FindObjectsNotInSnapshot’ depends on the missing object ‘dbo.p_FindWarehouseObjectsNotInSnapshot’. The module will still be created; however, it cannot run successfully until the object exists.
The module ‘p_FindObjectsNotInSnapshot’ depends on the missing object ‘dbo.p_FindReportingObjectsNotInSnapshot’. The module will still be created; however, it cannot run successfully until the object exists.
The module ‘p_FindObjectsNotInSnapshot’ depends on the missing object ‘dbo.p_FindLanguagePacksNotInSnapshot’. The module will still be created; however, it cannot run successfully until the object exists.
The module ‘p_FindObjectsNotInSnapshot’ depends on the missing object ‘dbo.p_FindResourcesNotInSnapshot’. The module will still be created; however, it cannot run successfully until the object exists.
The module ‘p_DeleteObsoleteMPObjects’ depends on the missing object ‘dbo.p_DeleteFolder’. The module will still be created; however, it cannot run successfully until the object exists.
The module ‘p_DeleteObsoleteMPObjects’ depends on the missing object ‘dbo.p_DeleteObsoleteResources’. The module will still be created; however, it cannot run successfully until the object exists.
The module ‘p_DeleteObsoleteMPObjects’ depends on the missing object ‘dbo.p_DeleteObsoleteLanguagePacks’. The module will still be created; however, it cannot run successfully until the object exists.
The module ‘p_DeleteObsoleteMPObjects’ depends on the missing object ‘dbo.p_DeleteObsoleteReportingObjects’. The module will still be created; however, it cannot run successfully until the object exists.
The module ‘p_DeleteObsoleteMPObjects’ depends on the missing object ‘dbo.p_DeleteObsoleteWarehouseObjects’. The module will still be created; however, it cannot run successfully until the object exists.
The module ‘p_DeleteObsoleteMPObjects’ depends on the missing object ‘dbo.p_DeleteObsoletePresentationObjects’. The module will still be created; however, it cannot run successfully until the object exists.
The module ‘p_DeleteObsoleteMPObjects’ depends on the missing object ‘dbo.p_DeleteObsoletePresentationTypes’. The module will still be created; however, it cannot run successfully until the object exists.
The module ‘p_DeleteObsoleteMPObjects’ depends on the missing object ‘dbo.p_DeleteObsoleteTemplates’. The module will still be created; however, it cannot run successfully until the object exists.
The module ‘p_DeleteObsoleteMPObjects’ depends on the missing object ‘dbo.p_DeleteObsoleteConfigurationGroups’. The module will still be created; however, it cannot run successfully until the object exists.
The module ‘p_DeleteObsoleteMPObjects’ depends on the missing object ‘dbo.p_DeleteObsoleteMonitoringObjects’. The module will still be created; however, it cannot run successfully until the object exists.
The module ‘p_DeleteObsoleteMPObjects’ depends on the missing object ‘dbo.p_DeleteObsoleteCategories’. The module will still be created; however, it cannot run successfully until the object exists.
The module ‘p_DeleteObsoleteMPObjects’ depends on the missing object ‘dbo.p_DeleteObsoleteTypeDefinitions’. The module will still be created; however, it cannot run successfully until the object exists.
The module ‘p_InstallTypesAndReltypes’ depends on the missing object ‘dbo.p_TypeDeletePermanent’. The module will still be created; however, it cannot run successfully until the object exists.
The module ‘p_InstallTypesAndReltypes’ depends on the missing object ‘dbo.p_TypeDeletePermanent’. The module will still be created; however, it cannot run successfully until the object exists.
The module ‘p_InstallTypesAndReltypes’ depends on the missing object ‘dbo.p_DropProcedureByName’. The module will still be created; however, it cannot run successfully until the object exists.
The module ‘p_InstallTypesAndReltypes’ depends on the missing object ‘dbo.p_CreateTableForType’. The module will still be created; however, it cannot run successfully until the object exists.
The module ‘p_InstallTypesAndReltypes’ depends on the missing object ‘dbo.p_InsertSingleton’. The module will still be created; however, it cannot run successfully until the object exists.
The module ‘p_InstallTypesAndReltypes’ depends on the missing object ‘dbo.p_AlterTableForType’. The module will still be created; however, it cannot run successfully until the object exists.
The module ‘p_InstallTypesAndReltypes’ depends on the missing object ‘dbo.p_MakeBulkInsertSprocForType’. The module will still be created; however, it cannot run successfully until the object exists.
The module ‘p_InstallTypesAndReltypes’ depends on the missing object ‘p_AddBlobTriggersToTable’. The module will still be created; however, it cannot run successfully until the object exists.
The module ‘p_InstallTypesAndReltypes’ depends on the missing object ‘dbo.p_CreateViewForType’. The module will still be created; however, it cannot run successfully until the object exists.
The module ‘p_InstallTypesAndReltypes’ depends on the missing object ‘p_AlterTableForType’. The module will still be created; however, it cannot run successfully until the object exists.
The module ‘p_InstallTypesAndReltypes’ depends on the missing object ‘dbo.p_CreateTableForType’. The module will still be created; however, it cannot run successfully until the object exists.
The module ‘p_InstallTypesAndReltypes’ depends on the missing object ‘dbo.p_InsertSingleton’. The module will still be created; however, it cannot run successfully until the object exists.
The module ‘p_InstallTypesAndReltypes’ depends on the missing object ‘dbo.p_MakeBulkInsertSprocForType’. The module will still be created; however, it cannot run successfully until the object exists.
The module ‘p_InstallTypesAndReltypes’ depends on the missing object ‘p_AddBlobTriggersToTable’. The module will still be created; however, it cannot run successfully until the object exists.
The module ‘p_InstallTypesAndReltypes’ depends on the missing object ‘dbo.p_CreateViewForType’. The module will still be created; however, it cannot run successfully until the object exists.
The module ‘p_InstallTypesAndReltypes’ depends on the missing object ‘p_AlterTableForType’. The module will still be created; however, it cannot run successfully until the object exists.
The module ‘p_InstallTypesAndReltypes’ depends on the missing object ‘dbo.p_MakeBulkInsertSprocForType’. The module will still be created; however, it cannot run successfully until the object exists.
The module ‘p_InstallTypesAndReltypes’ depends on the missing object ‘p_AddBlobTriggersToTable’. The module will still be created; however, it cannot run successfully until the object exists.
The module ‘p_InstallTypesAndReltypes’ depends on the missing object ‘dbo.p_CreateViewForSingletonType’. The module will still be created; however, it cannot run successfully until the object exists.
The module ‘p_InstallTypesAndReltypes’ depends on the missing object ‘dbo.p_CreateViewForType’. The module will still be created; however, it cannot run successfully until the object exists.
The module ‘p_InstallTypesAndReltypes’ depends on the missing object ‘dbo.p_TypeExtensionInstanceInsertionMPInstall’. The module will still be created; however, it cannot run successfully until the object exists.
The module ‘p_InstallTypesAndReltypes’ depends on the missing object ‘dbo.p_CreateTableForType’. The module will still be created; however, it cannot run successfully until the object exists.
The module ‘p_InstallTypesAndReltypes’ depends on the missing object ‘dbo.p_MakeBulkInsertSprocForType’. The module will still be created; however, it cannot run successfully until the object exists.
The module ‘p_InstallTypesAndReltypes’ depends on the missing object ‘dbo.p_CreateViewForType’. The module will still be created; however, it cannot run successfully until the object exists.
The module ‘p_InstallTypesAndReltypes’ depends on the missing object ‘p_AddBlobTriggersToTable’. The module will still be created; however, it cannot run successfully until the object exists.
The module ‘p_InstallTypesAndReltypes’ depends on the missing object ‘dbo.p_TypeExtensionInstanceInsertionMPInstall’. The module will still be created; however, it cannot run successfully until the object exists.
The module ‘p_InstallTypesAndReltypes’ depends on the missing object ‘dbo.p_ManagedEntityInsert’. The module will still be created; however, it cannot run successfully until the object exists.
The module ‘p_InstallTypesAndReltypes’ depends on the missing object ‘dbo.p_CreateViewForSingletonType’. The module will still be created; however, it cannot run successfully until the object exists.
The module ‘p_InstallTypesAndReltypes’ depends on the missing object ‘dbo.p_InsertSingleton’. The module will still be created; however, it cannot run successfully until the object exists.
The module ‘p_InstallTypesAndReltypes’ depends on the missing object ‘dbo.p_CreateTableForRelationship’. The module will still be created; however, it cannot run successfully until the object exists.
The module ‘p_InstallTypesAndReltypes’ depends on the missing object ‘dbo.p_CreateViewForRelationshipType’. The module will still be created; however, it cannot run successfully until the object exists.
The module ‘p_ManagementPackFinishInstall’ depends on the missing object ‘dbo.p_InstallResources’. The module will still be created; however, it cannot run successfully until the object exists.
The module ‘p_ManagementPackFinishInstall’ depends on the missing object ‘dbo.p_InstallConfigurationGroups’. The module will still be created; however, it cannot run successfully until the object exists.
The module ‘p_ManagementPackFinishInstall’ depends on the missing object ‘dbo.p_InstallSDWarehouseElements’. The module will still be created; however, it cannot run successfully until the object exists.
The module ‘p_MaintenanceScheduleJobStepNew’ depends on the missing object ‘dbo.p_MaintenanceModeStart’. The module will still be created; however, it cannot run successfully until the object exists.
Msg 208, Level 16, State 1, Procedure p_MaintenanceScheduleMigrateExistingSchedules, Line 26 [Batch Start Line 6025]
Invalid object name ‘dbo.MaintenanceModeSchedule’.
The module ‘p_ScheduledJobsEveryFiveMinutes’ depends on the missing object ‘dbo.p_MaintenanceModeJob’. The module will still be created; however, it cannot run successfully until the object exists.
The module ‘p_ScheduledJobsEveryFiveMinutes’ depends on the missing object ‘dbo.p_MaintenanceScheduleJob’. The module will still be created; however, it cannot run successfully until the object exists.
The module ‘p_ScheduledJobsEveryFiveMinutes’ depends on the missing object ‘dbo.p_JobStatusTimeout’. The module will still be created; however, it cannot run successfully until the object exists.
I am having the same issues and errors in one of my tenants. All other tenants updated without any issues.
Hi Kevin,
I’ve just done a brand new install of SCOM 2016 today, and have patched management servers and the
console to UR8. We’ll be introducing SCOM gateways later on, but won’t be using any of the other server
infrastructure in your list of things to patch.
Unfortunately I’ve installed the patch before I noticed the part about configuring the additional rights
within SQL (the “WHOA Nelly” bit). So these rights haven’t been configured.
We’re using MS SQL server 2016 SP2, CU 15 (released 28th Sept, 2020).
If I still need to configure the rights using this version of SQL, is it possible to just configure the
rights and re-apply the patch? Or should I blow the installation away and start again?
We’re using a SQL Always on group, and as described above, the installation is brand new
with no agents pushed out yet, or MPs included other than the default.
Thanks for any advice,
Christian.
After a re-read of the document, I’m assuming it will be fine to continue as is once the rights are configured in SQL. There’s no Scheduled MM configured yet. If I’ve got it wrong though let me know 🙂
Thanks,
Christian.