Wrox Press: Configuring and Managing Office SharePoint Server 2007

Applies To: Office SharePoint Server 2007

This Office product will reach end of support on October 10, 2017. To stay supported, you will need to upgrade. For more information, see , Resources to help you upgrade your Office 2007 servers and clients.

 

Topic Last Modified: 2016-11-14

This book excerpt is from Beginning SharePoint 2007 Administration, Wrox Press, June 2007.

Buy this book

Beginning SharePoint 2007 Administration (https://go.microsoft.com/fwlink/?LinkId=136776) mainly focuses on administration of Microsoft Office SharePoint Server 2007. You will also learn how to customize Office SharePoint Server 2007 by creating templates and by using SharePoint Designer to enhance the look and feel of SharePoint sites. Microsoft MVP and author Göran Husman explores the differences between Office SharePoint Server 2007 and Windows SharePoint Services, helps you decide if you need only Windows SharePoint Services or if you should also implement Office SharePoint Server 2007, and much more.

Author

Göran Husman is a true computer nerd who started his career as a computer programmer in 1978. After working as a C and Fortran developer for a medical university and later a large telecom company, he started his own consulting company in 1989. Due to market demands he soon switched his focus from UNIX to the Microsoft environment and from developing code to implementing large e-mail systems and building information systems. Göran has also been hired as a computer trainer since the beginning of 1980. In 1993 he became one of the first certified Microsoft Certified Trainers (MCT) in Sweden, and he has regularly conducted Microsoft courses ever since. He is also certified by Microsoft as a Microsoft Certified Professional (with the number 2888) and a Microsoft Certified Systems Engineer (MSCE). His great engagement in e-mail systems awarded him status as Sweden’s first Microsoft Exchange Most Valuable Professional (MVP) by Microsoft. He switched his focus to Microsoft SharePoint in 2003, and in January 2006 Microsoft awarded him status as Sweden’s first SharePoint Portal Server MVP, which was renewed in January 2007. Göran has written a large amount of training material for the Swedish market over the years, and in 2001 his book, Exchange 2000 Server on Site, was released in the United States. In 2006 his book Beginning SharePoint Administration was released by Wrox. He is also frequently a speaker at conferences and seminars. Today Göran divides his time between consulting contracts, training, leading his company, Human Data, and from time to time writing books. Oh, and he is also the proud father of six great kids from the ages of 6 to 28, which may be his greatest achievement in life.

Book excerpt -- Chapter 5: Configuring and Managing MOSS 2007

In this chapter, you learn how to configure and manage the MS Office SharePoint Server 2007. You learn about configuring shared services, global searching, how to import user properties from the Active Directory, and how to target information for different groups of users. Even if you do not plan to implement MOSS at this time, this chapter may still interest you because it describes the features that are specific to MOSS, as opposed to the pure WSS environment. This will help you understand the differences, and when using WSS with MOSS is a better choice than using WSS alone.

Basic Configuration

In Chapter 4, you learned how to install MOSS 2007, and to create a site collection containing a collaboration portal site. You may recall that SharePoint’s Central Administration tool, right after the installation of MOSS, displayed a list of four administrative tasks that you had to complete in order to set up the basic configuration:

• READ FIRST: Click this link for deployment instructions: A link to the Quick Guide for administrators.

• Initial deployment: Add servers to farm: This task will take you to the Operators page and its link: Servers in farm. This page displayed all servers in this farm, both SharePoint front-end servers, and SQL Server 2000/2005 back-end servers.

• Initial deployment: Assign services to servers: This task will take you to the Operators page and its link: Services on server; here you configure what services will run on what SharePoint server. This is also the page where you start and stop these services.

• Configure server farm’s shared services: This task will open the Shared Services Administration page, where you can create the first shared service provider (SSP), including search, user profile import, audiences, and Excel services.

After completing all four of these tasks, MOSS is ready to be used for creating user web sites. However, there are a lot of new configuration tasks that you may or may not need to complete, in order to activate optional features in MOSS. And this is what you will learn in this chapter. Some of these optional configurations most frequently used in MOSS installations are these:

• Outgoing e-mail settings: Before MOSS can send e-mail to recipients, you must configure how this SMTP-based communication will take place. For example, MOSS will send e-mail to users that request alert messages when something changes, such as when a new document is added to a document library.

• Incoming e-mail settings: This will make MOSS work as a receiving SMTP server, accepting mail to configured document libraries, in effect working as mailboxes.

• Global search: This configures what MOSS will index and what users can search for.

• Active Directory Import: This configures MOSS to regularly import user properties from the Active Directory into a User Profile database.

• Audience Targeting: Define groups of users that will be able to view specific content, such as Web Parts, news items, and documents.

• Excel Trusted Locations: MOSS Enterprise Edition comes with a specific Excel Service that can work as a repository for Excel spreadsheets and graphs, which users can view and work with, using only a web browser. To make this work, the administrator must point out where these Excel files can be stored.

There are actually a lot more settings and configurations available for a MOSS server, which you will see in the next section.

Advanced Administration

The previous list contains just a few of the settings that an administrator has to know about, in order to get the most out of a MOSS environment. In fact, there are more settings available than this book can cover, but you will learn all the important ones here. Remember that MOSS is a very advanced product that also easily can be expanded by adding new features or connecting to other systems. Even so, MOSS is easy to manage and configure, as long as you take it step by step and know what you are doing.

Two Important Tasks to Start With

After all the four tasks in the basic configuration part are completed, you will see a new list of administrator tasks show up on the Central Administrations Home page (if not, press F5 to refresh your web browser). You may remember that directly after the installation of MOSS, text in red said “Server Farm Configuration Not Complete!” Now this text is gone, but still there are most likely some other settings to configure before opening MOSS to all users. Note that in most installation scenarios you do not have to perform all the administrative tasks in this list, nor do you need to follow it in order. In fact, you usually do not follow this order. To help you configure SharePoint 2007 in a proper way, this chapter will present typical tasks to perform and in a more logical order. The complete list of the new administrator tasks is shown in the following table.

No	Task	Description
1.	Incoming e-mail settings	Enable SharePoint to accept incoming SMTP messages, and store them in mail-enabled document libraries.
2.	Outgoing e-mail settings	Enable SharePoint to send SMTP messages to users and administrators.
3.	Configure Workflow Settings	Define how Workflow processes will operate.
4.	Configure Session Throttles for InfoPath Form Services	Define settings for InfoPath, such as timeouts, if browser-enabled or not, and the like.
5.	Add/Change Excel Services Trusted Locations	Define what document library and other locations that are trusted for the Excel files used by Excel Services.
6.	Service level settings for SharedServices1	Open the general configuration page for this SSP instance.
7.	Check services enabled in this farm	List any warnings or errors regarding important services. Will also show if this is a trial installation.
8.	Diagnostic logging settings	Configure several logging settings, including error reports and trace loggings.
9.	Enable SSO in the farm	Single Sign-On is used to access non-Microsoft applications.
10.	Add anti-virus protection	When you have purchased an antivirus solution for SharePoint, use this link to configure it.

Although the previous list of tasks is long, you can start with just a two of them to get MOSS in shape to create portal sites with the fundamental features. Some of the tasks you should start with are not even listed on the Administrator Tasks list. You are supposed to know them anyhow. Do not despair! This section will show you how to configure these initial tasks, and many MOSS installations will be satisfied with just these tasks for a long time.

The First Important Task: Outgoing SMTP e-mail

This task is necessary if you want SharePoint to be able to send e-mail. A typical example of this is when a site owner adds a new member to his site, this member will get an e-mail from SharePoint, saying that the person has access, with a link to this site. Another example is when SharePoint discovers some problems and wants to send an error message by e-mail to the administrator. A third example is when a user has created an alert for a document library that sends an e-mail every time a new document is added or an existing document is modified or deleted.

This feature is available for both pure WSS installations and MOSS installations. It is not dependent on the SMTP service in Windows 2003 Server (or IIS to be more specific); SharePoint 2007 has the code to send SMTP messages built into its core features. Note that you do not need MS Exchange Server to make this feature work. Any SMTP mail server that accept e-mail from the SharePoint server will do fine (but some other cool features such as Inbox Web Parts will not work unless you have MS Exchange). To configure this feature, follow the steps in the Try It Out below.

Try It Out

Enable Outgoing SMTP e-mail

1. Log on as the administrator, and start the SharePoint 3.0 Central Administration tool. Switch to the Operations page (or use the Action link in this Administrator tasks item property).

2. Click Outgoing e-mail settings, in the Topology and Services section.

3. In the following web form, enter these values:

   1. Outbound SMTP server: Enter the full name to the mail server, for example dc1.filobit.com.

   2. From address: Enter any mail address you want listed as the sender of the e-mail; note that this address does not need to exist! You can enter any mail address you like here, but choose one that reminds the recipient that the mail comes from SharePoint; for example, SharePoint@filobit.com.

   3. Reply-to address: This must be an existing e-mail address. If a recipient of SharePoint’s e-mail sends a reply, it will be delivered to this address.

   4. Character set: Define the character set to be used by SharePoint’s SMTP service. Unless you have a very good reason, keep the default setting, that is, 65001 (Unicode UTF-8). However, if you cannot read the e-mail sent from SharePoint, you may need to change this setting. Talk with your mail administrator in this case and ask what character set he or she recommends.

   5. Click OK to save and close this page.

The Second Important Task: Defining the Index Schedule

This task is not listed above in the Administrative tasks, although it is necessary to complete if you want to activate the search feature in MOSS. You may recall that searching and indexing are features managed by the Shared Service Provider (SSP), by default named SharedServices1, that you created during the basic configuration steps. So in order to configure search and indexing, you must open the configuration page for SharedServices1.

The task you must complete is to define a schedule for the indexing service; by default, MOSS is configured to index its own databases, but there is no schedule set. In other words, you cannot search in MOSS at this moment. This task is simple, just follow the steps in the Try It Out below to set up how often the index service will run.

Try It Out

Define the Indexing Schedule

1. Log on as the administrator; start the SharePoint 3.0 Central Administration tool.

2. Click on the link SharedServices1 on the Quick Launch bar, to open the configuration page for this SSP.

3. Click Search settings under the section Search.

4. Click Content sources and crawl schedules.

5. If the column values for Next Full Crawl and Next Incremental Crawl both are set to None for “Local Office SharePoint Server sites,” then you need to set this schedule now:

   1. Open the quick menu for the “Local Office SharePoint Server sites,” and select Edit.

   2. In the Crawl Schedules section, click Create Schedule under Full Crawl and define the schedule (see Figure 5-1).

      Tip

      It is often enough to do a full crawl once every week or maybe even every month.

   3. Click Create Schedule under Incremental Crawl and define a schedule. This should normally take place rather often. For Basic mode installations of MOSS, this value is set to once every 20 minutes. Set a value that suits your organization, but remember that this is a very resource-intensive activity, so make sure you have enough hardware to avoid that users experience SharePoint as slow due to this reason.

   4. To make sure your index is up to date, check the option Start full crawl of this content sources, then click OK.

      Figure 5.1

      

At this stage, your MOSS server is ready to allow you to create any type of user site, such as portal sites, and team sites. The content in all of them will regularly be indexed, so users can search for information. Users can also create e-mail based alerts to monitor documents, libraries, and lists for updates.

Other Common Tasks in SharePoint’s Central Administration Tool

When you want to add more functionality to your MOSS environment, you must complete some configuration. Typical functionality that you want is to be able to search for users, and to allow users to use My Sites for both personal use and to publish information about themselves to other users in the organization. Another often requested feature is that SharePoint should be able to store e-mail related to a project or similar activities. As discussed earlier, these common tasks do not appear in the Administrators Task list in the Central Administration tool; instead they are organized based on how they are commonly implemented in a typical MOSS environment. Below are more detailed steps on how to add these features to MOSS.

Configuring User Profiles

Each user account in Active Directory can be granted access to a SharePoint web site. Each of these users also may have a number of properties registered in Active Directory, such as an e-mail address, department name, a company name, and a phone number. A very common request in intranet sites is a list of employees, so a user can search for a specific employee. Instead of creating a simple list of employees in SharePoint, you can activate a User Profile database, which stores the name of each user, including their properties; some are retrieved from Active Directory, and some are manually updated by the user or the administrator.

The User Profile database is managed by the SSP, that is, SharedServices1. By default, it will not contain any user names, besides the administrative account, so the first question is if you want to add each user account and corresponding properties manually or if you want to import this information from an external source, such as the Active Directory. In most cases, the latter is preferred, since the Active Directory is already used for storing properties about users, and you probably want to store just one master directory of user properties. MOSS can import that information from Active Directory on a regular basis, typically once every day. A new feature in SharePoint 2007 compared to previous versions is that MOSS can import user properties from any Lightweight Directory Access Protocol (LDAP) source, not only from Active Directory.

Since the user profile is managed by the SSP, its content is also stored in one of the SSP databases: SharedServices1_DB. Exactly what properties are stored for each user is defined in the User Profile settings; some of these properties are imported, some are manually updated. An administrator can add, modify, or delete these user properties at any time, including configuring which of them will be mapped to an Active Directory property, that is, imported from AD.

You will find more information, including the exact configuration steps for activating the User Profile database in Chapter 8, but the following Try It Out provides a quick guide on how to force a manual import of all users from an Active Directory domain named Filobit.

Try It Out

Configure the User Profile Import

1. Log on as the administrator, and start the SharePoint 3.0 Central Administration tool.

2. Click on the SSP link SharedServices1 (assuming that you have accepted the default name).

3. On the next configuration page, click User profiles and properties in the User Profiles and My Sites section.

4. Verify that the Import source is Current domain (FILOBIT), then click the Start full import link. Wait for some time until Profile import status = Idle (a large number of users takes several minutes, or even hours, to import); click Refresh or wait for the automatic refresh to take place.

5. When all users are imported, you will find the number of user profiles imported listed at the top of the page. Click the link View user profile to see a list of these imported users. Use the quick menu for any of these users, and select Edit to view the user’s properties.

The information in the user profile is searchable, but first MOSS must index it; to speed up this process you can force a manual update, as shown in the following Try It Out.

Try It Out

Force a Full Crawl

1. Open the SharePoint 3.0 Central Administration tool and SharedServices1.

2. Click Search settings in the Search section.

3. Click Content sources and crawl schedules.

4. Use the quick menu for Local Office SharePoint Server sites, and select Start Full Crawl.

5. Wait for this crawl to complete; click Refresh or wait for the automatic refresh of this page.

When the crawl process has completed, all the new information in the user profile is updated. Now you can start searching for some of these user properties, for example the Department property. Open the portal web site, and click Search, click the tab People, and then Search Options. A form is now displayed where you can enter what you are searching for (see Figure 5-2). Enter a value in the Department field you know exists in the user profile, and click on the Search icon. You should now see a list of users matching this search criterion.

Figure 5-2

Configuring My Sites

This feature is related to the User Profile database, since it will expose many, or possibly all, of a user’s properties stored in this database to other users by means of a shared My Site. But My Site is also a private web site for the user, or site collection really. The user can, and should, use this web site instead of a home directory on a file server, or even storing files locally, since it is easier for the user to retrieve this information from any computer that can access the SharePoint server, including over the Internet. The details about My Sites are described in Chapter 6, but here is a short summary since you probably want to get a basic understanding of this feature right now.

All users with at least Read access to SharePoint will be able to create their personal web site simply by clicking on the link My Site at the top right of SharePoint’s user web site. When they do so, SharePoint will create the personal site through the service account used by the application pool of the web application where the portal site is created. The user does not need any special permission to create My Site. However, in some situations, such as when installing MOSS using the Basic installation mode, this service account may not get the proper permission. If this happens, the user sees the error message in Figure 5-3.

Figure 5-3

This error message is actually misleading; the problems has nothing to do with the “self-service site creation” feature; it is simply due to the fact that the service account for the application pool is not allowed to create a site collection for this user. To correct this, follow the steps in the Try It Out below.

Try It Out

Set Permissions for Creating My Site

1. Log on as an administrator for the MOSS server.

2. Start the Internet Information Service (IIS) Manager.

3. Open the properties for the virtual IIS web server, used by the MOSS user web site (e.g., SharePoint – 80). Switch to the Home Directory tab and check what application pool it uses, then click Cancel to close this property window.

4. Right-click the application pool identified in step 3, and select Properties. Switch to the Identity page; memorize what user account is used here. Click Cancel to close the property page.

5. Open the general settings for the server object. For example, click Start, right-click on My Computer, and select Manage, then expand the System Tools —>Local Users and Groups —>Groups. Double-click on the group Administrators, click Add, and add the account identified in step 4, then click OK.

6. Reset the IIS: Open Start —>Run and type IISRESET, then press the ENTER key.

7. Log out and log in as a normal user. Open the web site, for example, http://srv1, then click My Site to create this personal web site.

After My Site is created, take a look at the user properties it displays. Click Details in the My Profile section in the Quick Launch bar. Note that some properties are already set; these come from the User Profile database. Also note that you can set some properties yourself, such as About Me, Responsibilities, and others. Whatever you enter here will be stored in the User Profile database when you click Save and Close. Now, click the My Profile tab, and you will see most, but not all, of your properties displayed. This My Profile page is available to all users, by default, although some of its information may be visible only to certain groups, such as My Colleagues. To see how this is controlled, click on Details again, and note the column to the far right of each property line. For example, the property Mobile phone is only visible to the group My Colleagues, while the Fax property is visible to Everyone.

So, how do you define who your colleagues are? Simple, just click on the link Colleague in the Quick Launch bar, and then click Add Colleagues. Next, enter the names of your colleagues in the Type Names field, select who will see these names by using the menu Show these colleagues to, and finally select the group the new colleague will be listed under; the default is General, but you can also choose Peers or create a new group name (see Figure 5-4). Now open the My Home page, and click Show Colleagues to see them all. This list of colleagues is also displayed on the My Profile page.

Figure 5-4

Enabling Incoming e-mail

This is a new feature in SharePoint 2007 and works for both pure WSS installations and those with MOSS. It is listed as Task 1 in the Administrators Task list. It solves a longstanding problem: How can you collect e-mail related to a specific activity, together with the rest of the information stored in a SharePoint web site? The typical scenario is when you work on a project and use e-mail to communicate with the other project members, and possibly also with external people, such as consultants. By mail-enabling a document library in the project web site, you can forward important e-mail to that document library, or you can add the mail address for this library to the mail group for that project.

In order to make it possible for SharePoint to receive e-mail, you must install the SMTP service in this Windows 2003 server. SharePoint will then use this SMTP service to accept incoming e-mails and store them in mail-enabled document libraries that in effect work as mailboxes. The important thing to remember is that SharePoint works as an independent SMTP server and that any mail server can send e-mail to it. When you accept that, it is not hard to understand that SharePoint needs its own mail domain, which will be different from the “normal” mail server in your organization. For example, if the mail domain used by your normal mail server is @filobit.com, then SharePoint will add its server name to that domain: @srv1.filobit.com (assuming that the server name is srv1).

As long as your SharePoint server will accept e-mail from internal users only, you will not need to configure a mail exchanger (MX) record in your DNS server, since the name of the domain is also the fully qualified domain name (FQDN) for this server; that is, your normal mail servers will be able to find SharePoint whenever there is an e-mail sent to one of its document libraries. However, if you want SharePoint to be able to accept e-mail from external users as well, you have two choices:

• Create an MX Record for SharePoint: This will make SharePoint’s mail domain @srv.filobit.com public, and anyone can now locate this mail server. But this does not mean that SharePoint will accept e-mail from anyone on the Internet; it would be devastating if any of SharePoint’s mail addresses became known to a spammer.

• Create an e-mail address in the normal mail system: For example, if your mail server is MS Exchange, then you would create a mail-enabled contact with one primary e-mail address that matches exactly the e-mail address for a given document library. The same contact will then get a second mail address using the default mail domain (e.g., @filobit.com), and an external user can then send an e-mail to that address; MS Exchange will receive it, and then immediately forward it to SharePoint and its document library.

Enabling Incoming e-mail with Manually Created e-mail Addresses

The first step is to enable the SMP service for the Windows 2003 server, then configure SharePoint to enable incoming e-mail, and finally mail-enable the document library that will accept e-mail. Follow the steps in the Try It Out below to set up incoming e-mail.

Try It Out

Enable Incoming e-mail

1. Log on as an administrator for the MOSS server.

2. Make sure that the SMTP service is installed on the Windows 2003 server:

   1. Click Start —>Control Panel —>Add or Remove Programs.

   2. Click AddRemove Windows Components in the left bar.

   3. Select Application Server, and click Details.

   4. Select Internet Information Services (IIS), and click Details.

   5. Near the end of this list, check SMTP Service and click OK twice, then click Next. If requested, mount a CD with the Windows 2003 Server setup files.

   6. Close the Add or Remove Program applet.

3. Configure SharePoint to enable incoming e-mail:

   1. Start the SharePoint 3.0 Central Administration tool.

   2. Switch to the Operations page.

   3. Click Incoming e-mail settings.

   4. In the Enable Incoming e-mail section, select Yes. Accept the other default settings; memorize the mail domain listed in the Incoming e-mail Server Display Address section.

   5. Click OK to save and close the web form.

4. Mail-enable a document library:

   1. Open the web site containing the document library you want to mail-enable.

   2. Click on the document library you want to mail-enable, for example Shared Documents.

   3. Click Settings —>Document Library Settings.

   4. Click Incoming e-mail settings, and fill in the form (see Figure 5-5).

   5. Select Yes in the Incoming e-mail section.

   6. Enter the mail address for the library.

      Tip

      Use a naming standard that makes it easy to understand what web site and document library this address points to. For example, if your site is named Project X, you could enter this address: ProjectX-DocLib1@srv1.filobit.com.

   7. In the e-mail Attachments section, select how mail attachments should be saved: save all in the root folder; create a subfolder per subject and store the attachments there; or create a subfolder per sender, and save the attachments there. You can also define if you want to overwrite existing files with the same name or not; if not, a number will be added to each file name.

      Tip

      If you select the option to save e-mail to folders named after the subject, then all e-mail must contain a subject. If not, SharePoint will use the message ID number as the subject name!

   8. In the section e-mail Message, choose if you want to save the actual mail message or not. If you do not choose to save the message (as an .eml file), only the attachments will be saved, according to your settings in step g above.

   9. In the e-mail Meeting Invitations section, choose if you want to save incoming meeting invitations or not. If you just want this library to store incoming attachments, you probably do not want to save these invitations.

   10. In the e-mail Security section, select which senders this library will accept e-mail from. The default is to accept e-mail only from users with Write permissions to the library. Note that if you instead choose the option Accept e-mail messages from any sender, then this library may be attacked by spam mail!

   11. Click OK to save and close this form.

       Tip

       If you test the incoming e-mail functionality, and no mail or attachments show up within a few minutes, then check that your user account has permission to write to that document library!

       Figure 5-5

       

5. Make the mail address to this mail-enabled library show up in the users’ global address list (GAL) in Outlook. To do this you need to create a Contact object in Active Directory with the same mail address as the library. These steps assume that you are using MS Exchange 2000/2003 as your normal mail system!

   1. Log on as a Domain Administrator to a Windows 2003 domain controller in your Active Directory domain.

   2. Start Active Directory users and computers (ADUC), which you will find in Start —> Administrative Tools.

   3. Select the Organizational Unit (OU) where you want to create the new contact; for example, to make this Users, right-click on Users and select New —>Contact.

   4. In the form that appears, enter a name for the Contact; pay attention to the Display name, since this is what will be visible in the GAL. You can skip the First name and Last name, but you must enter something in the Full name and Display name. It is okay to enter the same name in these two fields (see Figure 5-6), then click Next.

      Figure 5-6

      

   5. In the next form, make sure that Create an Exchange e-mail address is checked. This will ensure that the Contact will show up in the GAL. Note that this will not create a mailbox in the Exchange server! To define the mail address click Modify, then select SMTP Address and click OK. Now enter the same mail address you defined to the mail-enabled library in step 4f above, then click OK. Next, you see a summary of these settings (see Figure 5-7). Click Next to continue, and then Finish on the final page.

      Figure 5-7

      

6. Optional: The new contact will show up in Outlooks GAL within one minute. (You may have to download the new address list in Outlook if you run in cached mode.) You may want to give the contact a secondary SMTP address, to allow external users to send mail to that library.

   Remember that you must then also select the option Accept e-mail messages from any sender in step 4j above!

   1. Open the ADUC again, and locate the contact you just created.

   2. Right-click on that contact, and select Properties.

   3. Switch to the e-mail Addresses.

   4. Click New.

   5. Click SMTP address, and then OK. Note that you can add any type of alternative address you need for the Contact object.

   6. Enter an alternative SMTP address in the e-mail address field; for example, Project-X@filobit.com (assuming that @filobit.com is the mail domain for the Exchange server).

   7. Click OK. Now you will see all e-mail addresses that the Contact object has (see Figure 5-8). This means that you can send e-mail to the contact using any of these mail addresses, including the X400 address. When Exchange receives this mail, it will forward them directly to the mail server responsible for the mail domain @srv1.filobit.com, that is, the SharePoint server. You can now tell anyone outside your organization to send important e-mail regarding Project X to this address: Project-X@filobit.com.

   8. Click OK again, to close the properties for the contact.

      Figure 5-8

      

   Now open Outlook, and create an e-mail: Click on the To button, and select the display address Project X Document Library. Then enter a subject, add some text in the body and add an attachment. When you are ready, click Send. Next, open the document library in SharePoint and wait for the e-mail and attachment to show up.

Enabling Auto-Created e-mail Addresses

The example above assumed that you wanted to create the e-mail address for the document library manually, but SharePoint has a special module that can do this automatically: SharePoint Directory Management Service. For this to work, you need to do two things:

• Enable the Application Pool account write access to Active Directory.

• Configure the SharePoint Directory Management Service.

Before SharePoint can create an e-mail-enabled contact object in Active Directory, it must have permission to write in Active Directory. One easy way to ensure this is to make sure that SharePoint’s account is a member of the Active Directory group Domain Admins. But the question is what user account are we talking about? The answer is the user account listed as the security account for the application pool, used by the Central Administration web site. Instead of making this user account a member of Domain Admins, it is possible to grant this account the specific permissions needed to write to the organizational unit where the mail-enabled contact will be created.

The second thing listed on the bulleted list above is to enable and configure the SharePoint Directory Management Service (SDMS). This is done on the web form where you enable incoming e-mail. For example, say you have a SharePoint server named SRV1 and an Active Directory domain named FILOBIT.COM, and you want all auto-created contacts to be stored in the organizational unit SP2007. The following Try It Out shows how you would do this.

Try It Out

Enable SharePoint Directory Management Service

1. Log on as an administrator to the MOSS server.

2. Make sure that the organizational unit SP2007 exists and that the application pool account has permission to write to that OU.

3. Open the Central Administration tool —> Operations —> Incoming e-mail settings.

4. In the Directory Management Service section, select Yes, and you will see several new settings show up. To follow the example above, fill in these values (see Figure 5-9):

   Tip

   In order to make it easier for you to read, the information you enter in step a and b below are in capital letters; you can also use small letters if you want.

   1. Active Directory container where new distribution groups and contacts will be created: OU=SP2007, DC=FILOBIT, DC=COM.

   2. SMTP mail server for incoming mail: @SRV1.FILOBIT.COM.

   3. Accept messages from authenticated users only: Yes.

   4. Allow creating of distribution groups from SharePoint sites?: Yes.

   5. Distribution group request approval settings: This is a multivalue setting that asks what needs to be approved by an administrator before taking effect. The default settings are Create new distribution group and Delete distribution group. In other words, SharePoint will try to create or delete a distribution group when a site is created or deleted, but an administrator must approve this first. See the section “Approve/reject distribution group” below for more information on that. In this example, you can accept the defaults.

5. This concludes the configuration of the SharePoint Directory Management Service. Click OK to save and close this page.

Now, follow the steps described earlier to mail-enable a document library, and then check in ADUC to verify that a new contact with this e-mail address has been created. This method of auto-creating contacts is, of course, much handier than the first method described, but you should select the one most suitable for your organization.

Figure 5-9

This concludes the most common administrative tasks for a typical MOSS 2007 installation. You may want to configure more settings and activate more features, as described in the following section.

The Operations Page

The administrative tasks and configuration options you have completed so far have added a lot of functionality to the MOSS server. But there are also a lot more configuration options in SharePoint’s Central Administration tool that you may need in some situations. This tool contains two main pages: Operations and Application Management. The Operations page contains links to general settings and configuration options for the SharePoint server, while the Application Management page contains links for creating and managing tasks related to applications, such as site collections, web applications, and authentication providers. The most commonly used links on the Operations page are described in the following sections, and some of the links on the Application Management page will be described later in this chapter. Many other chapters will cover parts of these links when discussing specific application tasks, such as creating portal sites in Chapter 6.

Open the Central Administration tool, and switch to the Operations page: You have already seen a number of settings on this page, such as Servers in farm, Outgoing e-mail settings, and Incoming e-mail settings, and here is a quick guide to the rest of the settings on this page commonly used for a typical MOSS installation.

The Topology and Services Section’s Approve/Reject Distribution Group Settings

When you create a new web site, with its own permission groups, SharePoint can automatically create a mail distribution group for the members in this site. That group will then show up in the Distribution Groups list shown when you click the link Approve/Reject Distribution Groups on the Operations page. If the administrator approves this group, then SharePoint will create a distribution group with that name in Active Directory and add all users to it who are listed as site members. After that, the distribution group will show up in Outlook’s GALs so that users can start sending e-mail to that group. This is a very handy feature for project groups and other teams who have their own team site, where it is often required that there be a mail distribution group containing all the members of the site.

The Security Configurations Section

You can control security settings from here for service accounts, antivirus protection, blocking file types, SSO, and more.

Service Accounts

Use this page to view and change the service account used by specific services and application pools. The type of service accounts you can change are these (see Figure 5-10):

• Document Conversion Launcher Service (Windows service).

• Document Conversion Load Balancer Service (Windows service).

• Single Sign-On Service (Windows service).

• The User Web Application Pool (Web application pool —> Windows SharePoint Services Web Application).

• The SSP Application Pool (Web application pool —> Windows SharePoint Services Web Application).

• The My Site Application Pool (Web application pool —> Windows SharePoint Services Web Application).

An alternative would be to change these accounts directly; for example, changing the application pool security accounts using IIS Manager. But this does not always work, since SharePoint stores these accounts in its configuration database. In other words, use this page if possible; if not, then try changing the account manually.

Figure 5-10

Information Rights Management

Use this page to configure Information Rights Management (IRM), which is a complementary service for MS Office products and MS SharePoint. With IRM a user can define in very fine detail what other users can do with a specific document or e-mail. For example, a document’s author can say that only two people can read the document, but they can do nothing else, such as print or save it. Note that these permissions will be valid regardless of how a user gets hold of the document, including its having been sent as an e-mail attachment to someone outside the organization.

By default, this page is not active until you install the IRM client with Service Pack 2 or later. You can find more information about this feature in Chapter 8.

Antivirus

Use this page to configure your SharePoint-aware antivirus application. Note that even if this page looks like it is doing something, it will, in fact, not do anything until you install an antivirus application for SharePoint. Some examples of such products are:

• Forefront Security for SharePoint: This is a Microsoft product that previously was called Antigen for SharePoint. Check for more information on it at www.microsoft.com/forefront/serversecurity/sharepoint/download.mspx.

• PortalProtect for SharePoint: This is a product made by Trend Micro. Look for more information on it at www.trendmicro.com/en/products/file-server/ppsp/evaluate/overview.htm.

• Antivirus for Microsoft SharePoint: This product is made by Symantec. Look for more information on it at www.symantec.com/enterprise/products/overview.jsp?pcid=1008\&pvid=829\_1.

At first, you may think that antivirus protection for SharePoint is unnecessary, since your users have a client-based antivirus application. But think again; you would never run a file server without a virus protection, right? And SharePoint will, at least in part, replace your file servers. So it should have the same level of protection. Plan for the virus protection in SharePoint from the beginning; do not wait until you have a virus-infected file stored in any of SharePoint’s document libraries!

Blocked File Types

This section is very important, since it governs what file types SharePoint will accept for storage in any of its libraries, such as document libraries. By default it contains a list of 89 file types, such as .exe and .url. This page is used for both WSS and MOSS installations, so you will find more information about this in Chapter 8.

Updating the Farm Administrator’s Group

Use this page to configure what users will be farm administrators, that is, administrator with full control of the complete MOSS farm. Although this setting also applies to pure WSS installations, it is especially interesting for MOSS, since these types of installations tend to be more complex and have more people involved in the management and administration of the SharePoint farm.

A farm administrator has full access to all settings in the farm. By default, they will not be able to view any content, such as a site or a document library, unless specifically given the permission (i.e., the same rules apply to farm administrators as to ordinary users). But a farm administrator can take ownership of any content and site, if necessary; for example, when they need to fix a problem or assist a site owner.

By default, this farm administrator group contains the user account used by the application pool for the Central Administration tool, plus the user account used to install SharePoint 2007. There is no default group for assisting administrators with limited access, but you could create a SharePoint Group and give it view permissions only, using the steps in the following Try It Out.

Try It Out

Create a View-Only Administrator

1. Log on as an administrator for the MOSS server, and start the Central Administration tool.

2. Open the Operations page, and click Update farm administrator’s group.

3. Next to the New button, click the black arrow to open its menu, then click New Group.

4. On the web form that appears, enter these values:

   1. Name: View-Only Admins.

   2. About Me: “This group is for users who will have view-only access to SharePoint’s Central Administration tool.”

   3. Group owner: Accept the default value.

   4. Group Settings: Accept the default values.

   5. Membership Requests: Accept the default values.

   6. Give Group Permission to this Site: Check Read – Can view only.

   7. e-mail Distribution List: Accept the default value.

   8. Archive e-mail: Accept the default value.

   9. Click Create. The group is now created.

5. The group now contains only the owner account; click New to add users or groups as members of this SharePoint Group.

Since you cannot easily create a group with limited administrative access, you must be very cautious with whom you want as a member of the farm administrator group. Although these administrators cannot see information unless given the permission, they can take ownership and add themselves as members to whatever content exists in SharePoint (exactly as they can with files stored in a file server). Think “Top Management’s secret SharePoint workspace,” and you’ll understand what I mean.

Information Management Policy Configuration

This is a setting exclusive to MOSS installations; its purpose is to let you control what parts of the information management policies you want to be active. These policies will be listed as default configuration options in libraries and lists that will enable one or more policy features. The owner of these lists and libraries may choose any of these preconfigured policies, or choose to define a custom policy. By default, all four of these policies are enabled; if any of these is disabled, then that policy will not be available for any list or library:

• Labels: This feature will generate labels inserted into MS Office 2007 documents. These labels will show up when the document is printed. The information in these labels are also searchable.

• Auditing: This feature will audit any user activity on documents and list items, such as when a user reads a document or modifies a list item. This information is stored in the audit log, described later in this chapter.

• Expiration: This feature lets a user start an action or workflow at a given time; for example, 6 months after a document was created it should be moved to another library.

• Barcodes: This feature will generate a unique identifier in an MS Office 2007 document. They can also be used to search for documents.

Use this page to disable, or decommission as SharePoint calls it, any of these policy features; this will affect all lists and libraries in MOSS. Note that if a policy feature is already applied, the feature will remain active, but all new sites and libraries will not have that feature available. Click on the policy name to open the web form where the policy is decommissioned or activated.

Two of these policy features also let you configure their settings: Expiration and Barcodes (see Figures 5-11 and 5-12).

Figure 5-11

Figure 5-12

Managing Settings for Single Sign-On

This is an exclusive setting for MOSS; its purpose is to configure how the feature Single Sign-On (SSO) works in MOSS. This SSO feature is never used in standard MOSS features; in fact, it is not even installed by default. It is typically used when you have a need to retrieve information from a non-Microsoft application, such as SAP, and use this information in SharePoint. Since these non-Microsoft applications use a proprietary system for authenticating users, it will be a problem when SharePoint needs to access its information. The solution to this is to create a separate SSO database in SharePoint with the user account and password to access specific external content. A SharePoint application can then use the SSO database and the SSO feature to get access to that content.

For example, say that you want to show each user information about their salary on their personal My Site and that information is stored in a SAP system. To read this, you need to log on as a SAP user with the proper permission. If you were the programmer who was supposed to fix this, then you would need not only to create a Web Part that displays the salary information but also to add code to your Web Part so that it knows how to log on to the SAP system. The account used to log on is most likely a sensitive account that must not get into the wrong hands, so not only must your Web Part contain the user account to be used to log on, but it must also store this information in a highly secure way.

All of this is taken care of by the SSO feature: its database with user accounts and passwords to external systems are encrypted, and therefore protected. SSO also contains the code necessary to log on to the external system, so that your Web Part only needs to know how to use the SSO feature. There is also a specific administration tool for SSO, for managing these logon accounts and their passwords. This also means that the programmer does not need to know the logon account; the programmer only needs to know how to activate the SSO features.

The Logging and Reporting Section’s Information Management Policy Usage Reports Settings

This MOSS-specific configuration page lets the administrator define how often information management policy reports will be created and where they will be stored. These policies were described earlier in this section, but as a quick reminder here they are again: Labels, Auditing, Expiration, and Barcodes. Most commonly the information related to the Auditing policy will be used when SharePoint creates the policy usage reports. These reports are XML files and will by default be opened in MS Excel 2007.

For example, say that you have enabled auditing policies for a document library named ABC. Your boss asks for a usage report for ABC. If this is a one-time request, you can create the report when necessary, but if your boss wants a regularly created usage report, then you can schedule when to create it. Follow the steps in the Try It Out below to configure the policy usage reports.

Try It Out

Configure Scheduled Policy Usage Reports

1. Log on as an administrator to the MOSS server, and start the Central Administration tool.

2. Open the Operations page, and click Information management policy usage reports.

3. Make sure that the page shows the web application used by the SharePoint site; for example, SharePoint – 80. If it doesn’t, click on the current web application’s name, and select Change Web Application, then select the right web application.

4. Complete the rest of the web form (see Figure 5-13):

   1. In the Schedule Recurring Reports section, check Enable recurring policy usage reports.

   2. Enter the schedule when SharePoint will create these usage reports; for example, Daily between 6:00 and 7:00 am.

      Tip

      You must define the Report File Location before you can click the Create Reports Now button! Use this button whenever you need to generate a usage report immediately.

   3. In the Report File Location section, enter the path to a document library where the usage reports will be stored. You can also click Check URL and browse to a library, then copy that URL and return to the form. In this example, you will save the reports in the /docs/documents library, http://srv1/docs/documents.

   4. In the Report Template section, choose if you want to use the default report template or if you have a custom-made report template. To create a custom template, use MS InfoPath 2007. For more information on how to do this, go to msdn.microsoft.com and search for “SharePoint 2007 policy report template.”

   5. Click OK when ready.

      Figure 5-13

      

These reports will be stored in the document library listed in step c above. Note that any user with Read access to that library will be able to read these reports, so make sure to store them in a proper location to be certain that only authorized users can see them.

The Upgrade and Migration Section

From here, you can manage settings for converting editions, including converting the license type.

Microsoft Content Management Server

This section is used to create migration profiles, when migrating from MS Content Management Server 2002 (MS CMS 2002) to MS Office SharePoint Server 2007. This will help you migrate content from MS CSM to MOSS, but not code, that is, CMS applications. To get more information about this type of migration, go to https://msdn2.microsoft.com/en-us/library/aa480225.aspx.

Enable Enterprise Features

If you installed MS Office SharePoint Server 2007 Standard edition and later want to upgrade to the Enterprise Edition of MOSS, you need to purchase an Enterprise license key and enter this key on the Convert License Type page (see next section), then you can use the Enable Enterprise Features page to enable Enterprise features.

Convert License Type

This page is related to the Enable Enterprise Features page; it is used when you want to convert a Standard Edition of MOSS to an Enterprise Edition. Note that you must have a valid MOSS Enterprise product key in order to convert the license type.

Enable Features in Existing Sites

This page is also related to the conversion of a Standard Edition of MOSS to an Enterprise Edition. If you have used the Standard Edition of MOSS for some time, you have a number of sites that are limited to Standard features. If you later convert the license type to Enterprise Edition, all new sites will have the full functionality that Enterprise offers, but the old sites will still only have Standard features. Use this page to enable Enterprise features on those old standard sites.

The Global Configuration Section

This section has several important settings for configuring your entire system.

Master Site Directory Settings

With MOSS comes a special site template called Sites, which works as a site directory. The idea for this directory is to make it easier for users to find a specific web site, for example a project team site. By default, only subsites created in the current site collection show up in this site directory; any sites in other site collections will not show up here.

This page allows you to specify that all new site collections (their top sites, but not their subsites) can be (but don’t need to be) listed in a specific site directory. Most MOSS installations will only use a single site directory, but if you have more than one, then plan which of them that will be used to store other site collections, since there can only be one master site directory.

Try It Out

Enable a Master Site Directory

1. Log on as an administrator for the MOSS server, and start the Central Administration tool.

2. Open the Operations page, and click Master site directory settings.

3. On the following page, enter these settings (see also Figure 5-14):

   1. In the Site Directory Location section, enter the full URL to the master directory. Note that if the first site collection created is based on the Collaboration Portal site template, then the site directory will be named /sitedirectory, and it will be located directly under the top web site. For example, if the URL of the top site is http://srv1, then the full URL of the master directory will be http://srv1/sitedirectory/. Click on the link Click here to test if the URL you have entered really points to the site directory.

   2. In the Site Creation Metadata section, check Enforce listing new sites in Site Directory to make all new top sites to be listed in the directory. Then choose if you want to force these sites and site collections to contain none, one, or all metadata defined in this site directory. If you select one or all site categories (i.e., metadata), then you must select one, or all, metadata when you create a new site collection.

   3. Click OK to save and close the page.

      Figure 5-14

      

The next time you create a site collection (i.e., a new top site), you will also be able to set the metadata for that site, exactly as you will do when creating subsites in the first site collection.

Site Directory Link Scan

The site directory will soon be a valuable resource for users looking for a specific SharePoint site. But when you delete a site, its link will still be listed in the site directory. Since it does not point to any valid location, it is now referred to as a “broken link.”

On the Site Directory Link Scan page, MOSS has a special feature that can check the site directory for broken links. You just enter the URL to the site directory. But what URL is that? Well, it is not the same URL as you entered earlier; this time you must point all the way down to the list where all site links are stored, including the list view you want to check. For example, if your site directory was created by the Collaboration Portal site template, the complete URL to enter is http://srv1/SiteDirectory/SitesList/AllItems.aspx, assuming that the top site is http://srv1. Just enter this URL in the Site directory view URL’s field, and click OK. If it was the wrong URL, you will receive an error message. If it was correct, a test of all links is now performed and then this page is closed, regardless of whether a broken link was found or not. This may not be the most intuitive user interface, but this is how it works today; it may change in a future service pack. To find out if there were any broken links, you must now open the list with the site link and switch to the Broken Links view, as described in the following Try It Out.

Try It Out

Look for Broken Links

1. Log on as an administrator for the MOSS server, and start the Central Administration tool.

2. Switch to the Operations page, then in the Global Configuration section click Site directory links scan, and enter these settings:

   1. Enter the URL to the list view for the site links; for example, http://srv1/SiteDirectory/SitesList/AllItems.aspx (note that this page will remember any previously typed URL that points to a valid site list).

   2. If you also want to update the site directory with modified site titles and descriptions, check the setting Update title and description of links in the site directory automatically.

   3. Click OK to save and close the page.

3. Go to the URL in step 2a. This will open the site list in the site directory.

4. Change the View to Broken Sites. Any site link listed here is broken; either remove the link, or update it by using its quick menu, and selecting Edit Item.

   Tip

   By default, it will take up to 24 hours before a broken link will be discovered. The reason is that SharePoint runs a process that updates the site directory once per night (01.00 am). You can speed up this process by using the Stsadm.exe tool. For example, to run the site directory update process once every five minutes, open a command prompt and enter this string: stsadm –o setsitedirectoryscanschedule –schedule “every 5 minutes between 0 and 59”.

Quiesce Farm

In some situations you need to take down a SharePoint server, but it may be hard to find a time when the server is not being used. The brutal way, of course, is simply to shut it down, but you may not be so popular among the user community if you do this. The strange phrase “Quiesce farm” is exactly what you need. It will prohibit all new sessions but let the current sessions run for a configurable time, for example 30 minutes, before it stops all SharePoint actions. In other words, quiesce means to gracefully shut down a process, such as SharePoint. It can also be used to gracefully stop InfoPath forms from being used, as you will see later in this chapter.

Conclusion for the Operations Page

As you have seen, the Operations page contains a lot of links to general configuration settings. As a SharePoint server administrator, you must learn to use these features, or at least know what they do and when you may need them. If you are wondering about the backup and restore section on this page, it will be covered in detail in Chapter 14. This concludes the description of the Operations page, and the following section will describe commonly used links on the Application Management page.

The Application Management Page

Open the Central Administration tool, and switch to the Application Management page: You have already used a number of settings on this page, such as Create Web applications, and Create site collections. Here is a quick guide to the rest of these settings commonly used in a MOSS installation. Note that Chapter 8 will cover the settings on this page that apply to both WSS and MOSS installations!

The Search Section’s Manage Search Service Settings

This page shows the current settings for the Search service in MOSS, such as the server name; contact e-mail address, which is used by the administrator if there are questions about the search feature; and which SSP is hosting the Search service. It also contains links to configuration settings related to the search feature (see also Figure 5-15).

Figure 5-15

The InfoPath Forms Services Section

This section in Application Management has five links, all related to the InfoPath Form Service. Following is a short description of what each of these links is used for:

• Manage form templates: Use this page to list and manage all InfoPath forms templates uploaded to the InfoPath Forms Service. Use the quick menu for each template to:

  • View properties for the form template, such as the version, last modification date, and status.

  • Activate this form template for a site collection.

  • Deactivate this form template from a site collection.

  • Quiesce a form template (i.e., prohibit any new instance of this template from being created but allow the instances currently running to be completed).

  • Remove the form template.

  Tip

  The word quiesce has been chosen by Microsoft to describe a process in which a feature prohibits new sessions but allows all current sessions to continue to run for a period of time that you define.

• Configure InfoPath Forms Services: Use this page to configure the settings for the Forms Service, such as:

  • Define if InfoPath forms should be browser-enabled or not.

  • Data Connection Timeouts (default: 10,000 seconds).

  • Data Connection Response Site (default: 1,500 kilobytes).

• For HTTP data connections: Force the data connection to use SSL when authenticating by Basic Authentication, or Digest Authentication (default: Yes).

• Authentication to data sources: You can allow embedded SQL authentication (default: No).

• Cross-Domain Access for User Form Templates: You can allow cross-domain access for user form templates that use connection settings in a data connection file (default: No).

  • Configure Thresholds, that is, the number of postbacks per form session state (default: 75), and the number of actions per postback (default: 200).

  • Configure Form Session State, that is, that active sessions should be terminated after 1,440 minutes, and the maximum size of form session state (default 4096 kilobytes) and that Session State Service should store form session states.

• Upload Form Template: Use this feature to upload a new or updated form to the InfoPath Forms Service. Use the check box if you want to overwrite any existing copy of this form. This page also allows you to define what to do with currently opened forms that are about to be updated:

  • Allow existing browser-based form filling sessions to complete using the current version of the form template, or

  • Terminate existing browser-based form filling sessions. Any data in those sessions will be lost.

• Manage Data Connection Files: Use this page to upload a data connection to external content; this connection can then be used by the InfoPath Form. By default, there are no data connections uploaded.

• Manage the Web Service Proxy: Use this page to enable the Web service proxy for data connections between the InfoPath forms and Web services. You can also enable the Web service proxy for data connections in user forms.

You will learn more about creating InfoPath forms, and how to use the InfoPath Forms Service, in Chapter 7.

The Office SharePoint Server Shared Services Section

This section in the Application Management page is all about the Shared Service Provider (SSP). You may recall that you created an SSP named SharedServices1 in Chapter 4, and this SSP is responsible for many interesting features, such as user profile import, creating audience groups, and configuring global searching. These features are covered in Chapter 8, but here is a quick summary of the links and configuration pages related to the SSP:

• Create or configure this farm’s shared services: Use this page to create and manage instances of SSP, such as SharedService1. Note that you can also open this page by clicking the Shared Services Administration link in the Quick Launch bar to the left on this page.

• Grant or configure shared services between farms: Use this page to configure how shared services will work in a multi-farm environment. You may remember that one SharePoint farm will automatically share its SSP instances, but if there is more than one farm, you must use this page to configure the system so that the SSP in one farm can be used in other farms.

• Check services enabled in this farm: This is not directly related to the SSP, but its page will show a list of services that have some type of problem. In other words, if you see a service listed on this page, there may be something the administrator must do. Note that if you have installed an evaluation copy of MOSS, then you will see a service saying: The trial installation on server SRV1 will expire on <date>, plus a description of the impact it will have when this trial period has ended. This list may also show a recommended action for how to solve a problem; for example, how to convert the trial version to a full MOSS installation.

• Configure session state: This is a setting that will affect the web client. If this setting is on, then SharePoint will remember who you are when you move from one site to another. If the Session State is disabled, users may have to enter their logon credentials when moving to a new part or feature of MOSS. The default setting is enabled. This page also allows you to set a timeout period for a user session; the default is 60 minutes. If a user is inactive longer than that, he or she may need to log on again, depending on if he or she is working from the inside of your network or from the Internet.

The External Service Connections Section’s Records Center

A records center is an advanced MOSS feature that works like a stand-alone SharePoint document repository; it could be a separate SharePoint server or a subsite in a site collection. A Records Center is used when an organization needs to move or copy important records, such as records about employees, or important projects, to a safe place where no unauthorized personnel will be able to view or modify them. This configuration page is used to define the URL to the Records Center server, which must have been installed previously.

Before activating the records center, an organization must devise a strategy for how to use this records center; for example, what records should it store, what policies will be applied to these records, who should be able to send records to the repository, and who should be able to view and manage these records? These are important questions that are usually answered by management teams, compliance officers, and information workers. Best practice is to create one document library for each record content type, and avoid mixing content types in the same library; these libraries will store the records.

The next step is to create a Records Center site, preferably on a separate SharePoint server, or at least on a separate Web application (such as an extended IIS web server). You should use a separate SQL Server database to store the content of a records center if the security requirements are very high. In the following example, you will create a site collection in a separate web application and in a new site collection, which will be okay for organizations with moderate security requirements. Follow the steps in the Try It Out below to create a Records Center site in a newly created web application named RecordsCenter, using the TCP port 80 and the host header name RecordCenter.

Try It Out

Create a Records Center Site

1. Log on as an administrator for the MOSS server, and start SharePoint’s Central Administration tool.

2. Switch to the Application Management page.

3. Click Create or extend Web application, then click Create a new Web application, and give it the description RecordsCenter, the TCP port of 80, and the Host Header name RecordsCenter. Also create a separate application pool named RecordsCenter, using the account Filobit\sp_service. Click OK to save and close the form. For more information about creating web applications, see Chapter 4.

4. Since you defined a Host Header name for the Web application in step 3, you must now add this name as an alias record in the DNS:

   1. Log on to an Active Directory domain controller. Start the DNS by clicking Start —> Administrative tools —> DNS, expand the Forward Lookup Zone, right-click on the domain name (in this example Filobit.com), and select New Alias (CNAME).

   2. In the form that appears, enter RecordsCenter as the alias name, click the Browse button, and locate the SharePoint server name (in this example SRV1), then click OK twice.

   3. Test your work by opening a command prompt window, and typing ping recordscenter; the reply should be the IP number for SRV1.

5. Switch to the Application Management page again. Click Create Site Collection (in the SharePoint Site Management section). This will create a new site collection for the records center site.

6. On the web form that appears (see Figure 5-16), enter these settings:

   1. Click on the Web application, and change it to RecordsCenter.

   2. Title: Records Center.

   3. Description: Filobit Record Repository.

   4. URL name: http://recordscenter.

   5. Select a template: Switch to the Enterprise tab, and select Records Center.

   6. Primary Site Collection Administrator: Filobit\Administrator.

   7. Leave the rest of these settings as they are. Click Create.

      Figure 5-16

      

   The Records Center site is created and displayed. The next step is to configure it properly for the type of records management your organization requires. After that you must configure how an incoming document will be routed to the right library. Start by creating the document library that will store the records. Click Site Actions —> Create —> Document Library. Give it a name, for example, Financial Reports, and click Create.

   The next step is to configure the record routing for the records center site. This is a list of items that defines where an incoming document will be stored. For example, assume that you have five different document libraries, all storing different types of records. Since the user will never manually store the document in a specific library in the records center, you need another process that does that for you. This is what the Record Routing list is used for. By default, there is one document library named Unclassified Records.

7. Create a new Record Routing entry like this: While still in the Records Center site, click on the Record Routing list in the Quick Launch bar, then click New and enter this information (see Figure 5-17):

   1. Title: Financial Reports. This must match the title of the document content type.

   2. Description: “Store all financial reports in the document library Financial Reports.”

   3. Location: Financial Reports. This must match the name of the document library where the record documents will be stored.

   4. Alias: Enter any alias for the default content type, that is, “Title” above. For example, if you also want to route documents based on the content type Budget to the same library, then enter Budget here. If you have more than one name, separate them with a slash (/).

   5. Default: Set this check box if you want the location in step c to receive any documents that do not match any record routing rule.

   6. Click OK to save and close the page.

      Figure 5-17

      

8. You must now enable the application pool account used by the Web application hosting your user portal, for example “SharePoint – 80,” access to the Records Center site. In this particular case, it will not be necessary, since you are using the same account (Filobit\sp_service) for both the user portal and the records center:

   1. Use the Internet Information Service (IIS) Manager, and look up what user account that application pool is using (as described earlier several times); in our example it will be Filobit\sp_service.

   2. Open the Records Center site.

   3. Click People and Groups in the Quick Launch bar.

   4. Click the Groups headline in the Quick Launch bar. This will list all groups.

   5. Click on the group Records Center Web Service Submitter for RecordsCenter. The application pool account must be a member of this group in order to have write permission to the document libraries in the records center.

   6. This group is empty initially; click Add and enter the user name, including the domain name, for the user that the application pool is using as its security account.

   7. Close this configuration page.

   The Records Center site is now ready to be used. Next you must create a Content Type, i.e. a defined type of document, with a name that exact matches the Title in step 6b above. After that, you must activate this content type in all these document libraries where users are supposed to create financial reports, budgets and financial documents:

9. Open the top site where the users create their documents; for example, http://srv1, then click Site Actions —> Site Settings —> Modify All Site Settings, and modify the following settings:

   1. Click Site Content Types in the Galleries section.

   2. Click Create, and enter the name Financial Reports. Remember that it must match the Title in step 6b.

   3. In the Parent Content Type section, choose Document Content Types and Documents.

   4. Accept the option to put this site content type into the Custom Content Types.

   5. Click OK to save and close this new content type.

   6. Optional: If you want to use a specific document template, click Advanced settings and upload the Word template or document to be used as a template for this content type.

   7. Optional: If you need any custom columns, then add them in the Columns section.

10. When the content type is created, it must be associated with the user’s document library, used for storing this type of documents: Open a user site with the document library with which this content type will be associated; for example, the subsite Finance: http://srv1/sitedirectory/finance; then do this:

    1. Click on the document library.

    2. Click Settings —> Document Library Settings.

    3. Click Advanced settings, select Allow management of content type = Yes, then click OK.

    4. A new section named Content Types is displayed; click Add from existing site content types.

    5. Locate the content type Financial Reports, click Add, then OK. This content type is associated with this document library and is ready to be used.

    6. It is now time to add some test documents. Open the document you just added the content type to, then click the black arrow next to the New button to open its menu. Note that you now have two content types: Document and Financial Reports. Select Documents this time, and create a Word file with some text, save it in this document library, and close Word. Then use the menu again, but this time select the Financial Reports type; enter some text, and save the document.

    You now have two new documents in this library, one based on the default document content type, and the other based on the Financial Reports type. The only thing that remains is to configure SharePoint to activate the Web service that will assist all users when they want to send a document to the records center:

11. Open the Central Administration tool, switch to the Application Management page, click on the Records center, then enter these settings (see Figure 5-18):

    1. Select Connect to a Records Center.

    2. URL: http://recordscenter/_vti_bin/officialfile.asmx (where http://recordscenter is the URL to the records center site you created earlier, and the last part of this URL points to the Web service for this site.

    3. Display name: Records Center. This is the name that your users will see in the documents’ Send To menus.

    4. Click OK to save and close this page.

       Figure 5-18

       

12. Time to test the records center. Open the document library where you created the two documents in step 10f. Use the quick menu for the first document (based on the default content type), and select Send to —> Records Center. If all went well, you should now see a page saying Operation Completed Successfully. Click OK to go back.

13. Repeat this for the second document. Both of these documents are now sent to the Records Center site.

14. Open the Records Center site; Open the Unclassified Records document library. It contains a folder with a name based on the date and time when it was created; open that folder and your first document will be stored there. Then open the Financial Records library; your second document should be stored there.

Managing Access to the Portal Site

You use almost, but not exactly, the same procedures to manage users in the portal site as in the WSS site. You can allow access to users and security groups in the Active Directory domain or the SharePoint server’s local account database. Each user must be granted a permission level (directly or as a member of a SharePoint Group) in order to get access to any part of the portal site. Remember that the home site is the top-level site in the site collection that constitutes the portal site. Any permission settings for that top site will, by default, be inherited by all subsites, such as News, Reports, and Sites, and possibly by their subsites, if any.

Managing Users and Groups

When you create a new top site (and thus a new site collection), you must also define its primary site collection administrator. At that point this person (and you, as a SharePoint server administrator) is the only one with access to this site collection. To add users to the site, you follow the same steps as when adding users to a WSS site, as described in Chapter 3; be sure to read that chapter too, so you are sure how the permission system works for WSS 3.0 sites in SharePoint 2007. To add a user or an Active Directory group, you perform the steps in the following Try It Out. This can be done from any computer, as long as you have administrative rights on the top site.

Try It Out

Add Users to the Top Site

1. Log on as the administrator, and open the top site.

2. Click Site Actions —> Site Settings —> People and Groups.

3. Select the SharePoint Group that the new user will belong to. You may remember from Chapter 3 that SharePoint creates three local groups that have the name of the top site as a prefix, then a suffix: Visitors (View only), Members (View, Add, Modify), and Owners (Full Access). In this example, select the group that ends with Member, then click New.

   1. In the Users/Group field, enter the user’s name, or e-mail address. If you add more than one name, separate them with a semicolon (;).

   2. In the Give Permission section, make sure that the selected SharePoint Group is correct. If it is not the correct SharePoint Group, then use its menu to change the group. Note that you can also grant the user a permission level directly, such as Full Control, Design, or Contribute.

   3. At the end of this web form, check the Send welcome e-mail to the new users option, if you want to send an e-mail to inform the users about their new permission with a link to this web site.

   4. Click OK to save and close the page.

4. Verify that it works; log in as the new user and check that it works. Note that SharePoint’s security trimmed feature is active, so if this new user is missing some link, such as Site Actions, or cannot see everything that you know exists on this site, it is because he or she does not have the proper permission to do so.

If there are any subsites that inherit their permissions from this site, the new user will now have the same permissions to those subsites as he or she does to this site. If this is not what you want, you can break the inheritance like this as shown in the following Try It Out.

Try It Out

Break the Permission Inheritance

1. Log on as the administrator, and open the subsite where you want to break the permissions inheritance.

2. Click People and Groups in the Quick Launch bar.

3. Click Site Permissions in the Quick Launch bar.

4. Click Actions —> Edit Permissions, then click OK to accept the warning about breaking the permissions inheritance.

5. Now you can add, modify or delete any existing user account or SharePoint Group.

6. Optional: If you want to restore the inheritance of permissions, click Actions —> Inherit Permissions. All customized permissions will be replaced with the inherited permissions.

SharePoint Groups

In Chapter 3, you learned that a user must be associated with a Permission Level role before he or she can access anything in SharePoint. In WSS 3.0 the default permission levels were Read, Contribute, Design, and Full Control. MOSS adds some more Permission levels: Manage Hierarchy, Approve, and Restricted Read. As in WSS, the easiest way to grant a user permissions is to use any of the three default SharePoint Groups that automatically are created for each new SharePoint site configured to use its own security settings (that does not inherit its permissions from a parent site). The name for these SharePoint Groups will start with the name of the site they belong to. For example, if the site is named ABC, the SharePoint Groups’ name will start with ABC. MOSS will add more default SharePoint Groups besides these three. All of them are listed here, for a site named ABC:

• ABC Visitors: This SharePoint Group is associated with the permission level Read: Any member of this group can view, copy, and print content in lists and libraries, including previous versions, if any.

• ABC Members: This SharePoint Group is associated with the permission level Contribute. Members of this group can also add, modify, and delete lists and library content.

• ABC Owners: This SharePoint Group is associated with the permission level Full Control. Members of this group have full access to this site, and all its content.

• Approvers: This SharePoint Group can edit and approve pages, lists, items, and documents.

• Designers: This SharePoint Group can edit lists, libraries, and pages in a site. It can also create Master Pages, and page layouts in the Master Page Gallery, and it can modify the Cascading Style Sheets (CSS) files.

• Hierarchy Managers: This SharePoint Group can create sites, lists, list items, and libraries.

• Quick Deploy Users: This SharePoint Group can schedule Quick Deploy jobs.

• Restricted Readers: This SharePoint Group can view pages, libraries, and lists, but not their version history.

• Style Resource Readers: This SharePoint Group can read, but not change, the Master Page Gallery. By default, all authenticated users are members of this group.

• Viewers: This SharePoint Group can view pages, list items, and documents. If the document has server rendering available, members of this group can only view the document using the server rendering.

Removing User Accounts

As described several times, all users must be granted a permission level, either directly or as a member of a SharePoint Group, in order to access any part of SharePoint. This is true both for WSS and for MOSS sites. In most organizations, these domain user accounts are stored in the Active Directory. This section describes what happens when these user accounts are deleted from the AD. You might assume that SharePoint automatically cleans up when someone is removed from the AD. But if you do, you are wrong! Think about it: One of your users has been active in several important projects now she has left the company. Do you really want to remove all references to that user? In many situations, the answer is no. So, SharePoint requires the administrator to manually remove the user account when necessary. The good news is that it is easy; just follow the instructions below. There are two ways to delete a user from SharePoint. One is where you remove the user account from all sites in a given site collection. For example, you might want to have a user’s Active Directory account still be valid, but remove all access from SharePoint. The other way is to remove all information about a user from the User Profile database. Let’s start with the first method as shown in the following Try It Out.

Try It Out

Remove a User Account from a Site Collection

1. Open the top site in the site collection from where the user account should be removed.

2. Click Site Actions —> Site Settings —> People And Groups. If the top site is based on a WSS template, you can also click the link “People And Groups” in the Quick Launch bar.

3. Click the All People link in the Quick Launch bar.

4. Select the user(s) to be removed, click the Actions menu, and then click Delete Users from Site Collection.

5. You will now see a warning: “You are about to delete the following users from this site collection. The users will be deleted, and will not have access to any site within the site collection,” followed by the name(s) to be deleted. Double-check that this is what you want to do, then click OK to complete the delete operation.

The procedure above will remove the permissions, but not the properties for the user, from the User Profile database. Follow the procedure in the Try It Out below to remove the user from the User Profile database.

Try It Out

Remove a User from the User Profile Database

1. Log on as an administrator, and open SharePoint’s Central Administration tool.

2. In the Quick Launch bar, click in the shared service provider link, by default, named SharedServices1.

3. In the User Profiles and My Sites section, click User profiles and properties.

4. Click View user profiles.

5. In the toolbar, change the view to Profiles Missing from Import. Now, all deleted user accounts are listed. Check the user profiles to be removed from SharePoint, and click Delete on the toolbar.

A related situation occurs when someone is changing the logon account name in the Active Directory (for example, when changing her last name due to marriage). Doing this will not update the user account information in SharePoint unless you follow the steps in the Try It Out below (in this example, a user has changed his logon name from Filobit\tony to Filobit\Antony):

Try It Out

Update User Account Information in SharePoint

1. Log on to the SharePoint server as an administrator.

2. Open a command prompt.

3. Enter the following command (see Chapter 3 about updating the environment variable path to include the path to the file folder storing the STSADM utility):

   STSADM -o migrateuser -oldlogin filobit\tony -newlogin filobit\antony -ignoresidhistory
   

Anonymous Access

Just as in WSS, a MOSS site can be opened for anonymous access. The steps to do this are identical to how this is done in a WSS site, so be sure to read Chapter 3 to see more about these anonymous access settings.

Summary

In this chapter, you learned the following:

• After the initial installation of MOSS, there are three final steps that you must do to prepare the new SharePoint server. They are referred to as “administrator tasks.”

• When these tasks are completed, you will see a new list of administrative tasks.

• Not all of these tasks in the new list must be completed, but be sure to configure outgoing e-mail settings and schedule the indexing of SharePoint’s databases.

• The Central Administration tool is organized into two pages: Operations and Application Management.

• Enable incoming e-mail settings if SharePoint should be able to accept incoming e-mail.

• Configure User Profile import if you want SharePoint to store user properties.

• Define a link to the portal site before you start creating all My Sites.

• Create the records center using a separate web application or a separate SharePoint server.

• In order to enable creation of My Sites, the user account used by the application pool hosting the Central Administration tool must be a member of the local Administrators group on the SharePoint server.

• Be sure to use the Service Account area of the Operations page when you need to update a service account; for example, for an application pool or a SharePoint service.

• Do not forget to install antivirus programs that work directly with SharePoint’s database!

• Single Sign-On is used by programmers and applications to get access to external data sources.

• Use information management policy settings, to get full control over documents, during their lifetime.

• Granting access to the MOSS site is done exactly as in WSS; the difference is that MOSS has more preconfigured SharePoint Groups.

• Use the Master Site Directory Setting to ensure that all new top sites can be listed in the master site directory.

• SharePoint has a feature that scans for broken site links in the master site directory.

• There are a number of configuration pages related to InfoPath Forms Services; make sure that you know how to use them, to get the most out of the Forms Service.

• Anonymous access in MOSS is configured exactly as in WSS sites —be sure that you understand how this works before opening a site to anonymous access. Read more about this in Chapter 3.

In the next chapter, you learn more about creating web sites.