co-managed Working flow
Hi SCCM Expert, I would like to understand how co-management works in a multi-tenant scenario. Currently, my SCCM environment manages devices from two different domains: abc.com → Integrated with ABC Intune Tenant xyz.com → Integrated with XYZ Intune Tenant To enable co-management, we configured the Cloud Attach/Co-Management settings in SCCM using a Global Administrator account from the abc.com tenant. We then created a pilot collection and added devices from both abc.com and xyz.com domains. My questions are: Since co-management was configured using credentials from the abc.com tenant, how can devices belonging to the xyz.com tenant successfully become co-managed and receive Intune workloads from their respective tenant? During the co-management enrollment process, what determines which Intune tenant a device enrolls into? Is the SCCM co-management configuration tied to the tenant used during setup, or does the device use its own Azure AD/Entra ID registration information to identify the target tenant? What is the actual trigger point for the transition from SCCM management to co-management/Intune enrollment? If devices from multiple tenants exist in the same SCCM hierarchy, how does SCCM ensure that each device is enrolled into the correct Intune tenant? Could you please help clarify the architecture and enrollment flow in this scenario?
Windows 11 Upgrade via SCCM Windows Store Apps can not upgrade
I upgrade Windows 11 24H2 to 26H1 with SCCM. I created "Operating System Upgrade Package" and upgrade task. Upgrade successfuly completed. But Wşindows store applications can not be upgrade. Like Snipping Tool. Client does not have access windows store.
Issues to install MECM 2509 (setup could not install sql rmo, configmgr installation)
Hello Team! During the install process of MECM 2509 in a Windows Server 2019 Datacenter Edition OS, it stops by getting the following error message: When i tried to manually install msoledbsql.msi to validate what the error message is, I get the following error: Also, I've already installed a version greater than the error is stating (14.51). It, in theory should continue allowing the install. My ODBC Driver 18 version installed is: So, just for test, when I do uninstall the ODBC Driver 18 knowing that the msoledbsql.msi file will be executed by the MECM installer—thereby ensuring the installer doesn't halt at that stage but proceeds with the setup—but if an ODBC driver is not already installed on the server, the MECM installation will not start; it indicates that this component must be installed in order to proceed with the MECM setup. I'm stuck, since I've already installed sqlncli.msi, msodbcsql.msi (18.5), VC_redist.x64 (14.51) , vcredist_64.exe, SharedManagementObjects.msi, VDP48.exe but failing when MEMC Install is trying to install from the Prerequisite downloaded MECM folder the msoledbsql.msi (ODBC Driver 18) again. Installer should ignore the execution of this file since I've already installed and continue with the install. I don't know what else to do. I've reviewed other forums to try to find a solution but nothing. Someone has faced with this issue in the past who can help me or anyone has any knowledge to enlighten me? Thanks in advance, guys.
Moving from Windows Server 2022 to 2025
And by moving I mean stand up a completely fresh Windows Server 2025 as the old server was patched for one too many times. (painfully slow and stuffy) What I figured out so far, is to install Windows Server 2025, and the exact same SQL Server 1:1 to the build # install ODBC v18 update current MECM to the latest and its OS (update other Microsoft products with windows update) go to sites / maintenance tasks and do an export robocopy the "software" folder as is Now next would be to shut down old MECM server, rename new to the old's hostname, and start the "recover site" What my concern is as always "What if" can I at this point or once I set up the new MECM up and running go back by shutting down this new server, and powering on the old (leave and rejoin domain for trust) and go back to business as usual? That if anything goes sideways, or things won't get better. By that i mean speeding up things which is the main reason of the 'move' which now I do not wish to troubleshoot. Our environment, database size is 7.9 Gb, which is far from being big. The reason must be the update over upgrade over update over 15 years or more no and never brand new OS. I can take care of the "how to" I know exactly how to recover a site 'on paper'. I just want to know there's no such thing as point of no return. (when not making a single change in the Db/console) I also understand I should not make any changes in the Db (console) while testing, which is no problem at all. All we use MECM for is staging computers. Nothing else really. Like nothing else at all. PXE. The end. Thanks for the inputs. (I hope I picked the right tags)Existing required application deployments policy is not sent to devices
I have couple hundred applications in SCCM/MCM that are set to required and whenever there is a new device is built, all these required applications automatically get installed. I am on 2503 and 5 days ago i started seeing this issue. But if modify that deployment with current date and time then the application gets deployed right away if i run Application Deployment evaluation cycle. I also tested by deleting the existing deployment and created a new required deployment and run Application Deployment evaluation cycle then the application installs right away. The problem seems like the Primary server is not sending the policy to the client for existing deployments. The application compliance that we see for every deployment under Monitoring for all the devices moved to Error with Success. Not sure why this is happening. All these changes i noticed in the last one week. A week ago all these Already Compliant and Success status device count is under Success tab. Let me know if you have any suggestions.
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.Applications deployed on device based collection are missing from devices.
Hey guys, In my SCCM environment we are facing an issue. Its a co-managed environment where apps are deployed via SCCM. All of a sudden the apps deployed on Device based collection are not reaching the end user devices. The policies related to these app are also not reaching the device. The compliance status for these apps also went down even though if it is installed on the device the SCCM reports as Non-Compliant\Error. Has anyone faced this issue or can help me to identify what could be causing the issue.
Delivery Optimization breaking Windows 11 update downloads?
We started seeing Delivery Optimization–related issues with Windows updates after upgrading devices to Windows 11 24H2. In our SCCM environment, Windows updates begin downloading but consistently fail or stall partway through the download. In many cases, the download restarts multiple times and eventually errors out. This behavior is consistent across multiple devices and different boundaries. These same devices were patching normally prior to the 24H2 upgrade. Since moving to 24H2, patching has become unreliable, especially for larger updates. From what we’re seeing, this doesn’t look like a traditional content or boundary issue. It feels like Delivery Optimization is failing mid-transfer or not resuming downloads correctly after the OS upgrade. So far we’ve checked the following: - Boundaries and boundary groups are unchanged - Content is available and distributed correctly on DPs - No recent SCCM site or infrastructure changes - Network connectivity looks normal On the client side, we’ve been reviewing: - DataTransferService.log (downloads start but fail or restart mid-way) - DeliveryOptimization logs (showing repeated retries / stalled transfers) - CAS.log and LocationServices.log (content location looks normal) - WUAHandler.log (update detection looks fine) Overall, detection and policy seem healthy — the issue appears during the actual download phase. Has anyone else seen Delivery Optimization downloads stall or fail during Windows patching after upgrading to Windows 11 24H2? If so, did you find a specific DO setting, policy change, or workaround that stabilized patching?Delivery Optimization breaking Windows 11 update downloads?
We started seeing Delivery Optimization–related issues with Windows updates after upgrading devices to Windows 11 24H2. In our SCCM environment, Windows updates begin downloading but consistently fail or stall partway through the download. In many cases, the download restarts multiple times and eventually errors out. This behavior is consistent across multiple devices and different boundaries. These same devices were patching normally prior to the 24H2 upgrade. Since moving to 24H2, patching has become unreliable, especially for larger updates. From what we’re seeing, this doesn’t look like a traditional content or boundary issue. It feels like Delivery Optimization is failing mid-transfer or not resuming downloads correctly after the OS upgrade. So far we’ve checked the following: - Boundaries and boundary groups are unchanged - Content is available and distributed correctly on DPs - No recent SCCM site or infrastructure changes - Network connectivity looks normal On the client side, we’ve been reviewing: - DataTransferService.log (downloads start but fail or restart mid-way) - DeliveryOptimization logs (showing repeated retries / stalled transfers) - CAS.log and LocationServices.log (content location looks normal) - WUAHandler.log (update detection looks fine) Overall, detection and policy seem healthy — the issue appears during the actual download phase. Has anyone else seen Delivery Optimization downloads stall or fail during Windows patching after upgrading to Windows 11 24H2? If so, did you find a specific DO setting, policy change, or workaround that stabilized patching?
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.
