SharePoint Client Browser v1.2, get it while it’s hot!

The release is out since January 13th, but didn’t got the time to write about it. I have released a new version of the SharePoint Client Browser 2013 (#SPCB). It supports new nodes like associated Visitor, Member and Owner groups of a web object and showing the User Custom Actions for site, web and list object.

But the biggest investment is around User Profiles! Check out this post below.

Enjoy this new version of the SharePoint Client Browser and show your gratitude by adding a review on this page. Download can be found here.

SharePoint Client Browser - Main Screen - v1.2

User Profiles support improved!

The biggest update is within the User Profile area. Version 1.1 was limited to only showing the current user’s properties and peers.

SharePoint Client Browser v1.1 support for User Profiles

The new version shows not only the current user, but retrieves other users via the Search CSOM and retrieves their data as well.

SharePoint Client Browser v1.2 extended support for User Profiles

As shown above not only the User Profile properties and Peers are loaded, but lots of new properties is loaded as well allowing to create rich applications who use the User Profile data. Support is based on the Microsoft.SharePoint.Client.UserProfiles namespace and contains per user profile the following information:

  • User Profile properties
  • Peers
  • Direct Reports
  • Extended Managers
  • Extended Reports
  • Followed Tags (only current user)
  • Followers
  • Suggestions (only current user)
  • People Followed by User

Download SharePoint Client Browser

 Download the SharePoint 2013 Client Browser v1.2 here!

Enjoy this new version of the SharePoint Client Browser and show your gratitude by adding a review on this page.


Build your own custom administration

Managing application specific configuration is mostly done within an application page (aka layouts page). Navigating to these pages is done via custom actions, which adds links to for example the Site Settings page. The challenge starts when the number of application pages grows. Do you keep adding them to the Site Settings page? Do you show them on all Site Settings pages in the web application of every web?

What you need is a centralized administration, like the Central Administration, controlling your application configuration. The Central Administration in SharePoint has two sorts of pages. The homepage (default.aspx) providing an overview and pages like Application Management showing a collection of links related to Application Management.

CentralAdministration_Homepage CentralAdministration_ApplicationManagement

It’s easy to build your own custom administration site. The image below shows my own administration site. Do you see the resemblance?

ApplicationAdministration_Homepage ApplicationAdministration_Security

Creating these pages is pretty straightforward when using the FeatureLinkSections class together with “LinkSectionLevel1.ascx” and “LinkSectionLevel2.ascx” controls. This web control handles the rendering of the links based on enabled features in the current context. The links are provisioned by custom actions as part of a (enabled) feature.

<SharePoint:FeatureLinkSections Runat="server" Id="SettingLinksV4" CellPadding="4" CellSpacing="4" Location="Contoso.SharePoint.AdminPage" LinkSectionControl="LinkSectionLevel1.ascx" />

The Location attribute is an unique identifier indicating the location where links are provisioned. The location is used in the custom action XML (shown below) to point to the location in the FeatureLinkSections control.

<!-- Admin Page - Security --> <CustomActionGroup Id="ContosoSecurity" Title="Contoso Security" Location="Contoso.SharePoint.AdminPage" Sequence="10" Description="" ImageUrl="/_layouts/images/ SiteSettings_UsersAndPermissions_48x48.png" /> <CustomAction Id="ContosoAdmins" GroupId="ContosoSecurity" Location="Contoso.SharePoint.AdminPage" Rights="EnumeratePermissions,BrowseUserInfo" Sequence="10" Title="Contoso Administrators" Description="..."> <UrlAction Url="_layouts/people.aspx" /> </CustomAction>

The FeatureLinkSections control uses two views controlled by the LinkSectionControl attribute.


Shows a 48×48 icon for the group and links are placed below each other.



Shows a 32×32 icon for the group and links are delimited by the “|” character. LinkSectionLinks2


Visual Studio solution

I included the Visual Studio project containing the following components:

  • AdminPages_Web feature: Web scoped feature with event receiver updating the welcome page and quicklaunch. The feature contains the following components:
    • AdminPage module
    • AdminPageActions custom actions
    • PBWebTemplate element
    • Event receiver
  • AdminSite_Site feature: Site collection scoped feature containing the web template for creating the web. The feature contains the following components:
    • AdminWebTemplate web template
  • AdminPageActions custom actions: All custom actions containing all links displayed in the central adminstration.
  • AdminPages module: Provisions the adminpage.aspx and security.aspx pages in the web root folder.
  • AdminWebTemplate web template: Contains the web template for creating the web.
  • PBWebTemplate element: Property bag element with unique web template id

DownloadYou can download the WSP package and source code at

Adding script like jQuery to your pages

When working with the post of Andrew Connell I faced some challenges with implementing my solution. I wanted to add multiple scripts with dependencies to my pages. When creating one elements.xml containing all three script links the order of the <CustomAction Location=”X” ScriptScr=”Y” /> elements is important.

The following elements.xml is packaged in a feature.

<Elements xmlns=""> <CustomAction Location="ScriptLink" ScriptSrc="~site/_layouts/project_name/js/custom-1.0.0.js?rev=20110413" /> <CustomAction Location="ScriptLink" ScriptSrc="~sitecollection/_layouts/project_name/js/ jquery_query-2_1_7.js?rev=20110413" /> <CustomAction Location="ScriptLink" ScriptSrc="~site/_layouts/project_name/js/jquery-1.5.1.min.js?rev=20110413" /> </Elements>

This results in the following HTML in your pages.

document.write('<script type="text/javascript" src="/_layouts/project_name/js/jquery-1.5.1.min.js?rev=20110413"></' + 'script>'); document.write('<script type="text/javascript" src="/_layouts/project_name/js/jquery_query-2_1_7.js?rev=20110413"></' + 'script>'); document.write('<script type="text/javascript" src="/_layouts/project_name/js/custom-1.0.0.js?rev=20110413"></' + 'script>');

Important to know is the order in the elements.xml is the opposite sequence in the HTML. Meaning the script “jquery_query-2_1_7.js” is depending on “jquery-1.5.1.min.js” and needs to be the last item in the elements.xml.

In the script link I’m using “~site” and “~sitecollection” tokens to change the link according to the site or site collection where the user is located. This is important when creating a generic feature used on multiple sites.

By using the “?rev=20110413” at the end of your link you can force the browser to refresh its local cache. A (script) file is downloaded the first time accessing the page. As long as the link does not change the browser does not download the file. By changing the query string you can force a download of the script when changes are made. The actual value “20110413” is todays date, but can be your own versioning logic.

The example above also has a version number in the file name, this is another way of forcing a download. I simply wanted to illustrate the possibilities, you probably will use either query string or version number.

Lessons learned / best practices:

  • Order in elements.xml for <CustomAction /> elements is of influence of the order of script links in the resulting HTML.
  • Use “~site” and “~sitecollection” tokens to control the script link.
  • Use “?rev=20110413” query string or version number in filename to force a download of the file.