Wictor Wilén

It’s been almost a week since the International SharePoint Conference ended, the first of its kind – and what a conference it was!

I was honored to be part of the developer track, together with top-notch speakers and developers such as Andrew Connell, Ben Robb, Eric Schupps, Matthew McDermott, Mirjam van Olst, Paul Schaeflein, Todd Carter and Waldek Mastykarz. We’ve been working together on this “project” for a couple of months having weekly calls trying to build a solution that we would use for the developer track. I really think that we did a good job and that we covered a lot of the important pieces in a SharePoint project – that normally isn’t covered on conferences. And I do hope that you who attended it, enjoyed the track and what we tried to show you.

Everything that we built and presented is available for download. We’ve created a CodePlex project where we have uploaded the functional specs, all the session demos and the final solutions demoed. Go grab the stuff here: http://spkbase.codeplex.com. And if you have any comments or questions – use the CodePlex discussion features and let the discussion start.

Waldek and I started the dev track by building a couple of Visual Studio Extensions. After some initial problems with the Visual Studio Gallery site we finally got them published. Just search for “ISC” in the Extension Manager. And if you wait just a couple of more days – all this will be integrated into CKS:Dev.

Next year, our amazing host Steve Smith, will host the SharePoint Evolution Conference 2013. I would not miss it for the world!

It's Aprils fools day and together with a lot of other MVP's around the world we're checking our junk mail folder for the e-mail that says that we have been renewed. I just got mine (actually not in the junk for the first time). This was my second renewal and I have now been awarded MVP for three consecutive years (2010, 2011).

Thanks to everyone, colleagues, friends and Connecta, who have supported me the last year. Looking forward to another 12 months of really exciting SharePoint work and happenings.

The Microsoft MVP program is an award (not a certification) given to community leaders around the world, for their contributions to the community for the last 12 months. The MVP award is valid for one year and each awardee has to continue to contribute to the community to be renewed.

Do you want to know more about the MVP program, then head on over to the MVP site.

In less than a month the greatest SharePoint conference on this side of the pond will take place in London - the International SharePoint Conference (ISC). The ISC is the new name for the conference held in London and previously called Best Practices Conference and Evolutions Conference. This will actually be my first year at the conference, but I always wanted to go there - and now I'm one of the speakers in the fantastic line up!

This conference will not be just an ordinary conference - instead of having the traditional one hour demo sessions we will over the course of three days go from a functional specification to a deployable solution. The sessions will vary in length from less than one hour to a couple of hours long. There will be two parallel tracks like this - one focused on development topics and one focused on IT-Pro stuff.

I will together with some fantastic SharePoint MVP colleagues and friends participate in a couple of sessions ranging from Visual Studio extensibility, to BCS and Managed Metadata thingies. It will be a blast presenting and I do think that the audience will enjoy this show. So, if you haven't already booked your tickers - now is the time!

Se you there!

Last Friday I got the fantastic message that I had successfully passed the Microsoft Certified Architect - SharePoint 2010 (MCA) certification, something I'm really proud of - but something most of the community never ever heard of. During this weekend I've been pinged and messaged by a lots of people asking the question "What is a Microsoft Certified Architect?". In this post I intend to answer it as thorough as possible, including my own personal aspects of it.

First of all let's answer the most common question - "How does the Microsoft Certified Architect relates to the Microsoft Certified Master exam?".

I might agree that Master sounds way cooler than Architect, but that isn't the real story. The Master certification (MCM) is the most highly technical exam you could ever get in the Microsoft world. The term technical is important here. During the MCM rotation and the exam you explore and learn all the scary and exciting internals and externals of SharePoint (or the other MCM:able products/technologies) from a technical perspective. You will learn from the best teachers and SME's and you will be in a class together with some really awesome and skilled persons. The MCM is both a course (3 weeks on site, or 1 week on site and 10 weeks off-site), a written exam and a qualification lab. Read more about my MCM experience in one of my older posts. To even apply for the MCA you need to be an MCM on the specific product your applying for and on the current version. This means that Microsoft already tested and verified your technical skills! So one could actually say that the MCA is like the Microsoft Certified Grandmaster...

"What is the MCA then?".

So, let's take a look at the Architect certification (MCA). The MCA takes the certification to another level, and focus on the business side of SharePoint (or the other MCA eligible products; SharePoint, Exchange, SQL and AD). The MCA is not a course, it is not something you sit in class and learn for a couple of weeks, it is not something you can study for - it is something you learn over the course of several years of experience with the products, in real business cases together with one or more customers.

"How do I apply for the MCA?".

When applying for the MCA you must supply a portfolio which includes details about real customer gigs, your CV and other documentation to prove that you are in the business for real. Once the program manager thinks you have "what it takes" and that you proven that, you will be scheduled for a board appearance. You need to work on your documents and prepare for the board presentation. This is not something you should do with your left hand - you need to put in some real effort here to produce a good set of documents and a good presentation. It is up to you to prove that you have "what it takes".

"So, how does the MCA board appearance work?".

The board appearance is the certification. You will spend almost a day together with the MCA board (consisting of other MCA's or specific SME's). You will do a presentation, a case study and you will have several intense Q&A sessions. Enough to make you choke. The board will then grade you on six different competencies (full list and details on the official site). Once you are done - all you can do is wait for the pass/no-pass e-mail. This is an exhaustive day for which you need to prepare. But as I said earlier - it all comes down to the actual experience you have in the industry and how used you are to being in these situations with clients. You can't study for the Q&A sessions.

"What's the value of an MCA certification?".

The MCA, and the MCM for that matter, costs a lot of money. So is it worth it? In my opinion definitely. It's really hard to say what the exact payback is. We're currently early in the SharePoint MCA process with quite few certified MCA's and only time will tell. I can directly say that I learnt a lot while preparing for the board appearance - with a lot of time reflecting on past projects. Also the actual board appearance was great in that way that the board tested me; both on my strong areas and weak ones - and now I know what parts I might need to step up on. Studies done on the MCM community shows benefits such as a higher hourly rate, easier recruitment, better and safer deliveries. So the MCM/MCA are really a quality stamp, with MCM focused on the technical aspects and MCA on understanding and implementing business requirements.

"Why did I do this?".

This is the question my wife asks me! Well, first of all I always try to be better in what I'm doing. And going down the MCA route surely did this. I now know what I know and know what I don't know and know what I want to know... Also I think it is great for my company, Connecta, to have this certification - it will definitely be a USP in attracting clients and co-workers. A big thank you to Connecta and my managers who believed in me enough to send me on both the MCM and MCA journey! In the end I know that both me personally, my company and my co-workers will benefit from this.

"I want to learn more about the MCA?".

So, now I've been ranting about the MCA (from my perspective) and there are probably tons of questions that remains unanswered. Use the following links to learn more.

• Microsoft Certified Architect program
• Microsoft Certified Master program
• Regularly held online events with the MCM/MCA program managers. If you're just a little bit interested make sure to attend one of these held by the awesome program mangers for the MCM/MCA programs and have your chance to ask your questions
• Announcing the Microsoft Certified Architect: SharePoint Server 2010 - MCA/MCM/MVP Spence Harbar writes about the SharePoint MCA program

That's it. I hope you have a far better understanding of what a Microsoft Certified Architect is.

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...

How it works?

The claim encoding in SharePoint 2010 is an efficient and compact way to represent a claim type and claim value, compared to writing out all the qualified names for the claim types and values. I will illustrate how the claim are encoded in SharePoint 2010 focused on user names, but this claim encoding method could be used for basically any claim. Let's start with an illustrative drawing of the format and then walk through a couple of samples.

The format

The format is actually well defined in the SharePoint Protocol Specifications in the [MS-SPSTWS] document, read it if you want a dry and boring explanation, or continue to read this post...

The image below shows how claims are encoded in SharePoint 2010, click on the image for a larger view of it.

Let's start from the beginning. The first character must be an I for an identity claim, otherwise it has to be c. Note that the casing is important here. The second character must be a : and the third a 0. The third character is reserved for future use.

It's in the fourth character the interesting part starts. The fourth character tells us what type of claim it is and the fifth what type of value. There are several possible claim types. The most common are; user logon name (#), e-mail (5), role (-), group SID (+) and farm ID (%). For the claim value type a string is normally used and that is represented by a . character. The sixth character in the sequence represents the original issuer and depending on the issuer the format following the sixth character varies. For Windows and Local STS the seventh character is a pipe character (|) followed by the claim value. The rest of the original issuers have two values separated by pipe characters, the name of the original issuers and then the claim value. Easy huh?

Note: the f (Forms AuthN) as trusted issuer is not documented in the protocol specs, and this is what SharePoint uses when dealing with membership providers (instead of m and r). For more info see SPOriginalIssuerType.

For full reference of claim types and claim value types, look into the [MS-SPSTWS} documentation.

(Added 2012-02-13) If you are creating custom claim providers or using a trusted provider (as original issuer), you will see that you get some "undocumented" values in the Claim Type (4th) position (that is they are not documented in the protocol specs). The most common character to see here is ǵ (0x01F5). If the claim encoding mechanism in SharePoint cannot find a claim type it automatically creates a claim type encoding for that claim. It will always start with the value of 500 increment that value with 1 which results in 501. 501 is in hex 01F5 which represents that character. It will continue to increase the value for each new (and to SharePoint not already defined) claim type. The important thing here to remember is that these claim types and their encoding is not the same cross farms, it all depends on in which order the new claim types are added/used. (All this is stored in a persisted object in the configuration database)

Some notes: the total length must not exceed 255 characters and you need to HTML encode characters such as %, :, ; and | in the claim values.

Some samples

If this wasn't clear enough, let's look at a few samples.

Standard Windows claim
Another common claim. This time it's not an identity claim but an identity provider claim, and this is how NT AUTHORITY\Authenticated Users is represented.
This is how a Windows Security Group is represented as a claim. The value represents the SID of the group.
If we're using federated authentication (as in the Azure AuthN series I 've written) we can see claims like this. It's an e-mail claim from a trusted issuer called Azure.
Here's how a claim can be encoded if we're having a role called facebook in the trusted issuer with the name Azure.
This final example shows how the encoded claim for the Local Farm looks like. It's a Farm ID claim from the system Claim Provider and the claim value is the ID of the farm.
This is how a forms authenticated user claim looks like.

Summary

I hope this little post showed you all the magic behind the claims encoding in SharePoint. It's quite logical...yea really.

The best free SharePoint magazine published online, the DIWUG SharePoint e-Magazine, did yesterday release their sixth edition. As usual this is a great edition with a mix of articles for every aspects of the SharePoint universe. The articles are written by SharePoint community members and the magazine is compiled and managed by Mirjam van Olst and Marianne van Wanrooij.

This edition contains articles ranging from hard core Service Application federation, to SharePoint Online and Azure development to articles on how to engage your users and project teams in SharePoint. As usual - something you just must read!

In this edition I've participated with one article about Dynamic Ribbon customizations with Page Components. It's quite lengthy (sorry about that) and contains a lot of code, and quite a few tricks that makes Ribbon customizations easy(ier). My idea behind the article was to show a real world implementation of a Ribbon customization, instead of any Hello World stuff. This customization actually improves the OOB user interface (IMO) and allows your users to work with Workflows much easier. You can basically take the code from the article and install it in your farms.

So here's where to get it:

• Full fidelity high res PDF edition
• e-Reader PDF edition

Another post you think! Does this guy have a life? Well, actually I do. But once you get me started , I'm hard to stop...

This sixth post in the Visual guide to Azure Access Controls Services authentication with SharePoint 2010 is going to show you how to leverage some of the features that Azure ACS provides you with when using Facebook as Identity Provider. I'm going to show you how to use the Facebook Graph API and retrieve information about the user (and possible his/hers friends) - this is of interest if you're going to build a community or something similar on top of SharePoint 2010. For instance we can use the information from Facebook and push into the SharePoint 2010 User Profile service once the user has signed up..

Sit back and relax, while I show you how to do this...

Add the Facebook AccessToken claim

First of all I assume that you have configured Facebook as one of the Identity Providers as detailed in part 3, secondly we're going to use the approach with custom claims that we learnt in part 5. When you configured Facebook as an IP for your Relying Party Application and auto-generated Rules for the IP, then ACS automatically created some output claims for us. Especially the "http://www.facebook.com/claims/AccessToken" is of interest in this case.

This is a claim contains the access token required to do authenticated calls to the Facebook Graph API. And we will add this claim as in incoming claim to the Trusted Identity Provider in SharePoint 2010.

There is also another output claim that you should be aware of if building production code (which I'm not doing here) and that is the "http://schemas.xmlsoap.org/ws/2008/06/identity/claims/expiration" claim that contains the expiration time for the access token. You might need to check that so the user has to re-authenticate to get a new access token.

Ok, since Azure ACS has everything already in place for us, we only need to fix the Trusted Identity Provider in SharePoint. Just as in part 5 we'll add the claim using this snippet of PowerShell.

$map = New-SPClaimTypeMapping
    -IncomingClaimType "http://www.facebook.com/claims/AccessToken"
    -IncomingClaimTypeDisplayName "AccessToken"
    -SameAsIncoming
$tip = Get-SPTrustedIdentityTokenIssuer "Visual AuthN ACS"
$tip.ClaimTypes.Add("http://www.facebook.com/claims/AccessToken")
Add-SPClaimTypeMapping -Identity $map -TrustedIdentityTokenIssuer $tip
$tip.Update()

Once this is done, just log out and in again using a Facebook account and we should see the new claim.

Now, we are all set to use this Access Token in some custom code. I know you've been waiting for some code in this series - it's far too much clickety-click and PowerShelling...

Use the Facebook Graph API in a Web Part

To show you how to use the Facebook Graph API I'm building a simple Visual Web Part that is going to write the name of the Facebook user, the favorite quotes and show the profile picture. I'm not going into details on the Graph API here and there are a lot of .NET implementations/libraries that you can use, but for this demo this simple method is sufficient:

private Hashtable callGraphApi(Uri uri, string accessToken) {
    UriBuilder builder = new UriBuilder(uri);
    if (!string.IsNullOrEmpty(builder.Query)) {
        builder.Query += "&";
    }
    builder.Query += "access_token=" + accessToken;
    JavaScriptSerializer jsSerializer = new JavaScriptSerializer();

    using (WebClient client = new WebClient()) {
        string data = client.DownloadString(builder.ToString());
        return jsSerializer.Deserialize(data);
    }
}

This method takes a Graph API Url and the access token and returns a HashTable of the data. The implementation of the Visual Web Part is very simple, the Page_Load method is modified as follows:

protected void Page_Load(object sender, EventArgs e) {
    try {
        IClaimsPrincipal principal = Page.User as IClaimsPrincipal;
        IClaimsIdentity identity = principal.Identity as IClaimsIdentity;
        var accessToken = (from claim in identity.Claims
                            where claim.ClaimType == "http://www.facebook.com/claims/AccessToken"
                            select (string)claim.Value).FirstOrDefault();

        Hashtable me = callGraphApi(new Uri("https://graph.facebook.com/me"), accessToken);
        name.Text = me["name"].ToString();
        quote.Text = me["quotes"].ToString();
        image.ImageUrl = String.Format("http://graph.facebook.com/{0}/picture", me["id"].ToString());
                
    }
    catch (Exception ex) {
        error.Text = ex.ToString();
    }     
}

First of all, I'm using a Linq snippet to get the access token and then I'll do a call to the Graph API and retrieves data for the current user. The info is then just inserted into a few Label controls and an Image control. If you log in using a Facebook account and watch this Web Part it should look something like this:

What! Why do I get this error! Wictor showed me everything!? Don't be such a cry baby, remember that SharePoint keeps it's own certificate store! And it does only trust certificates in that specific internal SharePoint store. So we need to grab the Facebook.com certificate and add that to SharePoint. To get the certificate I use Firefox (IE9 does not allow me to save the certificate!) and browse to https://graph.facebook.com/me. You'll get an error but ignore that and click on the Facebook logo in front of the address, and then click on more information.

When the dialog appears, click on View Certificate and then finally on the Details tab use the Export button and save the certificate as a X.509 Certificate (PEM) file.

Copy this file to one of your SharePoint 2010 boxes and run the following PowerShell:

$cert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2("c:\-.facebook.crt")
New-SPTrustedRootAuthority -Name "Facebook" -Certificate $cert

This will add the Facebook certificate to the SharePoint Certificate store and SharePoint will now trust Facebook! So reload the page with the Facebook Web Part again and voila...

Imagine what you can do with this. For instance on the first time log in - set the correct user name, upload the user profile picture etc etc. Now we're talking!

More stuff...

If you need access to more information in the Graph API, such as statuses, friends etc you need to configure the permissions for the Facebook Identity Provider in Azure ACS. For instance if I would like to read out the status updates for a user I need to add the user_status permission to the Facebook Identity Provider in Azure ACS.

Then when the user re-authenticates it will be prompted by Facebook to allow these new permissions.

And now your application is allowed to read out status updates using the Graph API. You can find a list of all the available permissions here.

Tip: If you want to experiment with different Graph API Urls use the followin tool: http://developers.facebook.com/tools/explorer/?method=GET&path=me. You can copy and past your access token to the tool to see exactly what you can retrieve using that access token and your Facebook application permissions.

Summary

Now we've gone a long way from configuring Azure ACS and using simple Authentication using Google ID and Facebook to provide deeper integration with the external services. Good luck in building your own community sites!

This is the fifth post in the Visual guide to Azure Access Control Services authentication with SharePoint 2010 and this time it is time to augment some claims using the Azure ACS. We'll do this to prepare for the next exciting part. For this post I assume you have configured at least one Web Application to use Facebook login using Azure ACS - make sure that you've followed post 1 and post 3 and optionally post 4 thoroughly.

Why augment custom claims?

Sometimes you need more information from the users than just the e-mail and name. Perhaps you would like to get the phone number, age or other stuff. If you have that data in your identity provider you can augment that information (claim) to SharePoint. With Azure ACS you only have a specific set of data, unless you use a custom Identity Provider in Azure, such as ADFS. The default Identity Providers (Live ID, Google ID, Yahoo and Facebook) in Azure only has a limited set of claims that is sent to SharePoint.

Using Azure ACS we can augment brand new claims - using the Rules editor in the Azure ACS management UI. You can create new output claims from scratch or new output claims based on values from the other input claims. In this scenario we're going to create a completely custom claim called "Identity Source" which will identify from where the identity is coming (Facebook, Yahoo or Google). We will then be able to use this in SharePoint to target information.

If we log in to SharePoint using a Facebook account these are the claims that we get by default:

These claims are retrieved through a very simple Visual Web Part containing a DataGrid and the following code behind:

protected void Page_Load(object sender, EventArgs e) {
    IClaimsPrincipal principal = Page.User as IClaimsPrincipal;
    IClaimsIdentity identity = principal.Identity as IClaimsIdentity;
    var data = from claim in identity.Claims
        select new {
            Claim = claim.ClaimType,
            Value = claim.Value
        };
    GridView1.DataSource = data;
    GridView1.DataBind();
}

Adding a custom claim in Azure ACS

As usual we'll begin with the configuration in Azure. We would like to create a new claim with the following name http://visualauthn.accesscontrol.windows.net/IdentitySource. It will have the value Facebook when logging in using a Facebook account and the value Google when logging in with Google Id.

In Azure ACS go to Rule Groups and select the Rule Group that you use for your Relying Party Application. Click Add to create a new Rule. In the If section we choose Facebook as Input claim Issuer, and then for Input claim type select Any and leave Input claim value set to Any.

In the Then section enter our own Output claim type and use the name above. For Output claim value we enter Facebook, since that is the value we want SharePoint to receive for this claim. Finally always write a description on the rule - if you have many it can be a mess finding them otherwise. Once you're done click Save.

Repeat the procedure for the Google IP. Add a new Rule with Google as Input claim issuer and the Output claim value set to "Google" - the rest should be the same as above. The Rule Group should look like this after these two operations:

Configure the SharePoint Trusted Identity Provider

Now we need to configure the Trusted Identity Provider in SharePoint 2010 so that it accepts these incoming claims. And of course this is done in PowerShell. First we create a new claim mapping and then get a handle on our Trusted Identity Provider. After that we add our custom claim type to the trusted IP and finally add a claim mapping, before we persist the values.

$map = New-SPClaimTypeMapping
    -IncomingClaimType "http://visualauthn.accesscontrol.windows.net/IdentitySource"
    -IncomingClaimTypeDisplayName "Identity Source"
    -SameAsIncoming
$tip = Get-SPTrustedIdentityTokenIssuer "Visual AuthN ACS"
$tip.ClaimTypes.Add("http://visualauthn.accesscontrol.windows.net/IdentitySource")
Add-SPClaimTypeMapping -Identity $map -TrustedIdentityTokenIssuer $tip
$tip.Update()

That's it - we should be ready to test it now...

Validate the the claims

If we log out and in again (this is required to get the new set of claims) we should see that our new claim is there and with the correct value.

If you have configured a separate web application and a secondary trusted identity provider, shown in the previous article, you will also see this claim - without modifying the secondary trusted IP. Cool huh!

We can now use this claim to set permissions using the people picker:

Summary

I've now shown you how easy it is to augment claims using Azure ACS and to leverage them in SharePoint 2010. There are tons of cases where this is important and very useful. In the next post we'll add another claim for Facebook users - which will allow us to do some really cool stuff.

This post serves as an index for all the articles in the Visual guide to Azure Access Controls Services authentication with SharePoint 2010. 

This series is a set [not yet determined amount] of articles where I show you how to leverage the Azure Access Controls Services (ACS) in combination with SharePoint 2010 to make it easier for you to use identity providers such as Google ID, Windows Live ID, Facebook AuthN etc.

Posts

• Part 1 - basic setup
  This article guides you through the basic setup of ACS and SharePoint 2010, from creating the Azure ACS endpoints to configuring the identity providers and relying party to finalizing the setup in SharePoint 2010  and finally log in using Google ID credentials.
• Part 2 - common problems
  Even though if you follow all the instructions in part 1 you or more likely your colleague will run into problems. This article discusses the most common problems - and will hopefully be updated as time flies by.
• Part 3 - Facebook Authentication
  The third part shows how to enable Facebook Authentication for your Azure ACS namespace and log in using a Facebook account to SharePoint 2010.
• Part 4 - Multiple Web Applications
  This post will show you how to handle the case when you have multiple web applications and would like to use the same Azure ACS settings.
• Part 5 - Custom Claims
  In this post we'll take a look at how we can add custom claims through Azure ACS and leverage them in SharePoint.
• Part 6 - Facebook Integration
  In this post we'll use the features in Azure ACS to do deeper integration with the Facebook Graph API.
• Part 7 - Customize the login experience
• ...

Note: this is what is actually written and planned for now . Any planned posts might change over time...

Happy reading!

Back with another promised post in the Visual guide to Azure Access Controls Services authentication with SharePoint 2010. This time I'm going to show you how to work with multiple web applications. We're going to use the stuff we configured in part 1 (basic setup) and part 3 (Facebook setup), and hopefully we're avoiding the problems discussed in part 2 (common problems).

Scenario

In this article I would like to show you how to use Azure ACS and SharePoint 2010 when we have multiple Web Applications in SharePoint. The sample will assume the same web application as used in the previous posts, but now with a dedicated My Site Host Web Application (called http://my). If we just enable the same Trusted Identity Provider to the "My" Web Application, the user will be redirected to the Azure ACS log in page, but when he/she is redirected back it will redirect back to the other web application (called http://sp2010 in the previous posts), because that's the web application we configured in the Return URL in Azure ACS.

Since this is a "visual" guide we're only using the Azure ACS management web site to configure the ACS and the UI only supports one Return URL per Relying Party Application. If you're using the ACS management web services you can configure multiple return url's - but that's another story for someone else to write about.

So, we actually need to create a new Relying Party Application in ACS to handle a different Return URL, and with that also another Trusted Identity Provider in SharePoint.

Create a new Azure Relying Party

Let's start with Azure ACS. Log in to the Azure management portal and go to Relying Party Applications, then choose to add a new one. Give it a Name (must be unique), a new Realm (must also be unique within the ACS namespace) and finally the new Return URL for our new web application.

The next parts are pretty trivial, but important. Make sure you choose SAML 1.1 as token format, increase the Token Lifetime (to the same value as your other/original RP), then choose the same Identity Providers as for your other RP. Do NOT create a new Rule Group, make sure to select the same Rule Group as your original Relying Party. This is to make it easier for us to manage (especially for upcoming posts). Leave the rest as is and click Save.

The next thing to do is to configure the Token Signing certificate for this guy. Click on Certificates and Keys and choose to add a new Token Signing certificate. Choose the newly created Relying Party Application in the drop down and then choose to upload the SAME certificate that you used for your original RP - this is important, no other certificate will do!

Hit Save once you're done and we're done with configuring our new Relying Party Application for the new SharePoint Web Application.

Create a new SharePoint Trusted Identity Provider

In SharePoint we need to add a new Trusted Identity Provider that uses the new Realm that was specified in the Relying Party Application. The procedure is basically the same as we did for our first Trusted IP, but with a subtle but important difference - we will not set the ImportTrustCertificate parameter in the cmdlet. We have already imported the certificate once, to the original trusted IP. Adding the same certificate to a new trusted IP will throw an exception. But this is good, you will shortly learn that. So use the following PowerShell to create the new trusted identity provider.

$realm = "uri:visualauthn-my"
$signinurl = "https://visualauthn.accesscontrol.windows.net/v2/wsfederation”
$map1 = New-SPClaimTypeMapping
    "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress"
    -IncomingClaimTypeDisplayName "Email"
    –SameAsIncoming
New-SPTrustedIdentityTokenIssuer
    -Name "Visual AuthN ACS - MY"
    -Description "ACS rocks!"
    -Realm $realm
    -ClaimsMappings $map1
    -SignInUrl $signinurl
    -IdentifierClaim $map1.InputClaimType


The important things here to notice is that we're using the new Realm, the same sign in URL, gives the trusted ip a new Name and do not choose to use the ImportTrustCertificate parameter.

Now we're ready to connect the web application to the new trusted identity provider.

Configure the secondary Web Application

In Central Administration go to Web Applications Management, choose the new Web Application (in this case http://my ) and select the Authentication Providers button in the Ribbon. Choose the appropriate zone in the dialog and then scroll down to Trusted Identity Providers and select the newly created one.

Click Save when done and you're ready to test it.

Test it

Now when you browse to the secondary web application you can log in using our new Azure ACS Relying Party Application and you will be redirected to the correct web application (and not back to the first one, which is the case if we used the original trusted IP for the secondary web application).

Now to the really interesting stuff! If you choose My Settings in both web applications you will notice that the account name is exactly the same.

This is good! This account will now be same throughout your web applications and you can actually set up a dedicated My Site Web App and have all Notes and Tags from the other web apps.

Even though we created a new trusted identity provider, the account name is exactly the same! Even the issuer is the same in this identity. The reason behind this is that since we did not add any signing certificate to the secondary trusted IP (and we don't want to). When first trying to sign in SharePoint will redirect to the sign in URL (remember we have the same for both trusted IP's) using the Realm for the web application. We're using the same token signing certificate for both the ACS RP's (and the same rule group, which means that we get the same set of claims back) and when SharePoint retrieves the incoming request from Azure ACS it will locate the trusted identity provider using that token signing certificate. And it will find our original trusted identity provider and use it's settings (including claims mappings - which we'll also see in subsequent posts). Smart huh!

The image below just shows our trusted IP's and their certificates.

Summary

In this case we're adding a new Relying Party Application and a new Trusted Identity Provider in SharePoint just to get a new Return URL. The Trusted IP is there to send the correct Realm to Azure ACS so that it sends back the request to the correct Return URL. And this is only what the new trusted IP is for - in follow up posts to this one we'll modify the trusted IP and we only need to modify the original one to get effects on both web applications.

SharePoint is smarter than you think!

Welcome back to a third post in the Visual Guide to Azure Access Control Services authentication with SharePoint 2010. In the first part I showed you how to do the basic configuration of Azure ACS and SharePoint 2010 and log in using a Google Id. The second part discussed the most common problems I've seen so far. In this post we'll continue extending the ACS Relying Party to support another Identity Provider - namely Facebook! Depending on what type of site/community you're trying to build with your SharePoint 2010 site it might be of interest to use Facebook login (they have like a gazillion of users or something). The Facebook AuthN parts are a bit different than the others OOB IP's in Azure ACS - but not complicated at all, so let's get started...

Create a Facebook application

The first thing we need to do is to actually create a Facebook application. This is required to allow Azure ACS to convert the Facebook OAuth to outgoing claims, using the Facebook Graph API. And to do this you need a Facebook developer account. You do this by going to http://developers.facebook.com/. Once you have your account you just click Apps in the upper right.

This will take you to all your apps, if you're new you don't have any...but you get the point. Next, click the Create New App button. Give the app a display name and a namespace (as always namespaces must be unique - the UI helps you with that). Agree to the terms (you read those, right!?) and click Continue.

You will be asked to fill in the security check - do that and finalize you app creation.

Now we need to do some configuring, but just one simple thing. We need to tell the app how we integrate with Facebook - we'll do that by checking the Website mark and then entering the URL to Azure ACS - it should be https://[your ACS namespace].accesscontrol.windows.net (you can also find the URL under Application Integration in the ACS portal). Then save the changes. It says this will take a couple of minutes, but we have some more configuring to do so we'll be okay.

Keep this page open, you'll need the App ID and App Secret in the next step, when we configure Azure ACS.

Configure Azure Access Control Services

I assume that you have already created your Azure ACS Relying Party, but if you have not revert to Part 1 of this series. Choose to add a new Identity Provider and select Facebook application. Click Next when done.

Now you need the App ID and App Secret from the Facebook application, input those values.

Make sure that the checkbox is checked next to your Relying Party under Used By and then click Save.

Next step is to create Rules for this new IP. Go to the Rule Group that your RP is using and click on Generate. Azure ACS will by default mark those IP's that does not have any rules, so just click the Generate button to create the default rules.

Once the rules are created, you can verify that an output claim is created for the Facebook IP using the emailaddress claim.

Also check your Relying Party and make sure that it has the correct set of IP's configured.

That's it with the Azure ACS configuring. Now all that is left to do is test it in SharePoint!

Login using your Facebook account in SharePoint 2010

Before logging in you need to give access to your Facebook account in SharePoint. You'll use the e-mail address of the Facebook account - just add it to the Members Group of the site.

Then log out and sign in as a new user and choose to use Azure ACS login. You will now, as usual, be redirected to the ACS Sign in screen and you should see Facebook listed as an IP there. You might have to refresh your browser using Ctrl-F5, since the page might be cached.

When you click the Facebook button you will be redirected to Facebook which will prompt you for your credentials. Log in using the account you just gave permissions.

The first time you will be requested to approve that Facebook sends information to your App, just click Go to App and you'll be authenticated in ACS.

And voila! You have now logged in to SharePoint 2010 using your Facebook account.

Summary

Making SharePoint take advantage of Azure ACS and the Facebook integration you can very easily create a log in experience that users are quite used to by now. As I have shown you it just takes a couple of minutes.

I just can't stop writing on this topic, so I'll be back with some more awesomeness another day...

This is a the second part of the Visual guide to Azure Access Control Services authentication with SharePoint 2010. I hope you've read part 1 which showed you how to configure SharePoint 2010 to use Windows Azure Access Control Services, ACS, as the federated Identity Provider, IP. In this post I'll go through the most common errors that you might stumble upon (most likely due to the fact that you didn't follow part 1 thoroughly). These errors are also applicable to other providers such as ADFS.

Note: this post is written using Azure ACS as per February 2012 and with SharePoint 2010 Server with SP1 and December 2011 Cumulative Update.

So let's get started with a very annoying problem - Live ID...

Windows Live ID and the e-mail claim

The first error is not an error per see. You will see this one if you followed the instructions in the first part - but instead tried to use Windows Live ID when logging in. What you will see is the classic "An unexpected error occurred".

The key here is to take a look at the URL. You will see a query string parameter called errorCode which has the value TrustedMissingIdentityClaimSource.

So there is something missing! To understand what happened here we need to get back to the ACS management portal and take a look at the Rule Group that was created for our Relying Party Application. As you can see in the image below only one claim is augmented when using Windows Live ID - the nameidentifier. In part 1 we configured the identity claim (in the PowerShell script) and we configured it to use the e-mail as identity claim (http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress). If you read the last series on Live ID AuthN with SharePoint 2010 you might remember that you could not use the e-mail address of the Live ID user but instead had to use the UUID (basically a GUID that uniquely identified the user). Unfortunately (and this is a real bummer) this UUID (claim type http://schemas.xmlsoap.org/claims/UPN) is not available in Azure ACS, for Live ID. Instead the only claim we have access to is the nameidentifier - which is a unique identifier for the specific user on this ACS namespace.

If we add a new Rule in Azure ACS that uses the nameidentifier as input claim and outputs it as the emailaddress identifier claim. Then we at least have something unique for the user to work with.

When you now log in using a Live ID you will get an access denied message, which displays this unique nameidentifier. Copy the identifier and then log in using a Windows account (or the working Google account) and this identifier to the Members group (for instance).

Then log in again it will work, but...

Looks pretty bad! So you better leave Windows Live ID out of the discussion (until Microsoft fixes ACS to give us a decent claim to work with). Edit the Relying Party Application in ACS and remove Windows Live ID as Identity Provider and you will be a much happier person.

No Rules applied here!

One problem you might see when setting up the authentication using ACS is that you might be to trigger happy and fast when configuring and just forgets to add any Rules to your Relying Party. When you're trying to log in you will see an error message like this:

The error message is ACS50000: There was an error issuing a token, with two inner messages ACS60000 and ACS60001 where the last one gives us the clue in plain text: "No output claims were generated during rules processing". This is just because you have no rules applied to that Relying Party which converts the incoming claims from the IP's to outgoing claims. To fix it edit your Rule Group and just use the Generate to create your output claims:

This might happen if you're adding more Identity Providers to your Relying Party once you have configured it.

Note: make sure that you're doing it for the correct Rule Group - the one selected in the Relying Party.

Invalid identifier claim

Another error, not that common though, that might happen if you start fiddling with the claims is that you do not get any incoming identifier claim to SharePoint. When this error happens you will get the classic An unexpected error has occurred error page.

The actual error can be find either in the URL or in the trace logs - both explain exactly what has happened. In the URL the error code is written out as TrustedMissingIdentityClaimSource. Exactly the same as in the Windows Live ID dilemma above.

And in the trace logs you will find several entries (depending on your log level):

To fix this make sure that you have an output claim, from the ACS Relying Party, for each Identity Provider, that matches the exact claim that you specified when configuring the token issuer identity claim (using PowerShell). You can verify your identity claims by running the PowerShell snippet

Get-SPTrustedIdentityTokenIssuer | ft Name,  @{Label = "Id Claim"; `
Expression={$_.IdentityClaimTypeInformation.InputClaimType}} -autosize

Then check you ACS rules and that each IP has an output claim of that type (that is unique of course!).

Token lifetime

The most common problem with Azure ACS and SharePoint 2010 is that you successfully logs in and then either directly are redirected back to the log in page or you're logged in for a second and then as soon as you click something are requested to log in again. If you have enabled Verbose Trace Logging for Claims Authentication (which definitely is a good thing to do when troubleshooting claims stuff) you will also see this message in the ULS logs: "Token cache entry missing.".

This is most likely due to that you have misconfigured the Token Lifetime, or just let it have the standard value of 600. Most likely you did not read my previous post thoroughly enough!!!

The STS of SharePoint 2010 has a default lifetime of the logon token set to 10 minutes (600 seconds) and this is also the default value of the ACS RP token lifetime (600 seconds). If you with these default  values can actually log in you have a fast connection/machine, but any subsequent action in SharePoint will force you to re-authenticate. You have to configure the lifetime in ACS larger than the value in SharePoint (either by increasing the ACS token lifetime or lowering the SharePoint 2010 LogonTokenCacheExpirationWindow value of the  STS.

In my previous post I set the token lifetime to 700 seconds - this will then make your users log in every 100 seconds (700-600). If you set it to 610 seconds in ACS you will have to re-authenticate every 10 seconds. A recommendation is to bump it up to 3.600 seconds, so you don't annoy your users to much!

Not using correct SAML version

Another common error is that you get a Runtime Error (Yellow Screen of Death) directly after you have logged in using one of the IP's. The ULS logs does not show any useful information, you just see that a request is going to the /_trust/default.aspx page.

On the other hand, if you switch to the Windows Event Viewer you will notice an ASP.NET error, with event id 1309. And if you look closer at the details, the answer is there, once again under your fingertips.

The exception message says: "ID4014: A SecurityTokenHandler is not registered to read security token ('Assertion', 'urn:oasis:names:tc:SAML:2.0:assertion').". Once again you've misconfigured the ACS Relying Party - you must use SAML 1.1 to get this working (without setting up an intermediate ADFS server or similar).

Certificate problems 

Another issue that might throw the yellow screen of death on the /_trust/default.aspx page is when you have invalid or missing certificates. Again both the trace logs and Windows event logs shows us the error. In the Windows Event Logs you will see a SharePoint error with event id 8311. This error will say that it could not validate the certificate used to sign the incoming claims. The trace logs will show the exact same error, also with id 8311, in the Topology category.

Fix the error by making sure that you have added the same signing certificate to Azure ACS and as a trusted root authority. See part 1 of this series for more info.

Summary

As you can see it's all about configuration and make it right! I hope this post will help you with the basic problems, and if you get any other errors, please post a comment.

I'll be back with at least one more post on this topic...

A year and a half ago I posted the Visual guide to Windows Live ID authentication with SharePoint 2010 series, a post that got a tremendously amount of hits (and still gets) and tons of comments (and new ones still coming in). It showed quite a cumbersome way to Live ID enable your SharePoint 2010 Web Applications using the Microsoft Service Manager, MSM, (which works some times and some times not). Although it did/do work it is not the best way to enable Live ID authentication to your SharePoint 2010 web site. The MSM required you to first test in their INT environment and get approval before putting it into production, and you had to follow a set of guidelines on how to use Live ID logos etc etc, not mentioning all the manual configuration.

Microsoft has a service in its Windows Azure offering called Access Control Services. This is essentially an Identity Federation Provider, living in Windows Azure. This IP not only allows you to federate Live ID authentication but also Google ID, Facebook ID etc. In this post, and subsequent ones, I'll do a visual guide on how to configure SharePoint 2010 to use Windows Azure Access Control Services, ACS, to handle your authentication.

Configuring Azure ACS

First of all let's get acquainted with Windows Azure Access Control Services. But before you start you need to have a Windows Azure subscription. Unfortunately this isn't for free, but if you have an MSDN Subscription you can take advantage of the MSDN Azure benefits. Once you have your subscription you head on over to http://windows.azure.com and sign in with your Live ID. Once you're signed in you are in the Azure Management Portal.

On the left hand side is the navigation and select Service Bus, Access Control & Caching (this is the part that was/is called Azure AppFabric), #1 in the image below. This will load all the AppFabric Services and you will get a new navigation tree on the left hand side and the Ribbon menu will update. To create your Service Namespace, which is like a "container" for the AppFabric services, click on the New button in the Ribbon (#2).

This will bring up a dialog  where you create your new namespace. First of all select the services you want in this namespace - for this authentication sample we only need the Access Control (#1). Secondly you need to specify a unique namespace for your Service Namespace (#2). After that select an appropriate Region (#3) and optionally a Subscription if you have multiple ones. Once your satisfied click Create Namespace (#4) to start the creation.

The creation will take a couple of minutes, so now it's a good time to take that coffee you all been waiting for! As always when dealing with AuthN, coffee breaks are good, that's what my good ol' buddy Spence always nagging about. Wait until the service namespace has the status of Active until proceeding further.

Once it has the Active Status, select your newly created Service Namespace (#1) and  choose Access Control Service in the Ribbon menu (#2). This will open the Access Control Services administration. Note: you will navigate away from the Azure management and reuse the same browser window.

The Access Control Service administration site contains a lot of configuration options. You will see a left hand side navigation where you can set up everything from Identity Providers, IP, and Trusted Parties to custom certificates and get details on how to integrate this with your applications. The first thing we will do here is to add a couple of identity providers, click on Identity Providers in the menu.

Identity Providers

The Identity Providers menu option shows all the Identity Providers that currently is available for this ACS Service Namespace. By default you will only see Windows Live ID. While Windows Live ID might work (if you can live with all the guid based identities) it's very convenient to add other IP's here. Click on Add to add a new IP.

I like to add the Google Identity Provider, since all the user identities from Google IP will use the Google login id (e-mail). Select Google amongst the preconfigured IP's and then click Next.

The next page gives you some customizations options for the Google IP. Change anything you want here and click Save to continue.

This should take you back to the IP page and you should now see both Windows Live ID and Google listed there.

The Relying Party

Next thing to do is to add a Relying Party Application, that is our SharePoint Web Application. Choose Relying party applications in the left hand menu. You will have no RP's configured by default so click on Add to create a new one.

You will now see a form and it is here things must be written correctly otherwise you will not get the AuthN to work with SharePoint 2010. First of all give your RP a nice and easy name (#1). Secondly is the realm (#2), if you remember from the Live ID visual guide the Realm is important. Use a URI instead of URL, it's easier to remember and always works. In this case I choose uri:visualauthn. Then we also need to fill in the Return URL (#3). The return URL must point to http://server/_trust/default.aspx when dealing with SharePoint 2010 (of course replace with your server name, localhost also works in a test environment).

The next things to configure is the tokens. First of all SAML 1.1 must be used as Token Format (#1), SAML 2.0 is default in ACS so make sure to change this. Leave Token encryption policy to None (#2). Then finally an important piece - the Token lifetime. By default this is set to 600 seconds and you need to increase this value. The reason for that is that SharePoint 2010 has the expected token lifetime configured to 600 seconds and when SharePoint validates the token, which is after it's been issued by ACS it will fall outside the lifetime. So you have two options here lower the SharePoint lifetime or increase it in ACS, in this case I've done the latter and set it to 700 seconds.

The rest of the configuration is left intact. If you like you can uncheck Windows Live ID if you do not want Live ID users to sign in with this RP. Click Save when you're done.

You should now see your newly created Relying Party.

Some rules!

We now have two IP's connected to the RP - each of the IP's has a set of outgoing claims to our RP and we need to make sure that the claims received from the IP's to the RP are passed through to SharePoint as outgoing claims from the RP. This is done through the Rule Groups. Select Rule groups in the left hand menu. You will see a Rule Group called "Default Rule Group for Visual AuthN" - this group was automatically created for us when we created the RP: Now click on the rule group to create the actual rules.

Note that there are no rules by default. To create the default rules, just click on Generate to create them.

First we need to select for which IP's to generate the rules, make sure both Live ID and Google (in this case) are selected and click the Generate button.

Now ACS will generate the default rules for all selected IP's. Click Save to complete the rules setup.

I will in follow up posts on this one, show you how to fiddle a bit with these rules. But for now we're just using all the default settings.

Certificates

Next thing to do is to create a certificate that we will be using for Token Signing. The Management Portal makes it very easy for us to make a self signed certificate for testing and demo purposes. For production scenarios either purchase an X.509 certificate or request one from your local Certification Authority (CA) (for instance AD Certificate Services). Just make sure it's a certificate for sign and encrypt the payload. Navigate to the Certificates and Keys in the ACS Management Portal. Click on Add next to the Token Signing certificates.

First of all make sure that the correct Relying Party is selected, it should be the one you just created. ACS allows you to have multiple RP's so just make an extra check.

If you want to create a self signed certificate, take a look at the middle of that page. There is a small snippet that you just can copy and paste to create your own certificate (if you have the MakeCert utility, which is a part of the Windows SDK).

Copy and paste that into a command window or a PowerShell console. This will create your signing certificate and store in the My store on the box you run the command at.

Now you need to export this certificate into two files (with and without the private key). One to upload to ACS and one to import into SharePoint 2010 later. You can export the certificates using the Certificates MMC Snap-In (like in the previous visual Live ID guide) or use PowerShell, which will impress your colleagues more.

The PowerShell I use to export the certificate to one password protected Pfx file (with key) and a Cer file (without key) are the following:

$cert = @(dir cert: -Recurse |   Where-Object { $_.subject -like "CN=visualauthn*" })[0] $type = [System.Security.Cryptography.X509Certificates.X509ContentType]::Cert
$bytes = $cert.Export($type)
[System.IO.File]::WriteAllBytes("c:\visualauthn.cer", $bytes)
$type = [System.Security.Cryptography.X509Certificates.X509ContentType]::Pfx
$pass = read-host "Password" -assecurestring
$bytes = $cert.Export($type, $pass)
[System.IO.File]::WriteAllBytes("c:\visualauthn.pfx", $bytes)

As you can see I grab the certificate with the correct subject and then use the .NET classes to export the certificates and finally save the bytes into files. Replace the exported filenames with your own and also the subject on the first line when doing this for your service,

The Pfx file must be uploaded to ACS. You should still be on the Add Token Signing certificate page and now choose to upload the Pfx certificate and then enter the password you used when exporting it. Make sure that you choose to use this certificate as primary certificate and then click Save.

By now we're done with ACS. Let's head on over to configuring SharePoint.

Configuring SharePoint

Now it's time for the fun stuff - SharePoint. First of all you need to have a Web Application that uses Claims Authentication. If your web app is in Classic mode, either create a new one or upgrade from Classic to Claims.

Trusted Root Authority

Now we need to make sure that the SharePoint farm trusts the certificate used by ACS to sign the tokens. This is done by uploading the other certificate file into SharePoint, using PowerShell. The following code is used to import the .cer file:

asnp microsoft.sharepoint.powershell
$cert = Get-PfxCertificate "C:\visualauthn.cer"
New-SPTrustedRootAuthority -Certificate $cert -Name "Visual AuthN ACS"

To verify that the certificate is imported as a trusted certificate in SharePoint, go to Central Administration > Security > Manage Trust. You should see the name of the trust there:

The Trusted Identity Provider

Next up is to add the ACS RP as a Trusted Token Issuer in SharePoint. Once again we'll do this using PowerShell. Here it is really important that you specify the exact realm as entered when you created the RP in ACS (see line 1 in POSH below). Then you also need the Sign In URL for your RP. Modify line 2 below to match the URL for your Service Namespace (bold and red). Next we define a claim mapping for the identity claim that we want to use, in this case the e-mail address. Finally we just add the new trusted identity token issuer

$realm = "uri:visualauthn"
$signinurl = "https://visualauthn.accesscontrol.windows.net/v2/wsfederation”
$map1 = New-SPClaimTypeMapping
    "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress"
    -IncomingClaimTypeDisplayName "Email" –SameAsIncoming
New-SPTrustedIdentityTokenIssuer -Name "Visual AuthN ACS"
    -Description "ACS rocks!"
    -Realm $realm
    -ImportTrustCertificate $cert
    -ClaimsMappings $map1
    -SignInUrl $signinurl
    -IdentifierClaim $map1.InputClaimType

Now it's time to modify our Web Application to use this ACS RP. Go to Central Administration and Web Application administration. Choose the Web Application you want to enable the RP for (remember that it has to be a Claims Web App). Choose to modify Authentication Providers from the Ribbon menu and select the correct Zone (normally Default). Then scroll down to Claims Authentication Types and check the Trusted Identity Provider checkbox and then our own ACS Trusted Identity Provider. Once that's done click Save.

One final thing here before testing it all. I personally prefer to add a User Policy on the web application directly for one of the users that will log in through the ACS RP. You can of course log in using Windows AuthN and then set permissions inside the site if you prefer so. But this is how I do it. Select the web application and then click User Policy in the Ribbon. Then click Add User choose All Zones and enter the Google e-mail of the user that you will test with, give the user Full Control on the web application. Make sure that you type the e-mail correct - SharePoint will by default validate anything that you write in in Claims mode (more on this in another post).

With this policy in place all should be set to test drive it all.

Test it!

Now all we have to do is test it. Browse to the web application for which you added the Trusted Identity Provider, once it's loaded you will be presented by the default multiple login page. The drop down will show all the available AuthN providers for the web application. To use the ACS login we only need to choose that provider in the list.

Once the provider is selected you will be redirected to the ACS RP login page. In this case we will see two possible providers to use - Live ID and Google. Click on the Google button and you will be redirected, once again...

..this time to the Google log in page which will ask you for username and password. Enter the username (e-mail) that you used when creating the user policy for the web application and log in. In this case, with Google, Google will ask for confirmation that you trust the ACS RP. Choose Allow and you'll be redirected back to the RP which will seamless redirect you to SharePoint.

...and voila! You're in! Take a look at the username in the upper right corner - it should be the e-mail address of the Google ID you used.

Summary

That was it - a visual guide on how to configure federated authentication using Windows Azure Access Control Services and SharePoint 2010. It is this easy! Even though this article was quite lengthy you can do it all in a couple of minutes (compare that to the way I previously showed)!

The SharePoint Enterprise Search Migration Tool (SMT), created  by Microsoft, is a great little tool for moving/migrating search settings from one SharePoint Search Service Application to another, and even from a SharePoint 2007 SSP to a SharePoint 2010 SSA or FAST for SharePoint. The tool is available for download from the MSDN Archive - both as a binary and its source code. It is a console application that creates an XML when exporting the settings and uses the same XML when importing the settings, and it works great in a scripting environment. The SMT that's available from MSDN Archive allows you to migrate Best Bets, Search Scopes and Site Collection Search settings.

Introducing the Enhanced Search Migration Tool!

Consider using this tool when moving search settings from an SSA in a staging environment to an SSA in a production environment, or from production to a standby-farm. There's some stuff missing then - it's not enough just migrating best bets, search scopes etc. In my case I had to move the Managed Properties between our environments. Ok, you can script it all using PowerShell, but I'd prefer having something that automatically could move Managed Properties from dev to test to stage to production to standby.

So I took the source for the SMT and added functionality to work with the Managed Properties. It will export the Managed Properties from one SSA including its configuration and mapped crawled properties to the same XML file as the other Search Settings, and can then be used to import the Managed Properties to another SSA.

Here's how it works:

Export Managed Properties:

SearchMigrationTool.exe -export -managedproperty managedprops.xml

Import Managed Properties:

SearchMigrationTool.exe -import -managedproperty -conflictBehavior prompt managedprops.xml

As you can see it follows the same routine as the default SMT does and supports conflict resolution. And you can of course combine the export and import with the other SMT switches such as BestBet, Scope, SearchSettings or All (which exports/imports everything).

Features

The features of this Enhanced SMT are:

• Import/Export Managed Properties, including all their configuration
• Only works for SharePoint 2010 to SharePoint 2010 (no 2007 and no FAST)
• Only maps existing crawled properties to the managed property
• It will not change the type of a Managed Property
• Handles the case when an SSA is present in multiple proxy groups (bug in original SMT)

Sample usage

Here's a sample on how to use it. Assume that your developers need to add a new Managed Property. Instead of them writing feature receivers or PowerShell to create the Managed Properties they just write a snippet of XML, like this:

The admins then use the Search Migration Tool to import this new Managed Property (as a part of the update POSH or similar).

Once this is done you will see the Managed Property in your SSA.

Can't be easier?

Support for this!

There is no support for this tool at all, but I would appreciate any feedback on it. I've had it running for a while amongst my friends and received positive feedback.

Hopefully my additions will be merged into the "official" SMT - but until then download the tool from here and get your SSA's in sync!

Download

Here are the downloads:

• Just the binaries
• The source code

Note! If you're going to modify/build the SMT you need to grab the SharePoint assemblies. They are not included in this package due to licensing restrictions.

I bet you will!

The Advanced Certification Team at Microsoft Learning will start a new Live Meeting series where you can learn more about the Microsoft Certified Master and Microsoft Certified Architect programs. It will be regularly held meetings where they will go into details about the programs. The program managers will make you understand the program mission and vision, how to prepare for a certification, how to apply for participation and the value of the programs. If you're interested in one or more of these programs I recommend you to attend one of the live meetings or watch the recordings. Of course attending the live meetings will allow you to directly ask questions to the program managers!

There will be live meetings for each product category (SharePoint Server 2010, Lync Server 2010, Exchange 2010, SQL Server 2008 and Active Directory).

To register for one of the live meetings head on over to the Microsoft World Wide Events site and get your slot. Currently there are two planned sessions:

• 2012-02-10: SharePoint 2010 MCM Overview
• 2012-02-15: Exchange 2010 MCM Overview