I love working with SharePoint Server because there is never a dull moment on the job; the product is so rich and varied, and requires considerable knowledge of other systems and services, such as Active Directory, DNS, networking, SSL, SQL Server, etc. Working with SharePoint Server is a guarantee of learning something new nearly every day. On this day I discover a truly unique SharePoint error message.
I am performing routine maintenance on a SharePoint 2016 farm, cleaning up deprecated service accounts, to bring the farm into alignment with our project’s platform architecture security model. Using Central Admin (running on port 2016 of course!) at one point I need to refresh a page like so many times in a day but this time it comes with a little surprise, the page returns completely blank, with the bare minimum possible HTML. Whoa, what is going on?!
Well, I think, maybe it is just transient, so I hit the F5 refresh to get a clearer sense of the status of my SharePoint farm. Ooo ee, HTTP 404 Not Found. Eek, Central Admin is DEAD!
OK, don’t panic, I say to myself, not to worry, probably the app pool is hung up, so let’s just recycle it, and refresh the Central Admin page again. After a 30 second pause waiting for the app pool to come back, Central Admin reveals its true state, Server Error in ‘/’ Application!
Oh no, this is starting to look serious, I mutter. But never despair, it can be something simple. So I do as this all-too-common error page suggests and flip the Central Admin website’s web.config customErrors mode setting to RemoteOnly.
My favourite way to locate a SharePoint or IIS website root and its web.config file is to use Internet Information Services (IIS) Manager. So I select the website, in this case Central Admin, select Content View, and then Explore from the right panel Actions:
After an edit to the web.config, the change look like this:
The I save the web.config file and it automatically recycles the Central Admin website app pool to apply the new settings. Time for another F5 refresh in the browser to see what the actual error is.
Awesome, now I have a truly original, very precise, and quite possibly entirely misleading error message:
The error message text is:
This operation can be performed only on a computer that is joined to a server farm by users who have permissions in SQL Server to read from the configuration database. To connect this server to the server farm, use the SharePoint Products Configuration Wizard, located on the Start menu in Microsoft SharePoint 2016 Products.
OK, it is time for a little pause and a re-think. You can easily burns hours and hours researching and troubleshooting an error like that. So often with SharePoint the apparent error message is either a red herring or incredibly obscure and only tangentially related to the root cause. Think now, what if any config recently changed in the farm?
Ah yes, I am cleaning up some deprecated service accounts and am starting by disabling them in SQL Server Management Studio. Let’s check that out. Ooops, the farm account has a little red down arrow, it is denied and disabled!
Let’s look at the detailed properties:
That’s not right, SP_Farm has Permission to connect to database engine: Deny and Login: Disabled. How did that happen?! Leaving out out a few details and having simplified the screen snaps, suffice to say that there were several very similarly named SQL Logins and there was a slip up which one was previously disabled.
Let’s reset that!
Click OK to save and F5 refresh our browser for Central Admin, no need to recycle the app pool.
Yeah, Central Admin is back!
So all’s well that ends well, and it only took about 15 minutes. Luckily this happened in Test not Production!
So why blog it?
Because it is a funky error message that I’d never seen before so it deserves to be celebrated for that, plus the issue has a super easy fix that doesn’t require any elaborate analysis. Always keep the KISS principle (Keep it simple stupid) in mind when troubleshooting SharePoint Server.