Thank you TechNet! Deleting the Failed Requests

Thank you TechNet!
http://blogs.technet.com/b/askds/archive/2010/08/31/the-case-of-the-enormous-ca-database.aspx

Deleting the Failed Requests

The next step in this process is to actually delete the rows using our trusty command line utility certutil.exe. The -deleterow verb, introduced in Windows Server 2003, can be used to delete rows from the CA database. You just provide it with the type of records you want deleted and a past date (if you use a date equal to the current date or later, the command will fail). Certutil.exe will then delete the rows of that type where the date the request was submitted to the CA (or the date of expiration, for issued certificates) is earlier than the date you provide. The supported types of records are:

Name	Description	Type of date
Request	Failed and pending requests	Submission date
Cert	Expired and revoked certificates	Expiration date
Ext	Extension table	N/A
Attrib	Attribute table	N/A
CRL	CRL table	Expiration date

For example, if you want to delete all failed and pending requests submitted by January 22, 2001, the command is:

C:\>Certutil -deleterow 1/22/2001 Request

The only problem with this approach is that certutil.exe will only delete about 2,000 - 3,000 records at a time before failing due to exhaustion of the version store. Luckily, we can wrap this command in a simple batch file that runs the command over and over until all the designated records have been removed.

@echo off

:Top

Certutil -deleterow 8/31/2010 Request

If %ERRORLEVEL% EQU -939523027 goto Top

EXTRA... EXTRA... READ ALL ABOUT IT

FROM: http://social.technet.microsoft.com/Forums/en-US/winserverfiles/thread/47582917-9086-46a3-8fd1-5440e0a9c10f  

Cody Lewis

0 Points

 

0

Sign In to Vote

After many hours of reading logs and testing I have discovered the solution!

When the DFSR service is launched, it will detect the registry “HKLM\SOFTWARE\MICROSOFT\WINDOWS NT\CurrentVersion\ASR\RestoreSession\RestoredVolumes”, if this entry exists, DFSR knows a restore was once performed on the volume where the DFSR content resides, so DFSR will do an initial sync to confirm the local database is in a consistent state.

Problem is, this key is not getting removed, so when DFSR is disabled for backup, then enabled again, it believes it has just been recovered from backup and should sync again.

Remove the “RestoreSession” subkey under “HKLM\SOFTWARE\MICROSOFT\WINDOWS NT\CurrentVersion\ASR”.

Problem solved!

I hope this helps,

Cody

• Proposed

I have been experiencing a recurring error with DFS-R not syncing properly. After checking the logs, I discovered that DFS stops working every time Windows Server Backup begins to run. After changing my backups to every four hours only, replication began - in earnest! I triggered a replication storm! I also discovered this registry setting, and I hope that the solution is accurate. I hope to see some changes in my event viewer!