Archives

Archives / 2012 / July
  • SharePoint 2013: What’s new with the SPMonitoredScope

    Tags: SharePoint 2013

    One of the best things introduced for developers in SharePoint 2010 was the SPMonitoredScope, which can be used to trace your application, and to pin down potential bottlenecks. I wrote a post on how to use it way back in 2009 – Improve you SharePoint 2010 applications with monitoring using SPMonitoredScope. It’s still worth a read and still true for SharePoint 2013. But the SharePoint team has continued to evolve the SPMonitoredScope in SharePoint 2013, with two small but interesting changes.

    Note: this post is written for SharePoint 2013 Preview – things can/will be changed up until and after RTM…

    New constructor with a TraceSeverity option

    The SPMonitoredScope in SharePoint 2013 has a new constructor which allows you to specify a TraceSeverity for the scope. Why this TraceSeverity then? By default when entering and exiting a monitored scope this is logged in the ULS logs with the ULS log trace severity Verbose (always used by custom usage in SharePoint 2010). By now specifying a trace severity scope we can control at what level of diagnostics logging this should be visible in the trace logs. You can find the logging level for this in Central Administration > Monitoring > Configure diagnostic logging and then under SharePoint Foundation > Monitoring.

    Custom ULS logging with SPMonitoredScope

    This is a great new feature and it allows us to have better control of what goes into the ULS Trace logs, and potentially allows us to avoid flooding of unnecessary messages, when there is no need to trace.

    Detect if the Developer Dashboard is running

    A completely new feature to the SPMonitoredScope is the possibility to detect if the Developer Dashboard is running – that is, if the Developer Dashboard window is open, not if it’s turned on or off in the farm. You check this status by using the IsDeveloperDashboardEnabled property of an SPMonitoredScope instance.

    Let’s look at an example

    Here’s a simple Web Part that uses the new constructor as well as displays if the developer dashboard window is open or not.

    public class MonitoringWebPart : WebPart
    {
        protected override void CreateChildControls()
        {
            using(SPMonitoredScope scope = new SPMonitoredScope(
                "Wictor is watching you", 
                Microsoft.SharePoint.Administration.TraceSeverity.Medium, 
                null)) {
    
                this.Controls.Add(new LiteralControl() { 
                    Text = "Developer dashboard is: " + 
                        (scope.IsDeveloperDashboardEnabled ? "on" : "off")
                });
            }
        }
    }

    Summary

    This was just two small but (at least for me) important improvement for developers in SharePoint 2013.

  • SharePoint 2013: Developer Dashboard shows no data "issue"

    Tags: SharePoint 2013

    SharePoint 2013 Developer DashboardI hope you all had the pleasure to try out the new and improved Developer Dashboard in SharePoint 2013 Preview. It's a fantastic improvement to its predecessor and contains a huge number of improvements. One of the most notable ones is that it's no longer a control on your page which only shows you information about the current request. It's now a separate window which shows you all requests since you started the developer dashboard session. It can actually compete somewhat with ULSViewer!

    Note: this is written for SharePoint 2013 Preview - stuff might/will change in the future. Even though, if this is changed I'm confused :)

    How to turn on the Developer Dashboard

    Turning on the Developer Dashboard is done exactly as before in SharePoint 2010. You use PowerShell for that. The only difference is that the developer dashboard now only have two modes; On or Off. The old OnDemand mode is deprecated and if you set it to OnDemand it will act as On.

    $svc = [Microsoft.SharePoint.Administration.SPWebService]::ContentService
    $dds = $svc.DeveloperDashboardSettings
    $dds.DisplayLevel = "On"
    $dds.Update()

    My Developer Dashboard does not show anything!!!

    Dev Dashboard iconSo, now you have turned on the Developer Dashboard and you would like to check out how cool it really is. You click on the developer dashboard icon in the upper right and the new dev dashboard window opens.

    If you're a real IT-Pro (or any kind of SharePoint professional for that matter) you have not used the Farm Configuration Wizard and configured all your services "automagically". Instead you have created your services manually or by scripting them. Also to save some RAM memory you have not fired up the (new) Search Service, to avoid those pesky noderunners (can't help thinking about Lode Runner when I see em).

    If this is the case you will likely not see any data logged in the Developer Dashboard, instead you'll find these entries in your ULS Trace log: "WCF Request GET failed with error Store hasn't been provisioned". A similar error is also shown in Fiddler.

    WCF Request GET failed with error Store hasn't been provisioned

    Fortunately the fix is really easy! It all comes down to how the Developer Dashboard now is implemented. Previously it was a "simple" control on your page showing the current request only. The new 2013 Developer Dashboard depends on the Usage and Health Data Collection Service Application. This is a Service Application that you need to create through PowerShell and it's a simple one-liner.

    New-SPUsageApplication -Name "Usage Application" -DatabaseName "SP2013A_Logging"
    Just modify the line above with the name that you would like to have for the service application and enter a database name as you prefer (if you leave out the -DatabaseName parameter a database called WSS_Logging will be created).

    Once this is done, the Service Application should start logging to the database and the Developer Dashboard should start showing some neat logging data.

    Happy tracing...

  • SharePoint 2013 - Introduction to the Minimal Download Strategy (MDS)

    Tags: SharePoint 2013, Web Parts

    Introduction

    SharePoint is based on a very rich web interface containing lots of moving parts and lots of customizable areas. As you know the Interwebz is based on a request-response approach where you request a page and get a response back. The approach is the same whether you update the whole page or portions of it. The last decade we've seen smart approaches working around this "problem" using DHTML, JavaScript, AJAX, UpdatePanels, you name it. Facebook, which also contains a very rich and dynamic interface, has been excellent in making a dynamic web interface minimizing the amount of data downloaded for each user interaction and in this way also increasing the perceived performance.

    Up until now SharePoint (out-of-the-box) has not been that efficient on this, even though SharePoint 2010 did some improvements. Most often the whole page has been reloaded for each and every action, this of course affects all end-users and the perceived performance of SharePoint.

    But now, with SharePoint 2013, we have a whole new paradigm thanks to the Minimal Download Strategy - MDS. In this post I will walk you through some details of MDS, how to leverage it in your own customizations and how to successfully adapt your current and future customizations to MDS.

    Note: this article applies to SharePoint 2013 Preview

    Note: article has been updated per 2012-08-16 with some more nice details..

    The Minimal Download Strategy (MDS) - an overview

    The Minimal Download Strategy is by default enabled on Team sites, Community sites and a few others in SharePoint 2013. Once this feature (and it's also a Feature, notice the capital F, we'll get back to that later) all pages for that site is rendered "through" the /_layouts/15/start.aspx page. This page is responsible for loading pages from the site using the MDS. The start.aspx page has a specific JavaScript object asyncDeltaManager (defined in start.js). Basically it parses the URL, looks for the # sign and takes the path following that and dynamically loads that page.

    A MDS Url

    Subsequent requests to pages are dynamically loaded through the asyncDeltaManager object. Once a link is clicked it will invoke a method in the JavaScript object which creates the MDS URL and appends the query string parameter AjaxDelta=1. A request is created and downloaded asynchronously and only the "delta" is returned to the client and assembled and rendered using JavaScript.

    How does it really work?

    Let's dig one step further down and see what really happens and detail out some of the moving parts.

    Enabling or disabling MDS on a site

    [Edited 2012-08-16] First of all what sites do have the MDS enabled by default? MDS is actually a SharePoint feature (Name; MDSFeature, Id: 87294C72-F260-42f3-A41B-981A2FFCE37A) which is Web scoped. Some of SharePoint 2013 Site Templates has this feature stapled (for instance Team, Community, Wiki, Projects, App and Blog sites). The feature is very straightforward - it toggles the EnableMinimalDownload property of the SPWeb object. So you can quite easily yourself turn it off using code (server side or CSOM!!) or PowerShell. Of course you also use the Site Settings > Site Features to turn it on or off as well.

    The MDS is not enabled on publishing sites and is (as I understand it) not compatible with publishing sites, there are a couple of reasons for this, continue to read for more information

    Requirements for MDS

    Except enabling MDS it is required for the MDS to work there is one control that must be placed in the master page - the AjaxDelta control. It should be added to the head section of the master page. This control is responsible for a couple of things. If the page is a start/home page it will clear all controls and make sure that the page is loaded fully and registers the correct scripts.

    How is the delta pages generated?

    One of the key things in the MDS implementation is that SharePoint 2013 contains a new Page class - the DeltaPage. This page class is the key to generating the full pages or just the deltas. Fortunately the common pages such as WebPartPage, WikiEditPage, UnsecuredLayoutsPageBase, LayoutsPageBase etc are inheriting from this page. so most of the out-of-the box pages works and hopefully your custom application pages as well. This page class is quite smart it can handle when MDS is not enabled (ie default rendering) and when MDS is enabled. When MDS is enabled for the site this page is responsible for creating the delta response. The DeltaPage is also responsible for handling exceptions such as when the master page is different (another one or a new version). Every delta request sent using the asyncDeltaManager has a specific request header - the X-SharePoint header. This header contains information about the master page, the language and if the page is in read-write or read-only mode.

    X-SharePoint

    [Added 2012-08-16] This header is important since it contains the master page, the version of the master page etc and SharePoint uses this to determine weather to do a full reload (if the master page have changed) or not. So if you’re working on a master page, be prepared for full reloads of the page, at least the first time you request a page using the modified master page.

    The PageRenderMode control

    [Added 2012-08-16] There is one control called PageRenderMode that can be used on a master page, web part page or page layout. This control has one property called RenderModeType which can have one of two possible values; Standard or MinimalDownload. If the control is placed on a page and have the property set to Standard – it will prohibit the page from being rendered using MDS. If the control is not present or if it’s property is set to MinimalDownload it can participate in MDS rendering. So this control can be used on specific (master)pages to prohibit MDS.

    <SharePoint:PageRenderMode runat="server" RenderModeType="MinimalDownload" />

    A word of caution here, if you’re using the Design Manager to generate master pages, this control will automatically be inserted into the generated artifacts.

    Another gotcha here is that even if you have the PageRenderMode control set to MinimalDownload whenever the publishing features are enabled and you have the ribbon on the page, specifically when using the PublishingRibbon in your master page, SharePoint will automagically inject, during runtime, the PageRenderMode control with the property set to Standard.

    How does the delta response look like?

    The response returned to the asyncDeltaManager has a specific format which very much resembles how ASP.NET UpdatePanels work. Each control that should be re-rendered on a page has it's HTML rendition and all these renditions are separated by a specific token which has the format:

    -deltaboundary-<Guid>-

    The Guid is unique (which is the purpose of guids :-) and the asyncDeltaManager retrieves the current token from the response header called deltaBoundary.

    This image shows a snippet from the IE Network monitor.

    deltaboundary

    After all deltas, at the end of the response, is another encoded set of data.

    More delta stuff

    This data tells what each delta boundary block is intended for and has the following format:

    content length|type|id|data|

    Type identifies what kind of delta data it is; controlDelta is a standard control, pageTitle the title of the page, pageRedirect a page redirection etc. There are about ten more different types. Id identifies the control identifier and data, is the data...

    The asyncDeltaManager takes all this information and assembles the page, so it all looks fast and neat for the end users.

    MDS compliant controls

    If you upgrade a SharePoint 2010 site with custom Web Parts or controls, you will soon realize that the upgraded Webs are not rendered using MDS - even if you update the EnableMinimalDownload property on the SPWeb object. This is due to the reason that the DeltaPage checks all controls present on the page for a specific attribute - the MdsCompliantAttribute. This is an attribute that you can set on a class or on an assembly. If any of the controls present on a page does not have this attribute or has the IsCompliant property set to false it will not render any delta for that page.

    To make your own controls MDS Compliant the classes should look like this:

    [ToolboxItemAttribute(false)]
    [MdsCompliant(true)]
    public class MDSTest : WebPart
    {
        protected override void CreateChildControls()
        {
            this.Controls.Add(new LiteralControl("MDS is enabled on the site:" + 
                SPContext.Current.Web.EnableMinimalDownload));
        }
    }

    Or, you could add the MdsCompliant to the assembly instead of to each class.

    [Added 2012-08-16] The MdsCompliant attribute is set on the whole Microsoft.SharePoint.dll assembly, but not on the Microsoft.SharePoint.Publishing.dll assembly. This is a bummer. This means that all the Field Controls, used in page layouts, are not MDS compliant – which means no MDS on publishing sites.

    An important thing here to remember is that the MdsCompliant attribute does not work in the Sandbox!!! So adding a Sandboxed Web Part to a page disables MDS for that page, period.

    Summary

    Whew, quite a long introduction to the Minimal Download Strategy. I hope that you have a better understanding of it by now and that you better know how to possibly troubleshoot any issues with it (or rather your customizations on MDS sites). There are more to discuss on this topic though, but we'll save that for another day. Cheers!

  • SharePoint 2013: A look at hardware, software and other requirements

    Tags: SharePoint 2013, AppFabric, SQL Server

    SharePoint 2013As 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.

    Note: this is written for the SharePoint 2013 Preview and stuff will/can be changed for RTM.

    Server Roles

    Let's start with some key changes in the physical topology for SharePoint 2013. In SharePoint 2010 we basically had three different server roles; Web Servers, App Servers and SQL Servers. These roles are still valid for SharePoint 2013 but we also have two new roles; Office Web Apps Servers and Workflow Servers. Some roles can be combined and some cannot - for instance it is not supported to run any other role or application on servers that has Office Web Apps installed.

    Update 2012-07-21: A clarification on Office Web Apps Server. You cannot install Office Web Apps Server on a SharePoint 2013 Server Preview. This is currently a hard block.

    Of course we can still split out specific service applications on dedicated servers; for instance we can use specific search servers or cache servers, but I categorize these into the App Servers role.

    Software Requirements

    Let's start with the Software requirements. Software requirements are the minimum stuff you need on your (virtualized) metal before installing SharePoint 2013 or Office Web Apps. I'm not going to go through all the details - since they are well documented in the official documentation. Instead let's focus on some key things.

    Operating Systems

    SharePoint 2013 only supports two operating systems; Windows Server 2008 R2 Service Pack 1 and Windows Server 2012, 64-bit editions of course. There is no support for client OS such as Windows 7 any longer.

    For a Office Web Apps Server it looks like Service Pack 1 for 2008 R2 is not needed, but I strongly suggest that you install that anyways.

    Database Servers

    In SharePoint 2013 the support for SQL Server 2005 has been dropped and you need to use SQL Server 2008 R2 Service Pack 1 or higher (which includes SQL Server 2012).

    .NET Framework

    For SharePoint 2013 Web and App servers you need Microsoft .NET Framework 4.5 (RC) installed and for Office Web Apps Servers you need .NET Framework 4.0. If you have dedicated Workflow servers you can use 4.5 (RC) or 4.0 PU3.

    Windows Server AppFabric

    One new addition to the pre-requisites of SharePoint 2013 is the usage of Windows Server AppFabric, which is a requirement (you actually need to bump it to version 1.1). The AppFabric component is used for the Distributed Cache service (aka Velocity) which is used for the "Social stuff" and token caching.

    Distributed Cache

    Windows Azure Workflow Server specifics

    The servers hosting the Windows Azure Workflow server (WAW) has some specific requirements. The SQL Server must have Names Pipes and TCP/IP enabled and you must have the Windows Firewall enabled. Note that Windows Azure Workflow is an optional component of SharePoint 2013

    Other required software and things to note

    You also need a set of hotfixes, WCF Data Services, WIF 1.0+1.1. By using the pre-requisite installer you get these things configured for you automagically. The pre-req installer downloads them for you but if you would like to automate your installations you can pre download them using Paul Storks excellent PowerShell scripts.

    If you're leveraging the Exchange 2013 and SharePoint 2013 integration features, you need to install the Exchange Web Services Managed API, version 1.2, on your SharePoint boxes.

    Hardware Requirements

    So let's take a look at the hardware requirements, which has been stirring up the community to really weird proportions the last few days. Your hardware requirements really depends on how you intend to use SharePoint 2013, which Service Applications, which customizations etc etc, so you need to take this with a pinch of salt. For development purposes you can adjust these values as it fits you and your projects, but consider the "minimum values" below as something to start with. I'm going to add my personal "minimum values" to this discussion.

    Processors

    VMWare Processor configurationThe specified minimum requirements for the processor is 4 cores (64-bit of course). I've been setting up 2-core machines on my laptop and it has been working fine. But if you're doing development with Visual Studio you likely need a few more. For Production you of course add at least follow the "minimum requirements".

    For Database servers the recommendation is 4 cores for smaller deployments and at least 8 for medium and large deployments.

    Memory, RAM

    This one really hit the fan, when the requirements was published. And the reason for that is that the Requirements document states that you need 24 Gb of RAM for Server development on a single box. In my opinion it's far more than you need for average development, unless you're firing up all service applications, or using Search or Social features heavily. Having 24GB snapshots, will drain your disk space quite fast :).

    For my development boxes with SQL Server 2012 and Visual Studio 2012 installed I've so far found that the sweet spot is somewhere between 6 and 8 GB which is a good trade-off for laptop disk space and performance, but your mileage may vary.

    For production the minimum recommended RAM is 12GB, basically what I recommended for 2010.

    If we take a look at the SQL side you should have at least 8GB RAM for smaller deployments and 16GB RAM for medium ones. In production I would seriously consider bumping that to at least 64GB.

    Browser Support

    When the guessing game of SharePoint 15 features was in full motion a lot of people expected native HTML5 support for SharePoint vNext. Thankfully that did not happen and the Browser support is therefore basically the same as for SharePoint 2010; no Internet Explorer 6, use 32-bit IE's, support for latest versions of Chrome, Safari and Firefox.

    Summary

    This was a quick walkthrough of the hardware and software requirements for SharePoint 2013 Preview. A few new requirements and increased hardware resources compared to SharePoint 2010. But this is all about planning - you cannot just take the requirement and apply that onto your SharePoint 2013 farm, you need to evaluate your farm design and test it. Over the next few months I expect to see some great design samples including metrics from MSIT and of course gain experience from the 2013 engagements starting now...

  • SharePoint 2013: Claims is the new black

    Tags: SharePoint 2013

    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.

    Note: this is written for SharePoint 2013 Preview.

    Claims-based authentication is now the default authentication method

    In SharePoint 2010 we had to choose between two options when creating a Content Web Application - to use Classic mode Authentication or Claims-based Authentication. Classic mode used the same model as SharePoint 2007 and previous versions used and Claims-based authentication was all new and shiny. Initially the recommendation was to use Claims-based content applications, but after a while we discovered the limitations of Claims-based authentication in 2010, so we went back to using Classic for most implementations. Examples of limitations was PowerPivot, Reporting Services etc. There was/is also quite a few limitations with SAML claims.

    Now in SharePoint 2013, Claims-based authentication mode is the default authentication method. You cannot from the web interface create content web applications using Classic mode. If you need to create a Classic web application you need use PowerShell - but you should not do that (unless you have some specific requirement) since Classic mode is now considered deprecated, and will likely be removed in future releases of SharePoint.

    No Classic in sight...

    In SharePoint 2013 it is also required to use Claims-based authentication mode since there are lots of features that relies on it, such as app authentication and the new server-to-server (S2S) authentication.

    So from now on always use Claims-based authentication in SharePoint 2013 and SharePoint 2010.

    Claims-based authentication improvements!

    Since Claims-based authentication now is the default (and only one in the UI) you can expect a number of improvements of Claims-based authentication. First and foremost the SharePoint team has put an effort into the underlying infrastructure. I guess over the last few years with 2010 they have learned from customers, partners and Office 365 how to tune and improve the infrastructure and logging pieces. One significant improvement is the usage of the Distributed Cache (aka Velocity, which is now built into 2013) to store the FedAuth cookies - which means that you do not need sticky sessions, that is sweet! One really cool feature is that the SharePoint STS publishes its own metadata endpoint now. Unfortunately not using the standard XML format but a JSON format, which pretty much makes it useless (as of now). Also the new features in 2010 (June 2012 CU) I blogged about earlier - to choose your own vanity encoding characters is also there. And there are probably tons more that I have not discovered yet...

    How do I convert/upgrade my Web Applications?

    So if you have a Web Application in Classic mode (2010) today, how do I update it to a Claims-based Web Application for 2013. This change is a big change! You might have customizations in your farm that are not Claims compatible. For instance, they might not understand the claims encoding format. The best recommendation I have now is to upgrade your web applications to Claims, before upgrading to 2013. Yes, that's true. If you do the two upgrades at once and you run into trouble, the likelihood of finding the issue is lower and will consume more time. The second best option is to create a Classic Web Application in 2013 and attach (and upgrade) your Classic content databases to that web application and then (after testing) utilize the new Convert-SPWebApplication cmdlet to convert it. (Note: ye olde MigrateUsers method is deprecated in 2013, thank godness!).

    More details can be found in the TechNet article "What's new in authentication for SharePoint 2013 Preview".

    So, where do I go next?

    Now is the time to start testing all this. Test SharePoint 2013, start migrating your web applications (in 2010 and in 2013 - find which method suits you the best) and test your customizations! As I said, the best environment to start with is your current 2010 domains. It is still plenty of time until 2013 will go gold, and you cannot go from beta to RTM anyways...

    Also make sure you do learn WIF, WS-Trust, SAML and what an STS is. Here is a good starter guide. Did I mention test? And have fun! I do!

  • Introducing the SharePoint 2010 Get-SPClaimTypeEncoding and New-SPClaimTypeEncoding cmdlets

    Tags: SharePoint 2010

    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:

    Claim Type

    Encoded value

    http://schemas.microsoft.com/sharepoint/2009/08/claims/userlogonname

    #

    http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier

    ?

    http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress

    5

    Once you start adding providers and Claim Types to SharePoint 2010 using you might start using Claim Types that are not pre-defined by SharePoint. In this case SharePoint automagically assigns the encoded Claim Type a unicode character starting with the 0x01F5 (500 or ǵ) and then incrementing that value with 1 for each and every Claim Type. (Note that it's not just incremental, it can't be uppercase characters or whitespaces.) This is really important to know since if you ever going to move information from one farm to another then you need to configure them in exactly the same order, otherwise your Claim Types encodings, or SharePoint for that matter, won't work.

    Until the June 2012 Cumulative Update there was no (good) way to find out what the encodings were that you've added and there was no way to specify the encoding for a Claim Type. But from now on we have two sleek cmdlets; the Get-SPClaimTypeEncoding and the New-SPClaimTypeEncoding.

    Get-SPClaimTypeEncoding

    The Get-SPClaimTypeEncoding is a lightweight cmdlet that allows you to list all the defined Claim Type encodings in your farm - both the pre-defined ones and the ones you've added yourself. Just run the cmdlet like this to list all the Claim Type encodings:

    Get-SPClaimTypeEncoding

    This will give you the following output:

    Get-SPClaimTypeEncoding

    Note that I have two custom Claim Types, both listed with a question mark (PowerShell can't print Unicode characters - eeek!). Both of these are ones that have been added when I've fiddled with Claims and they have both been automatically been assigned an encoding character. To get a better idea of the encoded character, just run the following PowerShell:

    Get-SPClaimTypeEncoding | ft @{Label="Character";Expression={[Convert]::ToInt32($_.EncodingCharacter)}}, ClaimType

    This will show us, exactly which double-byte character that has been used for the encoding:

    No more ?

    New-SPClaimTypeEncoding

    Using the New-SPClaimTypeEncoding cmdlet we can also add our own encodings, not that we can use any fancy vanity encodings, but at least they can be specified. The cmdlet takes two arguments the -EncodingCharacter which is the encoded value and the -ClaimType. Here's an example on how you can use it:

    New-SPClaimTypeEncoding -EncodingCharacter ([Convert]::ToChar(517)) -ClaimType "urn:another-claim-type"

    After answering Yes two times you'll now have the Claim Type encoding in your farm, and once you use it for a mapping it will not generate a new encoding.

    I'm encoded!

    Note; if you get an ArgumentException it can be one of many reasons. Make sure that your character is not used in another encoding, it is above 500 (0x01F5) and not an uppercase or whitespace character.

    Summary

    That was it, two small but quite powerful and really useful cmdlets. Whenever you need to script environments and are doing Claim Type mappings, make sure that you utilize what you got in the toolbox!

About Wictor...

Wictor Wilén is a Director and SharePoint Architect working at Connecta AB. Wictor has achieved the Microsoft Certified Architect (MCA) - SharePoint 2010, Microsoft Certified Solutions Master (MCSM) - SharePoint  and Microsoft Certified Master (MCM) - SharePoint 2010 certifications. He has also been awarded Microsoft Most Valuable Professional (MVP) for four consecutive years.

And a word from our sponsors...

SharePoint 2010 Web Parts in Action