Wictor Wilen

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.

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

As usual a new version of a product has new requirements of all different kinds; especially when it comes to resource usage. With SharePoint 2013 there is no difference. The Hardware and Software requirements for SharePoint 2013 Preview is published and I thought I should walk through the new and updated requirements and compare them with SharePoint 2010. And also talk about some other key changes that you need to be aware of when planning your SharePoint 2013 installations.