SharePoint 2013 Configuration – Cannot start service AppFabricCachingService on computer

As I mentioned in my last post, I’ve been spending time with SharePoint 2013 and once again have come across another little error regarding Farm Configuration.

Cannot start service AppFabricCachingService on Computer “.”.

As mentioned in my last post, there are some posts out there that suggest that you can circumvent Distributed Cache problems by Creating or Connecting to your configuration database with the –SkipRegisterAsDistributedCacheHost parameter, however this will result in the Distributed Cache Service Instance being absent from your farm, and I have at this stage been able to get it to reappear.  As it is pretty early in the game for SharePoint 2013 I am not yet sure the impact that not having a Distributed Cache Service will have on your farm, however it will likely be negative.

This particular problem seems to be permissions related as the Windows Service “AppFabric Caching Service” is unable to start when it is using the SharePoint 2013 Farm Account, and while I have not YET spent much time trying to figure out why this occurs, I was able to avoid the problem by adding my Farm account to the Local Administrators group.

Hopefully this post will help a few folks avoid a rather frustrating problem.

Note : Yes I am aware this is not best practice, however it may help a few folks get around the problem in what is likely to be a non-production test machine anyway as the software is still in Beta (Release Preview).  I’ll be looking into this further to try and find out exactly what permissions are required so that we do not need to add to the local admin group.

Advertisements

SharePoint 2013 Configuration – Failed to connect to host in the cluster

I’ve been spending a little bit of time around SharePoint 2013 and have been probing the various installation methods and came across this problem twice sp far while trying to configure SharePoint 2013 Farms.

Connect-SPConfigurationDatabase : ErrorCode<ERRCAdmin040>:SubStatus<ES0001>:Failed to connect to hosts in the cluster

There are some posts out there that suggest that you can circumvent this problem by Creating or Connecting to your configuration database with the –SkipRegisterAsDistributedCacheHost parameter, however this will result in the Distributed Cache Service Instance being absent from your farm, and I have at this stage been able to get it to reappear.  As it is pretty early in the game for SharePoint 2013 I am not yet sure the impact that not having a Distributed Cache Service will have on your farm, however it will likely be negative.

What seems to be causing this particular problem is an alias being used for the SQL Server, when your SQL Server is on another server.  Re-running the command or trying to establish your farm with the server name instead of the alias seems to avoid the problem.

Hopefully this post will help a few folks avoid a frustrating problem.

Note : This is not a solution, it is just a work around that might avoid frustrating and let you test out SharePoint 2013.

Adding 285 Contoso Users with Pictures to your Development Environment Active Directory

While I love the Information Worker Demo VMs that Microsoft make available, I really wish they would hang around more than the really short expiry they are currently set to, and besides while I like the stuff they have in their VMs I do not need all of it for my work.

What I really like is the pre-populated Contoso Active Directory, with all of the users, properties and profile pictures pre-populated.   I like it so much I took the time to export all of the values and code up a script that will add them into just about any Active Directory environment.

###################################################################################
# Title : Create Contoso Users in Active Directory
# Author : Mark Rhodes - markrhodes@gmail.com - @mrhodes
#
# Purpose : Creates 270+ users in Active Directory copied from the Contoso Information Worker Environment
#
# To Use : Extract all files and run "CreateUserAccounts.ps1 from an Administrative PowerShell prompt.
#
# Requirements :
# Active Directory RSAT tools installed.
# User Account with sufficient privilegse to create accounts in "USERS" Container.
#
# Files :
# CreateUserAccounts.ps1 - PowerShell Script
# ADUsers.csv - CSV file with all Active Directory properties
# Folder UserImages - 270 Images of users to be populated into the thumbnailPhoto property
#
# Warning! - Do not use this on a production directory.
###################################################################################
#Import Active Directory Module
Import-module activedirectory

#Autopopulate Domain
$dnsDomain =gc env:USERDNSDOMAIN
$split = $dnsDomain.split(".")
if ($split[2] -ne $null) {
 $domain = "DC=$($split[0]),DC=$($split[1]),DC=$($split[2])"
} else {
 $domain = "DC=$($split[0]),DC=$($split[1])"
}

#Declare any Variables
$dirpath = $pwd.path
$orgUnit = "CN=Users"
$dummyPassword = ConvertTo-SecureString -AsPlainText "P@ss1W0Rd!" -Force
$counter = 0

#import CSV File
$ImportFile = Import-csv "$dirpath\ADUsers.csv"
$TotalImports = $importFile.Count

#Create Users
$ImportFile | foreach {
$counter++
$progress = [int]($counter / $totalImports * 100)
Write-Progress -Activity "Provisioning User Accounts" -status "Provisioning account $counter of $TotalImports" -perc $progress
if ($_.Manager -eq "") {
New-ADUser -SamAccountName $_.SamAccountName -Name $_.Name -Surname $_.Sn -GivenName $_.GivenName -Path "$orgUnit,$domain" -AccountPassword $dummyPassword -Enabled $true -title $_.title -officePhone $_.officePhone -department $_.department -emailaddress $_.mail
} else {
New-ADUser -SamAccountName $_.SamAccountName -Name $_.Name -Surname $_.Sn -GivenName $_.GivenName -Path "$orgUnit,$domain" -AccountPassword $dummyPassword -Enabled $true -title $_.title -officePhone $_.officePhone -department $_.department -manager "$($_.Manager),$orgUnit,$domain" -emailaddress $_.mail
}
If (gci "$dirpath\userimages\$($_.name).jpg") {
$photo = [System.IO.File]::ReadAllBytes("$dirpath\userImages\$($_.name).jpg")
Set-ADUSER $_.samAccountName -Replace @{thumbnailPhoto=$photo}
}
}

I’ve made a zip file available that contains :

1 CSV file populated with all the values required.
1 PS1 file with the full script to create these users
1 Folder with 285 user images

All you need to do is unzip these, and run the PS1 file with PowerShell.  By default my script puts each user into the USERS container, however if you wish to change this, just modify the $orgUnit variable.

The script can be downloaded from my public dropbox here. It is approximately 14 MB due to the large amount of photos contained within.

Update – 26/10/2011 – Fixed a couple of minor bugs, including one that stopped this working on any domains with three parts in the domain name.

Fixing an orphaned Site Collection within Project Server 2010

I had the pleasure of getting to know Project Server 2010 a couple of months ago.  I am a big fan of the way this has been implemeneted, as a SharePoint 2010 Service Application based approach seems to make more sense than a completely seperate product.

During this installation I found out a few interesting things about Project Server :

  1. Do not try using Claim Based Authentication on your Project Server Web Application. It may look like it is working, but I assure you it is not.  Clicking around some of the less obvious areas of the site will probably reveal it is not working.
  2. Never, ever delete a /PWA Site Collection for any reason.  They look just like a normal SharePoint Site Collection, but doing this will leave you with an orphaned PWA site and will leave you scratching your head.  This also implies that PWA site collections cannot be backed up and restored by conventional SharePoint Site Collection Backups.
  3. If you try to convert Claims back to Classic mode (which is not supported), you will likely just break your PWA instance.

There is no really clear cut way to recover from an orphaned Site Collection, and it becomes a real pain as you cannot retract the PWA Service Application until you fix the orphaned Site Collection.

The short verison is it can be done with PowerShell with the following script :

$psi = get-spserviceapplication | where {$_.TypeName -like “*Project*”}
$a = $psi.Sitecollection | where {$_.SiteID -eq “0ce62ac4-d733-483f-b60b-ea7e75b104d4”}
$a
$a.Delete()
$a = $psi.Sitecollection | where {$_.SiteID -eq “0ce62ac4-d733-483f-b60b-ea7e75b104d4”}
$a

You will then be able to recreate or remove the Service Application, and just get on with Project life!