Archives / 2010 / September
  • SharePoint 2010 and Visio 2010: Better together - Part 3

    Tags: SharePoint 2010, Microsoft Visio

    Welcome back to the SharePoint 2010 and Visio 2010 Better together series for this third part. In part 2 I showed you how to use Visio 2010 to convert your business requirements into workflows that later could be used in SharePoint 2010, using SharePoint Designer 2010 as the man in the middle. This time I'll show you how Visio comes into play even after you have deployed your workflows and running them in your organization.

    Workflows are a great feature in SharePoint 2010 that allows for instance your business rules to be performed in a consistent and repeatable manner. The SharePoint workflows are executed in the background of your web interface, they may pause for long durations and they may involve several users within your company. It can sometimes be hard to keep track of a long-running workflow and see what is happening right now, who is currently working on it etc. By default in SharePoint 2010 you have the Workflow History which is used to log events from the workflow. Events such as workflow status, errors and manual logging operations are seen there. This might be enough for a simple workflow. You can access the Workflow Information page, which contains the history, by clicking on the workflow status column in the list.

    Workflow History

    But for more complex workflows containing several branches and involving multiple users this history list can be long. To get a quick snapshot of the current workflow status it can be hard to interpret this list of log events. Wouldn't it be better to have a visual overview of the workflow? For earlier versions of SharePoint this was available through third party products, but now in SharePoint 2010 this is actually available out of the box.

    It is here Visio Services comes into play. Without digging into deep to the actual Visio Services Service Application, we'll have plenty of time for that, let's satisfy for the moment with that Visio Services is a server side Visio rendering engine. This feature is only available in SharePoint Server, since Visio Services is not available in SharePoint Foundation. If you have a successfully installed and configured the Visio Services Service Application in your SharePoint farm then all you have to do is open the workflow using SharePoint Designer 2010 and in the Settings section click the Show workflow visualization on status page checkbox. Don't forget to save and publish your workflow. If Visio Services is not correctly configured for your Web Application then the checkbox will be disabled.

    Workflow Settings

    Once you have done this you can fire up a new instance of your workflow and then head on over to the Workflow Status page. You will now be presented with Workflow Visualization section on the status page containing the current status of your workflow presented visually using Visio Services. Take a look at the screenshot below, which is taken from the workflow that we used in the previous post. First you can see exactly which steps have been completed using the check box icon (1) and even better you can also see who is actually the current owner of the approval task (2). The screenshot shows that the original task has been reassigned twice. This is a perfect solution to get a hint on the workflow status within seconds.

    Workflow Visualization

    This image is rendered by Visio Services using Microsoft Silverlight, which allows you to zoom and pan the workflow visualization. If you don't have Silverlight installed then Visio Services will render a plain image instead. Using Silverlight is preferred though due to performance and quality of the visualization.

    Worth noticing here is that the visualization does not to apply to already running instances of your Workflow, only new ones. When you publish the workflow from SharePoint Designer a new version of the workflow is created containing the visualization setting. Already running instances keep running the old version of the workflow.

    As you can see from the screenshot some of the workflow arrows intersect and the layout is not optimal, also the labels on the actions are not that descriptive. For instance what does Compare data source actually do? Fortunately there is a really easy solution to this. Notice in the upper left corner of the Visio drawing that there is a Open in Visio button. Click it! In the dialog asking you which mode to open it, choose Edit and click OK.

    The workflow will open in Visio 2010 and you can design the workflow as you like and even apply the corporate branding. You can basically do anything but edit the actual workflow. I do recommend you to edit the labels of the actions and arrange the workflow so that no lines intersect. While you're at it; do try the new auto-align features in Visio 2010 and the great container objects. When you are done all you have to do is save the drawing and then exit Visio.

    The screenshot below shows a modified visualization of the previous workflow, it also has one of the built-in themes applied. I think this is pretty neat and for complex workflows I think this is a necessity.

    Workflow Visualization Deluxe

    Note: You cannot enable visualization for the Workflows that you have created using Visual Studio 2010, only for those created by SharePoint Designer.

    That was it for this time. An introduction on how Visio Services can enhance your workflow experience even further. This really is a usability enhancement and your end-users will adore you for enabling it on your workflows. I will continue this excavation of SharePoint and Visio in the next part taking a closer look at the actual Visio Services Service Application.

    This post was originally posted on at

  • Visual guide to Windows Live ID authentication with SharePoint 2010 - part 2

    Tags: LiveID, SharePoint 2010

    UPDATE 2012-02-01: A new and better approach to this is detailed in a new Visual Guide - Visual guide to Azure Access Control Services authentication with SharePoint 2010.

    I'm back with the second part of the Visual guide to Windows Live ID authentication with SharePoint 2010 series. Part 1 was a huge success and has received a lot of feedback and hits - I hope many of you out there successfully configured your web sites and extranets. I'm currently working on getting the new Swedish SharePoint User Group website up using Live ID...

    This second part will continue where we left it last time, and this time also using a lot of images. Jeremy Thake (MVP), who currently working on a secret SharePoint project, blogged about some of the things I will detail in this post, so for some of you there are stuff repeated in this post.

    Give access to users

    One of the first things you need to do is to give all Windows Live ID users the possibility to log in to your application. It's not mandatory but it is really hard asking for the PUID of all users and manually adding them to your site(s). The PUID will be seen by the user by accessing the Live ID account services at or by signing in so they see the access denied page.


    Instead of manually adding users you should add all authenticated Live ID users to a Visitors group for instance and have some kind of application form with a workflow or similar which they must fill-in to become "real members" (sounds like an InfoPath and SharePoint Designer task...). To add all authenticated Windows Live ID users to the Visitors group; log in to your site and select Site Actions > Site Permissions. Then select the Visitors group or any other group of your choice. Clicking New > Add Users will open up the Grant Permissions dialog. If you write anything in the Users/Groups field and click Check Names you will see that you can actually type anything and it will be valid.


    The Live ID authentication provider accepts any string and it does not perform a lookup with Windows Live ID, so essentially you can use any string . But users will only be sent from Live ID to your site with a PUID (, so you can't give access to a user without the PUID. If you write All users instead this will perfectly resolve to two interesting groups; The All Users (windows) and All Users (LiveID INT) - all depending on what authentication providers you have, in this case the standard Windows login and Live ID (INT) is enabled for the web application. If you select the All Users (LiveID INT) and add it to the group, all authenticated Live ID users will be a member of it.


    You can also click the Browse icon and bring up the People Picker dialog, which has a new look when claims is enabled for the web application. To select the All Users group for Live ID select the All Users node in the tree on the left hand side and then select the All Users (LiveID INT).


    Worth noticing here is you cannot "search" for a Live ID user - not by name, e-mail or anything. You always need the exact PUID or username when claims mode is enabled.

    Anonymous Access

    So, now you have allowed all Live ID users to log in to your site. Enabling anonymous access to users is no different than before. First you have to change the Authentication Provider of the Web Application (Central Administration > Manage Web Applications > Select Web Applications > Click Authentication Providers in the Ribbon > Select Authentication Provider). Just check the Enable anonymous access for the authentication provider and then click OK.


    Next you have to enable anonymous access per Site Collection. Once again go to Site Actions > Site Permissions and click on the Anonymous Access button in the Ribbon menu.


    Then select what the anonymous users can access; Entire Site, Lists or Nothing.

    Once you have done this new users will not be required to log in to your site immediately. Instead they will see the "Sign In" link in the upper right corner.


    The display name of the user

    Once the user logs in to the site the user name still looks pretty ugly - it's just the PUID that is given to SharePoint from the Windows Live ID login service. Unfortunately Windows Live ID only returns one single claim and that is the UPN, which is in the form of a e-mail address. That e-mail address is not even a valid address. You can not expect to get the full name or e-mail of the user from Live ID - you have to implement something of your own OR use the built-in amazing stuff in SharePoint.


    What amazing things do we have in SharePoint then? First of all - if you are on SharePoint Foundation, it's not that amazing at all. You have to live with the PUID or build something of your own and keep all your Site Collections in sync.

    But if you are lucky to set up a SharePoint Server then you can take advantage of the User Profile Service Application. Configure the UPA according to all best practices - but do not configure the User Profile Synchronization (UPS), we do not need it and it does not synchronize with Windows Live ID anyways. Only configure the UPS if you are using both internal Active Directory users in combination with Live ID.

    Once you have configure the User Profile Service Application go to Central Administration > Manage Service Applications and select the User Profile Service Application. Then click on Manage User Properties. We will do that to configure what properties the users are allowed to change.


    You can change a whole lot of User Properties here, but the most important ones are Name and E-mail. We need to make sure that the user can edit those. Browse down to the Name property and select to Edit it.


    To make the Name editable and usable there are a couple of things that we need to take care of:

    1. Make sure that the property can be edited
    2. Make sure that it is visible on the Edit Details page
    3. Choose if the property is publically visible on the profile page
    4. Choose if updates to the property should be visible in the newsfeed
    5. Make sure that the property will be replicated from the profile into the userinfo list in all Site Collections


    Once you have configured the Name and Email property (at least) you are ready for a test drive. Log in to your site and choose My Profile from the login (upper right) menu and click on Edit My Profile. As you can see you are now able to edit the name, by default it is the PUID. Update the settings and click Save and Close and go back to the your main site.


    Once you get back to the site you will probably see that the PUID is still there, hold on and don't start crying yet. It takes some time to synchronize between the user profiles and userinfo lists. You can speed up the process by running the "User Profile to SharePoint Full Synchronization" job - normally run once an hour.


    After a successful sync you should see that the upper right menu shows the Name that you specified in the user profile.


    HTTPS and HTTP

    There is one final thing that you should do before continuing with your site and submit it for the PROD environment and that is to allow users to browse your site without HTTPS. The login procedure must use and will still be using HTTPS. Fire up the IIS manager and select the web site that you have been using and select to edit its Bindings.


    Add a new Host Header binding or other binding of your choice using the HTTP protocol and then click Close.


    Then open Central Administration and select Application Management, under Web Applications choose to Configure alternate access mappings (AAM). Choose to Edit Public URLs and then select your web application. In the Internet Zone add the URL of HTTP address, using the HTTP protocol and then click Save.


    Once this is done you should be able to browse to your site using the HTTP protocol, and then if you click the Sign In link you will be taken to Windows Live ID and be authenticated. When you are successfully authenticated Windows Live ID will redirect you back to the HTTPS address (remember that you specified the Return URL in the MSM using the HTTPS protocol, in part 1). From now on you can move seamless between the HTTP and HTTPS zones.

    There are other options here as well, such as extending the web apps, but that is for someone else to write about...


    That's it, you should now have a fully functional Windows Live ID enabled site. You can even edit the site using SharePoint Designer using the Live ID account. Next part will give you the details on how to move this site from the INT environment to production (PROD),

    Until next time...

  • Sweden SharePoint User Group (SSUG), Meeting in October

    Tags: SharePoint 2010


    After a long and well deserved vacation we’re now back with new strength! It’s time for our first SSUG meeting for the fall!

    Please do remember; This is a FREE event – we never have and never will charge anyone for loving SharePoint and sharing the awesomeness :-)

    Meeting details

    Let’s meet up at Microsoft HQ for our first SSUG meeting this fall! You will have the possibility to mingle around with SharePoint MVPs, folks from Microsoft and of course all our splendidly cool members!

    We will of course have snacks and beer/beverages at hand, just like we always do.

    Please see the following sections for details about the meeting!


    Microsoft AB, the Swedish Microsoft HQ.

    Microsoft AB Finlandsgatan 36 KISTA

    Find it:

    Time and Date

    October 5th, 2010.

    We’ll meet up at 17:30 at Microsoft HQ and sessions will start around 18.00 – so there’s plenty of time for making acquaintances before we begin.

    Session agenda

    • 17:30 – Doors open at Microsoft HQ
    • 18:00: Session 1;
      • Lync/OCS 14: Pontus Haglund from Microsoft AB
    • Break!
    • 19:00: Session 2;
      • Visio 2010 + SharePoint 2010: Wictor Wilén, Connecta AB

    Sign up for the meeting!

    As we still haven’t finalized the new membersite for the SSUG group (hold your breath, we’re soon to be finished); you can sign up for the meeting by e-mailing with the subject “Oktobermöte”.

    If you know of anyone interested in attending, please feel free to forward this information!


    A lot of questions have popped up in regards to what’s going on with the member-site, and we’ll shortly announce some news about that – but for now, let’s focus on making this meeting rock as always :-)


  • Making every site in SharePoint 2010 into a BI Center

    Tags: Visual Studio, SharePoint 2010, PerformancePoint

    The other day I had an interesting and great workshop with a customer about the BI features in SharePoint 2010. SharePoint Insights is one thing that really gets me going - so much great stuff can be unleashed using Excel, Visio and PerformancePoint Services.

    One thing that annoys me with the default settings in SharePoint 2010 is the BI Center. A BI Center does not support the "BI for everyone" mantra - that center only turns numbers and KPI fans on. What you should do is enable BI features on all of your sites; your Intranet home page, your department sites or even on project sites etc. But it isn't as easy as you could imagine. So here's some tips for you all to BI-enable all your sites. Oh wait, don't say to your end-users that you BI-enabled their site - tell them that you have Insight enabled their site instead so you don't scare them off.

    Let's start this little excursion by enabling the PerformancePoint features and Dashboard Designer on an new Site Collection with a top-level site based on a plain ol' Team Site. Of course it is on a SharePoint 2010 Server with Enterprise features installed.

    Enabling basic Insight features

    First of all we need to make sure that the Enterprise features are enabled on your site. If not enable them on the Site Collection or enable them on all Site Collections from Central Administration under Upgrade and Migration.

    Enterprise Features

    Enabling BI-Center features

    So what is so special about the BI-Center. It contains some demo pages using Excel Services, indicators and PerformancePoint content. But most interestingly it contains the special libraries and lists used by PerformancePoint Services to store the PerformancePoint data; the Data Connections Library, the PerformancePoint Content list and the Dashboards library. These lists and libraries cannot be created directly in the web interface, the definitions for these are "hidden" inside the BI-Center site definition. This can easily be solved using PowerShell or by creating our custom Insight enabler feature. PowerShell is great; but building a custom feature allows us to either staple it onto other site definitions or allow the end-user to turn the features on or off.

    Let's create a new feature that adds the necessary lists and libraries. Open Visual Studio and create a new Empty SharePoint Project and to that project we need to add a new feature, scoped to Web. The first thing we need to do is to enable two PerformancePoint features. Since these are hidden ones, activation dependencies is out of question. Let's make it using a Feature Receiver. This feature receiver enables the PPSSiteMaster feature on the current web site and PPSSiteCollectionMaster feature on the Site Collection:

    public const Guid PPSSiteMaster = 
        new Guid("0b07a7f4-8bb8-4ec0-a31b-115732b9584d");
    public const Guid PPSSiteCollectionMaster = 
        new Guid("a1cb5b7f-e5e9-421b-915f-bf519b0760ef");
    public override void FeatureActivated(SPFeatureReceiverProperties properties)
        SPWeb web = properties.Feature.Parent as SPWeb;
        SPSite site = web.Site;
        if (site.Features[PPSSiteCollectionMaster] == null) {
        if (web.Features[PPSSiteMaster] == null) {

    In the FeatureDeactivated method, these features are removed as well. Of course you can add or check for any other features here that you would like to add, such as the Enterprise Features.

    Insights Enabler

    Next up is to create the libraries and lists. Just add a new Empty Element SPI to the project and the lists as follows:

    <ListInstance Title="$Resources:ppsma,Onet_BICenter_Title"
                  Url="Lists/PerformancePoint Content"
                  QuickLaunchUrl="$Resources:core,lists_Folder;/PerformancePoint Content/AllItems.aspx"
    <ListInstance Title="$Resources:ppsma,Onet_BIDataConnections_Title"
                  Url="Data Connections for PerformancePoint"
    <ListInstance Title="$Resources:ppsma,Onet_BIDashboards_Title"

    Insight list and librariesThis CAML is almost a copy of what is in the BI Center site definition, with only modifications so that the correct elements and attributes are used (ListInstance instead of List etc).

    Just hit F5 and watch it build and deploy beautifully. You can see the PerformancePoint lists and libraries in the Quick Launch. Also if you inspect the lists you can see that the correct content types are there.

    Adding the Dashboard Designer

    In order to utilize this fully we need to use the PerformancePoint Dashboard Designer. In the BI-Center template this application could be accessed through a button on one of the publishing pages that was added by default - not a nice solution.

    Instead we would like to have this one in the Site Actions menu, or any other suitable location. Site Actions is where I think it belongs. Let's add it there.

    Add a new Empty Element SPI and in that elements.xml add a CustomAction as follows:

    <CustomAction Id="LaunchPPSDD"
                  Title="Dashboard Designer"
                  Description="Launch PerformancePoint Dashboard Designer"
      <UrlAction Url="javascript:
    var a = _spPageContextInfo.siteServerRelativeUrl.toLowerCase();
    var b = _spPageContextInfo.webServerRelativeUrl.toLowerCase();
    var c = location.protocol + '//' + + a;
    var d = b.replace(a,'');
    location.href = b + '/_layouts/ppswebparts/designerredirect.aspx' + '?SiteCollection=' + c + '&SiteLocation=' + d;"/>

    The CustomAction uses the default Dashboard Designer image and contains a UrlAction with a JavaScript. This JavaScript launches the Dashboard Designer with the correct Site Collection and Site.

    Dashboard Designer CustomAction

    Deploy your solution once again and create your dashboards - without the BI-Center.

    Team BI Center

  • Join me for a chat with the SharePoint MVP Experts

    Tags: SharePoint, SharePoint 2010

    MVP_BlueOnlyNext Wednesday I will sit in the SharePoint MVP Experts panel for a Q&A session where you can ask your questions about SharePoint. The SharePoint MVP Experts Q&A chat is your opportunity to chat and get instant answers about any SharePoint related questions, including topics such as development, design, configuration and setup. There will be several SharePoint MVP's ready to answer your questions...

    When? The chat will take place the 29th of September at 9AM PDT. Sign up here and add it to your calendar. Also sign up here at the Facebook event page.

    Where? In the MSDN Chat Rooms

    How? You only need a web browser to ask your questions

    The chat transcript will be published at the MSDN site after the session.

    See ya there...

  • SharePoint 2010 and Visio 2010 - better together - part 2

    Tags: SharePoint 2010, Microsoft Visio

    This is the second post in the SharePoint 2010 and Visio 2010 - better together series. And it is time to really check out what this great combination have to offer, and the most obvious subject to start with is that we can now use Visio to design the workflows, which then are imported to SharePoint via SharePoint Designer 2010. So let's get started.

    If you ever built workflows for previous versions of SharePoint you either used SharePoint Designer 2007 or Visual Studio 2005/2008. SharePoint Designer 2007 had a very limited workflow designer (you can't actually call it a designer) that took quite some time to get used to and you were very limited in what to do. Visual Studio of course offered you the full set of workflow features. I'm not trying to get to deep into the actual workflow stuff here but it is important to understand how hard it was for the organizations to get their hand-drawn or Visio-drawn workflow into SharePoint. If you used SharePoint Designer to build the workflows then the most problematic situation was when you were supposed to move the workflow from you development environment to production - this was just impossible (yea, there was ways to work around it - but not for mere mortals).

    Visio is excellent in drawing flowcharts, workflows and business processes and some business analysts just love it. So very often you were presented with a Visio diagram of a workflow that you were supposed to implement in SharePoint. What did you do then? Yes, you had to translate the workflow into either a SharePoint Designer 2007 workflow, using the wizard or go for the full monty with Visual Studio. There was room for many mistakes in this process of you, the developer or SharePoint professional, interpreting the Visio diagram to a SharePoint workflow.

    Now, with SharePoint 2010, SharePoint Designer 2010 and Visio 2010 the story is quite different. You can let your business draw the actual SharePoint workflow using the SharePoint Workflow template in Visio. Then you take this Visio diagram, turn it into a SharePoint Designer acceptable file format and configure the last bits in SharePoint Designer. Once that is done all that is left is to hit the publish button. Once the workflow is in place you can let the original author of the Visio diagram verify the functionality. If it is not what he or she asked for you can export it once again to a Visio drawing and fine tune it. The workflow can go back and forth between Visio and SharePoint via SharePoint Designer until everything is set and done.

    Before going into some conclusions and experience from this new way of producing SharePoint workflows, let's take a look at how you do this.

    Assume that we have a list in SharePoint containing proposals that we would like to send to our clients. In this case we use a custom list, but it could be any kind of list or library. Each proposal has a Proposal Value. If the proposal Value is higher than $100.000 then our manager must approve the proposal before sending it to the client.


    The financial controller of our organization decides that this must be implemented as a Workflow on a list and fires up Visio 2010. Of course he uses Visio 2010 Premium - which is the edition of Visio that contains the SharePoint Workflow template. Using this template the controller can draw the workflow using the default SharePoint Actions, Conditions and Terminators.

    By dragging a Start and End Terminator onto the drawing and then adding a condition (Compare Data Source) which should be used for comparing the proposal value to the limit he starts building the workflow, visually. If the condition is below a certain threshold it automatic set the content approval status and if it is above then it should send an e-mail to the manager and then start an approval process and so on. The actual values are not set here, just the actions and conditions in the workflow.


    All this is done by dragging the Actions and Conditions onto the drawing surface and then using the connection tool to connect the items. Notice that the controller cannot set any properties, see Shape Data tool pane, on the actual Workflow Actions. The only thing that can be configured is which path to take for a condition. This is set by right-clicking the connection and then select Yes or No.

    The SharePoint Workflow template, as well as other templates in Visio can also be validated. This is done using the Check Diagram button in the Process Ribbon tab. This check makes sure that all actions are connected and that there are no loose ends. It also checks so that the workflow does not contain any loops, which is not allowed in SharePoint Designer workflows.


    Once the financial controller is satisfied with his workflow he saves it and sends it to the SharePoint professional, if he isn't one himself. Here, he can send it as a standard Visio drawing using the .VSD format or he can use the new Visio Workflow Interchange format with the .VWI extension. The downside with sending it as a .VSD file is that the SharePoint professional must open it in Visio and convert it to a VWI file - which is the format that SharePoint Designer 2010 supports. On the other hand, it might be easier to not teach the business about that and avoid confusions?!

    SNAGHTML1e92be9To create the VWI file you cannot choose File > Save As. You need to use the Process tab in the Ribbon once again and select the Export button. This pops up an Export Workflow dialog where you can specify path and file name. Also notice the Import button. You use this to import a VWI file created by Visio or exported from SharePoint Designer, if you need to go back and update any changes.

    Here it is important to notice that if you export it from SharePoint Designer and then import it into Visio to once again get it back to SharePoint Designer. When exporting an imported VWI file using the same file name you must select to Update workflow information in existing file in the dialog. This makes sure that you can import it to SharePoint Designer once again without losing any settings configured in SharePoint Designer and to allow you to update an existing workflow.

    Ok, now you have the VWI file and you have fired up SharePoint Designer on the site containing the Proposals list. Select the Workflows object in the left navigation of SharePoint Designer and choose Import from Visio in the Workflows Ribbon tab. Then choose the workflow interchange file that you just exported. When you have selected the file you will be presented with a dialog that asks you how to import this Workflow. In this case we want it to be a list workflow, so we select the Proposals list and also give it a good name, then click Finish.


    SharePoint Designer will now open the workflow in the Workflow editor and you will see a workflow without any configuration - just the "flow" as designed in Visio in another, more logical, representation.


    Now you have to discuss with the financial controller what exactly is supposed to be the conditions and values - or even better whish that you got some documentation with the Visio file or even annotations in the actual file. After configuring the workflow it should look like below:


    We are almost there. All that is left is to verify the workflow by clicking on the Check for Errors button in the Ribbon menu and then configure the workflow to start whenever an item is added or changed. To edit the start options you use the bread crumb menu in SharePoint Designer and click on the name of the workflow. This takes you to the Workflow page and in the Start Options section check the Start workflow automatically when an item is created and the same for the changed option.

    The workflow is done, designed using Visio and configured using SharePoint Designer. Now we need to test it in SharePoint. But first you must publish the workflow. This is also done using the Ribbon menu, click on Publish and wait for the process to finish. SharePoint Designer will also check the workflow for any errors before publishing it. If you don't want to publish it right now you can select Save and go get a coffee and get back later and publish it.

    So now, head on over to the Proposals list and add a new proposal, this time with a proposal value of over $100.000. Notice how a new column is added to the list, with the workflow status, and that it automatically starts when you created an item.


    Since this workflow had a Start approval process action a task item will be created in the Tasks list, assigned to the person configured in the workflow using SharePoint Designer. Once the task is done with an approve or reject status the workflow will continue and update the proposal with the outcome, as well as sending an e-mail back to the original person creating the proposal.


    Quite easy, isn't it.

    I really like this approach, as a first version of the Visio, SharePoint Designer and SharePoint integration. There are a couple of things that I hope gets addressed in the future. First of all you can't really put the SharePoint Workflow template in the hands of a business analyst. They are so used to working with regular flow charts or BPMN diagrams. It can sometimes be hard for the to get a good understanding of the different actions in the SharePoint workflow directly related to lists. Secondly it is too bad that you can't configure more using Visio - as the matter of fact it will be hard having one person designing the workflow in Visio and another configuring it in SharePoint Designer. But we have a lot of things to look forward to in upcoming versions - and it's a fantastic start!

    Next time I will show you how to enhance the workflow experience using Visio Services so that your end-users always knows what is happening to their workflows. Which is one of the features I like most about the Visio and SharePoint marriage.

    This post was originally posted on at

  • Sandboxed workflow activities in SharePoint 2010

    Tags: SharePoint 2010

    One of the really great features in SharePoint 2010 is the Sandbox, which allows the end-users to upload solutions using the web interface, instead of relying on administrators adding the solutions directly to the farm. One of the things that that can be deployed to the Sandbox is custom workflow activities. These activates can then be used by the end-users building workflows with SharePoint Designer. It is really powerful to add custom sandboxed activities and it is very easy as well! In this post I will show you how to really fast build a custom sandboxed activity that breaks the permission inheritance on the item which the workflow is executed on.

    Create the activity

    In order to build a sandboxed activity you need to use Visual Studio 2010 and create a new Empty SharePoint project and choose to deploy it as a Sandboxed Solution. Then add a new class to the project. It is this class that will contain the logic for the activity. First make sure that the class is marked as public. Then you need to add a method which is the activity logic itself. This method must have a first parameter as a SPUserCodeWorkflowContext object and it must return a Hashtable. In this case we will use the SPListItem.BreakRoleInheritance() method on the item and since that method takes a boolean parameter, we will add that parameter to our activity as well. This parameter is added as the second in-parameter, which leaves the method definition as follows:

    public Hashtable BreakRoleInheritance(
        SPUserCodeWorkflowContext context, 
        bool copyRoleAssignments);

    The code required to break the role inheritance is as follows:

    Hashtable ht = new Hashtable();
    try {
      using (SPSite site = new SPSite(context.SiteUrl)) {
        SPWeb web = site.OpenWeb(context.WebUrl);
        SPList list = web.Lists[context.ListId];
        SPListItem currentItem = list.GetItemById(context.ItemId);
        ht["Result"] = "Success";
    catch (Exception) {
      ht["Result"] = "Failure";

    First of all the Hashtable to return is created. This hash table is used to store different return values, in this case only on: Result which can be either Success or Failure. Using the SPUserCodeWorkflowContext object the SPSite, SPWeb, SPList and finally SPListItem is retrieved. On the list item the BreakRoleInheritance method is called with the copyRoleAssignments parameter. If the update works fine then the Result return value is set to Success. All exceptions are caught and a Result value of Failure is set.

    Define the Activity for SharePoint Designer

    imageTo be able to use this activity in SharePoint Designer we need to deploy a WorkflowActions/Action element in an Empty Module. Add a new Empty Module SPI to the project. Before editing the elements.xml file modify the automatically added feature (called Feature1) to be scoped to Site so this activity can be used within the whole Site Collection.

    Then open up the elements.xml file and edit it as follows. Here is the full declarative code needed to hook up the activity to SharePoint Designer.

       1:  <Elements xmlns="">
       2:    <WorkflowActions>
       3:      <Action
       4:        Name="Break Role Inheritance"
       5:        Category="Permissions"
       6:        Assembly="$SharePoint.Project.AssemblyFullName$"
       7:        ClassName="$SharePoint.Type.0bc46b26-96ca-4201-8480-6fd7d8ea598e.FullName$"
       8:        FunctionName="BreakRoleInheritance"
       9:        AppliesTo="all"
      10:        UsesCurrentItem="true"
      11:        SandboxedFunction="true">
      12:        <RuleDesigner 
      13:          Sentence="Breaks role inheritance on the item (copy current roles: %1)">
      14:          <FieldBind 
      15:            Field="copyRoleAssignments" 
      16:            Text="Copy Roles" 
      17:            Id="1" 
      18:            DesignerType="Bool"/>
      19:        </RuleDesigner>
      20:        <Parameters>
      21:          <Parameter 
      22:            Name="__Context" 
      23:            Type="Microsoft.SharePoint.WorkflowActions.WorkflowContext,                        Microsoft.SharePoint.WorkflowActions" 
      24:            Direction="In" 
      25:            DesignerType="Hide" />
      26:          <Parameter 
      27:            Name="copyRoleAssignments" 
      28:            Type="System.Boolean, mscorlib" 
      29:            Direction="In" 
      30:            DesignerType="ParameterNames" 
      31:            Description="Copy roles" />
      32:          <Parameter 
      33:            Name="Result" 
      34:            Type="System.String, mscorlib" 
      35:            Direction="Out" 
      36:            DesignerType="ParameterNames" 
      37:            Description="Result of activity"/>
      38:        </Parameters>
      39:      </Action>
      40:    </WorkflowActions>
      41:  </Elements>

    Looking for the ActionFirst of all the WorkflowActions (2) and Action (3) elements are added. The Action element contains the Name (4) and Category (5) of the activity - these are visible in SharePoint Designer when browsing/searching for the Actions. The Assembly, ClassName and FunctionName is of course pointing to the actual assembly, class and method that we previously defined. Note that I'm using replaceable tokens here for the assembly and class name (read more about this in a previous post). The AppliesTo (9) indicates that this will apply to both document libraries and lists and with UseCurrentItem (10) set to true allows the action to modify the item in the list/library.

    The RuleDesigner (12) element tells SharePoint Designer how to render this action in the Workflow Designer. It will write the text in the Sentence attribute and the %1 token will be replaced with the field with the specific Id. In this case the field is the copyRoleAssignments (14-18). With this configuration editing the activity in SharePoint Designer will look like this:


    The last pieces of XML that is required for this activity is the definition of the Parameters (20). The two input parameters (the context and copyRoleAssignments) and the output parameter (via the Hashtable) is defined in the Parameter elements. The XML is quite self explanatory.

    That was it, just deploy this to a Site Collection then open up SharePoint Designer 2010 and build your workflows. Remember that the activity runs in the Sandbox and therefore has its limitations.

  • Visual guide to Windows Live ID authentication with SharePoint 2010 - part 1

    Tags: LiveID, SharePoint 2010

    UPDATE 2012-02-01: A new and better approach to this is detailed in a new Visual Guide - Visual guide to Azure Access Control Services authentication with SharePoint 2010.

    Using Windows Live ID as login provider for SharePoint is a really huge thing. It makes the scenario for public facing web sites, extranets etc. much more easier, for instance there is no need to maintain passwords and users in the same degree. For SharePoint 2007 there is no native support for this, so I built a custom Live ID login provider (available at, but SharePoint 2010 has native support for claims based access. And that is what's on the menu for tonight...

    This post, and the subsequent ones, will show you how to enable Windows Live ID on a SharePoint 2010 farm (SPF or SPS). I will do a visual approach using a lot of screenshots. It has not been an easy path since there are no official guidance on this subject (at the time of this writing), so I'm going to throw in a couple of steps where you can fail miserably while setting it up. Big thanks to Paul Schaeflein who also walked the hard path and took some hits to get this to work! Although there are a couple of available blog posts out there on this issue, some of the are very sparse on the details (why?) and some even contains faulty instructions. Just to safe up on this - the instructions works on my machines and I've been able to reproduce these steps a number of times. If you have any suggestions or comments, just leave them here and I'll try to (get someone to) answer them...

    So what are we waiting for, let's get the party started. I have to warn you - if you don't like certificates - stop reading!


    While I will explain more in details as we move along I think it is important to have a little heads up on claims based access and Windows Live ID. First of all (passive) claims based access is based on the simple scenario where a client/user (subject) trying to access a site (also called Relying Party/RP). This RP has distributed the login procedure to one or more trusted parties called Identity Providers (IP). In our case SharePoint is the RP and Live ID is the IP and you of course are the subject. When the subject tries to access the RP, the subject will be redirected to the IP where the actual logon process is taking place. By attaching cookies to the response and redirecting the user back to the RP with a set of (encrypted) claims the RP can finally authenticate the user. For a better understanding I recommend you to read A guide to Claims-based Identity and Access Control.

    A little bit of claims

    Windows Live ID (WLID) will take care of the login and send back a unique ID to the SharePoint site. This unique ID is the only claim WLID will give you. (Unfortunately you cannot get the correct e-mail address or the name of the user.) SharePoint will first verify the validity of the encrypted security token (containing the claims) before actually starting the AuthN and AuthZ process using the unique ID as username in SharePoint. You will later see how we give access to these unique ID's.

    Another important thing to keep in mind is that WLID have two "zones"; INT and PROD. The PROD zone is what you normally use when logging in to Hotmail etc. The INT zone is used for development and testing and have a completely different account database, so you need to have accounts in the INT zone to continue, more about this in a little bit. You cannot skip the INT zone, you have to register your site there first before applying for approval in the PROD zone.

    The steps provided here is only for the INT environment. For PROD it is basically the same and the post is long enough as it is...

    Registering the site

    MSMBefore even starting to configure the SharePoint site we need to register our site for usage with Windows Live ID. This is done using the Microsoft Service Manager web application located at You log in to this service using you normal (PROD) Windows Live ID account.

    In the left menu click on Register Your Site (1). This will bring up the Register Your Site page where you should enter the name of your site, use a descriptive name (2) and the DNS Name of your site (3). The DNS Name is important! Here you must specify a DNS Name, which we will later change into a URI, or rather URN. Write something random such as

    The DNS Name will be used as a SAML Audience when the security token is sent back and it will be verified by SharePoint. According to the SAML specification the audience must be a URI (a URN or URL). If you use a URL then WLID will for some reason remove the protocol from the audience when sending it back to the RP and SharePoint will throw an exception ([InvalidOperationException: This operation is not supported for a relative URI.] System.Uri.GetLeftPart(UriPartial part)). This might change in the future.

    Finally you have to specify that you will use Windows Live ID (4). Click Submit to continue.

    MSM Config

    You will get a confirmation screen. Click Yes to confirm and proceed to the next step

    MSM Confirmation

    After a few seconds you will be presented with the results. If anything goes wrong you need to go back and edit your registration accordingly - but it shouldn't if you followed these steps.


    Click on the Go to Manage Your Site link. In the drop-down (1) select the site that you just registered and then click on the Modify Editable Site Properties link (2).

    Manage your site

    The next screen allows you to edit the properties of the site. First of all check the Show advanced properties check box to enable more options.

    Advanced stuff ahead...

    First we need to rename the Domain name (1) and set our real domain name to use. Then we need to replace the dummy DNS name (2) with a URN, in this case I use urn:wictorslivesite:int. Remember not to specify a URL, it just won't work as of now. The third thing to edit is the Default Return Url (3); this must be an HTTPS url pointing to the /_trust/default.aspx page, for instance https://extranet.corp.local/_trust/default.aspx. This is the URL that the IP will post back the results to. Finally we have to edit the Expire Cookie URL (4). Just fix the URL and never mind the actual page (you can implement such a page if you feel to at a later time).

    Options, options, options...

    Then scroll down a bit on the page until you reach Override Authentication Policy, this step is crucial. Select MBI_FED_SSL in the drop-down. And when you're done click Submit (at the top of the page).


    Verify and confirm your changes by clicking Yes on the next screen. Take a screenshot and/or notes all these changes.

    Confirmation again

    That's it. Your site is now configured. Actually you can configure a bunch of more features here - but stick to these as of now...


    Let's move on to the SharePoint Server.


    Claims based authentication uses certificates for encryption and signing and you have to trust the certificate of the IP on your SharePoint servers. The following steps must be done on all WFE's in the farm.

    To get the IP certificate; browse to federation metadata URL: (this is for the INT zone). Then copy the inner text from the first X509Certificate node. Open up the Notepad application and paste the text and then save the file as LiveID-INT.cer. Make sure that you only get the inner text of the element.

    XML en masse

    Now you have the certificate in a file and you need to import it to the correct locations on the SharePoint Server(s). It is actually required to be stored locally on three different locations. Open mmc.exe and add the Certificates snap-in. When you select to add it you must first select to use the Computer Account to manage the accounts for and select to use the Local computer as computer to manage.

    Expand the tree until you reach SharePoint > Certificates then right-click on the node and Select All Tasks > Import...


    In the import wizard that appears locate the LiveID-INT.cer file you just created and then click Next > Next > Finish. That's the first one.

    Repeat this procedure for the Trusted Root Certification Authority and Trusted People. Don't worry if you don't have a Certificates sub-node. It will be created when you import the certificate.

    Even more certificates

    Now we're one step closer and it is time to get dirty with some PowerShell. You could of course have done this step using PowerShell, but I leave that for another crafty blogger to show how... Just remember to do this on all WFE's!

    Create the STS provider

    To create the Trusted Identity Token Issuer, that we will use to configure as the login provider for the Web Applications, we fire up PowerShell. This step will not be that "visual" as the previous ones, since none of these commands can be run using the standard SharePoint user interface. I guess it's just a matter of time until someone makes a neat add-on with these simple commands...

    I'll give you the script first and then explains all the involved steps:

    1: asnp microsoft.sharepoint.powershell
    2: $realm = "urn:wictorslivesite:int"
    3: $certfile = "C:\Temp\LiveID-INT.cer"
    4: $rootcert = Get-PfxCertificate $certfile
    5: New-SPTrustedRootAuthority "Live ID INT Root Authority" -Certificate $rootcert
    6: $emailclaim = New-SPClaimTypeMapping     -IncomingClaimType ""     -IncomingClaimTypeDisplayName ""     -SameAsIncoming
    7: $upnclaim =  New-SPClaimTypeMapping     -IncomingClaimType ""     -IncomingClaimTypeDisplayName "UPN"     -LocalClaimType ""
    8: $authp = New-SPTrustedIdentityTokenIssuer -Name "LiveID INT"     -Description "LiveID INT" -Realm $realm -ImportTrustCertificate $certfile     -ClaimsMappings $emailclaim,$upnclaim -SignInUrl ""     -IdentifierClaim ""

    The first line just loads the SharePoint PowerShell Snapin (1), asnp is a shortcut for Add-PSSnapin and saves you a cpl of keystrokes. Then we set three local properties; realm corresponds to the DNS Name (that is the URN), certfile points to the location where you saved the LiveID-INT.cer file and the rootcert is the certificate loaded in as an object.

    Make sure not to make any typos in the claims URN's - been there, done that!

    Then we add the certificate to a SharePoint trusted Root Authority, using the New-SPTrustedRootAuthority cmdlet. You can verify that it is correctly imported by going to Central Adminitration > Security > Manage Trust:

    Trusts in SharePoint

    Then we need to create two claims mappings; one for e-mail (line 6) and one for the identifier (line 7). The claim mappings defines how the incoming claims are mapped to the SharePoint tokens. These two claims are then sent into the New-SPTrustedIdentityProvider cmdlet (line 8) and here is where the magic happens. This cmdlet creates a new trusted identity provider with a name and description, we instruct it which claims mappings to use and which claim is the identifier claim. We are also specifying the URL for the WLID (INT zone) login page.

    Once these commands are executed, we are ready to head on over to the UI and create a Web Application. By all means, if you prefer to do the rest using PowerShell, feel free to do it.

    If you are fiddling back and forwards using different registered Live ID services, you can switch the Realm using the DefaultProviderRealm property of the Trusted Identity Provider object (authp). Don't forget to call Update() on the object... You can only have one provider for each service, even if the realms differ.

    Create the Web Application

    Fire up Central Administration and go to Application Management > Manage web applications. Click New to create a new Web Application.

    First of all you need to select to use Claims Based Authentication. Then enter a Name for your web application, use the port 443 (SSL) and (in this case) configure the host header to match the domain name that you entered while registering the WLID service. Just standard stuff so far.

    Create the web application

    Under Security Configuration make sure that you select Use Secure Sockets Layer (SSL).

    SSL settings

    Under Claims Authentication Types leave Windows Authentication enabled if you like, but make sure to check Trusted Identity Provider checkbox and then check the LiveID INT provider, the one we created using PowerShell.


    Once done click OK to create the Web Application.

    We're almost there just a few steps more...

    Create the Site Collection

    Once the Web Application is created you can directly click on the Create Site Collection link. Enter name and description for the site, and also specify which template to use.

    Now it is time to give some permissions to this site collection. Assume that we did not select any Windows Authentication when creating the Web Application, then we can only add Live ID users, right?

    If you don't have a WLID account in the INT domain it is time to get one now. Open up a new browser window. Go to and sign up for a new account or sign in using one of your existing INT accounts. (Stability of the INT domains are not 100% :-). When you have signed up or logged in click on Credentials and then View your unique ID.


    You will now see a screen with your unique ID; write it down, copy it or remember it...

    Magin number

    Close the browser and return to the Central Administration where you started creating a Site Collection. Now paste or write this unique ID and append in the Primary Site Collection Administrator. But, make sure to convert all characters to lowercase, otherwise you will not be able to log in later:

    Magic number becomes an admin

    Then click OK to create the Site Collection.

    Final configurations

    Before browsing to the site we need to make some final adjustment in the IIS. To be precise we will add a certificate to the site. You can use a certificate that you have acquired for your site or when testing just use a Self-Signed, which I will show you here.

    To create a Self-Signed certificate start the IIS Manager and select the server. In the Features View double-click the Server Certificates module.

    Ouch, more certificates

    Then click Create Self-Signed Certificate in the Actions bar to the right and follow the instructions. Mostly next-next-finish.

    I'll make one myself

    The final configuration is to use this certificate on the Web Application. Choose the Web Application you created in SharePoint in the IIS Manager (1), then click on Bindings (2), select to edit the only binding you have (3) and choose the SSL certificate you just created in the drop-down (4). Click OK and close everything down.

    Advanced stuff

    That's it! Let's see how it behaves...

    Taking it for a test drive

    Now open up a web browser and go to the web application you have created using the domain name you specified when creating it, make sure to use https. You should see the standard warning in the browser that the certificate is not valid (add it as trusted if you want to skip this warning in the future), otherwise just click the continue link.

    Bump, we just hit a certificate again...

    If you have several authentication providers you will see the new SharePoint 2010 Sign In screen with a drop-down where you can choose the authentication provider you would like to use to log in with. If you only have one, in this case the WLID, you will be redirected to the WLID Log In screen - the same will happen if you select LiveID in the drop-down.

    Signing in...

    If you get an error stating We're unable to complete your request, like below, you most certainly have not used the correct Realm when creating the trusted identity provider using PowerShell. Make sure that the Realm and the DNS Name in the Live ID Service Manager are exactly the same, case sensitive and all.

    Ooops, you made a mistake!

    The Windows Live ID sign in screen should look as expected, just the same as logging in to other Live ID services. Enter your INT username and password (remember this is still the INT zone).

    We're getting there

    If you remembered your username and password correctly you will very soon see the beautiful SharePoint 2010 scenery:

    Ahhh. So beatiful!

    Note that your username and display name will be exactly the same as the unique id you have for that user. How to fix this is scheduled for a later post :)

    Next steps

    So, there you have it. It's a handful of steps to complete and you have to make sure not to mistype anything. I will continue this series with some more info that could be of great use when setting this up - hopefully not as long as this one though...

  • SharePoint 2010 and Visio 2010 - better together

    Tags: SharePoint 2010, Microsoft Visio

    This is the first post in a series about SharePoint 2010 and Visio 2010 and how the two products integrate with each other.

    Viso Premium 2010I remember when I first saw Visio many, many years ago. It was before Microsoft acquired it from Visio Corporation. It was my dad using it to make blue prints of our summer house. As most of the gadgets and software he buys he needs a helping hand, not saying he is not technical, but I tend to catch up on such stuff faster than him, so I learnt the basics. I have used Visio since then, during my years in school and university and especially in my job as a developer and architect. (I have also made exact blue prints of our house, including the electrical wiring - call me crazy but I do love that product.) Visio is a great tool for technical diagrams and representations and extremely effective in drawing flowcharts and business processes.

    It was with great joy that I last summer; when SharePoint 2010 and Visio 2010 was let out of the gates in Redmond saw how my two favorite products SharePoint and Visio finally found each other. Not only as a client integration, Visio was also a service application for SharePoint, called Visio Services. There was no longer need for an Active X control to view Visio drawings in the browser.

    Visio 2010, part of the Office family, but not included in the Office suite is a diagramming, drawing and process modeling tool. The latest release of Visio includes new features such as for SharePoint integration, Business Process Modeling Notation and finally the Fluent user interface (aka the Ribbon and friends). Visio 2010 comes in three flavors Standard, Professional and Premium.

    This series will cover most of the connection points between SharePoint 2010 and Visio 2010, starting with the demo friendly workflow creation using the Visio to SharePoint Designer 2010 integration. Then I will show you how to use the Visio client and service application to provide the end users with a visual snapshot representation of a SharePoint workflow. After that we will take a look on how you can use SharePoint 2010 as an effective storage for process diagrams before looking into the BI aspects of Visio Services.

    This post was originally posted on at

  • Understanding folders and namespaces in Visual Studio 2010 SharePoint Solutions, Packages and Features - part 2

    Tags: Visual Studio, SharePoint 2010

    This is a follow-up post to the Understanding folders and namespaces in Visual Studio 2010 SharePoint Solutions, Packages and Features (probably my longest blog post title, except this one...). In that post I discussed how folders and namespaces are handled in Visual Studio 2010 SharePoint projects. I will continue to show some details and tips on how you can affect the outcome of your project/packages.

    Long feature folder names

    As the previous post showed the features generated by Visual Studio ends up as a subfolder in the {SharePoint Root}\TEMPLATE\FEATURES folder. The feature folder will get the name as the concatenation of the project and the feature - which possibly can be quite long.

    Autogenerated feature name

    In the image above the project is called Wictor.Customer.Intranet.Services and the feature IntranetServicesWebParts. There is a good reason to have these auto generated names; it will avoid collisions of features. But if you are in control of the target farm you might consider having shorter names of your feature folders. This is easily done using Visual Studio; Deployment PathOpen up the feature in the Feature Designer and select the Properties tool window. (Note you cannot right-click the feature(s) node in the Solution Explorer and select Properties - that will just give you the properties of the Visual Studio feature file.) If you take a look at the Deployment Path property you will see that it has a default value of:


    As you can see it uses the Visual Studio replaceable parameters to generate the feature folder name. Just edit this to something that fits your "style of coding". It can be a combination of strings and replaceable parameters. For instance this:


    will generate a feature folder like this:

    Optimized feature folder name

    Just remember that it is a reason that the default value of the feature folder name is a combo of the project and feature names.

    Project Assemblies

    By default all SharePoint projects in Visual Studio generates an assembly which is registered in the GAC when deployed. This is done even if we don't write a single line of compiled code. SharePoint allows you to do really neat stuff using only a declarative approach - such as adding content types, list templates, list instances etc. For these projects it is totally unnecessary to install an assembly in the GAC. Fortunately Visual Studio allows you to configure your project so no assembly is generated or rather included in the WSP package (an assembly will still be compiled and created but not deployed with the package).

    If you have a fully declarative package and do not want to add an "empty" assembly to the GAC then you go to the Properties of the project (right-click the project node in the Solution Explorer for instance) and set the value of the Include Assembly In Package property to False.

    No, I don't want any assembly this time...

    Now when you package your solution no assembly will be created and you can deploy your solution using PowerShell without the -GACDeployment argument.

    That's all for today - have a great weekend!

  • SharePoint 2010 August 2010 Cumulative Update makes User Profile Service Application inaccessible (Updated)

    Tags: SharePoint 2010

    UPDATED 2010-10-03: Obviously the KB2276339 is not a Aug CU hotfix KB2352342 is the correct one.

    The second Cumulative Update (CU) is out for SharePoint 2010. It contains two hotfixes; one for Foundation and one for Server. The Foundation fix contains the really important update that should fix the problem with LINQ to SharePoint and anonymous users. You can get the fixes here:

    Caution when installing hotfixes (as usual), they are not that thoroughly tested as Service Packs and only install them if you experience the problems mentioned in the KB articles. Nevertheless since this SPF hotfix contains the above mentioned fix for LINQ to SharePoint - this one is pretty important!

    After installing the CU's you should have version 14.0.5123.5000.


    So, what's the problem I'm talking about?

    UPDATE: The problem I and several others experienced is that the User Profile Service Application started generating errors. This was due to the fact that an incorrect hotfix for the August CU was floating around. So if you get these errors below, you know that you have installed the wrong hotfix.  (Question remains on what the KB2276339 does!)

    CONTENT BELOW SHOULD BE CONSIDERED OBSOLETE As the title of this blog post implies I have (once again) discovered a really nasty bug in the hotfix that makes your User Profile Service Application (UPA) inaccessible. After installing the binaries and upgraded the farm (including reboot and a very long wait for the content databases to update) this is what is presented when going to the UPA administration web page (ManageUserProfileServiceApplication.aspx):


    File not found, correlation id...yup, you know what to do next. Just search the ULS logs for the correlation id and discover this sweet little error message:

    UserProfileServiceUserStatisticsWebPart:LoadControl failed, Exception: System.IO.FileNotFoundException: Could not load file or assembly 'Microsoft.ResourceManagement, Version=4.0.2450.11, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its dependencies. The system cannot find the file specified.  File name: 'Microsoft.ResourceManagement, Version=4.0.2450.11, Culture=neutral, PublicKeyToken=31bf3856ad364e35'     at Microsoft.Office.Server.UserProfiles.UserProfileConfigManager.InitializeIlmClient(String ILMMachineName, Int32 FIMWebClientTimeOut)     at Microsoft.Office.Server.UserProfiles.UserProfileConfigManager..ctor(UserProfileApplicationProxy userProfileApplicationProxy, Guid partitionID)     at Microsoft.SharePoint.Portal.WebControls.UserProfileServiceStatisticsWebPartBase.LoadControl(Object sender, EventArgs e)
    Ok, it cannot locate the Microsoft.ResourceManagement.dll assembly with this version number; 4.0.2450.11. And that's correct, the GAC does not contain that version of the assembly:


    So where did the 4.0.2450.11 version of this assembly go then, I have no idea! But, if you take a look at the KB2276339 you will see that the pplwfe-x-none.msp package should contain just that specific assembly and version (.11). A search amongst the local files on the server also discovered that the assembly is located in two different locations, but not in the GAC:

    • C:\Program Files\Microsoft Office Servers\14.0\Synchronization Service\Bin
    • C:\Program Files\Microsoft Office Servers\14.0\Service

    This assembly is required by the Microsoft.Office.Server.UserProfiles.dll, also present in the GAC.

    UPDATE: Do not follow these steps, instead install the correct hotfix.

    My first reaction was - just register the new assembly to the GAC and everything will be fine. But not! That really funks up the User Profile Service Application. You will see the user interface in Central Administration but the synchronization service will seriously fail and eventually refuse to start, with even more exceptions in the ULS and application logs.

    So instead I decided to use some assembly redirection in Central Administration and forcing CA to use the older version of the assembly. This was done by editing the web.config of Central Administration and adding the following under the runtime/assemblyBinding element:

    <dependentAssembly xmlns="urn:schemas-microsoft-com:asm.v1">  <assemblyIdentity name="Microsoft.ResourceManagement"     publicKeyToken="31bf3856ad364e35" culture="neutral" />  <bindingRedirect oldVersion="4.0.2450.11" newVersion="4.0.2450.9" /></< span>dependentAssembly>

    As you can see I'm forcing Central Administration to use 4.0.2450.9 instead of 4.0.2450.11.

    Once the web.config is saved the CA app pool will automatically be recycled and SharePoint, UPA and the profile sync should run as usual.

    Interesting note: Also, looks like there is a lot of updates to User Profile Service Application in the Server hotfix, but no clues about that (except the files) in the KB!!!!

    WARNING! This is not a tested or validated solution for this problem. It is an intermediate solution for experienced SharePoint administrators to temporarily work around the issues. I expect that an updated CU hotfix will be released as soon as possible.

About Wictor...

Wictor Wilén is the Nordic Digital Workplace Lead working at Avanade. 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 seven consecutive years.

And a word from our sponsors...