Microsoft Connected Cache ISP – Auto-update history 404 and IoT Edge version mismatch

Do not reprovision or manually replace the MCC deployment; preserve the node and cache data, collect its current deployment evidence, and escalate the auto-update-history 404 ResourcePostActionFailed through the Connected Cache resource because MCC for ISP updates are service-managed.

What the versions mean

• IoT Edge consists of two separately updated parts:
  • the host security subsystem (aziot-edge and Identity Service);
  • the runtime containers (edgeAgent and edgeHub).
• Microsoft recommends that the runtime containers match the security subsystem’s major/minor release. For a 1.6 host, that normally means both system-module image URIs use :1.6. Mismatched versions are supported, but Microsoft has not tested every combination.^1^
• IoT Edge 1.6 is the current LTS release. IoT Edge 1.5 remains supported only through November 10, 2026, so the running 1.5 containers were still supported on October 23, but were close to end of support.^2^
• Changing /etc/aziot/config.toml and applying it affects the locally configured bootstrap edgeAgent. It does not by itself rewrite a cloud deployment that still specifies 1.5 system modules. That explains why reapplying the local configuration and restarting did not necessarily change the running containers.^1^

The public MCC for ISP documentation does not specify which exact edgeAgent/edgeHub build must accompany MCC container 1.2.1.2115. Therefore, 1.6 should not be forced solely from the generic IoT Edge recommendation without Microsoft confirming that release for this MCC deployment.

Supported non-destructive path

MCC for ISP container updates are automatically installed during low-traffic periods and require no customer action.^3^ Because this is an MCC-managed deployment:

1. Record the desired and running state without changing it.

      sudo iotedge version
      sudo iotedge list
      sudo iotedge system status
      sudo iotedge logs edgeAgent --tail 200
      sudo iotedge logs edgeHub --tail 200
      sudo iotedge check --verbose
   

   Capture the system-module image names/digests from iotedge list, plus any deployment, image-pull, or direct-method errors from the logs. These are the documented IoT Edge health and version checks.^1^
2. Verify that MCC itself remains functional. sudo iotedge list should show edgeAgent, edgeHub, and MCC. From a device that can reach the cache server, run:

      wget "http://<CacheServerIP>/mscomtest/wuidt.gif?cacheHostOrigin=au.download.windowsupdate.com"
   

   A 200 OK response confirms the node can serve the MCC test object.^4^
3. Open the MCC resource in Azure Portal → Diagnose and solve problems → Troubleshoot. Supply:
   • cache-node/resource name and region;
   • UTC timestamps and correlation/activity IDs for the October 23 failures;
   • the full ResourcePostActionFailed payload;
   • successful install-details response alongside the failed history response;
   • MCC, host IoT Edge, Identity Service, edgeAgent, and edgeHub versions;
   • output from the commands above.
   This is the documented escalation path when the ISP troubleshooting article does not resolve a cache-node issue.^5^

No public MCC documentation identifies the auto-update-history 404 as a known node-side fault. Since installation details succeed, Azure reports the node healthy, and MCC is running, the 404 alone does not establish that the cache installation or cached content is damaged.

Avoid these actions pending MCC support confirmation

• Do not delete the cache node or run uninstallmcc.sh. That script removes MCC, IoT Edge, Edge Agent, Edge Hub, Moby CLI, and Moby Engine, which conflicts with preserving the installation.^3^
• Do not manually delete the 1.5 system images or edit the MCC-managed deployment to force 1.6. Generic IoT Edge supports updating runtime URIs, but partner modules must use image URIs supplied by their publisher.^1^
• Do not change Docker DNS unless iotedge check --verbose specifically reports connectivity or name-resolution failures; the MCC DNS procedure is conditional on network-connectivity problems.^5^

Microsoft support should confirm either that the MCC deployment is intentionally pinned to 1.5 or issue/correct the managed deployment so both edgeAgent and edgeHub move together to the MCC-approved 1.6 images.

References

1. Update IoT Edge
2. Azure IoT Edge versions and release notes
3. Update or uninstall your cache node
4. Verify cache node functionality and monitor health and performance
5. Support and troubleshooting | Microsoft Learn