Category Archives: SharePoint

SharePoint 2010 PowerShell incompatibility with .NET 4.X

There is a known compatibility issue with SharePoint 2010 and Windows Management Framework 4.0 (WMF), which also includes PowerShell 3.0. If you install these components on a server that also runs SharePoint 2010, you may encounter errors when running SharePoint PowerShell cmdlets:

PS C:\> Add-PSSnapin Microsoft.SharePoint.PowerShell
The local farm is not accessible. Cmdlets with FeatureDependencyId are not registered.

PS C:\> Get-SPEnterpriseSearchServiceApplication
Get-SPEnterpriseSearchServiceApplication : Microsoft SharePoint is not supported with version 4.0.30319.1008 of the Microsoft .Net Runtime.

Although this is not a supported configuration, there is a workaround to force PowerShell 2.0 documented in KB 2796733 – SharePoint 2010 Management Shell does not load with Windows PowerShell 3.0

What isn’t mentioned in the KB article is a different combination when this issue can occur, even if WMF 4.0 isn’t installed. If your PowerShell version is 2.0 but configured to run with .NET 4.x CLR, you will still see the errors.

The $PSVersionTable will show the version of PowerShell and .NET that is being used.  If it shows a CLRVersion of 4.x, you will probably still have problems running SharePoint 2010 cmdlets:

PS C:\> $PSVersionTable

Name   Value
—-   —–
PSVersion  2.0
CLRVersion  4.0.30319.1008

You can override the .NET CLR version with these steps:

  1. Create or edit a file at $pshome\powershell.exe.config
    1. If you use the ISE, also do the same for powershell_ise.exe.config
  2. Insert or edit the contents so that the line for the v2.x supportedRuntime is listed before the v4.x line.

    <?xml version=”1.0″?>
    <configuration>
    <startup useLegacyV2RuntimeActivationPolicy=”true”>
    <supportedRuntime version=”v2.0.50727″/>
    <supportedRuntime version=”v4.0.30319″/>
    </startup>
    </configuration>

  3. Save the file and reopen any previous PowerShell sessions
  4. Test by adding the SharePoint snap-in, and running some SharePoint cmdlets, e.g.

    Add-PSSnapin Microsoft.SharePoint.PowerShell

This is similar to the procedure described in this post, but with forcing .NET version 2.x instead of version 4.x.

If this helps you, or if you still encounter these issues when running SharePoint 2010 PowerShell cmdlets, please post a comment or send me an e-mail.

CREDIT: https://blogs.technet.microsoft.com/alexsearch/2013/12/11/sharepoint-2010-powershell-incompatibility-with-net-4-x/

SharePoint 2010 Survey Issue

I recently had a problem where I have a site for hosting #SharePoint #Surveys. This was working amazingly with custom permissions so the users could only add items. The problem came when we introduced #branching into the questions. It appears that SharePoint creates the item after the first question so when the second one comes around the user will get “Access Denied” message. Obviously something as simple as this to fix shouldn’t have taken this long to figure out!

So if you have the same problem, just give your #PermissionLevels edit access as well as #AddItems – especially if you want to use branching!

Degraded Search SharePoint 2013

So recently I came across this error within #SharePoint2013.

Search service overall state: Degraded

1

This was actually really easy to fix for me in this instance.  Both of my WFE’s had run out of space on the Index #LUNs. As soon as I expanded the disk, the #Degraded warning triangle disappeared!

Nice and simple but make sure you check this before resetting the Index.

Restart SharePoint 2013 Workflows with PowerShell

Recently I had an issue where my #SharePoint list #workflows wouldn’t run and were in suspended state. The reason for the suspended state was an item already existed in the destination folder where the workflow was supposed to move the file to.

I tried lots of tricks to get the workflows to automatically start, I had about 250 instances of this happening and no scripts I found online would resolve this issue. They just wouldn’t cancel / resume.

In the end I removed the workflow from the list (which killed all instances) and then republished. Perfect. Now how to start them all again? Hmm

Well because these are #SharePoint2013 Workflows that run on a workflow management server, the normal scripts for starting them are different. To cut it short, use the following #script and all should be good.

$sourceWebURL = ‘http://YourURL
$sourceListName = ‘YourListName
$TargetWorkflow = ‘YourWorkflowName
$spSourceWeb = Get-SPWeb $sourceWebURL
$spSourceList = $spSourceWeb.Lists[$sourceListName]
$items = $spSourceList.getItems()

# Getting a Workflow manager object to work with.
$wfm = New-object Microsoft.SharePoint.WorkflowServices.WorkflowServicesManager($spSourceweb)
# Getting the subscriptions
$sub = $wfm.GetWorkflowSubscriptionService()
# Getting the specific workflow within the list of subscriptions on the specific list. (SP2010 associated workflows basically)
$WF = $sub.EnumerateSubscriptionsByList($spSourcelist.ID) | Where-Object {$_.Name -eq “$TargetWorkflow”}
# Getting a Workflow instance in order to perform my commands.
$wfis=$wfm.GetWorkflowInstanceService()

Foreach($item in $items){
# Creating the dictionary object I need to parse into StartWorkflow. This could be most other workflow commands.
$object = New-Object ‘system.collections.generic.dictionary[string,object]’
$object.Add(“WorkflowStart”, “StartWorkflow”);
$wfis.StartWorkflowOnListItem($WF, $item.ID, $object)
}

All you need to do is edit the BOLD text above and you should be on your way. Copy and Paste it into PowerShell ISE and save as PS1. Then run the file through the SharePoint 2013 Management Shell.

Good Luck!

Creating default SharePoint permissions groups (Hostname site collection)

When you create a #Hostname #SiteCollection within SharePoint 2013 you will notice that the default user groups aren’t there. This is because they aren’t created when you use #PowerShell to create a hostname site collection.

To get these groups back, this can be done via PowerShell or simply doing the following:

Navigate to http://yoursitename/_layouts/15/permsetup.aspx

From this page you will see the following:

groups

Simply click on OK and the groups will be available.

The important part of the URL is

_layouts/15/permsetup.aspx

Have fun with your permissions!

Active X errors SharePoint 2013/ SharePoint 2010 & IE11

This may not be the same for everyone but I recently had this error at work and it was doing my head in.

When a user got upgraded to IE11 from IE8 and went to a #SharePoint site, they were presented with a nice #ActiveX error that just wouldn’t go away! After lots of Investigations and Googling I still couldn’t find a solution.

FIX: 

Eventually I decided to get our #webapp URL’s and Host-name site collections added into the trusted site list and deployed via #GroupPolicy

Now we don’t get any #ActiveX issues within the sites we added to the trusted site lists.

As I said above, it might not apply to everyone but it certainly worked for the company that I work at.

Code blocks are not allowed in this file

Problem

Users report the following error when attempting to access a document library in #SharePoint.

An error occurred during the processing of /site/SharedDocuments/Forms/AllItems.aspx. Code blocks are not allowed in this file.

Explanation

Ever so often I have clients contact me with a SharePoint library fully corrupted reporting an error such as “Code blocks are not allowed in this file”.  The error is, in fact, limited to a specific view but it’s usually the default view, therefore the error makes the library appear like it is completely inaccessible.  The root cause of the error is simple – a user replaced a view file from the /forms/ folder of the document library, typically “AllItems.aspx” such as the screenshot below suggests.  Typically this occurs when the user is using explorer view but I’ve heard of manifest presentations of this error as well.

Solution

1) Open site that contains the library

2) Click on “Site Actions” >> “Site Settings” to view the site settings page “_layouts/settings.aspx”

3) Click on the library that displays the error to view the library’s settings page

4) Add a new view to the library and check the box “default view”

Host-named Site Collections

You must use #Windows #PowerShell to create a host-named site collection. You cannot use the #SharePoint 2013 Central Administration web application to create a host-named site collection, but you can use Central Administration to manage the site collection after you have created it.

You can create a host-named site collection by using the Windows PowerShell New-SPSite cmdlet with the -HostHeaderWebApplication parameter, as shown in the following example:

To create host-named site collections
  1. Verify that you have the following memberships:
  • The securityadmin fixed server role on the SQL Server instance.
  • The db_owner fixed database role on all databases that are to be updated.
  • The Administrators group on the server on which you are running the Windows PowerShell cmdlet.

An administrator can use the Add-SPShellAdmin cmdlet to grant permissions to use SharePoint 2013 cmdlets.

  1. On the Start menu, click All Programs.
  1. On the Start menu, click All Programs.
  2. Click Microsoft SharePoint 2013 Products.
  3. Click SharePoint 2013 Management Shell.
  4. At the Windows PowerShell command prompt (that is, PS C:\>), type the following syntax:
New-SPSite 'http://portal.contoso.com' -HostHeaderWebApplication 'http://<servername>' -Name 'Portal' -Description 'Customer root' -OwnerAlias 'contoso\administrator' -language 1033 -Template 'STS#0'

This creates a host-named site collection that has the URL, http://portal.contoso.com, in the SharePoint 2013 web application that has the URL ,http://webapp.contoso.com.