This is now the second time I’ve seen this, but it is still a rarity and you should only do the following in extreme circumstances once you’ve determined it isn’t something else.
The Problem
A SharePoint Farm is humming along nicely when WHAM! all of a sudden you can’t login to your SharePoint Web Application, yet Central Admin is probably fine. No errors to speak of, no evidence of tampering. Access Denied for everyone including Site Collection Administrators.
The Reason
In our case it wasn’t clear. For the one customer, there is a “rogue SharePoint Admin” that we could easily lay blame on, but we won’t, at least out loud… ;). But my other instinct, based on the fact/timing of when it occurred (our http monitoring caught the almost exact time of the failure *and* backups were in the thick of it at the time) is that either running a file system backup somehow thwacked it, or antivirus, or a combination of the two (one of them locks the file and chaos ensues…).
Stooopid Antivirus Grumble Backup Snarl Software.
The Solution
So in our case, the database was actually AOK.
The solution was to:
- Delete the web application (but not the content database)
- Recreate the web application and reattach the content database(s)
Now the above is super-simplifying it, so let’s add a little more detail, to ensure nothing is missed
- Backup your Content Database(s) just in case you tick the wrong box
- Take an inventory of all the web application customizations (or refer to your notes, you do have good notes right?)
-
- General Settings
- Managed Paths
- Customizations in the web.config (hell, you should be backing up that too before you do what I’m suggesting, hint)
- Attached content databases
- Once you know you have everything to recreate the web application, delete it (but do not delete the databases)
- Do an IISRESET for good measure
- Recreate the Web Application and using that handy inventory you took, get everything back to a working state. When you create the web application, you can specify the existing database and simply reattach any others after the fact
Happy Hunting!
I have encouraged the same issue on my customer environment. When it append I was with one Microsoft Engineer on site for a RAP. He never saw this issue before, after a lots of testing we got it to work with the same solution you are mentioning.
But a week after the issue came back and recreating the web application was not fixing the issue. We had to assign new super user, reset the config cache and reset permission level.
Since we change the super user the issue never came back !!!
Interesting and thanks for sharing Patrick. I know what you are talking about as I had blogged on a similar topic a couple of months back (http://blog.brainlitter.com/2011/08/31/resolution-for-site-collection-admins-in-new-site-collection-get-access-denied/) but this time, it wasn’t just site collection admins but all users. I suspect you are right though, this site recently had publishing flipped on and it appears to be aggravated by SP1 though not immediately, which is certainly curious. Cache accounts are being enabled today to support it so hoping we don’t see a recurrence.
I had a same problem and your steps helped me to solve the problem.
Thanks
Hi Sean,
even i also got the same exception but in my case content DB is set to read only mode.
Please read my article for more details:
http://bit.ly/1MRKdhN
It may helpful to the our sharepoint collegues.
-Thanks,
Sasi Kumar Reddy
Just to add to Patrick’s comments here is an MS article that details those steps:
https://technet.microsoft.com/en-us/library/ff758656.aspx