M365 Apps Update fails to download by DownloadError = 30101 when unable to download from peer cache source.
The expected behavior is fallback to DP and continue to download even if fails to download from peercache, however an error occurs before fallback and client cannot continue to download from DP.

The Peer Cache cannot be used effectively, so we request improvement.

Enviroment

ConfigMgr version 2006 , 2010 and 2103
Microsoft 365 Apps Update in March, April and May.

Repro Step

1. Peer cache client's AlternateHandler begin to download.

BeginDownload: contentID =750d04a4-8178-4cb6-9c72-f8bf2a096a7a and contentVersion=1 AlternateHandler

1. Data Transfer Service download error from peer and switched to location next peer.
2. Data Transfer Service download error from 2nd peer.

(Now it is expected download from next peer or DP, but actually...)

1. AlternateHandler.log is DownloadError = 30101.
2. UpdateHandler.log is Error = 0x80077595.

• AlternateHandler.log
  DownloadStatus = eDOWNLOAD_FAILED
  DownloadError = 30101

• UpdateHandler.log
  CAS failed to download update (750d04a4-8178-4cb6-9c72-f8bf2a096a7a). Error = 0x80077595. Releasing content request

When the unified write filter is enabled on an endpoint and a deployment is received, users receive a warning for the reboot as defined below. However when the unified write filter is disabled, it would be ideal to suppress this warning for the reboot and reboot instantly as the UWF Servicing screen saver is present preventing users from logging in.

We currently set the 'Client Policy' for 'Computer Restart' to 10 minute restart, but 2 minute final notification however this occurs before disabling the write filter, every time a software update needs a reboot regardless if the UWF is disabled and again when it finishes and needs to enable the UWF. This is redundant for UWF enabled devices as users aren't using the device when the UWF is disabled for servicing.

Right now when a member of an Orchestration Group fails, it leaves the Orchestration Group as a whole in a failed state that won't recover until you manually press the Start Orchestration button. Resetting all the failed members won't clear the failed state of the group and any future updates will not orchestrate unless manually started.

This is particularly frustrating as Security Intelligence Updates for Microsoft Defender will trigger orchestration. It also seems that update has an issue with reporting successful installation, so it fails to move on to the next server which will cause the whole group to timeout.

It would be nice if there was a button that would reset the state of the whole group back to Idle without requiring orchestration to start.

When using feature updates to upgrade Windows 10 from one version to another there is no possibility to include cumulative updates to the feature updates (esd files). It is only possible if dynamic updates are enabled. It is also possible to offline service image files (.wim) but then you have to use a task sequence to upgrade Windows 10 from one to another version.

When using feature updates instead of in-place-upgrade wim files it is necessary to get a possibility to do an offline servicing for feature updates (.esd files) or at least update them more often (every 2 months for example instead of twice a year)

Servicing Plans, effectively, don't work anymore. I had this process setup to be automated with different deployment phases at 30, 90 and 180 days. This process no longer works because Microsoft has been releasing newer versions of the upgrades that reset the release date.

So now build 2004, which released over 300 days ago, doesn't qualify for my 180 day General Release plan. Microsoft released an updated upgrade file on 11/9/2020, only 142 days ago. This revision was also 14 days BEFORE the 180 days was up, so build 2004 was never picked up by my Servicing Plan.

This forces me to either manually manage Servicing Upgrades, or I have to rework my testing phases and then still have to keep monitoring for new revisions that could mess it all up.

Servicing Plans need to be based on the Availability Date of the the Build ( https://docs.microsoft.com/en-us/windows/release-health/release-information ) and NOT the Revision Date.