Wictor Wilen

In todays episode of discovering awesome features in SharePoint 2013 we’re going to take a look at something really interesting, a feature that has been requested for years, a better management of end-user licensing in SharePoint. Even though this article contains a lot about SharePoint 2013 licensing I must make it very clear that nothing has yet been communicated from Microsoft regarding licensing on SharePoint 2013, and I am no expert on licensing and this is a Preview and this article must be considered as-is, things will and might change over the course of time. Remind me to go back to this article once SharePoint 2013 has gone gold. Microsoft has not made any statements about this and it might be so that you can forget about this article after RTM.

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

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

For some reason I get a lot of questions in my inbox about different SharePoint problems people have. I don’t mind, as long as they are polite. If I have time I do try to help out, but sometimes time is not enough. I’m sorry if I don’t answer all of them. But in order to help more people I have compiled a set of rules for SharePoint Troubleshooting. First rule of of SharePoint troubleshooting: You should always check the ULS logs The Trace Logs, often called ULS Logs, is where you find your answer to most of your problems. Always use ULS Viewer - if you do not have that tool in your kit, then you’re out on thin ice, period! Check the correlation id, search for exceptions and warnings. Things I almost always find the answer to here is “file not founds” (404) and “Access Denied”s (401). If you cannot find it immediately in the logs and you can re-create the problem, turn up the logging level to Verbose.

While fiddling, developing and configuring SharePoint 2010 I use the Service Application management a lot. This requires that you go to Central Administration, click on Manage service applications and then click on the service application that you need to configure or manage. I believe that managing the service applications are one of the most common tasks for people like me (I know some of you readers gets more fired up about the monitoring and upgrade parts of CA though).

I thought it was about time to bust one quite common myth in the SharePoint world (and there are lot of them!). This one in particular is interesting because it can cause you some interesting troubles, or at least some embarrassment. This is about that you can determine the current SharePoint [2010] version by checking the HTTP Response Header called MicrosoftSharePointTeamServices. So let’s bust that myth, or at least try!

Introduction In this small post I’m going to show you a really nice new feature to SharePoint 2013. It’s the Access Request and Invitations feature that allows you to easier manage access requests to your sites. Access Requests has been in the product for quite some time but required that your admins checked their e-mails once in a while. Using the new Share feature in SharePoint 2010 this process is so much easier. This has somewhat been blogged by the SharePoint team, but I would like to share my view of it.

Introduction SharePoint 2010 introduced the Service Application concept and that architecture model also includes the possibility to publish and consume service applications between farms. For instance you could have the Managed Metadata service application in one of your farms and use it in another farm. There are several interesting and valid scenarios for this and some of them include having dedicated Shared Services farms, that is a farm that’s only hosting service applications and not any content applications. If you have one of these farms, or farms that publishes or consumes service applications you are facing an interesting upgrade scenario when looking at SharePoint 2013. In this Visual Guide I’ll try to go through all the required steps for a successful upgrade to SharePoint 2013

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