Encountered this frustrating little nuance a few days ago whilst backing up a number of Path Based Site Collections and restoring them as Host Name Site Collections. Of the six sites I had been working with one of them was returning me the banner message shown below:
Image may be NSFW.
Clik here to view.
"We apologize for any inconvenience, but we've made the site read only while we're making some improvements."
Sites being left in Read-only following a site backup is something I have faced on numerous occasions and so isn't normally something that would cause much consternation. The usual corrective step is to navigate to Site Collection Quotas and Locks, select the affected site and unlock it. Having done so however, I was presented with the following:
Image may be NSFW.
Clik here to view.
Essentially, the option to reset the lockstate was greyed out. Any attempts to unlock using the Set-SPSite cmdlet failed and a check to ascertain whether the content database was set to Read-only confirmed it wasn't. A quick search quickly revealed the following thread: TechNet Forums Site Collection stuck in Read Only mode.
In the thread one victim of the issue had posted the solution offered by Microsoft having opened a support case with them. The solution offered by Microsoft in this case was:
$Admin = new-object Microsoft.SharePoint.Administration.SPSiteAdministration('http://site.collection.com')
$Admin.ClearMaintenanceMode()
$Site.MaintenanceModeWith SharePoint 2013, Microsoft introduced the MaintenanceMode property for the Spsite object which indicates the site is undergoing maintenance and is in a Read Only state. This property is set during certain operations, for example when a site collection is being upgraded, backed-up or moved.
If an operation does not terminate cleanly the site may be left in a Read-only state where the MaintenanceMode flag is still set which in turn results in the maintenance banner message being presented.
Microsoft introduced the SpsiteAdministration.ClearMaintenanceMode method as part of the April 2013 CU for SharePoint 2013 which allows this flag to be cleared via the PowerShell command shown above.
From my own perspective, on executing the above command the affected site was unlocked and I was able to continue. It's worth pointing out that the Backup-SPSite and Restore-SPSite cmdlet had both exited cleanly indicating that both backup and restore of the site had been successful and so there were no obvious signs that an error had occurred. A check of the site confirmed that to be the case and it is unclear to me whether the issue occurred during the backup or restore process.
Now there is a very clear lesson to be learnt here and that is the use of the -UseSqlSnapshot.
More Information: SharePoint Sites Backup & -UseSqlSnapshot
