We’ve been rolling out the Falcon sensor across a new set of Server 2022 Core instances and hitting a consistent snag. The deployment seems to hang or fail silently on about 30% of the Core hosts, while the GUI-equipped Server 2022 versions in the same batch proceed without issue.
I’m curious if others in the community have run into similar roadblocks. Our usual deployment method (via our RMM tool) hasn’t changed, and logs aren’t pointing to anything obvious—just a lack of the sensor process appearing. We’re double-checking prerequisites like .NET versions and pending reboots, but it feels like something specific to the Core SKU.
If you’ve successfully deployed on 2022 Core, did you need to adjust any deployment parameters or pre-install steps? Conversely, if you’ve seen failures, have you found any consistent workarounds or root causes? Sharing any specific logs or event IDs that helped you diagnose would be a huge help for everyone’s observability here.
- GG
- GG
Yeah, we hit almost the same pattern a few months back. Our silent failures on Core were tied to a specific Windows update conflicting with the sensor's service install step.
It didn't show in the sensor's own logs, but the Windows Application Event Log had a couple of 7000 events (Service Control Manager) from around the failure time, pointing to a dependency issue. A temporary workaround that got us through was pushing the installer with the /install /quiet /norestart flags AND a 60-second delay before the subsequent service start attempt via our RMM.
Have you checked if the failures correlate with a particular build of Server 2022 Core? Ours were all on the 20348.2340 build.
Ship fast, measure faster.
We saw the same 30% failure rate on a deployment last quarter. The logs were indeed silent, but the cost of those failed sensor installs showed up in our monitoring bill - we had to keep the instances provisioned an extra 36 hours for troubleshooting.
Our root cause was different from the Windows update theory. In our case, the Core instances lacked the Visual C++ 2015-2022 redistributable, which the GUI versions had from other software. The Falcon installer didn't check for it, and the failure was silent.
Quick validation: check for `C:WindowsSystem32vcruntime140.dll` on a failed host. Our workaround was a pre-install script that deployed the redistributable from Microsoft's official package. That dropped our failure rate to near zero.
Right-size or die
That's a solid find on the Visual C++ runtime. We've seen similar silent dependency gaps with other monitoring agents on Core SKUs, where the missing component is just assumed to be part of the base OS image.
Your pre-install script approach is the right way to handle it at scale. For our pipelines, we actually bundle those redistributables into a separate deployment artifact and use a checksum step to validate presence before the main installer runs. It adds a few seconds but eliminates the entire class of failure.
Did you package the runtime installer directly or use something like Chocolatey for that prerequisite step? I'm always curious about the trade-offs in maintainability versus a direct MSI pull.
Extract, transform, trust
That's a really useful check. We've had similar gaps with Core images, but it was the 2013 runtime for an older agent. I'll add this to our pre-deployment checklist.
Did you see any performance impact from adding the runtime? I'm wondering if it's worth baking into the base image instead of installing each time.