MCM Version 2509 - 5.2509.1036.1700

I just noticed this yesterday when trying to get to the Microsoft 365 Apps Upgrade Readiness page but the console will crash when trying to access that page or seemingly anything else that uses the webview2 runtime extension. The entry in SmsAdminUI.log is:

[1, PID:2408][10/27/2026 08:52:16] :System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> System.InvalidOperationException: The WebView control is no longer valid because the browser process crashed.To work around this, please listen for the CoreWebView2.ProcessFailed event to explicitly manage the lifetime of the WebView2 control in the event of a browser failure.https://docs.microsoft.com/en-us/dotnet/api/microsoft.web.webview2.core.corewebview2.processfailed

Then ~30 sub error entries.

The installed Microsoft Edge WebView2 Runtime app was 155.0.4283.62 when I first took a look but upgraded on its own(?) to 156.0.4314.50 while I was troubleshooting. The update didn't seem to solve the issue, unless I need to reboot the server?

I looked at the link in the error but .NET/C# stuff is above my paygrade so any dummy-friendly troubleshooting tips out there I could try?

Thanks

Hello everyone,

I'm starting to get a problem with some brand new computer I received from HP. When I image those computer using SCCM task sequence, everything goes well until it get into the OS. Once it receive GPO, it restart and we get bitlocker trigger.

We found on the HP website that it's because of the Secure Boot Certificat. It's as if the computer take the wrong certificat:

https://support.hp.com/us-en/document/ish_13070353-13070429-16

We are using official W11 enterprise wim (untouched) when imaging and all boot image are signed using the 2023 certificate in SCCM (checkbox is enabled and image are updated).

I've used Garlin's Powershell Script to verify all my wim and they all have 2023 certs

https://www.elevenforum.com/t/garlins-powershell-scripts-for-updating-secure-boot-ca-2023.43423/

I began to make some test. When I image the computer, if the 2011 certficate isn't enabled in the BIOS, it get enabled (probably by SCCM). Once it get into Windows, the status for the certificate is that it's not updated (even if it's present) and then the GPO to update it get triggered, the secure boot certificate change and it trigger bitlocker. And that's even when all 2023 certificate are already enabled.

https://support.microsoft.com/en-us/servicing/os/secure-boot/2025/09/group-policy-objects-gpo-method-of-secure-boot-for-windows-devices-with-it-managed-updates

If I disable the GPO, the problem go away. But my isssue is why is it using the old 2011 certificate in the first place?

I'm on SCCM 2603 latest KB with ADK 2454.

Thank you

Edit: Adding info cause the question get repeated many time. First, I was able to reproduce the problem on other computer.

While in WinPE, before starting the TS.

Processing img 8t5iz2h2f0yh1...

This show the secureboot already contain the 2023 UEFI certificate.

BIOS SecureBoot:

Processing img c8lb7g3bf0yh1...

As we can see, the 2023 is the only checked before running TS

Using Garlin's Powershell to detect computer and boot media certificate (https://www.elevenforum.com/t/garlins-powershell-scripts-for-updating-secure-boot-ca-2023.43423/)

install.wim used

Processing img q1sgnue4h0yh1...

WinPE

Processing img oy0yqewcg0yh1...

While in WinPE through PXE

Processing img 68jc8pbdh0yh1...

So at this point, it shows that the BIOS on that computer does have the UEFI 2023 cert and that both the boot image and the install.wim contain the 2023 certs. The BIOS as showed in first picture is configured to boot only with 2023 cert.

After the Task Sequence Start. We update the bios (if update is available, already latest version here), then we wipe the disk and then partition like this for HP

Processing img jrv9fiwuk0yh1...

Dell is the same without the hp partition

After it's partition, we install the official september 2026 Win 11 25H2 wim, then configure windows and network step, inject driver using DAT and then step "Setup Windows and ConfigMgr" which reboot the computer.

At that time, when the computer reboot, with the BIOS configured as previously mentionned, the PC will have 2 BIOS Reboot. So, TS => Reboot => Bios Screen => Reboot => Bios Screen => Reboot => Bios Screen.

If I enter the BIOS right now, this is how Secure Boot is configured:

Processing img n16lvpbgl0yh1...

As you can see, the 2011 Certificat is now enabled.

Let's continue the TS and run the script during the TS, after the sysprep during the OS Phase

Processing img uru6ihcot0yh1...

We see Windows Boot Manager is using 2011 now. WHY? Install.wim is with 2023, bios is 2023 ready so what give?

Bear in mind, I reproduce this on any HP computer that have already working OS by configuring the BIOS to not use the 2011 during the TS.

Has anyone experienced anything similar? I've been working with copilot and it basically told me to open a ticket.

Active directory user discovery works
Active directory system discovery works
Active directory group discovery works for systems, not users

Copilot:

The latest adsgdis.log also demonstrates that the Group Discovery agent is actively generating MPE discovery messages, adding users to payloads for groups where it recognizes membership, updating group membership tables, and queueing those discovery messages.

My conclusion

We've isolated this far enough that I would stop troubleshooting collections, SQL blocking, DDM backlog, or the user resource.

Your evidence is:

• AD on [DC] directly reports [domain user] in the raw member attribute of [domain group].
• ConfigMgr's [domain user] resource has the correct SID, GUID and DN.
• ConfigMgr's [domain group] group resource exists.
• A full AD Group Discovery was performed.
• ConfigMgr still reports:

Plain Text

[resource id] [domain user] NULL

• The current adsgdis.log proves Group Discovery itself is capable of adding users to MPE payloads for other groups. For example, it explicitly adds individual user payloads for [domaingroup]and [domain group].
• Independently, 1,296 of your 1,297 AD group resources were recreated on October 22, immediately after the 2603 → 2609 upgrade.

My working diagnosis is therefore a post-2609 AD Group Discovery membership enumeration failure, with the upgrade correlation being strong but not, by itself, proof that 2609 contains a general product defect.

I would preserve your current logs and SQL results for Microsoft support. In particular, don't delete/recreate [user] or manually modify the ConfigMgr database.

Hi All,

I have a number of devices that do not have the SCCM client for whatever reason, so that's the first thing I need to resolve. The second piece to this is that the SSD's to these devices are filling up from all the new creations of the installer.

Any tips on what to look for or recommendations to atleast stop this from filling these drives?

Anyone seeing HTTPS/PKI PXE issues after ConfigMgr 2609 + September 2026 ADK?

Our previously working setup:

ConfigMgr 2509 (5.00.9141.1000) + KB36949461

ADK/WinPE 10.1.26100.2454 (December 2024)

ADK serviced with KB5101684

ConfigMgr PXE responder without WDS

HTTPS-only site

PXE/OSD working normally

We upgraded to:

ConfigMgr 2609 (5.00.9152.1000)

SCCMPXE 5.00.9152.1003

ADK/WinPE 10.1.26100.9457 (September 2026)

Microsoft lists the September 2026 ADK as replacing 10.1.26100.2454 and supports the 26100.x ADK releases with ConfigMgr 2609. Interestingly, all 26100.x releases use WinPE 10.1.26100.1 binaries; the Deployment Tools changed between releases.
Since the upgrade, PXE receives and correctly parses UEFI x64 requests, but SCCMPXE fails communicating with the HTTPS MP:
SSL, using authenticator in request.
In SSL, but with no client cert.
Sending with winhttp failed; 80072f9a
Unsuccessful in getting MP key information. 0x80072f9a
PXE::MP::InitializeTransport failed; 0x80072f9a
PKI checks out:
DP ClientAuth certificate valid, private key present

Correct Client Authentication EKU

Full chain + CRL validation passes

Certificate correctly registered in ConfigMgr, approved and unblocked

IIS ServerAuth certificate/binding valid

Reimporting the DP PFX and restarting SCCMPXE makes no difference

The really odd part: MPControl on the same server selects the exact same ClientAuth certificate, connects to the same HTTPS MP and gets HTTP 200.
So essentially:
MPControl -> ClientAuth cert -> HTTPS MP -> 200 OK

SCCMPXE -> "no client cert" -> same MP -> 0x80072F9A
Anyone else seeing this after ConfigMgr 2609, particularly with HTTPS/PKI and the September 2026 ADK?
Starting to suspect a ConfigMgr 2609 PXE certificate/state regression rather than WinPE itself.

I was going through some articles and our environment, was checking clients last online time and activity status. I found

1. There are devices having the last online time within the last 7 days, but inactive.

2. Few devices for which the last online time is beyond 7 days, 3 months, 1 having last year last online time and for few even it's blank but the client is ACTIVE.

I have gone through the articles and got that last online time is synced using client notification channel (CcmNotificationAgent, Fast Channel) and for Activity status, 5 criteria (Policy Request, Heartbeat Discovery, Hardware and Software Inventory, State Message) which should be passed (7 days in our case) to keep the client as active.

But I want to get clarity on:

How Active devices for which last online time is beyond 7 days, are showing active as client sends online activity status using client notification channel in about every 5 minutes via MP only but not sending policy requests and other client status settings...?

How can MP be used for activity status and fail to update last online time?

I've tried various troubleshooting steps without being able to fix the issue. The workaround is to switch to using the browser extension. The article doesn't mention any future plans to fix the issue, but I would assume using the browser extension isn't the permanent fix. Does anyone have more info about an upcoming fix? Has anyone figured out away to restore functionality when resetting the licensing and reinstalling doesn't fix?

https://docs.recastsoftware.com/help/right-click-tools-greyed-out

KNOWN ISSUE (identified October 7, 2026)

Customers and Community users who upgrade to Configuration Manager version 2609 may see Right Click Tools menu items greyed out in context menus when using the console extension.

Workaround: We recommend running actions via the Right Click Tools browser extension for Edge or Chrome.

Our company is not a M365 suite and we are looking for options to enroll devices.

I've come across options such as Action1, Workspace ONE, ScaleFusion, etc.

What I don't understand is the best possible way to enroll these devices instead of doing it manually.

I've seen imaging software such as Windows Configuration Designer and OSDCloud.

What might be the best way to get devices enrolled so I can push apps, security policies, package software such as GCPW, etc.

Every release at work went the same way. Change the main task sequence in QA, test it, then rebuild the exact same steps by hand in the Prod task sequence. Different hierarchy, different package IDs, so copy and paste across environments doesn't work. Miss one reference and the next build breaks.

So I built TS Splice. You export both task sequences from the console, open them side by side, and drag the steps (or whole groups) across. It:

- matches packages between environments by name and swaps in the right IDs (you can pair any it can't match by hand, and it remembers)
- marks what's different between the two (only here / differs / same / copied), with a differences-only filter
- warns before export about packages it couldn't map, variables nothing sets, and child task sequences
- writes a new export zip, reads it back and checks it before calling it done. Files you didn't touch stay byte-identical. It never overwrites the zips you opened.

Then you import it with the normal import wizard. My advice: copy the target TS in the console first and import over the copy, not the real one.

It's fully offline. It works only on the export zips on your PC and never touches your site, the console or the database. No account, no telemetry. It's a single exe and doesn't need admin.

What it doesn't do yet: application references in Install Application steps are copied but not translated (each one is flagged so you can fix it after import).

Disclosure, same as last time: I'm the dev, this account is just for my tools, and I used AI coding tools to help build it. The workflow comes from doing this by hand every release.

It's a free, invite-only beta. Builds are licensed to you and expire after the beta. The first beta builds go out in November, code-signed. If you do QA to Prod promotion (or any "same change in two task sequences" work), email [support@lampbench.com](mailto:support@lampbench.com) with your role, roughly how many task sequences/environments you maintain, and your Windows version. Beta testers get founding pricing when the paid version launches.

What I really want to know: does it handle your task sequences? Weird step types, nested groups, conditions, anything that breaks the export or the import. Failures are more useful to me than "looks cool."

lampbench.com/tssplice

I'll be around in the comments.

Hello everyone,

About a 2 weeks ago, I uninstalled the SCCM client of our SCCM Site Server. We do not manage Server OS with SCCM (another team manage the server environnement with their own tool) and the clients were installed during a support call with MS a while ago.

I notice today that all server have their client back. I don't get why, according to log it happen about 7 days after I uninstalled them. I checked SCCM CLient Push, not enabled. I checked SCCM client through Windows Update, not enabled. I don't get why they got installed. Any clue?

Thank you

I can build laptops in other locations successfully but not in the IT Office, it “looks” like the switch seems to fail the laptops at about the same place in the build.

The sccm log files seem ok but the log on the laptop shows an error (I’ll have to find it again) but when look it up in CMtrace is basically nods towards communication fail.

I have tried different Ethernet adapters, laptops and task sequences but it still fails (sometimes in different places, even at the start when checking the dependencies etc). Definitely seems to point to something in the switch area.

What is there I can check on the switch or sccm maybe?

Every ConfigMgr-to-Intune conversation I have ends up at apps. A decade of applications, detection methods and dependencies has to be rebuilt for the Win32 model. 

For anyone mid-migration or co-managing: are you rebuilding manually, scripting around PSADT, using a catalog tool, or something else? Which part do you dread most? 

Disclosure: I'm Brandon, and I lead product at Splashtop. We just launched Splashtop Agentic Packr, an AI packager for Intune that can also bundle packages to deploy with ConfigMgr. The Free plan covers up to 100 endpoints. It isn't the point of this post. I'm more interested in how people are really handling this. Happy to answer questions about ours if useful: https://www.splashtop.com/agentic-packr?utm_source=reddit&utm_medium=social&utm_campaign=20261020_WW_EN_Packr

Hello everyone,

Our environment consists of one Primary Site, around a dozen Secondary Sites and CMG (2603 with the latest hotfixes). All MPs and DPs have been using HTTPS for a long time.

We currently have a Network Access Account configured. When we remove it, everything continues to work except bare-metal PXE deployments through our Secondary Sites. PXE deployments through our Primary Site work without NAA.

During troubleshooting, I found the following errors in MP_Token.log on a Secondary Site:

Cannot open registry key for token signing cert thumbprint. Error 0x80070002
CCMGetTokenSigningCertificateContext failed with error 0x80070002
Failed to get STS signing certificate. Return code: 0x80070002
CHandleTokenRequest::CreateReplyDocument failed with error code 0x80070002.
MP TM: Message discarded

Procmon capture shows that, while processing the client's token request, CcmExec.exe attempts to open:

HKLM\SOFTWARE\Microsoft\SMS\CMSERVICE

This key is absent on all the Secondary Site servers we checked. On the Primary Site server, it exists and contains TokenSigningCertThumbprint and IssuingCertThumbprint.

Has anyone encountered this? Is the Secondary MP expected to issue DP authentication token itself or should WinPE obtain it from a Primary Site MP while downloading content from the Secondary Site DP?

I’d appreciate any advice or suggestions

We are facing bsod during patch reboot after installing october 2026 os patch kb5126836 in windows server 2012 R2. This is happening in 3 hpe physical servers while my VMs don't have this issue. I'm able to bring back the servers by revering patches via repair but i want to install this patch. Anyone else is seeing this??

My environment is currently one MP that also acts as the DP for the entire environment.

I have a main location New York, I have several satellite offices Boston, Chicago, Paris and Rome. Each has its unique IP range. I would like to set up a DP at each satellite office.

I have created the boundaries for each range. Currently they all belong to a default Boundary group.

How can I set this so that the satellite boundaries hit their DP in their boundary group first and still fallback to the default boundary group with the MP if it's down or doesn't have content?

Thank you.

Hi,
last week I installed the latest security patch for SCCM 2509 (still waiting for the rollup 2603). Today I updated the SCCM agent in the TS and now I have the problem that after the step "Setup Windows and ConfigMgr" the TS just finishes, no domain join, nothing.

After that I updated the ADK and created a new boot image, but the same image. After "Setup Windows and ConfigMgr" I just get to the logon screen without a domain join. Any idea what I am missing?
Ah, OS is still 25H2

Hello! We have a few HP models that are licensed for W10 Enterprise LTSC (1809, and 21H2). I inject the latest cumulative patches into the install.wim prior to importing them into CM, and it’s been a flawless process until the October update. The latest patch now includes the ESU enablement KB, which breaks or prevents offline patch injection. The 1809 image still accepts the LCU patch offline but not the 21h2 install.wim. I tested the September oob patch and that works as well. I’m confused why this is happening since the 10 LTSC is still supported for at least a couple years still. Has anyone experienced this? Or maybe has a workaround?

hi folks

We saw this kick in on our test patch tuesday boxen.

Look for "The token supplied to the function is invalid (Error: 80090308; Source: Windows) in %windir%\ccm\logs\cmrcservice.log

We have a superceding GPO for this sort of situation so if you see this too:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System

TypeOfAdminApprovalMode=1

(Should be able to do it in GPMC, but it turns out I need to configure a new Win11 25H2 box for that change since it seems Server 2022 won't display that setting in GPMC even after templates updated)

Am also seeing inability to log in via RDP on accounts which are not local admins (which is our standard for users since Win7)

so, we are having issues with stuff not installing or servers not rebooting after a maintenance window in a once a month 4 hour mw. Was told here that others are using TSs. My idea:

1. TS Flow

​

Install Updates - Pass 1
↓ 
Restart Pass 1 
↓ 
Install Updates - Pass 2
↓ 
Restart Pass 2

Install Software Updates settings:

·         Required for installation: Mandatory software updates only
·         Evaluate software updates from cached scan results = Enabled
·         Retry if computer unexpectedly restarts = Enabled (2 retries)
·         Continue on error = Disabled

Rstart Computer settings:

·         Specify what to run after restart: the currently installed default OS
·         No user notification
·         Continue on error = Disabled

1. Task Sequence Deployment settings:

   ·         deployment: Required ·         maintenance window: monthly 4 hour ·         Do not allow execution outside maintenance window

for those running TSs in prod:

• Do you use 2 passes or 3?
• What happens if the TS is still running at the end of the maintenance window?
• Any gotchas with reboots in MW, interference, or updates evaluation?

with the july price changes, e3 picked up part of the intune suite and e5 got all of it. that’s had us looking at co-management again and wondering how much longer it makes sense to keep everything in sccm.

curious how others are handling it:

• did the new e3 features (remote help, advanced analytics, epm, etc.) cover what you used to rely on sccm for?
• anyone on e3 finding they still need intune suite add-ons for certain things?

would love to hear real experiences, good or bad. TIA.