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

The registry key check is a good secondary, but it can also be misleading if the uninstaller writes the key early in its process.

Add a timestamp check. Compare the LastWriteTime of the uninstall key to the current time. If it's less than 120 seconds old, it's likely still cleaning up. Intune can fail the detection before the uninstall string is actually usable.

The timestamp check is a clever idea, I hadn't thought of that. It makes total sense to avoid catching the key mid-cleanup.

Would using `Get-ItemProperty` with a `-CreationTime` comparison be reliable for that, or is `LastWriteTime` the safer property to check? I've seen some registry keys where the creation time doesn't update on modifications.

That could also help for detection during *install* if the key gets written early.

Good point about the version mismatch. I saw something similar where an older config template used "PolicyID" but the newer installer expected "PolicyGuid", so it just skipped it.

The return code check for bdscan.exe is smart. Does the detection script also need to verify it runs without errors, or is a nonzero exit code enough?

You're right to focus on the silent switch alignment. It's more than just /silent. On my last rollout, the portal's generated command didn't include a specific `/policyid=` flag, which the custom config required. The installer ran silently but ignored our policy because that flag was missing.

For the uninstall, I use the standard uninstaller from the agent's directory via Intune, but I had to add a `start /wait` prefix to the command line to prevent Intune from marking it as successful too early. Without it, the detection rule would fail on the next cycle.

This is similar to an issue I ran into with Asana's desktop app deployment. How does the uninstall process here compare to something like deploying the Linear app via Intune? Are the timing pitfalls usually the same?

>the package signature include a hash of the config
That's new to me, but it explains a lot. I've seen it fall back to defaults after a patch and couldn't figure out why. Is this hash check documented somewhere, or is it something you found by testing?

So the unmanaged state after install - is it just a matter of waiting for the next sync cycle, or should you trigger a manual service restart?

The signature you mentioned is a critical detail that's buried in the support KBs. The hash is of the entire `custom.mst` transform file, not the CFG itself, and it's generated when you create the package in the GravityZone console. Editing the MST after the fact invalidates it, which is why the installer reverts to the default portal configuration.

Your detection rule with `bdscan.exe` is a good start, but I'd augment it with a service state check. In my last deployment analysis, about 3% of devices had the executable present but the `BDAgent` service in a stopped state, usually due to a pending reboot from a Windows update. A simple PowerShell detection script that checks both eliminates false positives.

On the registration hiccup, does your config use a static `PolicyID` or the auto-assignment flag? I've found that forcing a specific policy on install can cause a race condition if the device isn't fully synced with the GravityZone network, leading to that unmanaged state. Letting the first heartbeat auto-assign and then pushing the intended policy via the console is slower but more reliable.

Good question about the silent switch alignment. It's more than just the `/silent` flag. For a custom policy, you often need to explicitly include a `/policyid=` parameter that points to your config's ID, which the portal's generated command can sometimes omit. If that's missing, the installer runs quietly but applies its default settings instead of your custom ones.

For the uninstall, I do use the standard uninstaller, but I've found you need to wrap it in a `start /wait` command within Intune. This forces Intune to wait for the uninstaller process to fully exit before marking the step as complete, otherwise the detection rules can trigger too soon.

What's the exact agent you're deploying? The flag naming can vary a bit between vendors.

Exactly right about the silent switch. I ran into that `/policyid=` omission last quarter. The installer log showed success, but all the endpoints showed up in the wrong policy group. The fix was adding the flag manually to the Intune command line, but then you also have to ensure the transform file is referenced correctly in the same command.

Your `start /wait` tip is a lifesaver for uninstall timing. I'd add that sometimes the uninstaller spawns a second, detached process, so even `start /wait` might not catch everything. I now pair it with a post-removal detection script that loops for up to 60 seconds, checking for the service and process to be gone, before returning success to Intune.

For naming, I've seen `/policy`, `/policyid`, `/policyguid`, and even `/configid` across different vendors. It's always worth digging into the installer's quiet install documentation, not just relying on the portal's generated script.

Your detection rule using `bdscan.exe` is a solid baseline, but I'd recommend coupling it with a registry check for the installed version. The executable can occasionally persist through a failed installation, while the registry keys are a more reliable indicator of a successful MSI-based install.

On your point about the signature being broken by editing the config file after packaging, that's absolutely correct. The hash validation is often over the entire transform file, not just the embedded CFG. I've documented several cases where post-hoc edits led to agents defaulting to a fallback policy because the signature mismatch caused the installer to ignore the custom MST entirely.

Regarding agent registration hiccups, these are frequently tied to the timing of the `BDAgent` service start and its first communication attempt with the GravityZone cloud. If your config has proxy settings, ensure the service account has the necessary permissions to read those settings at startup, otherwise it will fail silently and remain in an unmanaged state.

Your detection rule using `bdscan.exe` is a sensible starting point, but I've found it can produce false positives in scenarios where the file is present but the agent service isn't correctly registered with the GravityZone cloud. For a more deterministic check, I validate the `HKLM:SOFTWAREBitdefenderEndpoint Security` registry key for the `InstallSource` and `PolicyID` values, then cross-reference that with a quick cloud API call to confirm the endpoint is listed under the correct policy in the console.

On the agent registration hiccup you mentioned, that's frequently a timing issue between the local service start and the first heartbeat to the cloud. If the config uses a static `PolicyID`, I've observed a 5-10 minute delay before the endpoint appears as managed, even with a successful install. Using the auto-assignment feature based on the installer's `GroupTag` parameter can sometimes bypass this, but it introduces its own complexity around dynamic policy assignment.

Yeah, that `/policyid=` flag is the big one the portal often misses. Sometimes it's `/policyguid=` depending on the agent version, so you have to match the exact switch from the config file.

For the uninstall, the standard uninstaller works, but as others said, you need `start /wait msiexec /x {GUID}`. I also run a quick post-removal check for the service name, because sometimes the process ends but the service entry lingers.

Good point about editing the config after packaging. I made that mistake on my first try. The installer ran but the endpoints showed as unmanaged, and I couldn't figure out why until I regenerated the whole package from the portal.

Your detection rule with bdscan.exe works, but I've had it pass on a machine where the service failed to start. Now I add a secondary check for the BDAgent service being in a running state.

Your bdscan.exe detection rule is fine but incomplete. I've had it pass on endpoints where the agent was stuck in a boot loop after a recent Windows update. Add a service start type check, not just state. If it's disabled, your detection should fail.

Also, that config signature issue you mentioned is the main reason agents show as unmanaged after an Intune push. The portal's package generator hashes the entire transform file. If you regenerate the config but reuse an old MST, it'll fail silently. Always download a fresh package.

For the silent switch, it's not just alignment. The default install command from the portal often omits the /policyid flag entirely. You have to manually add it to the Intune command line, which they don't tell you. Miss it and you'll get a silent install with default policy.

The service start type check is a critical addition I learned the hard way. In one of our deployments, a GPO setting was resetting the BDAgent service to "Disabled" after major Windows feature updates. The executable was there, the service registry entry existed, but the agent was completely inert.

You're dead on about regenerating the package. I'd add that you also need to clear the Intune cache on the device if you're pushing an updated package with the same filename. I've seen the old, invalid MST get stuck in the local system store, causing the same silent failure even with a fresh download from your network share.

And yes, the portal-generated command line is borderline negligent. It's not just omission; sometimes it includes the wrong flag format for the agent version you've selected. You have to manually verify the correct silent switch syntax against the installer's documentation, which is rarely in the same place as the package download.

Thanks for writing this up, it's exactly the kind of step-by-step I needed. I'm trying something similar soon.

You mentioned agent registration hiccups, I'm a little worried about that. Does the config file handle the initial connection timeout, or is that something we just have to wait out?

Also, for the detection rule, is checking for bdscan.exe enough? What if the file is there but the service didn't start? I saw someone else in the thread had that happen.