Installing a New Microsoft Office SharePoint Server 2007 Portal: Step-by-Step InstructionsIn this post, I'll demonstrate with words and screen shots how
to install and get working a portal using Microsoft Office SharePoint Server
2007. Installing this product is not difficult, but it does require some
forethought and planning. You can use this post as a reference for getting
your version of MOSS 2007 installed.
You need to have downloaded the software from Microsoft's
site. For information on how to do that,
please go here. Once you have registered and downloaded the software,
you're ready to start.
First, you'll need Windows 2003 Server, fully patched and
ready to go. I believe I've seen blog postings recently that indicate that
you can install MOSS07 on a Vista server. I'll leave that discussion for
other threads and posts.
Once you have the operating system ready to go, you'll want to
start by running the setup.exe for MOSS 2007. Figure 1 illustrates that
after you start the installation process, you'll need to enter a valid product
identification key code. This key code can be found on the download site
and should have been a part of what you did to get the software in the first
place.
Figure 1: Product Identification Key Code Input
Screen
After entering the product identification key code, click
Continue. The next screen is the licensing agreement
screen. Now, I always recommend that you read the licensing agreement
since it is a legal document and you are bound by its' terms. But I also
recognize that in the 10+ years I've been in this industry, I've never seen an
agreement that I didn't agree with.............if you get my drift.
Figure 2: Licensing Agreement Screen.
Be sure to select
the "I accept the terms of this agreement" check box and then click
Continue.
The next screen will give you the chance to select which type
of installation you wish to commit. The Basic installation is used for
those who:
Need to install everything on a single server
Do not need to grow into a multi-server farm
Need a quick, easy deployment during installation with
lead administrative effort
The Advanced option is selected by those who wish to install
MOSS 2007 selecting some of the customizable features. In this
illustration, we'll select the Advanced option and follow that route.
Figure 3: Installation Type Selection Screen
After clicking on the Advanced button, you'll find that the
selections default to StandAlone (Figure 4). However, we'll choose
Complete. The meaning of the three options is as follows:
Complete: Enables all of the options for one server
to offer the entire range of MOSS 2007 services and features to the network.
You can scale out this deployment, start and stop services on this server
and use a SQL server to host your databases.
Web Front End: Enables only those options that
allows the server to run as a web front end server. What this means is
that server is merely the entry and exit point (or one of them among the
other WFE servers) for the farm. The actual servers that users will
consume will be hosted on other servers (presumably). This cannot be
the first choice of a farm unless you plan on installing other servers in
the farm to offer the services and features that users will want to consume.
Stand-Alone: Similar to complete, this option
enables all of the services and features for the MOSS 2007 farm, but assumes
that there is no SQL server, so the MSDE engine is installed locally on this
server. You cannot scale out this server into a larger MOSS 2007 farm.
Note that in reality, all of the MOSS 2007 binaries are
installed in all three choices. All these choices really do is
(pragmatically, not technically) turn on and off the code that is required for
the server to fulfill the functions that have been assigned to it. Note
also that you can select the location where the binaries should be installed in
the File Location tab and then sign up to give feedback directly to Microsoft if
you'd like to do this.
Make your selections, then click
Install Now.
Figure 4: Server Type Selection Screen
During the installation, you'll be presented with a status bar
that is illustrated in Figure 5.
Figure 5: Installation Status Screen
After installation has completed, you'll be given the chance
to run through the SharePoint Products and Technologies Configuration Wizard
(Figure 6). You'll use this wizard to commit the initial configuration
options for your new SharePoint farm.
Figure 6: Entry screen to the SPPT
Configuration Wizard. Note that you can come back to this screen using the
Administration menus that automatically install with the SharePoint Server
binaries
One you start the SPPT wizard, you'll receive a pop-up box
(Figure 7) that will inform you that certain services are going to be stopped.
Be sure it is a good time to stop these services before moving on with the
configuration options for your farm.
Figure 7: Informational Pop-Up Box
The following set of
screens in the SPPT Configuration Wizard are design to help you setup the farm.
In Figure 8, you'll be able to create a new farm or join and existing farm.
Farm membership, at the server level, is determined by which servers are using
the same configuration database in SQL and which servers are not. In my
illustration, I want to create a new farm, so I select the "No, I want to create
a new server farm" radio button. If I had wanted to connect to an existing
farm, I would have selected the other radio button.
Figure 8: Connect to a server farm
configuration screen in the SPPT Wizard
After making our selection in Figure 8 and then clicking
Next, I'm taken to the next screen illustrated in Figure 9.
On this screen, I can enter the following configuration values:
The SQL database server name. I'm not clear if this
is the host name or netbios name, but I suspect this is the host name.
However, you don't need the FQDN here, but you do need name resolution to
this server or SQL Instance.
The farm configuration database name is needed in the next
input box. Note that the screen just asks for a name, but you need to
understand you're entering the most persistent database name for the entire
farm - the farm configuration database name. Be sure this name
supports your database naming convention. You should decide the name
of this database in advance of getting to this screen
The database access account will need to be a member of
the local admins group on each SharePoint server along with having
db_creator and db_security permissions in SQL. I would suggest you
have an account setup just for this purpose in your Active Directory and
that you have a strong password associated with this account.
Figure 9: Configuration Database Settings Screen
in the SPPT Wizard
in Figure 10, you'll
be asked to decide which type of security settings you want to use for your
farm. First, you can specify a pre-selected port number for central
administration to run on or you can allow the wizard to randomly assign a port
number. As you can see, this instance of the wizard randomly selected
17386 as the port number for Central Administration (CA). If you want CA
to run on a different port, then select the check box and enter the desired port
number.
The issue of NTLM vs. Kerberos is one that you may at some
point wish to consider. Do you want the CA application to run using NTLM
(NT Lan Manager) for security authentication or Kerberos? If the latter,
there are some special configurations you'll need to complete for your Active
Directory (AD) before Kerberos will work. I'm finding that most
administrators are happy with NTLM, though those in a larger and more secure
implementations are increasingly using Kerberos. For purposes of my
illustration here, I'm selecting NTLM.
Figure 10: Configure SharePoint Web Application
configuration screen in SPPT Wizard
After you click
Next, you'll be given a
status bar that indicates how the SharePoint configuration is going.
Depending on the type of server you're installing and the options you're
installing, you could have as few as seven tasks or as many as eleven.
Figure 11 illustrates the progress screen. Note that the caption below the
status bar will inform you about the configuration actions that are being
executed during this process.
Figure 11: Configuration status bar screen in the
SPPT Wizard
After the
configurations have been executed and committed to the SQL Server database, we
finally get to CA where we can further configure our farm. We can start
and stop services (Figure 12) on this server and then create web applications.
In order to have portal, you'll first need to start the Office SharePoint Server
Search service and then create a Shared Services Provider (SSP). I'll
start the search service.
Figure 12: Services configuration screen in CA
When the search
service is started, you're presented with another web page for search
configuration administration that needs to be completed before the search
service can start. The configuration options are pretty clear. Out
of the shoot, you'll use this server for both indexing and servicing queries
from users until you can get enough servers in your farm to quarantine those
options in your farm. Select a location that has enough disk space for
your indexes. You should plan on a space allotment of 20% relative to the
amount of information you wish to index. You'll also need to input an
email address, a service account and whether or not there is a dedicated WFE for
all crawling activities. For now, in my illustration, since this is the
first server in the farm, I'll accept the defaults and click
OK.
Figure 13: Search configuration screen
After starting the
search service, the next thing I need to do is create a SSP. In order to
do this, I'll navigate to the Application tab in CA, click
Create or Extend a Web Application,
then click Create a New Web
Application, then make the configurations necessary that you see
in Figure 14. Most of this is pretty self-explanatory, so I won't go through
each input in detail. Suffice to say that I've done two things not
illustrated here. First, after creating this web application, I then web
back into CA, selected the Create or Configure Core Farm Services,
then selected New SSP (Figure 15) and then filled in the
configuration information for the new SSP. All of the options on that page
are self-explanatory, except that you must select an Index server for the SSP to
operate.
Backtracking just a bit, you can't have an Index server unless
the Search services is started. So, that's why I illustrated starting the
search services first, then creating an SSP, then creating a portal.
Figure 14: Configuring the new web application to
host the portal
Figure 15: Illustration of the SSP management
interface where you can select to create a New SSP.
Once the SSP is created and the web application for the
portal has been created, you can then create the portal. The way to do
this is to navigate to CA and then click Create Site Collection. Be sure
the http://portal
is selected in the drop down list in the upper right-hand portion of the screen
(Figure 16). Note that on this screen, you'll need to ensure that
you are creating the site collection at the root by selecting the "Create Site
at this URL" where the URL path is "root", not in the Sites managed path.
Also, if you scroll down, you'll need to select the Corporate Intranet Site
under the Publishing tab. Microsoft has renamed the Portal to Corporate
Intranet Site and placed it under the Publishing tab for web content publishing
purposes. BTW, even though I don't illustrate it here, be sure to give the
site a title.
Figure 16: Create Site Collection Screen
At this point, you should now have a new portal, ready to aggregate, organize
and present content for your enterprise, division or department.
Bill English
Mindsharp
