About Me

Having 12 years experience in Microsoft technologies.Since more than 7 years working in SharePoint technologies. Expert in providing consultation for SharePoint projects. Hands on with development and administration.

Friday, 5 April 2013

The local farm is not accessible. Cmdlets with FeatureDependencyId are not registered.- SP2010 PoweShell

There are two ways to check/resolve the issue. Basically it's related to the SP PowerShell console being not run for your login account.
 
1. Actually this issue belongs -
PowerShell version being used/installed in SP environment. Generally for SP 2010 the version would be 2.0, however, if you install Windows Management Framework 3.0, which will install PowerShell version 3.0. So we have make sure that , our PowerShell should take 2.0 version.
No worries, it's easy to find and update the same.
To find which version, run following command in your SP PowerShell management console.
 
$version = $host | select version
$version.Version

 
If you receive something like below. If the Major version is not on 2, then you will get this runtime error.
Major Minor Build Revision
—– —– —– ——–
3 0 -1 -1

Which means that, you console is running with 3.0 versions. Relax, there is way to point to 2.0 version.

How?
a) Go back to the SharePoint 2010 Management Shell Shortcut, right click and select “Properties”
Under the Shortcut tab, Target: section, insert "-version 2
into the path. Make sure its before the -NoExit.
b) 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 ‘ “
c) Click apply, and then Ok.
d) Launch SP PowerShell console. That’s it.. Done.
 
Note: If this approach doesn't work, please follow point 2 below.
 
2. Check whether your login account had farm access or not by using following PowerShell command
Get-SPShellAdmin - if you get same error, it means that, you don't access to farm.
Then login with account which has full rights on farm and run following command to add the user.
Add-SPShellAdmin -username DOMAIN\userid
And also grant full rights on farm configuration db (generally SharePoint_Config, however, it may vary based on your org needs) & SharePoint admin content db.
 

Wednesday, 20 March 2013

How to find Correlation ID token error in SharePoint 2010

What is Correlation ID?
 
In SharePoint 2010, you get a Correlation ID (which is a GUID) attached to your logs/error messages when something happens. This ID can then be used to lookup that specific error from the logs.
 
It's very hectic that to check id in log files manually by going to each web server and searching log files.

The correlation ID is written to the end of each line in the trace log files, which are by default stored in C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\LOG

There are two ways of getting actual error for Correlation ID with out checking log files.
 
Method1 - Using Powershell command
 
get-splogevent | ?{$_Correlation -eq "<GUID>" } - replace guid with your id.
 
And you can customize the command to view only specific information.
 
get-splogevent | ?{$_.Correlation -eq "<GUID>"} | select Area, Category, Level, EventID, Message | Format-List
 
Method2 - Query DB ULSTraceLog

You can search the WSS_UsageApplication database's ULSTraceLog view, which has a separate field for the correlation ID.

Example
select [RowCreatedTime], [ProcessName], [Area],
[Category], EventID, [Message]
from [WSS_UsageApplication].[dbo].[ULSTraceLog] where CorrelationId= 'B4BBAC41-27C7-4B3A-AE33-4192B6C1E2C5'