ADCS Database Maintenance, Cleanup, and Performance Tuning

Most guidance on cleaning up a large CA database jumps straight to “delete the old certificates and compact the file,” without pausing on the fact that a CA database is also your audit trail. This post draws that line deliberately: what’s genuinely safe to clean up, what needs a policy decision before you touch it, and how to compact and tune the database without turning routine maintenance into a compliance or availability incident.

If you’re dealing with an actual restore rather than routine upkeep, see Restoring a Microsoft CA Database After Failure. For backup practices this maintenance work depends on, see How to Back Up Microsoft ADCS Correctly.

TL;DR: Key Takeaways

Failed and pending requests are the safe, supported cleanup target: they were never issued, carry no private key material, and aren’t part of your issuance audit trail, removing them is the primary, Microsoft-documented cleanup mechanism.
Deleting expired issued certificate rows is not the same kind of safe: it removes part of your CA’s historical record, which can conflict with audit and compliance retention requirements, treat this as a deliberate policy decision, not a routine database-shrinking step.
certutil -deleterow has a practical scaling limit: it typically processes only a few thousand rows per run before exhausting the database engine’s version store, a single invocation against a large backlog will appear to hang rather than complete.
Compaction and repair are not the same operation: esentutl /d defragmentation reclaims space after legitimate cleanup, esentutl /p lossy repair is a destructive last resort, conflating the two is how routine maintenance turns into data loss.
Performance tuning is mostly about I/O layout and scale planning, not deletion: separating database and log files onto different storage, and addressing revocation volume through CRL partitioning where appropriate, do more for sustained performance than periodic cleanup alone.

What’s Actually Safe to Delete From the CA Database

Failed and pending certificate requests: safe to remove: these were never issued, contain no private key material, and don’t represent a certificate anyone is relying on, they’re eligible for routine cleanup as standard operational hygiene.
Expired issued certificates: not a default-safe deletion: these rows are your record that a certificate was genuinely issued, to whom, and when. Many public guides recommend deleting them purely to shrink the database, without addressing that this removes part of your audit trail and may conflict with retention requirements in your CP/CPS or applicable compliance framework. Don’t treat this as routine maintenance.
Revoked certificates: leave to the CA’s own lifecycle management: revoked certificate records and expired CRL entries are managed through the CA’s own configuration (the CRLF_DELETE_EXPIRED_CRLS registry flag controls automatic cleanup of expired CRL objects specifically), manually deleting revoked certificate rows ahead of that isn’t a documented, supported practice.
Never edit the database directly, through any tool, as a matter of course: the CA expects its database, registry configuration, and certificate store to remain internally consistent, direct manual modification outside the supported certutil operations risks corruption that a routine cleanup task shouldn’t be introducing.

Cleaning Up Failed and Pending Requests Safely

Use the documented command: certutil -deleterow <date> Request removes failed and pending requests submitted on or before the specified date, this is the supported, primary cleanup mechanism for this category.
Plan for the version store limitation: a single invocation typically only processes a few thousand rows before exhausting the database engine’s version store and appearing to stop responding. For a large backlog, wrap the command in a loop that reruns it until no further rows remain, rather than assuming a long-running single call will eventually finish.
Run this during a maintenance window, not during peak enrollment volume: large-scale deletion is CPU-intensive against the Certificate Services process, schedule it accordingly rather than treating it as a background task you can run anytime.
Back up the database before starting, this is routine cleanup, not a high-risk operation, but a fresh backup before any bulk data operation costs little and removes any question about your recovery position if something goes wrong mid-cleanup.

Handling Expired Issued Certificates Responsibly

Check your CP/CPS and compliance obligations before considering this at all: many regulatory and audit frameworks expect issuance records to remain available for a defined retention period, confirm what your organization is actually required to keep before treating expired certificate rows as disposable.
If deletion is genuinely authorized by policy, export and archive first: use certutil -view to capture the relevant records to an external, retained format before removing anything from the live database, so the historical record still exists even if it’s no longer in the CA’s active database.
Treat this as an exception process with a documented decision, not a standard maintenance task, someone with authority over your CP/CPS and compliance posture should explicitly approve this, database size alone isn’t sufficient justification on its own.
Reconsider whether database size is actually the problem you’re solving, before removing historical issuance records, evaluate whether compaction, storage expansion, or CRL partitioning (for revocation-driven growth specifically) address your actual performance concern without touching your audit trail at all.

Database Compaction (Defragmentation)

Understand what compaction actually does: deleting rows frees space logically within the database file but doesn’t shrink the file on disk by itself, esentutl /d defragmentation is what reclaims that space at the file-system level.
Stop Certificate Services first: this is an offline operation, the CA cannot be actively issuing or servicing requests while compaction runs.
Ensure sufficient free disk space for a temporary database file, roughly comparable to the size of your existing database, compaction works by writing a new, defragmented copy before replacing the original, not by shrinking the file in place.
Run compaction after cleanup actually freed meaningful space, not as a routine standalone step, if you haven’t removed a significant volume of records, compaction has little to reclaim and isn’t worth the maintenance window on its own.
Take a fresh backup after compaction completes, and confirm Certificate Services restarts cleanly before considering the maintenance window closed.

Safe Diagnostic and Integrity Checks

Use esentutl /g for a non-destructive integrity check, this verifies the database’s internal consistency without modifying anything, a safe first step whenever you have a reason to suspect a problem.
Use esentutl /k to verify checksums, similarly non-destructive, and useful for confirming a backup or restored copy of the database is intact before you rely on it.
Do not treat esentutl /p (repair) as a routine tool: this is a lossy, destructive repair operation that can discard corrupted pages to bring the database back to a mountable state, it’s a last resort for a genuinely corrupted database with no viable backup, not a step in ordinary maintenance.
If integrity checks reveal a real problem, restore from backup rather than repair in place, consistent with the guidance in our restore procedures, a supported restore from verified backup data is the safer path in almost every case where one is available.

Performance Tuning

Separate the database and log files onto different physical or virtual storage, standard guidance for any ESE-based database (the same engine used by Active Directory and Exchange), separating sequential log writes from random database access reduces I/O contention meaningfully on busy CAs.
Monitor database growth trend proactively, not reactively, tracking size over time lets you plan storage and maintenance windows ahead of a problem rather than responding to an unexpectedly full disk.
Address revocation-driven growth with CRL partitioning where it’s genuinely warranted, rather than database cleanup, for CAs with high revocation volume specifically, splitting the CRL itself, covered in depth in our CRL partitioning architecture guide, addresses a structural scalability limitation that cleanup alone can’t fix.
Consider whether shorter certificate validity periods are quietly driving faster database growth, as certificate lifetimes shrink industry-wide, issuance and renewal volume rises correspondingly, factor this into your capacity planning rather than being surprised by accelerating growth later.

Building This Into a Maintenance Routine

Back up before every maintenance operation, without exception, cleanup, compaction, and integrity checks are all lower-risk than a full restore scenario, but “lower-risk” isn’t “no-risk,” and a fresh backup costs little relative to the alternative.
Document what was done, when, and by whom, for every cleanup and compaction operation, this is both operational history and, for anything touching issued certificate records, part of your compliance evidence trail.
Test cleanup and compaction procedures in a lab before running them against a production database for the first time, particularly the version-store batching behavior for large-scale request cleanup, understanding how long an operation actually takes against realistic data volume avoids surprises during a live maintenance window.
Schedule maintenance on a defined cadence tied to actual growth, not an arbitrary calendar interval, a CA with steady, moderate volume may need this rarely, a high-volume issuing CA may need it far more often, base the schedule on your monitored growth trend.

How Encryption Consulting Can Help

Getting database maintenance wrong in either direction, letting a database grow unmanaged until it becomes an availability risk, or cleaning up records that should have been retained, both create real problems that are much cheaper to avoid than to fix after the fact.

Encryption Consulting’s PKI Services team supports this directly:

Retention policy alignment: helping you determine what your CP/CPS and compliance obligations actually require before any cleanup touches issued certificate history.
Safe cleanup and compaction execution: planning and running database maintenance with proper backups, lab validation, and documented evidence at every step.
Performance and capacity planning: assessing whether your CA’s growth trajectory needs storage changes, CRL partitioning, or architectural changes, rather than defaulting to deletion as the first response to database size.
Integrity and health assessment: running non-destructive diagnostics against your CA database and advising on findings before anything destructive is ever considered.
Ongoing maintenance governance, so database health becomes a monitored, scheduled practice rather than a reactive scramble when a disk fills up.

If you’re facing a growing CA database and aren’t sure what’s actually safe to clean up, our PKI Services team can assess your situation and help you maintain it correctly.

Conclusion

Safe ADCS database maintenance draws a clear line: failed and pending requests are genuinely safe to clean up, expired issued certificates are not a default deletion target and need a real policy decision behind them, and compaction or repair operations should never be reached for casually. Back up before every maintenance operation, test procedures in a lab before running them for the first time in production, and address performance concerns through storage layout, CRL partitioning, and capacity planning before deletion becomes the default answer to a growing database.

Not sure what’s actually safe to clean up in your CA database? Talk to our PKI Services team about a safe maintenance and performance review. Encryption Consulting is ISO/IEC 27001:2022 and SOC 2 certified.

FAQ

Is it safe to delete failed and pending certificate requests from a CA database? Yes. Failed and pending requests were never issued, contain no private key material, and are not part of your certificate issuance audit trail, so they’re the primary, fully supported cleanup target using certutil -deleterow against the Request table.

Should you delete expired issued certificate rows to shrink the CA database? Not as a routine default. Deleting issued certificate records removes part of your CA’s audit trail and may conflict with retention requirements in your CP/CPS or compliance framework. Treat this as a deliberate, policy-authorized exception with prior export and archival, not a standard database-shrinking step.

Why does certutil -deleterow seem to hang or fail on a large CA database? certutil -deleterow typically only removes a few thousand records per invocation before exhausting the database engine’s version store. Running it once against millions of rows will appear to hang; the supported approach is to wrap it in a loop that reruns the command until no further rows remain to delete.

When should you defragment the CA database with esentutl? After a significant cleanup operation has actually freed up space, defragmentation with esentutl /d reclaims that space at the file-system level. It requires Certificate Services to be stopped and enough free disk space for a temporary database file, and isn’t necessary as a routine step outside of meaningful cleanup or genuine performance concerns.

Is esentutl /p a safe way to fix a CA database problem? No. esentutl /p performs a lossy repair that can discard corrupted pages, and it’s a destructive, last-resort operation, not a routine maintenance step. Restoring from a verified backup is the supported approach; reserve /p for situations with expert guidance and no viable backup.