Tuesday, November 17, 2009

SharePoint 2010 Beta is Here

SharePoint 2010 Beta is now available for download for MSDN and TechNet subscribers. There are a few snags in getting it to work for some people, though. This post is a list of resources for overcoming those snags:

Windows 7
SharePoint 2010 will install on 64-bit Windows 7, but you need to make some updates to the configuration file first. See this post for details:

Server 2008 R2
SharePoint 2010 Beta will not install correctly on Server 2008 R2 without this hotfix:
Note that as of the time this blog was written, the link was not yet active.

SQL Server 2005
In order for SharePoint 2010 Beta to install correctly on an instance of SQL Server 2005, you need SP3 with the following cumulative updates installed:

SQLServer 2008
In order for SharePoint 2010 Beta to install correctly on an instance of SQL Server 2008, you need SP1 with the following cumulative updates installed:

Installing SharePoint on a Domain Controller
If you are installing SharePoint on a server that is also an Active Directory Domain Controller, you need to run a few PowerShell commands for Sandboxed solutions or Office Web Applications to work. See Jie Li's post here:

Installing SharePoint using Local Accounts
If you are installing SharePoint without Active Directory, using Local Accounts, you need to follow these instructions to get it to work:

Visual Studio 2010
I have heard of several instances where a Visual Studio 2010 installation caused problems with a SharePoint installation. I recommend uninstalling Visual Studio 2010 before trying to install SharePoint.

Good Luck!

Monday, November 16, 2009

Running stsadm -o preupgradecheck

In Windows SharePoint Services 3.0 service pack 2, two new commands were added to stsadm to help determine whether your installation is ready for an upgrade to SharePoint 2010:
  • Preupgradecheck - Runs a set of rule checks to determine whether your installation is ready for upgrade to SharePoint 2010.
  • Enumallwebs - Displays the ids and site map status for all site collections and subsites in the content database.
How do I run preupgradecheck?
  • Login to one of your SharePoint servers
  • Open a cmd prompt and navigate to c:\Program Files\Common Files\Microsoft Shared\Web Server Extenstions\12\Bin
  • type "stsadm -o preupgradecheck"
What output will I get?
  • You should get something like this:
  • In addition to the cmd output, you will get an htm file that details information about your installation and any problems found.
What if I fail a check?
Microsoft has issued a knowledge base article that is fairly comprehensive about the rule checks and the types of problems you may encounter. You can find it here: http://support.microsoft.com/kb/960577. It doesn't cover every possible scenario, though. If you have a problem that you can't figure out, feel free to post a comment and I will try to help.

Does Preupgradecheck change my site in any way?
No. It is read only.

How do I run Enumallwebs?
  • Login to one of your SharePoint servers
  • Open a cmd prompt and navigate to c:\Program Files\Common Files\Microsoft Shared\Web Server Extenstions\12\Bin
  • type "stsadm -o enumallwebs -databasename [contentdb]" Replace [contentdb] with the name of your content database.
What output will I get?
  • You will get xml output to the cmd screen. Something like this:

How do I redirect stsadm output to a file?
It might be helpful to redirect your enumallwebs output to a file. Here is how you do it:
  • Login to one of your SharePoint servers
  • Open a cmd prompt and navigate to c:\Program Files\Common Files\Microsoft Shared\Web Server Extenstions\12\Bin
  • Type "stsadm -o enumallwebs -databasename [contentdb] > output.xml 2>&1" Replace [contentdb] with the name of your content database.
  • This will output your xml to a file called "output.xml" in the same directory.
Additional Notes
  • You should run preupgradecheck on every server in your SharePoint farm. It does several server-specific checks.
  • Enumallwebs has an important field called "InSiteMap" that tells you whether a web is listed in the SiteMap. If a particular web is not listed in the SiteMap, it will have a value of "false" and the preupgradecheck will fail on the "ContentOrphan" step because you have an orphaned site.

Friday, November 13, 2009

My Top 10 Reasons to Upgrade to SharePoint 2010

  1. Fast Search - You are a sales executive looking for a particular type of presentation or company resource. Just type in a keyword. Fast Search will search not just titles, keywords or description, but the actual documents themselves. And it knows, based on your role, what you might be interested in (Sales).
  2. List Joins - We will finally be able to query lists and join them.
  3. Significantly improved user experience - The Microsoft Office ribbon, Silverlight and client object model, better CSS, etc...
  4. REST API - fantastic
  5. Visio diagram --> SharePoint Designer Worflow --> SharePoint Workflow - completely seamingless and not an ounce of C# (not that I have anything against C#)
  6. Built in support for database mirroring
  7. PowerShell
  8. Corporate Taxonomy - Don't underestimate the value of this. It is huge! And if you don't know what it is, read about it. In today's world, organizations are literally flooded with information. Forget storing your documents on a file share somewhere. SharePoint 2010 allows you to categorize, contextually search, and easily find whatever you are looking for.
  9. Logging database with windows event logging and health reporting
  10. Reusable Workflow Templates

Doing a Database Attach Upgrade to SharePoint 2010

A database attach upgrade to SharePoint 2010 is, in my opinion, a cleaner process than doing an in-place upgrade. It goes like this:
  • Create a new SharePoint 2010 farm. This is like doing a clean install of Windows when a new version comes out. You are starting with a fresh copy of the software. The disadvantage, of course, is that you lose your farm level configuration settings.
  • Manually transfer server side customizations to the new farm and test them
  • Detach your databases from the existing SharePoint 2007 farm and back them up. This is where the downtime starts. As soon as you detach your databases, SharePoint will be down.
  • Attach the databases to the new SharePoint farm.
The advantages of doing a database attach upgrade to a new SharePoint 2010 farm are as follows:
  • There is generally less downtime and the upgrade process is faster
  • If you happen to have multiple farms and want to consolidate them into one farm, you can do this with a database attach upgrade
  • You can upgrade several databases at the same time
The disadvantages of doing a database attach upgrade are as follows:
  • Server and farm level settings must be manually setup on the farm
  • Server side customizations do not transfer and have to be upgraded manually
  • You cannot upgrade a search database using this method
There is a nice set of technical diagrams from Microsoft on TechNet here: http://technet.microsoft.com/en-gb/library/cc263199(office.14).aspx

The technical diagrams go into detail about two possible hybrid methods. I will be covering those in a future post.

Wednesday, November 11, 2009

Doing an In-place Upgrade of SharePoint 2007 to SharePoint 2010

Assumming you have met all the upgrade requirements, how do you actually go about doing the upgrade? There are basically two options: an in-place upgrade or a database attach. You can also do hybrids of those two options. This post will cover the In-place upgrade.

Why would you choose to do an in-place upgrade of SharePoint?
  • The hardware currently hosting your SharePoint 2007 installation meets all of the requirements for 2010. Generally, if you are migrating your SharePoint farm to new hardware during the process, you would want to setup a new farm and use the database attach approach.
  • You want to preserve all of your farm-wide settings. Setting up a new farm and using the database attach approach requires that you redo your farm-wide settings. An in-place upgrade preserves those settings.
  • You don't mind the extra downtime. An in-place upgrade requires that your SharePoint farm be offline for the duration of the upgrade. Depending on the size and complexity of your SharePoint 2007 installation, this could be several hours.
How do you actually do an in-place upgrade?
  1. Run Setup on all servers in the farm. It is important to start with the server that will be hosting Central Administration. Make sure not to run the configuration wizard on any servers until setup has been run on all servers.
  2. Run the configuration wizard for all servers in the farm, starting with the server that will be hosting Central Administration. There will be a page telling you to pause and run the wizard on the other servers. You will need to pause at each server when you get to that page until all server are at the same point.
Use Visual Upgrade to upgrade the look and feel of the site collections
Visual Upgrade allows you to upgrade the look and feel of SharePoint 2010 Site Collections separately from the actual in-place upgrade process. When you have completed the upgrade process, the site will be upgraded to SharePoint 2010, but it will still have the look and feel of SharePoint 2007. The Visual Upgrade tool allows you to preview each Site Collection in the SharePoint 2010 look and feel before it is upgraded.

Microsoft has some great poster-sized diagrams that outline the upgrade process. Look for them here: http://technet.microsoft.com/en-gb/library/cc263199(office.14).aspx

Preparing to Upgrade from SharePoint 2007 to SharePoint 2010

This post will outline a few of the steps to help prepare for an upgrade from SharePoint 2007 to SharePoint 2010.

Step 1: Ensure SharePoint 2010 Hardware Requirements are Met

  • SharePoint 2010 is 64-Bit only. Unless you have ancient computers, you probably meet this requirement from a hardware perspective.
  • At least 3Ghz dual processors. From what I have been hearing, this is probably a less stringent requirement. You can probably get by with less.
  • Minimum 4GB RAM for the most basic installations. I have talked to several people who have installed and run SharePoint with 4GB on a test machine and they say they need more. MS recommends at least 8 GB for production. The more the better.
  • 80 GB Hard Drive. Depending on your usage, you probably need much more, though.
  • TechNet article for reference: http://technet.microsoft.com/en-us/library/cc262485(office.14).aspx
Step 2: Ensure Software Requirements are Met
  • Database has to be SQL Server 2005 with SP3 or SQL Server 2008 with SP1
  • OS has to be Windows Server 2008 SP2 or later
  • .Net 3.5 SP1. Yes, SharePoint 2010 uses .Net 3.5, NOT 4.0
  • IE 6 is not supported
Step 3: Run stsadm -o preupdatecheck
  • This has to be run on every server in the farm
  • It checks hardware and software requirements as well as a number of integrity checks
  • It also provides a ton of information about your SharePoint 2007 installation like: server components, alternate access mappings, site features and definitions that are installed, etc...
  • For detailed instructions see this post: http://technet.microsoft.com/en-us/library/dd793607.aspx
Step 4: Resolve any potential issues from the preupdatecheck
  • OSType
  • Database Schema
  • DataOrphan
  • SiteOrphan
  • UnfinishedGradualUpgrade
  • MissingWebConfig
  • InvalidHostNames
  • InvalidServiceAccount
  • DatabaseReadOnly
There are two main options for upgrade this time around: In-Place and Database Attach. If you are setting up a new farm, you will probably want to use the Database Attach. If you are upgrading an existing farm, you will probably want to use the In-Place upgrade. I will go into more details about these in a future post.

Monday, November 9, 2009

SharePoint 2010 Developer Training Videos on MSDN

Today, Microsoft published new training videos for developers here: Training Videos

A couple of the topics I have already covered below and most of the others I plan to cover in upcoming blogs. So, stay tuned!

Saturday, November 7, 2009

SharePoint 2010 Client Object Model Development

I spent some time reading the SDK on the Managed Client Object Model in SharePoint 2010. I thought I would distill some of the information for those of you that don't have time to read the entire object model SDK.

Resources: Managed Client Object Model SDK

There are three new client-side APIs that allow SharePoint developers to use and interact with the SharePoint object model from the client:
  • .Net Managed Applications - Writing a custom application for your organization that uses .Net? You can now interact with a limited version of the SharePoint object model directly from the client.
  • Silverlight Applications - The lines between client applications and browser-based applications are blurring. You can now use a limited version of the SharePoint object model directly from a SilverLight client.
  • ECMAScript (JavaScript) - Writing a custom web application that isn't using the SharePoint architecture? Just copy some .js files into your development library and the SharePoint object model is there for you to use.
Here are a few highlights of some of the real distinctions between these three object models:

.Net Managed Applications
  • .Net 3.5 or higher
  • Synchronous
  • Absolute URL for context
  • Cannot use Current property for context
  • Microsoft.SharePoint.Client is the core namespace
  • There are two development dlls: Microsoft.SharePoint.Client.dll and Microsoft.SharePoint.Client.Runtime.dll
  • SilverLight 2.0 and above
  • Synchronous or Asynchronous
  • Absolute URL for context
  • Can use Current property for context
  • Microsoft.SharePoint.Client is the core namespace
  • There are two development dlls: Microsoft.SharePoint.Client.Silverlight.dll and Microsoft.SharePoint.Client.Silverlight.Runtime.dll
  • Asynchronous
  • Absolute, relative, or no URL for context
  • Can use Current property for context
  • SP is the core namespace
  • There are several .js files needed for development. Here are a few of them: SP.js, SP.Core.js, SP.Ribbon.js, SP.Runtime.js
The client object model follows an SQL-like process flow:
  • Retrieve a client context object
  • Use the object model to specify an object to retrieve
  • Load the object to return a specific object collection or data
  • Execute a query to obtain the object
Here is some sample code taken directly from the SDK that demonstrates how to retrieve the title of a website:

using System;
using Microsoft.SharePoint.Client;

namespace Microsoft.SDK.SharePointServices.Samples
      class UsingClientContext
           static void Main()
               ClientContext clientContext = new ClientContext("http://MyServer/sites/MySiteCollection");
               Web oWebsite = clientContext.Web;

Web Services
Traditionally, if you wanted to interact with SharePoint from a client, you had to use Web Services (either Microsoft provided or custom). Microsoft is strongly encouraging developers to use the client object model now, instead. Here is a direct quote from the SDK:

“These APIs are still supported for backward compatibility with Web service clients. For reasons of both performance and ease, we recommend that you use either the client object model or the ADO.NET Data Services Framework"

The client object model provides useful APIs for interacting with SharePoint from the client. I imagine that support for these APIs will only grow as SharePoint continues to grow. It may be time for your organization to reevaluate how you use Web Services and how you provide a rich, interactive experience for your users.