Speaking at SharePoint Saturday Charlotte 2014

I am speaking at the Charlotte SharePoint Saturday 2014 event this Saturday.  Below is my abstract and slide deck if you are interested.  If you are a reader of my blog and are going to the event, please stop by and say hello.

Session Title:  Unwrapping the black box: Advanced SharePoint troubleshooting and forensics

Session Topic:  SharePoint can often feel like a black box, and with little to no knowledge of internal workings, troubleshooting can be daunting. In this session, I remind you that SharePoint is nothing more than ASP.NET Web Forms and apply some of the same troubleshooting techniques to get you out of the dark. I will also delve into some SharePoint specific tools and demonstrate actual errors and troubleshooting where the resolution requires reading Microsoft SharePoint code.

Tools/Techniques

  • Internet Explorer F12 Developer Tools
  • Fiddler2
  • Developer Dashboard
  • ULS Viewer
  • SharePoint Manager
  • Reflector/ILSpy
  • SQL Profiler

Click here for the presentation.

SharePoint 2013 conflicts with custom site definition

I was updating one of our custom Site Definitions from SharePoint 2010 to SharePoint 2013 recently and everything was going good until I tried to create a site from the updated definition.  I kept getting the error:

Microsoft.SharePoint.SPException: The template you have 
chosen is invalid or cannot be found.

Searching on the internet told me the most common cause of this error was a conflicting ID for the template.  I was pretty sure this couldn’t be the case since we followed the instructions here:  http://msdn.microsoft.com/en-us/library/office/ms454677(v=office.14).aspx which stated:

Change the ID attribute of the Template element to a 
value of 10000 or more. This ensures that your ID will 
not conflict with future site definitions produced by 
Microsoft. If there are other custom site definitions 
on your target farm, make sure that each one has a 
unique ID.

and we had given our template an ID of 10000.  I had previously updated another custom site definition of ours with an ID of 10001 without any issues.

So I decided to give a quick search in the SharePointRoot\template\1033\XML folder for anything that contains ID=”10000″.  Sure enough I found two site definitions, mine and a new one that comes with SharePoint 2013 called the Academic Library.

I found this article:  http://social.technet.microsoft.com/wiki/contents/articles/20149.sharepoint-2013-default-site-templates.aspx which discusses the new site definitions that come with SharePoint 2013.  You can see it listed there as:

ID Name Title
10000 DOCMARKETPLACESITE#0 Academic Library
The Academic Library template provides a rich view and consumption experience for published content and management. Authors populate metadata and apply rules at the time of publishing, such as description, licensing, and optional rights management.(IRM). Visitors of the site can search or browse published titles and add authorized selections to their collection to consume, subject to the rights and rules applied by the author. The site provides an IRM-capable document library, a publishing mechanism for authors to publish documents, detailed views for each document, a check-out mechanism, and related search capabilities.

So it would seem that if you followed the recommendations for SharePoint 2010 and used an ID of 10000 for your custom site definition, then when you try to go to SharePoint 2013, your site definition won’t work.

This is an issue because there is not a way to change the template ID of a site after it’s been created through the API.  Fortunately, I have found 2 ways to get around this.  One of them I haven’t fully run to ground and verified that it works but the concept seems valid and the other isn’t supported by Microsoft.

Option 1:

This option I got the idea from this blog:  http://iknowsharepoint2007.blogspot.com/2010/02/changing-sharepoint-site-definition.html.  The basic idea is you export your site without using compression, change some xml configuration files so they use your new ID, and then import it back into your SharePoint environment.  You might not even have to change any xml files since that post was for SP 2007.  If someone tries this method, please comment below, otherwise if I find time to give it a try, i’ll update with my findings here.

Option 2:

This involved editing data directly in the SharePoint content database.  This is unsupported by Microsoft but worked for me during my testing.  Go to the AllWebs table in the content database for the site in question.  You should be able to find your site listed by scanning the FullUrl column.  Once found, write a SQL update statement which updates the WebTemplate column to the new site definition ID.  This was an instant fix for me as I was able to immediately start the upgrade to SharePoint 2013 for that site collection.

It sucks that Microsoft told us they would never use Site Definitions ID of 10000 or more and then they go back on their word with SharePoint 2013.  Anyways, I hope this helps someone else out trying to complete their migration to SharePoint 2013.  If anyone finds a better way to fix the issue, please post in the comments below.  Thanks.

Warning: SetCookie changes implementation in SharePoint 2013

I was recently working on verifying some of my custom code worked in SharePoint 2013.  I had some older code where I needed to set cookies and use them to remember user preferences.  I was debugging my code and I noticed that all of my cookies were coming back either true or false instead of the value I put into them.  I had been using a SharePoint JavaScript method called SetCookie.  Below is the implementation that has existed in SharePoint for the previous 3 versions (2003, 2007, and 2010).

function SetCookie(name, value, path)
{
	document.cookie=name+"="+value+";path="+path;
}

But for some reason Microsoft decided to change the implementation of this method in SharePoint 2013 to the following:

function SetCookie(sName, value) {
    SetCookieEx(sName, value, false, window);
}
function SetCookieEx(sName, value, isGlobal, wnd) {
    var c = sName + (value ? "=true" : "=false");
    var p = isGlobal ? ";path=/" : "";

    wnd.document.cookie = c + p;
}

Notice this new method tries to evaluate the value into a boolean and then forcefully sets the cookie to true or false.  So if you were storing anything other than boolean values in your cookies and used this method in previous versions of SharePoint, you will now need to update your code.  For this you have two options:

Option 1:  I found there is another method in SharePoint 2013 which still implements the SetCookie the same was as previous versions of SharePoint.

function SetMtgCookie(cookieName, value, path) {
    document.cookie = cookieName + "=" + value + ";path=" + path;

}

So you can easily do a search and replace for SetCookie to be replaced with SetMtgCookie and you’ll be good to go.

Option 2:  This is the option I opted for.  I decided that as tempting as doing a quick search and replace like I suggested in option 1 sounded, I wanted to remove my dependency on SharePoint’s implementation in case it changes again in the future.  Since the older SetCookie is only one line, I just replaced my method call to that line:

document.cookie=name+"="+value+";path="+path;

It was a pretty simple change, only slightly more time taken than option 1 and I removed a dependency.

Anyway, I hope this helps someone else out when troubleshooting code migration to SharePoint 2013.

Repopulating the Newsfeed Cache after a Server Restart

In SharePoint 2013, the Newsfeed relies on data cached in the distributed cache service which behind the scenes is using the appfabric cluster service. Newsfeed data is lost when you restart a server in your farm running this service without doing a graceful shutdown (http://technet.microsoft.com/en-us/library/jj219613.aspx#graceful).

Stop-SPDistributedCacheServiceInstance -Graceful
Remove-SPDistributedCacheServiceInstance

Sometimes you have to restart all servers in the farm and then your newsfeed will be empty.  There is a timer job that runs every 5 minutes called “Feed Cache Repopulation Job” which according to this website http://technet.microsoft.com/en-us/library/jj219560.aspx is supposed to autopopulate the newsfeed cache from the content stored in SharePoint.  Our SharePoint 2013 farm is on the March 2013 PU and this job did not seem to be repopulating the cache.

The article seemed to imply you could run some powershell scripts as well to accomplish the same thing.  I tried these:

Update-SPRepopulateMicroblogLMTCache
Update-SPRepopulateMicroblogFeedCache

The parameter for the first one was easy, just pass in your UPA proxy.  The second one also needed this proxy but it could also include an account name or a site url (http://technet.microsoft.com/en-us/library/jj219749.aspx).  The wording states that when using the account name use the “user account name for the user profile service application”.  I took this to mean the UPA service account.  I tried that and even after waiting several hours, there still wasn’t any repopulation.  So I tried the site url option passing in the mysite host url.  Still nothing.

I finally figured out after using reflector on the source code that the account name it was expecting was an account of a user to repopulate THAT user’s information.  I updated my script to the code below to run the Update-SPRepopulateMicroblogFeedCache for EACH user in the UPA and my newfeed cache started coming back to life!

$proxy  = Get-SPServiceApplicationProxy | ? {$_.Name -eq "MySite User Profile Service"}
Update-SPRepopulateMicroblogLMTCache -ProfileServiceApplicationProxy $proxy

[System.Reflection.Assembly]::LoadWithPartialName("Microsoft.Office.Server")
[System.Reflection.Assembly]::LoadWithPartialName("Microsoft.Office.Server.UserProfiles")

$url = "https://mysite.company.com"
$contextWeb = New-Object Microsoft.SharePoint.SPSite($url);
$ServerContext = [Microsoft.Office.Server.ServerContext]::GetContext($contextWeb);

$UserProfileManager = New-Object Microsoft.Office.Server.UserProfiles.UserProfileManager($ServerContext);

$Profiles = $UserProfileManager.GetEnumerator();

foreach ($oUser in $Profiles ) {
	if ($oUser.item("SPS-PersonalSiteCapabilities").Value -eq 14 ){
		$personalurl = $url + $oUser.item("personalspace").Value
		Write-Host $oUser.item("AccountName").Value
		Update-SPRepopulateMicroblogFeedCache -ProfileServiceApplicationProxy $proxy -accountname $oUser.item("AccountName").Value 
		#-siteurl $personalurl
	}
}

$contextWeb.Dispose()

The first time through I got a couple of errors so I added the if statement to check for the personalsitecapabilities being equal to 14.  After that I got less errors but there still were a few.  That’s when I tried going the site url route.  I was thinking if I send in the url of a user’s personal site, that it might work better.  I didn’t get any errors but it also didn’t repopulate the newsfeed for the users.  Oh well…

I now believe that the siteurl parameter is to repopulate the newsfeed cache for any sites that have the newsfeed on the homepage like the new SP 2013 team site template.  I know our environment doesn’t have any of these so I skipped this part.  I was thinking at some point I will need to figure this out though.  Hopefully it won’t involve looping through all sites in my farm but my gut says it will.  If someone else has figured out a good solution, please post the powershell code in the comments.  Thanks.

Update 3/29/2014:  

This issue has been resolved in Service Pack 1 (SP1).

Getting Active Directory UserId from Windows Claim in SharePoint 2013

We’ve always used NTLM for our SharePoint authentication but in SharePoint 2013, claims is the preferred authentication method.  Fortunately, SharePoint 2013 ships with something called Windows Claims.  This seems to work the same as the NTLM auth from before but that windows auth is converted into a claim that SharePoint can use.

This change means that your userid would look something like this:

i:0#.w|contoso\chris

instead of this:

contoso\chris

Sometimes when calling other services, you need the windows userid and not the claim userid.  So for these instances, I’ve created a few helper methods.

//Regex needs more testing
public const string CLAIMS_REGEX = @"(?<IdentityClaim>[ic])?:?0(?<ClaimType>[#\.5\!\+\-%?\\])(?<ClaimValueType>[\.\+])(?<AuthMode>[wstmrfc])(\|(?<OriginalIssuer>[^\|]*))?(\|(?<ClaimValue>.*))";
 
public static string GetAdUserIdForClaim(string login)
{
    string userName = login;
 
    foreach (Match m in Regex.Matches(login, CLAIMS_REGEX, RegexOptions.IgnoreCase))
	{
		try
		{
			if (m.Groups["AuthMode"].Captures[0].Value.ToLower() == "w")
			{
				userName = m.Groups["ClaimValue"].Captures[0].Value;
			}
		}
		catch { }
	}
    return userName;
}
 
public static string GetClaimForAdUserId(string login)
{
    string userName = login;
    SPClaimProviderManager mgr = SPClaimProviderManager.Local;
    if (mgr == null) return userName;
 
    SPClaim claim = new SPClaim(SPClaimTypes.UserLogonName, login, "http://www.w3.org/2001/XMLSchema#string", SPOriginalIssuers.Format(SPOriginalIssuerType.Windows));
    userName = mgr.EncodeClaim(claim);
 
    return userName;
}
 
public static bool IsLoginClaims(string login)
{
    Regex re = new Regex(CLAIMS_REGEX, RegexOptions.IgnoreCase);
    return re.IsMatch(login);
}

First I made a regular expression to identify the different pieces of a claim (see http://social.technet.microsoft.com/wiki/contents/articles/13921.sharepoint-2013-and-sharepoint-2010-claims-encoding.aspx).  This allows me to effectively parse the claim for the windows login name (see GetAdUserIdForClaim).  This also allows me to validate whether a string is a claim or not (see IsLoginClaims).