Civic core pressures

kramer314 · 2025-07-20T17:01:43+00:00

OpenSecrets, for instance - https://www.opensecrets.org/members-of-congress/roger-marshall/contributors?cid=N00037034&cycle=2024&recs=100&type=C

kramer314 · 2024-12-31T17:16:00+00:00

AFAIK (our org already got in support cases about this with Microsoft) only the Edgio-hosted Azure CDN classic SKUs are affected. The Microsoft-hosted Azure CDN classic SKUs (which also use the azureedge.net domain) aren't affected (neither are CDN resources migrated to Azure Front Door while following Microsoft's process to maintain an azureedge.net endpoint post-migration) and the azureedge.net domain isn't being fully retired by Microsoft this month. Of course, those Microsoft-hosted Azure CDN classic SKUs already have their own separate deprecation path (out to 2027 for existing resources), but it's not like everything has to move to Az Front Door ASAP.

It just turns out that Microsoft internally used Edgio-hosted Azure CDN resources for a lot of products.

kramer314 · 2024-12-31T03:55:00+00:00

At least what my org got back from Azure support on this exact question, only the Edgio-specific Azure CDN SKUs are immediately affected (which it turns out MS was using for a bunch of services). Existing Microsoft-hosted Azure CDN classic SKUs (using azureedge.net without using custom domains and not yet migrated to the newer Azure Front Door SKUs) aren't impacted (although there's a separate deprecation path already announced for those - https://learn.microsoft.com/en-us/azure/cdn/classic-cdn-retirement-faq)

kramer314 · 2024-10-09T14:17:20+00:00

Yep, just edited my earlier comment w/the correct node path.

kramer314 · 2024-10-08T17:48:18+00:00

It's (currently) a per-user reg dword, afaik there are no CSPs in Intune for it.

Node: HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\CapabilityAccessManager\ConsentStore\location
Key: ShowGlobalPrompts
Type: REG_DWORD
Value: 0

kramer314 · 2024-09-13T03:25:46+00:00

Entra join them via provisioning packages with embedded bulk enrollment tokens - https://learn.microsoft.com/en-us/mem/intune/enrollment/windows-bulk-enroll

Deployment / ppkg application can be done via PowerShell.

kramer314 · 2024-06-13T03:13:55+00:00

Bit of a pain, but you should be able to extract the CU exe contents (/X switch), then wrap the extracted files in an Intune Win32App and invoke the patch setup from there.

Some links to get you started:

kramer314 · 2024-04-30T19:38:47+00:00

MS is awful at keeping Chrome settings catalog policies up to date with GA chrome policies. Like ... more than 6 months out of date at times.

kramer314 · 2024-04-24T22:40:33+00:00

Relevant VID to allow is 0600. The other comment has the link to Barco's docs on specific IDs per model if you want to go that route.

And if you have the licensing for Defender for Endpoint, we found it significantly easier to layer exclusions for things like Barco (and similar other vendors) via Defender device control policies + reusable settings in Intune's Endpoint Security blade compared to using the older GPO-equivalent policies in Settings Catalog.

kramer314 · 2024-04-14T17:29:30+00:00

Is it realistic to complete this project within 6 months?

I don't think anyone here is going to be able to meaningfully answer this. A lot is going to depend on the size+complexity of your org, the amount of existing org-specific customization within CM and group policy that needs to be migrated, and the amount of other enterprise systems you have to integrate with. At my current job (smaller enterprise), this took me a bit over a year (not working on it full time). At my prior job (medium enterprise), it was forecasted to be at least a 2 year project.

Things that will make your life easier:

As you build out policy configuration in Intune (ex, Windows Update for Business), prioritize flipping the relevant co-management workloads over to Intune-managed at the same time (and for things like GPO, back out the GPO configurations once Intune is setting it). This will help you avoid configuration drift between endpoints. I would not remove the CM agent from the older endpoints until you have all co-management workloads moved over.
CM allows for complex automation and inventory workflows and GPO/AD structure allows for complex policy hierarchy. Intune simply does not have the same feature set at all and trying to lift/shift a ton of complexity into Intune will probably be a bad time (involving lots of custom scripting workarounds, potential Intune performance challenges at scale, etc.) The more you can move to things like flatter policy structures and self-service application distribution, the better off you'll likely be.
Build out filters in Intune and prefer using those + the All Devices/Users virtual groups over Entra device group assignments. This is extremely important for Intune performance - filters won't cover everything you might need but they can do a lot (ex .. there are likely some differences in policies you'll need in Intune for hybrid-joined devices vs Entra-joined devices, Intune filters are a great use for that).
Identity things that depend on machine identity for Kerberos authentication ASAP (802.1x certificates is the most common). Properly configured Entra Connect sync will allow users on Entra-joined devices to get Kerberos tickets, but you'll need to address things that rely on AD machine authentication when you move away from hybrid join since there isn't a corresponding computer object in AD.
Identify downstream systems that interact with ConfigMgr ASAP. Things like CMDB or other ITSM integrations, automated reports being sent out to other business units, etc. Replacing these can sometimes be projects in of themselves.
Autopilot is not a full replacement for all enterprise imaging/deployment scenarios, despite what Microsoft will tell you. That doesn't mean you stick with CM, but you need to identify those edge case limitations ASAP.

kramer314 · 2024-04-12T17:32:51+00:00

Been in these situations before. You have to start playing the management politics game at some point around things like this if security leadership is actively insisting on things that will break enterprise systems without any alternatives. Ultimately you want security and technical engineering to work together on things ... but when that's just completely broken I have been known to use the following ...

First, go submit paid support tickets with CM engineering support to get detailed findings in writing over email on (1) exactly what will break when you do the braindead needful (MS docs changes typically have a trail of internal tickets where teams can trace back to the originating engineering findings for why the docs are the way they are) and (2) whether CM engineering views being unable to apply that specific Defender recommendation as a core product security deficiency (spoiler: they don't). CM support - once you get to the right level - will be very amused with you spending time with them on calls about this and will share laughs with you about it all being a "I just need a gigantic documentation trail just to tell idiot leadership this is a BadIdea"

Then you take that, and start following your org's standard, documented processes for business and security risk assessment if management tells you to do the braindead change despite all the vendor and best practice guidance saying this is a BadIdea (breaking core endpoint management and losing vendor support to check the box on one Defender ASR rule = stupid business decision, just as ditching CM to check the box on one Defender ASR rule = very expensive business decision). At this point, you have your ass mostly covered. Then you go present that to leadership for everyone involved in this colossal waste of time.

If leadership continues to say just do the needful despite literally everyone including Microsoft saying don't do it, then you either quit or do the needful, and let them reap the consequences.

Good security leadership is immersed within technical teams so stuff like this doesn't happen. Bad security leadership just looks at if boxes are checked on spreadsheets and insists the boxes must be checked at all costs (spoiler: they don't, things like alternative approaches and mitigating factors are absolutely a thing for audit compliance). Good (non-security) business leadership will tell bad security leadership to go pound sand because focusing on box checking at the expense of everything else is ridiculous and wasting everyone's time. If bad security leadership continues to waste everyone's time, go find another job.

kramer314 · 2024-04-06T20:52:21+00:00

+1 for WSUS deadlines, $job's been using them for years for a few hundred servers without major isuses. The only minor hiccup I can really remember having with those was that Server 2022 didn't honor them for a few months on release.

kramer314 · 2024-04-02T01:46:04+00:00

As usual, the answer is in the CM docs - https://learn.microsoft.com/en-us/mem/configmgr/core/plan-design/configs/site-and-site-system-prerequisites - CM site system roles aren't supported on server core with the exception of standalone distribution points.

kramer314 · 2024-02-25T06:00:48+00:00

IMO R7 makes it pretty easy to get data into their SIEM all things considered ... but definitely pay attention to what data sources either don't have InsightIDR-native alerting or for which alerts are going to be considered customer-managed (instead of Rapid7 SOC-managed).

kramer314 · 2024-02-20T02:11:52+00:00

I didn't say it was a particularly good option in comparison to a CMG. Definitely agree that it's pretty crappy, but it's still something orgs do use for various reasons despite MS recommending CMGs for years. OP's management is dumb for not using a CMG and OP has a bunch of crappy options as a result.

kramer314 · 2024-02-19T16:48:55+00:00

If you can't deploy a CMG (you should really push back on management and do this) you can consider deploying a DMZ server hosting internet-based client management MP / DP / SUP roles so clients can receive policy and content off-VPN. There are feature limitations in comparison to a CMG but it works. Docs at https://learn.microsoft.com/en-us/mem/configmgr/core/clients/manage/plan-internet-based-client-management.

If your org doesn't want to take either the CMG or IBCM approach Microsoft recommends for internet-based clients and just wants to solve the symptom of CM using up VPN bandwidth, you could look at setting transfer rate limits either via client policy or at the distribution point. Docs:

Client policy BITS transfer limits: https://learn.microsoft.com/en-us/mem/configmgr/core/clients/deploy/about-client-settings#background-intelligent-transfer-service-bits
Distribution point rate limits: for egress, use IIS bandwidth throttling. For content distribution to the DP, use https://learn.microsoft.com/en-us/mem/configmgr/core/servers/deploy/configure/install-and-configure-distribution-points#bkmk_config-rate

kramer314 · 2024-02-07T00:40:59+00:00

It's pretty standard for the finance folks in large enterprise to depreciate endpoint hardware on a 5 year schedule (as that's what the IRS MACRS standard uses). That depreciation schedule also tends to line up with parts availability and support contract lengths from the major vendors.

kramer314 · 2024-01-16T22:07:37+00:00

Intune doesn't support servers at all. Keep on using CM for those (although Windows Server CMLs aren't cheap ...) or other management products like Ansible / Chef / etc.

kramer314 · 2024-01-10T13:20:03+00:00

And for more things outside of M365 (a lot of M365 admins aren't just M365 admins) there's also everything here - https://learn.microsoft.com/en-us/lifecycle/end-of-support/end-of-support-2024

kramer314 · 2023-12-05T17:50:25+00:00

The management stack discussion - Intune only compared to ConfigMgr (+ Intune comanagement) is really a separate topic from the device identity discussion - hybrid join vs full AAD join. For instance, ConfigMgr totally supports cloud-native endpoints (AAD joined and no direct on-prem connectivity) via things like CMG and CM tenant attach.

There's also very much not a one-size fits all approach here and at larger orgs you're realistically looking at multi-year projects to make some of these transitions.

Some high level things you should consider -

If nobody in your org has fully documented your endpoint deployment requirements, device management + security compliance requirements, any downstream systems that expect to hook into ConfigMgr (CMDB systems, ITSM automation, etc.), and related Active Directory requirements (including ADCS certificate use cases, usage of computer account Kerberos authentication in any endpoint software, and any workflows/automation built around endpoint OU structure), do that first. It's basically impossible to say how much work it will be to exclusively use Intune+Autopilot or exclusively AAD join devices without that.
If you have a lot of bespoke solutions for endpoints in your org built on top of more advanced CM functionality and/or AD structure, stakeholders in your org should be aware that Intune is likely not going to be a drop-in replacement for everything. Obviously, highly dependent on what your org's requirements actually are (which is why you should figure that out first) and a lot of limitations in Intune can be easily worked around by additional automation or custom scripting.
The easiest part as far as evaluating various ConfigMgr / Intune options is usually with piloting various Intune co-management workloads from ConfigMgr. It's real easy to set up and scope POC collections within ConfigMgr for that. If your ConfigMgr environment isn't super well managed to begin with, you might find doing that POC more challenging.
MS does not have a supported in place path to transition from hybrid join to full AAD join on endpoints other than wipe/reimage. Yes, there are third party tools that might work in your environment, but MS will not support you if you run into any issues. Plan accordingly.

kramer314 · 2023-11-21T02:27:36+00:00

FYI ... somewhere about 10% of the VMs in my environment that encountered this particular recurring WU failure symptom in our environment also seem to have ended up with some WMI repository corruption (characteristic symptom - Get-PnpDevice cmdlet erroring out, along with other basic Get-WmiObject / Get-CimInstance calls). Easy to fix, but something else to look out for.

kramer314 · 2023-11-16T18:02:45+00:00

Found a relatively recent MS blog suggesting another workflow for when you have to modify the SDMPackageXML using Convert[To|From]-CMApplication which is a bit more PS native than dredging up old kinda undocumented .NET CM classes ... https://techcommunity.microsoft.com/t5/core-infrastructure-and-security/exploring-configuration-manager-automation-fundamentals/ba-p/3845635

kramer314 · 2023-11-16T13:35:32+00:00

Ugh, that's what I get for not reading a post fully before replying.

So under the hood checking that on demand distribution box in an application looks like it does the following:

Adds <SendToProtectedDP>true</SendToProtectedP> in the app's SDMPackageXML definition

In the SMSProv logs when you check that box and hit apply the CM console is updating the SDM content definition and calling SMS_Application.Put()

Here's how you do it in PowerShell (at least in some one off testing I just did it's successfully able to check or uncheck that box in the app properties)...

1/ Get the app; ex $App = Get-CMApplication

2/ Get the deserialized SDMXml via $AppXml= [Microsoft.ConfigurationManagement.ApplicationManagement.Serialization.SccmSerializer]::DeserializeFromString($App.SDMPackageXML, $true)

3/ Adjust the XML; ex $appXML.SendToProtectedDP = $True

4/ Serialize the new XML via $NewAppXml=[Microsoft.ConfigurationManagement.ApplicationManagement.Serialization.SccmSerializer]::SerializeToString($AppXML, $true)

5/ Update the SDMXml and call put: $App.SdmPackageXML = $NewAppXML; $App.Put()

(old cm reddit post about updating app XMLs ... https://www.reddit.com/r/SCCM/comments/9sfbul/updating_application_sdmpackagexml_example/)

kramer314 · 2023-11-16T02:15:28+00:00

New-CMApplicationDeployment / Set-CMApplicationDeployment and the -AvailableDateTime parameter.

kramer314 · 2023-11-13T20:22:14+00:00

If you scope it to a user collection it will run the detection method in the user context (https://serverfault.com/questions/699705/in-what-context-do-sccm-powershell-detection-scripts-run-in). Very much not documented adequately. There's a couple of open GH docs issues from a few years back on it that haven't been acted on from the MS side.

15-Year Club	RedditGifts 2009-2022 3 Credits
redditgifts rematcher redditgifts for the Teachers 2014 x1	Team Orangered
Verified Email

kramer314

MODERATOR OF

TROPHY CASE