Wednesday 10 April 2013

SharePoint 2013 - Configuring PowerShell

Powershell is great! Love it or hate it, it's become an essentially and awesomely powerful tool for SharePoint admins everywhere. But getting it up and running on a new server still presents the usual problems wtih permissiosns, configurations, version conflicts and a few wee hacks.

There's a lot to be done before you can run the Add-PsSnapIn command.

Step 1 - Installation

If you didn't run up the server yourself, then the first thing you'll want to do is make sure that Powershell, PowerShell ISE and the SharePoint 2013 Management Shell are all available.

Step 2 - Set-ExecutionPolicy

You will then want to set the script execution policy for the local machine to something useful like RemoteSigned, on your dev box anyway.

You can check this using:

> Get-ExecutionPolicy -Scope LocalMachine

And set it with:

> Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope LocalMachine

Lovely. At this point if u fired up the SP2013 Management Shell you'd likely receive the error below.

Add-PsSnapin : Cannot load Windows PowerShell snap-in Microsoft.SharePoint.Powe
rShell because of the following error: Could not load file or assembly 'file://
/C:\Windows\Microsoft.Net\assembly\GAC_MSIL\Microsoft.SharePoint.PowerShell\v4.
0_15.0.0.0__71E9BCE111E9429C\Microsoft.SharePoint.PowerShell.dll' or one of its
 dependencies. This assembly is built by a runtime newer than the currently loa
ded runtime and cannot be loaded.
At C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\15\CONF
IG\POWERSHELL\Registration\SharePoint.ps1:3 char:13
+ Add-PsSnapin <<<<  Microsoft.SharePoint.PowerShell
    + CategoryInfo          : InvalidArgument: (Microsoft.SharePoint.PowerShel
   l:String) [Add-PSSnapin], PSSnapInException
    + FullyQualifiedErrorId : AddPSSnapInRead,Microsoft.PowerShell.Commands.Ad
   dPSSnapinCommand

Yes, even after all this time there are still version conflicts to overcome.

So I created a powershell.exe.config file and saved it to the PS home directory in \Windows\System32\WindowsPowerShell\v1.0. Don't ask me why, but on native 64-bit systems, the 32-bit version is still used and the directory for PS v3 is still v1.0.

<configuration>
    <startup useLegacyV2RuntimeActivationPolicy="true">
        <supportedRuntime version="v4.0.30319"/>
        <supportedRuntime version="v2.0.50727"/>
    </startup>
</configuration>

Don't evern try to make these changes with the 64-bit version or you will run into a world of new problems with system directory redirects back to the 32-bit locations.

Terrific! Try to add the SharePoint Powerhsell Snap-In again and you're now likely to receive this.

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

Hmmm.... I ran off the usual check-list:

  • I'm a local admin and farm admin.
  • I ran the shortcut as Administrator.
  • I modified the shortcut to add the -version 2 flag as per SP 2010 fix (and then removed it).

All to no avail.

The culprit in this case was a SQL Admin who had failed to add the SharePoint farm admins group to the securityadmin and db_owner roles. :\

Hope this helps someone else.