The Managed Metadata’s  primary purpose is to provide you with a central location to store metadata (commonly defined as data about data) that can be utilised throughout any site within your SharePoint farm.  This is definitely one step ahead of what we referred to as Content Types and Site Columns in SharePoint 2007 where it was cumbersome to deploy to more than one site collection.  I touched upon the Managed Metadata Service Application in my article in Configuring the User Profile Service in SharePoint 2010 as this was a prerequisite for the User Profile Service Application.

Primer on the Managed Metadata Service in SharePoint 2010

Managed Metadata and the word Taxonomy go hand in hand, and as mentioned previously, the Managed metadata service application allows us to formalize our Taxonomy or metadata which will be utilized across the entire farm.

There are a number of concepts that you will need to familiarize yourself with before we embark on the configuration.

Term Store This is the database in which our managed metadata is stored in.

Term is a word or a phrase that can be associated with an item in SharePoint Server 2010.

Term set is a collection of related terms.

There are two types of Terms available within SharePoint 2010.  These are “Managed Terms” and “Enterprise Keywords”.

“Managed terms, commonly referred to as “Taxonomy” are predefined words or phrases that can only be created by users with the appropriate permissions.  We can refer to this special group of users as “Metadata Content Managers”.

“Enterprise keywords, commonly referred to as “Folksonomy” are words or phrases that have been added by the end user.

Now that we have a better understanding on some of the key concepts, let’s deep dive into our setup and configuration of the Managed Metadata Service Application.

Setup the Managed Metadata Service

To setup our Managed Metadata Service, navigate to Central Administration / Application Management / Manage Service Applications.

Click New and select “Managed Metadata Service”

Enter the follow details;

Name: Managed Metadata Service

Database Server: <server_name>

Database Name: Managed Metadata DB

I will utilize the sp_farm account for the Application Pool Identity.

Click Create.

Lastly, navigate to Central Administration / System Settings / Manage services on server and start the Managed Metadata Web Service.

Now that we have successfully setup our Managed Metadata Service, let’s venture into the Term Store Management Tool.  You can do so by navigating to Central Administration / Manage Service Applications and clicking on the newly created Managed Metadata Service.

Note, You can achieve the same by highlighting the service application and clicking on the Manage icon located in the ribbon.

This will launch the below screen which is referred to as the Term Store Management Tool.

Let’s quickly highlight what is made available on this screen.

Available Service Applications: If the farm has been setup with multiple Managed Metadata service applications you can easily navigate and configure each one from the single interface.

Sample Import: Here, Microsoft is providing your designated Metadata Managers with a template import file.  This template can be used as a base of creating your own which can then be later imported.

Term Store Administrators: This is where you would add the designated users which will provide them with the ability to create new term set groups.  By doing so, they will in turn be able to provide the necessary permissions to the group manager role.  Note, users added here have full control of the specified term store.  In the above screen capture, I have gone ahead and added Administrator and myself as Term Store Administrators.

Default Language: This one is self explanatory

Working Languages: In addition to the Default Language, you can also specify additional languages available for translation purposes.

That’s it for now.  Stay tuned for my next article in which I will venture into creating Groups, Term Sets and Terms and demonstrate how we can utilize our managed metadata within our SharePoint sites.

References

Plan managed metadata (SharePoint Server 2010) http://technet.microsoft.com/en-us/library/ee530389.aspx

• Word Viewing Service Application
• Excel Calculation Service
• PowerPoint Service Application

Today I will be extending my step by step SharePoint 2010 configuration articles and by the end of this post you will be able to open and edit Office documents from within your web browser without the requirement of having Microsoft Office installed locally.  This is a huge productivity gain for those that might be accessing their SharePoint sites from an Airport Kiosk where Office is usually not available.

Installation

You will need to download Office Web Apps from the Microsoft Download Site.  This download is available to Volume licensing customers or those with TechNet and MSDN subscriptions.  Let’s begin by launching the setup.exe and entering our product key;

Accept the licensing terms.

Click Continue

Choose a file location for installation.  Ensure you select a drive with adequate free space for your Data partition which stores the Office Web Apps search index files.

Click Install Now

Upon successful installation, you will be greeted with the “Run Configuration Wizard” window.  We will immediately run the configuration wizard by leaving the checkbox ticked and clicking close.  You can also achieve the same by running PSConfig.  Both methods will register the Office Web Apps services.

Click Close to Run the SharePoint Configuration Wizard.

Click Next and click Yes to acknowledging the restart of the IIS, SharePoint Administration and Timer Services.

Click Next

Click Finish to acknowledge the successful configuration.

You will then receive the below Central Administration screen regarding configuring your SharePoint farm.  Because we have been configuring each service application one by one as needed (best practice) we will click cancel and proceed to activate the Office Web Apps services individually.

Provisioning the Office Web Apps Service Applications

Let’s begin by starting the relevant Office Web Apps services located under Central Administration / System Settings / Manage services on server.

Scroll down until you locate all of the Office Web Apps specific services, namely Excel Calculation Services, PowerPoint Service and Word Viewing Service.  Click Start for each respective service.

Let’s now navigate to Central Administration / Application Management / Manage service applications.

Click on New / Word View Service

Enter the following details to complete the creation of the Word Viewing Service Application.  Ensure that you select “SharePoint Web Services System” from the Use existing application pool option.

Click OK

Your service application will then proceed with the creation process and will be listed with our previously provisioned service applications.

You can now further provision the “Excel Services Application” and “PowerPoint Service Application” in the same manner following the above steps.  Please note that there isn’t a separate service application for OneNote.

Activating Office Web Apps

Depending on where you want the feature activated, you will venture to your Site Collection(s) and activate each one individually or you can utilise PowerShell to activate multiple site collections at once within a single script.

From within your SharePoint Site, click on Site Actions / Site Settings.

Under Site Collection Administration, click on Site Collection Features.

Navigate down the page until you find Office Web Apps and click on Activate.

You should now be able to open a Microsoft Word document from a document library on your SharePoint site and it should launch within the browser by default.

To ensure the best experience possible for your end users, you should install Silverlight.  The below warning will be will be displayed if Silverlight is not detected.

By default, your browser will open the document in view mode and it’s only until you click on Edit in Browser that you will receive the Office Web Apps editing toolbar.

Things to note

• Silverlight installed on client computers will enhance the end user experience for Word and PowerPoint Web App and improve speed with regards to page loading.  There’s no benefits for Excel or OneNote Web App.
• Installing Office Web Apps will change the default behaviour when opening documents from open in client application to open in browser.
• There is no service application for OneNote.
• Service Application Proxies are utilised to provide location information of a service instance within a farm.
• You can load balance and install Office Web Apps on multiple servers to optimise performance.
• When installing on a SharePoint farm (i.e not a standalone installation), you will need to install Office Web Apps on every server.
• Current list of supported browsers include Internet Explorer 7 and 8, Firefox 3.X, Google Chrome and Safari 4.X.

Resources

Office Web Apps (Installed on SharePoint 2010 Products) – TechNet http://technet.microsoft.com/en-us/library/ee855124.aspx

Today we will introduce SharePoint Server 2010 Search and eventually work our way up to Microsoft’s latest and greatest FAST Search Server in a near future article.  Before we deep dive into the step by step guide I will begin by listing some of the new features that you will come to expect from SharePoint Server 2010 Search.   These are as follows;

• Boolean query syntax has finally been introduced.  These include AND, OR and NOT operators in your search queries.
• Suggestions whilst typing and after running search queries, a feature that we have come to love with major search engines such as Google and Bing.
• Integrating SharePoint enterprise search with Windows 7, allowing end users to utilise the Windows 7 search box to locate SharePoint 2010 content.
• Results display has been refined to provide filters for search results such as document type, categories and managed properties.
• View in Browser capabilities, allows end users to view documents within their own browser utilising Office Web Apps and not having to rely on launching the necessary Microsoft Office Application, or even the need of having it installed on their local machine.  This is handy when browsing your SharePoint site via Kiosks and Internet Cafes that may not be running the Microsoft Office Suite.
• Last but not least, there have been a number of improvements to People Search, including phonetic name and nickname matching, and improved relevance and self search.

Now that we have a taste for what’s to come, let’s begin our configuration.

SharePoint Server Search is a service application which we have come to learn about over the past few articles that it is independent of other services and is no longer tied to the Shared Services Provider (SSP) that was introduced in SharePoint 2007.

SharePoint 2010 search architecture is made up of the Crawler, Indexing Engine, Query Engine and the User Interface and Query Object Model.  We now have greater flexibility and expandability with our search design in 2010 and can setup not only multiple Query Servers but can now scale out our Index server and add multiple instances.

Below is a logical overview of the components that will make up our SharePoint 2010 search configuration.

Configuring the Service Application

As always we begin our journey in Central Administration / Application Management / Manage Service Applications.

Click New / Search Service Application.

Name: Enter a name for your Service Application.

FAST Service Application: Select “None” (we will leave the configuration of FAST for a future article)

Search Service Account: Click on Register new managed account and ensure your domain account has already been provisioned in Active Directory.  I have created a separate search account; e.g. DOMAIN\sp_search

Application Pool for Search Admin Web Service: Create a new application pool for your search admin web service application.

Application Pool for Search Query and Site Settings Web Service: Create a new application pool for your search query web service application.

Click Create

The search service application will begin its configuration process.

You will eventually be presented with confirmation that the search service application was created successfully.

If we now navigate back to Application Management / Manage Service Applications, you will notice that 2 additional services have been added to our list.  These are;

1. Search Service Application (Typical Search Administration page which is similar to that in SharePoint 2007. From here we can create content crawl rules, reset indexes, setup content sources etc).
2. WSS_UsageApplication (This is a new service in SharePoint 2010 that specifically handles our Usage and Health Data Collection Service Application.  This service application handles web analytics such as usage, search query usage, rating usage etc  More on this in a future article).

Let’s now launch the Search Administration page by clicking on our Search Service Application.

Our Default content access account should be set to the account that we had specified at the time of provisioning the Search Service Application; i.e. DOMAIN\sp_search

Confirming Permissions

There are a couple of areas to note that we should check to ensure that our Default content access acount (sp_search) has been provided with the appropriate access permissions.  Let’s first begin by checking our User Profile Service Application by Navigating to Service Applications / User Profiles.  Just highlight the User Profiles and select Administrators from the ribbon.

Our newly provisioned sp_search account should have “Retrieve People Data for Search Crawlers” selected as a permission.

We will also confirm that our sp_search account has the necessary “Read” permissions against the Web Applications being crawled.

Navigate to Central Administration / Application Management / Manage Web Applications.  Again, highlight the Web Application in question and from the ribbon select User Policy.

Ensure that the Search Crawling Account is set to the sp_search domain account.

Content Sources

Let’s venture into our content sources listed in the Quick Launch navigation bar under Crawling.

As was the case with SharePoint 2007, our Local SharePoint sites will be detected by default, albeit without a crawl schedule.

Check to see that your Start Addresses are located within your content source via editing the content source from the drop down menu.  These includes all SharePoint Web Applications and the sps3 “User Profiles” address.

You can easily create your crawl schedule by clicking on Local SharePoint sites and scrolling down to Crawl Schedules.

Let’s initiate a Full Crawl by clicking on Start all Crawls from the Manage Content Sources page.

Once your crawl has completed, you should confirm that there were no errors encountered during the initial crawl.  Usually any errors noted are most likely due to incorrect permission assignments.

Creating a “Basic Search Center” Site

If you haven’t done so already, from your top level site, click on Site Actions / New Site.

Select “Basic Search Center”

Enter a Name and URL and click on Create.

This will provision the Search Center similar to the below.

Creating an “Enterprise Search Center” Site

Let’s also create an Enterprise Search Center for comparison.  The key difference here is that we are provided with two tabs for searching, one for Sites and the other for People.  The “Enterprise Search Center” will be the search site of choice for most organizations running SharePoint Server.

From Central Administration / Application Management / Site Collections, click on Create site collections.   Ensure you are creating the Site Collection below the relevant Web Application.

Enter your Title, Description etc and select the Enterprise Tab under Template selection.  Select the Enterprise Search Center, specify your site collection administrators and click OK.

This will provision the Enterprise Search Center similar to the below.

As we have already completed an initial Full crawl earlier, I can now test my new search centers by performing a couple of searches.

Searching Content

Searching People

Now I ran into an issue when trying to search for content located in My Sites.  The crawl log displayed the following warning;

“This item and all items under it will not be crawled because the owner has set the NoCrawl flag to prevent it from being searchable”

In order to fix this issue (and this is true for any Site Collection), is to navigate to your My Site host and click on Site Actions / Site Settings.

Click on “Search and offline availability” under Site Administration, and ensure that you have Indexing Site Content, Allow this site to appear in search results? set to “Yes”.

After enabling the indexing of My Sites, I was able to successfully perform My Site Content searches and the warning disappeared from the Crawl Log.

That’s all that is to it in setting up a search center in its most basic form.  From here you can expand your service applications over multiple servers providing you with redundancy, scalability and increased performance .  Until next time, happy searching

References:

TechNet :: Getting Started with Enterprise Search in SharePoint 2010 Products

Appendix

SharePoint Versions Search Comparison

In my last article I introduced and configured our first service application for our SharePoint 2010 deployment, User Profiles, which provided us with a central location for storing user details that will later be imported from a content source such as Active Directory.  Today we will continue our journey to plan and configure User’s My Sites in SharePoint 2010.

Prerequisites

This article is the 5th in my series on deploying SharePoint 2010 for the enterprise, so if you have missed the first 4, you can easily catch-up via the links below;

1. Installing SharePoint 2010 using Least Privilege Service Accounts
2. Configuring incoming email in SharePoint 2010 with Exchange 2010
3. Configuring outgoing email in SharePoint 2010 with Exchange 2010
4. Configuring the User Profile Service in SharePoint 2010

Create the My Site Web Application

We begin by first creating a Web Application that will eventually house our My Site Host and subsequent site collections.

Navigate to Central Administration / Application Management / Web Applications

Click New

Authentication: Select either Claims or Classic depending on your requirements.  I will select “Classic”

IIS Web Site: Create a new IIS web site (enter your details as per your requirements)

Authentication Provider: Select your preferred provider based on your requirements.

Public URL: Specify the URL that users will type to access their My Sites.

Application Pool: Create a new application pool and give it a descriptive name

As we have been utilizing the least privilege model whilst configuring our SharePoint farm in this series, we will click on Register a new managed account and enter the details for our My Site Application Pool Identity.  Note: This account will be required to be provisioned in Active Directory before you can proceed. e.g. In my example I have created an account called DOMAIN\sp_mysite.

Click OK

Database Name and Authentication: Specify your Database server and Database name.

Failover Server: Specify your failover server if you are utilising SQL Server database mirroring.

Click OK

You should receive the below confirmation that the Web Application has been successfully created.

Click on our newly created “SharePoint – My Site” Web Application and click on General Settings.  Proceed to fill out your Web Application specific settings such as the Default Time Zone etc.

Create the My Site Host Site Collection

Now that we have successfully created our My Site Web Application, we can now proceed to create our My Site Host Site Collection.  This will be the top level site that will house our individual user’s site collections.

Navigate to Central Administration / Application Management / Create site collections.

Ensure that the recently created My Site Web Application is selected, enter in a Title and click select the My Site Host Template located under the Enterprise Tab.  Lastly, specify your site collection administrators and click OK.

You should then receive confirmation that the top level My Site Host has been successfully created.

Setup My Sites

Now that we have successfully provisioned our My Site Web Application and Top Level Site Collection that will host our My Sites, we can continue to configure our My Site Settings.

Navigate to Central Administration / Application Management / Manage service applications.

Click on User Profiles.

Click on Setup My Sites located under My Site Settings.

Enter the details of your Preferred Search Center if you have one setup already.

Enter the URL of your My Site Host that we have just created in the previous step and the personal site location.

Finally, select your Site Naming format, configure your Language Options, Permissions and My Site Email Notifications.

Click OK.

Add our Managed Path

Because we have specified “personal” as our Personal Site Location, we will need to define our managed path against our My Site Web Application.

Navigate to Central Administration / Application Management / Manage Web Applications.

Click on your My Site Web Application and click on Managed Paths from the Ribbon.

Add “personal” as a Wildcard inclusion, click Add Path and click OK

Enable Self-Service Creation

Our last configuration step provides our users with the privilege to provision their own My Site’s by enabling the Self-Service Creation.

Navigate back to Central Administration / Application Management / Manage Web Applications.

Click on your My Site Web Application and click on Self-Service Site Creation.

Select On and click OK.

If I now browse to my My Site URL I will be presented with the following “What’s New” Page.

It is only until I click on “My Content”, that SharePoint will proceed to create my personal site as per SharePoint 2007.

My Content

As you can see, we have now successfully completed our setup of a My Site Host which will house our user’s My Sites.

There is a whole bunch of new exciting features within SharePoint 2010 and its latest iteration of My Site in which I will deep dive in future articles.

SharePoint 2010 introduces the notion of “Service Applications” which build’s upon the “Shared Services Provider (SSP)” which was introduced in SharePoint 2007.  Service Applications are individual services that can be configured independently and can be shared across other sites within your farm with some service applications that can also be configured across farms.

The individual service applications provided with SharePoint 2010 are listed as follows;

• Access Services
• Business Data Connectivity
• Document Conversion
• Excel Services
• Managed Metadata Service
• PerformancePoint
• Search Service
• Secure Store
• State Service
• Visio Graphics Service
• User Profile Service

This article will build upon our initial SharePoint 2010 install utilizing the least privilege model which I have documented here, so check it out if you haven’t already done so.

Managed Metadata Service

The User Profile service requires that the Managed Metadata Service is setup and configured first before attempting setting up our first User Profile Service.  The Managed Metadata service allows you to utilize managed metadata and provides you with the ability to share content types across sites.  You can read more about Managed Metadata here.

To setup our Managed Metadata Service, navigate to Central Administration / Application Management / Manage Service Applications.

Click New and select “Managed Metadata Service”

Enter the follow details;

Name: Managed Metadata Service

Database Server: <server_name>

Database Name: Managed Metadata DB

I will utilize the sp_farm account for the Application Pool Identity.

Click Create.

Lastly, navigate to Central Administration / System Settings / Manage services on server and start the Managed Metadata Web Service.

User Profile Service

Now that we have successfully configured our Managed Metadata service we can now focus our attention on the User Profile Service.  The User Profile Service provides our SharePoint farm with all the social networking features that we have come to love in SharePoint 2007, plus more.  It forms the basis of My Site support, User profile pages, Audiences and some of the newer features in SharePoint 2010 social computing such as social tagging.

Before we begin, we need to ensure that our Farm account (DOMAIN\sp_farm) is listed as a member of the Local Administrator’s group where the User Profile Synchronization service will be deployed.

Let’s now navigate to Central Administration / Application Management / Manage Service Applications.

Click New and select “User Profile Service Application”

The “Create New User Profile Service Application” window pops up in which you will enter the following details; (you will obviously enter in the details based on your environment setup)

Name: User Profiles

Create new application pool: SharePoint – User Profiles

Register a new managed account: e.g. DOMAIN\sp_userprofiles (nb: this account will need to be provisioned in Active Directory first)

Enter your Profile Database server details and database authentication.  You will notice that SharePoint 2010 introduces the ability to configure Failover Server which allows you to associate your SharePoint databases with another SQL server for failover purposes utilising SQL Server database mirroring.   We will not specify a Failover Database server for any of our databases at this present time.

Specify your Synchronization Database which is used to store configuration and staging data for synchronization of profile data such as that from Active Directory.

Next, specify your Social Tagging Database which is used to store tags and notes that are created by users.  Social Tagging is a new feature in SharePoint 2010 which is not only displayed against the items that user’s are tagging, but are also displayed in the user’s activity feed.

Next, select your Profile Synchronization Instance Server.

In the proceeding section, we will not create a My Site Host URL and will leave this for part two of this series.

Click Create.

You should now have the User Profiles service application listed and  started.

We will now venture back into Central Administration / System Settings / Manage services on server.

Scroll down to the User Profile Service and User Profile Synchronisation Service and start both.  The User Profile Service should start without any further user interaction, however the User Profile Synchronization Service will ask for your SharePoint Farm credentials.

Click Ok.

Both services should now be listed as started.

This in turn, will correctly configure and start our ForeFront Identity Manager Windows Services (FIM).

We will now configure our User Profile Connection to our Active Directory Domain.

Navigate to Central Administration / Application Management / Manage Service Applications.

Click on User Profiles / Manage.

Click on Configure Synchronizations connections / Create New Connection.

Enter the follow details;

Connection Name:

Type: Active Directory

Auto discover domain controller or specify a domain controller

Authentication Provider Type: Windows Authentication

Account Name / Password:

Port: 389

Click on Populate Containers

Click OK.

Your connection should now be listed as follows upon successful creation.

We can now easily setup connection filters against our Active Directory User Profile connection by clicking on the connection that was just created and selecting “Edit Connection Filters”.

Specify and Add any User or Group exclusions and then click OK.

Next we will Configure a Synchronization Timer Job via Central Administration / Application Management / Manage Service Applications / User Profiles.

Click Enable

We will finish off by initiating a full synchronization via Central Administration / Application Management / Manage Service Applications / User Profiles / Start Profile Synchronization.

In order to confirm that the import was a success, the Number of User Profiles should now be set to the number of users in your organization, in my case I have 269 dummy users in my Active Directory domain.  Word of note; this will take some time and is considerably slower than an Active Directory User Profile import in SharePoint 2007.

You can also venture into Manage User Profiles and search for users (please take note that SharePoint 2010 does not display any users by default and that you will have to search for them).

Edit a User Profile to ensure that all the necessary Active Directory attributes were successfully imported.

We have now successfully completed a User Profile Synchronization which will form as a basis for User’s My Sites in my next article.  Until then, happy SharePointing!!

References

User Profile Service administration (SharePoint Server 2010) http://technet.microsoft.com/en-us/library/ee721050.aspx

Configure profile synchronization (SharePoint Server 2010) http://technet.microsoft.com/en-us/library/ee721049.aspx

The environment

This article builds on the SharePoint Farm setup that I have documented here. It consists of the following servers which would form a common basis in most large organizations.

• Windows 2008 R2 server running Active Directory Domain Services
• Windows 2008 R2 server running SQL 2008 R2
• Windows 2008 R2 server running SharePoint 2010 RTM
• Windows 2008 R2 server running Exchange 2010 RTM
• Windows 7 client running Office 2010 RTM

SharePoint 2010 allows you to configure any SMTP service including the one which I had setup in my previous article to send outgoing email, however we will utilise Exchange 2010 (same instructions apply for Exchange 2007) to provide email delivery to our end users.  Instructions on configuring the SMTP service (i.e. you are not using Microsoft Exchange in your environment) can be found on TechNet.

Creating a Receive Connector in Exchange 2010

If you recall from my previous article when we were configuring incoming email, we created a “Send Connector” in Exchange to forward the messages to the SMTP service that we had configured and installed.  This time round we will create a “Receive Connector” in Exchange 2010.

Launch the Exchange Management Console and navigate to Server Configuration / Hub Transport / New Receive Connector.  The New Receive Connector wizard is invoked.

Enter a descriptive name and ensure “Custom” is selected as the intended use.

Click Next

Leave “All Available IPv4” in your Local Network settings unless you have specific Exchange IP requirements.

Click Next

Edit the IP address of your SharePoint 2010 server.

Click Next

Click New

You will now notice that our SharePoint 2010 Outgoing mail connector is listed with our default Exchange 2010 Receive Connectors.. 

We will now venture into its properties and make a minor permission change.  Click on the “Permission Groups” tab and select Anonymous users.

Click Apply.

Configuring outgoing email in SharePoint 2010 Central Administration

Launch Central Administration and navigate to System Settings / E-Mail and Test Messages / Configure outgoing e-mail settings.

Enter your Outbound SMTP server, i.e. your Exchange server where we created our receive connector and specify a From and Reply-to address.

Click OK

Testing our configuration

Lets navigate to our SharePoint 2010 web application and create an Alert .  In my example I will create an immediate alert for Announcements.

Navigate to your Announcement List and click on List Tools/List and then click on “Alert Me” located in the ribbon interface.

Select “Set alert on this list” and select your Alert options.  Ensure that you have “send notifications immediately” selected for testing purposes.

Click OK

You should receive your notification email that you have successfully subscribed soon after creating your alert.

I will now create a Test Announcement to ensure that the actual alert is delivered.

Alas! 5 minutes later (based on the immediate timer job definition schedule) we have received our email alert confirming that our SharePoint configuration with Exchange was successful.

Did you know that you can also configure outgoing email for a specific Web application?  You might want to do this if you have multiple SharePoint Web Applications hosting specific site collections and would want a different From and or Reply Address setup.

Even though we are now going to configure outgoing email for a specific Web application, you are still required to setup the default farm outgoing email settings as per the above.

Configuring outgoing email for a specific Web application in SharePoint 2010 Central Administration

Launch Central Administration / Application Management / Manage Web Applications.

Select one of your Web Applications and then select “General Settings” from the Ribbon.

Select “Outgoing E-Mail” from the drop down.

It will pick up your default farm settings that we entered in earlier in which you can now change the From and Reply-to address to something more specific for the selected Web application.

Click OK

We are done!  I hope you have found this step by step guide in configuring outgoing email in SharePoint 2010 with Exchange useful, and stay tuned as we continue our journey in configuring our SharePoint 2010 Farm.

Articles in this series

Installing SharePoint 2010 using Least Privilege Service Accounts – Step by Step Guide

Configuring incoming email in SharePoint 2010 with Exchange – Step by Step Guide

Configuring outgoing email in SharePoint 2010 with Exchange – Step by Step Guide

In today’s post, I will provide you with a comprehensive step by step guide in configuring your SharePoint 2010 server in conjunction with Exchange 2010, to provide successful delivery of incoming email directly to your SharePoint Web Applications.

The environment

This article builds on the SharePoint Farm setup that I have documented here. It consists of the following servers which would form a common basis in most large organizations.

• Windows 2008 R2 server running Active Directory Domain Services
• Windows 2008 R2 server running SQL 2008 R2
• Windows 2008 R2 server running SharePoint 2010 RTM
• Windows 2008 R2 server running Exchange 2010 RTM
• Windows 7 client running Office 2010 RTM

The SMTP service

SharePoint 2010 is reliant on the SMTP service which is a Windows 2008 feature and we must install this on our SharePoint 2010 front-end web server.

Navigate to your Start Menu / Administrative Tools / Server Manager.  Click on the Features node and select Add Feature.  Scroll down and select SMTP Server and click on Add Required Role Services.

Click Next, Next and Install.

Click Close

We now need to install the II 6.0 Management Tools on our Windows 2008 R2 server in order to configure our SMTP service.  If IIS 6.0 Manager is not already installed you must do so via, Start / Administrative Tools / Server Manager.  Click on the Roles node and select Role / Add Role Services.  Then select Management Tools and IIS 6 Management compatibility.  Click Install.

We can now launch the IIS 6 Manager via Start / Administrative Tools.

Right click on SMTP Virtual Server #1 and select properties.

Under the General tab, I have enabled logging and encourage doing so at the start in the event we need to do some troubleshooting.  You can turn logging off after successful testing.

Click on the next tab, “Access”.

Click on “Authentication” and ensure that Anonymous access is selected.

Next, click on “Connection” and ensure “All except the list below” is selected.

Finally, click on “Relay”, and ensure that “Only the list below” is selected and that “Allow all computers which successfully authenticate to relay, regardless of the list above” is also checked.

Now click on the Messages Tab and make any necessary adjustments that you see fit, such as potentially increasing the message size to allow for the delivery of larger emails with attachments into your SharePoint Libraries and Lists.

Next click on the Delivery Tab in which I normally leave all the defaults in place.

We can skip the LDAP routing tab as there are no settings required to be configured in this area.

Lastly, the Security tab should list the default permissions as per the below.  No changes are necessary in this area.

We next journey into the “Domains” are within IIS 6 Manager and a domain name should be listed, which by default is the fully qualified domain name of the machine.

Right click on the Domain Name and select properties and take note of the Drop directory.

Finally, we now just need to confirm that our SMTP service is set to start automatically in the event the server is restarted.  I can tell you now that the service is by default set to Manual.

Venture into Start / Administrative Tools / Services.

Scroll down your list of services and ensure that the Simple Mail Transfer Protocol (SMTP) is set to Start-up type, Automatic.

We have now completed the configuration of our SMTP service on our SharePoint Server.

Exchange 2007/2010 Connectors

Part two of the implementation of configuring incoming email in SharePoint is to configure our connectors in Microsoft Exchange.  Now even though this is not a requirement, most organisations running SharePoint 2010 or 2007 will also be running a recent version of Microsoft Exchange, hopefully either 2007 or 2010.  Exchange 2010 or 2007 will provide you with that extra layer of protection ensuring that all the necessary message hygiene has been performed via its inbuilt Anti Spam Agents on the Edge or Hub Transport Server in conjunction with some form of email antivirus such as Microsoft’s Forefront for Exchange, before the message is delivered to the SharePoint 2010 List or Library.

My instructions and screen captures below are from an Exchange 2010 server which are pretty much identical and applicable to Exchange 2007.

Let’s begin by launching the Exchange Management Console / Organization Configuration / Hub Transport.

Click on Send Connectors / Actions / New Send Connector.

Type in a descriptive name for your Send Connector and then select Internal as the type.

Click Add and enter the Address space as the fully qualified domain name of the server where the SMTP service is installed (i.e. your SharePoint Server)

Click Next

Enter the IP address of the server which also hosts the SMTP service.

Click Next

Select “None” as your smart host authentication settings

Click Next

Ensure your Hub Transport Server has been added.

Click Next

Click New and then click Finish

The end result will be that the Send connector will route email to the SMTP service sitting on our SharePoint Server.

The Directory Management Service

SharePoint 2010 allows you to leverage Active Directory Domain Services (AD DS) so that contacts that are created when you email enable document libraries or lists are stored in a designated Organizational Unit within your AD DS infrastructure.  So why would you want to enable Directory Management Service?  Purely for the fact that by storing these contacts in AD, you are allowing your users to locate email enabled libraries and lists easily from within their Outlook Address book.

Let’s begin by creating an Organizational Unit in Active Directory.

From your Active Directory server, click Start / Administrative Tools / Active Directory Users and Computers.

Right click on your domain object and select New / Organizational Unit

Type in a descriptive name

Click Ok.

The next step is imperative and very important that we get this right.  I have seen on many occasions where incorrect permissions were applied and all sorts of problems were encountered when libraries or list were email enabled.

In summary, we need to provide our Central Administration Application pool identity account specific permissions to our recently created Organizational Unit to be used for creating and deleting contacts for our SharePoint 2010 libraries and lists when they are either email enabled or email disabled.

Right click on the recently created Organizational Unit and click on Delegate Control.  This will invoke the Delegation of Control Wizard.

Click Next.

We will now add the Central Administration application pool account which you can confirm from IIS Manager as per the below screen capture.

Add the necessary Account.

Click Next.

Click Create a custom task to delegate.

Click Next

Click “This folder, existing objects in this folder, and creation of new objects in this folder’.

Click Next

Click on Create All Child Objects and Delete All Child Objects.

Click Finish.

Before we finish off our configuration of AD DS and the Directory Management Service we need to provide our Central Administration application pool account with Delete Subtree permissions.

We need to ensure that “Advanced Features” from within Active Directory Users and Computers (ADUC) is active before we venture into the security tab of our SharePoint organizational unit.  If you do not enable Advanced Features, the security tab will not be visible.

From within ADUC, click on View and select Advanced Features.

Right click on our SharePoint 2010 Organizational Unit and select Properties.

Click on the Security Tab / Advanced /and Edit the CA Application Pool Identity Account.

Select Allow for “Delete Subtree”

Click on OK and Apply.

After assigning these permissions, you must run IISRESET on your SharePoint server.

Configuring Incoming e-mail settings in Central Administration

Navigate to Central Administration / System Settings / Configure incoming e-mail settings.

Select Yes to “Enable site on this server to receive e-mail”

Select “Automatic” for Setting mode.

Select “Yes” to use the SharePoint Directory Management Service to create distributions groups and contacts.

Enter your Active Directory container details, i.e. the Organizational Unit container that we created specifically for our SharePoint 2010 contacts.

Ensure that your SMTP server details are correct, this should be the fully qualified domain name of your SMTP service that was installed on your SharePoint Server.

Finally, ensure “Accept mail from all e-mail servers” is selected.

Click OK.

Please note that this process will configure the necessary permissions on the email drop folder listed in IIS 6 Manager.  In summary, the following permissions are added;

WSS_Admin_WPG – Full Control and

WSS_WPG – Read & Execute / List folder Contents / Read

Ensure that these accounts are added successfully and on the rare occasion in which it isn’t, you will need to add them manually.

Testing the configuration

From within any document library or list, click on Library / Library Settings.

Click on Incoming e-mail settings.

Select “Yes” to allow this document library to receive e-mail.

Select your email attachment options and ensure that Save original e-mail is set to Yes.

Lastly, ensure that you Accept e-mail messages from any sender is selected.

Click OK.

This is your first step to ensure that all of the above configuration is in place.  If you do receive an error, it’s most likely going to be permissions related against your Organizational Unit, i.e. SharePoint may not have the privilege to add the contact in Active Directory.

Let’s navigate back to ADUC and confirm that our “testing” contact is created under the SharePoint 2010 Contacts Organizational Unit.

Let’s next navigate to our Exchange 2010 server and ensure it is also listed there with an SMTP address against it.

Launch your Microsoft Exchange Management console and navigate to Recipient Configuration / Mail contact.

Right click on the Contact and select Properties / E-Mail Addresses.

Ensure that both an internal and external routable email address is listed.

From your favorite email client, send a test email to the document libraries’ external SMTP address.

Navigate to your recently email enabled document library and hopefully after a couple of minutes (SharePoint Job timer service delay) you should have received your test email.

Well! That’s all that is to it, from start to finish.  Apart from sending a test email, there are a couple of other scenarios that you should test to ensure complete seamless integration with the SharePoint 2010 Directory Management Service.  Within the same document library, modify the email address to something different and ensure that this change also flows through to Active Directory. You should also try disabling incoming email from that same library and ensure that the contact is completely removed from Active Directory.  If you pass all of these tests scenarios, then we are comfortable in knowing that the correct delegation was provided to our Central Administration Pool Account against our SharePoint Contacts Organizational Unit.

I hope you have found this step by step guide in configuring incoming email in SharePoint 2010 with Exchange useful, so stay tuned as we continue our journey in configuring our SharePoint 2010 Farm.

The below setup will be based on SharePoint 2007 best practices and SharePoint 2010 TechNet documentation on “proposed” best practices with this setup utilising the least privilege model for our SharePoint service accounts.  Before delving into the setup which will form the basis of all future blog posts on SharePoint 2010, I have provided the below summary of the environment that I will be working with.

Environment

• Windows 2008 R2 server running Active Directory Domain Services
• Windows 2008 R2 server running SQL 2008 R2
• Windows 2008 R2 server running SharePoint 2010 RTM
• Windows 2008 R2 server running Exchange 2010 RTM
• Windows 7 client running Office 2010 RTM

The Preparation

Before we delve into the actual installation, let’s begin to talk about what service accounts are required for the new SharePoint Farm setup. TechNet has a great article on the service accounts required and their respective privileges which you can read in some detail here.  In summary, these are not much different to the SharePoint 2007 best practices for utilising the Least Privilege model for service accounts and goes as follows;

1. SQL Server Service Account
   This should be a standard domain user account which will be used to run the MSSQLSERVER and SQLSERVERAGENT services on your SQL server.
   e.g. DOMAIN\sp_sql
2. SharePoint Setup User Account
   This should be a standard domain user account that will be used as the logged in user when installing SharePoint and for when running the SharePoint Products Configuration Wizard.  This account must be a member of the Local Administrators group for each server where SharePoint 2010 will be installed.  You will also need to create a SQL server login with the following SQL server security roles; “securityadmin” and “dbcreator”.  Instructions below.
   e.g. DOMAIN\sp_admin
3. Server Farm/Database Access Account
   You guessed it, this should also be a standard domain user account, however we do not need to grant any necessary permissions to this account as this is handled by the SharePoint Setup User Account during the SharePoint Products Configuration Wizard.  This is the account that we nominate as the “Database Access” account during the SharePoint Configuration Wizard.  This account will be applied against the SharePoint Foundation Workflow Timer Service and the SharePoint Central Administration Web Site Application Pool.
   e.g. DOMAIN\sp_farm

It’s imperative that these accounts are created and provisioned before attempting any installation of the SharePoint 2010 bits.  This article is assuming that SQL 2008 R2 has already been installed in your environment using the SQL server service account.

Firstly, have your Active Directory Administrator create the above accounts in Active Directory as standard domain users.   Then navigate to each server in which you will install SharePoint 2010 and add the DOMAIN\sp_admin account (SharePoint Setup User Account) to the Local Administrator’s group of that respective server.

Navigate to Start / Administrative Tools / Server Manager / Local Users and Groups and then click on the Groups folder.

Add the DOMAIN\sp_admin user to the Administrator’s group.

We next venture to our SQL 2008 R2 server to configure our sp_admin account as a SQL server login.

Launch the SQL 2008 R2 Management Console and navigate to Security / Logins.

Right click on Logins and select New Login;

Search for the newly created sp_admin domain account

Click on Server Roles and select dbcreator and securityadmin as your server roles.  Public will be selected by default.

Now that our environment is prepped up with your service accounts, we can now proceed with the installation, so let the *games* begin!!

The Install

Launch the SharePoint 2010 splash installation screen and ensure you have met the necessary hardware and software requirements.  You can find more details in the following TechNet article. It’s important that you download and install the WCF hotfix listed in the above TechNet article.   This hotfix is specific to the OS version that you are installing SharePoint 2010 on.

Run the Install software prerequisites first! This preparation tool will actually install the majority of the prerequisites listed in the TechNet article.

Click Next

Accept the terms of the License Agreement

The preparation tool begins installing the pre-requisites. It’s imperative that your SharePoint server has an internet connection as it will connect to the internet during the preparation and download the necessary software listed above.

After the installation of the prerequisites is complete, you will be asked to re-start your computer.

After your server has restarted, the preparation tool should pick up from where it last left and finalise any further configuration that is required. You should then receive a successful completed installation dialog window as per the below.

Click Finish.

You will then be required to re-launch the install splash screen and this time round click on Install SharePoint Server.

Enter your product key

Accept the Microsoft Software License Terms.

Select Server Farm (we all know not to select Standalone right?! Big no no in production)

Again, don’t be fooled into selecting the Stand-alone option which is identical to the Stand-alone option in the previous screen.  Be sure to select Complete and click Next to proceed with the installation.

Once SharePoint has copied it’s files, the Run Configuration Wizard window will appear.

Click Close

The SharePoint Products Configuration Wizard will then launch

Click Next

Click Yes on the following warning.

Select “Create a new server farm”

Click Next

Enter the name of your SQL 208 R2 server and keep the default database name for SharePoint 2010 Configuration database.  Then enter the SharePoint Farm account as the Database Access Account.  i.e. DOMAIN\sp_farm.

Click Next

Enter a Passphrase. As mentioned below, this designated passphrase is configured to ensure that no other SharePoint servers can join this farm unless the passphrase is provided.  The passphrase must meet the following requirements;

• Contains at least eight characters
• Contains at least three of the following four character groups:
• English uppercase characters (from A through Z)
• English lowercase characters (from a through z)
• Numerals (from 0 through 9)
• Nonalphabetic characters (such as !, $, #, %)

Configure your SharePoint Central Administration Web Application settings. I always like to change the default port number to something that is easier to remember.

You are also presented with the authentication provider options for your CA Web Application in which it is usually best practice to utilise Kerberos for your SharePoint Web Sites, however NTLM will suffice for your SharePoint CA Web Application.

Click Next

Click Next.

The infamous performing configuration task screen is displayed.  All we can do now is cross our fingers and wait…

Upon completion you should receive the following confirmation that the configuration was a success.

Click Finish

The SharePoint 2010 Central Administration website that was just created should launch.

The Customer Experience Improvement Program which is available with most Microsoft products will pop up in a separate Window.

After answering Yes or No the Customer Experience Improvement Program the Configure your SharePoint farm wizard option will appear.  We will click Cancel and go through the configuration of our service applications in subsequent future articles.

That’s all that is to it.  Before signing out, let’s venture into a couple of key areas to confirm the details of our farm configuration and then venture across to our SQL server and launch SQL Management Studio to determine what databases are created by default.

Let’s begin by navigating to Central Administration / System Settings / Manage servers in this farm.  After confirming the server listing as per our installation, navigate to your SQL 2008 R2 server and launch SQL Management studio. Browse to databases to see our SharePoint 2010 Databases listed, namely the SharePoint config database and the SharePoint Central Administration Database.

I hope this article has some shed some light with your SharePoint 2010 deployment and we will continue our focus in near future articles in configuring our SharePoint farm and focusing on the service applications that are on offer.

Resources

Administrative and service accounts required for initial deployment (SharePoint Server 2010) http://technet.microsoft.com/en-us/library/ee662513%28office.14%29.aspx

1. In-place upgrade
2. Database attach upgrade to a new farm
3. Hybrid approach (Read –only databases or Detach databases)

There is a wealth of information regarding these different approaches on the Microsoft TechNet site under the Upgrade and Migration Resource Center for SharePoint 2010. I will also outline other resources at the end of this article for convenience.

The upgrade model that I have chosen in this article series is the Database attach upgrade approach in which I will outline in this step by step guide.  The upgrade choice you choose is dependent on a number of factors such as how much down time can you afford and whether you are moving onto newer hardware.  All three options have their strong and weak points which is outlined in the following TechNet article; Determine Upgrade approach (SharePoint 2010)

This article is assuming that your SharePoint 2010 environment is up and running (albeit in beta form).  I have published a 3 part series in getting your SharePoint 2010 environment up and running that you can access from the following links;

1. Installing SharePoint 2010 Beta on a Windows 2008 R2 Server
2. Configuring SharePoint 2010 (Beta) Service Applications and User Profile Service Synchronization
3. Creating your first SharePoint 2010 Beta Web Application and Site Collection

When using the database attach method to upgrade your databases to SharePoint 2010, you need to be aware that none of your configuration settings in SharePoint 2007 will migrate.  You will need to ensure that you have replicated your 2007 environment in the newly created 2010 farm.  Some of the items to consider include the following;

• Outgoing email server
• Alternate Access Mappings (AAM)
• Quota templates
• Included paths
• Install any custom or 3rd party features, including web parts, solutions
• Custom site definitions
• Custom CSS

In order for you to perform a database attach upgrade into your SharePoint 2010 environment you need to ensure that you have created a new web application.  If you have not done so, you can follow my step by step guide on Creating your first SharePoint 2010 Beta Web Application and Site Collection.

Step 1 :: Restoring a copy of your SharePoint 2007 content database

Now that we have ensured that all our configuration settings are in place, and that all custom features, web parts and solutions have been re-instated, we can now proceed with our upgrade.  You will need to firstly backup and take a copy of your SharePoint 2007 content database and restore it to the newly created SharePoint 2010 farm.

I’m performing my database restore utilising SQL 2008 Management Console.  Right click on Databases and select Restore Database.

Select your source and destination as follows;

Click on Options and ensure you have selected Overwrite the existing database.

Click OK.

We should receive the following confirmation message once the database has been successfully restored.

Step 2 :: Verifying the Content Database

As you have already noticed from our first article, in particular with the introduction of the preupgrade check tool, Microsoft have done a great job in providing us with the necessary tools to ensure a successful upgrade.  The next tool that we will be using is the Test-SPContentDatabase Windows PowerShell cmdlet.  This cmdlet will test and verify that any custom components that are required for this content database has been installed and configured in the SharePoint 2010 environment.

Test-SPContentDatabase –Name <database name> -WebApplication <URL>

Test-SPContentDatabase –Name WSS_Content_Intranet -WebApplication http://intranet.georgekhalil.com

stsadm -o addcontentdb -url <URL> -databasename <database name>

If one is listed, you can remove the existing attached database by clicking on the actual database name and then clicking on the “Remove content database” check box.

You will receive the above warning which is safe to ignore.  In this instance we are not deleting the actual database but disassociating it from the selected Web Application.  This is the exact same behaviour that was available to us in SharePoint 2007.

We can now proceed and attach our restored SharePoint 2007 database via the following stsadm command line;

stsadm -o addcontentdb -url <URL> -databasename <database name>

In my instance, the command looked as follows;

stsadm -o addcontentdb -url http://intranet.georgekhalil.com -databasename WSS_Content_Intranet

You will eventually receive a message similar to the below advising that the upgrade was completed albeit with errors in my case.  You should review the upgrade log file which is quite extensive and lengthy, and sure enough the errors were all related to missing features etc which I was already aware of.

We can now verify that the upgrade was completed successfully by first navigating back to Central Administration / Application Management / Manage content databases, which now displays the upgraded database under my designated Web Application.

We can also view the upgrade status page which is located within Central Administration / Upgrade and Migration / Check upgrade status.  The page will list all previous upgrade attempts and summarise the number of errors and warnings that may have been encountered.  In my case, there were a number of features that were not installed in the new SharePoint 2010 farm that the current portal relies on.  All of the upgrade logs are located in the following location, providing you with finer detail on the errors and warnings encountered;

C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\LOGS

By default, your site will retain it’s 2007 theme which Microsoft have done on purpose and you will need to manually change this 2010 if you wish to do so.  This is referred to as the “Visual Upgrade”, providing site administrators the ability to switch to the new look and feel at their own leisure.  This is a great move by the SharePoint product team as the new interface can be quite overwhelming to begin with.  Think about the move from Office 2003-2007 with the introduction of the new ribbon interface.   There was a week or two of frustration for most users before eventually getting the hang of it and finding the new interface to be more productive.

The below screen capture is my upgraded SharePoint 2010 portal running in “SharePoint 2007 theme mode”.

To perform the Visual upgrade, navigate to Site Actions / Visual Upgrade.

Here you are provided with 3 options in which I will select “Use the new SharePoint user interface, and don’t ask me again”.  After clicking on OK, I am now presented with the same site utilising the default SharePoint 2010 theme.

We have now successfully upgraded one of our SharePoint 2010 content databases housing our main Intranet portal, albeit with some missing web parts and features.  So what’s next on the agenda?  Upgrading My Sites of course!  This will involve attaching and upgrading your Shared Service Provider (SSP) to upgrade your user profile information followed by upgrading the My Sites content database.  This process will be left for a future post.

I hope you have found this 2 part series useful and I am interested hear how many of you have attempted a SharePoint 2010 upgrade and your experiences.

Resources from TechNet

Determine Upgrade approach (SharePoint 2010)

Microsoft SharePoint 2010 Products Upgrade Approaches – Diagrams

Upgrading to SharePoint Server 2010

Preparing to upgrade to SharePoint 2010 Products

Attach databases and upgrade to SharePoint Server 2010

_______________________________________________________________

Articles in this series

1. Upgrading your Content DB to SharePoint 2010 – Part 1, The preupgradecheck
2. Upgrading your Content DB to SharePoint 2010 – Part 2, Database Attach method

1. Upgrading your Content DB to SharePoint 2010 –The preupgradecheck
2. Upgrading your Content DB to SharePoint 2010 – Using the Database Attach method

First and foremost, Microsoft have provided us with the pre-upgrade command line stsadm parameter switch in SharePoint 2007 Service Pack 2, which has been further updated with the latest October 2009 Cumulative Update (CU),. This will be our primary analysis and reporting tool providing us with invaluable information regarding your SharePoint 2007 farm and actions that may be required to be taken prior to upgrading to SharePoint 2010, so let’s begin our journey here.

Launch a Windows command prompt on your SharePoint Server and type the following stsadm command from the following directory;

%COMMONPROGRAMFILES%\Microsoft Shared\Web Server Extensions\12\bin

stsadm.exe -o preupgradecheck

STSADM -o deactivatefeature -id 758a6fdf-005a-bcaa-0ea0-1d4931979fec -url http://intranet.georgekhalil.com -force

In addition to the STSADM command line tool, there are a couple of other tools that really assisted with the process of removing rogue features where the stsadm actually failed.  The first tool which is provided by Gilham Consulting , is the WssAnalyzeFeatures tool, which will assist in listing features against their GUID similar to that of the preupgrade report.

The second tool required as part of the removal process is the WssRemoveFeatureFromSite which will remove rogue features installed in your SharePoint farm where the stsadm –o deactivate feature might fail.  Eventually you would want the output of the WssAnalyzeFeatures command to display no problems.

So after re-installing or removing any rogue features and site definitions we should be ready to proceed with our SharePoint 2010 upgrade, taking into account that there were no other problematic areas that were outlined in the preupgrade check.

There are several other tools worth mentioning that also assisted with outputting information and configuration details of my farm and assisted with the SharePoint farm cleansing process.

The SharePoint Feature Administration and Clean Up Tool which you can download from the Codeplex site,  does a great job in listing Feature Definitions across Site Collections and Sub Webs and cleanly uninstalling them.  My favourite feature in this tool is its ability to locate any faulty features and then providing you with the ability to remove them from your entire farm.

Clicking on the Find Faulty Feature in Farm should hopefully return the following “No Faulty Feature was found” message.

SharePoint Manager 2007 (note there is already a SharePoint Manager 2010 available) can also be downloaded from the CodePlex Site and is a great tool for administrators and developers in providing an understanding of any SharePoint farm topology.

My last tool of choice is from Bamboo Solutions, namely the Bamboo SharePoint Analyzer.  Similar to that of SharePoint Manager 2007, this utility also does a great job is listing everything you need to know about your SharePoint environment and your entire farm topology.  This is also available as a free download and should be installed as part of any SharePoint Farm deployment.  These tools will also greatly assist in replicating your environment for your SharePoint 2010 deployment.

Hopefully I have provided you with a comprehensive list of tools and tips to assist you in getting your Content DB’s primed for your SharePoint 2010 upgrade.  In the next part of this series I will focus on the actual upgrade itself utilising the Database attach method, so stay tuned!

References:

Upgrading to SharePoint Server 2010 – TechNet

Run the pre-upgrade checker (SharePoint Server 2010) – TechNet

5 Reasons SharePoint 2010 PreUpgradeCheck is better than Prescan – SharePoint Joel

Preparing for Upgrade to 2010 Today – Part 1 Preupgradecheck – SharePoint Joel

Planning for SharePoint 2010 – Upgrade Planning Part 4 – Using preupgradecheck – Chandima.Net