Database log files are not truncated when you perform a full Certification Authority database backup

As part of joining PKI Solutions, several blog posts from my old site are re-posted here for visibility and thoroughness.

April 1, 2020 – The issue described here is applicable to Windows Server 2016 and older. Windows Server 2019 has changed the behavior of log truncation – when a backup is performed, all unused logs are purged and deleted. As a result, the stop/start issue associated with log truncation is not applicable in Server 2019

You have Windows Server 2008 R2 with installed Active Directory Certification Authority role. When you perform a full database backup by using either certutil.exe utility, or Certification Authority, the database log files are not truncated, as expected and backup set may contain up to 60 database log files. When using certutil.exe tool, it reports that log files are successfully truncated:

Backing up Database files: 100% 
Backing up Log files: 100% 
Truncating Logs: 100% 
Backed up database to C:\Backup. 
Database logs successfully truncated. 
CertUtil: -backupDB command completed successfully. 

In the Application eventlog you can find a record with EventID = 225 and the following message:

certsrv.exe (2420) No log files can be truncated. 

If you restart Certificate Services before database backup, all logs, except the newest (created after Certificate Services start), are successfully truncated.

In previous operating systems (Windows Server 2003 and Windows Server 2008), log files are truncated to the most recent log file after each successive backup.

CAUSE

This behavior occurs due to internal changes in Certificate Services JET database to provide better stability in the case of unexpected Certificate Services exit.

The following detailed description is provided for informative purposes only. The information below don’t provide any steps to change the behavior.

After securing a backup of the database and log files, the log files can optionally be truncated. Log file volume increases with database activity, and truncating the log files will reduce the redundant records in the log files (thereby decreasing the disk space used to store the log files).

The log files are provided for database integrity and efficiency. If a less-than-graceful exit occurs with the Certificate Services application, the next time Certificate Services is started, the database replays the log files to prevent data corruption from being introduced into the database.

Certificate Services database supports a number that is known as “checkpoint“. All log files behind this checkpoint number are protected from truncation. To determine the current checkpoint you can use esentutl.exe tool. The esentutl.exe tool is shipped with each Windows Server 2008 R2 installation and is stored in %windir%\System32 folder. Here is an example syntax to use:

esentutl /mk \edb.chk

and the following example output is returned:

Extensible Storage Engine Utilities for Microsoft(R) Windows(R) 
Version 6.1 
Copyright (C) Microsoft Corporation. All Rights Reserved. 

Initiating FILE DUMP mode...       
Checkpoint file: .\CertLog\edb.chk       

LastFullBackupCheckpoint: (0x0,0,0)       
Checkpoint: (0x3B,2E,70)       
FullBackup: (0x3B,8,16)       
FullBackup time: 11/26/2011 15:40:03

The number identifies the start log file number to protect. In a given example, the file is — edb0003B.log. Any log files subsequent to this number (edb0003C.log, edb0003E.log, etc.) are protected from truncation. Certificate Services database maintains 60 latest log files created from the last Certificate Services start. When 61st (and subsequent) log file is created, a checkpoint is increased by one to keep only 60 latest log files.

As mentioned in this section, when Certificate Services is successfully started, the database replays the log files to prevent data corruption from being introduced into the database. In this case checkpoint number is feed to the current log file ID, thereby allowing to truncate all log files, created before Certificate Services start.

STATUS

This behavior is by design.

WORKAROUND

No workaround, but see our other article on ADCS Backups for further details and how to manipulate ADCS to truncate all logs manually: https://www.pkisolutions.com/adcsbackups/