This article applies in a situation when you don’t have internet access in your SharePoint server , I have placed all the direct download links for the installers you might need.

This article assumes you are having a new fresh installation of windows server 2008 R2 SP1

If you tried to run the installer , The following should be installed (but you cant install them directly from here since you don’t have internet)

in this case  you can download and install SharePoint 2013 Prerequisites offline and run them manually as below:

I have placed what needs to be installed on a clean Window server R2 SP1 , you should not need more than this:

In this post I will go through upgrading SharePoint sites from SharePoint Portal Server 2003 to SharePoint 2010 , I will include directions to use the most relevant upgrade approach, as start Upgrade from SharePoint Portal Server 2003 to SharePoint 2010 is really challenging as there is no direct path to upgrade from SPS 2003 to SharePoint 2010,  first it should be upgraded to SharePoint 2007 as first step then to proceed from 2007 to 2010 version.

One of the most important parts that need to be considered is the custom components ,In many cases, SharePoint 2010 has far more advanced and richer user interface elements which would definitely make the need for some of these custom components irrelevant

The other aspect of SPS 2003 customization was related to branding “look and feel” elements such as graphics and style sheets. Because SharePoint 2010 is dramatically different from SPS 2003 and it has the ribbon control it is recommended that the branding be completely redone using SharePoint 2010 native master pages and compliant style sheets. This will be an opportunity for a fresh look and feel for the portal signifying the additional ground-breaking features SharePoint 2010 will be introducing to the customer user community.

The following is one of the common upgrade paths from SPS 2003 to SharePoint 2007:

The following is the upgrade steps from the SharePoint 2007 environment to SharePoint 2010:

Typically where there are custom solutions like compiled components such as Web Parts and such, it is expected that these components might fail in SharePoint 2010. In some cases these components might seem to work well after the upgrade but it might not be desirable to keep these components in their pre-2010 binaries. For such components it is recommended that they be targeted for the SharePoint 2010 environment and then recompiled after the appropriate testing and validation to make sure that they can live side-by-side with other components in SharePoint 2010 without destabilizing the whole farm.

As mentioned above, there are many factors that make an upgrade from SharePoint Portal Server 2003 to SharePoint 2010 not an easy task. These include some of the following reasons:

• In-place upgrade are not possible because of the need for 64-bit hardware in SharePoint 2010
• It’s is a requirement to have an intermediate upgrade to SharePoint 2007 as there is no direct path from SPS 2003 to SharePoint 2010
• Some custom components might not be compatible with SharePoint 2010

For some of the reasons mentioned above, in this post we will follow an in-place upgrade from SPS 2003 to SharePoint 2007 and then a database attach method into the new SharePoint 2010 farm. The in-place upgrade will preserve as much functionality as possible during the upgrade to 2007. From SharePoint 2007 to SharePoint 2010 we have no choice but to use the database attach method as we cannot perform this upgrade on non-64 bit hardware. Even if it were possible, it better the upgrade to be performed on the final farm in which SharePoint will finally reside.

the following steps illustrates the In-place Upgrade from SPS 2003 to SharePoint 2007

• Run The Prescan Tool in Production
• Fix an Issues identified from the Prescan Tool
• Copy the production database to the Development Environment
• Make the Production Database Read-only
• Start the SharePoint 2007 in-place upgrade in the Development environment
• Test and validate all functionality and Web Parts in the SharePoint 2007 environment

Database Attach Upgrade from SharePoint 2007 to SharePoint 2010

• When all functionality has been validated in SharePoint 2007 move the Content database to the SharePoint 2010 function using the database attach method
• Test and Validate the portal in SharePoint 2010
• Remove and recreate features using SharePoint 2010 as needed
• Start the Feature Gap analysis process
• Enable 2010 Enterprise Search and add all existing Network File Servers as well as all existing internal sites and portals
• Create dedicated file store repositories for each department mapping or mimicking the current File Server directory structures for each department
• Enable use of SharePoint workspace in the portal

When performing the upgrade process, Current SharePoint environment should become in read-only mode to make sure no updates are taking place over the online version. Meanwhile, the upgrade process will take place in the lab environment. After a successful migration, the new portal will become available for users and the old environment will be taken offline to ensure that all users start using the new farm.

The upgrade process will be tested in the lab environment to make sure all issues will be identified, fixed and remedied before performing the actual upgrade. The customer team should be confident enough by performing the upgrade exercise more than once to avoid any complications in the actual upgrade process.

Planning is critical to a successful upgrade project. You must be methodical in your approach, because you will have to prepare all of the solution design areas, from requirements analysis to support. Prepare by assembling the right team, which should deliver business, technical, and project management skills. The team must then establish the working practices and resources that are necessary for the upgrade to complete successfully.

The Upgrade Cycle

Learn

Ensure that you fully understand—and your plan reflects—upgrade requirements such as 64-bit hardware and software. Use the available tools to preempt issues such as missing dependencies or lack of storage capacity. You should know and evaluate the update options for your farm or farms. This should include development of a plan for the completion of all of the tasks that are necessary for all of the versions of Office SharePoint that you must upgrade. You must also ensure that your plan reflects business requirements such as system downtime.

Prepare

Your upgrade plan should reflect what you have learned. It must have an exhaustive breakdown of events in chronological order, so that the administrators who implement your plan have all of the correct components in place. This plan should include all prerequisites. It should also include information about how to identify and manage any existing customizations and how to manage individual solutions and items.

Always establish a fallback position. An upgrade failure may be beyond your control, such as a hardware or power problem, so you must have a plan for ensuring that your business users can still work in the morning.

Test

If you are upgrading a business-critical system, you must always pretest your plan; this should be no different for SharePoint 2010 upgrades. If possible, you should build a test environment and test each component of your upgrade. This does, of course, take time. However, attempting to rebuild a business system after a failed upgrade will take longer, and it will cause greater problems for your organization.

Use copies of production data and hardware if possible, but you can sample data and virtual machines to do worthwhile upgrade testing.

Implement

When you have completed your tests and are satisfied with your mitigation plan, you should schedule the upgrade. You should have established how much time the upgrade will take through your test runs, but monitor the progress of your upgrade by viewing the status indicators. This will help you to assess any time differences between your tests and the upgrade exercises.

Validate

Always validate an upgrade by reviewing logs and testing applications. After a long upgrade, it can be easy to ignore apparently minor errors, but you must check everything thoroughly. As part of your upgrade, you should have experienced users who can test the validity of data to reveal any potential issues. You should also test for user experience (UX) in addition to UI changes. Note that the UX concerns the overall familiarity of your applications, and not just the visual changes in the UI. Your user acceptance testing must ensure that users are happy with any changes to working practices enforced by the upgrade. This will be of particular relevance to users who upgrade from Office SharePoint Portal Server 2003 or migrate from third-party platforms.

Planning an upgrade is more complex than planning a new deployment—it has all of the challenges of a fresh deployment and the additional problems of migrating existing business environments to the new platform. This means that in addition to planning to perform all of the installation tasks, you must also plan a complete review of your existing environments.

The list of tasks that you should perform when planning an upgrade includes:

• Gather business requirements.
• Plan business communications.
• Execute upgrade tools to gather information about the current environment.
• Test the upgrade.
• Perform environment cleanup.
• Build hardware.
• Perform pre-upgrade backups.
• Establish a project schedule.
• Test rollback and restore options.
• Perform post-upgrade activities.
• Establish launch and ongoing support management.

Now how to choose the upgrade path for your Farm

Migration and Upgrade Resource Center for Microsoft Office SharePoint Server 2007 contains the needed resources for IT pros to help migrate to Microsoft Office SharePoint Server 2007 from Microsoft Office SharePoint Portal Server 2003, Microsoft Windows SharePoint Services 3.0

For more information please follow the link http://technet.microsoft.com/en-us/office/sharepointserver/bb421259

The following table lists and compares different upgrade approaches

Then for your next step of upgrade There are two basic approaches to upgrade: in-place and database attach. In addition, there are various techniques you can use to combine aspects of these basic approaches to mitigate downtime or potentially improve performance.

The following table compares the in-place and database attach approaches.

for more information please follow the link from SharePoint resources center http://technet.microsoft.com/library/cc263447(office.14).aspx

In the next posts I will show how to perform the upgrade with step by step sample upgrade process

In the first post we have covered the planning steps and upgrade options you need to consider for your upgrade process , in this post we will perform step by step upgrade from SharePoint portal server 2003 to SharePoint 2010

Upgrade Toolkit for Windows SharePoint Services from 2003 to 2007

Before starting the upgrade from 2003 to 2007 especially for the cases of custom areas and site template of SharePoint portal server 2003, you should be aware of Upgrade Toolkit for Windows SharePoint Services Sites and Templates Guide of which Solution Accelerator Team (SAT) has created a solution accelerator that provides guidance and tools to enable IT Professionals to successfully upgrade their Windows SharePoint Services 2.0 custom sites and templates

When you upgrade from WSS 2.0 to WSS 3.0, your existing SharePoint sites are upgraded to work in the WSS 3.0 environment and the new WSS 3.0 features are applied to them. Also during the upgrade, the default WSS 2.0 site templates are replaced by WSS 3.0 equivalents. This is not true, however, for WSS 2.0 customized sites and site templates―there are no equivalents for them and they do not upgrade correctly.

The Upgrade Toolkit for Windows SharePoint Services Sites and Templates serve two main purposes:

· To provide IT professionals with the guidance and tools that they need to upgrade customized WSS 2.0 sites and site templates to function in a WSS 3.0 environment. The upgraded sites and site templates maintain their customizations and acquire a set of WSS 3.0 features.

· To provide a set of upgraded application templates for Windows SharePoint Services based on those currently published for WSS 2.0 on TechNet and to provide instructions for installing these application templates in a WSS 3.0 environment.

You can download the guide from the following URL

http://www.microsoft.com/en-us/download/details.aspx?id=14157

now lets proceed with the upgrade sample

Step 1 In place upgrade for SharePoint 2003 to 2007:

In place upgrade starts by installing SPS2007 at server on which you have already restored a SPS 2003 portal, for the upgrade process no need to install new SQL server, SharePoint 2007 works with both SQL 2005 and SQL 2000 which usually installed for server that runs SPS 2003.

Start by MOSS (Microsoft Office SharePoint) installer, Double click on setup.exe

Enter the product License key then click on ‘Next’

Accept the Microsoft Software License Terms, then click on ‘continue’

On the windows below choose ’Yes, perform a Gradual upgrade. This will allow the existing installation to function and enable you to upgrade web sites in batches. This is best for large installations or where web sites have been extensively customized’ and click on ‘install now’

When the page below is displaying , uncheck ‘ Run the SharePoint Products and Technologies Configuration Wizard now’ then click on ‘close’.

Launch of pre-scan tool

Before proceeding run the pre-scan tools (the pre-scan tools shows errors that may occur during upgrading process such as orphan’s links)

Pre scan tool can be found at SystemDrive:\Programm Files\Common files\Microsoft Shared\web server extensions\12\BIN

Launch DOS console and type cd Drive:\Programm Files\Common files\Microsoft Shared\web server extensions\12\BIN

Type the command prescan /c preupgradescanconfig.xml /all, scan process will take place resulting in two files one of them is XML file and the other is txt file they will be created in current folder.

Click here for more details about the Prescan tool also Here you can find a good article describing prescan in more details

Most probably you will see the screen above, as it’s expected that you will have some errors

Open the log files and search for “error” word and starting fixing them, here you can find helpful steps that help fixing the error such as deleting the orphaned sites.

In our case custom site definitions caused the issue , and those site definition are created to reflect organization look and feel and special branding images, so resetting them to initial state will not cause a big issue as we already planning to recreate the branding.

In our case we need to fix custom site definitions that caused the errors by resetting them to their initial state ,thanks to Upgrade Toolkit for Windows SharePoint Services Sites and Templates Guide that helped us resetting the site definitions to its initial state, also please check this blog How to Upgrade an Area based on a Custom Site Definition.

Lunch configuration wizard as indicated in screen below

Click Next ,You will see a warning for some services that need to restarted, click ‘yes’

Information message getting displayed asking either you have language packs to be installed click ‘OK’

Check ‘No, I want to create a new server farm’, then click on button ‘Next’

Specify Configuration Database Settings

Database server: Server Name

Database name: The name you want to give to the new database

(SharePoint_2007_Config)

Specify Database Access Account

Username: domain\Spsadmin

Password: SPSAdmin password

In Configure SharePoint Central Administration Web Application screen check ‘negotiate (Kerberos)

Click ‘yes’ on the ‘warning windows’ , then click Next

Configuration is in progress, then this screen is shown

now we need to Reset Site Definition

open the portal and from Site settings/Modify all site settings

Click on reset to site definition

Now navigate to SharePoint Central Administration , then Click on ‘Operations’ at the left side of the page, then Click on ‘Site content upgrade statues under ‘upgrade and migration’

On the next windows click on ‘Begin Upgrade’

Fill in the needed information then click ok

Upgrading should be done in stages as maximum of 500 sites can be checked at once.

now after selecting the sites , click on upgrade sites

You will have this page which shows you the status of upgrading process

now proceed with other sites by clicking on continue upgrade

now we should have reached to the middle stage , the site is now upgraded to 2007 version, in the next post we will proceed with next steps for upgrading to SharePoint 2010

Architecture

In this port , I’m going to talk about the FAST Search components and how they are interacting with each other , I recommend to read this article before start deploying FAST search as it should give a good guidance and understanding for your deployment plan: 

• FAST Content Search Service Application (SSA):

Is the default indexing connector and retrieves content from various content sources such as SharePoint content repositories, Web servers, Exchange folders, line of business data and file servers.

its worth to mention that this is a SharePoint service applications that will run within SharePoint farm

• FAST Query Search Service Application (SSA):

handle query results from users.

its worth to mention that this is a SharePoint service applications that will run within SharePoint farm

Note: for large FAST deployments I recommend to dedicate a special SharePoint application server to host the Content SSA and Query SSA service applications

The rest of the below components are FAST components: 

• Content Distributor:

Content distributor communicates with the indexing connectors and organizes the feeding of documents from indexing connectors to the indexing service. You can set up a primary and a backup content distributor for fault-tolerance.

• Item Processing: (document processor) :

The item processing component receives items to be indexed from indexing connectors. and process the items according to the given configuration. It then sends the processed items to the indexing service ,item processing responsible for:

• Extract properties from crawled content (name, date) or custom property.
• Mapping crawled property to managed property
• Extract content searchable text from document format (word, excel, pdf).
• Linguistic processing: which is the use of information about the structure and variation of languages

• Web Analyzer:

It analyzes search clickthroughs logs and hyperlink structures. Both contribute to better ranked search results as the following:

• Items that show many clicks in the search clickthroughs log are popular and therefore receive better rank scores than less-viewed items.
• Items that are linked to from many other items are also perceived to be more relevant for the user and therefore receive better rank scores.

• Search Cluster:
  • The search cluster provides the main topology for indexing and query matching
  • These components require their own scaling models using a matrix of servers in a row/column configuration.
  • The figure illustrates a deployment with four rows: two pure indexer rows and two pure search rows. In real deployments, it is common to combine indexer and search rows in order to reduce hardware footprint.

Below is a Real deployment scenario using same server role for indexing and Query matching in 3 servers topology will look like below where:

• One Admin server is used to host admin components like (content distributor, web analyzer, indexing dispatcher)

Primary and backup indexer You can configure a backup indexer node for fault tolerance.

One row in the configuration file is used to determine Search rows and indexer rows like in below example is a pure index server.  <row id="0" index="primary" search="false" />

• Search row corresponds to Search=”true”. If marked true, Query Matching component is deployed on that row.
• An indexer row can have the roles primary, backup, and none , An indexer row can also be a search row
• A <row> tag can be defined as a primary, secondary or none using the index attributed, There can only be one primary index row in the topology:
  • Marking the <row> tag as primary indicates this is the primary row of servers with Indexing components.
  • Marking the <row> tag as secondary means the row is redundant index row.
  • marking the <row> tag with the value of “none” means there is no Indexing components on this row.
• Indexing:
  • The indexing component creates inverted indexes, based on the items that it receives. The indexing component sends these inverted indexes to the query matching component for later use during query evaluation. (indexer is like crawler in SharePoint).
  • Each index column will contain one part of the index, and the combined set of index columns will form the complete index. In this case, each indexing node will handle only a part of the whole index.
  • Additionally, backup indexing nodes can provide fault tolerance.

• Query Matching:The query matching service uses the inverted indexes created by the indexing service to retrieve the items that match query and then return these items as a query hit list.
• The query matching service looks up each term in the index and retrieves a list of items in which that term appears.
• Resolve Query operators, such as AND and OR, the query hit list will consist of the set of items that contain all the terms. The order of the returned items is based on the requested sorting mechanism.
• The query matching service is responsible for the deep refinement that is associated with query results.
• You can deploy the query matching service in a row/column setup to achieve fault-tolerance and scaling in content and query volume.
1. Index columns provide ways to scale out for content volume, by partitioning the overall index into a set of disjoint columns.
2. Search rows provide ways to scale out for query volume, by duplicating the same partition of the index across more than one query matching node.
• can be installed in multiple servers for tolerance and performance
• number of columns should be equal to number of index files.

Search Cluster Example:

In below example you can see 4 servers , you can see one Indexing node-X in row 1 with a corresponding Query Matching node-x in row 2 , with fault tolerance applied , the below is called Search cluster, where each index row should contain a complete set of indexing (full index = index-X + index-Y) , mapped to a corresponding querying matching component in the same column. (Index-X in row1 is mapped to Query Matching-X in row 2)

• Query processing
• Is triggered when users hit on search button , The query processing component performs pre-processing of queries and post-processing of results.
• contains Result processing that includes merging the results from multiple index columns.
• It performs formatting for the query hit list, formatting the query refinement data, and removing duplicates.
• The query processing component interacts with the FAST Search Authorization (FSA) component to make sure that the user performing a query sees only the results that he or she is authorized to see.
• The query processing service can be scaled out across multiple nodes to handle fault-tolerance and more queries per second.

• Administration

The SharePoint Server 2010 Central Administration and site collection user interfaces provide the administrative interfaces for managing the FAST Search Server 2010 for SharePoint deployment and features.

The administration component contains functionality to control the search experience, such as determining how to perform property extraction, ascertaining which synonyms to use, and determining which items to use as best bets.

Consist of the below :

• Index schema administration : The index schema contains all the configuration entities that are needed to generate the configuration files that are related to the index schema for all the other services in the system.
  • The index schema controls which managed properties of an item will be indexed
  • how the properties will be indexed .
  • The rank profile is a part of the index schema that controls how the query hit list will be sorted by relevancy.

• Fast Search Authorization (FSA): The FAST Search Authorization (FSA) manager is a part of the administration service that manages user authorization for indexed content.

Ensures that only items that a user is entitled to read appear in the query results.

The FSA manager communicates with Claims services, Active Directory services or other LDAP based directory services to manage the authorization process.

FAST Search Web Crawler

The FAST Search Web crawler is an optional indexing connector that can be used for complex Web crawl scenarios involving a mix of Internet and Intranet sites.

The FAST Search Web crawler reads Web pages and follows links on the pages to process a complete Web of items. It then passes the retrieved items to the item processing service.

References:

http://technet.microsoft.com/en-us/library/ff599530.aspx