SCDPM 2012 R2 Exchange Mailbox Consistency Check
Recently ran into an issue where two of the mailbox databases on our Exchange server failed to create backups and failed consistency checks in System Center Data Protection Manager 2012 R2. It was a puzzling one, as the other two mailbox databases were happily creating recovery points.
The database generated an error that informed me that “Data consistency verification check failed for ****.edb of Exchange Mailbox Database **** on <email server>. (ID 30146 Details: Unknown error (0xfffffb4a) (0xFFFFFB4A))”. As a result of this we were unable to create any new recovery points due to the source being inconsistent.
Checking the logs on the email server itself revealed that every time a consistency check was requested, a VSS error was generated.

It appears that an old unused profile was preventing the VSS service from running. To remove the profile, I used the following steps:
- Log on to the system by using an administrative user account other than the user account that is experiencing the problem.
- Back up all data in the current user’s profile folder if the profile folder still exists, and then delete the profile folder. By default, the profile resides in the following location:
%SystemDrive%\Users\UserName
- Click Start, type regedit in the Start Search box, and then press ENTER.
If you are prompted for an administrator password or for confirmation, type your password, or click Continue.
- Locate the following registry subkey:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList
- Under the ProfileList subkey, delete the subkey that is named SID.bak.
Note: SID is a placeholder for the security identifier (SID) of the user account that is experiencing the problem. The SID.bak subkey should contain a ProfileImagePath registry entry that points to the original profile folder of the user account that is experiencing the problem.
- Exit Registry Editor.
- Log off the system.
- Log on to the system again.
Following this return to the DPM server and begin the consistency check for the affected database. The consistency check should now complete without error and a recovery point can now be created.