Wictor Wilen

As usual a new version of a product has new requirements of all different kinds; especially when it comes to resource usage. With SharePoint 2013 there is no difference. The Hardware and Software requirements for SharePoint 2013 Preview is published and I thought I should walk through the new and updated requirements and compare them with SharePoint 2010. And also talk about some other key changes that you need to be aware of when planning your SharePoint 2013 installations.

Well, by know everybody living in the SharePoint world are sitting with their best tin foil hats on and installing, configuring and fiddling with SharePoint 2013 Preview, which was announced today by mister Steve. I’ve been fortunate to be a part of the (debated) closed beta for some time and have been trying out the new version of our favorite product. You probably will be overwhelmed with blog posts over the next couple of months, up until the SharePoint Conference 2012, and continuing after that. And I aim to be a part of the flooding (at least partly)…starting with a topic that I think is profoundly important - Authentication.

I’ve seen it asked numerous times on forums and I’ve been asked over and over how to interpret the encoded claims - so here it is: a post which will show you all the secrets behind how claims are encoded in SharePoint 2010. Updates: - 2012-03-09 Added Forms Authentication info. - 2012-03-11 Updated with information about how the claim type character is generated for non-defined claims Background If you have been using previous versions of SharePoint 2007, been working with .NET or just Windows you should be familiar with that (NETBIOS) user names are formatted DOMAIN\user (or provider:username for FBA in SharePoint). When SharePoint 2010 introduced the claims based authentication model (CBA) these formats was not sufficient for all the different options needed. Therefore a new string format was invented to handle the different claims. The format might at first glance look a bit weird…

A couple of months back, when the weather was grey and it was cold (well, it still is here in Sweden, glad I did a tour to the Riviera last week), I wrote a post about how Claims encoding works in SharePoint 2010, simply called “How Claims encoding works in SharePoint 2010”. In that post I discussed how SharePoint encoded Claims from relatively long descriptive claims, containing URN’s, to a smarter and shorter format - smaller to store, faster to compare format etc. While there are tons of defined claim types only a selected few are “pre-encoded” in SharePoint. Here are a few examples:

Building the metadata structure in the Term Store Manager in SharePoint 2010 is not the most convenient way. I prefer working with the metadata structure and terms in an Excel document so that I can discuss the structure with colleagues and clients before implementing it. The Term Store Manager allows you to import a comma separated text file containing a Term Set. By default the Excel 2010 Save as CSV does not save in the correct format and for that I have made a Excel 2010 macro enabled template which produces the correct format.

A couple of days ago I started the migration of my blog to the new and shiny Windows Azure Web Sites (AWS - I don’t think that acronym is a co-incidence) and the Orchard CMS platform. The whole reason behind doing this migration is that I felt the need for a more modern (and stable) platform than the one I’ve built from scratch, years ago, and of course that I want to fiddle with some new toys. So, here is a short story on how I did the migration.

The Developer Dashboard in SharePoint 2010 can be configured using STSADM commands, PowerShell or some coding. To easy turn the Developer Dashboard on and off I have created a Farm scoped feature that allows you to configure the Developer Dashboard from Central Administration > General Application Settings > Development Settings. The Developer Dashboard contains more configuration options than just to turn it on or off. With this feature you can configure all of the options available for the dashboard:

YES! I’m finally alive with a new hosting provider - this time it’s Microsoft (who could have guessed that!). Thanks to the just released Azure Web Sites I have now moved my blog from my old custom blog implementation (that has been a fun project though), to running Orchard on Azure Web Sites using SQL Azure. This finalizes my cloud migrations - last year I moved e-mail and everything but the site to Office 365 and started with a hosted service for this site, but for running this little blog that was a bit to expensive (you’re not clicking the ads enough).

In this article I would like to give you some information about a very important timer job in SharePoint 2010 - the Application Addresses Refresh Job. If you do not understand what it is used for you might see some strange (to you) error messages when configuring SharePoint. Even if you’re familiar with it it might be a good idea to continue reading. Purpose of the Application Addresses Refresh Job The Application Addresses Refresh Job has one specific job to do - keep track of all available and online instances of all service application end-points. This means that whenever a proxy requests an endpoint for a service application it will ask the Topology Service (the Application Discovery and Load Balancer Service) for an endpoint. The Topology Service keeps a list of the endpoints that has been discovered by the Application Addresses Refresh Job and passes on one of these endpoints to the proxy, using the load balancing algorithm, which uses that endpoint to talk to the service application. So far so good…