SharePoint 2010 - Enterprise Search

Search is one of the compelling reasons to invest in the platform when evaluating SharePoint for a many companies.

Search Capabilites

The architectural changes in SharePoint 2010 allows to index File Shares, Exchange public folders, Other websites, LOB data and even Lotus Notes Databases and supporting multiple index partitioning or multiple index servers.

Search Limits

SharePoint Search now has a capacity to 100 million items, And if you incorporate Fast search the upper limit will be 1 billion items. Isn't that good enough for a big Enterprise ??

Search Experience

User experience is enhanced with wild card searches, support for Boolean operators, and a refi nement panel. New Searchspecific master page that provides more screen real estate, and AJAX support for rendering Web Parts — and extensible Web Parts this time around.

SharePoint 2010 - What new in PATCHING SharePoint 2010

Patching is referred to as a build-to-build or b2b upgrade, as it is only upgrading to a newer build of the same version

One of the most great improvements in patching with SharePoint 2010 is that the binaries on your farm can be at a newer version than the databases those binaries are using, if both builds are in the same compatibility range.

The compatibility ranges should be between service packs, meaning that any database that is SharePoint 2010 SP1 or higher should be able to be rendered by binaries that are at the same build or later, but before SP2. This gives you the freedom to upgrade your binaries without immediately upgrading your databases at the same time. Walking through all your databases and upgrading them is the most time intensive part of patching, so being able to postpone that is a huge advantage.

Meaning you’ll be able to patch the binaries running on your servers quickly and take advantage of any fixes or security updates without having to incur the downtime penalty of upgrading

your databases too You can postpone the lengthy database upgrade part to a more convenient

time, like over the weekend.This is especially handy if you have user bases in different time zones. While you shouldn’t plan on leaving your farm in this condition for weeks or months, you can safely do it for a few days.

Once you decide to upgrade the databases then run the command "Upgrade-SPContentDatabase" with the name of the specific database, And as like "Mount-SPContentDatabase" you can run multiple instances of the upgrade command.

Not only can your databases be out of sync with the binaries installed on your server, but the servers themselves can be at different build levels as well. This is truly an advanced move, however, and should only be used when necessary by trained professionals. If you do choose to patch your servers individually it’s recommended that you do tiers of them at a time. For example, if you have several servers running the Search component, try to keep their patch level in sync. If you have multiple web front ends (WFEs), keep them in sync or all search servers in sync etc.

SharePoint 2010 - What is the best Upgrade Practice ?

Nothing makes a grown man scream like a little kid or as bad as realizing they don’t have any backups — or even worse, realizing the backups you have cannot be restored. So the foremost thing to keep in mind is have complete set up backups for all the required.

In-Place Upgrade

The most obvious path to upgrading SharePoint 2007 to SharePoint 2010 is an in-place upgrade.

This method is the simplest, and boils down to clicking Next ➪ Next ➪ Finished. Wooho...

Congratulations, you have SharePoint 2010. But fairly speaking it is not that easy though.

When you do an in-place upgrade, you’re installing SharePoint 2010 on the same hardware as

your existing SharePoint 2007 farm, and for the most part everything stays the same. For example, URLs are the same for your users, settings are retained, custom code is still installed, customizations are still there, and application pools run as the same accounts. If you were to envision your “dream” SharePoint upgrade, this would be it.

Considerations before you go for the above approach.

1. Your hardware should support SharePoint 2010 .i.e. all servers should be Server 2008/R2 64Bit

2.SQL should have a supported version (stsadm -o preupgradecheck command can discover this).

3.Considerable amount of downtime, since the content will not be available until all the upgrade completes (Drawback here)

Database Attach

In this method you already have a SharePoint 2010 farm installed and configured. To upgrade your content, you attach a SharePoint 2007 (service pack 2 or later) content database, which SharePoint 2010 will upgrade. Sounds easy, Giv a try...

The Database attach method requires that you have separate hardware for your SharePoint 2010 farm; you cannot use your SharePoint 2007 hardware unless you remove SharePoint 2007 from all of the machines and install SharePoint 2010 on them.

Considerations for DB Attach method

1. The database attach method also usually results in different URLs for your web applications, as the corresponding SharePoint 2007 farm istypically online at the same time.

2.You have more control over the data.

3.You can attach multiple databases at the same time by opening multiple command windows provided your sql has the capacity to handle.

4.In simple > use the below set of commands in the sequence for every database that you want to attach to the new SharePoint 2010 farm

Use Test-SPContentDatabase ( Can ignore those basic errors if needed which can be fixed later)

Then Mount-SPContentDatabase to upgrade and attach the database to SP2010 Farm. In case of failure at any stage you can re-run the command Upgrade-SPContentDatabase

SharePoint 2010 - What does a preupgrade check looks for ?

• Farm is at service pack 2 or later
• Supported operating systems (Windows Server 2008 SP2 64-bit or Windows Server 2008 R2)
• Database schemas have not been modified
• Configuration database does not have any site orphans
• Content database does not have any data orphans
• Farm is not still in a gradual upgrade from SharePoint 2003
• Databases are read only
• Invalid entries in web.config
• Custom site definitions
• Large lists
• Views and content types that use CAML