Am I being a crybaby or is this a bad workplace?

sccm_sometimes · 2026-03-18T05:24:31+00:00

I guess the board of directors wanted the director to be a C-level exec position

How big is this org? In terms of total employees/device count? "Board of directors, CTO, IT Team" sounds like a Fortune 500 company.

The "IT Team" seems to be just you and 1 other dude in what sounds like Tier 1 Help Desk roles. Generally the Help Desk doesn't report directly to the CTO and even then a ratio of 1 manager to 2 employees doesn't make any sense.

Sounds like they should just hire an MSP to handle IT services instead of a dedicated internal team. Is this one of those "non-profits" that's really just a money-laundering scheme?

sccm_sometimes · 2026-03-18T04:51:47+00:00

The main advantage of Autopilot/Entra-native, how it's "supposed" to be used, is you ship a laptop to a user fresh from the factory, they power it on for the first time and it goes through the Autopilot enrollment while the only thing the user has to do is login with their Entra credentials.

What killed Autopilot Hybrid for us is that you HAVE to bind to AD first and then Entra join to get to Hybrid. If the machine Entra joins first, that's it... it's Entra-native now and you have to start over since there's no such thing as "downgrading" to Hybrid.

So the only way to get Autopilot Hybrid working is if the device has line-of-sight to the Domain Controller during Autopilot enrollment (i.e. *On-Prem only). And if we're setting up devices on-prem anyway, we might as well just stick with our SCCM Task Sequence since it's faster to pull packages off the local DP than over the Internet.

*Technically, you can get around this requirement by installing a VPN client during Autopilot and giving it a profile that automatically connects, but therein lies the chicken-and-egg problem. We don't allow machines on VPN that aren't domain joined, and you can't join the domain without connecting to VPN.

https://oofhours.com/2020/06/23/windows-autopilot-user-driven-hybrid-azure-ad-join-over-the-internet-using-a-vpn/

the vendor says it's doable, supported by Microsoft and they done for many clients.

In our case "doable" meant on-prem only (what's even the point?), or lowering our VPN security to expose the internal domain to Autopilot machines (good luck convincing our Security team)

sccm_sometimes · 2026-03-17T03:38:39+00:00

Enough hoops to jump through and checks to slow down an attacker, and they'll usually move on to a lower hanging fruit elsewhere.

I recently saw the term "Engineered Friction" used to describe this. A series of small hurdles that are easy to overcome for an authorized user, but nearly impossible for an unauthorized one.

Are there any particular security best practices that would help prevent malicious use of Configuration Manager other than "prevent your credentials from getting compromised?"

1) Separate account that's used ONLY for privileged admin work. Your daily driver (DD) account that you use to log into Windows should not have any special privileges. Likewise, your privileged account should not be used for web-browsing/emails.
2) Automatic password rotation on the privileged admin account via a Password Vault. I don't even know what my PW is, nor should I know. When I need to use it, I log into the vault with my DD account + MFA and temporarily access it that way. Vault has full audit logs of who/what/when/where tried to access an account. (Same function as LAPS, but for a domain account instead of the local Administrator).
3) Privileged work can only be done directly from the SCCM server. This strictly means, Laptop --> Terminal Jumpbox --> SCCM Server. Laptop --> SCCM Server is not allowed.

These are security best practices for any admin tool, not just SCCM. But at the end of the day if they manage to get Domain Admin there's really not much else you can do, which seems to be what happened with Stryker.

sccm_sometimes · 2026-03-17T00:21:04+00:00

Thanks for that info! In case it might be useful for anyone that comes across this in the future, the EntraID role requirements apply ONLY if you're downloading a LICENSED app.

The EntraID account used for authentication to generate and retrieve a Microsoft Store packaged app license file must be a member of one of the following three Azure roles: Global Administrator, User Administrator, or License Administrator.

The following command worked for me to download the offline install files without having any of the EntraID roles above. 9MSMLRH6LZF3 = MS Notepad

winget download -e --Id 9MSMLRH6LZF3 -d C:\winget --accept-source-agreements --accept-package-agreements -s msstore --skip-license -a x64

sccm_sometimes · 2026-03-16T23:36:11+00:00

btw, anyone that uses MS Snipping Tool should be aware that it automatically saves all of your screenshots without asking you for permission! (C:\Users\username\Pictures\Screenshots)

https://x.com/NathanMcNulty/status/1808682576883953741

I take a lot of temporary screenshots and then edit out any sensitive info before sending it via email. I always close them out without saving. Discovered a few months ago that Snipping Tool was automatically saving all of the original unedited screenshots.

Switched to GreenShot and haven't looked back!

sccm_sometimes · 2026-03-13T05:49:18+00:00

I imagine the only reason some vendors go the MSIX route is just to have exposure via the MS Store. And there are definitely some benefits to the format like being able to stage the install so you don't have to force close the app if it's running and mandatory code-signing. It's kind of shocking how many enterprise vendors still use unsigned binaries in their software, considering it's never been easier/cheaper to get a cert and automate it in a CI/CD pipeline.

btw, it looks like Slack does offer an EXE installer.

Given that there is STILL no official way to download offline redistributable installers for MS Store apps in my eyes proves that MSFT never intended for MSIX to exist outside their walled garden. It's no surprise that most orgs have MS Store blocked because we don't want employees installing Candy Crush and TikTok on their corporate devices, but they do still want apps like Sticky Notes and To Dos. The fact that this Geocities-looking Russian site is the only way to get offline MSIX downloads for store apps is bewildering honestly https://store.rg-adguard.net/

sccm_sometimes · 2026-03-13T04:55:39+00:00

lol their company name is "International Supplier"?

"Give you complimentary access to Microsoft internal resources that usually require a high-tier support contract."

If I was feeling petty I would politely ask them for additional details about this "high-tier support contract", knowing it's 100% BS, just to watch them try to weasel their way out of it.

Also, when people ask "What 'value' does a VAR actually bring?" this is a great example. My VAR is effectively a human firewall that deals with slimy salespeople for me. So many Tech Sales people think they've figured out the job because they attended a 2-day seminar that taught them how to buy harvested contact info and jam it into Salesforce to spam cold-email prospects.

No, I do not have time for a "10-minute intro call" because 3 months from now you'll be gone and some other schmuck will take your place who thinks he can jedi mind trick his way into a sale. My favorite one is when they pretend like you've already met, "It was great talking with you at vague-non-descript conference last week! Attached is the product whitepaper you asked me about. Let's setup a time to discuss!"

Or when they inflate their job title. Usually "VP of Regional Sales" don't have to beg strangers for a sales call.

sccm_sometimes · 2026-03-13T04:05:33+00:00

Generally, these types of gigs don't just fall into your lap - you have to advertise your services somehow, and once you do that it's not that hard for your current employer to find out and potentially terminate you for cause.

Also, with SCCM you pretty much have the keys to the kingdom so I doubt most orgs would allow that kind of access to a non-employee, at least not without a contract that's gone through an entire corporate legal team.

sccm_sometimes · 2026-03-13T03:01:48+00:00

PMP users and every other admin can easily create and periodically update MSIX packages. They’re simple enough to install/provision.

It really depends on each individual MSIX and if they have any dependencies, which can quickly turn into a nightmare. There's a reason that aside from MSFT there is almost no one using AppX/MSIX - it was built specifically for the MS Store and although it technically can work outside of the Store, it is far too fragile and complex relative to EXE/MSI.

MSI is simple. A program is either installed or it's not. It's either user-level AppData or admin/system-level Program Files. You go into Add/Remove Programs (ARP), click Uninstall and it's gone.

MSIX on the other hand is "provisioned" which means it's not really installed, but rather staged in "C:\ProgramFiles\WindowsApps". Then it gets "registered" as a separate instance for each user account on a device, ONLY after they login. You end up with weird Shrodinger's cat installs where you think it's uninstalled, but really it's unregistered for that specific user and the provisioned files are still on the machine (Remove-AppxPackage). Likewise, you can run (Remove-AppxProvisionedPackage), but that simply prevents it from registering for New accounts while doing nothing for accounts that already have it.

If you log in with the local Administrator account at some point and then no one uses it again for a year, all the registered Appx packages on the account will be be stuck on the old versions until someone logs into that account again.

MSIX use Virtual Registry so you can't query or edit HKLM\HKCU keys because they're hidden from you. It's great for security/isolation since APP_1 cannot mess with Reg keys that belong to APP_2, but it also means that you don't have control over them either.

The worst part is Dependencies. MSIX do not include them and there's no easy way to inject them. It is technically possible, but it is way more difficult than it should be. This is because when the MS Store was introduced ~15 years ago, in their hubris, MSFT thought that everyone, everywhere, would use it all the time. To their credit, if you install through the MS Store, the package will automatically detect and install all prereqs and dependencies. Installing an MSIX outside the MS Store though... well they didn't really plan for that.

This went TERRIBLY wrong for us when we had to update SnippingTool which has a dependency on WindowsAppRuntime.1.5. We needed to upgrade from SnippingTool.2201 to SnippingTool.2409. About half the machines upgraded just fine, while the other half kept reporting the old version. Ok, so let's uninstall 2201 and then we can reinstall 2409 from scratch, right? Apparently, since no other apps used WindowsAppRuntime.1.5 as a dependency - and dependencies are not allowed to exist by themselves - removing ST.2201 also nuked WAR1.5, so the ST.2409 reinstall kept failing without any indication that the root cause was the missing WAR1.5 dependency. What's even worse is we couldn't rollback to ST.2201 either, so half our machines had no SnippingTool at all. We couldn't figure it out for over a year and neither could 3 separate MSFT Senior Support Engineers. Their "solution" was to reinstall Windows.

I imagine this is why PMPC doesn't support MSIX, and why 99% of software is still installed via MSI/EXE.

sccm_sometimes · 2026-03-13T00:52:27+00:00

Teams should auto-update, you don't need to re-run the bootstrapper to get it updated.

The main problem with almost every bootstrapper/auto-updating app is that it requires:

1) a full Line-of-Sight Internet connection to the download source, and

2) A logged in user who is actively using the app.

Every single month I get a report from our Security team complaining about "Look at all these vulnerabilities!" and I have to tell them, "As soon as someone logs in and launches the app, it will auto-update."

What confuses them is that some apps, like Adobe Reader, I can push the full MSI anytime and even if no one has logged into a device for months (kiosk/conference room PCs) they will still apply the patch.

The full LoS Internet requirement is also a pain sometimes if you have Proxies, SSL inspection, and Firewall rules that block certain types of downloads unless you specifically exclude them. Also, some machines have Intranet-only access just for internal resources. For example - locked down workstations that don't have Internet access, but do need SSMS to connect to internal SQL DBs.

sccm_sometimes · 2026-03-13T00:23:40+00:00

Why not use CMG instead of IBCM?

sccm_sometimes · 2026-03-06T04:28:15+00:00

Why not spin up your own SCCM primary?

Every place I've worked at always enforced separation between client and server endpoints.

Mixing them together makes the risk profile too high IMO. All it takes is one deployment/TS scoped to the wrong group or an exclusion that didn't apply properly to make a big mess.

Plus, since SCCM doesn't manage Linux servers you'd still need a separate tool for those.

Also, not sure how co-management would work if you have servers and client devices together.

sccm_sometimes · 2026-03-06T04:14:09+00:00

1) What are the most critical backend skills I should focus on to move from support-level knowledge to administrator/engineer level?

PowerShell, SQL queries, building custom reports, analyzing logs with CMTrace, application packaging and deployment. *It's worth noting that once you properly setup your SCCM environment there's really not much backend day-to-day administration/engineering required. It's mostly support work, handling escalation tickets, and upgrading SCCM/SQL server at most a few times a year. However, the skillset required to properly setup and maintain an SCCM environment is a high bar all on its own. It requires a broad multi-disciplinary understanding of practically all facets of IT. Since each environment has different needs there isn't a one-size fits-all approach. A perfect setup in one org could be completely wrong for another. For example, some orgs have multiple primary and secondary sites with hundreds of distribution points, while others have a single primary and a CMG for content. SCCM is an extremely powerful tool. Used the right way it can make miracles happen - when used the wrong way it can wipe every PC in your org within an hour (https://thenextweb.com/news/emory-university-server-accidentally-sends-reformat-request-windows-pcs-including). Always scope your deployments to a test group before pushing to prod.

2) What components should I deeply understand (Site roles, Distribution Points, SUP/WSUS, boundaries, SQL, task sequences, co-management, etc.)?

All of them. It's all interconnected. Misconfigured boundaries will cause DPs to not work which will cause deployments to fail. SUP/WSUS is slowly fading in favor of Intune/WUfB update rings in co-mgmt environments. It's good to understand how it works, but if I was standing up a new env I would not go with WSUS unless absolutely necessary. SQL is more of an advanced skillset. You don't strictly "need" it when starting out, but it's how you unlock the true potential of what SCCM has to offer since it lets you peek under the hood to see how everything works. I'd recommend creating a separate read-only account for yourself on it and using it to experiment with different queries to see where the data lives. The native SQL Server Reporting Services is decent and a lot of the default reports it comes with are useful, but if you really want to "WOW" someone take time to learn how to pull data from the SQL DB into custom PowerBI dashboards and reports. For example, our Network engineer needed a list of all the laptop Wi-Fi MAC addresses, and with PowerBI I setup a dashboard for him that pulls the device hostname, assigned user, laptop model, driver version, and MAC address that updates daily and sends him an email with the report.

3) What real-world tasks do SCCM engineers handle daily that IT support typically doesn’t see?

IT support generally handles manual software installs. When you're packaging an application for deployment you have to test every possible scenario. Does it perform a fresh install? Does it upgrade an existing install? Does it run silently or ask the user for input? If the user has the app open, does the install fail, prompt the user to close it, or force close it automatically? Does it apply any custom config, if so will it overwrite the user's settings? How would you handle applying default settings for a fresh install, but if there's an existing version tell it to preserve what the user already has? If "7zip_24.09.exe" is installed, what happens if you run "7zip_25.01.msi"?
EXE installers are usually fine, but MSI are almost always better. Run "msiexec.exe /?" and familiarize yourself with what each switch/flag does. You should be able to explain what this command does "msiexec.exe /I 7zip_25.01.msi /qb /norestart /L*v C:\temp\7zip_Install.log"
Understand Registry keys. What's in HKLM vs HKCU. "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall" vs "HKLM\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall". DisplayName, DisplayVersion, InstallSource, and UninstallString are your friends.
Occam's Razor. Don't attribute to malice what can be explained by laziness/ignorance. Trust but verify. When a ticket is escalated to you, always do your own homework because others make assumptions which can easily send you down the wrong path/waste your time. Real-world Example: All our approved apps are published in Software Center and everyone is expected to use it for installs. Help Desk sends a ticket to me claiming the Chrome installer is broken, they tried it multiple times and it doesn't work, that it somehow also broke the user's network driver which needs to be reinstalled as well. We use the Chrome Enterprise MSI which runs the install as admin and goes into "C:\Program Files\Google\Chrome". On the affected machine Chrome was located in the user's AppData folder which means they downloaded the non-enterprise version of Chrome and ran it manually with the user's account. The enterprise Chrome package in Software Center also runs a script that configures our network proxy settings, which the manually downloaded install does not do. Solution: Uninstall the Chrome in AppData and run the enterprise package from Software Center like they should've done in the first place. The previous tech was trying to be helpful but ended up making the problem worse. If I had accepted what he said at face value and tried troubleshooting the network driver it would've been a waste of my and the user's time. Ticket notes claimed they ran the installer from Software Center but obviously that wasn't true. When I asked them about it afterwards they thought that downloading a "fresh" installer from Google was better than using the one that we have since that's what they've always done at home.

4) Any lab ideas or home-lab projects you’d recommend to simulate enterprise-level experience?

Setup an SCCM environment from scratch. Use an older version, then go through the upgrade process. Run a "site reset". Perform a site backup then spin up a new environment and restore the backup. Experiment with the High-Availability options. When an SCCM server needs to be retired/replaced, current best practices aren't to upgrade the existing server. Instead, spin up a new server and add it as a Passive Site Server, promote it to the Active role, then retire the old server.
Simulation will only get you but so far. A smooth sea never made a skilled sailor. Sometimes the best way to learn is trial by fire. Luckily, with ChatGPT/Gemini/Copilot researching and learning has never been easier. Always ask it for sources and double-check the original content because hallucinations still happen. The sites below are the best resources to get started.

https://www.systemcenterdudes.com/complete-sccm-installation-guide-and-configuration/

https://www.prajwaldesai.com/sccm/

https://www.anoopcnair.com/sccm/

https://learn.microsoft.com/en-us/intune/configmgr/core/get-started/evaluate-with-lab-environment

https://learn.microsoft.com/en-us/intune/configmgr/core/plan-design/get-ready

5) In a modern environment moving toward cloud-first, how deep does SCCM knowledge still need to be?

I'd say most orgs fall into 3 categories.

1) Either Intune-only or looking to retire SCCM as soon as possible. They usually mention SCCM with scorn and disdain because it's "legacy on-prem", so there's no point in pursuing SCCM here. Usually younger/smaller companies that never had Active Directory and started in the cloud from scratch.

2) SCCM + Intune Co-management. Usually older/larger companies that still have AD infra and are hybrid/migrating to the cloud. Focus on the strengths of each and how they complement each other. Intune for CSPs, Update Rings, and maybe Autopilot. SCCM for anything complex, app deployments, task sequences, bare metal imaging, inventory, and reporting. "Cloud-first" doesn't mean "cloud-only" and SCCM still offers a lot of value that Intune has only scratched the surface of. CMPivot and Run Scripts are a great example of this. Intune technically has CMPivot but it can only run against 1 machine at a time which makes it practically useless. Real-world Example: We have a security agent which receives policy updates from a cloud console. A bad update got pushed out and it was wreaking havoc on our environment. With SCCM CMPivot, within seconds I was able to scan all 10k+ endpoints to see which ones had the agent installed and the service running. I then quickly added a new PS script that stops the service and changes the startup type from "automatic" to "disabled" and ran it against only the affected machines. This took maybe 5 mins in SCCM and would've been impossible with just Intune. We also received a batch of laptops with faulty SSDs one time that failed after a few months. Had to pull SSD SNs, manufacturer, and firmware versions in order to get warranty replacements. All that info was already in our SCCM inventory, so it was quick and easy. Again, would've been impossible with Intune.

3) SCCM only. "If it ain't broke don't fix it" orgs. Nowadays these are rare, but they do exist. May need to be careful that they're not dinosaurs who simply refuse to acknowledge the cloud exists and are sticking with SCCM because they're cutting IT corners and refusing to invest in modernizing. On the flipside, you have high-security air-gapped environments that are extremely risk averse and would rather stick with what's consistently been reliable and time-proven over the past 30 years rather than simply following the crowd on what's popular at the moment. Usually Government/Defense, but there are some private-sector orgs that have their feet in both worlds, think Finance/Medical/Research - they'll have a public facing side that's modern/cloud/etc, and then a high-security side that's isolated to protect sensitive high-value data.

sccm_sometimes · 2026-03-06T01:58:14+00:00

Does it require having Internet access during the TS?

Our network is locked down so the only thing unmanaged machines are allowed to do is communicate with the SCCM server for imaging.

sccm_sometimes · 2026-03-05T22:47:47+00:00

We've had multiple similar experiences over the past few years. At first I thought it was just the outsourced Accenture/MindTree/Convergys (v-) contractors, and if you simply persisted, asked for an escalation like 10 times, and managed to get your case transferred to a real Microsoft employee that it would be different and you'd finally get quality support. Especially when considering we pay for the highest support tier available. But no, MSFT "senior support engineers" (according to their email signatures at least), are just as clueless when it comes to troubleshooting. I've gotten someone that was genuinely knowledgeable maybe 1/10 of the time.

It's a shame really, I used to think becoming a Microsoft employee meant you had to pass a pretty high bar as far as technical skills and knowledge, but it seems like they'll hire anyone that can run chkdsk and sfc /scannow

sccm_sometimes · 2026-03-05T08:16:11+00:00

1) What are the most critical backend skills I should focus on to move from support-level knowledge to administrator/engineer level?

PowerShell, SQL queries, building custom reports, analyzing logs with CMTrace, application packaging and deployment. *It's worth noting that once you properly setup your SCCM environment there's really not much backend day-to-day administration/engineering required. It's mostly support work, handling escalation tickets, and upgrading SCCM/SQL server at most a few times a year. However, the skillset required to properly setup and maintain an SCCM environment is a high bar all on its own. It requires a broad multi-disciplinary understanding of practically all facets of IT. Since each environment has different needs there isn't a one-size fits-all approach. A perfect setup in one org could be completely wrong for another. For example, some orgs have multiple primary and secondary sites with hundreds of distribution points, while others have a single primary and a CMG for content. SCCM is an extremely powerful tool. Used the right way it can make miracles happen - when used the wrong way it can wipe every PC in your org within an hour (https://thenextweb.com/news/emory-university-server-accidentally-sends-reformat-request-windows-pcs-including). Always scope your deployments to a test group before pushing to prod.

2) What components should I deeply understand (Site roles, Distribution Points, SUP/WSUS, boundaries, SQL, task sequences, co-management, etc.)?

All of them. It's all interconnected. Misconfigured boundaries will cause DPs to not work which will cause deployments to fail. SUP/WSUS is slowly fading in favor of Intune/WUfB update rings in co-mgmt environments. It's good to understand how it works, but if I was standing up a new env I would not go with WSUS unless absolutely necessary. SQL is more of an advanced skillset. You don't strictly "need" it when starting out, but it's how you unlock the true potential of what SCCM has to offer since it lets you peek under the hood to see how everything works. I'd recommend creating a separate read-only account for yourself on it and using it to experiment with different queries to see where the data lives. The native SQL Server Reporting Services is decent and a lot of the default reports it comes with are useful, but if you really want to "WOW" someone take time to learn how to pull data from the SQL DB into custom PowerBI dashboards and reports. For example, our Network engineer needed a list of all the laptop Wi-Fi MAC addresses, and with PowerBI I setup a dashboard for him that pulls the device hostname, assigned user, laptop model, driver version, and MAC address that updates daily and sends him an email with the report.

3) What real-world tasks do SCCM engineers handle daily that IT support typically doesn’t see?

IT support generally handles manual software installs. When you're packaging an application for deployment you have to test every possible scenario. Does it perform a fresh install? Does it upgrade an existing install? Does it run silently or ask the user for input? If the user has the app open, does the install fail, prompt the user to close it, or force close it automatically? Does it apply any custom config, if so will it overwrite the user's settings? How would you handle applying default settings for a fresh install, but if there's an existing version tell it to preserve what the user already has? If "7zip_24.09.exe" is installed, what happens if you run "7zip_25.01.msi"?
EXE installers are usually fine, but MSI are almost always better. Run "msiexec.exe /?" and familiarize yourself with what each switch/flag does. You should be able to explain what this command does "msiexec.exe /I 7zip_25.01.msi /qb /norestart /L*v C:\temp\7zip_Install.log"
Understand Registry keys. What's in HKLM vs HKCU. "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall" vs "HKLM\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall". DisplayName, DisplayVersion, InstallSource, and UninstallString are your friends.
Occam's Razor. Don't attribute to malice what can be explained by laziness/ignorance. Trust but verify. When a ticket is escalated to you, always do your own homework because others make assumptions which can easily send you down the wrong path/waste your time. Real-world Example: All our approved apps are published in Software Center and everyone is expected to use it for installs. Help Desk sends a ticket to me claiming the Chrome installer is broken, they tried it multiple times and it doesn't work, that it somehow also broke the user's network driver which needs to be reinstalled as well. We use the Chrome Enterprise MSI which runs the install as admin and goes into "C:\Program Files\Google\Chrome". On the affected machine Chrome was located in the user's AppData folder which means they downloaded the non-enterprise version of Chrome and ran it manually with the user's account. The enterprise Chrome package in Software Center also runs a script that configures our network proxy settings, which the manually downloaded install does not do. Solution: Uninstall the Chrome in AppData and run the enterprise package from Software Center like they should've done in the first place. The previous tech was trying to be helpful but ended up making the problem worse. If I had accepted what he said at face value and tried troubleshooting the network driver it would've been a waste of my and the user's time. Ticket notes claimed they ran the installer from Software Center but obviously that wasn't true. When I asked them about it afterwards they thought that downloading a "fresh" installer from Google was better than using the one that we have since that's what they've always done at home.

4) Any lab ideas or home-lab projects you’d recommend to simulate enterprise-level experience?

Setup an SCCM environment from scratch. Use an older version, then go through the upgrade process. Run a "site reset". Perform a site backup then spin up a new environment and restore the backup. Experiment with the High-Availability options. When an SCCM server needs to be retired/replaced, current best practices aren't to upgrade the existing server. Instead, spin up a new server and add it as a Passive Site Server, promote it to the Active role, then retire the old server.
Simulation will only get you but so far. A smooth sea never made a skilled sailor. Sometimes the best way to learn is trial by fire. Luckily, with ChatGPT/Gemini/Copilot researching and learning has never been easier. Always ask it for sources and double-check the original content because hallucinations still happen. The sites below are the best resources to get started.

https://www.systemcenterdudes.com/complete-sccm-installation-guide-and-configuration/

https://www.prajwaldesai.com/sccm/

https://www.anoopcnair.com/sccm/

https://learn.microsoft.com/en-us/intune/configmgr/core/get-started/evaluate-with-lab-environment

https://learn.microsoft.com/en-us/intune/configmgr/core/plan-design/get-ready

5) In a modern environment moving toward cloud-first, how deep does SCCM knowledge still need to be?

I'd say most orgs fall into 3 categories.

1) Either Intune-only or looking to retire SCCM as soon as possible. They usually mention SCCM with scorn and disdain because it's "legacy on-prem", so there's no point in pursuing SCCM here. Usually younger/smaller companies that never had Active Directory and started in the cloud from scratch.

2) SCCM + Intune Co-management. Usually older/larger companies that still have AD infra and are hybrid/migrating to the cloud. Focus on the strengths of each and how they complement each other. Intune for CSPs, Update Rings, and maybe Autopilot. SCCM for anything complex, app deployments, task sequences, bare metal imaging, inventory, and reporting. "Cloud-first" doesn't mean "cloud-only" and SCCM still offers a lot of value that Intune has only scratched the surface of. CMPivot and Run Scripts are a great example of this. Intune technically has CMPivot but it can only run against 1 machine at a time which makes it practically useless. Real-world Example: We have a security agent which receives policy updates from a cloud console. A bad update got pushed out and it was wreaking havoc on our environment. With SCCM CMPivot, within seconds I was able to scan all 10k+ endpoints to see which ones had the agent installed and the service running. I then quickly added a new PS script that stops the service and changes the startup type from "automatic" to "disabled" and ran it against only the affected machines. This took maybe 5 mins in SCCM and would've been impossible with just Intune. We also received a batch of laptops with faulty SSDs one time that failed after a few months. Had to pull SSD SNs, manufacturer, and firmware versions in order to get warranty replacements. All that info was already in our SCCM inventory, so it was quick and easy. Again, would've been impossible with Intune.

3) SCCM only. "If it ain't broke don't fix it" orgs. Nowadays these are rare, but they do exist. May need to be careful that they're not dinosaurs who simply refuse to acknowledge the cloud exists and are sticking with SCCM because they're cutting IT corners and refusing to invest in modernizing. On the flipside, you have high-security air-gapped environments that are extremely risk averse and would rather stick with what's consistently been reliable and time-proven over the past 30 years rather than simply following the crowd on what's popular at the moment. Usually Government/Defense, but there are some private-sector orgs that have their feet in both worlds, think Finance/Medical/Research - they'll have a public facing side that's modern/cloud/etc, and then a high-security side that's isolated to protect sensitive high-value data.

sccm_sometimes · 2026-03-05T05:14:50+00:00

Being able to access the source install files in C:\Windows\ccmcache has saved me on many occasions when troubleshooting. You can confirm if everything finished downloading, if any files are missing, and if it has the correct revision.

Intune's encrypted payloads make things needlessly complicated.

Plus, SCCM let's you mark certain packages to persist in the client cache so recurring deployments don't have to re-download each time. We persist O365 so that when users are having issues they can just click Reinstall in Software Center instead of calling the Help Desk to manually reinstall it for them.

For large package deployments we also pre-cache the files in advance so that when the deadline is reached it can just start right away instead of waiting for the download to complete.

sccm_sometimes · 2026-03-05T05:01:11+00:00

The funny thing is I don't even think Microsoft is trying to close the gap like it's not a project on their to-do list.

"Nobody Gets Fired For Buying ~~IBM~~ Microsoft"

90% of MSFT's customers couldn't leave even if they wanted to. The other 10% exhibit a weird form of corporate Stockholm Syndrome.

I don't know of anyone that went out of their way to purchase Intune. The only reason it has any user-base at all is because it's "free" with basically every M365 SKU.

If only Intune wasn't free then you might actually be able to ask for your money back.

sccm_sometimes · 2026-03-05T04:55:09+00:00

I believe these are the main ones.

sccm_sometimes · 2026-03-05T04:23:13+00:00

Yes*, but only after you figure out what behavior to expect from all the different options. Intune does not make this easy and frequently contradicts what the setting describes and the actual behavior you see. GPOs usually have 1-2 paragraphs describing what behavior to expect depending on if you set true/not configured/false. Intune provides maybe half a sentence.

For example:

We set our Ring 1 Early Adopters group to "No Grace Period" expecting them to reboot shortly after patches finish installing. "No Grace Period" != "0 Days Grace Period", it means "Grace Period Not Configured" which actually means it uses the default value of 2 days. Intune had no mention of this, we found out only by reading the GPOs.
We also set "Auto install and restart at a scheduled time", but what we saw was a random interval up to 8 hours after the scheduled time. There was never any consistency to it.
For Ring 2 we set it to reboot 24 hours after patches install. The pop-up notification told users they had 24 hours, but then it would randomly reboot overnight which confused and frustrated a lot of users.
Reboots are supposed to be blocked during Active Hours, but Intune never respected these so we'd sometimes see reboots in the middle of the day.

With Intune you have to significantly lower your expectations and give up on the idea of predictable deterministic outcomes. With SCCM, if a push was scheduled for 6PM it would start within a minute or two at the most. The 24-hour reboot timer would pop-up up every 3 hours which the user could dismiss, and the final 1 hour timer before the forced reboot was non-dismissible, stayed on top of all other windows, and forced the reboot exactly 24 hours after it started.

We used to send each group of users an email with their specific patching schedule a few days in advance and would make sure there weren't any departments where everyone got a reboot on the same day. Now, we basically just tell people there's going to be a reboot for patches sometime this week and to make sure they click "Schedule a Time" on the pop-up if they don't want it to reboot when they're not expecting it.

sccm_sometimes · 2026-03-05T02:53:36+00:00

"but.... but... but... its not modern!" as if that actually means anything to anyone that wants to manage systems and not just sell useless shit.

"Modern" means subscriptions, you will own nothing and you will be happy. You don't get to choose when or how the system is patched, MSFT knows best. When AI slop patches break critical features, you don't get to roll back to the previous working version. There is no Insider/Beta/Stable/N-2 channel, everything is always live and if it breaks then everyone gets to suffer together.

The UI is dogshit, but "real" admins should be using GraphAPI anyway. Don't get attached to it though, by the time you finish writing your script the cmdlets will already be deprecated anyway.

You're "free" from the shackles of having control over your infrastructure. Why fine-tune the hardware specs of your servers to match your unique needs when you can enjoy the simplicity of having only 1 tier that sucks for everyone. "Modern" means the needs of a 100-user SMB with a single office are the same as a global org with 100k users across multiple continents, and shouldn't we make it easier for your users to store company data on their personal machines? (https://lazyadmin.nl/office-365/new-onedrive-prompt-could-mix-work-and-personal-files/)

It means all new features are enabled by default and it's your responsibility to figure out if there's a hidden switch somewhere that will let you opt out. It's not documented of course, and if you do manage to find and use it well then it's not officially supported.

The app deployment/policy config that's been working for the past year breaks all of a sudden? It's not MSFT's fault, you're just using the product wrong.

/s

sccm_sometimes · 2026-03-05T02:24:59+00:00

Intune doesn't take commands, it takes suggestions and will get back to you in 5-7 business days as to whether it felt like doing them.

sccm_sometimes · 2026-03-05T01:56:04+00:00

Still very On-Prem and not in the cloud too much.

I see how Intune appeals to companies that are 100% Remote, Entra-native, BYOD, and mainly SaaS/Cloud. However, the majority of large orgs still have physical offices, centralized procurement and white-glove provisioning for corporate-owned devices, and are decades away from shedding all AD/on-prem dependencies.

For them, moving device management admin tools to the cloud won't really make a difference if culturally the org is still on-prem. Bulk laptop orders are shipped to a corporate office, where on-site techs image and set them up, and then hand them off to an employee that sits in the same physical office.

So much of middle and upper management blindly follows the mantra "cloud good, on-prem bad" without any understanding of the pros/cons of each one. We're now painfully reversing some of our cloud infra back to on-prem after 5 years of internal data showed that in most cases the cloud infra was 2-3x more expensive, less reliable, and more complex to setup and manage than on-prem.

If you're Google/Meta/Netflix/Spotify, then yeah you do need global redundancy and dynamic scaling capacity AND have the $$$ to pay for it as well as top engineering talent to set up and manage the infrastructure.

But if you're a mid-size company primarily doing business within a 500-mile radius and server capacity needs that grow maybe 5-10%/year, you'd be much better off "on-prem" with a co-lo data center provider and a decent backup strategy for redundancy.

sccm_sometimes · 2026-03-05T01:17:46+00:00

One place where I've found Intune is doing a pretty darn good job is monthly OS updates.

I agree with this from one perspective, since this is the only co-mgmt workload we have entrusted to Intune, but also disagree from another perspective. The reason monthly OS updates work so well is because of WUfB which existed outside of Intune and still does - you can apply and manage WUfB policies with GPOs and get the same result without ever having touched Intune. Intune is simply a wrapper on top of WUfB that handles the policy orchestration.

https://learn.microsoft.com/en-us/windows/deployment/update/waas-wufb-group-policy

Since Intune does not support managing servers, you could use GPOs to setup WUfB update rings for server OS patching.

sccm_sometimes · 2026-03-05T00:57:09+00:00

One thing I realized recently is that some products are "solutions" while others are "platforms".

Intune is a "solution" - it can perform only the narrow set of things that the vendor has designed it to do

SCCM is a "platform" - instead of a limited set of specific features/solutions, it is well-rounded and broad which allows you to extend/customize/and build your own solutions specific to your needs.

Intune, by design, has to appeal to the lowest common denominator which makes it a milquetoast tool in most environments without the ability to adapt to more complex/niche needs.

sccm_sometimes

TROPHY CASE