MECM Primary Site Multiple in-console updates were started in parallel

Statz, Martin 0 Reputation points
2026-06-12T11:17:23.6566667+00:00

Since then, "Updates and Servicing" is permanently greyed out.

 

Symptoms:

  • Update states (196607 / 262146) reappear after restart
  • No update is actively running
  • Console remains locked

We believe the in-console update orchestration state is corrupted

and cannot be reset locally anymore.

 

Request:

Please perform a backend reset of the in-console update orchestration state.

Microsoft System Center | Other
0 comments No comments

1 answer

Sort by: Most helpful
  1. AI answer

    2026-06-12T11:17:39.8733333+00:00

    Configuration Manager doesn’t support a “backend reset” of the in-console update orchestration state by customers. Only supported options are the documented recovery and retry mechanisms.

    Use the following supported steps to recover from a stuck or corrupted in-console update state:

    1. Do not use CMUpdateReset.exe after install has started
      • If any of the in-console updates have already started the Installation stage, don’t run CMUpdateReset.exe for that package. The documentation explicitly warns against using the update reset tool after an update package starts installing.
    2. Use the Update reset tool only for failed, not-yet-installed updates
      • For updates that are in a failed download/replication state (for example, stuck for hours in download or replication, not yet installing), use CMUpdateReset.exe from \cd.latest\SMSSETUP\TOOLS on the site server.
      • Prerequisites for the account running CMUpdateReset.exe:
        • Read/Write on the site database of the CAS and each primary site (for example, db_datareader and db_datawriter on each ConfigMgr DB).
        • Local Administrator on the top-level site server.
        • Local Administrator on the service connection point server.
      • Identify the update’s Package Guid in Administration > Updates and Servicing by adding the Package Guid column, then run CMUpdateReset.exe against the specific GUID.
    3. Retry installation of failed updates from the console
      • After fixing all errors (and preferably warnings) reported in ConfigMgrPrereq.log and the console:
      • For hierarchy-wide retry:
        • Go to Administration > Updates and Servicing.
        • Select the failed update (states like Prerequisite failed / Installation failed / Replication failed / Prereq passed with warnings).
        • Choose Retry to restart the install for the hierarchy. This retry automatically ignores prerequisite warnings and re-runs content replication if it previously failed.
        • Or choose Ignore prerequisite warnings if the install stopped only because of warnings.
      • For a single site retry:
        • Go to Monitoring > Site Servicing Status.
        • Select the update and choose Retry to restart only at that site (this retry does not ignore prerequisite warnings), or Ignore prerequisite warnings if applicable.
    4. If content/redistributables are missing or replication is broken
      • If the issue is missing files during Install Files stage (for example, offline service connection point):
        • Use the service connection tool to download and import the update files again.
        • Verify in ServiceConnectionTool.log and ConfigMgrSetup.log that required files download successfully.
        • Confirm required files exist under EasySetupPayload\Offline\<PackageGuid>\Redists and then retry the in-console update.
      • If files exist in EasySetupPayload but are missing from CMUStaging:
        • On a server hosting the SMS Provider for the top-level site, run in PowerShell:
                 (Get-WmiObject -Namespace "ROOT\SMS\site_<SiteCode>" -Query "select * from SMS_CM_UpdatePackages where PackageGuid = '<PackageGuid>'").RetryContentReplication($true)
          
        • After replication completes, retry the in-console update.
    5. Avoid unsupported manual cleanup or DB changes
      • Do not manually clean up \EasySetupPayload or \CMUStaging folders, or modify SQL tables, unless explicitly instructed by Microsoft Support.
      • Do not restore the ConfigMgr database or reinstall the Service Connection Point just because an in-console update failed; instead, fix the issue and retry the update.
    6. Investigate current state before further retries
      • Identify the update package GUID (if not already done) via Administration > Updates and Servicing (add Package Guid column) or via SQL:
             SELECT Name, PackageGuid FROM v_LocalizedUpdatePackageMetaData_SiteLoc
        
      • Check prerequisite state:
        • Use ConfigMgrPrereq.log and Monitoring > Updates and Servicing Status > Description for each site.
        • In CM_UpdatePackages, state values like PREREQ_ERROR 196607 or PREREQ_WARNING 131075 indicate where to focus.
      • Check installation state:
        • Use Administration > Updates and Servicing and Monitoring > Updates and Servicing Status.
        • Optionally run the documented SQL query against CM_UpdatePackageSiteStatus to find sites where state <> 196612 (not fully installed) for the given Package GUID.
    7. If console remains locked or orchestration appears corrupted
      • Use the supported tools and flows above (CMUpdateReset.exe for pre-install failures, Retry/Ignore prerequisite warnings, service connection tool, RetryContentReplication).
      • If the console is still permanently greyed out and no supported recovery path clears the state, open a support case with Microsoft. Backend repair of orchestration state (beyond the documented tools) is not something customers can perform and requires direct Microsoft support intervention.

    References:

    AI-generated content may be incorrect. Read our transparency notes for more information.

    Was this answer helpful?

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.