Bitdefender Housekeeping We Wish Every Client Did
A short, opinionated list of Bitdefender GravityZone housekeeping jobs every admin should be doing every month, and the failure modes when they're not.
TL;DR. GravityZone is not fit-and-forget. Most broken Bitdefender tenants we audit aren’t broken because Bitdefender is bad. They’re broken because nobody has logged into the console with intent in six months. Here is the short list of housekeeping jobs that take a few hours a month and head off the “why didn’t this catch X?” conversation nobody enjoys having on a Sunday night.
Right. Rant mode on. We audit a lot of Bitdefender GravityZone tenants. Ones we manage. Ones we inherit. The pattern is depressingly consistent. The product is fine. The deployment was fine. The housekeeping never happened. Here is what we wish every client did, monthly.
The list
1. Action the Risk Management dashboard. For real.
Risk Management is the most under-used feature in GravityZone. It scores every endpoint on misconfiguration (open RDP, autorun on, SMBv1 still hanging around) and on user behaviour. Most clients open it once during onboarding, nod at the score, never look again.
Open it once a month. Sort by severity. Pick the top three. Action them. If autorun is on across 200 laptops, fixing it via policy is twenty minutes of work that turns a popular ransomware delivery path into a non-event.
2. Don’t run file servers on the default policy
The default BEST policy is built for laptops. On-access scanning everywhere, full ATC, the works. Point it at a file server with a 400 GB SQL Server database and the I/O penalty is not subtle. Then someone disables on-access scanning “because Bitdefender was slow” and you have a server with no protection at all.
Build a server policy. Or several. Database servers, file servers, RDS hosts each need their own. One afternoon. Performance and protection both improve.
3. Use vendor-recommended exclusions, not blanket ones
This one makes us tired. We open a tenant, look at the exclusions list, find C:\ excluded. Or *.exe excluded. Or the whole D:\Apps\ tree excluded. Whoever did that has shipped you a tenant with no antivirus on it.
Use the vendor exclusions. Microsoft publishes them for SQL Server (MDF, LDF, NDF files plus the Binn and Backup directories). Veeam publishes them for Backup & Replication (the VBR repository directory, the vPower NFS cache, VeeamAgent.exe). Exchange and Hyper-V each have their own. Add only those. Document why each exists.
4. Configure email alerts (“checking the dashboard weekly” is not a strategy)
If your incident plan starts with “I check the GravityZone dashboard every Monday”, your plan has two-and-a-half days of dwell time built in for a Saturday-night ransomware deployment.
GravityZone has solid email and webhook alerting. Critical detections, blocked ransomware attempts, EDR incidents, agents that have stopped reporting. All of it can fire to a mailbox or Teams channel the second it happens. Configure it. Test it. Add a second recipient because the first is on leave eventually.
5. Keep the agent build current
The BEST agent updates itself, mostly. Until it doesn’t. Old machines, machines off for months, machines behind weird proxies, machines where someone disabled the update relay: all end up running an agent build from eighteen months ago. Signatures are current. The behavioural engine is not. New detections in newer builds simply do not run.
Pull the agent-version report monthly. More than two minor versions behind, push a redeploy. More than a year behind, redeploy and find out why.
6. Test your update relay if you have remote sites
GravityZone supports relay agents. One local endpoint per site distributes updates and policies to the rest, instead of every laptop pulling 200 MB from the cloud over a 10 Mbps WAN link. Lovely feature. Frequently misconfigured.
The failure mode is silent. The relay stops being a relay (someone reinstalled it as a normal endpoint, role never re-enabled), every site endpoint falls back to direct cloud updates, and your branch office bandwidth gets eaten alive on Patch Tuesday. Nobody notices until the office manager phones to ask why Teams is choppy. Test it quarterly.
7. Audit the “not reporting” list weekly
Any endpoint that has not checked in for seven days is one of two things. Decommissioned, in which case it should not still be in the console eating a licence. Or broken: agent crashed, machine off, network blocked, user disabled the service.
Either way, deal with it. Decommissioned machines get removed. Broken agents get reinstalled. A five-minute job that prevents the much longer “we thought we had 312 endpoints protected, turns out 41 haven’t reported since November” conversation.
8. Verify FDE recovery-key escrow if encryption is on
Full Disk Encryption is brilliant right up until you need a recovery key and can’t find one. We have seen this. The keys should be in the GravityZone console, escrowed automatically by the agent. Sometimes they aren’t: agent reinstalled after encryption, key never re-escrowed.
Export the recovery-key inventory monthly. Compare it to your endpoint inventory. Anything encrypted with no key in escrow is a future support call you really don’t want. Fix it while the user can still log in.
Right, the obligatory CTA
If you read that and thought “yeah, I should be doing this”: go do it. The GravityZone buying guide and the cross-platform deployment walkthrough are next door. If you want broader context, the Bitdefender page covers the wider stack.
If you read that and thought “I am not going to do this every month, who am I kidding”: that is exactly what our managed Bitdefender service is for. Risk Management actions get actioned. Exclusions get audited. The non-reporting list gets chased. You get a monthly report and an engineer’s mobile number, which is more useful than a dashboard nobody opens.
Either way: do not let your GravityZone tenant become someone else’s audit horror story.
