Having just completed my last speaking engagement of 2012 it was time to get back into the swing of things and start playing with troubleshooting a bit.
The dilemma
In a continuing effort to evolve my PowerShell build script for SharePoint I spent a few hours with my team playing with different settings. One of my team members was driving to get better hands on experience with using PowerShell to configure SharePoint.
We started with the very standard PSConfig script that I have used hundreds of times in the past:
(I left out the variables to save some space)
The following error popped its ugly head up in PowerShell’s angriest color when attempting to run this initial farm configuration:
New-SPConfigurationDatabase : Requested registery access is not allowed.
The troubleshooting
Check permissions
Hackles went up immediately when the error was read out loud. Prior to running the script we had just walked through several Security Best Practice checks, following Microsoft’s guidance in TechNet, partly to see if anything had changed recently (it hadn’t) and partly as a good refresher:
Account permissions and security settings (SharePoint Server 2010)
Plan administrative tasks in a least-privilege environment (SharePoint Foundation 2010)
Plan for administrative and service accounts (SharePoint Foundation 2010)
We went back and doubled checked all of our settings and found that things were configured as prescribed. The SharePoint install account had local administrator permissions on the SharePoint server and SecurityAdmin and DBCreator rights on the SQL server.
Examine the logs
We visited our Server Event Log and 14 Hive Logs folder but found no evidence that anything was in error. In fact, no logs entries were created at all…
Check the firewall rules
We validated that for this configuration, in a sandbox without external connections to the world, that the Windows Firewalls were turned off.
Check the connection between servers
Using the trusty Data Sources (ODBC) validation method we were able to make connection from the SharePoint server to the SQL server, and browse the available databases.
Get thyself to Google!
Completely perplexed at this point by an error that doesn’t make any sense due to the fact that the SharePoint install account was a local admin we went to our good friend Google and found, well to be honest a bunch of crap that didn’t help us in any way. Lots of stuff for people who have lost access to Central Admin due to GPO changes, or had a driver go corrupt, or are trying to write to the registry using C# in ASP.net, & even a forum about people having problem registering their car in Nebraska.
Review of Local Security Policies
One last ditch effort to check the local security policy to see if a new GPO pushed down changes to turned out fruitless, however one of the AD admins mentioned they had seen an issue similar to this once before they changed the User Account Control Settings (UAC).
The Root Cause
Not even thinking about it my response to the UAC question was “There is no need to do that, you just right-click and launch as Administrator or use my PowerShell script to run as a different user”
Upon examination of my team member’s screen it was revealed that: 
PowerShell ISE have in fact been opened without being run as Administrator. A costly lesson from a time perspective, but a good learning experience for a newbie at PowerShell for SharePoint.
The most troubling of all however was upon reexamination of the PowerShell error message we needed to only go 2 lines above the big red error message that we were troubleshooting on, to the plain black texted TRUE error: (highlighted here in yellow)
Unassuming and unnoticed as we troubleshot the obvious error, the line was thrown by the PSConfig.exe and not a bad PowerShell parameter which explains why PowerShell did not recognize it as an error.
The moral of the story…
Even after following every documented Best Practice out there, we still were able to find a way to cause an error. While the UI was bad for the error that would have been useful to us, it was at least thrown in our faces.
The easy answer is to always make sure that you open PowerShell or PowerShell ISE as Administrator. My personal preference is always going to be login in to servers using a non-SharePoint privileged account and then elevate permissions to run in the context of a SharePoint Farm admin or service account as demonstrated in my previous post which sets the run as Administrator for you.
Be sure when you are ready to do any SharePoint Admin work that you see the “Administrator:” in front of your PowerShell ISE path, like this:
At the end of a fun troubleshooting session we walked away with a new notch in our troubleshooter tool belt, a fun article to write, and team member who will never forget to fire the RunAs flag ever again 
