SharePoint 2010 User Profile Sync Service

One of the big bugbears I’m having with SharePoint 2010 is the User Profile Syncronisation Service (UPSS). It has been a struggle on and off over many weeks, and I just cannot get it to work properly on our intranet farm. I’ve ready many, many well documented guides on how to configure UPSS, but never had a sucessful sync occur. There seems to be a general consensus online that UPSS is problematic.

In my attempts, I’ve played around with Forefront Identity Manager, applied hotfixes, recreated the service application and just about everything inbetween. After everything I have tried, I’m getting pointed down the route of starting again. The other complication is that the farm went unoffically into production, and now most of the organisation is using it. This makes it very difficult to be able to safely perform configuration changes and restart IIS without a lot of screaming from the end users. The situation has also been escalated as it appears no audiences can be applied due to he UPSS not currently being operational.

I recalled while reading Professional SharePoint 2010 Administration the notion of a Services Farm that does nothing else than provide SharePoint services to be consumed. This was reinforced at the Australian TechEd session SharePoint storage and physical architecture best practices. In summary, these services can be published from a Services Farm and consumed by one or more other farms. This can save a lot of duplication of effort, and instead of having UPSS, search, managed metadata etc for each farm, it can be consolidated and save the computing and operational resources to manage those.

Following this idea, I have planned out how I would like to see this work in my current environment, I also have the added requirement that HR may potentially wish to have their own, secure farm. This helps support my arguement going forward, and allows us to be flexible:

SharePoint UPSS Plan

I’ll post an update once I have this configured, hopefully I’ll have a chance within the next week to get this operational.

UPDATE: I’ve made significant headway on setting this up, and now compiling my ultimate guide to UPSS, MySites, Social Connectivity, People Search and Trusted Farms!

Security Concerns on SharePoint 2010 HR Site

A few weeks ago, I was approached by our HR department to advise how to best secure the personnel files inside SharePoint. There were some concerns that a number of staff (IT and non-IT) who had unncessary access to this data. So I outlined for them our structure, who had access at each level, and them some options to mitigrate their security concerns. The HR executive understood that it would be impracticle to totally remove IT staff access from accessing personnel files, but agreed that it should be limited.

Current Scenario

The current structure of the INTRANET is along the lines of:

(1)SharePoint Farm:    COMPANY FARM
(2)Web Application:    |__INTRANET
(3)Site Collection:       |__Human Resources
(4)Site:                  |__Human Resources Site (root of site collection)
(5A)Site (subsite):          |__Management Tools
(5B)Site (subsite):          |__HR Only
(6)Document library:            |__Personnel Files

Let’s look at how we can give acccess to the Personnel Files (6).

  1. At the lowest level (5B), a Site typically has the permissions defined in the Owners/Members/Visitors SharePoint groups. Removing access at this level, will block access for the majority of staff. Even with Visitor access at the top level site (4) we can prevent access to the lower sub-Sites (5B).
  2. At the Site Collection level (3), there is an overriding group called Site Collection Administrators that effectively have access or the ability to grant access to all content below it, including the HR Only Site (5B).
  3. At the Web Application level (2), we have a user policy defined, which gives a group of people full access to ALL site collections (eg Human Resources, Operations, Sales etc) and all Sites (inc HR Only (5B)).
  4. At the top most level (1) there are Farm Administrators. The role here is to manage the SharePoint infrastructure. These people, although they may not have explicit access to any Web Applications (2) or Site Collections (3), they are in a position to grant access to themselves or someone else. It will be impossible to not have some IT staff assigned at this level. There are no options to restrict Farm Admins from changing permissions.

In my original communication, I included a list of staff who had access, and it was quite clear there was an abundance of people with access at the latter to levels – (1) and (2) which is what gave most concern to our HR department.

Mitigation Options

  1. Enable full auditing on the HR Only site to record who has accessed information
  2. PRO: Quickest to achieve, will not require an internal approval processes (treated as BAU).
    CON: Won’t prevent access, will require monitoring from HR to review audit reports.

  3. Trim the people with access as a Farm Admin, within a Web Application User Policy and Site Collection Administrators for Human Resources.
  4. PRO: Quick to achieve.
    CON: Will require staff who do have permission to perform more administrative functions, will require a submission for approval.

  5. Create a separate web application just for HR and restrict Web Application User Policies and Site Collection Administrators
  6. PRO: Moderate effort to achieve, should be able to move existing content without a lot of rework.
    CON: Farm Administrators can still grant access to themselves or others, will require a submission for approval.

  7. Create a separate SharePoint farm for HR-INTRANET. Least amount of non-HR priviledges can be granted to this farm, and lock down the IT staff access.
  8. PRO: Most secure option, does not impact administration effort for INTRANET, should be able to move content across without a lot of rework, can provide a seamless transition between INTRANET and HR-INTRANET, can share some service applications across farms (eg managed metadata).
    CON: Most amount of effort to achieve initially, will require a submission for approval.

I suggested that if HR is happy that auditing will be sufficient to monitor access to the HR Only site, then mitigation option 1 would be recommended.

However if it is not sufficient just to know who has accessed Personnel Files, then mitigation option 4 would be suitable for a complete, separate HR SharePoint farm.

Site auditing was enabled as an immediate measure, and a proposal was submitted to proceed with the provisioning of a dedicated HR SharePoint farm. At the time of writing this is still awaiting approval.

Building the SharePoint House

I’ve been working on a SharePoint 2010 project lately, a migration from a SharePoint 2007 farm.  As usual in this particular organisation, there is never any time for any actual planning, but a desire to just trial and error it.  The only problem is, it has suddenly become production, and I’ve getting bogged down helping various people with site specific requests, rather than completing the infrastructure configuration (don’t even get me started on the user profile synchronization service…).

To help explain why everything is not yet configured, or why I have to keep performing IIS resets on the farm, I’ve been using an analogy to the staff who are coming to me – I call it the SharePoint House.

SharePoint is a big block of land, and we’re building a house (web application) on it.  Let’s call this house Portal.  Portal from the outside looks like a completed house – the foundations are down, there’s a roof, and we have a few rooms (site collections).  Some of these rooms have wardrobes or even other rooms contained within (sub-sites).

Within some of these rooms we have special functions (features) like a kitchen vs a bedroom, and they all have different looks and feels (theming, page layouts).  Inside the rooms, wardrobes etc is a bunch of storage items – drawers, cupboards, boxes – these are used to store stuff (libraries/content) and some of it may even be collated together to represent something in particular (content types).

Of course, no house would be complete without running water, electricity, gas, cable TV etc all connected up (service applications).

So when someone asks me questions or complains about the Portal, I explain the SharePoint House.  I then make a point that we didn’t use an architect to design the SharePoint House, we just started building.  Then all of a sudden, while we were still putting up rooms, everyone all of a sudden started moving in.  In the chaos of moving all their own stuff across, it was poorly organised and now hard to find.  To make matters worse, when anyone went to use the toilet…it wouldn’t flush.

Converting SharePoint 2007 list templates for SharePoint 2010

I’m hot on the heels of a SharePoint 2007 to 2010 migration project.  It had been decided not to upgrade, but to transition all of the content across and try and make better use of the document management features of SharePoint from scratch.

One of the first problems we discovered was for bringing across list libraries.  This was to be a simple task, simply save the list as a template, import into the new environment and it should just work. Unfortunately, I was greeted with an error along the lines of version 3 templates are not supported in this version of the product“.

Searching for the error, I came across the answer in this blog post of Importing SharePoint 2007 list templates (STP) into SharePoint 2010.

Tom’s solution  worked great, but there was no way I could get general users to extract the list template, edit the XML and re-package.  So I wrote this small PowerShell script:
#Script:  UpgradeSharePointList
#Author:  Peter Heydon (
#Date:	  16 September 2010
#Purpose: This script will convert a SharePoint 2007 list template to be SharePoint 2010 compatible.
#Credit for defining the conversion process:
#Credit for calling 7-Zip from Powershell:
#Everything else cobbled together from Microsoft TechNet
#	Three folders:	input		(SharePoint 2007 list templates)
#			output		(SharePoint 2010 compatible list templates)
#			processed	(SharePoint 2007 list templates that have been processed)
#	7z.exe (from 7-Zip installation:
#	makecab.exe (should be in your WINDOWS installation folder)
#WARNINGS:  There is zero error handling, so don't expect the script to be gracefull.  The script is supplied
#		'as is' and should be tested thoroughly before using in a production environment.  
$RootDir = "\\server\share\path\"	#Ensure it has a trailing backslash ('\')
Set-Alias sz ("C:\path\to\7zip\7z.exe")
Set-Alias mcab ("C:\windows\system32\makecab.exe")
#  Get list of all STP files
$InputDir = get-childitem ($RootDir + "input") 
foreach ($item in $InputDir | where {$_.extension -eq ".stp"})
	$targetFile = ($RootDir + "input\" +$
	$extractPath = $targetFile.substring(0,$targetFile.length-4)
	"Processing: " + $targetFile  
	#Create directory
	New-Item $extractPath -type directory
	#Expand STP File
	$extractPathOption = ("-o" + $extractPath)
	sz x $extractPathOption $targetFile
	#Replace files
	$manifestFileIn = $extractPath + "\manifest.xml"
	$manifestFileOut = $extractPath + "\manifestOut.xml"
	(Get-Content $manifestFileIn | Foreach-Object {$_ -replace "<ProductVersion>3</ProductVersion>", "<ProductVersion>4</ProductVersion>"} | Set-Content $manifestFileOut)
	#Cleanup files
	Remove-Item $manifestFileIn
	Rename-Item $manifestFileOut $manifestFileIn
	#Recompress (MakeCab)
	$itemNoExtension = $,$
	$CabFileName = ($RootDir + "\output\" + $itemNoExtension  + ".cab")
	$NewSTPFileName =  ($RootDir + "\output\" + $itemNoExtension  + ".stp")
	mcab $manifestFileIn $CabFileName 
	#Rename cab, and move to output folder
	Rename-Item $CabFileName $NewSTPFileName
	Remove-Item $manifestFileIn
	Remove-Item $extractPath
	#Move original file to processed folder
	Move-Item $targetFile ($RootDir + 'processed')

I have a scheduled task now running every 10 minutes during the day that will process all files in the input folder.  The process is simplified, I’m not having to get involved, so everyone is happy! Click here in order to Buy Windows 7 Ultimate Online for your office or home pc.

SharePoint 2010 Secure Store Service Error

Tonight I was configuring my SharePoint 2010 farm and attempted to “Generate New Key” for the Secure Store Service.  After entering my passphrase, I was presented with the error:

An error occurred during the “Generate Key” process. Please try again or contact your administrator.

Not very helpful, and neither was the event or ULS logs.  I found this post here from Trevor that describes the same error, and he advises to ensure that the logged in user is a member of the farm administrators group – but that was OK.

After turning up the diagnostic logging, I came across this line in the logs:

The Secure Store Service application Secure Store Service is not accessible. The full exception text is: User does not have permission to perform the operation.

This seems to concur with Trevor’s findings, however the next line in the logs was:

Unexpected exception from endpoint address : https://app01:32844/cabb71d36c534d49ba47bf4ca164e983/SecureStoreService.svc/https

App01 is one of five servers in my farm, and one of two application servers.  It seemed a bit suspicious that it couldn’t communicate on a particular URL, and both app01 and app02 had the Microsoft SharePoint Foundation Web Application stopped.  As soon as I started the web application on app01 only, I was able to generate the key for the Secure Store Service.

I then confirmed that the web application was still stopped on app02.  Very weird it had a problem with one and not the other.  Nonetheless I was able to generate the key.