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.
Problem with running TS OSD from Windows
Hello everyone. I have a problem that I can't solve for a long time... This trouble is happening during with only running TS OSD from Windows (step - Restart in Winpe). If booted from PXE - works ok. I having trouble with a particular model (Acer Veriton Vero B650). There is no problem on many other different models. UEFI. Bitlocker and antivirus disabled. Windows 11 x64 ltsc 2024. SecureBoot enabled or disabled - does not matter. All drivers added to boot.wim Maybe someone has encountered something similar. Could you please explain the mechanism of deployment not from PXE, but from Windows, or help to find out the reason for the impossibility of TS OSD running from Windows (step - Restart in Winpe). apparently the error occurs at the stage of saving bcdMicrosoft Patching is not working until User logon to the newly imaged device
Hi All, I have a customer that they have two separate SCCM and WSUS environments in the same domain and they use SCCM for OS imaging and WSUS for patch updates. The problem is end user hast to logon to the device after imaging the OS using SCCM to kick start the patching process from WSUS. My client's understanding is that it should work without user logon to the device since GPO targeted to all authenticated users. Please also note that the computer objects and other settings are working without any issues. I would appreciate if anyone come across such a behavior and there is any workaround that we can do kick start the patching regardless of user login or is this behavior by design? Thanks, Dilan
SCCM applies DoNotConnectToWindowsUpdateInternetLocations registry during OS install task sequence
Hi, We are facing problem where SCCM 2203 applies DoNotConnectToWindowsUpdateInternetLocations registry key for windows update policies. I went trough all GPO and there is not any policy which apply this setting, but each new laptop or VM installed through SCCM contains this registry key. I did a test and I build as simple Task Sequence for installing Windows 11 as possible without domain without SCCM Client App. Windows 11 is clear image without any customization, just added install.wim into SCCM. Unatended.xml also does not contains this. So this settings must come up from SCCM itselfs. I went through Default Client Settings and also didn't find any item which could be related. Only what I think could be related is "Enable software updates on clients" which I have "No" because I do not want to manage windows updated with SCCM but standalone WSUS. Any idea why fresh SCCM deployed windows, which is workgroup without domain, contains DoNotConnectToWindowsUpdateInternetLocations registry key? (GP cannot be applied) Edit: When I delete this key manually, it is never added again, so it's really just SCCM install task sequence or something which must add it. Simple TS I used for testing if registry key will be applied. ThanksLocal administrator created during OSD doesn't get administrator access
This is an issue at the intersection between application deployment (via task sequence) and operating-system deployment. I have a setup.exe installer (actually, several of them, all part of the same collection - but the issue can be illustrated by talking about just one) which works fine when run as an ordinary local administrator, but fails with error 1619 when run as SYSTEM. As best I've been able to determine, the installer detects that the embedded MSI would be extracted to a location under the Windows folder, decides that's a security violation, and intentionally does things in a way that will result in this error. To work around this, I have created a task sequence (without a boot image) to run the installation as a temporary local administrator account. Specifically, this task sequence has the following series of actions: * A Run Command Line action to create a new local user account, by running 'net user TEMPORARYUSERNAME PASSWORD /add'. * A Run Command Line action to add that user to the local Administrators group, by running 'net localgroup Administrators TEMPORARYUSERNAME /add'. * A Run Command Line action to invoke the setup.exe from its package, with the "run this step from the following account" box checked, the username set to '%computername%\TEMPORARYUSERNAME', and the password entered accordingly. * A Run Command Line action to delete the temporary local user, by running 'net user TEMPORARYUSERNAME /delete'. If I create a deployment of this task sequence to a collection, and invoke it manually from the Software Center, it works; the program is installed as intended, and the user is created and cleaned up along the way. Event Viewer does log a warning (or perhaps an error) indicating having failed to load the user profile for this account, but that doesn't seem to do any harm, and I haven't yet found any way to avoid having it happen. If I then go to an OSD task sequence and add a Run Task Sequence action (after rebooting out of Windows PE and into Windows proper) which invokes the above task sequence, and then deploy that OSD task sequence to a computer, the embedded task sequence fails. More specifically, it gets as far as the action which invokes setup.exe, and then records that the installation failed with error 1603. As best I can determine based on analyzing the logs, the 1603 in this case is a simple "access denied" error, and means that the account which is being used to run the program does not have write access to the install location. However, because the user has been added to the local Administrators group, that user should have Administrator-level access to the entire system - including the install location. The fact that this install succeeds when invoked from Software Center seems to indicate that this user *does* in fact get such access in that environment - but in the post-WinPE OSD environment, it apparently does not. I have gone so far as to add a reboot step in between the step which adds the temporary account to the local Administrators group and the step which invokes setup.exe, in the hopes that the reboot would lead the system to recognize that the temporary account is a member of that group. However, this did not appear to produce any change in the behavior of the setup.exe step. My first question is: How can I get Windows to properly grant local Administrator access (and, as a consequence, write access to the install location) to this user no matter which environment the "inner" task sequence is run from? If there's no apparent way to do that, my second question is: How else can I get this install to run as a non-SYSTEM user with local administrator access? Running as the built-in administrator account itself is not really an option. We manage that account's password with LAPS, so while I know what that password is at Windows install time, as soon as we join the domain (which, for various reasons, will have happened by this point in the task sequence) there's a possibility that the password will have changed; as a result, I can't specify that password in the Run Command Line action.SCOM
hey, I need to ask a question about Transaction monitoring, SCOM2016 Windows server 2016 IE 11 when I click capture it runs IE put without web recorder pane I tried : https://docs.microsoft.com/en-us/previous-versions/system-center/system-center-2012-R2/hh457546(v=sc.12)?redirectedfrom=MSDN and change the registry value for HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\AppPaths\IEXPLORE.EXE but still not open. any advice. thank you for your time. update: I tried Windows Server 2012r2 still negative status. I tried Windows Server 2016 still negative status. I tried Windows 10x64 still negative status.SCOM
hey, I need to ask a question about Transaction monitoring, SCOM2016 Windows server 2016 IE 11 when I click capture it runs IE put without web recorder pane I tried : https://docs.microsoft.com/en-us/previous-versions/system-center/system-center-2012-R2/hh457546(v=sc.12)?redirectedfrom=MSDN and change the registry value for HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\AppPaths\IEXPLORE.EXE but still not open. any advice. thank you for your time. update: I tried Windows Server 2012r2 still negative status. I tried Windows Server 2016 still negative status. I tried Windows 10x64 still negative status.
Error when trying to add windows 11 OS upgrade package to sccm 2203
the specified path does not contain a valid operating system or you do not have permission to access it. please specify a valid path. I do have access to the path as i can browse it and can also add new OS images. Any help on this will be appreciated. thanksStop Updates Deployment during OSD or Upgrade TS
Hi dear community I'm in discussion with our workplace operational teams. They always want me to stop the software update (patching etc.) deployments during the long period of Windows 10 upgrade task sequence deployments because they think it interferes with the upgrade task sequence and leads to many failures. I really don't think that this is a problem. What is your opinion and how do you handle these kind of deployments? Kind regards
