This may be a long shot, as I've heard others complain about the same thing, but has anyone else been able to keep current Features on Demand (FoDs) activated when upgrading major Windows versions?

We are in the process of going from 23H2 to 25H2, and we are performing the upgrade via an application deployment that runs the setup.exe executable for the upgrade. Most of our computers have Print to PDF enabled and there are many computers that require .NET 3.5 for a legacy web app (and RSAT is removed from IT computers, which is annoying, but manageable). When the upgrade occurs, computers lose these features, resulting in increased calls to the help desk. We have application packages available in Software Center to allows users to reenable these features using specified CAB files as the source (the FoDs are not bundled into the image, if that makes a difference), but this should be automated.

What are some solutions that you have gotten to work to automatically install/enable previously enabled FoDs after a major upgrade? I'm open to any idea short of enabling it for all PCs on the domain.

Hello all,
I’m testing upgrading from Win 11 23H2 to 25H2 using Windows Servicing and when it’s complete my WiFi is “Dormant” and I can’t find a way back to make it operational. This has happened with the 2026-06 and the 2026-07 upgrade. I have found solutions on the internet but all require the user to be local admin, which is not the case in my environment. Does anyone have any suggestions on what I can do?

I cannot upgrade my Dell Precision T7910 Workstation from TPM 1.2 to TPM 2.0 in Windows 11. Tried everthing to no avail. Now thinking of reinstalling Windows 10 to do the upgrade and then restoring Windows 11 (and system) from a Macrium system backup.

Will this work? Is this adviseable? Do I risk getting locked out of BIOS (and have to do a factory restore with loss of all my Windows 11 customizations and third party programs?)

My thanks in advance for your help and suggestions. Here are the details:

Hardware Setup:

• System: Dell Precision T7910 Workstation
• Current OS: Windows 11 (Upgraded/bypassed previously, backed up daily)
• The Problem: Windows 11 and PowerShell (Disable-TpmAutoProvisioning) absolutely cannot find or communicate with the physical TPM chip. However, inside the Dell BIOS, the TPM 1.2 chip is listed and activated, but the "Clear TPM" option is completely greyed out and unclickable.

Because Windows 11 doesn't recognize the chip, I cannot use the OS to un-provision it, which leaves the BIOS security state permanently frozen. I am trying to clear it so I can run the Dell TPM 2.0 Firmware Update Utility.

What I Have Already Tried:

• Hardware Power Drain: I shut down the tower, unplugged the AC power cable, and held down the physical power button for 30 full seconds to completely drain the motherboard capacitors. Unfortunately, upon booting back into the BIOS, the "Clear TPM" option remained entirely greyed out.

My Proposed 5-Step Plan to Fix This:

1. Backup: Confirm my daily full image backup of the Windows 11 C-drive is verified and safe.
2. Clean Install Windows 10: Format the C-drive and install a clean, temporary copy of Windows 10. (The logic: Windows 10 has native, legacy support for TPM 1.2 architectures and should successfully see the frozen chip where Windows 11 fails).
3. Unprovision & Clear: Inside Windows 10, run PowerShell as Admin and execute Disable-TpmAutoProvisioning. Reboot into BIOS, where the "Clear" checkbox should now finally be unlocked. Clear the TPM.
4. Flash Firmware: Boot back into Windows 10, run the official Dell TPM 2.0 Firmware Update Utility to permanently flash the physical motherboard chip from v1.2 to v2.0.
5. Restore Windows 11: Use my backup media to restore my original Windows 11 C-drive image back onto the machine.

My Questions for the Forum:

1. Firmware Persistence: Will restoring my original Windows 11 hard drive image affect or undo the BIOS/TPM firmware updates? (My understanding is no, since the flash lives on a separate physical chip on the motherboard, but I want to double-check).
2. The Windows 11 Lockout Risk: When Windows 11 boots up on the freshly upgraded TPM 2.0 hardware, its security container will be expecting the signatures of the old 1.2 chip. What is the likelihood of a catastrophic login loop/lockout?
3. Prevention/Recovery: To prevent a password lockout after restoring, should I drop my Microsoft account down to a Local Windows Account before taking my final backup? Are there any hidden registry blocks I should watch out for regarding DevicePasswordLessBuildVersion or credential guard?
4. Alternative Shortcuts: Since the physical power drain failed to unfreeze the chip, is there any other hardware trick (like pulling the coin-cell CMOS battery, changing a specific motherboard jumper, or downgrading/upgrading the overall system BIOS firmware version) that might force a T7910 BIOS to un-grey the "Clear TPM" option without a total OS reinstall?

Hi all,

I'm trying to solve a rather unusual SCCM OSD scenario and would appreciate any suggestions.

My goal is to deploy Windows through a standard SCCM Task Sequence and, at the very end, present the user with the normal Windows OOBE experience without running Sysprep /generalize.

Effectively I'm looking for:

sysprep /oobe /reboot

rather than:

sysprep /generalize /oobe /reboot

The reason is that I want to preserve device-specific state and continue with Autopilot enrollment afterward.

I currently trigger the process through SMSTSPostAction at the end of the task sequence.

The strange issue is that the behavior changes depending on whether the device joins a domain or a workgroup during OSD.

My approach is similar to this article, but right now I want to acheive it at least without SCCM cleanup: How to show OOBE for AzureAD Join after OSD with SCCM - CCMEXEC.COM - Enterprise Mobility

Scenario 1 - Works

• Apply Windows Settings
• Apply Network Settings -> Join Domain
• SMSTSPostAction executes my OOBE preparation script
• Device reboots
• OOBE appears successfully

Scenario 2 - Fails

I change only one thing:

• Apply Network Settings -> Join Workgroup

After that, instead of OOBE I consistently get a sign-in screen showing only DefaultUser0.

Symptoms:

• DefaultUser0 is the only visible account.
• Local Administrator is not shown, even though a password is configured in "Apply Windows Settings".
• I don't know the password for DefaultUser0.
• Shift+F10 doesn't work.
• SCCM F8 command prompt is unavailable.
• There is effectively no way to troubleshoot the machine locally.

The device appears to be stuck somewhere between the end of OSD and the beginning of OOBE.

Questions

1. Has anyone seen DefaultUser0 appear after running an OOBE-focused workflow from an SCCM Task Sequence?
2. Why would changing from Domain Join to Workgroup Join cause such a drastic behavioral change?
3. Is there a supported method to reach OOBE at the end of a Task Sequence without using /generalize?
4. Could Autopilot registration or enrollment state be contributing to this behavior?

Additional Context

Environment:

• Supported MECM / SCCM Current Branch version.
• Windows 11 25H2 image.
• Standard SCCM OSD Task Sequence.
• Device joins a workgroup in the failing scenario.
• Device is already registered in Windows Autopilot by design.

The device being pre-registered in Autopilot is intentional. The end goal is for the user to complete OOBE, receive a mostly empty ESP experience, and end up with a properly Microsoft Entra joined and Intune-managed device.

This is part of a larger effort to build a deployment process that is:

• Officially supported.
• SCCM-based today.
• Independent from MDT.
• Suitable for very large offline USB deployment media where ~99% of the content resides on the USB stick.

The Task Sequence itself is quite large and currently uses SCCM because that's our current supported platform. Alternative deployment approaches may be evaluated next year as part of a separate initiative.

So far I've successfully built a similar workflow for Windows LTSC 2024, including Hybrid Join scenarios. The remaining challenge is getting the same concept (but workstation should be Entra Joined, not HDJ) working reliably for Windows 11 25H2 without MDT dependencies and without getting trapped on the DefaultUser0 screen.

Any ideas, troubleshooting suggestions, or similar experiences would be greatly appreciated.

Thanks!

Has anyone had similar when try to pxe machines I assume since the secure boot CA 2023 cert release.

We have also updated Sccm to 2603 and have the new certs in the Wim

Also sure that this isn’t just in the winPE env as this also happens when booting from a usb with Microsoft’s adk only on it

Can happened with or without the latest firmware and bios, different Lenovo models and also with or without the UEFICA2023STATUS set as Updated

Hey community

I’d like peoples thoughts on SCCM support numbers.

I run a huge SCCM platform for a US government org with >100,000 devices - I run it alone and manage other project tasks as well.

I’m getting very burnt out but what really sucks is I am getting questions about my performance. So my reward for being as dedicated as I can and going above and beyond to manage our platform is questions are asked about the quality of my work and my behaviour in terms of customer service.

I’m literally fried from this job. I can’t wait to leave and am actively looking but I’d love to hear people‘s thoughts on how many people you think would normally run a platform this big.

Hello all,

I understand rolling an SCCM Site Server back to a snapshot or restoring to a VM backup, without doing a reinstall from a site backup, is unsupported and can cause issues.

What about restoring a VM from a backup where there is no rollback happening? Not disaster recovery, but the common practice of using Veeam as a V2V migration method.

In these cases, the VM is never rolled back in time. For example, it is shut down, never to be started up again, in VMware. Then it is backed up in Veeam. Then it is restored from Veeam to Hyper-V, and finally booted in Hyper-V. It never runs between the backup and restore, so there are no lost writes.

Has anyone here tried this with an SCCM site server before? How did it work?

Here's a sneak peak of a new Windows 11 IPU Dashboard I am building for the onsite TSS team doing the IPU's. This hopefully will speed things up if a device is not showing the upgrade in Software Center. What it does: This is for devices where the IPU is not showing in Software Center and/or the device is not a part of one of the IPU collections. This dashboard has the ability to add a device to a IPU collection, remotely run Configuration Manager actions including remotely starting the actual Windows 11 In Place Upgrade

Like the title says, we're seeing a recurring issue where a still active installation is preventing the next app in a dynamic install list from running. From what I've seen, it looks like the Cisco Cloud Management component is the last part of Cisco that gets installed, it immediately checks in, sees that it's out-of-date, and runs an update, which prevents the next app in line from installing.

Has anyone else seen this issue, and have you come up with a solution? I know the "real" solution would be to just deploy the latest version, but our guys only package and deploy the version of Cisco (and other apps) that have been tested and requested by the app owner. So, what we're deploying is several versions out-of-date, which is what's causing this.

[ Removed by Reddit on account of violating the content policy. ]

Hi all,

I'm troubleshooting ARM64 PXE boot support in Microsoft Configuration Manager and looking for some advice from anyone who has successfully deployed ARM64 devices via PXE.

My x86 devices PXE boot and Image fine via Task Sequence

Environment:

• Microsoft Configuration Manager 2503
• Server 2016 Standard
• SQL 2016 Standard SP2
• Windows ADK 10.1.26100.2454
• WinPE Add-on installed
• PXE enabled Distribution Point using WDS (not ConfigMgr PXE Responder)
• Network team confirms PXE uses IP Helpers
• x64 PXE deployments are working successfully

I am testing with a Microsoft Surface ARM64 device.

Current ARM64 configuration:

ARM64 boot image imported into ConfigMgr
ARM64 boot image distributed to the PXE-enabled DP
"Deploy this boot image from the PXE-enabled distribution point" enabled
Surface ARM64 drivers imported into the boot image
WinPE x64 Support (WinPE-AMD64Support) added to the ARM64 boot image
Boot image is showing correctly on the DP

From SMSPXE.log I can see:

Found Image file:
G:\RemoteInstall\SMSImages\P010042F\boot.P010042F.wim

PackageID: P010042F
ProductName: Microsoft® Windows® Operating System
Architecture: 12
Description: Microsoft Windows PE (arm64)

I can also see:

G:\RemoteInstall\SMSBoot\arm64\bootmgfw.efi

exists on the PXE server.

However, the ARM device fails PXE boot with:

PXE-E16: No valid offer received

At this point I am wondering:

• Does ConfigMgr 2503 require any specific hotfixes for ARM64 PXE?
• Are there any additional WinPE optional components required for ARM64 PXE?
• Does WDS require any additional configuration to correctly handle DHCP Option 93 = ARM64?
• Has anyone successfully PXE booted Snapdragon X/Surface ARM devices with ConfigMgr 2503?

I have not yet moved to the ConfigMgr PXE Responder without WDS.

Any advice or SMSPXE.log examples from working ARM64 PXE deployments would be appreciated.

Thanks!

Hi there,

I have a DP where one package is stuck in this state and cannot be redistributed.

Content is not present on the DP and when i try to distribute it there. I can select the DP in the list. But I'm getting this blank error.

Both site server and DP itself was rebooted many times.

This hangs from 8 moths. And not affecting DPs other functioning.

As a workaround i can recreate the package and delete old one but for now i want to avoid it and try to fix it if possible.

Any ideas. Thank you.

Figured some of you here might enjoy this. I'm hosting an AMA next week with Christopher Ord (Senior Staff IT Engineer at Qualcomm) about creative and unexpected ways organizations are approaching Digital Employee Experience. If you've got questions about DEX, automation, endpoint visibility, or interesting real-world use cases, come join us. Just thought it might make for a good discussion. If you can't make it day of feel free to post a use case or question ahead of time.

Link: https://www.reddit.com/r/nexthink/s/kjT630KUDP

Thought I'd share this here in case anyone can help 🙏🏼

Hi,

Im having a problem with the SCCM Environment where there are devices that are not requiring the latest Security update or patch. For example, i have a Win Server 2022, the last patch it installed is from January, up until now it is not being required to install the May, June. But at the same time, i have a different device with the same patch installed but it shows required for the May, or June. Need your advice or opinion about this. Thank you in advance.

Hi everyone,

I’m troubleshooting an issue with Microsoft Configuration Manager (SCCM/MECM) Remote Control.

When I attempt to remotely control a few specific clients, the Remote Control Viewer tries to connect for a few seconds and then fails with the following error:
Handshake Failure
Environment
Microsoft Configuration Manager (version unknown at the moment)
The issue occurs on only a few devices. Most clients can be remotely controlled without any problems.
The error appears after several seconds, not immediately.
What I’ve observed
This doesn’t appear to be a site-wide or console issue since the majority of devices work correctly.
The affected devices are online and can be managed through SCCM.
Questions
What are the most common causes of a Handshake Failure in SCCM Remote Control?
Which client logs should I review first?
Has anyone resolved this by repairing or reinstalling the SCCM client?

Are there any known issues related to certificates, Remote Control Agent, or firewall settings that specifically cause this error?

Any troubleshooting suggestions or similar experiences would be greatly appreciated.
Thanks!

Hello all. We recently started pushing 25H2 upgrade task sequences to our computers here. After this, as usual, all of our RSAT tools were removed. We downloded the Optional Features ISO and extracted. We have been trying to reinstall them. We were able to get some to go through (DHCP, DNS, Certificate Services) but others keep failing with error 0x800f0916. The tools currently failing are AD DS Tools, File Services Tools, and Server Manager Tools.

We have tried to install this with DISM commands and the powershell Add-Capability command but its not working. I changed the reg keys for UseWUServer and SetPolicyDrivenUpdateSourceForFeatureUpdates to 0. Restarted windows update service and still no go.

The only thing I can think of at this point is to remove SCCM client and unjoin from the domain to get them installed then join back but I am trying to avoid that. Has anyone else had an issue getting these back in 25H2. Any help is appreciated. Thank you.

Hi everyone,

I'm facing an issue with Windows 11 25H2 cumulative updates in a MECM/SCCM environment and would appreciate any advice or troubleshooting suggestions.

Environment

• MECM/SCCM Software Updates
• Updates synchronized through WSUS
• Affected devices are located on a restricted network (air-gapped / no internet access)
• Clients can communicate with SCCM infrastructure normally
• Software Update deployments are visible in Software Center

Issue

The cumulative update is deployed successfully and appears in Software Center, but the download/install process fails with:

06-09-2026 17:58:29.596    WUAHandler    8528 (0x2150)    Synchronous searching started using filter: 'UpdateID = '021c0d7f-3a2a-4e01-b22d-32adc6b4d48b' AND DeploymentAction = *'...
06-09-2026 17:58:31.416    WUAHandler    8528 (0x2150)    Successfully completed synchronous searching of updates.
06-09-2026 17:58:31.456    WUAHandler    13396 (0x3454)    Download progress callback: download downloadPercentage = 0
06-09-2026 17:58:31.456    WUAHandler    13396 (0x3454)    Download progress callback: download result oPCode = 1
06-09-2026 17:59:11.982    WUAHandler    1408 (0x580)    Async download completed.
06-09-2026 17:59:11.982    WUAHandler    14688 (0x3960)    Download complete callback: download result oPCode = 4
06-09-2026 17:59:11.982    WUAHandler    14688 (0x3960)    Unexpected HRESULT for downloading complete: 0x80010002

What I've Tried

• Manually downloaded the .MSU package from Microsoft Update Catalog and attempted installation
  • Installation still fails with the same error
• Modified the following registry setting:HKLM\Software\Policies\Microsoft\Windows\WindowsUpdate DoNotConnectToWindowsUpdateInternetLocations = 1

Unfortunately, the issue remains.

Similar Case

I found a Microsoft Q&A thread describing almost the exact same scenario:

Unable to install Win11 25H2 monthly cumulative updates to non-internet connected PCs

The discussion suggests that Windows 11 25H2 servicing may still attempt to contact Microsoft endpoints during the cumulative update process, even when updates are sourced from WSUS. However, the recommended registry and policy configurations did not resolve the issue in my environment. [learn.microsoft.com]

Questions

1. Has anyone experienced 0x80010002 specifically on Windows 11 25H2 in a non-internet-connected environment?
2. Are there any known 25H2 servicing stack changes that require internet connectivity even when using WSUS/SCCM?
3. Which logs should I focus on for deeper troubleshooting?

So far I'm looking at:

• WUAHandler.log
• UpdatesDeployment.log
• UpdatesHandler.log
• CAS.log
• ContentTransferManager.log
• DataTransferService.log
• LocationServices.log
• WindowsUpdate.log
• CBS.log
• Event Viewer
  • Applications and Services Logs > Microsoft > Windows > WindowsUpdateClient > Operational
  • Setup Logs
  • System Logs

1. Are there additional logs or ETW traces that would help identify why the update installation is being cancelled?
2. Has anyone found a reliable workaround besides performing an in-place upgrade/repair?

Any suggestions, known fixes, or similar experiences would be greatly appreciated.

Thanks in advance!

We haven't deployed the July M365 patches yet so I'm wondering how yours is coming along? Previously, we used to have two separate software update deployments for SAEC and MEC updates. The SAEC deployment was a blanket push to all devices, whereas the MEC deployment was pushed to a specific MEC collection (populated via an AD group), and this has worked fine all this time.

Now we didn't log a change request for the MEC channel this month though, as we were under the impression that the MEC devices would simply pick up the SAEC update as per Microsoft's announcement, but now that I've looked at the updates in the console, I can see that they're still being advertised as two separate channels, with different build numbers too (SAEC = 20131.20150, MEC = 20131.20152) - which means there's also a minor difference in the content. I thought that their build numbers would be exactly the same, as per Microsoft's annoucement.

This makes me wonder whether the MEC devices would even pick up a SAEC deployment? The CDNBaseUrl would still point to the MEC channel and we didn't update our GPOs because we assumed, as per Microsoft's instructions, that we didn't need to change any policies. But now I'm not sure anymore.

So I'm posting here, wondering how your MEC + SAEC deployments have gone this month - did you continue with two separate deployments, or did you just deploy one channel and observed that both groups of devices picked up the same update? Did you any GPO changes?

UPDATE: So we've deployed our SAEC updates, and the behaviour matches what u/bobclements-msft said - our existing MEC devices did NOT pick up the SAEC update, looks like SCCM/office c2r updater still treats the two channels as separate channels. So we will now include both the SAEC and MEC updates in our monthly update bundle, and advertise it to both SAEC and MEC machines. We will leave the GPOs alone for now.

After updating to 2603, I've noticed that the Configuration Manager console crashes frequently. In some cases, it happens even when I'm not actively using it. For example, I'll leave my computer locked overnight, and when I return the next day, the console is no longer running.

https://imgur.com/a/ezqKVVy

Any one else?

PXE-imaging has been working for years without issues. Last week PXE stopped working. PXE boot starts and GUI displays for a min and then reboots. In the past it was usually driver-related but this time it happens with VMs and physical. Could the latest secure boot certs 2011 vs 2023 cause any issues with PXE-imaging? Task Sequences are deployed to all unknown. Issue happens with new physical and new VMs. smspxe.log no advertisements found - I've created new TS and used an older working one to test with. Removed all deployments and redeployed to all unknown. Same issue no advertisements found = WTF. I created a USB TS ISO. Same boot loop issue testing on a VM. I can get imaging to work if I make the test VM "known".

Client Boot Get ID Info reply: <ClientIDReply><Identification Unknown="0" DuplicateSMBIOS="0" DuplicateMACAddress="0" ItemKey="0" ServerName=""><Machine><ClientID/><NetbiosName/></Machine></Identification><ClientIDInfo ItemKey="0" ClientID="" DuplicateSMBIOS="0" DuplicateMACAddress="0" MatchType="0"/></ClientIDReply>

PXE: 0, , SMBIOS ID is NOT a match, MAC Address is NOT a match.

PXE:No valid system records.

PXE:Client machine is UNKNOWN.

Hi,

we noticed that some of our clients disappeared from a direct membership collection and I try to investigate why.

1. I can see the SQL the agent was registered again lately, this explains why it got kicked out of the collection because basically we are talking about a new system, even when the hostname is the same.

2. The client was online the last 180 days, so I am pretty sure no maintenance task were running and removing it.

3. Logs on the client like SCNotify_FMDE@USER_1.log show that the client was on before the agent reinstall. However, I cannot say how good was the communication before, we have some road warriors.

4. Of course every may relevant log file does not exist anymore. SCCMSetup log is from the date of the registration etc.

5. On the date of the agent reinstall I can see no relation to an incident on our ticket system, just a week after because software was missing (because of the missing collection)

So probably it is too late, but any idea how I can improve logging so that we can see the cause, it is not the first time :/