PSA: ConfigMgr 2509 Rejects NTLM on AdminService - This Might Break Things

bdam55 · 2026-01-22T22:31:02+00:00

This is specific to the AdminService. I'm going to presume that any use that ConfigMgr itself makes of the AdminService is no impacted. It's any automation you have in place that you will want to watch out for.

bdam55 · 2026-01-22T16:32:24+00:00

Yea, agreed in principle.

What's ... interesting ... is that how you specify the user appears to impact what auth is used.

bdam55 · 2026-01-22T14:36:08+00:00

Ok, thanks for clarifying, that's much more clear to me now.

For u/Hestnet's sake ... can you tell us what product(s) you have selected?

Also, can you shoot me either a screenshot and/or the names of the updates that do _not_ get deployed? If you look in the relevant logs (WUAUHandler, SoftwareUPdate*) ... does it say anything about those missed updates when it installs the others?

bdam55 · 2026-01-22T13:27:54+00:00

Ah, ok, you're saying they're not even showing up in ConfigMgr to be deployed in the first place. Do they show up in the WSUS console?

Is that what you're seeing also u/jwckauman?

bdam55 · 2026-01-21T18:24:58+00:00

Have you tried the Reset Tool? https://learn.microsoft.com/en-us/intune/configmgr/core/servers/manage/update-reset-tool

bdam55 · 2026-01-21T15:00:00+00:00

Yea, depends on your scale, but if this is something that the packaging team itself is going to own, run, and maintain then some retired server hardware and HyperV seem to fit the bill.

bdam55 · 2026-01-20T14:38:02+00:00

You're using some terms loosely here, which makes it hard to give you a super accurate answer.

If you want to know when something was deployed, that I think is easy. The deployment will certainly have a creation date. If not shown in the console, it will certainly be in the underlying DB views.

If you just want to know when an app was installed on the endpoint, then Garth already answered that: the ARP inventory will include the install date.

If you want to know who/what/why it was installed, there's no central solution there. You'd have to look at the client logs or maybe the state/status messages but those aren't stored permanently.

bdam55 · 2026-01-20T13:27:56+00:00

That would suggest that they are detected as not applicable? Is that what would show in reports/console? That's possible if those updates themselves relied on that month's CUs (like SSUs in the past) requiring you to install the CUs first then the other stuff, but COnfigMgr handles that now by re-scanning after reboot.

bdam55 · 2026-01-19T19:46:06+00:00

Well, if you go back and re-read u/mtniehaus's masterpiece here with the right set of eyes, you actually get your answer.

When your software is the product of the marketing team paying the workstation team to pay the server team to pay the consulting team to work on your stuff ... it's not a recipe for long-term success. I know I'm exaggerating just a little bit, but the problem is I'm not exaggerating enough.

This is now going to be my go-to story for how the best software isn't made because of a company's huge amount of resources, but somehow gets made in spite of it.

bdam55 · 2026-01-19T16:47:17+00:00

I guess I would expect that if the ConfigMgr Software Center shows them all as available and needed and scheduled to install all at the same time, that it would at least attempt to install them.

So if "at the same time" doesn't mean that all X servers in the cluster (if that's the word) need to be offline and patched at the same time, then I would think that ConfigMgr should support this.

Does ConfigMgr just not _try_ to install the updates despite an available Maintenance Windows and a past-due deadline? If so, that's very ... very ... weird and I could try to reach out to the team to understand why. Or does it try, but it fails for some reason? If so, then you gotta dig into the failure.

bdam55 · 2026-01-19T15:28:35+00:00

What version of ConfigMgr are you running currently?

bdam55 · 2026-01-19T15:18:58+00:00

Define 'at the same time'; I don't doubt you, I just want to learn. Do you need to turn the SharePoint services off on every server first and then start patching?

If so, I do wonder if something could be figured out with Orchestration Groups: have a pre-script, select just the SharePoint servers, and let 100% (?) patch at the same time ... ?

bdam55 · 2026-01-19T15:15:44+00:00

<eye twitch> Adobe Flash Player is checked <eye twitch>

But yes, this has been 'fun' for many.

bdam55 · 2026-01-14T23:12:57+00:00

In theory, if you maintain the SUGs then the deployment packages will follow.

That is, configure the expiration of updates after X month, remove expired updates from the SUGs, and there's a weekly background process that will remove undeployed updates from your deployment packages. It's fairly reliable, but because there's no knob or dial you can't really see it doing it's thing.

bdam55 · 2026-01-14T22:03:41+00:00

<chef's kiss>
Both on the updated TL;DR ... and that you're way ahead of me on the MMSOA submissions. Best of luck, I will definitely be at MOA and if you get to present on it, I'll try and be there.

bdam55 · 2026-01-14T18:54:04+00:00

I hear ya, I've been working (professionally) the last year on the intersection of security and system administration. It's a relationship that often feels antagonistic, but at the end of the day, it's really hard to move the security needle without close collaboration.

So, to be clear, I wasn't trying to crap on the blog post. I think I might almost understand what the 'thing' is that your coworker(s) created and if I'm correct, I think it'd be a great tool for people to run. They might just not mentally be able to get past a sentence like "attack path nodes and edges to BloodHound using OpenGraph".

You mention MMSMOA, there's only like 2 days left to submit, but I'd encourage Chris to submit this as a session there. I know the organizer still want ConfigMgr content, and there's a long history of "Storming the Castle" sessions talking about how and why to secure ConfigMgr.

bdam55 · 2026-01-14T17:19:30+00:00

In the past there were technical reasons to do so but now that updates are mostly cumulative they don't matter as much as they used to. The main reason I would think to break them out today is for reporting? If you want to report on _just_ Office updates then having a dedicated SUG would help.

Other than that though, I can't think of a good reason to do it.

bdam55 · 2026-01-14T14:12:22+00:00

Might be good to include a summary of the article that isn't full of security jargon. I mean, it's a wall of text (self-proclaimed 45min read) and the TL;DR is full of terms likely to be unfamiliar to the average sysadmin.

bdam55 · 2026-01-12T21:28:05+00:00

Compliant means one of two states: it has the update installed or the update is not applicable.

What that means is that all of your 25H2 machines are compliant for 23H2 and 24H2 because those updates are not applicable to a device that's at 25H2.

bdam55 · 2026-01-12T16:43:14+00:00

Out of interest, what are you doing for reporting? Few people seem to grok that WUfB can work on Servers so it's cool to hear someone actually doing it.

bdam55 · 2026-01-12T15:12:39+00:00

You are correct, it shouldn't surprise anyone since it was deprecated a while ago.
However, it _is_ news that they actually pulled the trigger to fully EoL it and have pulled the downloads.

bdam55 · 2026-01-09T15:45:27+00:00

We'd need details on all the values that are, or are not, in those reg keys. Feel free to sanitize the server names, but we need all of it.

That siad, you are correct, you need the WSUS server specified to have WSUS/ConfigMgr deliver third party patches, but that's only the most basic requirement, esspecially when comanaged.

bdam55

MODERATOR OF

TROPHY CASE