If a user has moved CDB on to another SQL instance with a different SMK (service master key), the connection between the SMK and DMK will be broken. To work correctly (e.g. a STP upgrade) with those CDBs, StoragePoint needs to regenerate the DMK with the following SQL query:
OPEN MASTER KEY DECRYPTION BY PASSWORD = '<DMK password>'; -- password used to protect DMK on previous/source SQL instance
ALTER MASTER KEY REGENERATE WITH ENCRYPTION BY PASSWORD = '<new or the same DMK password>'; -- could be used the same password but this one will be "secured" by target SQL instance SMK
CLOSE MASTER KEY;
You do not need to regenerate DMK if CDB does not have DMK or if the existing DMK is working correctly.
NOTE: SharePoint 2019 and above only. |
When the option Restore missing blobs is checked, and some BLOBs are missing from the endpoint, not all the missing BLOBs are repopulated.
BLOB Health Analyzer restores only BLOBs associated with a SharePoint file/attachment. In SharePoint 2019 and above, there are some BLOBs that are externalized and do not belong to any files, so even if they are backed up, they are not repopulated when the option Restore Missing blobs in BLOB Health Analyzer is checked.
If a storage profile has a backup endpoint configured and a SharePoint file (contained within the scope of the storage profile) is deleted, its residual BLOBs will be counted twice. They will appear both in the "Unused BLOB files marked for future deletion" field and in the "Unused backup BLOB files marked for future deletion" field, without necessarily having backup BLOBs of the SharePoint file.
If the storage profile does not have a backup endpoint configured, this behavior will not occur.
In the case of synchronized profiles, the number of BLOBs to migrate and the size of migrated BLOBs in the Migration Analyze and Estimate feature is inaccurate unless a BLOB Health Analyzer job has been run first.
© ALL RIGHTS RESERVED. Terms of Use Privacy Cookie Preference Center