In part 1 I went over some of the basics of why an automated installation is a good idea for not only Development and testing labs, but for QA/Staging environments and even Production.
Part 1 detailed the initial steps in creating a farm, including the scripted installation of the product (copying the binaries) and initial configuration (setting up the farm). In this section, I'm going to talk about the different steps required to finish the installation, or the user configuration. These are the parts of the farm setup that are not done by the wizard if you install SharePoint manually, but are required to "complete" your installation.
One of the things that always seems to annoy developers is that nagging message on the Central Admin page that says in Red "Your Farm is not configured properly!" (I think it is actually stated nicer, but I haven't seen it for a while). These are the steps that are required to make that go away, and "complete" the installation of MOSS.
Indexing/Search - You must configure the Index Server options so you have both the crawl and query functions active in the farm.
Shared Service Provider(s) - you must install and configure at least 1 Shared Service Provider. This is the service mechanism used by MOSS to provide User Profiles, Indexing, and other Shared Services, such as BDC, Excel Calculation Services, Forms Server, and Web Rendering.
Outbound SMTP Server - you must configure the Outbound mail SMTP address for the farm so it knows how to communicate with users and admins.
Excel Calculation Services - You have to enable the ECS role on at least one server in the farm. This allows Excel sheets to be web-rendered.
1st: Required steps to configure Index Server
The Index server is made up of two services, the WSS Search Service, which searches help content, and the MS Office SharePoint Server Search service, which searches user content and other sources. These can be configured with simple STSADM commands.
First, configure the Windows SharePoint Services Indexing Service. This needs to be done on the server that will hold this role. This is done with the STSADM SPSearch command:
stsadm -o spsearch -action start -farmserviceaccount domain\searchaccount -farmservicepassword Password
The parameters mean the following:
-action start: gives the directive to start the indexing on this server.
-farmserviceaccount and -farmservicepassword: The identity and password for searching. This does not have to be your Farm Admin account.
Second, configure the Office SharePoint Server Indexing Service using the STSADM OSearch command, again, on the server that will hold this role, like this:
stsadm -o osearch -action start -role indexquery -farmcontactemail admin@SharePoint.pri -farmserviceaccount domain\searchaccount -farmservicepassword Password -defaultindexlocation d:\index
And the parameter descriptions:
-action start: again, the action tells the service that this farm member will be starting this role.
-role x: The role is what part of the search functions will be running on this machine. you can specify index, query, or indexquery for both roles. For those unfamiliar with this terminology, indexing is the crawling portion of the search role, that will search web pages and create indexes to be searched. Querying is the user-request side of the index service, the side that handles all search requests from a user and provides a list of results. My example shows both roles being assigned, however you can separate these by using this command on multiple servers in the farm with the role specified. An example might be to make all your load balanced Web Front End (WFE) servers Query servers, to handle user requests.
-farmcontactemail: the email address of the admin for the farm.
-farmserviceaccount and -farmservicepassword: the identity information for the indexing service.
-defaultindexlocation: the location for all the locally stored index files, used to add index results by the index role, or to parse results by the query role.
And that's all there is to it. you now have a functional indexing service installed. One thing to note is that this does not configure the actual crawling of content, just the infrastructure to support crawling. you must still specify any custom content sources and crawl schedules in the SSP admin console.
2nd: Required Steps to Install the Shared Service Provider.
Here is what is required to install an SSP:
1) A Web App for the SSP
2) A Web App for MySites (can be a bogus/mock one if you do not plan to deploy MySites)
3) Configure the SSP
Frist, to script the creation of the Web Apps, we turn to the STSADM command ExtendVS, and it ends up looking something like this:
stsadm -o extendvs -url http://SharePointServer:9100 -ownerlogin domain\SPFarmAdmin -owneremail mossadmin@domain.com -exclusivelyusentlm -donotcreatesite -description "SSP - 9100" -databasename SSP_Content -apidname "SSP - 9100" -apidtype configurableid -apidlogin domain\WebAppAccount -apidpwd Password
So here's what it means... ExtendVS is the STSADM command for creating WebApps. It is used for both extending existing ones in IIS, as well as creating new ones. The primary difference is whether it already exists in the metabase as a Web App, or if it is an unknown name. Here are the parameters described:
-url: this is the url and port for the Web App. If no port is specified it does default to 80. By default this will not create a host header, just the URL of the Web App.
-ownerlogin: this is the owner of the Web App... I've heard various theories on who this should be, but I prefer this to always be the Farm Admin Account that you use to create the farm.
-owneremail: same as above, really. Just contact info.
-exclusivelyusentlm: this is for the security level on the Web App. If you will be setting up Kerberos, then you do not want this option, however if that is a long way off, or possibly never, use this flag.
-donocreatesite: by default the ExtendVS comand creates a Site Collection at the root ("/"). For MySites and SSPs, this will break the WebApp so it cannot be used correctly, so you need this flag. This is also handy if you are scripting for DR or restoration purposes, in which case you already have a root site you will want to restore later, so do not want another one to conflict.
-description: the description of the Web Application
-database: the name of the content DB to be created (this cannot be an existing DB. Add existing DB's using the addcontentdb function detailed in the upcoming part 3 installment of this series).
-apidname: this is the name of the App Pool for the Web App.
-apidtype: this is either configurableid or networkservice, depending on what credentials you want the app pool to run under. In most cases this will be configurableid.
-apidlogin and apidpwd: the app pool login and password.
-sethostheader: this one isn't in the example above, but is handy for setting the host header values for the web app based on the url parameter.
So after creating a Web App for the SSP, you'll need to repeat the process for a Web App for your MySites. Both these Web Apps need to be created prior to establishing your SSP. Typically in a "more-secure" model you would use separate identities for the Farm Admin, the SSP Web App and the MySite Web App.
To create the SSP itself, once both the SSP and MySite Web Apps are created, you will use the CreateSSP STSADM operation. Here is an example of the function:
stsadm -o createssp -title "Shared Service Provider" -url http://SharePointServer:9900 -mysiteurl http://mysite.SharePoint.pri:80 -indexserver SomeServer -indexlocation "d:\index" -ssplogin domain\SSPAccount -ssppassword Password -sspdatabasename Shared_Services -searchdatabasename SSP_Search_DB
So here are the parameter descriptions:
-title: the title of the SSP... Make this meaningful, as you may find in larger farms that multiple SSPs are needed for a variety of reasons.
-url: the url of the SSP, including the port. This is usually fine for oddball ports, as almost all functions of the SSP are server requests, not user requests, so users never see the url.
-mysiteurl: the url of your MySite Web App. This is needed for the profile and user linkage, as well as the personalization functions of the MySite Web App.
-indexserver: the server that will hold the crawl role for the SSP. This does not enable the crawl role, but sets the parameters. You must have the index/crawl role already configured as is noted above.
-indexlocation: the physical file location of the index files on the crawl server.
-ssplogin and -ssppassword: the user and password for the ssp identity.
-sspdatabasename: the name used for the SSP database. This is not the content DB of the Admin page for the SSP, that was specified in the Web App Extend command. This is the location of SSP configuration and data (like profile details).
-searchdatabasename: the name used for the index DB.
Once this phase is complete, you have a functional SSP. The only remaining steps to perform in the SSP that are not yet scriptable are the Profile Import to pull user profiles from a directory source (and schedule updates), and Search details. Search details include the content sources and crawl schedules. You'll actually find that those two functions are just about the only manual processes that need to be done in a fully scripted installation.
3rd: The Required Steps to Configure Outbound Email.
Outbound SMTP Email is one of the configuration settings that will give you the red "Your Farm is Broken!" warning, because outbound email is a fairly integrated part of MOSS. It is used in admin notifications, user notifications for task assignment, workflows, as well as user alert subscriptions.
Outbound email is configured via STSADM using the Email command.
stsadm.exe -o email -outsmtpserver mail.domain.pri -fromaddress SharePoint@domain.pri -replytoaddress noreply@domain.pri -codepage 65001
The parameters are described below:
-outstpserver: This is the address or Fully Qualified Domain Name (FQDN) of your organization's SMTP Relay server.
-fromaddress: This is the address that will be listed as the originator of all emails coming from SharePoint. You can actually set a Web App version of this, but this is the default.
-replytoaddress: This is the reply to address, which is usually a bogus address like no-reply, or leavemealone.
-codepage: This is the Character Set for email encoding. Most will be using UTF-8, which is 65001.
There are inbound email functions that can be set, but these are not currently scriptable, and also requires local SMTP server configuration on the server that will receive email. Inbound email is a choice that many are split on. There is some good functionality with it, but also some bugs and gotchas...
4th: The Required Steps to Configure Excel Calculation Services.
Excel Calculation Services (ECS) need to be started on at least one server in the farm to provide calculation and web rendering for Excel Workbooks. To enable ECS, use the STSADM ProvisionService command on the server that this role will be activated on:
stsadm.exe -o provisionservice -action start -servicetype "Microsoft.Office.Excel.Server.ExcelServerSharedWebService"
This one is very basic and straight forward, and only has two parameters, the action and the servicetype. The servicetype is the namespace of the service to start.
These steps will bring your MOSS farm out of the "Red" zone, and ready for use. There are still many other great scriptable functions that can add to your farm configuration automatically. In the next installment, I'll go over things like Alternate Access Mappings, Managed Paths, Attaching Content DBs, Deploying Features, and all sort of good stuff like that! Until next time...!
0 comments:
Post a Comment