Newly published SharePoint 2010 documents

Newly published SharePoint 2010 documents. I came across these through some of the tweets that I am following.

Thanks to Andreas Glaser for tweeting about these documents


Technical reference for Microsoft SharePoint Server 2010

Brief Description:

Technical information about the Microsoft SharePoint Server 2010.


This document includes technical information about the Microsoft SharePoint Server 2010 provider for Windows PowerShell and other helpful reference information about general settings, security, and tools.



Operations guide for Microsoft SharePoint Server 2010

Brief Description:

Operate and maintain servers, server farms, sites, and solutions in Microsoft SharePoint Server 2010.


This document describes how to operate and maintain your servers, server farms, sites, and solutions in Microsoft SharePoint Server 2010.



Operations guide for SharePoint Foundation 2010

Brief Description:

Operate and maintain your servers, server farms, sites, and solutions in Microsoft SharePoint Foundation 2010.


This document describes how to operate and maintain your servers, server farms, sites, and solutions in Microsoft SharePoint Foundation 2010.



Planning guide for Microsoft SharePoint Server 2010

Brief Description:

Information and guidelines for planning the deployment of a solution based on Microsoft SharePoint Server 2010


This document provides information and guidelines to lead a team through the steps of planning the deployment of a solution based on Microsoft SharePoint Server 2010.



Planning guide for Microsoft SharePoint Foundation 2010

Brief Description:

Information and guidelines to lead a team through the steps of planning the deployment of a solution based on Microsoft SharePoint Server 2010


This document provides information and guidelines to lead a team through the steps of planning the deployment of a solution based on Microsoft SharePoint Server 2010.



Upgrading to Microsoft SharePoint Foundation 2010

Brief Description:

Guide for administrators and IT professionals for upgrading to Microsoft SharePoint Foundation 2010


This document is designed to guide administrators and IT professionals through the process of upgrading to Microsoft SharePoint Foundation 2010 from Windows SharePoint Services 3.0.



SharePoint Server 2010 capacity management: software boundaries and limits

in a Mike Watson session yesterday at the SharePoint Evolution Conference (#spevo at Twitter), Mike mentionned this new document published by Microsoft recently, specifying the software boundaries and limits to take into account when plaaning your SharePoint 2010 infrastructure.

His slides included the following interesting table showing the capacity guidance differences between 2007 and 2010:

Higher capacity guidance



Content DB Size

100 GB

200 GB

File Size

2 GB

2 GB

DB’s per webapp



Site collection size

100 GB

100 GB

List items per view



Get the full document at

An interesting figure I was wondereing about was the maximum number of web applications per WFE for which the guidance document now specifies a maximum of 10 Application Pools per WFE. For 2007, I have always been told to not exceed 8 web applications / application pools, which makes the new guidance for 2010 not much better. If you are hosting a lot of web applications on a single farm, then planning the application pools will be a major step in the planning process.


lessons learned in my last sps to moss migration project using gradual approach

I have been doing a fun project for a customer, which asked to have his SharePoint Portal Server 2003 farms upgraded to MOSS 2007 using the gradual upgrade approach. I wanted to share some tips and things to consider when you are facing such a project.

1. remove unused and/or previous versions of webparts fom the SharePoint configuration.

There can still be web parts registered in SharePoint that have been physically or manually removed from the virtual server. Check stsam -o enumwppacks for any webpart packages installed that are no longer registered in the web.config files and so on. Know that when you start the upgrade of the web application, MOSS will try to upgrade all registered webpart packages and that if it cannot find it anymore, the process will fail and you zill not be able to upgrade the web application until you have fixed this. 

2. check if your IIS sites have not been renamed

Another one of those things to keep in mind is the fact that when the farm is created in SPS, it writes down the name of the IIS web site in the configuration database. The MOSS upgrade will use this information to find out which IIS site corresponds to the SPS sites. If these sites have been renamed in the meantime and you want to upgrade a SPS web application, then you can get a message indicating that there is nothing to upgrade or you will also not be able to find your SPS virtual servers in the MOSS upgrade pages in Central Administration v3. If for some reason you are in a farm scenario and your IIS site name has been changed on another front end server and not on the one you are performing the upgrade, then you will not get this warning, but the MOSS upgrade will not update the IIS site with the alternat url or port that you configure and you will therefore need to make the changes manually.

3. consider adding an additional frontend server to be used as the server that performs the upgrades

When you are ready to start upgrading sites, you need to do this on a server running the Central Administration role and the Web Application role. Do not think you can get away by using your index server to do your upgrades. The moss upgrade pages go through your IIS configuration to find the web applications that can be upgraded. If you are going through the upgrade pages on a central admin site hosted on your index server and net having the web application role, you will not find any web applications and/or site collections for which you can start the upgrade. Of course having installed MOSS on top of your existing front end servers, already bring an additional load to those systems and your users will probably start complaining with performance issues. That is why I would advise havin an additional frontend server installed in your SPS farm and use this one for performing the upgrades.

4. beware of the side effects of prescan

Another thing that surprised me in the project is prescan. This required tool suppoedly does not change anything to your sites. However it does. You know when you are viewing a list of all yous Document libraries and lists in your site, that it mentions next to each list when the last modification was done in that library or list (e.g. 6 days ago). Well running prescan will reset that information. So while it does not actually change any documents or lists, it does change the last modified date of the list or library itself. Knowing this may help you when you get your users on the phone complaining that all the document libraries have been changed all of a sudden (after you have run prescan)

5. there is no stsadm command to lock/unlock a site in SPS

damn, this is a bugger. Planning to script the upgrade of each site I found out that you cannot lock a site in SPS using the commandline stsadm tool. Apparently this was only introduced in MOSS. I found the solution in SPSiteManager (see my post about it)

6. Plan your content databases in MOSS

part of my project I was asked to have tha large databases in SPS, split up in multiple databases in MOSS. I did this by using the stsadm -o mergecontentdbs operation right after the site has been upgraded. Unfortunately you cannot choose wher the upgrade porcess needs to put the upgraded site collection. Part of the preparations to your upgrade is the fact that you need to configure a 1 to 1 relation of your existing SPS content databases to your MOSS databases, meaning that if a site is located in a specific content database, that its upgraded version will end up in the configured MOSS database and nowhere else (even if there is a parameter in the stsadm -o upgrade command that allows you to specify the targetdatabasename)

A piece of good advise: If you are planning to have more content databases in a specific web application in MOSS than you have in the corresponding virtual server in SPS, create additional empty databases in SPS to match the number of content databases in MOSS. It will save you a lot of trouble if you need to revert an upgraded site and reupgrade it again.

7. Check your upgrade.log file

Every action that MOSS does which regards upgrades of web applications, upgrades of site collections and even reverts of sites is logged in the upgrade.log file. If you have chnaged the default logging location in Central Administration v3 – Operations – Diagnostics Logging, then do not expect the upgrade.log file to be there as well. This log file does not leave the nest. You need to find it in the 12-hive Logs folder. A good practice would be to clear this file before starting the upgrade of any site.

8. Know how to rollback a failed upgrade of your SPS virtual server.

I had this issue that I was finally ready to start the upgrade of the web application and that during this upgrade process the well-known “unknown error occured” appeared. When I went back to the upgrade page, I was not able to rollback this operation or redo the upgrade. So what do you do next? the answer is very simple: delete the newly created web application in MOSS and every change made to the IIS sites (URL redirection) will automatically be undone as well.

I am sure that I can add some otherpoints to this list, but nothing comes to my mind on this sunny sunday afternoon. If something does come up I will gladly add it to this post and share it with you guys.

Using SQL Aliases with SharePoint by Thomas Vochten

Thomas Vochten, a former colleague of mine, wrote about an interesting way to create and configure your SharePoint farm to take into account any possible changes in your backend SQL infrastructure by using SQL aliases on your MOSS servers and therefore adding the possibility to change your backend SQL server transparently to your SharePoint configuration.

On his blog, he wrote:

“I recently found out about SQL Aliases and how to use them in combination with SharePoint installations. It enables you to define local alias name to connect to with a SQL Client, so you can change the actual connection later on. This may come in handy when switching over to your mirror database server, when moving servers, when virtualizing you database server etc. “

Furthermore he describes the actual steps to configure this. I am not adding those steps to this blog post, to have you go look at the original post instead [8-|]

I also checked with my favorite Premier support Engineer form Microsoft to check if this is supported and he confirms it is. He aslo confirmed seeing this more and more for use with Excel Services and failover scenarios as suggested by Thomas.

**** Update ****
Also worth mentionning is Thomas’s comment on my question:

I wrote: “Just to be clear: this needs to be configured on the MOSS servers locally, right, and not on the SQL box? And if so, then it would need to be configured on all MOSS servers part of the farm, too, right? “

Thomas replied: “Indeed, it needs to be configured on every MOSS server. You could also do this after MOSS is already installed: configure the alias exactly as your existing connection, and change it when needed.”

Thanks Thomas for sharing.

SharePoint Price Calculator by Jeroen

I am currently on a project where the licence cost for MOSS is causing an issue in this time of financial crisis and all… So I was wondering, is there an easy way to calculate what MOSS costs for your organization in licenses. I found the answer through Jeroen’s Blog for a tool from Bamboo solutions, called the SharePoint Price Calculator. You can find it here

The tool tells you how much licences you need by specifying details about your MOSS environment (number of frontends, number of users, number of SQL boxes, etc). The licenses and costs shown are for all the required moss license, operating system licenses etc.

Of ourse the prices are probably not updated, but they also list where they got the information for calculating this. The tool can at least be used to get a rough estimation.

So go take a look


What version of WSS/MOSS are you running?

I am preparing to install the new Infrastructure update that has been made available recently and wanted to find out what versions I am currently running. A post on the blog of Aaron Saikovski showed a nice table to determine the versions:

Remember that you can find these version numbers in Central Administration -> Operations -> Servers in Farm (/_admin/FarmServers.aspx)

Quick field reference – MOSS 2007/WSS V3.0 Version guide by Aaron Saikovsky

Here is a quick table for those who want to find out what version of WSS/MOSS you are currently patched up to:

Service Pack/Hotfix Version WSS V3.0 MOSS 2007

Infrastructure Update (KB951695 & KB951297)

Post-SP1 hotfix (KB948945)

Post-SP1 hotfix (KB941274)

Post-SP1 hotfix (KB941422)

Service Pack 1

Release To Manufacturing (RTM)

MOSS Capacity planning -> some usefull tips

These bits and pieces come right out of the OFF305_Capacity and Performance Planning for Microsoft SharePoint Products and Technologies 2007 session at TechEd.

slides are attached. 

  • Farms: do not split up WebFE servers across WAN’s. Keep all servers part of the same farm together

  • concurrency planning: on average take about 10% of your total number of users for calculating the concurrency planning. However, plan for peak concurrency as well, which is usually about 5 times the normal usage

  • 64-bit Hardware:

    • MOSS 2007 is tha last 32-bit SharePoint product. So if you are planning you renvironment, choose to install the 64-bit version now

    • 64-bit Hardware prioritization: SQL -> Index -> Excel -> Search -> WebFE

    • you cannot mix 64-bit / 32-bit Hardware in the same role.

  • Typical HW/role scenario:  (will support easily 25K users)

    • 2 WebFE servers with Query server role

    • 1 application server with index role

    • 1 clustered SQL Server (2 HW server)

  • Network: always use Gbit NIC’s between the MOSS servers !

  • Disk Space:

    • plan 1.2 to 1.5 times the File System size for your SQL database size for files that you plan to store in MOSS

    • index: ~ 10% of total content size

    • query: 2 times the index size

  • Performance testing: Use Visual Studio Team System Test Edition (VSTT)


Some facts you need to be aware of when planning/implementing MOSS

These facts come right out of my first session at TechEd IT Forum in Barcelona. I was in the following sessions when I wrote down these notes:

OFF07-IS From Day #1 to Launch  End-to-End Design   Architecture for a SharePoint Server 2007 Solution.

You can find the slides attached to this post [;)].

  1.  Licensing: You will need Enterprise CAL ‘s if your users are using Excel Services, Business Data Search, E-Forms and Data Management Reporting.

  2. SSP Planning: Best practice: use only 1 SSP !

  3. SSP Planning: you should never plan your SSP’s to span multiple geographical locations connected over a WAN.

  4. Search & Indexing: you can only have 1 index server per SSP which can handle about 15 million documents. If you need to index more documents, you will have to create more SSP’s.

  5. Query servers have a copy of the index. Queries do not get passed to the index servers as some people may think. If the index server is down, queries will still work, but the index file on you WebFE servers will no longer be updates as long as the index server is offline.

  6. Server Lockdown: do not use IIS lockdown for locking down your SharePoint servers.Instead use the SharePoint lockdown tool. I don’t know if it is available yet. If not, you can always turn to Joel Oleson’s page about locking down your SharePoint environmnet @

 So that’s it for my first session