Step-by-step: Deploying the agent via Intune with custom config.

Wait, so you have to edit the config file *before* downloading the Intune package? I've been doing it after and wondering why things keep failing silently. That's a huge help, thank you!

I'm about to try this myself. For the detection rule using `bdscan.exe`, does that file show up immediately after a silent install, or is there a delay? I'm worried Intune might mark the install as failed if it checks too soon.

You're right about the silent switch needing to align. I've found that sometimes the silent install will complete, but the agent fails to register with the GravityZone console if a policy parameter is formatted incorrectly in the config. It appears successful locally, but the central dashboard shows it as offline.

Regarding detection, `bdscan.exe` does appear right after the installer finishes in my tests. However, Intune's timing can be inconsistent. To be safe, I set the detection rule to check for the file *and* verify the service "Bitdefender Security Service" is running. That seems to give Intune enough of a signal that the installation is truly complete.

Has anyone compared the registration success rate between using the policy ID in the config versus letting it auto-assign after install? I'm wondering if one method is more reliable with the silent switch.

Thanks for writing this up, the bit about editing the config *before* downloading the package is something I'd have missed for sure.

I'm planning a rollout soon and I have a similar question about the silent switch alignment. When you say to check it aligns with your config, do you mean just the `/silent` part, or are there other flags needed for a custom policy that the portal doesn't always make obvious?

Also, for the uninstall command, did you find a clean method through Intune, or is it just using the standard uninstaller that comes with the agent?

You're right to double-check the silent switch alignment. It's not just the /silent flag, you also need to confirm the installer isn't expecting any other interactive prompts that your config file is supposed to handle. Sometimes the portal's generated command line can omit parameters like /norestart if your config specifies a reboot policy, which can cause a hang.

For uninstall, I've had reliable results using the standard uninstaller path (the one in Program Files) with the /silent switch in Intune. It's cleaner than trying to package a separate removal tool, and it matches how the agent would be removed manually. Just make sure to test it on a pilot device first, as sometimes the uninstaller can wait for a pending scan to finish.

Exactly, that "pending scan" wait during uninstall can time out Intune's removal. I set the detection to also look for the uninstall string in the registry as a secondary check, so it doesn't prematurely fail if the agent's own cleanup is taking a bit.

Good call on matching the reboot flags. I ran into that hang once because the config had "reboot=1" but the command line from the portal didn't include /forcerestart. The agent just sat there waiting for a reboot prompt that never came. Now I always cross-check those three things: the silent switch, the reboot flag in the config, and the corresponding switch in the installer command.

Good catch on the signature break. I've also seen the agent install fine but then silently ignore the edited config if you modify it post-download. The signature check isn't always obvious.

For detection, I've had Intune freak out over `bdscan.exe` being present but the service not being ready. I added a PowerShell detection script that loops a few times checking the service state. It's a bit hacky, but it stops the false negatives.

On registration issues, I found that messing with the policy assignment in the config is a gamble. Half my test group registered fine, the other half just sat there with default settings. Now I just let it auto-assign and push the real policy after the first heartbeat. It's slower, but more reliable.

That's interesting about letting it auto-assign. I hadn't considered the delay as a trade-off for reliability. I'm curious, how long does that first heartbeat usually take after the install finishes? And does the agent show as unprotected during that window?

Using a registry key for detection is solid. I do that, but also set a return code requirement in the detection script - `bdscan.exe` can exist with a corrupt install.

For the silent switch alignment, I'd add you need to verify the installer version matches the config template version from the portal. I've had mismatches where new installer builds ignored old config keys, making the silent install succeed but with defaults.

Good to see the registration issue mentioned, as that's the real gotcha. I've found that even with a correct policy ID in the config, the agent's initial sync can sometimes fail if the network location service is delayed. It shows as "installed" but "unmanaged" for a few minutes.

Your point about editing *before* download is critical. I've also seen the package signature include a hash of the config, so any tampering after invalidates it. Some admins miss that because the installer might still run, but it'll just use default values.

That point about the installer waiting for a reboot prompt is a really good catch, I wouldn't have thought of that. So the config and the command line can be silently fighting each other on the reboot decision?

When you say to test the uninstaller on a pilot device first, do you just run the same silent command from an admin prompt to see what happens, or is there a better way to simulate Intune's removal timing?

Yes, exactly - the installer checks the config file for the reboot flag first, but if the command line explicitly says /norestart, the command line usually wins. That creates a deadlock where the config says reboot but the installer won't trigger it.

For testing the uninstaller timing, I run the command from an admin prompt with a log file, but I also add a 30-second sleep in a wrapper script to simulate Intune's evaluation delay. The uninstaller's exit code often returns immediately while processes are still terminating, so the registry key check is crucial.

Great start on the detection rule. I also use `bdscan.exe`, but found I needed to check the `BDAgent` service is actually running, not just the file existing. A stale install can leave the .exe behind.

On the registration issue you mentioned, I've seen that happen when the policy ID in the config is correct but the agent's initial sync gets queued behind a network location check. It'll show as installed but unmanaged for a few minutes. Letting it auto-assign and then pushing the policy after the first heartbeat is slower, but it eliminated those headaches for me.

One more thing: verifying the installer version matches the config template version from the portal. A mismatch can cause the installer to ignore your custom keys silently.

The registry key for uninstall detection is a solid approach. In my own benchmarks, I found that relying solely on `HKLMSOFTWAREMicrosoftWindowsCurrentVersionUninstall{GUID}` can still be problematic if the uninstaller creates the key but doesn't populate the `UninstallString` value immediately.

I started using a detection script that checks for the *absence* of the `DisplayName` value, not just the presence of the key. This catches scenarios where the installer's cleanup script gets stuck in a pending state but has already written the registry entry.

Regarding the reboot flag alignment, you're spot on. I've documented a specific failure mode where the config has `reboot=1` and the command line uses `/silent`, but the installer's internal logic defaults to `/norestart` when the `/forcerestart` switch is omitted. The agent then waits indefinitely for a system context that never triggers. My validation checklist now includes parsing the exact installer version's documented behavior, as this has changed between build 12.1 and 12.2.

Your bdscan.exe detection rule is fine, but it's not enough. You also need to check the service is running. A dead install leaves the file behind.

Don't trust the silent install. Test the uninstaller on a pilot device first. The uninstall exit code can be 0 while processes are still hanging, making Intune think it's gone when it's not.