Showing posts from 2013

Default Value for Secure Store Implementation Field

When you import a BDC model into Central Administration in SharePoint 2013, you often need to configure it to use a Secure Store Target Application. This is straightforward to an extent:
Browse the external systems in your BDC service application.Click through to the settings of the external system that corresponds to your BDC model.Select an appropriate Authentication Mode for your Secure Store Target Application (Impersonate Windows Identity or Impersonate Custom Identity).Provide the target application ID for your secure store target application. The tricky bit is that SharePoint expects you to provide a value for Secure Store Implementation. If you've changed the authentication mode from User's Identity or BDC Identity, this field will be blank:

What you actually need to type in this Secure Store Implementation field is the fully-qualified type name for the secure store provider. Unless you've built your own secure store provider (in which case you're the ultimate S…

Adding Active Directory OU Members to a SharePoint 2013 Group

Over the last few months we've been busy writing the SharePoint 2013 developer courseware for Microsoft (check out 20488B and 20489B). That hasn't left much time for blogging, so I plan to write a few quick posts on some of the more tricky things we had to figure out along the way.

First up: how to use PowerShell to import a bunch of users from an Active Directory OU into SharePoint and add them to a group. The script below does the following:
It adds a new group named Finance Members to the specified site.It links the group to the site as the associated members group.It grants the Contribute permission level to the group.It gets all the members of the Managers OU from Active Directory.It adds each AD user to the Finance Members group.
# Variables
$siteUrl = ""
$groupName = "Finance Members"
$groupDescription = "Members of this group can contribute to the Finance site."

# Load the SharePoint PowerShell snap-in
Write-Host "L…

Another Reason to Stop Developing Sandboxed Solutions

As you probably know by now, sandboxed solutions are no longer a preferred approach to development in SharePoint 2013. Wherever possible, you should use develop your custom functionality within a SharePoint app. If SharePoint apps don't offer the capabilities you require, you probably need a farm solution anyway, which leaves sandboxed solutions in a distant third place for SharePoint development.

However, there may still be reasons that compel you to create a sandboxed solution for SharePoint 2013. (In my case, it's because I'm writing a course that needs to cover sandboxed solution development). If so, there is a limitation you need to be aware of:

You can't run sandboxed code on a single server installation of SharePoint 2013 on Windows Server 2012 + domain controller.

You can install and activate the solution without any problems, but any sandboxed code will throw the following error:

An unknown exception occurred while executing a sandboxed code solution request in …

Product Catalog Sites and the Product Hierarchy Term Set

We recently ran into a perplexing issue with SharePoint 2013. We'd create a Managed Metadata service application, and we'd be able to create and use term sets without any issues. However, when we created a Product Catalog site, the site collection term store group and the Product Hierarchy term set did not get created. This is a fairly major roadblock, as the entire structure of the site (e.g. the Item Category site column, the Products list) is built around this term set.

In other words, you click this:

You expect to see this:

But you actually see this:

The Solution
On the properties for your Managed Metadata service proxy, you need to select the option This service application is the default storage location for column specific term sets. To do this, in the list of service applications, select the Managed Metadata service application proxy (be sure to select the proxy, not the service application itself). Then, on the ribbon, click Properties: 

Next, on the Edit Managed Met…

The Search Dictionaries term store group does not exist

Today's SharePoint 2013 configuration quagmire is this: you provision the Search service application, you click on Search Dictionaries - for example, to manage company name extraction or query spelling correction - and you see a largely empty term store.

In other words, you click this:

You expect to see this:

But instead you see this:

As is often the case with these issues, you'll probably that everything works fine if you use the Farm Configuration Wizard to provision your services. However, if you do things properly and create your service applications by hand, you come across this kind of issue.

The Solution
The Search Dictionaries term set group is not created when you provision the Search service application, it's created when you provision the Managed Metadata service application. When you create a Managed Metadata service application, it should create the Search Dictionaries and the People term set groups in addition to the System group. However, this will only happ…

The target principal name is incorrect. Cannot generate SSPI context.

Today's problem occured after I restarted a Hyper-V based SharePoint 2013 farm (Windows Server 2012, one SharePoint 2013 machine, one SQL Server 2012 machine, one DC). I fired up Central Administration and was hit with the following error:

Unknown SQL Exception 0 occurred. Additional error information from SQL Server is included below.

The target principal name is incorrect. Cannot generate SSPI context.

After checking the obvious things - testing connectivity to the DB server, checking the SQL service was running, verifying permissions, etc - I initially figured this was an issue with my Hyper-V snapshots being out of sync, so I ran the SharePoint Products Configuration Wizard. This hit me with the following error:

Failed to detect if this server is joined to a server farm. Possible reasons for this failure could be that you no longer have appropriate permissions to the server farm, the database server hosting the server farm is unresponsive, the configuration database is inaccessib…

We don't know what happened, but something went wrong. Could you please try that again?

I recently ran into an issue I hadn't seen before when configuring Excel Services on SharePoint 2013 RTM. I'd performed all the configuration steps described on TechNet. However, when I tried to browse to a workbook, I got the following error:

I checked the event logs and the trace logs, and the root of the problem was an Excel Services Application error with event ID 5226: Unable to create or access workbook cache.

This might seem like a straightforward permission issue. However, what also tends to happen in this situation is that the IIS application pool will stop, and this error gets buried under many more generic errors. (I've seen event IDs 5231, 5239 and 5240, for which the official advice is to restart the server. Obviously in this case that isn't much help.)

The fix is straightforward - change the permissions on the %WINDIR%\Temp folder. As a managed account, the Excel Services application pool is a member of the local WSS_WPG security group, which has read and…