Поделиться через

Recommended registry tweaks for SCOM 2016 management servers

  • Статья

<!--[if lt IE 9]>

<![endif]-->

Comments

  • Anonymous
    March 09, 2017
    Kevin, Thanks for posting this article. Looks like the recommendations are the same as for SCOM 2012 management servers. So if I am planning to upgrade my existing SCOM configuration from 2012 to 2016 will the registry tweaks that I currently have set on my management servers remain, or will I have to tweak them? Thanks
    • Anonymous
      March 09, 2017
      Historically - the "upgrades" actually do an uninstall/reinstall.... so it is possible registry entries will get wiped out. I'd absolutely go back and re-verify these after an upgrade.
  • Anonymous
    March 12, 2017
    Thanks for the writeup.Do you know why these are not set by default?
  • Anonymous
    May 16, 2017
    Thnx for the info! Helps alot!
  • Anonymous
    July 20, 2017
    Hi Kevin,we have the issues Event ID 15002 and 15004 on both Gateway Servers.Are these Registry keys are to set then only on Gateway Servers, OR only on Management Servers, OR on both Management Servers AND Gateway Servers?Best RegardsBirdalEvent IDs:Event ID: 15002Task Category: Pool ManagerLevel: ErrorKeywords: ClassicUser: N/AComputer: Description:The pool member cannot send a lease request to acquire ownership of managed objects assigned to the pool because half or fewer members of the pool acknowledged the most recent initialization check request. The pool member will continue to send an initialization check request. Management Group: Management Group ID: {C601BF31-FBEC-4CD4-12F9-814C98AFF83E} Pool Name: Pool ID: {9EE78DB3-4D6C-DA05-608F-3B79294E3AFB} Pool Version: 3075036988681890219 Number of Pool Members: 3 Number of Observer Only Pool Members: 1 Number of Instances: 2Log Name: Operations ManagerSource: HealthServiceDate: 19.07.2017 17:22:02Event ID: 15004Task Category: Pool ManagerLevel: ErrorKeywords: ClassicUser: N/AComputer: Description:The pool member no longer owns any managed objects assigned to the pool because half or fewer members of the pool have acknowledged the most recent lease request. The pool member has unloaded the workflows for managed objects it previously owned. Management Group: Management Group ID: {C601BF31-FBEC-4CD4-12F9-814C98AFF83E} Pool Name: Pool ID: {9EE78DB3-4D6C-DA05-608F-3B79294E3AFB} Pool Version: 3075036988681890219 Number of Pool Members: 3 Number of Observer Only Pool Members: 1 Number of Instances: 2
  • Anonymous
    August 23, 2017
    I have a Data Warehouse issue in my new SCOM 2016 environement, where the RMS is a 2016 server data center edition. The reg key path you mentioned to modify the DW command timedout is not present. I have both DB and DW on a single server and all my reg key path shows is HKLM\SOFTWARE\Microsoft\Microsoft Operations Manager\3.0\Setup where all DB and DW details are present. Can you let me know where should I add Command Timeout Seconds to get rid of event 31551 and 31552 events.
  • Anonymous
    September 20, 2017
    Thank you Kevin! great information as always!
  • Anonymous
    October 02, 2017
    Hi Kevin, I hope all is well. we are seeing a number of 29181 event on the Management Servers, all related to SnapshotSynchronizationworkItem timeout issues. Artile (https://blogs.technet.microsoft.com/silvana/2014/09/04/eventid-29181-snapshotsynchronization-not-taking-place/) suggest to implement key HKLM\Software\Microsoft\Microsoft Operations Manager\3.0\Config Service->New DWORD CommandTimeoutSeconds - is this required in 2016?Thanks
    • Anonymous
      October 02, 2017
      I generally don't recommend extending snapshot timeout. Most of the time extending a timeout is like placing a band aid... on a gushing wound that really needs stitches.I would first try and understand what's unique about your environment that is causing snapshot to fail. First - how long does it run before it fails? Does it fail often then complete with success?Is this SCOM 2016?What OS?Snapshot runs once per day - and should complete with success. It is normal for it to fail a few times every night, but it should have a successful completion, once per day.SELECT * FROM cs.workitemWHERE WorkItemName like ‘%snap%’ORDER BY WorkItemRowId DESC
      • Anonymous
        October 04, 2017
        The comment has been removed
        • Anonymous
          October 04, 2017
          Snapshot only runs once a day. Random failures are FINE as long is it completes every day. What was the output of the SQL query?
          • Anonymous
            October 05, 2017
            The comment has been removed
            • Anonymous
              October 05, 2017
              No, it is not safe to say that. 10's are bad. But again - it is ok to haver snapshot job failures, AS LONG AS you get at least one "20" per day, which means that it was able to complete with success, once per day.
  • Anonymous
    October 05, 2017
    Thanks, the issue we are seeing is that the SnapShotSyncronization engine work item never seems to recover after 25hr period, so for example a 29180 does not get generated. Other Work flows, such as GetNextWorkItem engine work item, will generate a 29181 and recover with a 29180.What I am unclear about is when we get alert Microsoft.SystemCenter.ManagementConfigurationService.SnapshotWorkItemMonitor (generated by monitor Snapshot Sync state) - I see WorkItemStateId 10 for the server (when running the query). Will SnapShotSyncronization engine work item automatically rerun? Even with restarting the Config Service I don't see 29180 logged for SnapShotSyncronization engine work item - is this normal behavior?Its random why see this on some servers not other.Thanks again