jessc2fi Part 2: How to Conditionally Require Data in more than one SharePoint ColumnPart 2: How to Conditionally Require Data in more than one SharePoint ColumnPart 2: How to Conditionally Require Data in more than one SharePoint ColumnPart 2: How to Conditionally Require Data in more than one SharePoint ColumnPart 2: How to Conditionally Require Data in more than one SharePoint Column

Part 2: How to Conditionally Require Data in more than one SharePoint Column

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.

sssblog sss1sss2

Get More Out of Your Secure Store Service via PowerShell and C#

Download: SecureStoreServiceHelper.ps1

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.  

cswpfi

Beware of Duplicates in SharePoint Online’s Content Search Web Part

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.

syncmms mmssyncblawsMMS_PPT

Sync a Managed Metadata Term Group with SharePoint Online or On-Premises

The Scripts

>Download the updated scripts .zip file

>Download the original scripts .zip file

>Download the Webinar

MMS_PPT

(open in PowerPoint and play the slideshow to hear the presentation)

The Problem

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.