SharePoint 2013: Site in Read only mode after an interrupted backup


I came across an interesting issue recently where a customer was backing up a site collection via SharePoint Management shell & the backup process was abnormally terminated. This resulted in the Site being in Read only mode & the following message would show up when users browsed to the site.

“We apologize for any inconvenience, but we've made the site read only while we're making some improvements."

clip_image001

Go to "Site collection Quota & locks" in Central Admin & here is how the Status looks like. It is locked as “Read only" & all settings are grayed out.

clip_image003

Here is more on this behavior & how to get out of this situation.

In SharePoint 2013, we introduced a property MaintenanceMode for Spsite object which indicates the site is undergoing a Maintenance & is read only. SPSite.MaintenanceMode flag can be set on a site for several reasons like content database is in read only state, or site collection is being upgraded, backed up or moved.

If a site gets into a state where the action that set this has terminated in a way where this is still set, we run into this situation.

The way to clear this flag is use the ClearMaintenanceMode method in SpSiteAdministration object. Here is how it can be done via SharePoint Management Shell

------------------------------------------------

# $Admin = new-object Microsoft.SharePoint.Administration.SPSiteAdministration('http://weburl/sites/sitecollectionurl’)

$Admin.ClearMaintenanceMode()

-------------------------------------------------

The SpsiteAdministration.ClearMaintenanceMode method was introduced in April 2013 CU for SharePoint 2013. So you would need to upgrade the environment to March 2013 & April 2013 update available at Update Center for SharePoint 2013

 

References :

SPSite.MaintenanceMode property

SpSiteAdminstration Class


Blog By : Rajan Kapoor [MSFT]

 


Comments (17)

  1. Assembly Not found says:

    Where is this assembly and why is it not available?  Is there a separate update or reference to get this?

    This is the error I get when running your script.

    new-object : Cannot find type [Microsoft.SharePoint.Administration.SPSiteAdministration]: make sure the assembly containing this type is loaded.

  2. SPUser says:

    This was the solution for me 🙂 Thanks alot.

  3. Re: Assembly Not found says:

    Did you add the SharePoint snap-in before running the command?

    Add-PSSnapin Microsoft.SharePoint.Powershell

  4. Khim says:

    Fell into same issue. Fortunately conducts frequent manual backups whn workn on Portal. Restored to yesterday's backup, and jst reloaded my custom files/scripts and was up to date. Still downloading Microsoft's Cumulative Update anyway, bt im all gd to go.

  5. Vikas Katyal says:

    Thanks for sharing this tip. Good to know stuff.

  6. Sarika G says:

    Thanks! Solution work for me and save me 🙂

  7. Mike M. says:

    Thank you, this resolved my issue as well!

  8. Paul says:

    Add-PSSnapin Microsoft.SharePoint.PowerShell -ErrorAction SilentlyContinue

    #Clears all the maintenance modes for all Site Collections in the farm.

    $webapp = Get-SPSite -Limit ALL

    foreach ($site in $webApp){

    $Admin = new-object Microsoft.SharePoint.Administration.SPSiteAdministration($site.url)

    $Admin.ClearMaintenanceMode()

    }

  9. Suman says:

    Thanks, Solution works for me.

  10. Azra says:

    Thank you so much, you made my day!

  11. Ajit says:

    Unlock Site collection after interrupted backup without Installing Patches.

    $site = Get-SPSite http://siteurl/
    $site.GetType().GetProperty(“MaintenanceMode”).GetSetMethod($true).Invoke($site, @($false))

  12. anil kumar says:

    Hi Rajan,
    Thanks for sharing this info.
    In our DR servers, we set content databases in readonly mode and hence sites are showing this readonly message. Should we revert the content databases to read and write mode as well or just enough to run this powershell with setting Maintenance mode unlock?

  13. Scott Goode says:

    Saved my life, THANKS!

  14. Ankur Agarwal says:

    Life saver Man.. thanks a lot

  15. samolpp says:

    Thanks for the article and ps script, that worked like a charm!

  16. Umr says:

    Hi ,
    We are at Nov 2015 CU and see the same error one morning on SharePoint site in Production . No back up job or any other upgrade process was running at that time as it happen during the business hours. I searched the whole logs and could not find out a single entry for this behavior. How ever after running your PS script it went away but I will like to know if there is a way to see why it happened at the first place?

    1. Spses says:

      Hi Umr,
      Unfortunately there is NO way that we can comment on why this happened without looking at the relevant logs. The possible ways are already mentioned in the blog and I am sure that you checked for all of those. The logs should be collected from the time that you suspect the property was set to true till the time you cleared it off. Moreover the severity of the logging also plays a role in getting the right info. If the Sharepoint logs are not with Verbose/VerboseEX severity, we may not get a right clue. If you have these info, please open up an advisory case with us and we will further look in to it for a possible cause.

Skip to main content