Upgrading your Content DB to SharePoint 2010 – Part 1, The preupgradecheck

I’m sure there are a lot of SharePointers out there who are excited about the 2010 release and as I have been working my way through the installation and configuration of this updated beast, I have also been providing you with posts along the way sharing my experiences.  Today isn’t any different, and in this two part series I will be providing you with a guide to upgrading your SharePoint 2007 content databases to SharePoint 2010.  There are already some great resources out there regarding upgrade options and preparation guidance including those from Microsoft on the TechNet Site and others which I will list at the end of this article. The prime focus of part 1 of this 2 part series will be to outline the many tools that are available to you at no cost, assisting and ensuring that your SharePoint  farm and SharePoint databases are up to scratch and ready for 2010.  The series will proceed as follows;

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

This will begin the pre-upgrade process checks which will display the relevant steps in your command prompt window.

When the pre-upgrade process completes, you will receive the following “Operation completed successfully” message in which it will then launch your web browser displaying the results in HTML format, titled “SharePoint Products and Technologies Pre-Upgrade Check Report”.  These results can also be located under the following location;
%COMMONPROGRAMFILES%\Microsoft Shared\Web Server Extensions\12\Logs\

What you will notice is that the report being displayed does a great job in not only notifying you of any issues regarding your SharePoint farm such as missing Site Definition Information or missing Feature Information, but it also provides you with a blueprint of your SharePoint Farm setup.  Such useful information which will be required to be taken into consideration when upgrading to SharePoint 2010 includes the following items;

• Search content sources and start addresses
• Office Server Search topology
• Servers in the current farm
• SharePoint version and list of components running in the farm
• Supported upgrade types (Inplace Upgrade and Content Database Attach)
• Site Definition and Feature Information
• Language pack information
• Alternate Access Mappings (AAM) that will need to be recreated
• Customized List views (these will not be upgraded)
• Customized field types (these will not be upgraded)
• WSS Search topology
• List of Content Databases and SQL server location

Joel Oleson does a great job in explaining these items in great detail in his blog post Preparing for Upgrade to 2010 Today – Part 1 Preupgradecheck, however I will outline some of the issues that I personally encountered with my SharePoint 2007 content database.
The majority of your issues will most likely evolve around Missing Site Definition and or missing Feature Information.  These missing items are listed at the bottom of each of these respective sections in the pre-upgrade report.  My first problem area was a missing Site Definition.

name = Unknown, language = 1033, template id = 75816, count = 5, status = Missing
Notice that the name of this feature is  “unknown”, which isn’t of much help, however this is where Google (or your preferred search engine provider) comes into play.  The key identifier is the template id which in this case is 75816, and after typing this ID number in my search criteria I was immediately presented with a number of results all pointing to the Help Desk Fab 40 template.  Aha! my eyes lit up and I recall back in the day installing some of the Fab 40 templates (I’m sure many did at the time of release).  So I downloaded the solution from the Microsoft Download Center and re-installed the template. I then re-ran the preupgrade check and whalla! my missing site definition now has a name against it with a status of “Installed”.

My next problematic area was a plethora of missing features. Now this will all depend on how much history is attached against your current SharePoint farm environment and how many 3rd party solutions and or custom development have been installed or uninstalled over time.

One thing you will learn throughout this process is that the preupgrade check utility does a great job in naming features against GUID’s when they are installed, but fails miserably in displaying names when they are missing.  Once again, Google quickly becomes a point of reference and 9 times out of 10, utilising the GUID in your search criteria will yield the results that you are after, and that is the actual name of the missing feature.   A few of mine were features from the Codeplex site so I was easily able to identify whether I needed to re-install or remove these rogue items.  In most instances, if they are missing, they are missing due to failed uninstalls, so this is where the stsadm becomes your next best friend.
Let’s take a single example where the following GUID was listed as being missing; 758a6fdf-005a-bcaa-0ea0-1d4931979fec.  You will need to run the following stsadm –o deactivatefeature command to remove the rogue entry.  More information on the this command can be located in the following TechNet article.

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

Preparing for Upgrade to SharePoint 2010 with Joel Oleson Quest Software Webcast

View more presentations from Joel Oleson.

|

Subscribe

Upgrading your Content Database to SharePoint 2010 – Database Attach method

lcome back to the second article in this series on upgrading a SharePoint 2007 content database to SharePoint 2010.  In we deep dived into the preupgrade tool that Microsoft made available with SharePoint 2007 SP2 and today we will complete our upgrade journey utilising one of the 3 upgrade models that are available to you by Microsoft.  These are listed as follows;

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 theUpgrade 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  -WebApplication 

Launch the SharePoint 2010 Management Shell and type the above command, ensuring you have entered your Database Name and URL. e.g. below

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

The Test-SPContentDatabase is a great reporting tool that will list any missing setup files, web parts and provide you with information on how to remedy any errors.  It will also specify whether these missing features will block the upgrade from succeeding.

You can either attend to these missing features pre or post-upgrade but this depends on whether there are any items that will block the upgrade from proceeding.  Once you have remedied the above, we can proceed with our next tool, which will add the content database to our Web Application.  The stsadm  addcontenddb command line parameter is as follows;

stsadm -o addcontentdb -url  -databasename 

Before proceeding, ensure that there are currently no databases connected to the web application that we will be attaching to.  You can check this via Central Administration / Application Management / Manage content databases.

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  -databasename 

In my instance, the command looked as follows;

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

This will initiate the upgrade process as per the below screen capture.

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

Share|

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

 my last article I provided you with a guide in setting up your SharePoint 2010 farm providing it with the capabilities in receiving incoming email which can then be delivered directly to your SharePoint libraries and or lists.  Today we wrap up our 2 part series on email flow in SharePoint 2010 in which I will provide you with another step by step guide in configuring your SharePoint Farm in order for it to send outgoing emails through your Microsoft Exchange server.
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.

Share|

Configuring the User Profile Service in SharePoint 2010

http://sharepointgeorge.com/2010/configuring-the-user-profile-service-in-sharepoint-2010/I first introduced Service Applications and User Profile Service Synchronization back when SharePoint 2010 was in beta, and as many of you who would have attempted this feat, would have come to realize that there were a couple of known issues, in particular those around utilizing a least privilege model with service accounts.  I’m confident in stating that these issues have now been resolved with RTM and in today’s article I will share with you my step by step guide in setting up the User Profile Service application, focusing on its configuration and administration and how we can enable the creation of user profiles via an Active Directory import .
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: 
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 (UPS) service will be deployed.  Please make a note to remove the DOMAIN\sp_farm account from the Local Administrator’s group after provisioning the User Profile Synchronization service.  Please also note, that if you ever have to re-provision the UPS service at a later date, that you will need to ensure the DOMAIN\sp_farm account is added back to the Local Administrator’s group.
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

Share|