Alright, I know this isn't the usual observability content, but I've been knee-deep in endpoint telemetry lately and had to get GravityZone rolled out. The Intune deployment part with a custom config was a bit of a puzzle—the docs aren't terrible, but they assume a certain path. Since we're all about reproducible configs here, I figured I'd document my steps.
The goal was to push the Windows agent via Intune with a pre-configured `bdconfig.xml` to control initial policy assignment and avoid the "default-only" setup.
**Key steps I took:**
1. **Grab the installer & config from GravityZone:** In your GravityZone dashboard, go to **Installation Packages** -> **Windows** -> **Create Installation Package**. Select your target policy, download the `.exe` (which is really a self-extracting archive). Run it locally to extract the `gravityzone_installer.exe` and the `bdconfig.xml`.
2. **Prepare the Intune package:** You can't just push the `.exe` as-is. I wrapped it in a PowerShell script for reliable deployment. The script copies the config and installer to a temp location, then runs the install silently.
```powershell
# Install-GravityZone.ps1
$TempPath = $env:TEMP + "BitdefenderDeploy"
New-Item -ItemType Directory -Force -Path $TempPath
# Place gravityzone_installer.exe and your customized bdconfig.xml here in your Intune package
# Copy them to the temp location
Copy-Item ".bdconfig.xml" -Destination $TempPath -Force
Copy-Item ".gravityzone_installer.exe" -Destination $TempPath -Force
# Run installer with silent switch
Start-Process -Wait -FilePath "$TempPathgravityzone_installer.exe" -ArgumentList "/s"
```
3. **Intune Upload:** In Microsoft Intune, create a new **Windows app (Win32)**. Upload the installer `.exe`, the `bdconfig.xml`, and the PowerShell script. Set the install command to:
`powershell.exe -ExecutionPolicy Bypass -File .Install-GravityZone.ps1`
Uninstall command can be the standard `"%ProgramFiles%BitdefenderBitdefender Securityuninstall.exe" /quiet`.
4. **Detection Rule:** I used a custom detection script checking for both the installation path and the agent service. A simpler MSI-based rule might fail.
**Pitfall I hit:** The `bdconfig.xml` is sensitive to being read-only. If you pre-stage it, ensure the script doesn't inadvertently lock it. Also, the agent will show in GravityZone under the "Computers" view based on the policy ID in that XML—double-check that before you roll out wide.
It's been running solid for a few weeks now. The config stickiness is good, and the deployment success rate in Intune is >98% for me. Has anyone else tried a similar method or found a cleaner way to inject the config?
- away
That's a really useful breakdown, especially the bit about extracting the config from the self-extracting archive. I'm not in endpoint security, but your method of wrapping the installer in a script for Intune feels very similar to how we have to handle certain analytics connectors that don't have native MSI packages.
One thing I'm curious about: how did you handle the initial validation of the `bdconfig.xml` on a test machine? I've run into situations where a silent install with an embedded config fails, but the error reporting is minimal. Did you find it necessary to first run the installer manually with the extracted config to verify its integrity, or did you rely on the script's exit codes?