Read-Only Lock

Comments

5 comments

  • Avatar
    Per Svedenbring

    We are going with AlwaysOn High Availability Groups and are having a problem. When the first SQL-server is primary it works. When we failover to the second we get this error in SharePoint:

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

    It seems locked somehow. The database properties says Read-Only = False.

    I try some coding:

    $SiteURL = "https://siteXXX"
    $Admin = new-object Microsoft.SharePoint.Administration.SPSiteAdministration($SiteURL)
    $Admin.ClearMaintenanceMode()

    or

    Set-SPSite -Identity "https://siteXXX" -LockState "Unlock"

    or 

    $site = get-spsite https://siteXXX

    $site.GetType().GetProperty("MaintenanceMode").GetSetMethod($true).Invoke($site, @($false));

    but Always get this error: "Failed to update database "SP_ContentDB_XXX" because the database is read-only.

    What is happening and any suggestion how to solve it? SharePoint 2016.

    0
    Comment actions Permalink
  • Avatar
    Alex

    Hello Per,

    Thank you for your comment. I'm going to go ahead and open a ticket with Support for you, they'll be better aligned to help you with this issue!

    Thanks. 

    0
    Comment actions Permalink
  • Avatar
    SHAREGATEADMIN Bapco

    What is the alternative? We want to restrict users from changing site content during migration, and were planning to use the read-only lock to achieve that.

    So what is the best practice alternative for preventing users from adding content?

    1
    Comment actions Permalink
  • Avatar
    Vic (Edited )

    Hi BAPCO,

    From a technical standpoint, options are limited. Establishing a good communication plan with your users is usually the way to go.

    If you are migrating from an on-premises environment to another on-premises environment (SharePoint 2019 and below), it is possible to use DNS redirection to bring your users to the new site(s) while you are doing an incremental migration from the old site(s).

    You will have to modify your host file for ShareGate Desktop to work during that incremental migration.

    If this is your scenario and you think this solution can work for you, don't hesitate to reach out to our excellent support team for assistance.

    0
    Comment actions Permalink
  • Avatar
    SHAREGATEADMIN Bapco

    Hi Vic,

    Thanks for the excellent answer. Our migration scenario is ON PREMISE SharePoint 2013 --> Office 365 SharePoint Online, so the DNS redirect trick probably won't work.

    I already asked the support team who suggested doing a cut-off incremental migration after the main migration is done. But I agree 100% that the biggest factor of success (given all circumstances) is a proper communication plan.

    Thanks again.

    1
    Comment actions Permalink

Please sign in to leave a comment.