Cleaning Up Orphaned Objects In SharePoint Using PowerShell
You might have encountered a SharePoint Health Analyzer rule that states “Content databases contain orphaned items”. The TechNet article summarizes this rule where SharePoint Health Analyzer has detected some sites in content databases that are not referenced in the configuration database and these sites may not be accessible. Possible causes are incomplete restore operations resulting in sites in content databases which are not reference in SharePoint configuration database.
Although it conveniently shows the Resolution of just clicking the Fix Now button, this is something that you might need to think twice before doing, especially in a production environment. Clicking “Fix Now” or “Repair Automatically” is not recommended, most especially in a production farm as this could cause SQL deadlocks for large content databases. For example, you have more than 10 content databases on your SharePoint environment, clicking “Repair Automatically” is like blindly clicking what feels like a “Delete” button and hoping it fixes everything for you. Not a smart move if you ask us.
Config Orphan
Content Orphan
Instead of doing above, you might want to initially identify the orphaned items. These are items that do not have parent or child relationship which remain in the content database and left uncleaned. Orphan objects could be of type Config Orphan or Content Orphan. Config Orphans are sites that exist in configuration databases but do not have child item in content database while good examples of Content Orphan are documents that do not have a parent document library, web parts without assembly, or maybe a list or a page without a parent site.
Cleaning up config orphans will require detaching the content database with the orphan site and attaching it back. This performs a refresh and cleans up the orphan entries.
We can use PowerShell commands to remove content orphan objects. We can execute below command against all of our content databases.
(Get-SPContentDatabase ).Repair($false)
The false parameter indicates that the command will just display the items that would be repaired by the command. This will not, in any way, perform any repair action just yet. Validating these content databases will throw errors and these provide information on orphaned contents. Changing $false to true will do the actual repair process. What we do is we just use the PowerShell command to just examine the orphaned content and then work our way from there to look into the specific files. It could be as easy as completely deleting the file, or detaching and attaching content databases. Either way, a database backup is recommended before doing any of the corrections or automatic repair.
Send us your questions on SharePoint
Related Blog Post
The Joy it Gives
This blog has been quiet for over a year. Of course, I have to write my first post after a long time while experiencing flaky internet. Such has been the last few months for us - a lot of changes sometimes wanted and some surprises. Two of our For Dummies books...
SharePoint Cross-Domain Library Part 1: Getting To Know The Library
We have attempted to have an in-depth understanding of how permissions work in SharePoint add-ins in a blog post here and have mentioned a thing or two about the need for the cross-domain library when doing cross-domain calls. When you have for example built an app...
Customizing SharePoint Lists Using Column Formatting
Now available on "modern" SharePoint lists, column formatting is one way of applying custom formats to columns. Pretty much similar with the conditional formatting in Excel, column formatting makes it possible to apply styles to columns like CSS or modify the way data...