I am currently conducting a deployment assessment of Microsoft Defender for Endpoint (MDE) across a heterogeneous server estate, and I have encountered a significant, reproducible blocker on Windows Server 2012 R2 instances. The core agent (the unified sensor package) consistently fails to install via both direct manual execution and automated deployment tools. The error manifests during the installation phase, typically with a generic 1603 error code or an "Installation failed" prompt from `MsSense.exe`, with scant useful detail in the standard Windows Application event logs.
Having analyzed the prerequisites and system requirements documentation, the server OS is ostensibly supported. However, the failure pattern suggests a conflict or missing prerequisite that is not adequately documented. My environment is standardized, and the servers in question have the following baseline:
* Fully patched Windows Server 2012 R2 (including all .NET Framework updates).
* No competing third-party AV/EPP installed (confirmed via `Get-WmiObject -Namespace rootSecurityCenter2 -Class AntiVirusProduct`).
* Sufficient disk space and memory resources.
* TLS 1.2 enabled system-wide (a known prerequisite for service communication).
The standard troubleshooting steps from Microsoft documentation have been exhausted:
1. Running the Microsoft Defender for Endpoint onboarding script (`InstallSense.ps1`) with elevated privileges.
2. Manually downloading and executing the latest standalone installer package from the Microsoft 365 Defender portal.
3. Verifying proxy settings and network connectivity to the required endpoints (`*.security.microsoft.com`, etc.).
4. Checking for any residual Group Policy objects that might be interfering with device registration.
Given the analytical nature of this forum, I am seeking a detailed, procedural workaround or root-cause analysis. Specifically:
* Has anyone successfully decomposed the installer to identify the exact prerequisite check that fails on Server 2012 R2?
* Are there specific legacy system components or C++ runtimes that must be present beyond the documented .NET 4.6+ requirement?
* Is there a known registry key or system integrity component (e.g., a specific version of `ucrtbase.dll`) that must be manually installed prior to agent deployment?
I am prepared to conduct a comparative analysis of a working Server 2016 system against a failing 2012 R2 system using tools like `procmon` from Sysinternals to trace the installation failure. If the community has already undertaken this analysis and identified a discrete mitigation—such as a specific standalone update package (KBXXXXXX) that must be slipstreamed, or a manual extraction and registration of the sensor binaries—I would greatly appreciate the data.
A sample of the non-informative log entry from `Applications and Services Logs > Microsoft > Windows > Sense > Operational` is below:
```
Log Name: Microsoft-Windows-Sense/Operational
Source: Microsoft-Windows-Sense
Event ID: 5
Level: 2
Description: Service startup initialization failed.
```
Any technical deep dive into the component-level failure would be more valuable than a generic "re-image the server" suggestion, as we are evaluating MDE for broad enterprise deployment.
1603 on Server 2012 R2? Seen it. That OS is a landmine of missing KBs. Your list is good, but check for KB3046738 specifically. It's a pre-req for the C++ runtime redistributable the sensor leans on, and Microsoft's docs sometimes forget to mention it for 2012 R2.
Run this. If it's not there, that's your culprit.
```powershell
Get-HotFix -Id KB3046738
```
Also, generic logs are useless. Enable MDE diagnostic logging before the install attempt and watch `Microsoft-Windows-Windows Defender/Operational` and `Microsoft-Windows-SENSE/Operational`. The real error is hiding there.
Prove it.
That KB tip is sharp, thanks. I'd been leaning on the official prerequisites list too hard. So if the hotfix is missing, do you just install KB3046738 and then retry the sensor, or is there a reboot order that matters?
not a buyer, just a nerd
Yep, you'll need a reboot after that specific KB. The install usually triggers it anyway, but I'd do a cold restart before trying the sensor again.
Beyond the KB, have you quantified the risk and cost of keeping these 2012 R2 boxes in the loop? The patch treadmill for an OS that old has a real operational tax. Sometimes the better ROI is fast-tracking the workload migration off them.
Ask me about hidden egress costs.
You say your 2012 R2 boxes are "fully patched," but that term is meaningless with this OS. The official patch list is incomplete and vendor KB articles are notoriously revisionist. I've seen three separate "supported" configurations for 2012 R2 and MDE that contradict each other.
The 1603 error is a polite fiction. The real failure is almost always a dependency chain you can't see, like an obscure servicing stack update or a specific build of the Visual C++ redist that only came with some other forgotten application. Relying on `Get-WmiObject` for AV confirmation is also a bit quaint; I've found remnants of old endpoint clients that block the sensor but don't show up there.
Have you tried the installation on a truly clean 2012 R2 VM, built from your gold image? If it works there, then your "standardized" environment isn't.
cg
You say "standardized" and "fully patched" but that's where the problem always starts. The prerequisite matrix for 2012 R2 is a moving target. The docs are wrong.
What's your build number? Not just "all updates applied." If you're not on 9600.21924 or later, you're missing the actual servicing stack update that the installer silently checks for.
And WMI to check for AV conflicts is insufficient. You need to scrape the registry and installed programs list for remnants of anything from McAfee, Symantec, or even old SCEP. Their uninstallers are trash.
Show me the methodology.