Just stated to deploy my first SEP 12.1 implementation for a new client and came across a bug whereby the disk space on the system drive where SEPM had been installed was decreasing rapidly.  Investigation showed that the Endpoint Protection Manager is not configured by default to backup or truncate the log files for its database.

For more information from Symantec on the configuration of the truncate and index rebuild options please review the following KB article: http://www.symantec.com/business/support/index?page=content&id=TECH166658

One other thing that was pointed out by a colleague was that Backup Exec is unable to backup the Database files and you will need to configure SEPM to backup and export the data if you would like to recover the current SEPM configuration in the event of having to restore the server from backup.

To fix this is straightforward but led me to ask the question why Symantec wouldn’t think this needs to be enabled by default for the product.

 

I have spent the last few days trying to understand why a successful one time backup hadn’t flushed the transaction logs on my client’s Exchange 2010 server. We spent a lot of time troubleshooting message queues and looking for a transaction that hadn’t completed as the Backup job had reported successful. Digging a bit deeper into some of the job logs I can see that the one-time backup was doing a COPY – Full database and logs and not a FULL – database and flush committed logs.

Googling this came up with the following technote: http://www.symantec.com/business/support/index?page=content&id=TECH187838 and there is no way that you can change the option to do a full log flush in the one time backup.

I can’t fathom why this wouldn’t be a useful feature of the software to at least have the flush committed logs as a tickbox in the job options for the one-time backup.