none
DAS/SDK service failing after SQL migration RRS feed

  • Question

  • So, to prepare for upgrading our 1807 deployment to SCOM 2019, I had our DBAs restore the OpMgr and DW DBs from our LAB MG to a new SQL 2017 server (from current SQL 2014). The DBA migrated all permissions as well, and afaik, they are identical and meet all documented requirements. After following all the MS steps to edit the registry keys and configservice.config file on each MS, and editing the listed tables on the DB server for both the OpsMgr and DW DBs, SCOM appears to be running, all MS are talking to SQL, with a fairly robust amount of data being exchanged for our LAB MG, but I can’t launch a console on any MS. Data Access Service fails, with Application Log Errors 1000 and 1026, System Log Error 7034 (OMSDK keeps restarting and failing) , and OpsManager Errors 26340 and 26380. If I restore the previous registry keys values and old configservice.config values, Management servers have no problem talking to the old DB.

    Two of my DBAs swear up and down that logins, perms, ports (default on both old and new servers), firewall, etc. are all configured the same. And the management servers and SQL are talking. Traffic on all of them, and OpsMgr log files show that agents are available. Just no console and the DAS keeps failing, restarting, failing, etc. I notice that in Microsoft’s “How to configure Operations Manager to communicate with SQL Server” page, the database edits specify using (computer\instance,portNumber). On the old server, only SQL server name is used. Since we’re using default ports, my DBAs don’t think this should be an issue, but did this maybe change in SQL 2017? Grasping at straws here (at least it’s in the lab MG). Thanks.

    Thursday, May 2, 2019 5:43 PM

Answers

  • FYI, if you're interested, the real issue is that on our Server 2016 template, TLS 1.0 and 1.1 were disabled.  Enabling these solved the bulk of my problems.

    Adam Mizicko

    • Marked as answer by Adminzicko Thursday, July 25, 2019 10:56 PM
    Thursday, July 25, 2019 10:56 PM

All replies

  • Hi,

     

    Have you edited the following file on new management server?

    %ProgramFiles%\Microsoft System Center\Operations Manager\Server\ConfigService.config

    In the <Category> tags named “Cmdb” and “ConfigStore”, change the value for ServerName to the name of the new SQL server. And make sure other setting are set correct. Here is the one in my lab which is with SQL 2017:

     

    =======================================================

    <Category Name="Cmdb">

            <Setting Name="ServerName" Value="scom1\scom_opsmgr" />

            <Setting Name="DatabaseName" Value="OperationsManager" />

            <Setting Name="PortNumber" Value="0" />

            <Setting Name="FailoverPartnerServerName" Value="" />

            <Setting Name="FailoverPartnerPortNumber" Value="0" />

            <Setting Name="AccessApplicationName" Value="Management Configuration Service" />

            <Setting Name="ConnectionPoolSize" Value="0" />

            <Setting Name="ScriptFilePath" Value="C:\Program Files\Microsoft System Center\Operations Manager\Server" />

            <Setting Name="OperationRetryCount" Value="3" />

            <Setting Name="OperationRetryTimeoutMilliseconds" Value="1000" />

            <Setting Name="MinimumVersion" Value="7.0.0.0" />

            <Setting Name="TypeCacheRefreshIntervalSeconds" Value="300" />

            <Setting Name="OperationTimeout" Value="Xml">

              <OperationTimeout DefaultTimeoutSeconds="30">

                <!--Operation Name="InitializeConfigurationDataProvider" TimeoutSeconds="30" /-->

                <Operation Name="GetConfigurationSnapshotNextBatch" TimeoutSeconds="300" />

                <!--Operation Name="InitializeSnapshot" TimeoutSeconds="30" /-->

                <Operation Name="GetManagementPack" TimeoutSeconds="300" />

                <!--Operation Name="GetConfigManager" TimeoutSeconds="30" /-->

                <Operation Name="GetManagesRelationshipActionList" TimeoutSeconds="120" />

                <!--Operation Name="GetNextManagesRelationshipAssignmentBatchId" TimeoutSeconds="30" /-->

                <!--Operation Name="GetAgentCredentialDeltaList" TimeoutSeconds="30" /-->

                <!--Operation Name="MarkManagesRelationshipAssignmentBatchCompleted" TimeoutSeconds="30" /-->

                <!--Operation Name="InsertManagesRelationshipAssignmentBatch" TimeoutSeconds="30" /-->

                <Operation Name="GetEntityChangeDeltaList" TimeoutSeconds="180" />

                <!--Operation Name="GetMaintenanceModeDeltaList" TimeoutSeconds="30" /-->

                <!--Operation Name="GetAgentCredentialDeltaList" TimeoutSeconds="30" /-->

                <!--Operation Name="CompareAndExchangeCmdbStateGuid" TimeoutSeconds="30" /-->

                <!--Operation Name="GetNextAgentPoolMembershipAssignmentBatchId" TimeoutSeconds="30" /-->

                <!--Operation Name="MarkAgentPoolMembershipAssignmentBatchCompleted" TimeoutSeconds="30" /-->

                <!--Operation Name="InsertAgentPoolMembershipAssignmentBatch" TimeoutSeconds="30" /-->

                <!--Operation Name="QueueAllDynamicPoolsAgentPoolMembershipAssignmentBatch" TimeoutSeconds="30" /-->

                <!--Operation Name="GetAgentPoolMembershipActionList" TimeoutSeconds="30" /-->

                <!--Operation Name="GetNextSiteMembershipAssignmentBatchId" TimeoutSeconds="30" /-->

                <!--Operation Name="MarkSiteMembershipAssignmentBatchCompleted" TimeoutSeconds="30" /-->

                <!--Operation Name="InsertSiteMembershipAssignmentBatch" TimeoutSeconds="30" /-->

                <!--Operation Name="GetSiteRelationshipsActionList" TimeoutSeconds="30" /-->

              </OperationTimeout>

            </Setting>

          </Category>

          <Category Name="ConfigStore">

            <Setting Name="ServerName" Value="scom1\scom_opsmgr" />

            <Setting Name="DatabaseName" Value="OperationsManager" />

            <Setting Name="PortNumber" Value="0" />

            <Setting Name="FailoverPartnerServerName" Value="" />

            <Setting Name="FailoverPartnerPortNumber" Value="0" />

            <Setting Name="AccessApplicationName" Value="Management Configuration Service" />

            <Setting Name="ConnectionPoolSize" Value="0" />

            <Setting Name="ScriptFilePath" Value="C:\Program Files\Microsoft System Center\Operations Manager\Server" />

            <Setting Name="OperationRetryCount" Value="3" />

            <Setting Name="OperationRetryTimeoutMilliseconds" Value="1000" />

            <Setting Name="OperationTimeout" Value="Xml">

              <OperationTimeout DefaultTimeoutSeconds="30">

                <Operation Name="InitializeConfigStore" TimeoutSeconds="90" />

                <!--Operation Name="GetDirtyAgentList" TimeoutSeconds="30" /-->

                <!--Operation Name="MarkAgentClean" TimeoutSeconds="30" /-->

                <Operation Name="GetAgentConfiguration" TimeoutSeconds="300" />

                <Operation Name="StartSnapshot" TimeoutSeconds="300" />

                <Operation Name="WriteConfigurationSnapshotBatch" TimeoutSeconds="300" />

                <Operation Name="EndSnapshot" TimeoutSeconds="900" />

                <!--Operation Name="StartDelta" TimeoutSeconds="30" /-->

                <Operation Name="WriteConfigurationDeltaBatch" TimeoutSeconds="900" />

                <Operation Name="EndDelta" TimeoutSeconds="900" />

                <Operation Name="StatisticsUpdate" TimeoutSeconds="120" />

                <Operation Name="IndexOptimize" TimeoutSeconds="600" />

                <Operation Name="ConfigStoreGroom" TimeoutSeconds="600" />

                <!--Operation Name="SnapshotSynchronizationForce" TimeoutSeconds="30" /-->

                <!--Operation Name="WorkItemGetNext" TimeoutSeconds="30" /-->

                <!--Operation Name="WorkItemMarkCompleted" TimeoutSeconds="30" /-->

                <!--Operation Name="WorkItemActivityUpdate" TimeoutSeconds="30" /-->

                <!--Operation Name="WorkItemStatsGet" TimeoutSeconds="30" /-->

              </OperationTimeout>

            </Setting>

            <Setting Name="StatisticsUpdateFrequencySeconds" Value="3600" />

            <Setting Name="StatisticsUpdateMaxTimeAllowedSeconds" Value="60" />

            <Setting Name="IndexOptimizationFrequencySeconds" Value="3600" />

            <Setting Name="IndexOptimizationMaxTimeAllowedSeconds" Value="300" />

            <Setting Name="MinFragmentationPercentageToOptimize" Value="10" />

            <Setting Name="MinFragmentationPercentageToRebuild" Value="30" />

            <Setting Name="MaxRowsToGroom" Value="10000" />

            <Setting Name="MaxSynchronizationBatchAgeMinutes" Value="60" />

            <Setting Name="SynchronizationDeltaHistoryEnabled" Value="false" />

            <Setting Name="SynchronizationDeltaHistoryGroomingEnabled" Value="false" />

            <Setting Name="OperationRetryCount" Value="3" />

            <Setting Name="OperationRetryTimeoutMilliseconds" Value="1000" />

          </Category>

    ================================================================

     

    Meanwhile, I would like to suggest you check the registry key in the below path on the operation manager server, make sure it points to the new DB server and the DatabaseServerName format is as below:

    [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\System Center\2010\Common\Database]

     

     


     

    Hope the information can help.

     

    Best regards.

    Crystal


    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.



    Friday, May 3, 2019 7:36 AM
  • Thanks, Crystal.  But yes, I followed all the steps in both https://docs.microsoft.com/en-us/system-center/scom/manage-move-opsdb?view=sc-om-2019 and https://docs.microsoft.com/en-us/system-center/scom/manage-sqlserver-communication?view=sc-om-2019#how-to-configure-the-operations-manager-operational-database.  I performed every regedit, configservice.config change, SQL DB edit and script in both documents, and DAS still fails on every management server.  If I restore the previous registry values and configservice.config to point to the old SQL (which we still have online in the lab), everything works.  Thanks again for the suggestion.
    Friday, May 3, 2019 2:08 PM
  • Hi,

    How about the System Center Data Access Service and Configuration service Logon account? Did we change the account after SQL migration? Is it a domain account with local administrative rights on all management servers in the management group? If no, please grant related permission to see if it is working.

    Confirm the following user mappings are added for the account to the new SQL server:

    • ConfigService
    • db_accessadmin
    • db_datareader
    • db_datawriter
    • db_ddladmin
    • db_securityadmin
    • sdk_users
    • sql_dependency_subscriber

    Best regards.

    Crystal


    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.



    Monday, May 6, 2019 6:18 AM
  • Hi,

    Also check the TCP/IP for the protocol in the SQL server 2017 configuration manager is enabled.

    Best regards.

    Crystal


    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Monday, May 6, 2019 6:29 AM
  • Hi,

    How's everything going? If there's any update, please let me know.

    Thanks and have a nice day.!

    best regards.

    Crystal


    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Wednesday, May 8, 2019 5:22 AM
  • Thanks, Crystal, but I've checked and double- and triple-checked everything, including your latest suggestions.  Still no luck.  I've switched my efforts into convincing my boss that SCOM 2019 is no good and we should just stick with 1807.  :)
    Thursday, May 9, 2019 8:39 PM
  • FYI, if you're interested, the real issue is that on our Server 2016 template, TLS 1.0 and 1.1 were disabled.  Enabling these solved the bulk of my problems.

    Adam Mizicko

    • Marked as answer by Adminzicko Thursday, July 25, 2019 10:56 PM
    Thursday, July 25, 2019 10:56 PM