Posts Tagged ‘Featured’


In one of my previous blog posts about The future of Forms with SharePoint and Office 365 I talked about what is going on related to Forms. In this article I will show you the power and ease of using Access 2013 to create a simple App Form that you can use in your Office 365 deployment. Simply put, it’s one of the easiest way to create an App for SharePoint without breaking out any code at all.

Say what you want about Access, but these features are pretty slick and I’m going to stick out my chin and say that it’s here to stay.

First, the technical background

I was pretty skeptical when Microsoft announced the use of Access to build Apps and Forms for SharePoint Online, which meant I really had to dig into it myself and try it out. Said and done, here’s what my research tells us.

The big news here is something called Access 2013 Web Apps which enables you to publish your app and host it in Office 365. There’s three main areas in an Access 2013 Web App:

  • The Web App Model
  • Deployment to SharePoint
  • Data storage based on SQL in Azure

    The Web App Model

    With the new web app model we can design our forms for this app easily. There’s no exhausting design process to get around when creating apps using Access. You’ve got table templates ready-to-go as a boilerplate to start your work on.

    This is truly a no-code solution where you with just a few clicks have created a complete application.

    Deployment to SharePoint

    You deploy your app to SharePoint just like any other app you create. An Access App is just like any other SharePoint App. Simple as that.

    Data storage on SQL Azure

    When you deploy your App to Office 365, the data you store in the app is hosted in SQL Azure.

    Simply put, this is it

  • Design your App using Access 2013
  • View your app using the browser
  • Access Services in Office 365 hosts the presentation of the app
  • SQL Azure hosts the data storage of the app

    And what about reporting?

    I’m glad you asked. Since it’s all based on SQL Azure (an actual reliable relational database), you can pull out all types of information though any means you like, including:

  • Power View
  • Access Reports (desktop)
  • Crystal Reports
  • Custom built tools that gather and displays the data ( for example)
  • Excel
  • etc etc.

    Show me the money, step by step

    In order to show how easy it is to get started with building Apps using Access 2013, I’ll show you a step by step guide here for the entire process.

    Get things started

    Launch Access 2013 and choose a Custom Web App

    When you start up Access you are presented with the option to create various types of projects using different templates. There’s one called Custom Web App that you will choose:


    Select a name and location

    In this step you’ll simply enter a name and a location (SharePoint Online site url) and click Create:


    Sign in and authenticate

    If you are not signed in to the site already, you’ll have to fill in your credentials and re-authenticate. Mandatory step to ensure you can deploy the App later.


    Designing the application

    The design overview view

    Okay, so now we have opted to create a new App for Access Services in Office 365, but have yet to create the logic for it. In the next few steps I’ll create a very simple application that will be a way to create and manage small events.


    Create a new data table

    The easiest thing to get you started is to search for a specific type of template in the search box on the front page of Access. I’m searching for Event.


    Select the Event template

    Select the first template in the list, called Event. You will see that it will create a bunch of tables for you which you can review on the left-hand side of the Access design surface:


    Launch the App

    In order to just test this app out, you will click the very large and nice button in the upper left section of the ribbon called "Launch App". Once you’ve done that, it will be published to Office 365 and displayed in your oh-so awesome favorite web browser:


    Filling in some data

    I’ll go ahead and create some data in my application just to demonstrate the various built-in views I get with my forms here.

    I normally switch over to Datasheet view instead of the default List view, which enables me to quickly fill in new data:


    Review the data in the List view mode, a fully functional application


    Where can I find the App?

    Well, after you clicked "Publish App" from Access, it was pushed to your SharePoint Online site that you entered when you created the Access App. So, going to your portal you’ll find the App right there:


    Update: What about on-premises?

    Right after publishing the article I got a question whether this was available for on-premises SharePoint 2013 as well. It requires Access Services to be configured which my friend Kirk Evans have a great overview in his blog here:

    That’s the starting point for taking the discussion to on-premises, check it out!


    This was a very quick introduction to creating Apps using Access 2013. I only wanted to scratch the surface so you can get an introduction to the concept of App Forms with Access Services in Office 365.

    There’s a lot of additional resources available on this topic that I would urge you to check out.

    So as you can see, the information isn’t really new. The reason for the extreme hype the last few days is because when they announced the information about Forms that everyone waited on, Access Apps or App Forms were one of the categories moving forward. So there you have it, an easy way to create business applications without even touching a single line of code.

  • Author: Tobias Zimmergren | |


    What can I say; Microsoft is doing a killer job with Office 365 and their cloud offerings in general. Today during the SharePoint Conference 2014 Keynote, they discussed some of the highlighted new features for SharePoint, Office 365 and related technologies. It is a clear message that cuts across all channels, blogs and presentations alike: Cloud comes first, on-premises may or may not be kept up to date.

    Let’s dig into some of the announcements.

    Office 365 is the fastest growing product in Microsoft’s history

    As quoted from the Keynote presentation from the SPC14 conference, Office 365 is now the fastest growing product in Microsoft’s history. A few years back I was very proud and glad that I got to work with SharePoint, which was the fastest growing product in Microsoft history back then. It was a great feeling when Microsoft announced today that Office 365 now is the fastest growing product in the history of the company. The feelings are the same as when I worked exclusively with SharePoint and they announced it as the fastest growing product ever – safe to say, we work with the right technology.

    I’m also happy to hear that the Office 365 investments that Microsoft are pushing are actually delivering results; Some of the companies I’m involved with have now successfully migrated to Office 365 and we’ve never been happier to get rid of the infrastructure and be able to pay full attention to the actual content and format of the data, instead of allocating resources to connect cables and setup servers.

    Fun fact about Office 365:

    60% of the Fortune 500 companies use Office 365

    Introducing Office Graph

    Office Graph is an Office 365-only feature and is based on the concept of the Yammer Enterprise Graph, but for Office 365. It gives you the possibility to map relationships between people and information. Based on how you utilize your Office 365 information (likes, replies, posts etc) it gathers information and makes available in a neat graph that shows you a visual interpretation of how you are connected to people and information.

    (Image from

    Look out for more information about the Office Graph in the near future. This is a step in the right direction, and I can see a lot of uses for these types of information-linking and visualizations.

    Introducing Oslo

    Oslo is a new app which taps into the Office Graph API’s and presents you with the information that the Office Graph has collected. So based on the information (again; Likes, Replies, Uploaded Documents, Posts and other data collected) by the Office Graph engine you are presented with the information that is most relevant to you. Making it searchable and workable with less effort for the user. Oslo looks very slick and promising – I’m predicting a LOT more to come in this area, and the Office Graph is one heck of an awesome introduction to the existing toolset by Microsoft.

    (Image from

    Introducing the "Groups Experience" and "Inline Social Experiences"

    Building onto the story of Office 365 enhancements, we can now enjoy something referred to as "Groups Experience". This is essentially a feature derived from Yammer’s social groups.

    Over the years Yammer found that the value of enterprise social goes up exponentially when people organize themselves into smaller groups focused on a specific process or deliverable. This simple Groups Experience is so powerful, in fact, that we’re making it a cross-Office 365 concept that will unify people, profiles, conversations, email, calendars, and files across the entire set of Office 365 applications

    This means that if you create a new social group in any of your Office 365 applications, that group and it’s conversations will be available across all applications. For example if you’re creating a new group for discussing a new product launch, you can access the discussions, people and content of that group no matter if you’re in your Outlook application, Calendar, Yammer site or SharePoint sites. Simply put: Integrate social group interactions across the Office 365 suite.


    The "Inline Social Experiences" is where they’re tying it all together with social interactions across their product suites. Office 365, Dynamics or other LOB-applications. Yammer conversations are being added to documents in SharePoint Online and OneDrive for Business and other similar additions. The future holds additional integration points and will be interesting to follow. Keep an eye out for future releases in this area – integration with Office 365 and related technologies will blossom.

    Feature availability

    These new features will become available during 2014, without any more detailed specifications.

    Summary: Cloud-first becomes an immediate reality

    It becomes immediately clear that the cloud-first approach that Satya Nadella mentioned in his first e-mail to the Microsoft employees is already becoming a reality. It doesn’t come as a surprise to me, given that Microsoft have pushed in this direction for several years now. I do believe it’s an important thing to bring to light though, that even if there’s going to be a next version of SharePoint Server for on-premises, that doesn’t mean that it will have feature parity with the services in the cloud.

    A quote from Jarod Spataro on Office 365:

    While we’re committed to another on-premises release of SharePoint Server—and we’ll maintain its social capabilities—we don’t plan on adding new features. Our investments in social will be focused on Yammer and Office 365, so that we can innovate quickly and take advantage of the viral user adoption that is so important to the natural network effect that makes social so powerful.


    Tools for your SharePoint 2013 development toolbox

    January 18th, 2014 by Tobias Zimmergren

    Author: Tobias Zimmergren | |


    Some of my students, clients and community peers have asked about my favorite tools for working with SharePoint. So with that in mind, I quickly noted down some of my favorite tools that every developer should have in their toolbox. I’ve written posts about this before but as times and technology moves forward, new tools and techniques are evolving. I may post about the tools I recommend for IT-Pros at some point, but right now let’s stay on track with the dev-focus.

    If you think I’ve missed out on some great tools, let me know by commenting on the article and I’ll make sure to include it in the post!

    Recommended development tools

    Here’s a brief list of tools that I would recommend for any SharePoint solution developer. At the very least, I would assume that you already have Visual Studio 2012 or Visual Studio 2013.

    CAML Designer 2013

    Historically I’ve been using some kind of CAML query generator since the U2U CAML Query Builder tool was released. There’s really no other efficient way to build your CAML queries than have the stubs auto-generated with a tool. For SharePoint 2013 I am now solely using the CAML Designer tool available from

    The application is a lot more enhanced than any predecessors and I highly recommend that you download it right away unless you’ve already done so. There’s some tweaks that has to be made in the tool before it’s feature complete, but hey it’s a community tool and the best one I’ve used thus far in the area. The best part is the auto-generated code samples that goes with your query. Yum!

    Quick Highlights:

  • Autogenerate the actual CAML Query
  • Autogenerate Server OM code
  • Autogenerate CSOM .NET code
  • Autogenerate CSOM REST code
  • Autogenerate Web Service code
  • Autogenerate PowerShell code

    If you investigate the tool you’ll see that it does not only generate the CAML query itself, but also code-snippets for various technologies for you to copy and paste into your code as a stub to work with. Simple, elegant and so far it only crashes every now and then ;-)



    SharePoint Manager 2013

    Since a friend of mine, Carsten Keutmann, started working on the SPM (SharePoint Manager) tool I have been impressed with it. It has been in the community for a long time and now the 2013 version is pretty slick. Simple and intuitive interface which allows you to quickly and easily navigate down the farm and investigate settings, properties, schema XML and so on. Most of the things in your SharePoint environment can be investigated from this tool.

    So unless you have downloaded this tool already, go get it now. Pow!



    ULS Viewer

    I still keep getting the question about what tool I use to parse my ULS Logs. Honestly, there’s no alternative to the ULS Viewer. I’ve written about logging previously, including the ULSViewer tool: In SharePoint 2013 I use this tool on a daily basis, but I also use the built-in ULS viewer in the Developer Dashboard.

    ULS Viewer Windows Application Screenshot:

    ULS Viewer in the Developer Dashboard:

    For information about how to enable the developer dashboard and launch it, check out my mate Wictor’s blog:

    Windows version download:

    CKS Dev

    A plugin for Visual Studio that is a killer-feature you can’t live without, is CKS:Dev. A team of awesome folks in the community have put together this amazing extension to Visual Studio and it now have support for 2013 as well. It allows you to manage your development routines more efficiently while you are on a coding adventure, it adds a bunch of new project items for your SharePoint projects and contributes to an overall satisfactory SharePoint developer story. You need this extension. Period.


    Color Palette Tool for Branding

    With SharePoint 2013 comes new possibilities for branding. A lot of people are accustomed to wobbling up their own custom CSS files and have a designer do most of the branding parts. If you’re just looking to create new composed looks for SharePoint 2013 without too much effort, you should use the SharePoint Color Palette Tool, provided by Microsoft!



    Debugger Canvas

    A few years ago I blogged about a tool called Debugger Canvas. A tool that can aid you in the debugging process. I’m not using it every day, but when I switch it on it really nails it! What can I say, if you hate the tedious normal debug execution and you want a better and more hierarchical way of displaying your trace in real time, enjoy debugger canvas awesomeness. All the code in your current calls displayed in one view type of thing. You’ve got to check it out.

    Note: The debugger canvas is for VS 2010 Ultimate. I’m not sure if they’ve gotten around to port it up to VS 2012 or VS 2013 yet; But if you’re lingering with 2010 Ultimate, you should get this now. Period.

    (Screenshot is from the Visual Studio Gallery)


    SharePoint 2013 Search Tool

    As we all know search is one of the biggest things in SharePoint 2013. This tool allows us to learn and understand how the queries can be formatted and allows us to easily configure a Search REST Query. Pretty slick if you ask me. Use the tool to create the queries for you, then you can analyze them and better understand how to tweak and modify the output. Great job with the tool!



    Fiddler. Always use Fiddler!

    For most experienced web developers, Fiddler has been a constant tool in the basket. It is an addition to many of the existing tools you can use, but it’s extremely slick for analyzing SharePoint requests on the client side. I’ve saved countless hours by using this awesome tool to analyze the requests and responses from SharePoint. Download it, learn it, use it.



    SPCAF – SharePoint Code Analysis Framework

    My friend Matthias Einig created a tool called SPCAF which analyzes your solutions and code. Truly a beneficial tool in your toolbox that will aid you in the direction of awesomeness. If you’ve developed crappy solutions, you’ll know it before you ship it off to production environments. It integrates with Visual Studio, there’s a stand-alone client application and you can even have it hooked up to your build process – something I’m doing with my Iterative Development Processes.

    (Image from


    .NET Reflector from Red Gate

    It’s no secret that we want to peek into other peoples’ code. With the .NET reflector from Red Gate you can do just that. It’s an awesome reverse-engineering tool which allows you to peek into the code of a compiled assembly! I use it to debug Microsoft.SharePoint*.dll assemblies and to investigate third-party assemblies.



    F12 Debugging experience in your browser

    As Anders mentions in the comments, I forgot to mention the most obvious one. The F12-experience in your web browser. It enables you to debug and investigate HTML, CSS, JavaScript and other resources on your web pages on the client. Internet Explorer, Google Chrome and FireFox all have some type of developer tools available. For me personally, I use Chrome as my main debugging tool and IE for verification. I seldom use Firefox anymore to be honest.

  • How to use F12 Developer Tools to Debug your Webpages
  • How to access the Chrome Developer Tools

    PowerShell Tools for Visual Studio

    As Matthias points out in the comments, there’s another great extension for Visual Studio called PowerShell Tools for Visual Studio. It allows you to get syntax-highlighting on your PowerShell files directly in Visual Studio.




    Are you developing Apps for SharePoint 2013? Steve Curran commented about using the SPFastDeploy tool that he has created. It’s a great extension for quickly pushing changes to your dev site without having to re-deploy the entire app. Pretty neat!

    (Image from Steve Curran’s blog)


    Advanced REST Client plugin for Google Chrome

    As pointed out by Peter in the comments, there’s an awesome plugin for Chrome called Advanced REST Client which allows you to investigate the REST calls and configure your queries pretty simply through the UI. You get to see the results and the request times directly in the browser and you can play with the parameters etc easily until you get it just right. Great tip!



    Postman – REST Client plugin for Google Chrome

    The previous REST Client I mentioned above is awesome, and here’s another really great tool that AC tipped us about. The Postman REST Client plugin for Google Chrome. Similar to the previous plugin for Chrome, but slightly different for the one who prefers that tool instead. An idea is to try them out both and figure out which one you like best yourself.



    SharePoint 2013 Client Browser

    As pointed out in the comments by André, the SharePoint 2013 Client Browser is a tool similar to SharePoint Managed which I’ve mentioned above in this article. With this tool you can connect remotely to a SharePoint environment and investigate the data through the Client API’s. In my screenshot I’m connected from my laptop to my Office 365 SharePoint Online dev-account for development. Pretty sweet!


  • Download:

    Note: There’s a similar tool available called SharePoint Explorer 365, which also allows for connecting to Office 365 which can be found here ( I prefer the previously mentioned one though, the SharePoint 2013 Client Browser, but that’s a matter of preference.


    I can’t believe I originally forgot to put this in. Thanks to the tip in the comments from Caroline I got around to add it to the list here. Smtp4dev is an awesome tool for testing out if SharePoint are sending its e-mails properly, but instead of actually sending the e-mails to the recipients (which may not be wanted if you’re testing on real data for example..) it will catch all e-mails sent through the smtp server and allow you to view them directly in the tool’s UI. It’s pretty neat, and I do use it a lot when working with things related to e-mails and specifically automated processes where e-mails may be sent at various points in time but you still need to verify the logic and correctness.




    So there you go. For everyone who asked what common tools I keep in my toolbox; There’s the most common ones.

    If I missed to mention a tool, feel free to enlighten me and perhaps I can add it to the post.


    Author: Tobias Zimmergren | | | @zimmergren


    When dealing with SharePoint development, there’s tons of things to consider. There’s the aspects of code quality, aspects of proficient testing taking place and of course having a reliable process to re-do and fix anything that comes up along the way. Most importantly in my opinion is to not do all iterative work manually over and over. Most of these things are part of any common ALM (Application Lifecycle Management) cycles in a modern-day development team. In this article I’ll talk briefly about how I’ve set up most of my recent projects with routines for the daily iterative development work. This includes Continuous Integration, Nightly Builds, Automated SharePoint Deployments and Automated UITesting. Pretty slick.

    Background: Why automate?

    One of the most common questions I’m getting today when I introduce the concept of code and deployment automation is "Why?". Why would you invest time to set up an automated environment for iterative builds, deployment and automated tests? For obvious reasons (to me) I shouldn’t need to answer that question because the answer lies within the question itself. That’s just the point – it’s automated and you don’t have to do it yourself over, and over, and over.. and over and over and over again!

    As a quick go-to-guide for automation benefits, this should make do:

    • Continuously finding problems and fixing them in time.
    • Revert the entire code base back to a state where it was working, in case trouble arises.
    • Early warnings of things that could be a potential danger to the success of the project.
    • Frequent check-in policies forces developers to validate their code more often.
    • We can iteratively have an up-to-date testing environment for stakeholders to verify our work continuously.
    • Automate testing by PowerShell.
    • Automate UI Testing.
    • Etc etc etc.

    The list can grow pretty long, and I’ll try to cover a pro/con list of things to consider in the ALM process, but for now I think it’s important to focus on what’s important for your team. For me and my teams the most important thing is to make the processes more efficient and managing some of the daily tasks automatically. In one of my latest projects I’ve taken the time to enforce a new type of development routine for the team which did not exist before – an iterative development process. This has been key to our development in the upgraded SharePoint solutions where we’ve upgraded older projects from SharePoint 2010 to SharePoint 2013.

    See my previous article about Iterative Upgrade Process. It discusses another type of automation that I set up – namely a full SharePoint 2010 to SharePoint 2013 upgrade – every week – before the real upgrade finally approaches.

    So if the "why’s" are clear, let’s move on to an overview of what the process could look like.

    Implementation: How are we enforcing code- and test automation?

    First of all, our main process of automatic development looks something like this:


    This is similar to one of the processes I’ve introduced in one of my projects, but as always it’s individual for each project and can vary quite widely with your requirements and setups. Once we’ve done enough iterations and fixes in this simple ALM cycle, we move on to pushing this out to the production environments. But before we get into that, let’s break these steps down a bit:


    During the development phase we focus on getting things done .Taking the collected requirements, nailing them down into a technical implementation and finally checking the code into our code repository. This is the first step of the technical ALM cycle where we actually start to implement the code to fulfill the requirements. But it can also be the last step in the cycle, where bugs have been reported in the "Test & Verification" step, resulting in additional code fixes – which causes the cycle to start all over. For most people this is common sense, and in most experienced teams there are some type of ALM routines in place.


    When you commit or check-in your code, we can set up rules for the actual check-in. In my case there’s always a few things I tend to do:

    • Build projects and package SharePoint solutions to make sure there’s no basic issues in the project files etc.
    • Execute tools to check the quality of the code, for example the SPCAF tool which is doing a good job of analyzing the packages and resources.
    • Automatically deploy the new packages to a dev-test farm for quick tests by the developers themselves.

    Automatic code verification

    So as mentioned in the earlier step, we perform automatic verification of various things in our code and packages. You can use the code analysis tools for this, and the SPCAF tools and so on. I will automatically fail the build instantaneously if there are any errors reported, which will cause the build server to e-mail the entire team saying "the latest build broke, here’s why…". The reason for having the build server notify everyone is of course that we should be aware of any issues that occur due to our recent changes – better have everyone know about it than nobody.

    In short, we can perform these types of tasks here:

    • Unit Tests (if any)
    • Code analysis
    • SPCAF analysis for SharePoint artifacts
    • etc etc.

    Automatic deployment to dev-test farm

    When we check-in, we perform a new deployment on the developer test environment, which is a separate farm setup for only the developers to verify their changes and code. Each time a check-in is found in the TFS, we trigger a new deployment to this environment. If a developer is doing tests in the environment for some reason, he/she can flag to the build server that no builds should push any deployments until he/she is done with their tests. Then the build server will pick it up right where it left off before pausing.

    Automatic deployment to pre-production farm

    After the code is automatically verified and the solution packages are flagged as OK we proceed with deploying the packages to a test environment. This is also a fully automated step but instead of having this triggered on every check-in I’ve chosen to trigger this once per day in my current setup. The reason for this is that we generally want a better uptime on this environment so we can do some actual tests both automatically and manually. I’ve set up rules that first checks that everything went fine when deploying to the dev-test environment. If not, it’ll flag it as a failed build – otherwise it’ll continue to do the full deployment in the pre-production environment as well.

    Our pre-production environment is a place where more of the UAT and QA tests happen. We have this environment connected to the proper Domain (AD), proper services and the exact same setup (and even content) as in our production environment. Read more about how we duplicate the content in my previous article, more precisely on the "Copy fresh databases" section.

    Summary of the pre-production environment: An almost exact replica of the actual production environment. Proper, life-like tests can be performed here.

    Automatic SharePoint & UI Tests

    One of the coolest things we’ve got setup are something called UI Tests. If you haven’t seen these before, I urge you to take a look here: MSDN – Verifying Code by Using UI Automation.

    With our coded UI Tests, we can simply record logical tests in the UI from our web browser, have Visual Studio convert these recorded actions into a sequence of commands in C# which then are executed automatically once they are run. We’ve made sure that our build server are executing the UI tests on a remote machine, enabling us to test graphical changes and things in the user interface by automatic measures so we don’t have to do this every time ourselves. This is awesome. I promise this is very, very awesome.

    On top of the UI tests that we can have automated, we can also have some logical tests performed by PowerShell. In this step we also conduct generic tests to make sure we can create all types of sites based on our templates, that we can change all settings that we have designed in our applications, that we can create all types of lists and so on. In other words: Automating the boring dirty work that otherwise may be very redundant and you normally fall asleep while doing ;-)

    Technicalities: Team City as a build server

    All of the aforementioned tasks are things that happen automatically by utilizing a build environment. Personally I am pretty hooked on Team City these days. Best part is that it’s free for up to 20 configurations. Cor blimey!

    Why use this specific build server? Some people argue that using a TFS build server is the best, some argue that Jenkins beats all else, some argue that Team City is the most awesome tool in the world and so on. They are all good, and they all serve a purpose. For me, the core benefits of Team City are:

    • Installation is done in less than 1 minute (pow!)
    • Configuration and setup of new builds is as easy as 1-2-3
    • Build agent statistics to keep track of build performance etc.
    • It works with multiple version control systems out of the box

    TeamCity supports a broad range of version controls out of the box, from the most popular ones to somewhat deprecated but still used systems.

    For a single build TeamCity can take source code from several different VCS repositories. You can even mix different types of VCS.

    I’m not going to sell you either TeamCity or any other build server, you can just have a look for yourself at the various options there are out there:

    My obvious recommendations falls on TeamCity and TFS. It all comes down to where you are, what the projects and budgets look like and what features you’re prone to have included. Some of my projects are on TFS build and some are with TeamCity – most of them in TeamCity actually.

    In a future post I might describe in more detail how I’ve technically set everything up for my build environments.

    Build Server Configuration: Setting up proper routines

    It doesn’t really matter which build server configuration you prefer, as long as it fulfills your requirements. My normal requirements in any type of long-running project for example intranets may look like this:

    Continuous Integration

    • Configure a trigger to automatically execute a build, package and code analysis on each check-in.
    • Deploy to dev-test on each check-in

    Nightly Deployment

    • Configure a trigger to automatically execute a build, package and code analysis each night.
    • Configure a trigger to automatically execute a deployment to dev-test and pre-production each night.

    Weekly Deployment

    This is a special configuration that doesn’t really tie into just this ALM cycle, but also to my previously described "Iterative Upgrade Process" cycle. Every week in a current project, we’re tearing down the entire SharePoint environment and we’re building it up again automatically and performing an upgrade. This configuration can trigger that full scheme of things, but it can also be used to just deploy all the latest artifacts. Hence, it’s a pretty special step that we manually trigger today in order to keep the chaos to a minimum.

    PowerShell Verification Tests & Nightly UI Tests

    By using PowerShell to verify that artifacts exist, can be created and seemingly contain the right properties and by using coded UI tests to perform recorded tests of UX interaction tasks, we’re pretty confident that we’re continuously finding out any issues along the way with less manual work.

    As always though; The tests are only as good as the person who wrote them – if you create bad tests, the results will be bad. Keep this in mind and don’t just trust the green lights :-)

    Visual overview: Common setup in my projects

    My thoughts are along the lines of "the less work you have to manually do yourself, the more work you get done" which are pretty common if you’re into making routines more efficient. I’ll try to describe from a birds perspective what our routines are technically doing by showing you an awesome visualization of my most common type of setups. Following is an illustration of my setup, and below the illustration I’ll describe each section more precisely:


    Description of the legend

    In the legend (the gray box) you can see that I’ve marked some of the areas in different colors.

    Developer Area is where the devs are playing around. Nobody else are touching those environments.

    Build Master Area is where the build master (usually me) and potentially a few more designated build administrators hang out. Nobody else are allowed on this environment – it is strictly locked down to only the few people with the required skillset to configure them. If we make a mistake here, we could easily screw up our deadlines in the projects.

    Dev Test Farm is where the developers do their initial tests. A rather simple environment with only one goal: Successfully deploy the packages and activate the required artifacts.

    Pre-Production Farm is where the artifacts are deployed right after they are verified in the dev-test environments. When we push things to this environment we enable the business decision makers and product owners to get in the game and finally try out what we’ve created. Normally this means that they perform initial requirement matching (that is; did we create what they wanted) and then we’ll connect parts of the organizations users in order to perform the UAT (User Acceptance Tests) properly. Once that is done, and we’ve iterated the cycles enough times to fix all the bugs (yay!) then we’ll push it on to the production environment.

    Production Farm is where everything is going live. This is the real deal, and nobody has any access to this environment except the farm administrators. The exception is that the build environment have permission to remotely deploy SharePoint solution packages and execute the required PowerShell commands in order to successfully (and automatically) ensure that the proper artifacts are deployed in a safe manner. We don’t want to allow people to perform manual deployments here! Hands off please :-)


    Well that’s a short story about what my current ALM adventure looks like. I’ve been rigging up some pretty cool environments lately, and I’m loving every bit of it. The confidence of automation is unbeatable – not to mention how much time we actually save.

    I could easily hand any of my clients a presentation saying how many man-hours they’ve saved by investing the hours needed to set this up. Priceless!

    In the future I might write about the technical implementation of the build servers and so on, but that’ll be a post for another time.


    So today we launched, let’s celebrate!

    November 29th, 2013 by Tobias Zimmergren


    The last few weeks and months I’ve been busy setting up the foundation for a new set of products we’re developing. We call them Pointbird. The story behind the name is a tale for another time.

    Simple but powerful plugins, products and solutions for SharePoint and other services – that’s what we’re currently building. We’ve also simplified licensing so that all our customers can easily understand our model and implement our solutions without any trouble! Easy as 1-2-3.



    We’ve got a set of products lined up in our respositories that are in testing and conceptual phases. However we’ve already launched a few products that we’ve experienced as the most popular requirements from our customers in the projects I’ve been involved in the last few years. Nobody had found a solution for these common problems, so I drew some sketches and then we started creating them. Some are small, others more complex – but they all offer value to our clients and that’s the most important thing for me.

    Pointbird Short Url

    So the Short Url product, as the name implies, is a product that can shorten url’s of items in SharePoint lists and libraries.

    It’s pretty slick and for the user it’s just a matter of clicking one link in the ECB menu:

    We’ve actually already implemented this solution at a few clients, and today as soon as we launched we had a few copies sold during the first few hours. Wohoo!

    Pointbird Zip Saver

    A common request from a lot of my clients I’ve been working with is to be able to select specific files from a library and then just download them all, including folders. Requirements were simple and very clear, so that’s exactly what we implemented – a “Zip Saver” solution that can download multiple files at once, including folders, and presents them nicely in a zip-file. The zip-file contains the exact same structure as your library that you chose to download. Neat! Very neat!

    The Pointbird Zip Saver is a rather popular demand and we’ve implemented this in a few organizations already as well.

    Pointbird Notify

    A very simlpe yet smooth solution for displaying ad-hoc messages to your users in your various sites and site collections. A popular request is to instead of using a portal start page news list or announcement list, to be able to push out messages to your users in a more persistent and focused way. With the Pointbird Notify solution you can simply create a new list item in a special list containing announcements, and it will automatically display it for your users with the settings you specify. Awesome.


    That’s it. No more marketing – we’re done for now. Hope you enjoy it :-)

    Author: Tobias Zimmergren | | | @zimmergren


    Every cycle of SharePoint comes with challenges around upgrades and migrations. In one of my current projects I’ve been part of designing an iterative upgrade process – as I like to call it – which means we’ll be upgrading our Farm (all content databases) from SharePoint 2010 to SharePoint 2013 every week. Yes, that’s right – we upgrade SharePoint 2010 to SharePoint 2013 every single week with the latest content from the production environments. This of course happens on a separate SharePoint 2013 farm setup specifically for this purpose.

    In this article I’ll talk about the benefits of my “Iterative Upgrade Process” and what it means in terms of benefits for the teams and people involved with your Intranet, Extranet, Public site or whatever you are using your SharePoint farm for.

    Please do note that this is not an article describing the steps to upgrade your SharePoint environment – this is a process for iterative development and iterative testing in environments that we tear down, build up and upgrade from SharePoint 2010 to SharePoint 2013 every week.

    Background: Everyone is effected by an upgrade or migration

    It’s not uncommon that you bumb into a lot of problems while upgrading your farms from one version to the other. Common problems include customizations, faulty configurations and general bad practices being implemented in the original farm. But for most organizations an upgrade doesn’t “just happen” overnight and then everything works flawlessly – on the contrary there’s always a bunch of problems brought to light that needs to be taken care of.

    Working a lot on SharePoint Intranets like I currently do, we often see problems before, during and after upgrades. Not only technical issues that we can handle, but issues with people in the organization not reaching the right information or not being able to perform their daily tasks. This can have very complicated impacts on the organization if the migration fails to run smoothly and everything isn’t up and running after the service windows you’ve specified.

    The end-user is affected in terms of downtime and possible being hindered to perform their tasks, which in the end hurts the organization since these guys are the thing that keeps the organization running! The IT-departments (or technical folks in your organization involved with SharePoint) may be affected if the migration or upgrade doesn’t go as planned. The business as a whole relies on the system to be functioning and for every minute or hour that the systems aren’t fully available the organization may loose both time and money.

    So in order to minimize any pain in upgrading from one version of SharePoint to another, we need to consider the implications of a troublesome upgrade. With the iterative upgrade process we’ve got in place right now at one of my clients you can test and verify all your changes and customizations and whatever you want to assure the quality of – over and over again before the real deal.

    Implementation: How am I doing this?

    So boiling down the steps included in our iterative upgrade process, gives something similar to this:


    In a nutshell this is what the process looks like from a bird perspective, even though some of the steps require extensive amount of preparation-work and time to get done. Below is an explanation of all these steps in more details, to give you an understanding of what this really means.

    Setup SP 2013 Farm

    The very first step that we need to do is to setup and configure the SharePoint 2013 Farm where our upgraded content will eventually land. In our case we’ve set up this as a one-off configuration, re-using the 2013 farm on every new iteration. You could – as an alternative – argue that it would be beneficial to tear down the entire farm and have it set up again. It would be theoretically possible, but in our specific case it simply doesn’t work that easily – too many dependencies rely on things outside of my and my team’s control.

    Uninstall any custom solutions

    This step is of course only necessary if you’ve already upgraded at least once in the new farm, then by the time you’ve scheduled your next iterative upgrade you’ll need to uninstall any and all old solutions in order to clean up the farm a bit before we proceed.

    Remove any content databases

    Again, this step is only necessary if you’ve already upgraded at least once in the new farm. If you have, there’ll be upgraded content databases that you need to get rid off before we commence the process to the next step. We’re doing this with the PowerShell cmdlet Remove-SPContentDatabase.

    Deploy SP 2010 Solutions

    Deploy your old 2010 solutions. The reason why we would want to do this is that when we later perform the actual mount of the databases, it’s pretty nice if the mounting-process can find the references to the features, web parts and any other resources within those solutions. This is a temporary deployment and the 2010 packages are soon to be removed again.

    Copy fresh databases

    Next step is to ensure that the SQL Server in our new 2013 farm is up to date with containing the latest content databases from the SharePoint 2010 farm. This is why we’re using Flexclone (described in more detail further down in this article). Actually, Flexclone makes virtual copies which are true clones without demanding additional storage space. Pow! Totally awesome.

    Attach databases

    After the databases are copied to the SQL Server, we’ll have to attach them to SQL Server as you would normally do.

    Mount databases

    Next step is where we mount the actual databases to SharePoint. The databases are still in SharePoint 2010 mode, since the copies of our databases comes from the SharePoint 2010 environment. This is why we need to have our 2010 WSP solutions in place before we perform the mount – otherwise reading the mount-logs will be… well, not so fun ;)

    We do this with the PowerShell cmdlet Mount-SPContentDatabase.

    Uninstall SP 2010 Solutions

    When the mounting is done, we’ll need to uninstall the 2010 version of the old solutions and move on to the next step.

    Deploy upgraded SP 2013 Solutions

    Yay, finally we’re at a much cooler step – deploying SharePoint 2013 solutions. So, to give a little background on what these solutions should be:

    You should’ve already upgraded your SharePoint projects to SharePoint 2013 solutions, have them ready to go and use in this step.

    Notes:  This is probably the most time-consuming step if you have custom solutions. Anything you’ve built in SharePoint 2010 and customized there needs to be upgraded to SharePoint 2013 and work there as well. Good thing we’ve got an iterative upgrade process so we can fine-tune this iteratively every day and just hit a button to re-upgrade the farm with the latest builds in our test- and pre-production environments. Yay!

    Upgrade-SPSite with all Site Collections

    Once the new and freshly upgraded 2013 packages have been deployed, we’ll continue by upgrading the actual Site Collections from SharePoint 2010 mode to SharePoint 2013 mode.

    We’ll be using the PowerShell cmdlet Upgrade-SPSite for every one of our Site Collections.

    Misc automated configuration scripts

    We’ve got a lot of custom scripts getting run after the upgrade, as part of the finalization process of the actual upgrade. This includes custom re-branding scripts, re-creation of My Sites and moving content between old and new My Sites, custom scripts to disable and remove artifacts that aren’t used in SharePoint 2013 projects and solutions anymore, modification to removed or altered Content Types etc etc. The list can be made long – if you’re reading this you’ve probably already understood that each scenario is unique, but this process can be applied to most scenarios with a tweak here and there.

    Tools: What tools are we using to make this happen?

    Obviously things doesn’t get done by themselves, so I’ve automated much of the process with various tools and techniques, defined below.

    Deployment Automation with Team City

    There’s tons of ways to automate things in any ALM cycle. Be it a development lifecycle or an infrastructural upgrade lifecycle like this – something to automate the process will be your best bet. Since we’re doing this every week, and the process in itself is pretty complex with plenty of steps that needs to be done properly, I’ve chosen to go with Team City for all of the automation work.

    I’ve gotten the question why use Team City instead of TFS Build or Jenkins or any other available build automation tools. Simply put: Team City is free for up to 20 configurations, easy (very very easy) to configure, works with multiple data sources and repositories and it just works – every time. But that’s a discussion for another day.

    Database copies with Flexclone

    In order to easily get set up with the databases in our environments, we’ve been using Netapp’s Flexclone software very successfully the last year. As quoted from their own website:

    NetApp® FlexClone® technology instantly replicates data volumes and datasets as transparent, virtual copies—true clones—without compromising performance or demanding additional storage space.

    So in essence, the usage of Flexclone allows us to with a single click (almost) replace all of the databases in our test- and pre-production environments and get real copies of the actual production environments in a matter of minutes. There’s no denying that this is awesomenss in its true form.

    Iterative code upgrades with Visual Studio 2013

    In order to maintain and upgrade the new codebase (upgraded from SharePoint 2010), we’re using Visual Studio 2013 like most professional Microsoft-related developers do today. You can use VS 2012 as well, should you like – but do try out 2013 if you can, it’s multiple times faster than previous versions of Visual Studio.

    I have pushed hard for implementing a real ALM process in the team, and we’ve finally got that in place and it’s working pretty nicely right now. We’re using TeamCity to automate builds with continuous integration, nightly builds and scheduled and on-demand deployments to our environments. I will cover code automation more thoroughly in another post in the future, as it would be too much info to cover in this single post.


    So this is a process we follow every week. Once a week I tear down the entire SP 2013 test farm and rig up a new snapshot of the databases on the SQL environment. Then I re-iterate this upgrade process (Team City, PowerShell and PowerShell Remoting to the rescue). This means we can literally try what the real upgrade will be like once we get there. Every week. Also we can have a nice agile iterative way of handling bugs that appear in the environments.

    Oh yeah, should we break something – we click a button or two and we’ve got a freshly upgraded environment with the latest builds from the SP 2013 dev rigs.

    It simplifies the overall process:

    • When time comes for the real upgrade, everything including upgraded code base and automated upgrade scripts is in place!
    • Find and report errors early in the upgrade process of your project
    • Find compatibility errors in code and solutions
    • Find out what will upgrade, and what will not upgrade before its too late
    • Be confident that once we reach the point of upgrade, we’ve done it so many times already that we know what might go wrong
    • The Product Owners, Project Managers, Testers and any other involved people have already verified the state of the system, so once we hit the button in the Production environments – we’re pretty much in a “accepted release” state already.

    I hope you enjoyed this little read about my iterative upgrade process. It’s pretty darn good if you ask me – but requires some time to set up initially, but in larger projects it’s definitely worth it!


    Author: Tobias Zimmergren | | @zimmergren


    In one of my previous articles where we investigated some of the new and awesome delegate controls in SharePoint 2013. It walks you through some of the interesting DelegateControl additions that I was playing around with. On top of that I got a comment about how you could extend it further by adding the current site title in the Suite bar:


    Sure enough, I took a dive into the Seattle.master to take a look at how the title is rendered and found the control called SPTitleBreadcrumb. This is the control that is responsible for rendering the default out of the box title in a normal SharePoint team site like this:


    So to follow the question through and provide an answer to get you started, we’ll take a quick look on how we can build further on our old sample from the previous blog post and add the site title (including or excluding breadcrumb-functionality) to the Suite bar.

    Investigating the out of the box Seattle.master

    In the OOTB Seattle.master, the title is rendered using the following code snippet:

    <h1 id="pageTitle" class="ms-core-pageTitle">
      <SharePoint:AjaxDelta id="DeltaPlaceHolderPageTitleInTitleArea" runat="server">
        <asp:ContentPlaceHolder id="PlaceHolderPageTitleInTitleArea" runat="server">
              <SharePoint:ClusteredDirectionalSeparatorArrow runat="server" />
      <SharePoint:AjaxDelta BlockElement="true" id="DeltaPlaceHolderPageDescription" CssClass="ms-displayInlineBlock ms-normalWrap" runat="server">
        <a href="javascript:;" id="ms-pageDescriptionDiv" style="display:none;">
          <span id="ms-pageDescriptionImage">&#160;</span>
        <span class="ms-accessible" id="ms-pageDescription">
          <asp:ContentPlaceHolder id="PlaceHolderPageDescription" runat="server" />
        <SharePoint:ScriptBlock runat="server">

    What we can see in this file is that there’s a lot of action going on to simply render the title (or title + breadcrumb). You can play around with this in tons of ways, both server-side and client side. In this article we’ll take a look at how we can extend the Suite bar delegate control from my previous article in order to – using server side code – modify the title and breadcrumb and move it around a bit.

    Should you want to get the title using jQuery or client side object models, that works fine too. But we can save that for another post.

    Adding the Title Breadcrumb to the Suite bar

    I’m going to make this short and easy. The very first thing you should do is head on over to my previous article “Some new DelegateControl additions to the SharePoint 2013 master pages” and take a look at the “SuiteBarBrandingDelegate Delegate Control” section and make sure you’ve got that covered.

    Once you’ve setup like that, here’s some simple additional tweaks you can add to your Delegate Control in order for the breadcrumb to be displayed in the top row of SharePoint. Modify the content of the “” (the file in my previous sample is named like that, in your case it may differ) to now look something like this:

    protected void Page_Load(object sender, EventArgs e)
        // Register any custom CSS we may need to inject, unless we've added it previously through the masterpage or another delegate control...
        Controls.Add(new CssRegistration { Name = "/_layouts/15/Zimmergren.DelegateControls/Styles.css", ID = "CssReg_SuiteBarBrandingDelegate", After = "corev5.css" });
        BrandingTextControl.Controls.Add(new Literal
            Text = string.Format("<a href='{0}'><img src='{1}' alt='{2}' /></a>",
        // Create a new Title Breadcrumb Control
        SPTitleBreadcrumb titleBc = new SPTitleBreadcrumb();
        titleBc.RenderCurrentNodeAsLink = true;
        titleBc.SiteMapProvider = "SPContentMapProvider";
        titleBc.CentralAdminSiteMapProvider = "SPXmlAdminContentMapProvider";
        titleBc.CssClass = "suitebar-titlebreadcrumb";
        titleBc.DefaultParentLevelsDisplayed = 5;
        // Add the Title Breadcrumb Control

    As an indication, the end-result might look something like this when you’re done. What we’ve done is simply copied the logic from the Seattle.master into the code behind file of our delegate control and set the “DefaultParentLevelsDisplayed” to a higher number than 0 so it’ll render the actual breadcrumb. By setting this value to 0, only the title will be displayed.


    Then if you want to hide the default title, you can do that by using this small CSS snippet:

        display: none;

    And it’s gone:


    From there you should be able to take it onwards and upwards in term of the styling. I haven’t really put any effort into making it pretty here :-)


    With these small additions and changes to my original code samples you can make the title bar, including or excluding the breadcrumb, appear in the top bar instead of in the default title-area.

    Additional important comments:

    You may need to consider ensuring that the Site Map datasource is available on every page, including system pages for example. If it isn’t or you land on a page that don’t want to render your breadcrumb/title, it may not be able to properly render your navigation as you would expect it to. However that’s something to look into further from that point.

    For example, by default the “Site Content” link will not render the full breadcrumb properly, but rather just say “Home”. In order to fix smaller issues like that, we can further extend the code logic a few lines and take care of those bits.

    My recommendation:

    Always make sure you consider the approach you take for any type of customization and development. For this specific case, we’ve already used some code-behind to display our logo in the top left corner, so we’ve just built some additional sample code on top of that to render the breadcrumbs. However should we only want to do that and not move further onwards with the logic from here – I would most likely suggest you do this using jQuery/CSOM instead to be “Office 365 compliant” and keeping your customizations to a minimum.

    Hope you enjoyed this small tweak. And keep in mind: Recommendations going forward (however hard it’ll be to conform to them) are to keep customizations to a minimum!

    Cheers, Tob.

    Author: Tobias Zimmergren | | @zimmergren


    SharePoint 2013 comes with tons of enhancements and modifications to previous versions of the product. One of the cool features I’ve played around with lately is the Geolocation field. Back in 2010 I wrote a custom-coded solution for displaying location information in our SharePoint lists, integrating some fancy-pants Google Maps – in SharePoint 2013, a similar field exist out of the box.

    In this article I’ll mention what this field does, a sample of creating and using the field, getting and setting the Bing Maps keys to make sure our maps are properly working and displaying.

    Update 2013-09-14: As pointed out by Leon Zandman in the comments, there’s a some updated pre-requisites required in order to view the geolocation field value or data in a list. Information from Microsoft:

    An MSI package named SQLSysClrTypes.msi must be installed on every SharePoint front-end web server to view the geolocation field value or data in a list. This package installs components that implement the new geometry, geography, and hierarchy ID types in SQL Server 2008. By default, this file is installed for SharePoint Online. However, it is not for an on-premises deployment of SharePoint Server 2013. You must be a member of the Farm Administrators group to perform this operation. To download SQLSysClrTypes.msi, see Microsoft SQL Server 2008 R2 SP1 Feature Pack for SQL Server 2008, or Microsoft SQL Server 2012 Feature Packfor SQL Server 2012 in the Microsoft Download Center.

    Introduction to the Geolocation Field

    I’ll showcase what the Geolocation field can do for us in a SharePoint list. In the sample below I’ve used a list called “Scandinavian Microsoft Offices” which contains a few office names (Sweden, Denmark, Finland and Norway). What I want to do in my list is to display the location visually to my users, not only the name and address of the location. With the new Geolocation field you can display an actual map, as I’ll show you through right now – skip down to the “Adding a Geolocation Field to your list” section if you want to know how to get the same results yourself.

    A plain SharePoint list before I’ve added my Geolocation field


    As you can see, no modifications or extra awesomeness exist in this list view – it’s a vanilla SharePoint 2013 list view.

    The same list, with the Geolocation field added to it

    When we’ve added the Geolocation field to support our Bing Maps, you can see that a new column is displayed in the list view and you can interact with it. In my sample here I’ve filled in the coordinates for the four Microsoft offices I’ve listed in my list.


    Pressing the small globe icon will bring up a nice hover card kind of dialog with the actual map, with options to view the entire map on Bing Maps as well (which is essentially just a link that’ll take you onwards to the actual bing map):


    Viewing an actual list item looks like this, with the map fully integrated by default into the display form:


    And should you want to Add or Edit a list item with the Geolocation field, you can click either “Specify location” or “Use my location“. If you browser supports the usage and tracking of your location, you can use the latter alternative to have SharePoint automagically fill in your coordinates for you. Compare it with how you check in at Facebook and it recognizes your current location and can put a pin on the map for you.


    In my current setup I don’t have support for “Use my location” so I’ll have to go with the “Specify location” option – giving me this pretty dull dialog:


    As you can see, you don’t have an option for searching for your office on Bing Maps and then selecting the search result and have it automatically insert the correct Lat/Long coordinates. But, that’s where developers come in handy.

    Create a new Map View

    Let’s not forget about this awesome feature – you can create a new View in your list now, called a “Map View”, which will give you a pretty nice map layout of your tagged locations with pins on the map. Check these steps out:

    1) Head on up to “List” -> “Create View” in your List Ribbon Menu:


    2) Select the new “Map View”


    3) Enter a name, choose your fields and hit “Ok”


    4) Enjoy your newly created out of the box view in SharePoint. AWESOME


    Adding a Geolocation Field to your list

    Right, let’s move on to the fun part of actually adding the field to our list. I’m not sure if it’s possible to add the field through the UI in SharePoint but you can definitely add it using code and scripts, which is my preferred way to add stuff anyway.

    Adding a Geolocation field using PowerShell

    With the following PowerShell snippet you can easily add a new Geolocation field to your list:

    Add-PSSnapin Microsoft.SharePoint.PowerShell
    $web = Get-SPWeb "http://tozit-sp:2015"
    $list = $web.Lists["Scandinavian Microsoft Offices"]
        "<Field Type='Geolocation' DisplayName='Office Location'/>",

    Adding a Geolocation field using the .NET Client Object Model

    With the following code snippet for the CSOM you can add a new Geolocation field to your list:

    // Hardcoded sample, you may want to use a different approach if you're planning to use this code :-)
    var webUrl = "http://tozit-sp:2015";
    ClientContext ctx = new ClientContext(webUrl);
    List officeLocationList = ctx.Web.Lists.GetByTitle("Scandinavian Microsoft Offices");
        "<Field Type='Geolocation' DisplayName='Office Location'/>", 

    Adding a Geolocation field using the Javascript Client Object Model

    With the following code snippet for the JS Client Object Model you can add a new Geolocation field to your list:

    function AddGeolocationFieldSample()
        var clientContext = new SP.ClientContext();
        var targetList = clientContext.get_web().get_lists().getByTitle('Scandinavian Microsoft Offices');
        fields = targetList.get_fields();
            "<Field Type='Geolocation' DisplayName='Office Location'/>",
        clientContext.executeQueryAsync(Function.createDelegate(this, this.onContextQuerySuccess), Function.createDelegate(this, this.onContextQueryFailure));

    Adding a Geolocation field using the Server Side Object Model

    With the following code snippet of server-side code you can add a new Geolocation field to your list:

    // Assumes you've got an SPSite object called 'site'
    SPWeb web = site.RootWeb;
    SPList list = web.Lists.TryGetList("Scandinavian Microsoft Offices");
    if (list != null)
        list.Fields.AddFieldAsXml("<Field Type='Geolocation' DisplayName='Office Location'/>",

    Be amazed, its that easy!

    Bing Maps – getting and setting the credentials in SharePoint

    Okay now I’ve added the fields to my lists and everything seems to be working out well, except for one little thing… The Bing Map tells me “The specified credentials are invalid. You can sign up for a free developer account at“, which could look like this:


    Get your Bing Maps keys

    If you don’t have any credentials for Bing Maps, you can easily fetch them by going to the specified Url ( and follow these few simple steps.

    1) First off (after you’ve signed up or signed in), you’ll need to click on the “Create or view keys” link in the left navigation:


    2) Secondly, you will have to enter some information to create a new key and then click ‘Submit’:


    After you’ve clicked ‘Submit’ you’ll be presented with a list of your keys, looking something like this:


    Great, you’ve got your Bing Maps keys/credentials. Now we need to let SharePoint know about this as well!

    Telling SharePoint 2013 what credentials you want to use for the Bing Maps

    Okay – so by this time we’ve created a Geolocation field and set up a credential for our key with Bing Maps. But how does SharePoint know what key to use?

    Well that’s pretty straight forward, we have a Property Bag on the SPWeb object called “BING_MAPS_KEY” which allows us to configure our key.

    Since setting a property bag is so straight forward I’ll only use one code snippet sample to explain it – it should be easily translated over to the other object models, should you have the need for it.

    Setting the BING MAPS KEY using PowerShell on the Farm

    If you instead want to configure one key for your entire farm, you can use the Set-SPBingMapsKey PowerShell Cmdlet.

    Set-SPBingMapsKey -BingKey "FFDDuWzmanbiqeF7Ftke68y4K8vtU1vDYFEWg1J5J4o2x4LEKqJzjDajZ0XQKpFG"

    Setting the BING MAPS KEY using PowerShell on a specific Web

    Add-PSSnapin Microsoft.SharePoint.PowerShell
    $web = Get-SPWeb "http://tozit-sp:2015"
    $web.AllProperties["BING_MAPS_KEY"] = "FFDDuWzmanbiqeF7Ftke68y4K8vtU1vDYFEWg1J5J4o2x4LEKqJzjDajZ0XQKpFG"

    Update 2013-03-31: More examples of setting the property bag

    I got a comment in the blog about having more examples for various approaches (like CSOM/JS and not only PowerShell). Sure enough, here comes some simple samples for that.

    Setting the BING MAPS KEY using JavaScript Client Object Model on a specific Web

    var ctx = new SP.ClientContext.get_current();
    var web = ctx.get_site().get_rootWeb();
    var webProperties = web.get_allProperties();
    webProperties.set_item("BING_MAPS_KEY", "FFDDuWzmanbiqeF7Ftke68y4K8vtU1vDYFEWg1J5J4o2x4LEKqJzjDajZ0XQKpFG");
    // Shoot'em queries away captain!
    ctx.executeQueryAsync(function (){
    },function () {
        alert("Fail.. Doh!");

    Setting the BING MAPS KEY using .NET Client Object Model on a specific Web

    // Set the Url to the site, or get the current context. Choose your own approach here..
    var ctx = new ClientContext("http://tozit-sp:2015/");
    var siteCollection = ctx.Site;
    var web = siteCollection.RootWeb;
    ctx.Load(web, w => w.AllProperties);
    var allProperties = web.AllProperties;
    // Set the Bing Maps Key property
    web.AllProperties["BING_MAPS_KEY"] = "FFDDuWzmanbiqeF7Ftke68y4K8vtU1vDYFEWg1J5J4o2x4LEKqJzjDajZ0XQKpFG";
    ctx.Load(web, w => w.AllProperties);

    So that’s pretty straight forward. Once you’ve set the Bing Maps Key, you can see that the text in your maps has disappeared and you can now start utilizing the full potential of the Geolocation field.


    The Geolocation field is pretty slick to play around with. It leaves a few holes in terms of functionality that we’ll have to fill ourselves – but of course that depends on our business requirements. One example is that I rarely want to enter the coordinates into the Geolocation field myself, but I might just want to do a search and select a location which is the added and the coordinates populated into the field automatically, or use the (built in) functionality of “Use my location” – good thing we’ve got developers to fine-tune this bits and pieces :-)


    Author: Tobias Zimmergren | | @zimmergren


    Recently someone asked me about how to attack the major pain of upgrading their custom coded projects and solution from SharePoint 2010 to SharePoint 2013. Given that question and my experiences thus far I’ll try to pinpoint the most important things to consider when upgrading. There’s TONS of things you need to consider, but we’ll touch on the most fundamental things to consider just to get up and running. After that I’m sure you’ll bump into a few more issues, and then you’re on your way ;-)

    Keep your developer tools updated

    Visual Studio 2012 Update 1

    The first step is to make sure that you’re running the latest version of Visual Studio 2012. As of this writing that means you should be running Visual Studio 2012 and then apply the Visual Studio 2012 Update 1 pack (vsupdate_KB2707250.exe) if it isn’t installed on your system already.

    Download Visual Studio 2012 Update 1 here:

    Visual Studio 2012 Office Developer Tools

    The second step is to make sure you’ve got the latest developer tools for SharePoint installed. The package comes as an update in the Web Platform Installer which I urge you to have installed on your dev-box if you for some reason don’t already have it installed.

    So, launch the Web Platform Installer and make a quick search for “SharePoint” and you should see the new developer tools there (note that the release date is 2013-02-26, which is the release date for the RTM tools):


    Select the “Microsoft Office Developer Tools for Visual Studio 2012” and click “Add“. It will ask you to install a bunch of prerequisites which you should accept if you want to continue:


    Let the tools be installed and the components updated. This could take anywhere from a few seconds to a few Microsoft minutes. It took about 5 minutes on my current development environment, so that wasn’t too bad.


    Once the tools are installed, you are ready to get going with your upgrade.

    Open your projects/solutions after upgrading Visual Studio 2012 with the latest tools

    When the tools have been successfully installed and you open your solution the new tools will be in effect. If you’re opening a SharePoint 2010 project that you wish to upgrade to SharePoint 2013, you’ll get a dialog saying “Do you want to upgrade <project name> to a SharePoint 2013 solution? Once the upgrade is complete, the solution can’t be deployed to SharePoint 2010. Do you want to continue?”


    Hit Yes if you get this dialog. If you want to upgrade your project to SharePoint 2013.

    Once the project is loaded and have made all the necessary changes to the project files (which it now does automatically, unlike in the beta/preview tools where we had to do some manual tweaks), you should get an upgrade report telling you how things went. Hopefully there’ll be no Errors, only warnings and Messages.


    If you check out the assembly references in your project that are pointing to any SharePoint assemblies, note that they have automatically been updated to the correct version of the SharePoint 2013 assembly:


    Additional notes

    If you upgraded without the latest version of the developer tools you only had the option to launch your projects in 2013-mode if you manually went into the .csproj file to modify (or add if one of them were missing) the following two lines:


    This was true when the developer tools were in Preview/beta. But now when they’re released to RTM you shouldn’t be doing those manual hacks anymore. Trust the tools!

    Tip: Some general code updates that may be required

    When you deploy artifacts to the SharePointRoot folder in SharePoint 2013 they are now deployed to the /15 folder instead of the older /14 folder. SharePoint 2013 has a much better support for upgrade scenarios than previous versions of SharePoint (2010) which is why we’ve got the double hives. So, if you want to properly upgrade your solution you should also make sure to replace all the paths in your project from:

    Path to the Images folder

    From the images folder:




    Path to the layouts folder

    Make sure to not forget the general layouts path:




    Path to the ControlTemplates folder

    Also make sure to replace the following paths:




    Well you get the general idea here.. Should you find paths pointing to your old 14-hive instead of the new 15-folder, make sure to change the path/url.


    As always, you will not be an efficient developer without the proper tools at hand to make the daily tasks easier.

    If you enjoyed using CKS Dev for SharePoint 2010 development, you’ll still be able to enjoy some of that awesomeness by simply installing the CKS Dev tools for SharePoint 2010 on your Visual Studio 2012/SP2013 box. They seem to work fine on Visual Studio 2012 as well – so until there’s a proper update of the tools, you’ll be able to knacker some of your code with the old tools.

    Do note that there’s certain features of the CKS Dev that doesn’t work fully, so should you encounter issues with the tool in various scenarios that’ll most likely be because they’re not engineered for Visual Studio 2012 (yet).


    After you’ve done enough tinkering you’ll be ready to rock this baby up on SharePoint 2013.


    Author: Tobias Zimmergren | | @zimmergren


    In this post we’ll take a quick look at some of the new DelegateControls I’ve discovered for SharePoint 2013 and how you can replace or add information to your new master pages using these new controls, without modifying the master pages. This is done exactly the same way as you would do it back in the 2010 projects (and 2007), the only addition in this case are a few new controls that we’ll investigate.

    New DelegateControls

    Searching through the main master page, Seattle.master, I’ve found these three new DelegateControls:

    • PromotedActions
    • SuiteBarBrandingDelegate
    • SuiteLinksDelegate

    So let’s take a look at where these controls are placed on the Master page and how we can replace them.

    PromotedActions Delegate Control

    The PromotedActions delegate control allows you to add your own content to the following area on a SharePoint site in the top-right section of the page:


    An example of adding an additional link may look like this:


    So what does the files look like for these parts of the project?


    <?xml version="1.0" encoding="utf-8"?>
    <Elements xmlns="">
      <!-- DelegateControl reference to the PromotedActions Delegate Control -->
      <Control ControlSrc="/_controltemplates/15/Zimmergren.DelegateControls/PromotedAction.ascx"
               Sequence="1" />

    PromotedActions.aspx (User Control)

    <!-- Note: I've removed the actual Facebook-logic from this snippet for easier overview of the structure. -->
    <a title="Share on Facebook" class="ms-promotedActionButton" style="display: inline-block;" href="#">
        <span class="s4-clust ms-promotedActionButton-icon" style="width: 16px; height: 16px; overflow: hidden; display: inline-block; position: relative;">
            <img style="top: 0px; position: absolute;" alt="Share" src="/_layouts/15/images/Zimmergren.DelegateControls/facebookshare.png"/>
        <span class="ms-promotedActionButton-text">Post on Facebook</span>

    SuiteBarBrandingDelegate Delegate Control

    This DelegateControl will allow you to override the content that is displayed in the top-left corner of every site. Normally, there’s a text reading "SharePoint" like this:


    If we override this control we can easily replace the content here. For example, most people would probably like to add either a logo or at least make the link clickable so you can return to your Site Collection root web. Let’s take a look at what it can look like if we’ve customized it (this is also a clickable logo):


    So what does the files look like for this project?


    <?xml version="1.0" encoding="utf-8"?>
    <Elements xmlns="">
      <!-- SuiteBarBrandingDelegate (the top-left "SharePoint" text on a page) -->
      <Control ControlSrc="/_controltemplates/15/Zimmergren.DelegateControls/SuiteBarBrandingDelegate.ascx"
               Sequence="1" />

    SuiteBarBrandingDelegate.ascx (User Control)

    This is the only content in my User Control markup:

    <div class="ms-core-brandingText" id="BrandingTextControl" runat="server" /> (User Control Code Behind)

    protected void Page_Load(object sender, EventArgs e)
        BrandingTextControl.Controls.Add(new Literal
            Text = string.Format("<a href='{0}'><img src='{1}' alt='{2}' /></a>", 

    SuiteLinksDelegate Delegate Control

    The SuiteLinksDelegate control will allow us to modify the default links, and to add our own links, in the "suit links" section:


    By adding a custom link to the collection of controls, it can perhaps look like this:


    What does the project files look like for modifying the SuiteLinksDelegate? Well, here’s an example:


    <?xml version="1.0" encoding="utf-8"?>
    <Elements xmlns="">
      <!-- DelegateControl reference to the SuiteLinksDelegate Delegate Control -->
      <Control ControlSrc="/_controltemplates/15/Zimmergren.DelegateControls/SuiteLinksDelegate.ascx"
               Sequence="1" />


    SuiteLinksDelegate.aspx.cs (User Control Code Behind)

    public partial class SuiteLinksDelegate : MySuiteLinksUserControl
        protected override void Render(HtmlTextWriter writer)
            writer.Write(".ms-core-suiteLinkList {display: inline-block;}");
            writer.AddAttribute(HtmlTextWriterAttribute.Class, "ms-core-suiteLinkList");
            // The true/false parameter means if it should be the active link or not - since I'm shooting off this to an external URL, it will never be active..
            RenderSuiteLink(writer, "", "Time Report", "ReportYourTimeAwesomeness", false);

    Solution overview

    For reference: I’ve structured the project in a way where I’ve put all the changes into one single Elements.xml file and they’re activated through a Site Scoped feature called DelegateControls. The solution is a Farm solution and all artifacts required are deployed through this package.



    In this post we’ve looked at how we can customize some of the areas in a SharePoint site without using master page customizations. We’ve used the good-old approach of hooking up a few Delegate Control overrides to our site collection. Given the approach of Delegate Controls, we can easily just de-activate the feature and all our changes are gone. Simple as that.

    In SharePoint 2013 we can still do Delegate Control overrides just like we did back in 2007 and 2010 projects, and it’s still pretty slick. I haven’t investigated any other master pages other than the Seattle.master right now – perhaps there’s more new delegate controls somewhere else. Let’s find out..


    Author: Tobias Zimmergren | | @zimmergren


    In one of my previous posts I talked about "Using the SPField.JSLink property to change the way your field is rendered in SharePoint 2013". That article talks about how we can set the JSLink property in our SharePoint solutions and how we easily can change the rendering of a field in any list view.

    It’s pretty slick and I’ve already had one client make use of the functionality in their pilot SharePoint 2013 farm. However I got a comment from John Lui asking about what the performance would be like when executing the same iterative code over thousands of items. Since I hadn’t done any real tests with this myself, I thought it’d be a good time to try and pinpoint and measure if the client-side load times differ while using the JSLink property.


    The tests will be performed WITH the JSLink property set and then all tests will be executed WITHOUT the JSLink property set.

    I’ve set up my scenario with various views on the same list. The total item count of the list is 5000 items, but we’ll base our tests on the limit of our views:

    Test 1  
    View Limit 100
    Test 2  
    View Limit 500

    The results will be output with a difference between using the JSLink property and not using it. Should be fun.


    I’be been using these tools for measuring the performance on the client:

    Fiddler4, YSlow, IE Developer Tools

    The code that will be executed will be the same JavaScript code as I had in my previous article.

    SharePoint 2013 browser compatibility

    If you intend to measure performance on various browsers, make sure you’ve pinned down what browsers are actually supported by SharePoint 2013. The following versions of browsers are supported:

    • IE 10, IE 9, IE 8
    • Chrome
    • Safari
    • Firefox

    Let’s start measuring

    Let’s start by taking a look at how I’ve done my tests and what the results were.

    Testing methods

    Each test was executed 100 times and the loading time result I’ve used for each test is the average of the 100 attempts. These tests are executed in a virtual environments so obviously the exact timings will differ from your environments – what’s mostly interesting right here though is the relative difference between having JSLink set and not set when rendering a list view, so that’s what we’ll focus on.

    I’ve performed these tests on IE 10 and the latest version of Firefox. Since older browsers may handle scripts in a less efficient way than these two versions of the browsers, you may experience different results when using for example IE 8.

    Results overview

    SharePoint 2013 is pretty darn fantastic in its way that it renders the contents and pages. The measurements I’ve done here are based on the entire page and all contents to load. The chrome of the page (Navigation/Headers etc) loads instantly, literally in less than 25ms but the entire page takes longer since the content rendered for the list view will take considerably longer. Here’s the output…

    Using 100 Item Limit in the View


    Difference: 969 milliseconds


    There’s not really much to argue about with the default 100-item limit. There’s a difference on almost one second, which is pretty bad to be honest. I would definitely revise these scripts and optimize the performance if I wanted quicker load times. However, if I changed the scripts and removed the rendering of images and used plain text instead, there was very little difference. So I guess it comes down to what you actually put into those scripts and how you optimize your JavaScript.

    Using 500 Item Limit in the View


    Difference: 529 milliseconds


    The load times are naturally longer when returning 500 items, but the difference was smaller on a larger result set. I also performed the same tests using 1000 item limit in the view, and the difference per page load was between 500ms to 1000ms, essentially the same as these two tests. If your page takes 7-8 seconds to load without the usage of JS Link like these samples did in the virtual environments, I’d probably focus on fixing that before being too concerned about the impact the JS Link rendering process will have on your page. However, be advised that if you put more advanced logic into the scripts it may very well be worth your while to draft up some tests for it.

    Things to take into consideration

    • The sample script here only replaces some strings based on the context object and replaces with an image. No heavy operations.
    • Replacing strings with images took a considerably longer time to render than just replacing text and render. Consider the code you put in your script and make sure you’ve optimized it for performance and scope your variables properly and so on.
    • Take your time to learn proper JavaScript practices. It’ll be worth it in the end if you’re going to do a lot of client side rendering stuff down the road.
    • If you’ve got access to Scot Hillier’s session from SPC12, review them!


    Its not very often I’ve seen anyone use 1000 items as the item limit per view in an ordinary List View Web Part. Most of my existing configurations are using 100 or less (most likely around 30) items per page for optimal performance – however should you have larger views you should of course consider the impact the rendering will have if you decide to hook up your own custom client side rendering awesomeness.

    You’ll notice the biggest difference between page load times if you’ve got a smaller item row limit in your view, simply because it looks like using the custom JS link property adds between 500 – 1000 milliseconds whether if I’m returning 100 items, 500 items or 2500 items in my view. Worth considering.

    With that said – It’s a pretty cool feature and I’ve already seen a lot of more use cases for some of my clients to utilize these types of customizations. It’s a SUPER-AWESOME way to customize the way your list renders data instead of converting your List View Web Part (or Xslt List View Web Parts and so on) into Data View Web Parts like some people did with SharePoint Destroyer.. Err.. SharePoint Designer. For me as a developer/it/farm admin guy this will make upgrades easier as well (hopefully) as the list itself will be less customized, and only load an external script in order to make the customizations appear. Obviously I’m hoping for all scripts to end up in your code repositories with revision history, fully documented and so on – but then again I do like to dream :-)


    SP 2013: Searching in SharePoint 2013 using the REST new API’s

    December 26th, 2012 by Tobias Zimmergren

    Author: Tobias Zimmergren | | @zimmergren


    Search has always been a great way to create custom solutions that aggregate and finds information in SharePoint. With SharePoint 2013, the search capabilities are heavily invested in and we see a lot of new ways to perform our searches. In this post I’ll show a simple example of how you can utilize the REST Search API’s in SharePoint 2013 to perform a search.

    REST Search in SharePoint 2013

    So in order to get started, we’ll need to have an ASPX Page containing some simple markup and a javascript file where we’ll put our functions to be executed. The approach mentioned in this post is also compatible with SharePoint Apps, should you decide to develop an App that relys on Search. In my example I’ve created a custom Page which loads my jQuery and JavaScript files, and I’m deploying those files using a Module to the SiteAssets library.

    Preview of the simple solution


    Creating a Search Application using REST Search Api’s

    Let’s examine how you can construct your search queries using REST formatting and by simply changing the URL to take in the proper query strings.

    Formatting the Url

    By formatting the Url properly you can retrieve search results pretty easily using REST.

    Query with querytext

    If you simply want to return all results with no limits or filters from a search, shoot out this formatted url:’Awesome’

    will yield the following result:


    Essentially we’re getting a bunch of XML returned from the query which we then have to parse and handle somehow. We can then use the result of this query in our application in whatever fashion we want. Let’s see what a very simple application could look like, utilizing the SharePoint 2013 rest search api’s.

    ASP.NET Markup Snippet

    As we can see in the following code snippet, we’re simply loading a few jQuery and JavaScript files that we require and we define a Search Box and a Button for controlling our little Search application.

    <!-- Load jQuery 1.8.3 -->
    <script type="text/javascript" src="/SiteAssets/ScriptArtifacts/jquery-1.8.3.min.js"></script>
    <!-- Load our custom Rest Search script file -->
    <script type="text/javascript" src="/SiteAssets/ScriptArtifacts/RestSearch.js"></script>
    <!-- Add a Text Box to use as a search box -->
    <input type="text" value="Awesome" id="searchBox" />
    <!-- Add a button that will execute the search -->
    <input type="button" value="Search" onclick="executeSearch()" />
    <div id="searchResults"></div>

    JavaScript logic (RestSearch.js)

    I’ve added a file to the project called RestSearch.js, which is a custom javascript file containing the following code which will perform an ajax request to SharePoint using the Search API’s:

    // in reality we should put this inside our own namespace, but this is just a sample.
    var context;
    var web;
    var user;
    // Called from the ASPX Page
    function executeSearch()
        var query = $("#searchBox").val();
        SPSearchResults =
            element: '',
            url: '',
            init: function(element) 
                SPSearchResults.element = element;
                SPSearchResults.url = _spPageContextInfo.webAbsoluteUrl + "/_api/search/query?querytext='" + query + "'";
            load: function() 
                        url: SPSearchResults.url,
                        method: "GET",
                                "accept": "application/json;odata=verbose",
                        success: SPSearchResults.onSuccess,
                        error: SPSearchResults.onError
            onSuccess: function (data)
                var results = data.d.query.PrimaryQueryResult.RelevantResults.Table.Rows.results;
                var html = "<div class='results'>";
                for (var i = 0; i < results.length; i++)
                    var d = new Date(results[i].Cells.results[8].Value);
                    var currentDate = d.getFullYear() + "-" + d.getMonth() + "-" + d.getDate() + " " + d.getHours() + ":" + d.getMinutes();
                    html += "<div class='result-row' style='padding-bottom:5px; border-bottom: 1px solid #c0c0c0;'>";
                    var clickableLink = "<a href='" + results[i].Cells.results[6].Value + "'>" + results[i].Cells.results[3].Value + "</a><br/><span>Type: " + results[i].Cells.results[17].Value  + "</span><br/><span>Modified: " + currentDate + "</span>";
                    html += clickableLink;
                    html += "</div>";
                html += "</div>";
            onError: function (err) {
                $("#searchResults").html("<h3>An error occured</h3><br/>" + JSON.stringify(err));
        // Call our Init-function
        // Call our Load-function which will post the actual query

    The aforementioned script shows some simple javascript that will call the Search REST API (the "_api/…" part of the query) and then return the results in our html markup. Simple as that.


    By utilizing the REST Search API we can very quickly and easily create an application that searches in SharePoint 2013.

    This can be implemened in SharePoint Apps, Sandboxed Solutions or Farm Solutions. Whatever is your preference and requirements, the Search API’s should be easy enough to play around with.


    Author: Tobias Zimmergren | | @zimmergren


    Recently I’ve had the pleasure (and adventure..) of upgrading a few SharePoint 2010 solutions to SharePoint 2013. One of the things that come up in literally every project I’m involved in, is the ability to quickly and easily change how a list is rendered. More specifically how the fields in that list should be displayed.

    Luckily in SharePoint 2013, Microsoft have extended the SPField with a new proprety called JSLink which is a JavaScript Link property. There’s a JSLink property on the SPField class as well as a "JS Link" property on for example List View Web Parts. If we specify this property and point to a custom JavaScript file we can have SharePoint render our fields in a certain way. We can also tell for example our List View Web Parts to point to a specific JavaScript file, so they’re also extended with the JS Link property.

    In this blog post I’ll briefly explain what the "JS Link" for a List View Web Part can look like and how you can set the property using PowerShell, C# and in the UI. I’ll also mention ways to set the SPField JSLink property, should you want to use that.

    Final results

    If you follow along with this article you should be able to render a similar result to this view in a normal Task List in SharePoint 2013:


    You can see that the only modification I’ve made right now is to display an icon displaying the importance of the task. Red icons for High Priority and Blue and Yellow for Low and Medium.

    Since it’s all based on JavaScript and we’re fully in control of the rendering, we could also change the rendering to look something like this, should we want to:


    As you’ve may have noticed I haven’t put down a lot of effort on styling these elemenbts – but you could easily put some nicer styling on these elements through the JavaScript either by hooking up a CSS file or by using inline/embedded styles.

    Configuring the JSLink properties

    Okay all of what just happened sounds cool and all. But where do I actually configure this property?

    Set the JS Link property on a List View Web Part

    If you just want to modify an existing list with a custom rendering template, you can specify the JSLink property of any existing list by modifying it’s Web Part Properties and configure the "JS Link" property, like this:


    If you configure the aforementioned property on the List View Web Part your list will automatically load your custom JavaScript file upon rendering.

    Set the SPField.JSLink property in the Field XML definition

    If you are creating your own field, you can modify the Field XML and have the property set through the definition like this:

    <?xml version="1.0" encoding="utf-8"?>
    <Elements xmlns="">  
           Name="My Awesome Sample Field"
           DisplayName="My Awesome Sample Field"
           Group="Blog Sample Columns">

    Set the SPField.JSLink property using the Server-Side Object Model

    Simply set the SPField.JSLink property like this. Please note that this code was executed from a Console Application, hence the instantiation of a new SPSite object:

    using (SPSite site = new SPSite("http://tozit-sp:2015"))
        SPWeb web = site.RootWeb;
        SPField taskPriorityField = web.Fields["Priority"];
        taskPriorityField.JSLink = "/_layouts/15/Zimmergren.JSLinkSample/AwesomeFile.js";

    Set the SPField.JSLink property using PowerShell

    If you’re the PowerShell-kind-of-guy-or-gal (and you should be, if you’re working with SharePoint…) then you may find the following simple snippets interesting, as they should come in handy soon enough.

    PowerShell: Configure the JSLink property of an SPField

    $web = Get-SPWeb http://tozit-sp:2015
    $field = $web.Fields["Priority"]
    $field.JSLink = "/_layouts/15/Zimmergren.JSLinkSample/Awesomeness.js"

    PowerShell: Configure the JSLink property of a Web Part

    Note that this is what I’ve been doing in the sample code later on – I’m not setting a custom JSLink for the actual SPField, I’m setting it for the List View Web Part.

    $web = Get-SPWeb http://tozit-sp:2015
    $webPartPage = "/Lists/Sample%20Tasks/AllItems.aspx"
    $file = $web.GetFile($webPartPage)
    $webPartManager = $web.GetLimitedWebPartManager($webPartPage, [System.Web.UI.WebControls.WebParts.Pers
    $webpart = $webPartManager.WebParts[0]
    $webpart.JSLink = "/_layouts/15/Zimmergren.JSLinkSample/Awesomeness.js"
    $file.CheckIn("Awesomeness has been delivered")

    As you can see in the PowerShell snippet above we’re picking out a specific page (a Web Part page in a list in my case) and picks out the first Web Part (since I know I only have one Web Part on my page) and set the JS Link property there. This will result in the Web Part getting the proper link set and can now utilize the code in your custom javascript file to render the results.

    So what does the JS Link JavaScript logic look like?

    Okay, so I’ve seen a few ways to modify the JS Link property of a list or a field. But we still haven’t looked at how the actual JavaScript works or what it can look like. So let’s take a quick look at what it could look like for a List View Web Part rendering our items:

    // Create a namespace for our functions so we don't collide with anything else
    var zimmergrenSample = zimmergrenSample || {};
    // Create a function for customizing the Field Rendering of our fields
    zimmergrenSample.CustomizeFieldRendering = function ()
        var fieldJsLinkOverride = {};
        fieldJsLinkOverride.Templates = {};
        fieldJsLinkOverride.Templates.Fields =
            // Make sure the Priority field view gets hooked up to the GetPriorityFieldIcon method defined below
            'Priority': { 'View': zimmergrenSample.GetPriorityFieldIcon }
        // Register the rendering template
    // Create a function for getting the Priority Field Icon value (called from the first method)
    zimmergrenSample.GetPriorityFieldIcon = function (ctx) {
        var priority = ctx.CurrentItem.Priority;
        // In the following section we simply determine what the rendered html output should be. In my case I'm setting an icon.
        if (priority.indexOf("(1) High") != -1) {
            //return "<div style='background-color: #FFB5B5; width: 100%; display: block; border: 2px solid #DE0000; padding-left: 2px;'>" + priority + "</div>";
            return "<img src='/_layouts/15/images/Zimmergren.JSLinkSample/HighPrioritySmall.png' />&nbsp;" + priority;
        if (priority.indexOf("(2) Normal") != -1) {
            //return "<div style='background-color: #FFFFB5; width: 100%; display: block; border: 2px solid #DEDE00; padding-left: 2px;'>" + priority + "</div>";
            return "<img src='/_layouts/15/images/Zimmergren.JSLinkSample/MediumPrioritySmall.png' />&nbsp;" +priority;
        if (priority.indexOf("(3) Low") != -1) {
            //return "<div style='background-color: #B5BBFF; width: 100%; display: block; border: 2px solid #2500DE; padding-left: 2px;'>" + priority + "</div>";
            return "<img src='/_layouts/15/images/Zimmergren.JSLinkSample/LowPrioritySmall.png' />&nbsp;" + priority;
        return ctx.CurrentItem.Priority;
    // Call the function. 
    // We could've used a self-executing function as well but I think this simplifies the example

    With the above script, we’ve simply told our field (Priority) that when it’s rendered it should look format the output HTML according to the contents in my methods. In this case we’re simply making a very simple replacement of text with image to visually indicate the importance of the task.

    For examples of how you can construct your SPField.SPLink JavaScript, head on over to Dave Mann’s blog and check it out. Great info!


    With a few simple steps (essentially just a JavaScript file and a property on the LVWP or Field) we’ve changed how a list is rendering its data. I’d say that the sky is the limit and I’ve already had one of my clients implement a solution using a custom JS Link to format a set of specific lists they have. What’s even better is that it’s so simple to do, we don’t even have to do a deployment of a new package if we don’t want to.

    The reason I’ve chosen to do a Farm Solution (hence the /_layouts paths you see in the url’s) is that most of my clients still run Farm Solutions – and will be running them for a long time to come. And it wraps up a nice package for us to deploy globally in the farm, and then simply have a quick PowerShell script change the properties of the LVWP’s we want to modify and that’ll be that. Easy as 1-2-3.



    As most if not all of you already know, SharePoint 2013 and Office 2013 has been released to preview/beta and is available for download from Microsoft’s download centers. In this article I will briefly introduce some exciting changes that has been made to the SharePoint 2013 Business Connectivity Services framework. I’ve written a bunch of articles on BCS for SharePoint 2010, and now it’s time to continue that track and introduce the new features available in SharePoint 2013.

    Please note that this article is written for SharePoint 2013 Preview, and for the final version of SharePoint some details may have changed

    1. SharePoint 2013: Business Connectivity Services – Introduction
    2. SharePoint 2013: Business Connectivity Services – Consuming OData in BCS Using an App External Content Type
    3. SharePoint 2013: Business Connectivity Services – Talking to your external lists using REST
    4. SharePoint 2013: Business Connectivity Services – Client Object Model
    5. SharePoint 2013: Business Connectivity Services – Events and Alerts

    SharePoint 2013 – BCS with REST

    In this article we’ll be taking a further look on the new Business Connectivity Services changes and additions in SharePoint 2013. I want to take a quick look and introduce how REST (Representational State Transfer) can be used and also how the Client Object Model can be utilized to communicate with your External Lists and BCS Entities.

    So without further delays, let’s dig into the fantastic world of BCS and CSA (Client Side Awesomeness).

    Important: The project type in this project, as mentioned in the post where we started building our sample, is a SharePoint-hosted app.

    Business Connectivity Services and REST

    Utilizing REST in BCS in your SharePoint 2013 environments isn’t really that big of a deal. It’s pretty straight forward. The first thing you should do is take a look at the following link which references the MSDN article about getting started with REST in SharePoint 2013.

    MSDN Reference:

    So now that we know that REST is all about, we’re going to look at some code that will utilize REST to retrieve some data. In this sample I’ll continue to build on the solution I created in the previous article.

    Final result will look like this

    When our first snippet of code will be done, it’ll look something like this where our (in this case) App (page) is loaded:


    So what the code will do is to pull out the images and links for the videos in the Telerik.Tv OData data source that we created in the previous article, and we’ll be doing this using the REST API’s.

    In one big snippet, here’s what the REST call looks like in my App.js:

    var context;
    var web;
    var user;
    function sharePointReady()
        var requestUri = _spPageContextInfo.webAbsoluteUrl + "/_api/lists/getbytitle('Video')/items";
        jqxhr = $.getJSON(requestUri, null, onSuccessfullJSONCall);
    function onSuccessfullJSONCall(data) {
        var outputHtml = "";
        var results = data.d.results;
        var counter = 0;
        for (var i = 0; i < results.length; i++) {
            outputHtml += "<img src='" + results[i].ImageUrl + "' class='brick-image' />";
            if (counter >= 4) {
                outputHtml += "<br/>";
                counter = 0;
    function onErrorInJSONCall(err) {
        $("#message").text("Unawesome Error: " + JSON.stringify(err));

    As you can see in the aforementioned code snippet, the calls to the REST API’s are pretty straight forward and I’m only making a quick call to fetch the data asynchronously using the $.getJSON() method.

    Lets break it down in sections..

    Script part 1: sharePointReady() method call

    Since our project type (a SharePoint-hosted App) contains a stub for the Default.aspx page and the App.js files – a method called sharePointReady is defined in the App.js file and in the Default.aspx you have the following block which initiates the call to this method upon loading all other required awesome things:

        <!-- The following script runs when the DOM is ready. The inline code uses a SharePoint feature to ensure -->
        <!-- The SharePoint script file sp.js is loaded and will then execute the sharePointReady() function in App.js -->
        <script type="text/javascript">
            $(document).ready(function () {
                SP.SOD.executeFunc('sp.js', 'SP.ClientContext', function () { sharePointReady(); });

    (Optionally, you can put this code-block in the actual App.js file as well if you’d like – it’s up to you)

    When SharePoint is done loading all the required stuff that it needs to function (sp.js), this method is executed. In this sample, I’m making a simple JSON call to the REST API using the syntax http://url/_api/lists/getbytitle(‘ListTitle’)/items which will get all list items in the list named Video:

    function sharePointReady()
        var requestUri = _spPageContextInfo.webAbsoluteUrl + "/_api/lists/getbytitle('Video')/items";
        jqxhr = $.getJSON(requestUri, null, onSuccessfullJSONCall);

    Script part 2: On successful JSON callback, the following block is executed

    We’re executing the onSuccessfullJSONCall() when our previous call is successful, and it’ll basically just parse the JSON result and push the items out in a simple HTML structure:

    function onSuccessfullJSONCall(data) {
        var outputHtml = "";
        var results = data.d.results;
        var counter = 0;
        for (var i = 0; i < results.length; i++) {
            outputHtml += "<img src='" + results[i].ImageUrl + "' class='brick-image' />";
            if (counter >= 4) {
                outputHtml += "<br/>";
                counter = 0;

    Script part 3: In case of unawesomeness (failure)

    In case the request failed, we’ll be handling that somehow in this method. In this case we’ll just be printing out the error message very quickly to the user:

    function onErrorInJSONCall(err) {
        $("#message").text("Unawesome Error: " + JSON.stringify(err));


    In this article we took a very quick look at how to get that first REST call working with SharePoint 2013 against our External List called “video”. With the returned result in JSON, we’re parsing it out and simply rendering the result in a more reader-friendly manner as pictures in a simple HTML grid.

    So that’ll be it for the REST calls for now. It should get you started and set-up for creating a very simple application that utilizes REST for retrieving data from SharePoint.

    More details on working with the REST API’s in SharePoint 2013 will follow later, including how to perform cross-domain queries.


    Author: Tobias Zimmergren | | @zimmergren


    As most if not all of you already know, SharePoint 2013 and Office 2013 has been released to preview/beta and is available for download from Microsoft’s download centers. In this article I will briefly introduce some exciting changes that has been made to the SharePoint 2013 Business Connectivity Services framework. I’ve written a bunch of articles on BCS for SharePoint 2010, and now it’s time to continue that track and introduce the new features available in SharePoint 2013.

    Please note that this article is written for SharePoint 2013 Preview, and for the final version of SharePoint some details may have changed

    1. SharePoint 2013: Business Connectivity Services – Introduction
    2. SharePoint 2013: Business Connectivity Services – Consuming OData in BCS Using an App External Content Type
    3. SharePoint 2013: Business Connectivity Services – Talking to your external lists using REST
    4. SharePoint 2013: Business Connectivity Services – Client Object Model
    5. SharePoint 2013: Business Connectivity Services – Events and Alerts

    SharePoint 2013 – BCS with OData

    In this specific article we’ll be looking on how you can consume data from an Open Data protocol (OData) data source. Tag along for the ride!

    First of all, tell me what OData is…!?

    Right, so OData is a  Web protocol for performing CRUD (Create Read Update and Delete) operations and utilizes technologies like HTTP, ATOM and JSON.

    As quoted from the OData Web Site:

    The Open Data Protocol (OData) is a Web protocol for querying and updating data that provides a way to unlock your data and free it from silos that exist in applications today.
    OData does this by applying and building upon Web technologies such as HTTP, Atom Publishing Protocol (AtomPub) and JSON to provide access to information from a variety of applications, services, and stores.

    We can have lengthy discussions about how awesome (or unawesome) OData is but in this article we’ll be focusing on consuming OData data sources in SharePoint 2013 through Business Connectivity Services, one of my favorite parts of SharePoint.

    Launch Visual Studio and get started!

    So, as you probably could tell by the title of this post – you should now open Visual Studio 2012 :-)

    Create the project

    Choose the project type App for SharePoint 2013:

    SharePoint 2013 bcs odata app

    The Wizard that launches will give you a few choices which we’ll discuss in another article. In this article I’ve selected the “SharePoint Hosted” alternative, as you can see below:

    SharePoint 2013 bcs odata app

    This should get you setup with the initial project structure, and you should now have a project that looks something like this:

    SharePoint 2013 bcs odata app project

    Add an external content type

    Now that we’ve created our initial project, we should add a new external content type. If you right-click your project and choose Add, you can see that there’s a new menu item called “Content Types for an External Data Source…“. Click it:

    SharePoint 2013 bcs content type

    In the following wizard, you can enter the service URL for the OData provider you’d like to consume. In my example I’ve used the public OData service:

    Telerik OData in SharePoint 2013

    In the next step in the wizard, you get to select for which data entities you want to generate external content types. Choose the entities you’d like to work with and continue by pressing Finish:
    Please note that you should leave the “Create list instances for the selected data entries (except Service Operations).” checked so the tools can create your external list automatically!

    SharePoint 2013 BCS Entity

    After we’ve completed this step, we can see a few additions in our project that Visual Studio 2012 has been so kind to help us out with.

    A Telerik Video external content type with it’s associated ListInstances (one per entity, in my case only one for Video) that it was also kind enough to create for us since I had the checkbox in the previous dialog ticked:


    Looking in your Feature explorer, you can see that the default Feature now contains your artifacts along with the newly created List Instance and External Content Type:


    In the newly created List Instances, the following XML has been generated for us:

    <?xml version="1.0" encoding="utf-8"?>
    <Elements xmlns="">
      <ListInstance Url="Lists/Video" Description="Video" OnQuickLaunch="TRUE" Title="Video">
          <Property Name="LobSystemInstance" Value="Telerik OData" />
          <Property Name="EntityNamespace" Value="TelerikTvDataServiceDataServiceModels" />
          <Property Name="Entity" Value="Video" />
          <Property Name="SpecificFinder" Value="ReadSpecificVideo" />
          <Property Name="MetadataCatalogFileName" Value="BDCMetadata.bdcm" />

    As you can see, the ListInstance DataSource node contains information about connecting to our newly created BCS entity. Perfect.

    Just to make sure that we can deploy our solution, hit F5 and make sure that VS2012 deploys your project properly

    Validate that your application works

    Navigate to your site and validate that your new App is properly deployed and showing:

    SharePoint 2013 app

    Click the app and make sure you can see the result of your very basic and “hello world”-ish app:


    Display your new external list!

    Do you remember in one of the previous steps that I mentioned that you should leave the checkbox ticked in a dialog, saying “Create list instances for the selected data entries (except Service Operations).”? Well the reason for that is that we want Visual Studio 2012 tools to create this list for us so we don’t have to do that ourselves.

    With the newly deployed BCS external content type app, with it’s created list, you can access the content of the list on the following URL (you’ll need to check your Elements.xml for your ListInstance element in order to find out your url:


    Navigate to this URL and you’ll see this view:

    SharePoint 2013 BCS OData Telerik Tv

    So that’s pretty cool and easy right? Straight from the XML-formatted OData source we’ve pulled some info into our App in SharePoint.


    As you can see, working with SharePoint 2013 and the OData model with BCS is pretty straight forward. In this example I created an App for SharePoint utilizing the BCS framework to connect to an OData data source. I’m pretty impressed with the options this opens up for many of our existing SharePoint 2010 projects that sometime in the future will be upgraded to SharePoint 2013.

    In the next few posts we’ll dive more into the news around BCS for SharePoint 2013.