Recently I was challenged with the task to set the layout and content of a wiki page when a new page is added to a team site. As I'm used to work with SharePoint publishing the task sounded easy, but I was wrong.

With SharePoint it's easy to configure multiple zones for your SharePoint Web Application. For example you have a Publishing Web Site with two zones. After the content is published it'll also be available on the anonymous site and most of the URLs will be automatically translated to corresponding zone URL. There are however some places this is not the case.

In a previous post I have written about Using the people picker over a one-way trust. In this post I use STSADM commands as there are no other ways to configure this. A downside of the STSADM command is your domain password being visible on the command prompt in clear text for everybody to read, or to retrieve from the command line history. SharePoint 2010 introduces several cmdlets to replace the “old” STSADM commands. Microsoft has posted an overview of the STSADM to Windows PowerShell mapping. However the commands for configuring the people picker are not available.

With SharePoint 2010 the amount of databases on your SQL server has grown quite a bit. By default most of these databases have their recovery model set to 'FULL'. After some time you will discover you're running out of space.

When you have a SharePoint farm and you want to use accounts from another domain you need a partial (one-way) or a full (two-way) trust between those domain. A full trust is not always desirable and there your problem begins. After setting up the one-way trust you can authenticate with an account from the trusted domain, but the SharePoint People Picker doesn't show any accounts from this domain. It has been documented by others before, but as I ran into this recently I'll give my summary how I fixed this.

I wanted to use the new REST services in SharePoint 2010. But when I navigated to the ListData.svc service. I got the following error: “Could not load type 'System.Data.Services.Providers.IDataServiceUpdateProvider' from assembly 'System.Data.Services, Version=3.5.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089'.”

Now and again I come across code with hardcoded SharePoint IDs in it. Or scary loops matching a field, list or property name. SharePoint provides some classes containing the out of the box IDs, you only have to know they exist. I made an overview so nobody has to hardcode those pesky GUIDs, ContentTypeId's or property names.

As announced yesterday by Microsoft the Office 2010 products will be 64bit only. Well no surprise there, we already knew that. But they went even further: Windows Server 2008 and SQL Server on 64bit is a must for ensuring the best performance possible.