The state of California is a very unusual place in many respects. Not long after I moved there in 2010, a coworker told me that I should think of it as another country that happened to use the same currency as the rest of the states in the US. This turned out to be a handy guideline for how I thought about many aspects of life there.
I wrote a blog a few months ago titled How to Conditionally Require Data in SharePoint Columns. Since then, I’ve had several readers ask if it was possible to use list validation to conditionally require data in more than one SharePoint column. So, I decided, why not write a Part 2 to that blog to detail how to accomplish this.
I recently had request from a client to show current items in a list for users to preview as they created a new request. The actual requirement is listed below.
In my opinion, one of SharePoint 2010/2013’s unsung heroes is the Secure Store Service Application. I’m sure the vast majority of SharePoint users have never even heard of it. It’s one of those quiet, unassuming service applications that only a farm administrator can love. It is, however, potentially so much more than the place to hold your Excel and PowerPivot unattended account. In this blog, I hope to show you how you can use the Secure Store Service in a new and powerful way.
So What is This Secure Store Service?
The Secure Store Service Application (SSS) was added in SharePoint 2010 as a replacement for 2007’s Single Sign On feature. Its role in life is to map a SharePoint user (domain account) to a different account, such as a legacy system login. It stores the encrypted user information securely inside a farm database, and the service application provides a simple means to manage the accounts (called “credentials”). The administrator creates something called a Target Application. It defines the user configuration (including who has access to use it) and stores the remote user name and password.
Recently, I faced a really thorny issue regarding the Content Search Web Part in SharePoint Online. The customer is configured with a one-way, outbound hybrid topology with SharePoint Online/Office 365. We had Search Federation setup and working great on-premises. They setup a Content Search Web Part on their SharePoint Online home page to display all sites the user belongs to, and they wanted that same Content Search Web Part in their on-premises farm. What they found, however, was a puzzler: the exact same query configured the exact same way would return more results in SharePoint Online than it did on-premises.
We verified that the user had the proper permissions, the sites were being indexed, etc. A site that we found missing in the on-premises results could actually be returned if we narrowed the search just to its URL. We couldn’t explain the behavior, and understandably, it was quite a concern for the customer. However, I was finally able to crack the nut and figured others might be struggling with the same issue. The problem: duplicates and a probable bug in SharePoint Online.
Before moving into the details of the solution, let me give you some more background information.
(open in PowerPoint and play the slideshow to hear the presentation)
In a multi-farm environment, it is likely that data will be transferred between farms, either as one-off copies or migrations of entire sites. Microsoft’s implementation of the Managed Metadata Service (MMS) and its taxonomy/term store poses a significant challenge in a multi-farm situation. When a term is stored, it is given a unique, automatically generated identifier (a GUID) which identifies the term.