SharePoint Farm configuring and deployment Part 2 – Installation & Configuration

07. Jun, 2009 Comments

  • Part 1 – Architecture and Logical Planning
  • Part 2 – Installation
  • Part 3 – Development Environment
  • Part 4 – Backup and Recovery Strategy
  • Part 5 – Virtualization
  • Part 6 – Post Deployment (final)

Installation

The recommended Windows environment that offers the best performance for SharePoint is to have 64-bit servers. Such an environment provides significantly larger address space than 32-bit one; more room for SharePoint assemblies, CLR/Native APIs, Network Stack, IIS/ASP.NET and other components hosted in their respective tiers.

Windows Server 2008 and SQL Server

SharePoint install on the Windows Server 2003 and 2008. The recommendation is to use Windows 2008 because it has the outmost security. For the Windows 2008 you need to activate the following roles: Web Server role and the Microsoft .NET Framework 3.5.

Take into account that Windows 2008 Web Edition is not supported for farm roles, except WFE boxes, due to restrictions of non-Web editions of SQL Server on Windows 2008 Web Edition. The release of “SQL Server 2008 Web Edition” extends usage of Windows 2008 Web Edition for SharePoint. Refer to licence regulations and SQL Server 2008 Web Edition info for more details: http://tinyurl.com/b8nype

Do not install SharePoint on Domain Controller box in virtualized environment. DC role of Windows 2008 limits performance of hard drive by turning off caching to provide AD consistency. Any installations on virtualized DC might not work properly.

SharePoint installation supports  SQL 2005 and 2008 Servers (even SQL Server 2000 is supported, but there are not much advantages of its usage). SQL Exress edition is supported as well, but for basic MOSS installation, however basic install of WSS 3.0 will use Windows Internal Database (WID doesn’t have size limitation). SharePoint installs only on SQL Server, but you can use BDC use content from 3-rd party databases.

A few advantages of SQL 2008 over SQL 2005 are in performance, encryption, clustering, mirroring and etc. Moreover, it provides updated SharePoint Web Parts for Reporting Services and KPI. Detailed information about SQL 2008 and SharePoint can be found in the following post http://tinyurl.com/cdkcyw.

User SQL Aliases

When provisioning a new SharePoint farm, it is highly recommended to use an alias to connect to the Microsoft SQL Server, as this provides for greater flexibility to move the SharePoint databases to a new server. For example, using an alias during the installation will simplify the migration process of SQL database server from small environment to larger physical cluster during scaling out process.

Install Microsoft Office 2007 on farm premises (optional)

Office 2007 is not required on SharePoint server, but it might be  good to have it somewhere in you farm premises (not server box) for administrators, especially when you outsource your support or/and admins connect  remotely. In this case they might  need client apps installed somewhere to have access to

  • Word and Excel for documents in Document Library
  • PowerPoint for Slides in Document Library
  • Access for “Edit in Datasheet” support in Document Library

Consider the same for Office SharePoint Designer(SPD), which is necessary for customisation purposes. (SPD is a  free product with is distributed as separate product that is not include into Office)

Install all Windows Updates

Make sure that all servers have the latest service packs and updates for Windows, SQL and Office prior installing SharePoint.

Choose the right edition of SharePoint

Be careful when use Enterprise edition of SharePoint, because Microsoft doesn’t provide the support if you decided to downgrade to Standard version, due to loss in features and functionalities. If you need Standard edition then consider a fresh installation.

Install SharePoint

Install SharePoint across all servers in farm. Start with WSS/MOSS slipstream package (with integrated latest Service Pack) rather then using basic WSS/MOSS installation and applying Service Pack later.

Follow the next order of installation:

  • Application server where Central Administration site will be hosted
  • All front-end Web servers
  • The index server (if using a separate server for search queries and indexing)
  • The query servers, if separate from the WFE servers
  • Other application servers (optional)

Consider using scripts to automate SharePoint installation and configuration for the large farm deployment. SharePoint provides several configuration files and console commands that will do all deployment un-attendant. This will speed up installation and brings consistency of building and rebuilding servers in farm.

There are three commands to automate SharePoint installation:

  • SharePoint Setup.exe + Config.xml – to script the setup questions
  • PSconfig.exe – to script configuration wizard
  • STSADM.exe – to script central admin UI for creating web apps and site collections

Alternative solution is to use already preconfigured Power Shell scripts. “SharePoint Deploy” tool on CodePlex provides the configured scripts for the standard installation, which can be adapted to any environments.

Refer to the following documentation for details about unattended installation http://go.microsoft.com/fwlink/?LinkID=135694&clcid=0×409, and info about installations scripting http://technet.microsoft.com/en-us/library/dd335964.aspx.

Take into account that SharePoint does not uninstall properly and additional steps are required to clean remaining files and remove database tables, which are kept for the security reasons (http://nehasinha.wordpress.com/2008/02/01/uninstalling-moss-2007-manually). It might be better to reinstall everything from the scratch if something went wrong, including Windows Server – because it will save a lot of time trying to fix potential issues that might be caused by files from the previous installation. In this scenario, using virtualization and snapshots feature saves a lot of time.

Detailed information about SharePoint installation guidelines are published on TechNet http://go.microsoft.com/fwlink/?LinkId=106632

Check Office Web Service availability

Sometimes, SSL protocol of Office SharePoint Web Service is broken.  To test it, go to IIS Management Console and open SharePoint Office Web Service in browser via https://. If it doesn’t work – don’t process further till fix it. This is very critical stuff, because SharePoint roles cannot be assigned on other services in farm. (I’ve seen such issues across several clients, when you can’t use other boxes in farm and only Application boxes are available for Index and Query roles, because SSL was broken).

No known fix at this moment, except reinstalling SharePoint.

Install SharePoint updates

Install all SharePoint updates (Infrastructure Updates and/or Cumulative Patches) after farm is deployed. Check the release notes of the latest cumulative patch if it includes all previous patches and updates. Sometimes you need to install previous updates manually. Cumulative patch releases each 2 months. Follow the official documentation “Deploy software updates for Office SharePoint Server 2007” for the processes of how to deploy infrastructure update (WSS Upgrade needs to be installed first and only then MOSS upgrade).

Be careful with SharePoint hot fixes

There are several hot fixes, for example “Coreserver.msp” package, which are released after Cumulative Patch.  However, be careful with these fixes, because they are temporary solution before the next official update, and they are not properly tested. Install hot fixes for specific problems only.


Configuration


Enable SharePoint Features

Navigate to the Central Administration site and enable Enterprise SharePoint features, if necessary. The default settings is Standard features.

Assign roles to servers

Navigate to the Central Administration site and assign SharePoint roles across all farms servers, according the infrastructure design and topology.

Configure administrative tasks

Configure administrative tasks across servers, like email settings, blocked type, logging and etc. Setup SharePoint Shared Services and configure all related services like Search, Query, Application Services, Profiles and etc.

Disable “Central Administration” role

Navigate to the Central Administration site and disable “Central Administration” role for all servers in farm, except application servers. This action will disable “Central Administration” site and IIS won’t use additional resources to host this application.

Configure Warm-Up scripts

Install site “warm-up” scripts. Those scrips will compile each page of SharePoint site collections when box restarts or after IIS poor restarts. This script improves the response time when users request pages first time.

Those warm-up scrips use STADM command to “warm-up” the administrative interfaces and hit each page in the portal to force their JIT. The collection “warm-up” scripts available there http://blogs.msdn.com/joelo/archive/2006/08/13/697044.aspx

Recycle IIS application pool at different time

Make sure that the application pools are set to recycle at different times on different Web servers, in case of multiple Web servers in the farm.

Recycle different IIS Web sites at different times to avoid peaks on the Web servers. When recycling more than one application pool on a specific Web server at the same time, temporarily remove that Web server from the load balancer to avoid bad user experience.


Following these steps helps to install SharePoint and configure basis settings with the minimum amount of time and avoid most common pitfalls, which usually happens when SharePoint installs in the wrong order

In the next part we will describe the configuration of development environment for the SharePoint stuff.

Twitter Digg Delicious Stumbleupon Technorati Facebook Email
Administration, Technical
, , , , , , ,
  • Hi Michael, Can you tell me the need of installing Office 2007 apps (word, excel, etc.) onto an Application Server in a Sharepoint Farm? Nice article that pretty much sums it all up though...
  • laflour
    Work Excel and PowerPoint are required to create document libraries for this documents.
    For example you can create library that has Word content types, or "Presentations" library, which has support of PowerPoint slides (it parse them and shows separately on the pages)

    for such functionality you need to have Office installed
  • ssgill
    this is ridiculous. You don't need to install applications on SharePoint 2007 servers. So if i was implementing SharePoint 2007 in an environment where they were doing stuff with AutoDesk, so are you saying i have install this on the SharePoint 2007 app server as well. The licensing is USD20,000 per installation.

    i think there are a lot of new folks to SharePoint which are going to get the wrong information because of this.
  • laflour
    Agree, you really don't need to install Office application on Application Server in SharePoint in most cases. But this series of articles are about "Best Practices", which try to cover most common scenarios.

    There are several cases when you don't have the right office version on the client and need to make some changes to you farm as admin. Having offices installed on app server provide you all required features, when you logon on you server's remotely.

    Another thing I kept in mind when wrote about installing Office on application server (not 100% sure, but it helped me last time) is rendering office documents in browser, what requires some additional files from office installation.

    So, in most cases it's "good" to have Office installed on Application Server, but it's not obliged in most cases.

    Regarding AutoDesk: if you want to expose you autodesk functionality to the client via browsers then I believe yes, you need to install in on SharePoint server to have a tight integration (or you suggest to install autodesk on each client app?)
  • ssgill
    thanks for your respond.

    Installing office apps on the sharepoint server is not a best practise scenario. Okay is this blog article about best practise for development, POC or production?

    You do know when you install office app on sharepoint servers, you also bring with it all issues and fixes for office. imagine you have to apply a hotfix for word 2007 and you are doing it on a server. what if the hotfix breaks you sharepoint server? do you think microsoft tests their hotfixes on server installation or clients installation? even worse imagining opening a virus infected file on the server. with the office application on the server, you will be inclined to carry out client-side/user-side activities on the server. That in it self is not a best practise.

    just imagine, you are sitting at domain controllers getting some back up done. you are waiting and to kill time you open the browser on the DC to check your gmail? make sense? certainly not.

    at the end of the day, are you writing about common installation scenarios or best practises. maybe the blog should be re-titled. also would be good if you can make the readers aware of the issues with installing office app on server and also it is not required.

    Thank You
    Sarbjit

    i hope you see my point?

    i think the best way is have a dedicated machine for CA on a sharepoint server. put the office there.

    as for autodesk, yes it is on the clients, where the CAD/CAM folks are doing their work. i don't need to put autodesk on the sharepoint server just in case i need to make some changes to the autodesk documents. autodesk client is meant for the client.

    it is not even good to have office application on servers.
  • Who?What?
    You don't need to install office on the server. Thats crazy talk. Using this logic you would have to install "every application known to man kind" just incase someone uploads a document from that application.
  • Michael,

    You make some valid points, but a lot of your statements are false. Furthermore, it's a good practice to differentiate between WSS 3.0 and MOSS 2007 to avoid any further confusion.

    Adding the Windows Internal Database role on your server is not a best practice or a requirement for that matter. WSS 3.0 stand-alone installations use WID as a data store when a SQL Server instance is not available. In your article you mention the need to install SQL Server 2005 or 2008 (FYI: SharePoint supports SQL Server 2000 as well) so WID won't even be used in this case. As for MOSS 2007, if a stand-alone (aka Basic) installation is selected, SQL Server 2005 Express Edition is installed and *not* WID.

    Installing Microsoft Office 2007 and SharePoint Designer 2007 on Application Servers is **NOT** required or recommended. SharePoint doesn't require these applications installed on the server to open Word, PPT, Excel, etc. documents - that's just nonesense. If you want to open Office documents stored in SharePoint, you'll need these applications installed on your client machine, that's it. Same goes with SPD2007 - if you want to open your site in SPD, you only need to have it installed on your client machine.

    "Take into account that uninstalling of SharePoint is not supported." -- That's not true, or even logical for that matter. There's a difference between unsupported and doing something wrong (even though I don't see how you can go wrong with uninstalling SharePoint).

    "Navigate to the Central Administration site and disable “Web Application” role for all servers in farm, except application servers. This action will disable “Central Administration” site and IIS won’t use additional resources to host this application." --- Oh wow, this is a big No-No. The WSS Web App role is what makes a server a Web Front End. Without this, content won't be rendered. Enabling it on Application Servers defeats the purpose of having a scalable web solution. Disabling the WSS Web App service doesn't disable the "Central Administration" site on your servers either; there's a separate service for that. Furthermore, the Central Administration site is only hosted on one server by default (unless configured otherwise). Your guidance should state that the WSS Web App service be stopped on any server not rendering content to users (i.e. any server that isn't a Web Front End).

    There should also be a section for Service Accounts in your article. This is a crucial part of planning the installation and deployment of any SharePoint Farm.

    I hope this clears up some of the points mentioned in this article.

    Muhanad Omar
  • laflour
    1) Agree with WID. Should be more specific between WSS and MOSS.
    WSS:
    Windows Internal Database is used for Basic installation of WSS 3.0. WID doen't have size limitation
    MOSS:
    Basic installation: SQL Express 2005 with 4Gb limit
    Using SQL 2008 for WSS and MOSS (advanced install) is preferable due to additional feautures of SQL 2008.

    2) Office on MOSS Application server is "good-to-have". (see my previous reply, even not all agree with my points) I don't see real disadvantages of having Office on Application Server, that stop you install it there.

    3) Re-installation of SharePoint is not supported automatically. It's well-known issue, because SharePoint doesn't remove some corpses and doesn't clean database. You need to complete several manual operation, to remove it completely, otherwise it can't be installed correctly in some cases.
    There are some descriptions
    - http://blogs.technet.com/victorbutuza/archive/2...
    - http://www.sharepointblogs.com/spfromscratch/ar...

    4) Thanks for this note, I actually meant "Central Administration" service. Mistyped. Will fix this in article

    Thanks for you comments
  • 2) Office on MOSS Application server is "good-to-have". (See my previous reply, even not all agree with my points) I don't see real disadvantages of having Office on Application Server, that stop you install it there.

    I have to disagree, from memory having office install on Windows Server is not a supported configuration (I may be wrong, but i remember this being the case). Additionally having office install on a server opens up more surface for problems, additional fixes to install + maintenance.

    I would strongly discourage the installation of Office on a SharePoint Server. It belongs on a client.

    Daniel Brown
  • I agree on the need for more information about Service Accounts. Cut Michael some slack. :)
  • Simply inaccurate info
    +1 to Mo. Certainly would not suggest my clients read this and use it as a best practice. Unless I want a job cleaning up after them.
  • SharePointer
    You should not be giving advice on SharePoint in a holistic manner (though I'm sure you are knowledgeable about something related to SharePoint). I'd pick a less broad topic next time.

    Who edit's SharePoint magazine, does anyone read this stuff before publishing?!
  • DISCLAIMER: Views expressed in this section are those of the authors and do not necessarily reflect the editorial position of SharePointMagazaine.net . SharePointMagazaine.net does not knowingly publish false information and may not be held liable for the views of authors exercising their right to free expression.

    :)
  • laflour
    Sorry guys, I realized that this published Part 2 article is the earlier draft, that contain several significant mistypings. The final version doesn't include all that errors you highlighted. But for some reasons it was not submitted :(

    It will be updated soon.
  • laflour
    I'd like to explain in details what exactly happened.

    There are 6 articles I started to write in the end of 2008 and they were queued in March 2009 for publishing. After that articles were reviewed by several guys, changed and published in June 2009. Unfortunately, the “part 2” was not updated since December 2008, and that very early draft version was published accidently :( That version was a bit messy – a lot of copy-pasting issues with the wrong section titles, wrong references, and some stuff were not elaborated properly. And it’s when discussion started :) Let’s say people where really surprised to read that bullshit.

    Unfortunately, I had limited internet access at those days and everything I saw were comments that I got by email. I was a bit confused by people reaction, because I had no idea that wrong articles had been published.
    In a couple of days that “draft-version” mistake was noted and fixed by uploading the right version of article.

    Please ignore all comments, because they doesn't relate to this updated article and are about draft version.
blog comments powered by Disqus