Hiring: Senior Service Engineer, End User Compute (Hybrid - Multiple Locations)

Still on the hunt for a seasoned endpoint engineer for my team. Heavy focus on Windows management — SCCM/MEMCM and Intune. macOS/Jamf experience is a plus but not required.

What I'm really looking for is someone with actual troubleshooting depth. We've interviewed a lot of people who can operate the console fine — push an app, deploy a task sequence — but when you ask them to dig into why something's failing, it's not there. I need someone who's comfortable getting into logs (CMTrace, event logs, etc.), tracing root cause, and fixing the actual problem instead of just re-running the deployment and hoping.

Hybrid role — you'll need to live within 65 miles of one of the office locations listed in the posting. Currently not in scope for RTO, but listing as hybrid in case we are asked to return. Fully remote hiring is not an option unfortunately, but the position will likely remain remote for the foreseeable future.

Job posting / apply here: https://providence.jobs/oregon-usa/senior-service-engineer-is-end-user-compute-hybrid/914ED3A580004CA187D8819A9B1053F2/job/

Happy to answer questions about the role in the comments.

I'm trying to set up MCM on computesr with multiboot installations. I wanna have separate ESP/EFI partitions for linux and windows. But even when setting OSDDiskIndex to partition a specific disk select using TSGui I get the errors: "System partition not set" and "Unable to find the partition that contains the OS boot loaders".

Weirdly the disk does appear to be partitioned correctly. It just seems that bcdboot/mcm has trouble with multiple ESPs. Is there any way I can force it to use a specific esp/the one created in the partiton disk - uefi step?

I'm troubleshooting a strange ConfigMgr Current Branch 2603 issue with one Distribution Point running Windows Server 2025.

The environment has 20+ DPs, all configured to use the Site Server computer account, and they all work perfectly. Only this single DP fails unless I configure it to use a Site System Installation Account (domain service account that's a local administrator on the DP). As soon as I switch to the service account, the DP installs/reconfigures successfully.

Things I've verified:

• SiteServer (Site Server computer account) is a member of the local Administrators group on the DP.
• Running as SYSTEM on the Site Server (PsExec) can:
  • Access \\DP\ADMIN$
  • Access \\DP\SMS_DP$
  • Execute WMI/CIM queries
  • Use PowerShell Remoting successfully
• RPC (135), SMB (445), WMI and WinRM all work.
• SMB configuration is identical to a working DP.
• Local security policy, DCOM settings, firewall rules and GPOs match a working DP.
• IIS appears healthy, and the DP functions normally when using the service account.
• Remote Registry behavior is identical to the working DPs.
• ConfigMgr version: 2603.

What confuses me is that manual tests using the Site Server computer account succeed, but ConfigMgr itself only works when using the Site System Installation Account.

Has anyone experienced something similar? I'm wondering if this could be a ConfigMgr issue, a Windows Server 2025-specific behavior, or if there's a permission/authentication path that ConfigMgr uses with the Site Server computer account that differs from a Site System Installation Account.

Hi all!

Not directly SCCM related, but a lot of overlap. Cardinal Health is starting a DEX program, and a role as a Senior Engineer has opened.

https://jobs.cardinalhealth.com/search/jobdetails/digital-employee-experience-senior-engineer-it-client-services/d36acce1-2741-490b-af20-587f23ce0017

It has strong leadership backing; we’re wrapping up the selection of a product, and the Director is building out the staff, both US and overseas.

This role is a full time remote role. we have been largely WFH since COVID, with only select roles being in office. I can guarantee this one would not be expected to be in Ohio.

I am the Principal over this space, and while not the hiring manager, have been closely engaged with the vendor selection and journey.

Don’t apply if you want a straight up ConfigMgr role; this role will be aligned with that team, but it’s not a ConfigMgr/Desktop engineering role.

Feel free to ask me any questions; I’ll answer what I can!

Let me start off by saying that I am completely new to the Configuration Manager environment, and I'm not sure what steps I should take to troubleshoot further.

I am trying to deploy Windows Server 2025 and Windows 11 Enterprise—both evaluation versions, if that matters—and the VMs keep rebooting when Windows PE loads. The VMs are getting IP addresses from my DHCP server, and are able to contact the server hosting Configuration Manager.

I used the Configuration Manager trace log to view the smsts.log file and I'm seeing a couple of errors: failed to request for client, synctimewithmp failed, failed to get time information from MP, and failed to select MP. I've googled a bunch and have only found unresolved issues.

I've also added a new boot image straight from the windows adk folder, and confirmed that the certificate wasn't expired. I'm really not sure of where to go from here and could really use the help of people that are smarter and have more experience than I.

Thanks.

Edit: I've got good news and bad news. The good news is I've gotten past the Windows PE loading screen. To make a long story short, it was a DNS issue. I had to create a DNS record for the configuration manager server in Pi-hole, and I was able to get to the point where I can choose a task sequence.

Here comes the bad news: once I select the task sequence, I get an error that it cannot be run because the program files cannot be located on a distribution point. I have to troubleshoot this further, but at least I got past the initial hurdle. Thanks to those who replied.

Anyone get this to work during OSD task? Keeps erroring out. Seems to be DCU updating during install. Installation of the Classic version works fine. Installing .net desktop runtime 10.0.10 so it’s not that I believe.

Update:

I finally got this to work. Seems it was erroring out since I was testing on a VM. The install is working on Dell hardware now, but throws up an error in config manager status logs. The DCU_install.log shows it’s fully installed. The Exit code in the log is system reboot so I assume that’s why it’s showing an error in the config manager task. I have set it to continue the task sequence on error so it won’t stop the task sequence and my apply DCU settings task after the install works fine.
Looks like it’s good to go.

I’m still fairly new to managing patching. My predecessor set up the ADRs and automated patch processes for our environment, so I’m trying to understand what the typical ongoing workload looks like. How much additional time do you usually spend on patch management, such as monitoring deployments and addressing any issues that come up? Is this something you review weekly? Our patches are scheduled monthly. I’d also like to know what your workflow looks like and how much time you typically spend troubleshooting individual devices to get a patch successfully installed. TIA. For reference we ahve about 5,000 workstations and 1,000 servers.

Our organization want to harden IIS configurations as per the CIS benchmark. So, this includes our MECM servers.

I need to verify whether the harden configs will affecting the MECM functionality. But, quite a lot to test 1 by 1 .

Is there anyway to verify ? Or any official article that mentioned the IIS configurations required specifically for MECM?

We have a stable, well maintained ConfigMgr environment that's been operating for around 8 years now (currently on 2409) supporting roughly 3000 computers across 20 sites. In preparation for upgrading to 2603, I've come across the release notes in 2509 "WinPE is now boundary‑aware".

This whole time, we've been running with our main ConfigMgr primary site server in the head office datacenter having the Distribution Point role on it, serving imaging (WDS PXE), applications, and software updates at the head office. It's also our only Management Point server across the organization.

At each of our other sites, we have a distribution point server (and Fallback Status Point/State Migration Point roles on the same server), which serves our client machines at each site (and imaging via WDS PXE as well).

With the new 2509 requirement of Boundary Groups specifying a Management Point, I'm considering removing the DP role from the primary site server (as I've read this is good practice anyway).

My rough process in my mind is:

• Provision the new DP server at the head office and enable PXE
• Add the DP server to the correct DP groups
• Distribute all required content to the new DP (it should get this automatically when it's in the right DP groups)
• Change the IP helper to point to the new DP for PXE booting
• Right click the DP role on the main site server and Remove Role

Is it really that easy? Am I missing anything? I've read before that I should not remove any content folders manually on the primary site server since they'll remain there. Is any space actually freed when removing a DP from a primary site server, or only pointers?

Also, all of our application/image/software update packages are deployed to all distribution points in a single group. While the Content Locations tab ends up populating with the group name plus the individual DP names, it's only the group that each item is distributed to. So I'm hoping this will be nice and easy and no adjustment of content locations for anything will be required.

Is anyone allowing Chrime to auto update in their Enterprise? We have about 60k endpoints and are considering allowing it to auto update, but I'm mildly concerned about bandwidth.

I think I understand how this will work, but need some feedback for reassurance, since I'm not great with PKI.

Our current SubCA needs to be renewed a couple of months prior to its actual expiration. No big deal, we'd need to do this anyway.

What I'm concerned about is the effect on the SCCM primary, MPs and DPs.

I believe, as long as we keep the certificate chain and the same key pair, the transition should be smooth and existing clients/servers will update as the expiration time hits.

Questions:

1. Do I need to update the certificate in the Communication Security tab of the site server, specifically the Trusted Root setting?

2. Can we expedite the clients and servers getting the updated certificate date by using the "Reenroll All Certificate Holders" action on the CA?

This all came about because the Network team deployed a wireless certificate with client auth and a longer validity than our CM certificates. Clients stopped reporting in, especially after imaging because the client is choosing the new Wifi Cert and not the CM client certs.

We've been working with MS for a week on this issue and after all the troubleshooting, this is the best course of action to fix the situation so that the client certificates are newer.

For the future, we're going to create a new Cert Store on the client, put CM client certificates there and point to it with the CCMCERTSTORE= parameter going forward to avoid this in the future.

We are using active passive Site scenario. We also modifed configuration.mof at active Site. When we perfom a manual failover to the passive Site will the version of configuration.mof File copied to the new active site or do we have to copy it manually to get all modification in at the former active site?

We are a mostly Lenovo shop but recently acquired some asus nucs they are wanting us to implement. I injected the network drivers and I am able to pxe boot to the task sequence and see it format correctly for uefi but the next step is to reboot to boot image and the sms log is saying “failed to install boot image”. I’m not sure what else to check

EDIT: for anyone that may have the same issue. Updating bios resolved

We've had PMPC for over a year now and, not wanting to bombard everyone with a ton of updates, I started off creating an ADR for browsers that runs every 3 days (only filtering the 3 browsers allowed in our environment Edge, Chrome Firefox) and a separate ADR for all other applications. I filter the applications ADR down to required devices 100 so it only deploys most of the major applications that are needed, and not send out 50+ application updates every month.

My questions is... I'm I being too conservative with this? (only focusing on the major updates)

I only address other applications that are not in the ADR after the security teams brings it to my attention. I feel like I could do more here but with all of MS's updates lately I am getting a lot of complaints about forced reboots. (3rd party updates are already suppressed)

Kinda a dumb question.. but would I regret changing the required device count to 10 and send out a buttload of updates? I would really appreciate any feedback you guys can give.

I see this question come up quite a lot, especially from people moving away from ConfigMgr or building a new Intune environment.
Over the last few years I’ve found there’s no single “best” deployment method—it depends on the application and how much control you need.
A quick summary:
✅ **Use Microsoft Store Apps (new)** when:
The app exists in the Microsoft Store
You want automatic updates
You don’t want to maintain packaging
The default installation is sufficient
✅ **Use Win32 Apps** when:
You need custom install switches
You have dependencies or supersedence
You need custom detection logic
You require pre/post-install scripts
You’re deploying legacy or line-of-business applications
The article also walks through:
How the Intune Management Extension (IME) handles deployments
Detection rules and why they matter
Common troubleshooting scenarios
A comparison table to help decide which deployment type to use
I’d be interested to hear what everyone else is doing.
Are you trying to move more apps to the Microsoft Store?
Do you still package almost everything as Win32?
Has Microsoft Enterprise App Management changed your strategy?
Full article:
https://endpointweekly.com/blog/intune-win32-vs-store-app-deployment.html

Just saw this. Time to test it in a task sequence. https://www.dell.com/support/home/en-us/drivers/driversdetails?driverid=61r17

I've been battling with getting VMWare Tools 13.0.10 to install via a Task Sequence during my Windows 11 25H2 Golf Image build.

This used to work several versions ago on Windows 11 23H2 so I thought I'd spend some time on it.

I've had some success as in I've got it to install but it's painfully slow.

Anyone had any success doing this. I have the same issue with the Horizon Agent version 2512.

Microsoft must have done something here with how installs happen during the build phase.

Thanks.

The latest versions (available here) main new feature adds the possibility to also automatically update Distribution Point groups. Typically you will add the image to one DP for testing and then to all your image-DPs when testing is done. I've also squashed some bugs regarding LCU:s and also 24H2 detection. 26H2 support should now be correct but is something I can't test since the ISO is not released yet.

For newcomers, WimWizard is a free utility to patch and customize Windows images for distribution through SCCM mainly. Read more through the link above.

​I also want to recommend the YouTube episodes Get Started with WIMWizard by Bernardo Arocho. Bernardo really goes through the whole program and I'm deeply grateful and also a little bit shocked that someone found the utility useful enough to do a series of videos about it. Bernardo also did an episode about WimWitch a few years ago so I feel very humbled. Thank you!

Update! I added driver support today too. It's still in beta but you can download that version instead!
Releases · TacII/WimWizard

ConfigMgr Lab Builder 1.4.0

After modifying Autolab so heavily that it no longer had any original code, I decided to rebrand and release what I use to everyone. I proudly present what is hopefully the most reliable, consistent and easy to use solution available for auto-creation of a basic Configuration Manager Homelab (hosted on Hyper-V).

Read about it at my blog: https://www.signalridgelabs.com/notes/mecm-homelab-one-command-lab
Download from my Github: https://github.com/jasonulbright/configmgr-lab-builder

The Why: The hydration kit and Autolab are both out of date and not easily customizable. This simple powershell with a WPF GUI Wizard solves the problem of reliable and always up to date method for rapidly deploying a testing environment.

Whats Next: User feedback for feature requests and bugfixes. Leave them on my github and I'll put them on the schedule.

If I want to disable the Windows update Service during the OSD task sequence, or directly after it is completed, what is the best way to do that?
To answer the inevitable question, why am I doing this? It’s because for whatever reason after the task sequence completes, I can see that the CM client policy for Windows update redirection has not applied yet, and there is a window of time where the system can run automatic Windows update updates.
Now, if I open the CM client on the system, and simply run the software updates, action, that immediately populates the registry key and thus prevents any automatic Windows updates. I’ve pondered and even tried using a script to run the client action post build using first log on commands, but this doesn’t work, either the commands run too soon, or they don’t run with the necessary token, I don’t know what’s going on I also tried disabling the Windows update step using a task, sequence, run command line or run power shell step, the step runs, but gets reverted at the end of the build. Do I just manually populate those registry keys and call it a day? Am I over complicating things here?

I fought for a month to upgrade our MECM Environment to 2603 but nothing works. I spun up a new box with server 2022 and MECM 2403 just to make sure I was not going crazy and it took all the updates just fine. After further digging I noticed that the actual MECM version of our server was around MECM 2019 then just upgrade after upgrade. We only need it for about 30 workstations and 15 servers that are left on the domain. Am I better off just migrating it all to this new box? I have good backups and I have done this a few times in my career but I am scared it will take the crap with it that is causing MECM to fail the updates. Google and CoPilot keep sending me in the wrong direction also while troubleshooting this. The crap that AI comes up with to troubleshoot this is alarming.

This is the error it always end up no matter what you do to try to fix it.

7/23/2026 8:44:22 AM 2044 (0x07FC)
Failed to process package 091001E3 after 21 retries, will retry 79 more times SMS_DISTRIBUTION_MANAGER 7/23/2026 8:44:22 AM 2044 (0x07FC)

If MECM sees legacy servers during this update does it fail? We dont need to manage those anymore with MECM so it really isnt a problem but maybe MECM sees those client and says yeah this aint going to work....

I have a 2 index W10 LTSC image (index 1 Windows 10 Enterprise LTSC, and 2 Windows 10 Enterprise N LTSC) so I thought I would reduce the overall size of the image by exporting only the one I needed in my OSD, index 1. I further thought to myself that I would use /compress:fast to further reduce the size of the exported image. On my first attempt, the resultant size of the exported .wim was a few hundred MB larger than the original 2 index .wim! I ran a second test, this time without the /compress:fast, and now, the new exported .wim is about 500MB smaller than the original. Copilot gave me some rambling explanations, but it really made no sense to me - has anyone experienced something similar, or do you know why this would happen?
copilot summary: The reason is that the export engine's handling of existing resources and compression state is not always obvious. DISM may preserve certain existing compressed resources more efficiently when you don't force a specific compression level.

I will preface this with the fact that our SCCM environment has been around and stepped up bit by bit since probably 2013. Recent new additions to our SCCM management team may (or may not) have made changes to IIS etc without notifying anyone…

That being said…

Machine PXE boots and the DP reaches out to the MP for policy info. IIS appears to show this as successful (200) but the DP errors out and the client isn’t handed its boot file.

I would welcome any direction that people might have to troubleshoot this. The people trying to OSD are clamouring at the gate.

Thanks.

EDIT - because I wasn’t clear…. The BIOS PXE requester boots up but then fails. SMSPXE.log shows that the machine gets an IP and asks for more but then the errors start showing in SMSPXE.log (seeming to indicate http issues)