MECM OSD TS Application Installations fail randomly to download content.

We are experiencing a persistent and well-documented issue with MECM OSD Task Sequences where Applications randomly fail to install after the MECM client has been installed. This behavior seems to affect many environments and has been an ongoing problem for years, yet a definitive solution remains elusive.

In our case, we have over 30 Applications included in the OSD Task Sequence. Despite implementing all commonly recommended mitigations—such as inserting an additional restart after the MECM client installation and including a two-minute delay before the Application install task group begins—we still encounter random failures. The issue is not limited to any specific Application; it can be any one of the 30+ Apps, and the failure to download appears to occur entirely at random. Occasionally, most of the Applications install successfully, and only one will fail, which subsequently causes the entire Task Sequence to fail with the same error.

Importantly, all of these Applications install without any issues post-OSD, further confirming that the problem lies not with the Applications themselves but with the process during the Task Sequence. The randomness of which App fails also suggests an underlying process, feature, or timing issue—not an App configuration problem.

We have thoroughly validated all related infrastructure settings:

• Boundaries and boundary groups have been triple-checked.
• No boundary is assigned to multiple groups.
• Site system assignments are correct.
• We are using PKI certificates and HTTPS, and the client authentication certificate is present on the device at the time of failure.
• The issue has been replicated across both Windows 10 and Windows 11, ruling out any specific cumulative updates or OS version anomalies.
• No additional language packs are being installed—only language fallback is applied via the "Apply Windows Settings" step.

One suspicious observation is the lack of any reference to our local Distribution Point in the LocationServices or CAS logs during failure events. Initially, this pointed to a possible boundary misconfiguration, but after multiple checks, no issues have been identified.

Unfortunately, we are unable to use the common workaround of converting Applications to Packages, due to internal policies and deployment requirements. Therefore, we need to resolve this while continuing to use Applications in the Task Sequence.

Given the number of years this issue has persisted across customer environments, it's surprising there isn’t more formal guidance or documentation available to help isolate the root cause. If anyone has encountered a similar scenario or has any advanced troubleshooting tips, we would greatly appreciate your insight.