SCCM software update install error 0x8007139F
While trying to install the monthly September patch Tuesday updates, e.g. 2025-09 Cumulative Update for Windows 11 Version 24H2 for x64-based Systems (KB5065426) (26100.6584) and 2025-09 Cumulative Update for .NET Framework 3.5 and 4.8.1 for Windows 11, version 24H2 for x64 (KB5064401) would often fail on many machines with error code 0x8007139F. Every single time this would happen, the update will always install on a retry. That's if the issue happened at all, but it happened on around 60% of the endpoints this month in the test deployment group. It appeared to happen to both updates. Based on the error description, it states that the group. or resource is not in the correct state to perform the requested operation. I couldn't find any documentation of this issue for other people using SCCM. I already tried resetting windows update components, running sfc /scannow, and the DISM restore image command which all completed successfully, but nothing has fixed the issue so far. Any help would be greatly appreciated.
Access collections information locally
Is there a way through WMI/Microsoft.SMS.Client comobject to access information from the computer if is in a collection (cached information or otherwise)? I'm not sure if a computer gathers that information somewhere. I can't access that information on the site server or through the AdminService as the account running the commands would be the SYSTEM account. My goal is query if a computer is in a collection and install a piece of software through a task sequence.
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.