Welcome to MSDN Blogs Sign in | Join | Help

My new blog location ... Introducing ‘UK SharePoint Team’ blog

After careful thought, I have decided to join forces with the rest of the SharePoint team in UK Microsoft Consulting Services to work collectively on a new team blog called UK SharePoint Team (http://blogs.msdn.com/uksharepoint).

With many people contributing to the blog, we hope you will find great content being posted regularly. The focus will be on informative, useful articles based on all things SharePoint covering the full spectrum of development, infrastructure, architecture and best practices.

The team blog idea has worked well in several teams already within Microsoft including Microsoft SharePoint Team Blog and The Deployment Guys (MCS Deployment Team). The new blog will replace all of the following blogs from people who are now going to contribute to UK SharePoint Team instead:

We have already posted an article on UK SharePoint Team called "SharePoint Farm Communications .... Ports, Proxies and Protocols" which talks about inter-farm communications, firewall ports etc within SharePoint. This is a summary of a presentation that was recently given at TechEd 2008 in Barcelona by Martin Kearn.

So redirect your RSS readers to http://blogs.msdn.com/uksharepoint and enjoy! J

Manually configuring Search Propagation Location using STSADM

As part of a SharePoint farm configuration, you will need to setup a share on your Query servers in order for the Index Server to propagate (i.e. copy) the search indexes to the Query Servers. In Central Administration (Services on Server > Office SharePoint Server Search Service), there are two options for this:

  • Configure share automatically
  • I will configure the share with STSADM

In my experience, the automatic configuration option is sometimes unreliable. This is especially true with farms that are using the 'least privilege service account principle' or on Windows Server 2008 which is much more locked down by default than Windows Server 2003.

Therefore I'd recommend choosing the STSADM option. If you do choose this, you'll need to follow these steps to finalise your Query server configuration.

  1. Ensure you have started the 'Office SharePoint Server Search Service' in Query mode on all of your Query servers (choosing the STSADM option for the propagation share)
  2. Ensure you have created a Shared Service Provider
  3. If using Windows Server 2008, enable 'Network discovery' and 'File sharing' from the 'Network Sharing Centre' on all Query servers
  4. Create a directory on all of your Query servers where you want the search indexes to be propagated to. This must be the exact same path of all Query servers (c:\SearchIndexes in this example). Do not set up any sharing at this point, STSADM will do this for you.
  5. If you are using the 'least privilege service account principle', temporarily give the "farm" or "database access" service account local Administrator rights on all Query servers (this can and should be removed after the operation is complete)
  6. Logon to any server in the farm as the "farm" or "database access" account and execute this command:

    c:\program files\common files\microsoft shared\web server extensions\12\bin\STSADM.exe –o osearch –propagationlocation "c:\SearchIndexes"

  7. If you are using the 'least privilege service account principle', remove the "farm" or "database access" service account from local Administrator rights on all Query servers (as added in step 5)
  8. Observe that the c:\SearchIndexes directory has now been shared as 'SearchIndexPropagation' and the "Search" service account has been given write access

Your indexes should now fully propagate to the query servers....Job done! J

SharePoint Object Hierarchy: How it all fits together

I often get asked to clarify how all of the objects in SharePoint relate to each. For example, people do not always understanding the differnence between a site collection and a site or how a web application and content database relate to each other.

To help out, I have produced this diagram which I think explains all of the main SharePoint objects and how they relate to each other. I did consider writing some kind of description to go with this, however I think it is better that I just do my best to answer any questions via the comments. If there are any re-occuring themes, I'll add to this article and try to explain them.

If you cannot see the image below, you can download it from here:

Image Updated to inlcude additional items from a reader's comment (thanks)

 

Useful facts about SharePoint farms

I recently presented a talk at the Office Developer Conference in San Jose and I was surprised about the amount of questions we got around SharePoint server farms and topologies. Having a good understanding of what a farm is and some of the best practices around designing your farm is critical to your overall SharePoint deployment so I thought I'd put together some key facts about farms.

There are two articles on TechNet called Plan for server farms and Plan for availability which contain some useful information and I'd definitely recommend reading that in addition to this article.

What is a Farm?

A place where lots of animals are kept and things are grown! J In the context of SharePoint, the term 'farm' is used to describe a collection of one or more SharePoint servers and one or more SQL servers that come together to provide a set of basic SharePoint services bound together by a single Configuration Database in SQL.

Farms can range in size from having everything (all SharePoint roles and SQL server) on one machine to scaling out every individual SharePoint serve role onto dedicated sets of servers. A farm the highest administrative boundary for SharePoint and everything that happens inside SharePoint happens in a farm.

Server Services and Fault Tolerance

Within a farm, there are several services that run on one or more servers. Some of these services are mandatory and some are optional. These services provide the underpinning functionality for SharePoint. The decision around which services run on which servers will have a huge impact on your overall farm architecture and performance.

It is worth noting that some services have built-in fault tolerance and some do not. In the TechNet articles listed above, the services that have fault-tolerance are described as "Roles that can be redundant".

This table describes each service:

Service 

Purpose 

Fault Tolerance 

Typical Server Placement 

Things to note / Rules

Windows SharePoint Services Web Application (often referred to as 'Web Server' or 'WFE')

This service is responsible for serving the HTML to clients and routing requests to other services in the farm.

Yes, this service can exist on multiple servers.  

Typically there are two or more servers running this service ion a farm. 

If you are using multiple servers, you must also implement a Network Load Balancing solution (NLB) to balance requests across the servers.

You must also use host headers for all web applications in this scenario. 

Office SharePoint Server Search in Query Mode (often referred to as 'Query Server') 

This service is responsible for executing search queries against a locally stored copy of the index

Yes, this role can exist on multiple servers 

This service is typically placed on each Web Application server in the farm. 

Since this service requires a local copy of the index, appropriate disk space is needed to store the index.

Office SharePoint Server Search in Index Mode (often referred to as 'Index Server') 

This service is responsible for indexing all of the configured content sources, creating an index and propagating it to every Query server in the farm

No, you can only have 1 Index server for each SSP in the farm. If you have multiple SSPs (not recommended – see SSP section), you can have multiple Index servers, but they have their own set of content sources. 

This service is typically placed on its own dedicated server.

It is possible to run both the Index and Query roles on the same server. However, in this configuration you cannot have multiple Query servers because when Index and Query are on the same server, propagation of the Index is disabled. 

Windows SharePoint Services Search

This service is basically a slimmed down version of the Office SharePoint Server Search service which combines both the Query and Index roles into a single service.  

No. If you have more than one instance of this service in a farm, it will be simply do the same thing as the other servers.

This service is typically not used. If you do run this service in a MOSS farm, it is generally run on the same server as the Index server. 

If you have a MOSS farm, then the only reason for using this service would be to provide full text search of Help.

Excel Calculation Services

This service is responsible for performing calculations on Excel workbooks that are stored in the content databases.

Yes, many instances of this service can exist on the same farm.

This service is typically placed on each Web Application server in the farm initially.

However, this is a fairly resource intensive role; therefore, it is typically moved to a dedicated pair of servers if the load becomes too heavy.

Although this service does support fault tolerance, it does maintain session-state information, therefore users will stay on the same Excel Calculation Services server for the duration of their session.

Document Conversions Load Balancer Service 

This service balances document conversion requests from across the server farm.

No. An application server can only have a single Document Conversions Load Balancer Service enabled.

There is typically only one server running this service in a farm. This is typically placed on the Index server

For more information on the document conversion service click here.

Document Conversions Launcher Service 

This service schedules and initiates the document conversions on a server.

Yes. Multiple launchers can exist in the same farm.

This service is typically placed on each Web Application server in the farm.

If you are using multiple launcher services, they much each have the same set of document conversion applications installed.

Windows SharePoint Services Incoming E-Mail

This service is responsible for receiving incoming emails and placing them in email enabled lists. 

Yes, this service can run on multiple servers. However this does have additional configuration. See the 'Things to note' column for details.

This service is typically placed on each Web Application server in the farm.

There are lots of pre-requisite steps that must be configured before using this service. Read more here.

Windows SharePoint Services Outgoing E-Mail 

This is not technically a SharePoint service but refers to an SMTP server which SharePoint send outbound email to

n/a 

n/a 

n/a 

Central Administration

This service enables the central administration interface that is required for farm-wide administration 

No, this service can only run on one server in the farm. 

UPDATE: 17 May 2009. This is an error. The CA service only runs on one server by default, however there are ways of enabling fault tolerance for this service and in actual fact you SHOULD enable fault tolerance for this service. Spence Harbar has a great article which talks all about it: http://www.harbar.net/articles/spca.aspx .The topic is also discussed on the 'From the field' blog from our PFE colleagues: http://sharepoint.microsoft.com/blogs/fromthefield/Lists/Posts/Post.aspx?List=0ce77946%2D1e45%2D4b43%2D8c74%2D21963e64d4e1&ID=60

Typically, this role is placed on either the Index server or one of the web servers. By default, the first server in the farm will run this service.

The Central Administration web application does run on every Web Application server in the farm; however requests are always routed to the server that is running this service.

So what is the difference between an 'Application Server' and a 'WFE Server'?

When SharePoint is installed, you have to select one of three installation options, they are:

  • Application Server
  • Complete
  • Web Front End

There is a lot of confusion around what these options mean. An 'Application Server' is a server that is capable of running any of the services in the table above apart from the Windows SharePoint Services Web Application service. A 'Web Front End' (sometimes called a WFE) is the opposite in that it can only run the Windows SharePoint Services Web Application service. 'Complete' means that the server can run any SharePoint service.

The reason behind these options is that in some scenarios, very 'thin' web servers may be required which have a very small installation footprint. In this case, it is not desirable to install all of the DLLs etc that are required to run any service apart from the Windows SharePoint Services Web Application – these are true web servers. In my experience, this is a relatively rare scenario and only really relevant when SharePoint is being used to host high traffic internet sites.

The problem with selecting anything other than 'Complete' is that it means if you ever change your mind about what services a server can run, you'll need to re-install SharePoint on that server. For that reason alone, I would always recommend that you choose 'Complete' unless you have a very good reason to do otherwise.

This means that the terms 'Web Front End Server' and 'Application Server' are often used incorrectly. Unless your server is only running the Windows SharePoint Services Web Application service, it is an Application server. This means that the majority of servers in the majority of farms are actually Application servers.

How should I design my web applications within my farm?

I often get asked how to dedicate specific servers to specific web applications and the default answer is '"you can't"! J

One of the rules about SharePoint farms is that every server that is running the Windows SharePoint Services Web Application service has to serve every web application in the farm. It is not possible to say "Server X serves Web Application X". This means that when you create a new web application in Central Administration, the Windows SharePoint Services Timer on each server that is running the Windows SharePoint Services Web Application service creates the necessary sites and application pools in IIS to serve the web application.

What about Central Administration? .....

The Central Administration web application is no exception to this rule in that the web application does exist on every web server. However, the Central Administration service only runs on a single server and it is that server that responds to Central Administration requests. This is why the Central Administration site is always bound to a server name rather than an NLB-enabled host header.

Cross geography farms

One of the key questions is around how farms relate to different geographical data centres.

The quick answer is that you cannot run servers in the same farm across a WAN connection. For example you cannot have 1 web server in London and 1 in Reading if they are both in the same farm. This model will technically work, however it is unsupported because the web servers are very 'chatty' with the SQL server, therefore WAN connection are not seen as being good enough to support this.

What happens if I have a super-fast WAN? ....

There are some circumstances where you can span a farm over a WAN and they are as follows:

  • WFE has less than 1 millisecond(ms) latency to DB
  • WFE has less than 10 miles (16 kilometres) to DB
  • All servers on the same network segment
  • Same VLAN
  • No router switching
  • SSPs in the same datacenter
  • Servers cannot cross time zones

As a general rule of thumb you should plan to have a different farm at each data centre.

A farm's relationship with the SSP

One of the optional components in a farm is a Shared Service Provider (SSP). SSPs are optional applications that use a combination of web applications and server services to provide several shared services. The key thing to note here is that the SSP does not run on any single server within the farm, there is no such thing as an 'SSP server'. The SSP is actually an application that requires the following:

  • At least one server running Office SharePoint Server Search service in Index mode
  • An 'SSP Administration' Web Application.
  • 2 databases in the farm's SQL server.
  • Optionally, a server running the Excel Calculation Service.

Once an SSP is configured, its shared services can be provided to all of the web applications within the local farm. An SSP can also provide services to separate farms; this is called 'cross-farm Shared Services' and is very common in large deployments. You can read more about this in my MOSS Architecture and Shared Services article.

How many SSPs should I have in my farm? ....

Generally speaking it is best practice to have only one SSP per farm. It is possible to have multiple SSPs, but that configuration introduces a whole load of issues.

Each Web Application in your farm must get its Shared Services from a single SSP; it is not possible to pick and choose certain SSPs for certain shared services. Neither is it possible to say that a certain SSPs only provides certain services. The problem with this is that if you do have 2 SSPs, then you have 2 My Sites per user, 2 profiles per user, 2 sets of search indexes etc. Companies that do have this configuration, generally have to do a load of development work to keep the SSPs in sync with each other and make sure that user's are redirected to the correct SSP for their My Site.

There are only two common reasons for having multiple SSPs, they are:

  • Index Server scale. There is a recommended maximum of 50 million items per Index Server (more information click here). Since you can only have 1 Index server per SSP. If you can more than 50 million items to index, you may need to split the load across multiple SSPs.
  • Privacy. Some parts of the organization may actually want to host their own My Sites, Profiles etc and the split is seen as a good thing.

When to have multiple farms

The final thing that I get asked a lot in relation to farms is when to make the decision to have multiple farms. The general answer is that wherever possible, you should have a single farm.

However, there are several scenarios where multiple farms make sense. I covered some of this in my MOSS Architecture and Shared Services article, but here is a summary:

  • Physically separate data centres
  • Differing customisation approaches and polices
  • Differing support policies and SLAs
  • Development, staging and test environments

That will do for now! ....

I think that is quite enough for one article and I've covered most of the questions I hear a lot when chatting to people in the field.

I'm keen to hear about areas that I may have missed so please use the comments to log your own grey areas around SharePoint farms and maybe I'll do a part 2 covering the common themes.

How to create a ‘Slipstream’ installation for MOSS with SP1

Update (8th March): The product team have now released a MOSS with SP1 download. Read all about it here: http://blogs.msdn.com/sharepoint/archive/2008/03/07/moss-2007-with-sp1-slipstream-officeserverwithsp1-exe-released.aspx  

In order to install MOSS 2007 on Windows Server 2008 you will need to install 'MOSS with Service Pack 1' (this includes WSS with Service Pack 1). This is known as a slipstream installation and it contains the original image for MOSS/WSS RTM and the MOSS/WSS SP1 files. The problem is that this 'all in one' slipstream for MOSS is not available for download just yet, so you have to create your own slipstream image. Fortunately, this is very easy to do, just follow these steps:

1- Download MOSS and WSS Service Pack 1 files

You can download the MOSS and WSS SP1 files from here. You will need both service packs for a MOSS installation:

WSS SP1: http://www.microsoft.com/downloads/details.aspx?FamilyID=4191a531-a2e9-45e4-b71e-5b0b17108bd2&DisplayLang=en

MOSS SP1: http://www.microsoft.com/downloads/details.aspx?FamilyID=ad59175c-ad6a-4027-8c2f-db25322f791b&DisplayLang=en

Once downloaded you will have two executable files: Wssv3sp1-kb936988-x86-fullfile-en-us.exe and Officeserver2007sp1-kb936984-x86-fullfile-en-us.exe

2 - Extract the exe's

You now need to extract the exe's, to do this enter this command (this assumes you've downloaded the exe's to your c:\, change if not)

C:\Wssv3sp1-kb936988-x86-fullfile-en-us.exe /extract:c:\wsssp1extract

C:\Officeserver2007sp1-kb936984-x86-fullfile-en-us.exe /extract:c:\mosssp1extract

3 - Add the extracted files to your RTM MOSS installation

Once you've extracted the service pack exe's you need to copy the extracted contents to the /Updates folder on the MOSS CD. The easiest way to do this is take a copy of your MOSS RTM CD (or extract your ISO image) onto your file system and simply copy the contents of both c:\wsssp1extract and c:\mosssp1extract into the \Updates folder (both the WSS and MOSS service pack files go into the same folder, do not use sub-folders)..

You're done; you will now be able to install MOSS as usual on your Windows Server 2008 machine. If you need a guide for doing this, check out my other post here: http://blogs.msdn.com/martinkearn/archive/2007/03/28/how-to-install-sharepoint-server-2007-on-a-single-machine.aspx . This guide was written for Windows Server 2003 so there may be some minor variations.

Code Callout Features: How to make automated modifications to sites after they have been deployed

Ok, I'll admit that this is not the most snappily-named blog title; however it will address a specific problem that I've hit a few times at different customers; which is how to make automated modifications to sites after they have been deployed and used.

The Problem

The scenario I am hoping to address here is when you build a site structure based on standard site templates but one day a requirement arises to change all of the sites for some reason (very common given the 'organic' nature of SharePoint). There are lots of reasons why you might need to do this; here are just some of the common ones:

- Changing master page, CSS or theme on specific sites or part of any overall structure

- Associating content types or site columns with all libraries

- Adding specific security settings to a site

The list goes on, this basically applies to anything that you could do through Site Settings but want to automate.

The problem is that the sites are already out there being used and therefore you cannot change the template or definition that the site is based on (which you'd do if you knew about the requirement beforehand). The other approach is manually configuring the sites via the UI, but this is just not realistic in large structures.

Throughout this article I'll use the scenario of adding a content type (let's say the standard 'Dublin Core Columns' content type) to every document library in the site structure, but this could be applied to a plethora of different scenarios .... anywhere where you need to execute some one-off code to do something to an existing site or range of sites.

The Solution

To address this requirement, we build what is known as a 'Code Call-out Feature', this is basically a feature that simply executes some code when it is activated. Once written and installed, you can activate the feature by using STSADM.exe command line utility. You can use a batch file to repeat this command throughout your entire site structure if desired (more on this later).

Before you get worried about the fact that we are talking about code here, don't worry – it is really very simple, even if you are not a 'developer'. The following steps have been written for someone that has only very basic experience with Visual Studio, so if you are a more established developer some of this may be a little obvious.

Step 1 – Setup your Visual Studio project

The first step is to setup your Visual Studio project for the .net assembly that will get called when your feature is activated. Simply follow these steps:

a. Open Visual Studio and create a C# 'Class Library' project called 'CTAssociation'

b. In Solution Explorer, right-click on your project and click 'Add Reference', go to the 'Browse' tab and choose Microsoft.SharePoint.dll (normally located in C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\ISAPI\Microsoft.SharePoint.dll)

c. Go to the project properties (Projects > CTAssociation properties) and do the following:

- On the Application tab set the Assembly name to 'CTAssociation.DublinCore' and the namespace to 'CTAssociation'

- On the Signing tab, check 'Sign the assembly' and create a new Strong Name Key file (choose 'new' from the drop-down)

d. Open 'Class1.cs' and change it so that it looks like this (I've highlighted the things that you need to add or change):

e. Save and Build your project (ensure you have no errors)

2 – Add your assembly to the GAC

Providing your project built OK, you should now have a new DLL called CTAssociation.DublinCore.dll located in My Documents\Visual Studio 2005\Projects\CTAssociation\CTAssociation\Bin\Debug. We need to add this to the Global Assembly Cache (GAC). To do this follow these steps:

  1. Go to Start > All Programs > Administrative Tools > Microsoft .net Framework 2.0 Configuration
  2. Expand My Computer > Assembly cache, right click and choose 'Add'
  3. Navigate to your DLL (My Documents\Visual Studio 2005\Projects\CTAssociation\CTAssociation\Bin\Debug\CTAssociation.DublinCore.dll) and add it

Now that the assembly has been added to the GAC, you will be able to get the Public key Token which will be required later one, to do this follow these steps:

  1. In the .net Configuration Utility click on My Computer > Assembly Cache and click 'View List of Assemblies in the Assembly cache' which is located on the right-side pane.
  2. Located your assembly (CTAssociation.DublinCore)
  3. Double click your assembly to open its properties and take a careful note of the Public Key Token (I like to copy it and paste into notepad)
  4. Close the .net Framework Configuration tool

3 – Setup your Feature

Now that your assembly has been added to the GAC, we need to build the feature that calls it when activated. The 'Code Callout feature' is one of the simplest ones to create, follow these steps

All features have to have a unique identifier called a GUID. The easiest way to create a GUID is to use a tool that comes with Visual Studio called GUIDgen.exe. Follow these steps:

  1. Navigate to C:\Program Files\Microsoft Visual Studio 8\Common7\Tools and load GuidGen.exe (search for it if it is not in this location)
  2. Click 'New Guid'
  3. Set the format to '4. Registry format'
  4. Copy the contents of the result but without the {}. You should have a string of random numbers and letters in 5 blocks delimited by a hyphen. Again, I like to paste this into Notepad to avoid typos.

Now that you have your GUID and Public key Token, you can create the actual feature. To do this follow these steps:

  1. In Windows Explorer, navigate to your Features directory (usually C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\FEATURES)
  2. Create a new folder in \template\Features called 'CTAssociationDublinCore'
  3. Within the CTAssociationDublinCore folder, create a new XML file called feature.xml
  4. Add the following code to feature.xml and save (replace the ID with your new GUID and PublicKeyToken with the one you took note of earlier)

    <Feature

        Scope="Web"

        Title="Content Type Association - Dublin Core Columns"

        Id="BD26E0C3-3AC7-4c07-90AD-54FF3A908A95"

        ReceiverAssembly="CTAssociation.DublinCore, Version=1.0.0.0, Culture=neutral, PublicKeyToken=d43c4c8ff8fcf2b6"

        ReceiverClass="CTAssociation.DublinCore"

        xmlns="http://schemas.microsoft.com/sharepoint/">

    </Feature>

4 – Install your Feature

Installing your feature could not be simpler. There is an STSADM.exe parameters called 'InstallFeature'. To install the feature follow these steps:

  1. Open a command prompt and navigate to C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\BIN
  2. Enter the following command

    stsadm.exe -o installfeature -name "CTAssociationDublinCore" –force

Providing all is well your feature should now be installed. Next thing to do is test that is basically works (i.e. throws the "This feature was activated!!" message when activated). To do this follow these steps:

  1. Open the browser and navigate to any site in your site collection
  2. Go to Site Actions > Site Settings > Modify All Site Settings
  3. Click on Site Features
  4. You should see 'Content Type Association – Dublin Core' in the list of feature, simply click 'Activate'.
  5. If all is well you should see this message:

    <screen of error>

5 – Writing the code to add a Content Type

At this point you have all the plumbing in place to starting adding functionality to your feature. This is the point where you add the code to make the modification that you require.

It is not in the scope of this article to explain how to do this in detail; the article is more about how to create the feature. However, in our example of adding a new content type to all document libraries, the code would look something like this:

SPWeb oWeb = (SPWeb)properties.Feature.Parent;

SPContentType oCT = oThisWeb.Site.RootWeb.ContentTypes["Dublin Core Columns"];

foreach (SPList oList in oThisWeb.Lists)

{

//check if the current list is a document library

if (oList.BaseTemplate == SPListTemplateType.DocumentLibrary)

{

dDocLibCount += 1;

oList.ContentTypesEnabled = true;

try

{

oList.ContentTypes.Add(oCT);

//if the above throws an exception, it means the content type is already on this list. This does not matter so catch the exception and carry on

}

catch

{

}

}

//if there were no document libraries throw an exception

if (dDocLibCount == 0)

{

    throw new Exception("There were no lists of the Document Library type in this Site, therefore no updates were made and the Content Type was not associated with any lists.");

}

//update the list

oList.Update();

}

Summary

In summary, code-callout features are a very powerful capability which allow you to make changes to you existing Sharepoint solutions after they have been deployed and are actively being used.

Configuring Kerberos for SharePoint 2007: Part 2 - Excel Services and SQL Analysis Services

This is the second of my several-part series on how to configure Kerberos for MOSS 2007. In the first article, I outlined the steps that are required in order to get Kerberos working for a basic MOSS installation. In this article I am going to address one of the most common scenarios that actually requires Kerberos in order to work; that is using Excel Services to display data from a SQL Analysis Services Cube (or a normal SQL database) via SharePoint.

Why does this scenario require Kerberos?

As outlined in part 1 of this series, Kerberos is required whenever something in SharePoint needs to access another service on the user's behalf (i.e. "double hop"), this scenario does exactly that. The spreadsheets that are hosted by Excel Services will need to access a SQL server in order to get the information that is required. This is a double-hop and unless Kerberos is enabled, you will get errors in your Excel Services Webparts.

Step 1: Configure Kerberos for MOSS

The first step in configuring this scenario is to get your base MOSS configuration sorted. Follow the steps in my first article to do this (Configuring Kerberos for SharePoint 2007: Part 1, Base Configuration for SharePoint).

Step 2: Configure Permissions in SQL AS

This section specifically relates to using SQL Analysis Services, but similar steps will be required for normal SQL or Reporting Services.

In order that users can access your SQL AS cube, you need to configure permissions inside SQL Management Studio. Follow these steps:

  • Open SQL Management Studio
  • Connect to Analysis Services
  • Right-click on the server level and go to properties
  • Go to the Security tab
  • Give the relevant users access. If you want everyone to have access, add 'authenticated users'

This will means that user have access to actually read the data from eth AS cube

Step 3: Configure Excel Services for Delegation

One of the key things that people get caught out with on when attempting this scenario is configuring Excel Services to use Delegation (i.e. to use Kerberos rather than NTLM). This is a setting that you can only set by using STSADM.exe; you cannot set it through the SharePoint Administration pages and it is not well documented. The discussion thread outlines this step: http://forums.microsoft.com/TechNet/ShowPost.aspx?PostID=1224539&SiteID=17

Follow these steps:

  • On your SharePoint server, open a command prompt and navigate to c:\program files\common files\microsoft shared\web server extensions\12\bin
  • Run the following command where %SSPNAME% is the name of your Shared Service Provider:
    • stsadm.exe -o set-ecssecurity -ssp %SSPNAME% -accessmodel delegation
  • Now run the following command:
    • stsadm.exe -o execadmsvcjobs
  • Now perform and IISRESET

Step 4: Create your Data Connection file

Now Excel Services has been configured, you need to make sure that the data connection has the right settings for Kerberos. Typically in this scenario, a data connection file will be created and stored in a SharePoint data connections library. This ensures that you only have to set the data connection up once and use it many times.

There are several key settings that must be in the data connection file in order for Kerberos to work, these include using the FQDN of the SQL server and adding SSPI=Kerberos to the connection string. Follow these steps:

  • Open Excel 2007 (Client)
  • Go to the 'Data' ribbon
  • In the 'Get external data' area click on 'From Other Sources' and choose 'From Analysis Services'
  • Enter the FQDN of your SQL server here (i.e. server.domain.local, not just server), leave the default of 'Use Windows Authentication' and click Next
  • Choose the database and cube that you wish to connect to and click Next. Click Finish on the following screen.
  • Choose to show a pivot table (this is not relevant and will not be used at this stage) and click OK
  • Once the pivot table is displayed, it is a good idea to test it out to make sure you got the right settings
  • Go to the 'Data' ribbon and click 'Properties'
  • Go to the 'Definition' tab of the connection properties dialog
  • Add ';SSPI=Kerberos' (without the ') at the end of the connection string (after MDX Missing Member Mode=Error)
  • Now Export your data connection to SharePoint by clicking 'Export Connection File'
  • Enter the full URL to the Data connection library that you wish to save you data connection to and click 'Save'.
  • You may now close Excel and disregard the spreadsheet (you have got the data connection in SharePoint which is the bit you need)

Step 5: Configure your site

Now you have created the data connection, you can go ahead and configure your site.

Generally one of the first things to do is to add an 'SQL Server 2005 Analysis Services Filter' webpart which uses the data connection to provide filters to other webparts on your site. This is one of the first places to test Kerberos. When you add the SQL AS Webpart, you will first need to choose the data connection. Upon doing this the Dimension drop-down should populate with dimensions from SQL. If this works then Kerberos is working! J

Useful References

These articles were useful for me when trying to configure this:

Displaying Workbook using external data with periodic refresh in EWA ... this is a good discussion thread on TechNet that talks about some of the Excel Services settings that are required.

How to configure SQL Server 2005 Analysis Services to use Kerberos authentication ... a great MSDN article that covers some of the AS and connection string parameters.

How to use Kerberos authentication in SQL Server ... a very comprehensive article that covers configuring Kerberos for SQL

Configuring Kerberos for SharePoint 2007: Part 1 - Base Configuration for SharePoint

(UPDATED on 04/06/07 as per feedback from two different subscribers (thank-you). Updates in Italic)

(UPDATED on 20/08/07: My colleauge James World has just published an excellent article which is a kind of follow-up to this one. It goes a bit deeper on Kerberos basics and covers some real-world tips that relate specifically to SharePoint. Check it out here: http://blogs.msdn.com/james_world/archive/2007/08/20/essential-guide-to-kerberos-in-sharepoint.aspx )

At some point during a career working with SharePoint, everyone will be given the dubious task of configuring Kerberos authentication. I've done this a few times with SPS 2003 in the past, but despite my previous experience, it is a complex and difficult task to undertake if you don't know how. As with most things, if you have the right info, it is really quite easy.

This is the first of a several-part series that outlines what you need to do to enable Kerberos in a MOSS 2007 environment. This article (part 1) will focus on how to get Kerberos working for just MOSS; the later articles will then expand on that to include Excel Services, Data Connections and SQL Server 2005 Analysis Services.

Why Kerberos?

There are many reasons why Kerberos authentication can be used rather than the default NTLM, the main reason should be because it is faster and more secure than NTLM. It should really be the default choice for any SharePoint deployment on this basis, however in the SharePoint world the main reason is normally to get around the 'double hop' authentication issue.

I am no security expert and I am sure there are better explanations out on the web somewhere (try here) but my simple understanding of a 'double hop' is where a user authenticates to a web server and that web server then needs to impersonate the user against another service. When this happens, the user's authentication ticket is 'hopping' across two services; this is not allowed in NTLM and you will have to user Kerberos to do this.

In SharePoint, 'double hops' are most commonly seen when webparts need to access other web services or databases. In MOSS 2007, the most common scenarios are around Excel Services, Data Connections and connecting to SQL Server Analysis Services cubes. (I.e. 'hopping' from the Excel services webpart to the SQL analysis cube).

Step 1: SPNs

The first thing you need to do in order to enable Kerberos for SharePoint is configure Service Principle Names (SPNs) for your SharePoint service accounts in Active Directory. Here lies the first stumbling block... depending on your configuration it is very hard to figure out which SPNs need to be applied to which accounts.

If you are installing SharePoint properly, you'll use the 'least privilege account principle'; this basically means that each distinct service inside the SharePoint farm will have its own domain user account. These accounts should have the minimum privileges that they need to perform their jobs. There is a great document which goes into detail on each different account (8+ accounts) here, however in summary, you should have the following accounts:

  • SQL Server Service Account: Account used by SQL to run all SQL services
  • Server Farm Account
  • SSP Service Account
  • Office SharePoint Server Search Account
  • Default Content Access Account
  • User Profile and Properties Content Access Account
  • Excel Services Unattended Account
  • One account per application pool: This is typically three accounts; SSPAdministration, MySite and your main 'Portal' or 'Intranet'.

SPNs are used by Kerberos to ensure that only certain accounts have permission to delegate a specific service on a user's behalf. An SPN needs to be configured for each service and address that the account needs to delegate for. SPNs are configured by using SetSPN.exe (download here) which is a command line  provided as part of the Windows 2003 resource kit. This table outlines the commands that are required to create the right SPNs for each of the relevant SharePoint service accounts, however please bear the following points in mind:

  • Some services require the fully qualified domain name (FQDN) even if your users only use the host name. For example if user type http://portal to get to you main portal and you Active Directory is called Domain.local then the FQDN is Portal.Domain.Local
  • Some SPNs require the host name which is the FQDN without the .domain.local bit on the end. In the example above, this would simply be portal
  • For all user accounts you must include the domain prefix.
  • To make the table easier to understand, I have included an example for a single server farm in a domain called 'Domain.local' where the MOSS server is called 'Server' and I have three host headers for web applications which are called 'My Site', 'Portal' and 'SSPAdmin'. The 'least privilege account principle' has been used in this example and the accounts are fairly descriptively named.

Command

Notes

Setspn.exe -A HTTP/%SHAREPOINTSERVERFQDN% %SERVERFARMACCOUNT%

%SHAREPOINTSERVERFQDN% = the FQDN of your SharePoint server's NetBIOS name (local machine name)

%SERVERFARMACCOUNT% = Server Farm Account

Example: Setspn.exe -A HTTP/server.domain.local domain\serverfarm

Setspn.exe -A HTTP/%MYSITEURLFQDN% %MYSITEAPPPOOLACCOUNT%

%MYSITEURLFQDN% = the FQDN of the host header for the My Site Web Application

%MYSITEAPPPOOLACCOUNT% = The application pool account that the My Site web application uses

Example: Setspn.exe -A HTTP/mysite.domain.local domain\mysiteapppool or Setspn.exe -A HTTP/server.domain.local domain\mysiteapppool

Setspn.exe -A HTTP/%MYSITEURLHOST% %MYSITEAPPPOOLACCOUNT%

%MYSITEURLHOST% = the host name (i.e. without the .domain.local bit) for the My Site web application

%MYSITEAPPPOOLACCOUNT% = The application pool account that the My Site web application uses

Example: Setspn.exe -A HTTP/mysite domain\mysiteapppool or Setspn.exe -A HTTP/server domain\mysiteapppool

Setspn.exe -A HTTP/%PORTALURLFQDN% %PORTALAPPPOOLACCOUNT%

%PORTALURLFQDN% = the FQDN of the host header for the main portal or intranet Web Application

%MYSITEAPPPOOLACCOUNT% = The application pool account that the Portal web application uses

Example: Setspn.exe -A HTTP/portal.domain.local domain\portalapppool

Setspn.exe -A HTTP/%PORTALURLHOST% %PORTALAPPPOOLACCOUNT%

% PORTALURLHOST % = the host name (i.e. without the .domain.local bit) for the Portal web application

%MYSITEAPPPOOLACCOUNT% = The application pool account that the Portal web application uses

Example: Setspn.exe -A HTTP/portal domain\portalapppool

Setspn.exe -A HTTP/%SSPADMINURLFQDN% %SSPADMINAPPPOOLACCOUNT%

% SSPADMINURLFQDN % = the FQDN of the host header for the SSP Administration Web Application

% SSPADMINAPPPOOLACCOUNT % = The application pool account that the SSP Administration web application uses

Example: Setspn.exe -A HTTP/sspadmin.domain.local domain\sspadminapppool

Setspn.exe -A HTTP/%SSPADMINURLHOST% %SSPADMINAPPPOOLACCOUNT%

% SSPADMINURLHOST % = the host name (i.e. without the .domain.local bit) for the SSP Administration web application

% SSPADMINAPPPOOLACCOUNT % = The application pool account that the SSP Administration web application uses

Example: Setspn.exe -A HTTP/sspadmin domain\sspadminapppool

Step 2: Trust for Delegation

In addition to setting the SPNs for each of your service accounts, you also need to trust each of the computer accounts and some of the service accounts for delegation. Trusting for delegation means that the accounts are allowed to delegate on a user's behalf.

In order to trust for delegation you need to open Active Directory Users and Computers as a user with domain administration rights and follow these instructions

  • Repeat the process for each of the following
    • MOSS Server (Computer Account)
    • SQL Server (Computer Account)
    • FarmService (User Account)
    • MySiteAppPool (User Account)
    • SSPAdminAppPool (User Account)
    • PortalAppPool (User Account)
  • Locate the account and click 'properties'
  • Navigate to the 'Delegation' tab
  • Choose 'Trust this user/computer for delegation to any service (Kerberos)'

Step 3: Enable Kerberos on your web applications

In MOSS 2007, the switch between Kerberos and NTLM is very simple and is undertaken via Central Administration.

If you are creating your farm from scratch, be sure to set Central Administration itself to use Kerberos which you can set as part of the 'SharePoint Products and Technologies Configuration Wizard', however if the farm is pre-created you can easily enable Kerberos by following these steps:

  • Open Central Administration
  • Navigation to Application Management > Authentication Providers
  • Choose the web application you wish to configure from the drop-down in the top right corner (this includes the Central Administration web application)
  • Click on 'Default'
  • Set the authentication to Negotiate (Kerberos)
  • IISRESET

Step 4: Enable Kerberos on your SSP

In this step you enable Kerberos on your SSP. Follow these steps:

  • Open a Command Prompt and navigate to your '12\Bin' directory (normally c:\program files\common files\microsoft shared\web server extensions\12\bin) 
  • Run 'STSADM.exe -o SetSharedWebServiceAuthn -negotiate'

Step 5: Component Services Configuration

This is one of the lesser documented steps. You need to set various permissions in Component Services. Follow these steps:

  • Open Component Services on the MOSS server
  • Navigation to Component Services > Computers > My Computer
  • Click on Properties (for My Computer) > Default Properties > Default Impersonation Level = Delegate (see http://support.microsoft.com/kb/917409)
  • Navigate to Component Services > Computers > My Computer > DCOM Config > IIS WAMREG Admin Service
  • Click on Properties (for IIS WAMREG Admin Service) and navigate to the Security tab
  • Edit Launch and Activate Permissions
  • Grant all three of your application pool account 'Local Activation' permissions (see http://support.microsoft.com/kb/920783). In our example, these accounts would be domain\MySiteAppPool, domain\SSPAdminAppPool, domain\PortalAppPool

How do you know it has worked?

The thing with Kerberos is that it can be difficult to see if it is working properly. There are several things you can do to check:

  • Do your web applications work from a client computer? If they do, then this is a good sign
  • Keep an eye on your System event log on both your MOSS and SQL servers. Kerberos related errors are logged here.
  • Make sure all the servers in the loop (MOSS, SQL and Domain Controllers) have the same time set. Inconsistent time settings are one of the primary causes of Kerberos related issues.

If you have further difficulties, try these articles:

How to install SharePoint Server 2007 on a single machine

One of my first ever blog articles (and by far most popular to date) was a set of instructions on how to install Beta1 of SharePoint Server 2007 on a single machine. I removed this article because it was too much of an overhead updating it with the various Betas and the official guides were being developed. Now that SharePoint is RTM, I do still get a lot of questions from customers on how to do a simple installation of SharePoint (with SQL 2005) on a single machine to be used for a stand-alone development, demonstration or simple 'play-pen' server (normally on a virtual machine). This guide will outline all of the main steps to setup such an environment.

Please bear in mind that this is just an unofficial guide to getting SharePoint 2007 installed quickly and easily in a demo / test environment. This guide will not necessarily observe best practices with regard to security etc. For production setups, you should seek guidance from the official documentation which is available on TechNet (http://technet2.microsoft.com/Office/en-us/library/3e3b8737-c6a3-4e2c-a35f-f0095d952b781033.mspx?mfr=true).

Pre-Install

There are several things that you must do before you even insert the SharePoint 2007 CD they are:

  • Install Windows 2003 R2 with the latest service pack (2 at time of writing) and all of the latest Windows Updates.

NOTE: Please do not use NewSID to change the SID of the machine if you are using a copy of another VM, this breaks things in SharePoint. My advice is to build Windows from fresh or to use Sysprep if you are using a copy of a VM.

  • Join your machine to a domain or create a domain by running DCPromo.exe from the Start > Run dialog.
  • Install the .net frameworks v3.0 and v2.0 from Windows Update. You can also download the full redistributable packages if your server is not online.
  • Install Windows 'Application Server' from Add/Remove Programs in Control Panel with default settings
  • Prepare a service account in your active directory domain to use for all Sharepoint services.

NOTE: Do not use the main domain\administrator account. This causes a problem if ever you wish to install Project Server 2007 on the same machine.

  • Give your service account local administrator rights and logon as this account throughout the entire installation process.
  • Install SQL 2005 (and latest service pack) with typical settings.
  • Assign your service account to the 'Security Administrators' and 'Database Creators' server roles in SQL server (You will need to use SQL Server Management Studio).

Base SharePoint Server Install

You are now ready to install SharePoint 2007 itself, follow these steps:

  • Login as your service account
  • Insert your CD (or attach your ISO image) and run setup.exe if it does not autorun.

NOTE: If you get an error about web service extensions here, ensure that 'ASP.net V2.0.50727' web service extension is allowed in IIS. If it is not in the list, perform a 'repair' on .net 3.0 framework using add/remove programs and then the web service extension will appear in the list. This is caused when IIS is installed after the .net framework

  • Enter your CD key and accept the license agreement.
  • Choose 'Advanced' on the installation type dialog.

NOTE: The definition of 'Advanced' means that you are using full SQL server (which may or may not be on the same machine). If you had selected 'Basic' then it would have installed the cut down version of SQL (MSDE).

  • Select 'Complete' on the Server Type screen and click 'Install Now'. The setup will now commence and you'll get a blue progress bar.
  • Once installed you will get a screen with a check box that reads "Run the SharePoint products and Technologies Wizard now". Ensure this is ticked and click 'Close'.
  • After a short pause, you'll get a 'Welcome' screen. Click 'Next'.
  • You will get a warning that the wizard is about to reset several services, click 'Yes'.
  • You'll be asked about the farm configuration, select to 'No, I want to create a new server farm'.
  • Provide the database server (your server name) and your account details (account in the domain\user format). Leave the database name as the default. Click 'Next'.
  • Leave the authentication mode as 'NTLM', set a specific port number is desired (not required) and click 'Next'.

NOTE: In a production environment, you would most likely use Kerberos where possible (if your infrastructure supports it).

  • You'll get a summary screen; click 'Next' to kick-off the process.

NOTE: If it fails here, it is most likely that you do not SQL setup correctly. Ensure your service account is in the right groups. Please also note that this section can take a very long time, especially step 2 (up to 45 minutes).

  • You'll get a success screen at the end, click 'Finish'.
  • The wizard will attempt to load the central administration window. You may need to login here, use your service account. You may also get prompted to add the site to your trusted sites; go ahead and do that.

NOTE: This authentication prompt is caused by the secure version of IE on Windows 2003 Server. You can turn if off by modifying the security settings in IE.

Services on Server Configuration

The first bit of configuration to do is set your server to host all services. You do not strictly have to enable all of these services, but I find it helps if you are using the machine to test / investigate functionality.

  • When the Central Administration screen appears, go to 'Operations' tab, then 'Services on Server'.
  • Start the 'Document Conversions Load Balancer Service'.
  • Start the 'Document Conversions Launcher Service', you'll have to choose the 'Load Balancer Server'; there should only be one option. If there are no options, ensure that the 'Document Conversions Load Balancer Service' has been started.
  • Start the 'Excel Calculation Services'.
  • Start the 'Office SharePoint Servers Search' service, observing the following guidelines:
    • Tick both Query and Indexing check boxes
    • Specify a contact email address (this can be any address)
    • Enter your service account in the 'Farm Search Service Account' section
    • Accept all other defaults and click 'Start'
  • Leave all remaining services in their default configuration

Web Application Setup

The next stage is to create the 3 web applications that will be required to host the basic set of sites for a typical deployment, these are:

  • Shared Service Provider Administration Site (Recommended to be called 'SSPAdmin')
  • My Site Host (Recommended to be called 'MySite')
  • The Main Intranet (or 'Portal') Site (Recommended to be called 'Intranet')

It is much simpler if all of these sites are on port 80 in IIS; this means that you do not have to remember to enter the ports all of the time. However having all three sites on port 80 means that each needs their own Host Header (required by IIS to differentiate between sites on the same port). The simplest way to do this is to create new 'Host (A)' records in DNS for each of your three sites. These should point to the IP address of your server; to do this follows these steps:

  • Open the DNS Management tool from Administration Tools on your domain controller
  • Navigate to your DNS zone
  • Create new 'Host (A)' record
  • Enter the Host header (i.e. 'SSPAdmin', 'MySite' or 'Intranet') for the site and the IP address of your server
  • Click 'Add Host' and repeat for each of the three sites

Now the DNS entries are configured, we can create the three web applications in SharePoint; follow these steps for all three of your web applications (i.e. 'SSPAdmin', 'MySite' or 'Intranet'):

  • In Central Administration, go to the 'Application Management' tab
  • Click 'Create or Extend Web Application' and then click 'Create a new Web Application'
  • Fill out the new web application screen observing the following points:
    • Change the New IIS Site description to read something like 'SharePoint – 80 - <Host header name>' where <Host header name> is the name of the web application your are creating (i.e. 'SSPAdmin', 'MySite' or 'Intranet')
    • Ensure the 'Port' is set to 80
    • Set the 'Host Header' to match the DNS record you created (i.e. 'SSPAdmin', 'MySite' or 'Intranet')
    • Change the 'Application Pool Name' to match the 'New IIS Site Description'
    • Enter your service account for the Application Pool account settings
    • Change the 'Database Name' to read something like 'WSS_Content_<Host header name>' where <Host header name> is the name of the web application your are creating (i.e. 'SSPAdmin', 'MySite' or 'Intranet')
    • Leave all other settings on default and click 'OK'
  • Repeat for all three web applications (i.e. 'SSPAdmin', 'MySite' or 'Intranet')

Shared Service Provider Setup

The next stage is to create the Shared Service Provider (SSP). The SSP is required in order to provide several key services such as Search or My Site. You can read more about SSP on my blog article about it here. To configure the SSP, follow these steps:

  • In Central Administration, go to the 'Application Management' tab
  • In the 'Office SharePoint Server Shared Services' section, click 'Create or Configure This Farms' Shared Services'
  • Click 'New SSP'
  • Fill out the 'New Shared Services Provider' screen observing the following guidelines:
    • For the 'SSP Administration Site' web application (the first one you get asked for), choose the web application that you created earlier (suggested name was 'SharePoint – 80 - SSPAdmin')
    • For the 'My Site Location' web application (the second one you get asked for), choose the web application you created earlier (suggested name was 'SharePoint – 80 - MySite')
    • Enter your service account for the 'SSP Service Credentials'
    • Leave all other settings on default and click 'OK'
  • The creation of an SSP can take some time (up to 1 hour on a virtual machine). When it is finished you will see a 'Success!' screen, Click OK.

Collaboration Portal Site Collection Setup

The next stage is to create a collaboration portal which is one of the more feature-filled site types and represents a typical intranet environment. To do this, follow these steps:

  • In Central Administration, go to the 'Application Management' tab
  • In the 'SharePoint Site Management' section, choose 'Create Site Collection'
  • Fill out the 'Create Site Collection' observing the following guidelines:
    • Ensure you have selected the 'Intranet' web application you created earlier (suggested name was 'Intranet')
    • Give your site a title ('Intranet' is suggested)
    • In the 'Template Selection' section, choose 'Collaboration Portal' from 'Publishing' tab
    • Enter you service account for the 'Primary Site Collection Administrator'
    • Leave all other settings on default and click 'OK'
  • When the 'Top-Level Site Successfully Created' message appears you have created the site, simply click the link that is provided (something like http://intranet)

Configure Indexing

The final step of the process is to configure indexing so that you have some search results. Though this step is optional, it is recommended as it will enable you to use the powerful search capabilities of SharePoint. To configure the index, follow these steps:

  • In Central Administration, click the 'SharedServices1' link on the left-side navigation (or whatever you name your SSP)
  • When the SSP Administration site appears, click on 'Search Settings' in the 'Search' section
  • On the 'Configure Search Settings' page, click 'Content Sources and Crawl Schedules'
  • Edit the 'Local office SharePoint Server Sites' content source by hovering your mouse over it and choosing 'Edit'
  • Fill out the 'Edit Content Source' observing the following guidelines:
    • Set a full crawl schedule to be at least once a day
    • Set a incremental crawl schedule for every 10 minutes
    • Tick the 'Start Full Crawl of this Content Source' tick-box
    • Click 'OK'
  • A crawl will now start. Initial crawls normally take up to 10 minutes.

The process is now complete. User should be able to access the main collaboration portal from http://intranet (or whatever you called the DNS record).

I hope this was useful, please comment with any errors or amendments

How Groovy is Groove?

As some of you may have noticed from my lack of recent posts, I’m working on a fairly intense MOSS deployment project right now (apologies, will blog as much as I can). We are using Groove 2007 as our primary collaboration tool within the project and I thought I’d share my thoughts on exactly how Groovy we have found Groove to be......

 

So what is Groove?

OK, so I could spend a whole article explaining what Groove is (and is not), but that is not my intention here. Therefore if you have never ‘got Groovy’ before, you might want to find an article that gives you the high level view like this one from Mark Wilson or you could try Mark Olson's blog (Groove product team) or grab the trial version from here.

 

For those that require a refresher, Groove is a peer-to-peer client-side collaboration application that enables network and organisation independent collaboration. In a nutshell, Groove allows you to share files and other bits with people from different organisations across whichever network you like (Inc public internet). Groove does have a server aspect, but you can work perfectly well just using the client.

 

Project background

We are deploying MOSS to a large customer and therefore, we have about 10 full-time team members working on the design and planning for the project. 5 of the team members are from Microsoft, 3 from 3 different partners and 2 from the customer (which makes 5 different organisations in total)

In terms of network, we were all connected by a very un-reliable wireless LAN (up and down throughout the day) or public internet via home, hotels or MS offices.

 

What has worked well?

This is what has worked really well:

·         Using Groove has really cut down on all the inter-team emailing we did. Everyone knows that the latest copy of something is in Groove and that is all there is to it. We spent much less time chasing and waiting for documents that if we’d used a file system.

·         The IM and presence capabilities were really useful. Although all the Microsoft guys have communicator, being able to IM the partner/customer team members and see if they are online or actively using the workspace has been very useful indeed.

·         We’ve made use of the ‘notes’ tool to store contact information. It would have been nice to be able to sync this with Outlook, but the plain text notes served their purpose.

·         By everyone having Groove, it serves as an unofficial backup repository because essentially every user has a copy of all document on their local machine

·         The peer-to-peer nature  of Groove means that physical location really is not important, so long as you have at least an internet connection (which is great for me because I live about 80 miles from the customer office J )

·         We have had lots of ‘new starters’ on the project and it is very good to be able to say “everything is in Groove” in terms of giving them project documentation

·         We were able to store remote desktop connection files to all our dev servers (13 of them). By having the RDP files in Groove with passwords embedded. No-one needs to worry about server names or passwords; they just double-click the RDP file.

·         Other people from within Microsoft have wanted to take a look at our designs on several occasions. Being about 50Mb in total, email has been out of the question, but the capability to add them as a temporary Groove user and allow them to browse the workspace has been really useful.

 

Not so good

There have been a few areas where the experience has been slightly lacking. They are generally quite minor, but here goes...

·         There is a feeling that the capabilities and Office integration could be better. Don't get me wrong .. there are lots of things in Groove that do integrate well with Office and lots of good collaboration tools, but there are areas that are lacking a bit. For example, it would have been great to have the calendar and contacts capabilities linked directly into Outlook. I have also missed the document check-out & version history features that SharePoint provides and the more advanced real-time collaboration features in Office Communicator or Vista Meeting Space.

·         We use a WSS 2.0 site as our official deliverable repository and Groove has no direct integration which means we have to manually copy everything up there on a weekly basis. Groove 2007 does have very good integration with WSS 3.0, but not WSS 2.0 so for our puposes we had a gap here. Clearly, as WSS 3.0 becomes more popular, this problem will go away, but for now it is one extra task.

·         If you are using Groove directly (i.e. opening and editing directly out of Groove), you have to confirm each time you save a document and everyone else gets a notification – this can get very annoying.

 

What I’d do different next time

Lessons learnt and things that I’d do differently on the next project:

·         Out of the team, I think that I’ve been the only person brave enough to work directly from Groove. I.e. I have not maintained a local copy of my documents, but have opened and edited directly out of Groove. This ensures that the latest copy of all my content is always in Groove. Some of the other guys have not taken this approach and have tended to work locally and then do a manual upload once they have reached a certain milestone. The down side to this is that a) they have to remember to upload and b) The latest content is not always in Groove. Next time round, I’d probably try to enforce a practice where everyone works directly from Groove rather than maintaining local copies and uploading.

·         By using Groove, we’ve put together a structure that probably reflects an average MOSS project. Next time round, I’d probably save this as a template and start the workspace based on that template.

·         I work harder on encouraging all users to use Groove. In my case, this would include the staff from the customer who could not easily install Groove on their production machines (had to rely on using their home PCs and copying every night).

·         I’d probably look to establish a collection of links to key documents for the purpose of on-boarding

 

Conclusion

Groove does feel like a young product and lacks some of the key features that you take for granted with other Office products and especially SharePoint. There are lots of great collaboration features and ideas in the product and good integration with WSS 3.0, but you are often left thinking “if only it did X, Y or Z”.

 

Having said that, the fact that Groove is peer-to-peer and has no network dependencies has really paid dividends on this project as it has enabled cross-organisation collaboration for the whole team. This feature alone more than makes-up for Groove’s short-comings around collaboration features and Office integration. I really feel that collaboration would not have been anywhere near as straight forward without it.

 

Added to the above, Groove has given the whole team collaboration tools that have been invaluable (such as chat, IM, presence, calendaring etc) and whilst they do not match the might of SharePoint & co, they have been useful on the project and we’d have been that little bit less-collaborative without them.

 

I would certainly look to use Groove again on future projects and if the “What I’d do different next time” learning’s are observed, it makes for a great tool to help run small project teams and I’d recommend it without hesitating.

 

I hope this was useful.

Posted by Martin.Kearn@Microsoft.com | 5 Comments
Filed under:

What is the Business Data Catalogue?

..... In short, the Business Data Catalogue (BDC) is without doubt the most powerful feature in MOSS 2007! (In my opinion)..... I know this is a rather bold statement and hopefully this article will go some way to convincing you of the same!

So what does BDC actually do?

The BDC is a feature of MOSS that allows you to connect your business data systems to MOSS and use data from those systems in one of 4 main presentation methods. When I say 'Business Data System' what I'm referring to there is basically anything you can get to via ADO.net (SQL, Oracle, ODBC, and OLEDB) or web services. Throughout this article, we'll use the Adventure Works sample database in SQL 2005 as our 'Business Data System'.

BDC Webparts

The easiest presentation method to understand is the BDC webparts. There are several webparts provided out-of-the-box with MOSS which work together to provide various views on your BDC data.

The first one is the BDC List webpart. This webpart will simply display your data in a list form with all of the filtering and sorting capabilities that you'd expect in a list view webpart. It even has a built-in search interface which allows users to perform mini searches on the contents of the list. The scenario here is that you may have a list of 'resellers', including some of the key information that you might have about those resellers such as geography, address phone etc.

The BDC List is nicely complimented by the BDC List Item webpart which, when connected (using standard MOSS webpart connections) to the BDC List will display further details for the item that is selected. The idea is that you click a 'reseller' out of the BDC List of resellers and the BDC List Item webpart displays that reseller's full profile.

 

Other webparts include related list, which is useful for showing sub-lists of information. In the Adventure Works system, this can be used by having a BDC List displaying all of the product categories and the BDC Related List showing the sub-categories of the category that is selected in the BDC List webpart. Again, this works via webpart connections.

BDC Search

BDC applications can be 'indexed' by the standard MOSS index service. This means that users can search across the business systems amongst all of the other data in the MOSS index. Results are presented in the same way as other documents and when the users click on a result, them get sent to an out-of-the-box ASPX page that shows all of the data that is available for that item. The BDC applications are treated as normal content sources and can be managed in exactly the same way (schedules, scopes etc).

This feature is great for integrating CRM systems into SharePoint and allowing users to search across customers and partners and get phone numbers etc. This also has applications if you have products in your BDC system; users could search for the product name and return things like financial data from the BDC system amongst document-based results from elsewhere in MOSS.

BDC Columns

One of the new column types in MOSS is 'Business Data'. If you select a business data column, users will be able to choose an entity from the BDC to store as the value of a column (metadata).

Once chosen, the column will then pull other fields that are related to the chosen BDC entity and display them in your document library or list as normal (read-only) columns. For example, if you have a document that you are writing for a customer, you might select the customer name for the business data column and the system will then display the phone number, address, website, key contact etc for that customer as part of the document metadata.

 

Having these details displayed in your list views and webparts is great, but like all columns, this data also gets stored in the document itself and if you have Office 2007 professional, you can edit and view this data directly from within office.

BDC Profiles

Like BDC columns, you can also create 'business data' properties in the MOSS user profile database. This means that the user profile can now be a mixture of MOSS-based, Active Directory and business data information.

The scenario here is that you might hook the BDC up to your HR system and have key fields from the HR system imported into the BDC and displayed as part of the standard user profile. This solves the "where do I store my personnel data" problem that many organisations face; it does not matter where the data is stored ... simply have BDC pull it in from whatever systems it is in today.

What can I do with my data once I have it in MOSS?

All of the things I have discussed so far have been about reading the data from your business system and displaying it in various formats. You can also perform actions on this data and use bits of the data as parameters to a URL.

One scenario where Actions are used is performing internet searches on customers or resellers from your BDC system. If users clicked on the 'internet search' action, the system would pass the reseller name into the URL of an internet search engine such as Windows Live Search.

 

This works by admins configuring markers in the URL that are replaced by BDC properties, for example if you did want to perform an internet search, you'd configure an action that used this URL http://beta.search.live.com/results.aspx?q={0} where {0} is replaced by the 'reseller name' of the BDC entity that is action is based on. This works with any URL, for example if (for some weird reason), Windows Live is not your favoured search engine, you could use Google as follows: http://www.google.co.uk/search?q={0}

The same principle can also be applied to passing an address into Windows Live Local and displaying a map of your customer's office. For this, you would use this URL http://local.live.com/default.aspx?where1={0}%20{1}&v=2 where {0} is the postal code and {1} is the country name of your customer.

How do I get started?

By far the easiest and most compelling way to get started with BDC is to install the SQL 2005 Adventure Works sample database, to do this you will need:

  • MOSS Beta2 TR Enterprise Edition (BDC is an enterprise edition only feature) installed
  • SQL 2005 installed with the Adventure Works DW database which you can get from Control Panel > Add/Remove Programs > Change SQL 2005 > Workstation Components > Sample Databases
  • The Adventure Works BDC application definition which is available here: http://msdn2.microsoft.com/en-us/library/ms494876.aspx

Simply import the BDC application definition file (via Shared Services Admin interface) and away you go!

How do I use BDC anywhere other than demo-land?

If you want to use BDC with your own applications and systems (which hopefully, you will! J), you'll need to write an application definition file. This is basically a big XML file which sets out the metadata of the system you are connecting to. You can write it from scratch using the excellent SDK examples which are here http://msdn2.microsoft.com/en-us/library/ms563661.aspx.

There are also two great tools for helping you created your own definition files:

So is BDC the "most powerful feature in MOSS 2007"?

I think it is because when you sit back and think about all those webparts and custom applications we used to write for Sharepoint 2003, I'd say that BDC removes the need to write custom code (C#, VB etc) to achieve the same results in MOSS for most cases. In many cases, you get a much better result with features that would have taken eternity to try and code yourself (search, profiles etc). Added to that, we get all of the 'plumbing' work like security, performance, deployment etc managed for us.

On this basis, I think BDC will significantly reduce the custom code footprint on most MOSS deployments. Reducing the custom code footprint is one of the best ways of improving stability, performance and overall TCO for a MOSS deployment, which is why I feel BDC is the "most powerful feature in MOSS 2007" .... Discuss J

Posted by Martin.Kearn@Microsoft.com | 32 Comments
Filed under:

MOSS Architecture and Shared Services

I have been doing some work recently on MOSS architecture for large deployments and thought that I’d share some of my findings. MOSS architecture is very similar to SharePoint 2003 in some ways but different in a few crucial areas.

So what is the same?

MOSS adopts a typical 3-tier model with web servers at the front, application servers in the middle and a database server at the back where all the data and config is stored.

The front-end web servers are simple web servers that can be network load balanced to achieve additional performance and fault tolerance (like 2003). The backend database is a typical SQL 2005 database service and can be clustered as you’d expect.

So what is different?

The interesting bit is what goes on in the middle. With MOSS, it is mandatory to have a Shared Service Provider. This is a collection of application servers that provide shared services out to any portals or sites that need them. These services include:

  • Search
  • Index
  • Audience compilation
  • User profiles database
  • My Sites
  • Business Data Catalogue
  • Excel Services

Any of the above services can exist on any number of servers within the SSP. For example, for a small-ish deployment you could have them all on one box, or you could scale them out onto different boxes as you see fit. There are no rules that govern where these services reside within the SSP or how many servers you have servicing them (with the exception of the Index server - only one per SSP). For example if you want 10 search servers – got for it ... “fill your boots” as we’d say here in England!

This model is very similar to the 2003 approach with one crucial difference,  the SSP has no portal affiliation. This means that you are not forced to have a specific parent/child style portal topology in order to use Shared Services which was one of the big sticking points with Sharepoint 2003 shared services.

So what does the ‘Portal’ actually do now?

For starters, it is now called ‘Collaboration Portal', not ‘portal’ and it is just another type of site collection that is hosted on an IIS site (called web applications in MOSS). Portals no longer contain any application services such as search, my site etc – all these services now have to come from an SSP. This means that all you need to host a portal is a web server and a place to put the content database.

Different portals can live on their own hardware which is completely isolated from any other hardware other than the fact that it consumes services from a centrally managed SSP. Alternatively, you can put some of your portals on shared hardware and some on dedicated.

I always hear requirements around different business units wanting their own portal which has its own visual style, custom webparts, different SLAs etc . With this model, there does not have to be any affiliation between any portals or sites if it is not required.

This diagram outlines the logic of how SSP provide services that are consumed by several site collections:

So does this mean that ‘Supported Farm configurations’ have gone?

In short, yes!

This model means that you can scale any element of the system out as you see fit. However, there are several recommended server layouts that will meet most scenarios. These broadly follow the small, medium and large models of Sharepoint 2003, but should be considered as starting points only. You can easily deviate to a different setup depending on your requirements.

So how does all this map to physical servers?

All three tiers (web, application, database) of the SharePoint model can be hosted on a single machine or scaled out to a huge collection of servers to meet the requirements.

Most organisations will want some level of fault tolerance and separation between server roles. Typically these kind of organisations will have at least 2 web servers running your portals and sites, at least one application server hosting all services (maybe a second for fault tolerance) and one database cluster. This diagram shows this model:

Larger organisations may want to have separate web servers for each of their portals, sites and my sites. They may also have multiple application servers as part of the SSP. This diagram describes this model:

I hope this was usefull. There is an increasing amount of content on the public Microsoft sites now about this stuff, so be sure to have a dig around.

SharePoint on your Phone!

One of the interesting new features in MOSS 2007 is the support around mobile devices. In this article, I’ll aim to give you a quick overview of how you can get the next version of SharePoint on your phone.

What are Mobile Views?

Every list and library in MOSS 2007 or WSSv3 is capable of hosting ‘Mobile Views’. These are standard views of lists or libraries that an administrator has defined as being mobile enabled. You can also view individual list items in mobile form.

This is a picture of the mobile view for a standard task item.

How do you navigate to these Mobile Views?

Every site has a mobile home. You can get to it by simply appending an ‘m’ on the end of the URL. For example the mobile view for the following URL http://<server>/TestSite can be accessed by http://<server>/TestSite/m.  

From the mobile home you can navigate through the lists, libraries and list items in the site.

This picture shows the mobile home of a standard team site

How do I configure Mobile Views?

Each list has a default mobile view, but you can configure any normal view as being ‘mobile’. This is all done through the same interface that you’d use to modify view filters, sorts etc.

This picture shows the UI for enabling a normal view as being ‘mobile’

When you access a list using your device, you can use a drop-down to choose the most appropriate view. However, generally speaking the most sensible views for a mobile device are pre-configured as the default mobile view. For example, the default for a tasks list is ‘my tasks’.

How do I play with this more?

The easiest way to investigate this further is to get the Microsoft Windows Mobile emulator from http://msdn.microsoft.com/mobility/windowsmobile/downloads/emulatorpreview/default.aspx. Follow the instructions on the page for getting onto Betaplace and downloading the emulator.

Once you have the installation file, I suggest that you install it directly onto your SharePoint server. This way it is much easier to configure the networking between the server and the emulator.

The emulator will allow you to emulate a smart phone or PDA. I found that the PDA is easiest to work with. Follow these instructions to get a mobile view of SharePoint on your PDA emulator (you should be able to adapt them for SmartPhone if you are familiar with the SmartPhone interface)

-          Install the emulator and start the ‘Emulate Pocket PC-WM 2003 SE(Cold Boot)’ from your start menu

-          Map your real network card to the device by going to File > Configure > Network Tab > Enable ‘NE2000 PCMCIA adapter and bind to’ and click ‘OK’

Note: All of the following instructions are for the device interface itself, not the emulator application, unless otherwise stated.

-          Go to ‘Settings’ from the start menu

-          Click on ‘Network Cards’

-          Choose ‘The Internet’ on the ‘My network card connects to’ drop-down

-          Click on ‘NE2000 Compatible Adapter’

-          Set your IP and Name Server settings in accordance with your environment (it needs to be in the same subnet as your server).

-          Click ‘OK’ until you are back to your home screen

-          On the emulator application, disable and re-enable the network card mapping from File > Configure > Network Tab > Enable ‘NE2000 PCMCIA adapter and bind to’ (this is the equivalent to unplugging the PCMCIA card, you’ll see the icon change on the device screen)

-          On the device, wait for the network icon to show that it has re-connected.

-          You will get a new icon at the top of the device screen. Click on it and choose ‘This network card connects me to the internet’

-          Load Internet Explorer from the start menu and type your portal URL with an /m at the end

-          Enter login credentials and the mobile home should appear

 I hope this was interesting.

What is new with Columns?

Columns have always been one of the most powerful features in SharePoint as they allow you to slice and dice you data into different views that provide very compelling information to the end users. In MOSS 2007, columns have received a facelift and in this article I’ll aim to tell you what is new and how columns have been improved.

For the sake of clarity, when I’m referring to a column, I am talking about the columns that you would add to a list or library and use to define metadata for a document or list items that are contained within. I’ll also refer to libraries and documents exclusively throughout this article, but that also include lists and list items (just too lazy to write ‘library/list’ or ‘list item/document’ every time!).

What has not changed?
Columns in MOSS 2007 still adopt the same basic principles as in the 2003 suite. A column is still part of a library and when you add a document to that library you have to provide values for the columns. The data you provide acts as the metadata for that document and can be used for many things including:

  • Views on the library
  • Webparts
  • Search queries
  • Workflow

Columns still have a variety of types. All of the old types are still there (single line of text, number, date etc) but a few new ones have been added (which I’ll discuss later)
Columns are still the main data source for webparts and views.

What were the main issues with 2003 columns?
In the 2003 suite, columns were very useful and were enthusiastically used to build applications and tools based on SharePoint data. However, in my opinion they had several key draw-backs, which were:

1. No central management
Columns we not centrally managed across the portal, instead they were managed at the library level. This meant that you never had central control over your corporate metadata taxonomy which is an issue for most organisations, especially those that are concerned with compliance issues such as FOI or SOX.

For example, if you had a company-wide column called ‘Offices’ which you applied to every document library and you suddenly find yourself with new offices; there was no real way of retrospectively adding the new column values to the existing libraries. In practice if you needed to update all of your columns, you either had to manually visit every document library, or write some kind of script that used the object model to update the libraries. Both methods were time consuming and expensive.

2. Limited range of types
In 2003, you only had a limited range of types for each column. The types on offer did the job for most scenarios, but not all. You’ll see later in this article how several new types are now available.

3. Only defined at the list/library level
In 2003, the columns were defined at the library level which meant that every item in that library had to have the same metadata. This dictated the whole approach around how the lists and libraries were designed.

If you had a document that needed a different set of metadata, you had to have a whole new library just for that document, which clearly does not make sense.
Because of this restrictive approach, it became impossible to build a library structure based on corporate taxonomies; instead they were based on document types.

So what is new?
OK, so here is the interesting bit…. Unsurprisingly, my take on what is new directly maps to the weak areas in the 2003 platform, here goes:

1. Column templates: portal-wide management of column definitions
In MOSS 2007, when you add a column to a library, you now have two choices:

  • Create a new Colum directly on that library (2003 style)
  • Add a column template

This picture shows the interface for adding a column to a library

Column templates are centrally controlled columns that are created by Admins at the portal level. Site owners can simply add a column template to his library and it maintains a connection back to the central column template. This means that when the column template is changed in any way, it also changes on any libraries that have used it.

This addresses the scenario around “what happens when I get extra offices”.

2. New Types
In MOSS 2007, there are several interesting new types in additional to the 2003 types. The new types are:

  • Business Data: Allows you to include data from the Business Data Catalogue (BDC). The BDC is a whole new feature which I’ll probably blog about some time soon. It is basically a way of including business data from external applications in your portal.
  • Audience Targeting: A way of choosing a specific audience, distribution list or sharepoint group to target the document to. Adding this column gives you an audience picker control that you can use to browse the audience, distribution list or sharepoint groups and choose which ones to target the item to.

This picture shows the different types that are available

3. Content Types
Content Types are a whole new feature that allows the behaviour of a piece of content (including templates, columns workflow etc) to be centrally defined and applied to any library in the portal.
This means that libraries can now contain multiple content types and therefore the columns are defined by the content type itself, not the library in which it is placed.

For example, you can have you expense reports in the same library as your reports and they can each have different sets of columns that are driven by the Content Type, not the library (though you can still have library based columns).

This picture shows how columns can be included in Content Types

This is a huge step forward because it means that we can now design library structures based on organisational rules rather than content-driven rules. I’ve written a whole article explaining Content Types in general, check it out here.

But wasn’t all this in SharePoint 2001?
A few people have commented on my last post about Content Types and have drawn the obvious comparisons about this stuff in MOSS 2007 going back to some of the functionality on SharePoint 2001. These comments made me chuckle and it is true that we have come ‘full circle’ (thanks for the comments by the way ;) ).

I think the reason that much of this stuff was removed in SharePoint 2003 was because of the changes in the underlying architecture (WebStore to SQL) and there simply not being enough time to develop these features.

It is good for all of us that they are now here in MOSS 2007!

Cheers

PS: I am never quite sure where my audience is at with these articles. If you do not understand anything, please do not hesitate to comment on the blog or ping me at Martin.Kearn@Microsoft.com and I’ll do my best to answer your question

More Posts Next page »
 
Page view tracker