Rebuilding SharePoint Farm

Recently, I have done a rebuild of a SharePoint Farm for a QA environment. It is really a challenging task to rebuild a SP Farm, because some servers must be already running and you need to create a new server and deploy your stuff out there on the new one. I managed to setup the QA, but the turn-around time was poor as I was facing so many roadblocks in setting up and configuring servers. Sharing you some of the major tasks which I have done to rebuild the SharePoint Farm.

 Install Windows Server 2008 R2

• Click Here to know more about the System Requirements

Install IIS 7.0 on Windows Server 2008 R2

IIS is one of the Windows Server Server roles. IIS 7 can be installed through the graphical user interface (GUI), using the new Server Manager interface after the Windows Server operating system is installed.

You can also enable IIS 7.5 in Windows Server 2008 R2.

 

Server Manager provides a single dashboard to install or uninstall server roles and features. Server Manager also gives an overview of all currently installed roles and features. When IIS 7 is chosen from the Server Manager, the basic components and services needed for IIS are automatically selected.

 

1. Click Start -> All Programs -> Administrative Tools -> Server Manager.

 

2. In the Server Manager Window, scroll down to Roles Summary, and then click on Add Roles. The Add Roles Wizard will start with a Before You Begin page. The wizard asks for verification of the following

• The administrator account has a strong password.
• The network settings, such as IP addresses, are configured.
• The latest security updates from Windows Update are installed.

3. Select Web Server (IIS) on the Select Server Roles page. An introductory page will open with links for further information.

 

4. Select the IIS services to be installed on the Select Role Services page. Add only the modules necessary. In this case, ASP.NET is selected, and a description of ASP.NET appears in the right pane. Once desired modules are added, click Next.

 

5. Add any required role services.

 

6. IIS is now installed with a default configuration for hosting ASP.NET on Windows Server. Click Close to complete the process.

 

7. Confirm that the Web server works using http://localhost/.

 

 

Install .Net Framework 3.5 on Windows Server 2008 R2
 
Here are the steps to verify that .NET Framework 3.5.1 is installed on Windows Server 2008 R2.


1. Click the Start button in the lower left hand corner of the display.
2. Highlight Administrative Tools and select Server Manager.
3. In the Server Manager interface, click Features to display all the installed Features in the right hand pane. Verify that .NET Framework 3.5.1 is listed.

If .NET Framework 3.5.1 feature is not listed, you can use the following method to install it:

Using Server Manager Interface

1. In the Server Manager interface, select Add Features to displays a list of possible features.
2. In the Select Features interface, expand .NET Framework 3.5.1 Features.
3. Once you expand .NET Framework 3.5.1 Features, you will see two check boxes. One for .NET Framework 3.5.1 and other for WCF Activation. Check the box next to .NET Framework 3.5.1 and click Next.

Note: If you do not expand .NET Framework 3.5.1 Features and check it, you will get a pop-up titled Add Features Wizard as shown below.

Click Cancel and expand .NET Framework 3.5.1 Features and then check .NET Framework 3.5.1 check box below it.

Site Templates

A site template provides the basic components and layout of a new site created under SharePoint. It contains specific design information about a site, including the lists that are part of that site, Web Part Pages used in the site, the site’s themes and borders, changes to the Quick Launch bar, as well as some site content (such as document libraries).

Site templates are used to allow the rapid creation of web sites and basic content in a SharePoint system. Any number of new sites can be generated based on a site template, which is a set of basic content pages and schemas (which are themselves stored on the Web server as a set of HTML and XML files). There can be an unlimited number of site templates, although typically there are basic types and a few templates customized to an organization’s specific requirements.
Site templates are stored in the SharePoint database and can be accessed through template galleries. Once a site template has been created, other users can use that template (or create copies of it for further modification). User-created site templates can be imported to the site collection level, adding them to the site template gallery. Site template files have an “.stp” extension.

Site templates provide several important benefits for site administrators:
They enable you to have a consistent, professional look throughout your portal site.
They provide an efficient way to create subsites and site collections. Individual groups within your organization don't need to set up their sites from scratch, which can be costly and time consuming.

Their use results in a uniform, professional look throughout your portal site that reflects your organization's standards.
Site administrators and designers can create a site template by customizing a site and then saving it as a site template. The site template can be used by others to create sites with the same look and feel. Site collection administrators can also import a site template that was created by another administrator or designer and add the new template to the available site templates in the site collection.

Site templates, compared to site definitions, are easy to create and deploy. You can make all customizations through the user interface or FrontPage 2003. In addition, you do not need to be a server administrator on the Web server to create and deploy site templates. You can modify a site template without affecting existing sites created by the template. Deployment is simple because template data is stored centrally in the configuration database.

Because it is slow to store templates in and retrieve them from the database, site templates can result in slower performance. Templates in the database are compiled and executed every time a page is rendered. Windows SharePoint Services does some performance optimization whereby it stores templates on the local Web server and a copy (or “ghost”) of the page in the configuration database. However, you can easily prevent Windows SharePoint Services from using a copy of the page by using Web Folders or FrontPage to open, modify, and save it. From this point forward, the database is used to render the page. Preventing Windows SharePoint Services from using a copy of a site page will cause the page to stop picking up changes from the site definition files, so if you want to keep a consistent look across the entire portal and only want to modify the site definition files, then don’t prevent this optimization. Rendering pages from the database will result in an initial performance penalty.

Site templates only work on SharePoint sites that are not portal sites (not based on the SPS templates). Furthermore, site templates are not ideally suited for a development environment. In effect, they are still customizations of a site definition. If the site definition does not exist on the server, the site template fails.
Typically, because of these issues, site templates are not as efficient as site definitions in a large-scale environment”

But you should notice that, when you create site out of site template or site definition, and make changes to either of them, will that effect the sites already created out of them? I am still having this confusion

Site Definition

Site Definition contains a server-side collection of files that defines the structure of one or more site templates.

A site definition is composed of the following:
A webtemp.xml file that defines the numbering and creation details for the various site templates that are contained in the site definition.
A separate directory that contains all of the core files used by the site definition, excluding any items that are provided through Features.

The webtemp.xml file is stored in

%COMMONPROGRAMFILES%\Microsoft Shared\web server extensions\12\TEMPLATE\1033\XML

The directory that contains the site definition files is named according to the site definition’s name and is stored in

%COMMONPROGRAMFILES%\Microsoft Shared\web server extensions \12\TEMPLATE\SiteTemplates

Customizing portal sites and other SharePoint sites using site definitions is most appropriate for third-party developers and server administrators. Because site definitions require access to the file systems of the Web server, server administrators must always be involved in the deployment of site definitions. If you are modifying areas of a portal site, then you will need to use site definitions.

Although deploying a site definition requires more work, site definitions typically perform better when cached on the file system instead of in the database. In addition, you can achieve a finer level of customization by directly editing all the schema files and not depending on the existing site definition as a site template does. Also, if you want to introduce new file types, view styles, and drop-down edit menus, you need to edit the schema files that make up the site definition.
Custom site definitions are version and upgrade independent. Subsequent upgrades to SharePoint Products and Technologies may overwrite existing default site definitions. Using custom site definitions excludes your sites from potential upgrade issues.
However, there is no easy way to modify site definitions once they are deployed. There is always the possibility of breaking existing deployed sites derived from the site definition once you modify an existing site definition. You can only add to the site definition once it is deployed.

SharePoint Solutions

Solution packages are the preferred mechanism for deploying WSS components. The solution package itself is a compressed CAB file with a .wsp extension, and it contains one or more WSS components along with any dependent files that need to be deployed on each front-end Web server.

A simple solution package might contain just the files needed to deploy a single feature. A more complex package could contain the files for multiple features, applications pages, Web Parts, list definitions, event handlers, and a site definition.

The WSS runtime provides a built-in installer component that runs on each front-end Web server and is responsible for uncompressing the files inside a solution package and properly installing its components. The WSS installer requires each solution package to carry additional metadata inside a file named manifest.xml. When the installer is called upon to deploy a solution package, it reads the metadata in manifest.xml to determine exactly which components and files from inside the CAB file need to be extracted and deployed.

Manifest.xml contains metadata to instruct the installer which files need to be extracted from the solution packages and copied into various WSS system directories. But beyond that, manifest.xml also carries metadata that tells the installer to perform other important deployment procedures, such as registering features with the WSS runtime, adding assembly DLLs to the Global Assembly Cache (GAC), and updating the web.config file with SafeControl entries required in Web Part deployment.

Branding in SharePoint

Branding is the successful attempt to symbolicly embodiment of all the information connected to a company, product or service. Branding helps you identify a company, product or service through the use of consistent logo, colors and text.SharePoint 2007, allows for many forms of customization to transform the presentation of the content to meet the needs of those that require it.

Starting with the third generation of SharePoint Products and Technologies, the SharePoint platform is built natively on top of the Microsoft .NET Framework. The SharePoint product team has developed a custom HTTP application and custom HTTP handlers and modules to create SharePoint Products and Technologies and change how Microsoft ASP.NET 2.0 works

SharePoint Object Model Hierarchy

Microsoft Office System Architecture