This problem can be caused by the database signature for the private/public not agreeing with the signature of the log file(s). This is commonly caused by restoring Exchange but not clearing out the "mdbdata" directory. When Exchange is reinstalled or started, the database and log files are generated with a matching signature. If either one differs, the IS will not start. If your stores are consistent, clear the "mdbdata" and start the IS. If they are inconsistent, clear the contents of "mdbdata" and restore from backup or run “eseutil /p” on the “priv.edb”, “pub.edb”, and clear the "mdbdata" of all other files, then start the IS.
As per Microsoft: "After you defragment your database offline, it has a new signature that does not match the signature in the old log files. Retention of the old log files causes the database to fail to start and the following event ID 143 error message is logged: "The database signature does not match the log signature for database". Because the database was shut down correctly before you defragmented it, all the data was written to the database. You can safely move the log files from the production location to a temporary location. Then you can start the database". See ME255035
for more details.
This error occurs if you use the eseutil to repair or defrag and you do not remove the old log files. More information can be found in ME182903
In our case, symptoms appeared after an offline defrag of the DS and IS databases. You need to remove “.log” and “.chk” from the MDB/DSA directories and restart the corresponding services.
I received this error when trying to do an “eseutil –r” recovery on a corrupted Exchange 5.5 database after performing the “eseutil –p” repair. In the end, I figured out that after an “eseutil –p” repair I have to delete the entire log files before running “eseutil –r” or “isinteg –test”.