32

This morning all the development machines at the company I work at, couldn't manage SharePoint through Powershell. We were all getting the annoying "The local farm is not accessible. Cmdlets with FeatureDependencyId are not registered." error.

A quick search has given me two causes for this error.

1: Wrong rights set for the user on the Config DB in SQL

2: Not running the Management Shell as Administrator

Neither of these two are the problem, since nothing has changed.

Improve this question
1
  • 1
    For me it turned out to be insufficient permissions on the configuration database in SQL.
    – TempaC
    Mar 27, 2013 at 9:12

8 Answers 8

Reset to default
32

Turns out the problem was caused by our wonderful operations guys ok'ing a windows update on our development machines.

The update in question is: Windows Management Framework 3.0 for Windows 7 SP1 and Windows Server 2008 R2 SP1

This update updates Powershell to a new version that uses .NET 4.xx and is not compatible with SharePoint 2010 resulting in the error described in the question.

There are two possible solutions.

  1. Add "-version 2" without the quotes to your Management shell link, to force running as an older version.
  2. Remove the update if you have no use for it, for other purposes.

So if you sudenly get this error on a server that has been running fine, check your Windows Updates.

Improve this answer
3
  • Very interesting answer, because I was recently very tempted to move to PowerShell 3. i'll wait for my 2010 boxes :)
    – Steve B
    Dec 13, 2012 at 15:13
  • 1
    Nice find! Good to know, will test PS3 on another machine...
    – SPArcheon
    Dec 13, 2012 at 15:29
  • 1
    I love our operations guys... They flagged the update as important, so now the evil thing is back.. I love when stuff like this is handled by policy.
    – Rasmus
    Dec 14, 2012 at 7:33
5

In followup to @JoeJohnston answer crediting me: If you want to play by the rules you won't go modifying permissions on the SQL Server directly. Here is an alternate approach that may work for you, provide you already have one account that can use PowerShell to connect to the SharePoint farm. I haven't had occasion to try it directly.

From SharePoint TechNet article Add-SPShellAdmin

Use the Add-SPShellAdmin cmdlet to add a user to the SharePoint_Shell_Access role as follows:

  • If you specify only the user, the user is added to the role for the farm configuration database.
  • If you use the database parameter, the user is added to the role on the farm configuration database, the Central Administration content database, and the specified database. Using the database parameter is the preferred method because most of the administrative operations require access to the Central Administration content database.

With an example

Add-SPShellAdmin -UserName CONTOSO\User1 -database 4251d855-3c15-4501-8dd1-98f960359fa6

Improve this answer
0
3

In my case the source of this exact error msg was that my Windows domain account was not granted rights to the SQL Server in the SharePoint farm. Once I used SSMS to add my account to the sysadmin role then the SP2010 management shell opened fine without this error. You may want to add this as an alternate stop-gap resolution.

Of course that begs the follow on question, why isn't my farm configured so adding my domain account to the usual AD groups makes everything right?

Credit John Calvert from a blog

Improve this answer
0
2

I updated target in my run command to look like this:

C:\Windows\System32\WindowsPowerShell\v1.0\PowerShell.exe -version 2 -NoExit " & ' C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\CONFIG\POWERSHELL\Registration\sharepoint.ps1 ' "

Improve this answer
2

I came across this issue too today, here is the solution - http://blogs.technet.com/b/meamcs/archive/2013/02/18/sharepoint-powershell-command-problem-featuredependencyid-are-not-registered.aspx

You can alternatively open the SharePoint Management Shell as a user that does have Shell access to the SharePoint config DB and then run the command Add-SPShellAdmin DOMAIN\Username of the user that needs shell access.

Improve this answer
2
  • JoeKir, Thanks for the post. But, we are not able to access the below link and it throws error. blogs.technet.com/b/meamcs/archive/2013/02/18/…
    – user19320
    Sep 4, 2013 at 14:38
  • @user19320: From the website: Make sure the logged in user who is trying to run SharePoint PowerShell commands is having the right "SharePoint_Shell_Access" to the SharePoint_Configuration database to do so: Open SQL Management Studio Browse Security folder — Logins , select the user name that is running power shell , right click properties Click on User Mapping , check SharePoint_config , select SharePoint_Shell_Access
    – invalidusername
    Jul 5, 2021 at 10:22
2

I recently faced this issue, fixed in SharePoint 2010 management shell shortcut but when I ran my .bat file to deploy solution I still got to see the same error. Checked .bat file and found this line, powershell -noexit -file "xyz.ps1" "%CD%"

So I changed it to following and it worked like charm, powershell -version 2.0 -noexit -file "xyz.ps1" "%CD%"

Improve this answer
2

If the issue is not related to the SQL permission, so you should update the SharePoint Shell target with the correct version as below:

For SharePoint 2016

C:\Windows\System32\WindowsPowerShell\v1.0\PowerShell.exe -version 3
-NoExit " & ' C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\16\CONFIG\POWERSHELL\Registration\\sharepoint.ps1 ' "

For more details, check The local farm is not accessible. Cmdlets with FeatureDependencyId are not registered in SharePoint

Improve this answer
2
  • Although this explains the fix the OP applied in detail, it does not explain why it works. For that, see the accepted answer, where the OP explains that upgrading PowerShell caused the original issue.
    – jpaugh
    Jul 5, 2019 at 17:21
  • @jpaugh the details explained in the mentioned link, I posted this answer for SP 2016 that using V3 not V2 as provided in the accepted answer!! Check first, before judge!!
    – Mohamed El-Qassas MVP ♦
    Jul 5, 2019 at 18:26
0

After I got this message in Management Shell, I tried to open the Central Admin site, which greeted me with another error message:

"Server Error in '/' Application. 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. ..."

So I went further towards SQL... In my case the reason was that the config database has been corrupted (by power outage). It's sign was a word "(Suspect)" next to the database's name in SSMS. One way to fix this:

-- Use the Master database
Use Master
 
-- Verify that database has issues
EXEC sp_resetstatus 'SharePoint_Config'
 
-- Put the database in emergency mode
ALTER DATABASE SharePoint_Config SET EMERGENCY
DBCC checkdb('SharePoint_Config')
 
-- Set the database in single user mode
ALTER DATABASE SharePoint_Config SET SINGLE_USER WITH ROLLBACK IMMEDIATE
 
-- Repair the database with data loss
DBCC CheckDB ('SharePoint_Config', REPAIR_ALLOW_DATA_LOSS)
 
-- Set the database in multi-user mode
ALTER DATABASE SharePoint_Config SET MULTI_USER
 
-- Verify that database is reset
EXEC sp_resetstatus 'SharePoint_Config'

Found on Nik Patel's site https://nikpatel.net/2011/03/02/sharepoint_config-suspect-mode-cannot-connect-to-the-configuration-database-error/

Improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.