Situations where maintenance mode is useful/needed:
1. When the system (hardware) is in transit from the location where it was installed to the site where it is to be used in production.
2. When the system is down for other maintenance (software patching and updates, OS configuration changes, hardware reconfiguration and other external factors causing planned or unplanned downtime).
The above outlined method for installing new DPs to remote locations is widely used for various reasons (For example to have a dedicated team at one location install machine and to avoid having to copy a large content library across WAN links). During the time in transit (which is usually between 1 day and 2-3 weeks), the ConfigMgr site server will only know that the DP server is unreachable on the network.

Advantages with a maintenance mode option:
- The status system should/will mark the system as being in the fully expected maintenance mode state (no error condition).
- The log files for components actively working with the DPs will not be cluttered with information about attempts to work on packages targeted to the off-line DP.
- We will not have various error status messages generated regarding the distribution points and its packages during the planned off-line time.
- The Distribution Manager (DistMgr) / Package Transfer Manager (PkgXferMgr) pipe will not be burdened with and slowed down by requests for systems known to be offline.
- Packages targeted to systems that are in the maintenance mode state will not be labeled as failed after the retries are used up, but rather that they are in a “waiting” (for the DP to get out of maintenance mode) state.

The change requested:
The primary ask here is to let DistMgr and PkgXferMgr know that they should not need to work any request targeted to DPs that are in maintenance mode. If they are currently working on such requests, they should stop doing so and postpone the request until the DPs status changes.
It will also be good, if DP systems in the maintenance mode state are not considered when clients make content location requests.

When you use Task Sequences (TS) to deploy software (non OS TS) and there is a reboot inside of the TS there will be no ProgressUI at the logon Screen after the reboot. So you can't see the Progress of the running TS or there is a TS running.
If You logon, after a short time the ProgressUI will start.
We started a MS Case (REG:116092814729429): This is a expected behavior because it's not planned for out of WinPE stage.

Please implement the start of the ProgressUI after the reboot inside of the TS, so we can see the Progress at the logon Screen.

Once the cache has been filled all subsequent application deployments fail until the cache self-cleans. In CAS.log you see that the client is refusing to download the content because the cache, not the actual disk, is full.

This strikes me as a non-optimal design choice if the goal is to successfully install applications. If I want to install an application I do not want it to fail because of an artificial limit that until very recently was set at the time of client install. Most of the time the cache clears in 24 hours and there's no problem but there are two specific and prevalent cases where it is.

Task Sequences: During OSD we want every app and every update applied before the user gets the machine and we want it done quickly. It's very easy to go over a limit that day-to-day is ideal. This has forced SCCM admins to either abandon the application model during TS (a common MVP suggestion) or write custom scripts to temporarily increase the cache. Neither of these are ideal.

Large Applications: There are some applications (ex. CAD) that are just incredibly large (20+ GB) and all their own will exceed what an organization desires to reserve for cache size. Again, admins are either abandoning the app model entirely for these or running temporary cache modification scripts. This simply shouldn't be necessary for a system designed to deploy applicatons.

So, what to do? One option would to implement a rolling (first in, first out) cache where if cache space is needed the oldest non-persistent content for a compliant application is removed to make space. If the new app's content is larger than the cache itself then simply don't cache it. The only hard limit should be on the amount of free disk space to reserve before the SCCM client refuses to download content of any type.

TL;DR: Stop breaking application deployment just because the cache is full. No one wants to troubleshoot app failures.