Microsoft Sharepoint Products and Technologies Resource Kit eBook

Microsoft Sharepoint Products and Technologies Resource Kit eBook
PUBLISHED BY
Microsoft Press
A Division of Microsoft Corporation
One Microsoft Way
Redmond, Washington 98052-6399
Copyright © 2004 by Microsoft Corporation.
All rights reserved. No part of the contents of this book may be reproduced or transmitted in any form or by
any means without the written permission of the publisher.
Library of Congress Cataloging-in-Publication Data pending.
Printed and bound in the United States of America.
1 2 3 4 5 6 7 8 9
QWT
8 7 6 5 4 3
Distributed in Canada by H.B. Fenn and Company Ltd.
A CIP catalogue record for this book is available from the British Library.
Microsoft Press books are available through booksellers and distributors worldwide. For further information
about international editions, contact your local Microsoft Corporation office or contact Microsoft Press
International directly at fax (425) 936-7329. Visit our Web site at www.microsoft.com/learning/. Send comments
to [email protected]
Active Directory, BizTalk, FrontPage, InfoPath, IntelliSense, JScript, Microsoft, Microsoft Press, MSDN,
Outlook, PowerPoint, SharePoint, Visio, Visual Basic, Visual Studio, Win32, Windows, Windows NT, and
Windows Server are either registered trademarks or trademarks of Microsoft Corporation in the United States
and/or other countries. Other product and company names mentioned herein may be the trademarks of their
respective owners.
The example companies, organizations, products, domain names, e-mail addresses, logos, people, places,
and events depicted herein are fictitious. No association with any real company, organization, product,
domain name, e-mail address, logo, person, place, or event is intended or should be inferred.
This book expresses the author’s views and opinions. The information contained in this book is provided
without any express, statutory, or implied warranties. Neither the authors, Microsoft Corporation, nor its
resellers or distributors will be held liable for any damages caused or alleged to be caused either directly
or indirectly by this book.
Acquisitions Editor: Hilary Long
Project Editor: Valerie Woolley
Technical Editors: Mark Harrison and Gary A. Bushey
Development Editor: Maureen Zimmerman
Principal Compositor: Elizabeth Hansford
Indexer: Pamona Corporation
Body Part No. X10-46136
Contents at a Glance
Part I
1
2
3
Introduction to SharePoint Products and Technologies
Part II
4
5
6
7
SharePoint Products and Technologies Architecture
Part III
8
Planning and Deployment
9
10
Introduction to Microsoft SharePoint Products and Technologies . . . . . . . . . . . . . . . . . . . .3
Installing Windows SharePoint Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Installing Microsoft Office SharePoint Portal Server 2003 . . . . . . . . . . . . . . . . . . . . . . . 53
Windows SharePoint Services Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
SharePoint Portal Server Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
Security Architecture for SharePoint Products and Technologies . . . . . . . . . . . . . . . . . 125
Architecting SharePoint Products and Technologies for Operating System Topologies . . 149
Planning Your Information Structure Using Microsoft Office . . . . . . . . . . . . . . . . . . . . . 157
SharePoint Portal Server 2003
Capacity Planning. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185
Performance Monitoring in Microsoft Office SharePoint Portal Server 2003 . . . . . . . . 237
Part IV
11
12
13
14
Deployment Scenarios
Part V
15
16
Administration of Windows SharePoint Services
Part VI
17
18
Administration of Microsoft Office SharePoint Portal Server 2003
Part VII
19
20
21
22
23
24
Information Management in SharePoint Products and Technologies
Deploying a Single Server and a Small Server Farm . . . . . . . . . . . . . . . . . . . . . . . . . . .
Deploying Medium and Large Server Farms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Installing and Configuring Windows SharePoint Services in an Extranet . . . . . . . . . . .
Shared Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
273
281
317
339
Configuring Windows SharePoint Services. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353
Windows SharePoint Services Site Administration . . . . . . . . . . . . . . . . . . . . . . . . . . . . 405
Configuring SharePoint Portal Server 2003. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 451
Managing SharePoint Portal Server 2003 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 481
Working with Documents in SharePoint Products and Technologies. . . . . . . . . . . . . . .
Working with Information Components in SharePoint Products and Technologies. . . .
The Architecture of the Gatherer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Managing External Content in Microsoft Office SharePoint Portal Server 2003 . . . . . .
Personalization Services in SharePoint Products and Technologies . . . . . . . . . . . . . . .
Information Security Policies for SharePoint Products and Technologies . . . . . . . . . . .
511
553
585
607
629
661
iv
Contents at a Glance
Part VIII Securing SharePoint Products and Technologies
25
Firewall Considerations for SharePoint Portal Server Deployments . . . . . . . . . . . . . . . . 673
26
Single Sign-On in SharePoint Portal Server 2003 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 693
27
Securing an Extranet Using SSL and Certificates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 723
Part IX
28
29
30
31
32
33
34
35
36
37
Part X
38
39
40
Part XI
41
42
Maintaining a Server in Windows SharePoint Services
Disaster Recovery in SharePoint Products and Technologies. . . . . . . . . . . . . . . . . . . . . 751
Usage Analysis Tools in SharePoint Products and Technologies . . . . . . . . . . . . . . . . . . 787
Default Tools to Customize Windows SharePoint Services. . . . . . . . . . . . . . . . . . . . . . . 799
Working with Web Parts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 819
Using Microsoft Office FrontPage 2003 to Customize SharePoint Products . . . . . . . . . 849
and Technologies Sites
The Windows SharePoint Services Object Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 925
The SharePoint Portal Server Object Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 941
Building Applications Using Windows SharePoint Services Data . . . . . . . . . . . . . . . . . . 951
Building Applications for Microsoft Office SharePoint Portal Server 2003 . . . . . . . . . . 987
Using Visual Studio .NET to Create Web Parts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1001
Microsoft Office 2003 Integration with SharePoint
Products and Technologies
Windows SharePoint Services with the Microsoft Office System . . . . . . . . . . . . . . . . . 1027
Using Microsoft Office InfoPath with SharePoint Products and Technologies . . . . . . . 1037
Microsoft Outlook 2003 Integration with SharePoint Products and Technologies . . . . 1067
Upgrading and Migrating to SharePoint Products
and Technologies
Integrating Exchange Server 2003 with SharePoint Products and Technologies. . . . . 1089
Upgrading and Migrating to SharePoint Products and Technologies . . . . . . . . . . . . . . 1099
Contents
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxvii
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxxi
Part I
1
Introduction to SharePoint Products and Technologies
Introduction to Microsoft SharePoint Products and Technologies
3
Comparison of Features in Windows SharePoint Services and
SharePoint Portal Server 2003. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Main Design Goals for SharePoint Products and Technologies . . . . . . . . . . . . . . 6
Consistent Experience for Users, Developers, and IT Professionals. . . . . . . . 6
Consistency and Integration with the .NET Framework . . . . . . . . . . . . . . . . . 6
Integrated Storage Strategy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Trustworthy Computing Initiative: Security and Reliability . . . . . . . . . . . . . . . 7
Architecture and Design Decisions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Integrated Storage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
ASP.NET Web Part Pages and Web Parts . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Common Collaboration Management Services . . . . . . . . . . . . . . . . . . . . . . . 9
Site Creation and Management Services. . . . . . . . . . . . . . . . . . . . . . . . . . 10
Integrated Search Solution. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Personalization and Audience-Targeted Information and Applications . . . . . . 10
Subscriptions and Alerts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Simple Single-Server Configurations and Highly Scalable Server
Farm Configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Important Features and Terminology Used in SharePoint
Products and Technologies. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
SharePoint Sites and Site Collections . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Single-Server Scenario. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Server Farm Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Portal Sites. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Site Groups and Rights . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Cross-Site Groups, Local Groups, and Domain Groups . . . . . . . . . . . . . . . . 16
Authentication. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Authorization. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Site Administration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Document and Content Storage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Organizing Documents and Other Content . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Search Configuration and Usage. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
v
vi
Contents
2
Installing Windows SharePoint Services
Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Hardware and Software Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . .
Application Coresidency and Configuration Considerations . . . . . . . . . . . . .
Installing Windows SharePoint Services on a Single Machine with WMSDE . . . .
Avoiding Installation Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Installing Windows SharePoint Services with SQL 2000 . . . . . . . . . . . . . . . . . .
Installing Windows SharePoint Services with SQL Server on the
Same Computer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Upgrading from WMSDE to SQL Server . . . . . . . . . . . . . . . . . . . . . . . . . . .
Installing Windows SharePoint Services into a Server Farm . . . . . . . . . . . . . . .
Server Farm with Multiple Host Names Deployment . . . . . . . . . . . . . . . . . .
Preparing the Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Hardware and Software Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . .
Installing and Configuring Windows SharePoint Services. . . . . . . . . . . . . . .
Install Windows SharePoint Services with the Remote
SQL Server Option. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Uninstalling Windows SharePoint Services . . . . . . . . . . . . . . . . . . . . . . . . . . .
Uninstall Windows SharePoint Services Completely from a Server. . . . . . . .
Removing Windows SharePoint Services from a Virtual Server . . . . . . . . . .
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3
Installing Microsoft Office SharePoint Portal Server 2003
Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Hardware and Software Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . .
Application Coresidency and Installation Considerations . . . . . . . . . . . . . .
Installing SharePoint Portal Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Automated Installations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Migrating from WMSDE to SQL Server. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Installing the Component for Backward-Compatible Document Libraries. . . . . . .
Install the Component for Backward-Compatible Document Libraries . . . . . .
Installing the Client Components for Backward-Compatible
Document Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Repairing the Client Components for Backward-Compatible
Document Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Installing SharePoint Portal Server into a Non–Active Directory Environment . . .
Uninstalling SharePoint Portal Server 2003. . . . . . . . . . . . . . . . . . . . . . . . . . .
Uninstall SharePoint Portal Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Repairing SharePoint Portal Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
21
22
22
25
27
27
29
29
35
40
41
41
41
42
42
48
48
49
52
53
54
54
58
60
72
81
82
82
83
84
86
86
87
88
Contents
Troubleshooting SharePoint Portal Server Installations . . . . . . . . . . . . . . . . . . .
“Error 502” Error Message When Trying to Access SharePoint
Central Administration Pages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
The Configure Server Farm Account Settings Page Does Not Appear . . . . . .
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Part II
4
vii
89
89
90
92
SharePoint Products and Technologies Architecture
Windows SharePoint Services Architecture
95
Architectural Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
Improvements over SharePoint Team Services . . . . . . . . . . . . . . . . . . . . . . 97
Front-End Web Servers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
Back-End Databases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
Physical Configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
IIS Services Used by Windows SharePoint Services . . . . . . . . . . . . . . . . . . . . . 99
Virtual Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
Application Pools. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
Authentication. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
ASP.NET . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
Changes Made by Windows SharePoint Services . . . . . . . . . . . . . . . . . . . . . . 100
Request Handler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
Extending Virtual Servers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
Application Pools in Windows SharePoint Services . . . . . . . . . . . . . . . . . . 101
Web Part Pages. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
Web Parts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
Web Part Zones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
Customization and Personalization for Web Parts. . . . . . . . . . . . . . . . . . . . . . 105
Customization vs. Personalization. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
Exporting Web Parts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
Description Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
Handling Site Page Requests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
Routing Page Requests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
Rendering .ASPX Pages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
Templates. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
Saving Database Space . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
Increasing Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
The Effects of Customization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
The Web.Config File. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
viii
5
Contents
SharePoint Portal Server Architecture
Building on Windows SharePoint Services . . . . . . . . . . . . . . . . . . . . . . . . . . .
Additional Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Administration Service. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
SharePoint Portal Alert Service. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Microsoft SharePoint Portal Server Search Service . . . . . . . . . . . . . . . . .
Microsoft Single Sign-On Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Changes to Front-End Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Front-End Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Changes to Back-End Database Components . . . . . . . . . . . . . . . . . . . . . . . .
Configuration Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Additional Databases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Physical Configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Single Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Server Farms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Personal Sites vs. My Site . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
User Profiles and Audiences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Populating the User Profile Database . . . . . . . . . . . . . . . . . . . . . . . . . . .
Creating Audiences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Enabling and Configuring Single Sign-On Service . . . . . . . . . . . . . . . . . . . . . .
Authentication with Single Sign-On . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Shared Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Database Access in Shared Services . . . . . . . . . . . . . . . . . . . . . . . . . . .
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6
Security Architecture for SharePoint Products and Technologies
Authentication. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Authorization. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Authorization in Windows SharePoint Services . . . . . . . . . . . . . . . . . . . . .
Authorization in SharePoint Portal Server . . . . . . . . . . . . . . . . . . . . . . . .
Code Access Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
SharePoint Products and Technologies Code Access Security Policies . . . .
Communication Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Communication with Microsoft SQL Server . . . . . . . . . . . . . . . . . . . . . . .
Communication Between Index and Search Servers . . . . . . . . . . . . . . . .
Using Firewalls to Protect the SharePoint Sites . . . . . . . . . . . . . . . . . . . .
Using SSL for Extranet Deployments . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
113
114
114
114
115
115
115
115
116
117
118
118
118
119
119
119
120
120
120
121
121
122
123
123
125
126
129
129
137
142
143
145
146
147
147
148
148
Contents
7
Architecting SharePoint Products and Technologies
for Operating System Topologies
Specific Requirements for Server and Client . . . . . . . . . . . . . . . . . . . . . . . . .
Server Requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Client Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Authentication. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Administrative Rights. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
User Account Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Controlling Access to Sites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Active Directory–Dependent Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Active Directory Application Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Part III
8
149
149
150
150
150
151
152
152
153
153
154
Planning and Deployment
Planning Your Information Structure Using Microsoft Office
SharePoint Portal Server 2003
Key Information Management Features of SharePoint Portal Server 2003 . . . .
Where to Start . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Key Decision Areas for SharePoint Portal Server 2003 . . . . . . . . . . . . . . . . . .
Planning Search . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Planning Alerts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Planning Topics and Areas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Planning Keywords and Keyword Best Bets . . . . . . . . . . . . . . . . . . . . . . .
Planning User Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Planning Audiences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Planning Personal Sites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Planning Windows SharePoint Services Team Sites . . . . . . . . . . . . . . . . .
Planning and Managing Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
ix
Capacity Planning
Topology Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Common Infrastructure Requirements. . . . . . . . . . . . . . . . . . . . . . . . . . .
SharePoint Products and Technologies Licensing Guidelines . . . . . . . . . . . . . .
SQL Server Licensing Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Deploying a Single Server with MSDE . . . . . . . . . . . . . . . . . . . . . . . . . . .
Deploying a Single Server Using SQL . . . . . . . . . . . . . . . . . . . . . . . . . . .
Small Server Farm. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Load-Balanced Medium Server Farm . . . . . . . . . . . . . . . . . . . . . . . . . . . .
157
158
158
160
160
169
171
174
175
177
179
180
183
183
185
185
186
188
189
190
190
191
192
x
Contents
Highly Available Medium Server Farm with SQL Cluster. . . . . . . . . . . . . . .
Minimum Large Server Farm with a SQL Cluster. . . . . . . . . . . . . . . . . . . .
Windows SharePoint Services Server Farm (Optional). . . . . . . . . . . . . . . .
Maximum Large Server Farm with a SQL Cluster . . . . . . . . . . . . . . . . . . .
Logical Deployment Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Planning Services and User Accounts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Planning Services Accounts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Planning User Accounts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Planning the Corporate Portal Site . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Planning Additional Portals. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Planning Roles, Groups, and Rights . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Planning Search . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Overview of Search Functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Planning Alerts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Planning User Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Planning Audiences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Planning for Growth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Estimating System Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Choosing the Farm Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Single-Server Design and Performance . . . . . . . . . . . . . . . . . . . . . . . . . .
Medium Server Farm Design and Performance. . . . . . . . . . . . . . . . . . . . .
Large Server Farm Design and Performance . . . . . . . . . . . . . . . . . . . . . .
Adding Capacity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Performance Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Testing for Capacity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Selecting the Stress Test Tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Tools Used When Performing Load Simulations . . . . . . . . . . . . . . . . . . . .
Scenarios for Load Stress Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Testing Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Generating Load and Interpretation of the Results . . . . . . . . . . . . . . . . . .
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10
Performance Monitoring in Microsoft Office SharePoint
Portal Server 2003
Monitoring Server Farm Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
General Counters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
SharePoint Portal Server Counters . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Microsoft SQL Server. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
193
195
197
197
198
198
199
200
200
201
202
204
204
206
208
209
210
211
216
216
217
219
220
220
222
223
225
226
228
230
235
237
237
238
239
244
Contents
Logs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Internet Information Services (IIS) Logs . . . . . . . . . . . . . . . . . . . . . . . . .
Usage Analysis Processing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Usage Analysis Processing Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Operation Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Architectural Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Monitoring and Alerting Requirements . . . . . . . . . . . . . . . . . . . . . . . . . .
Monitoring Performance Counters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Microsoft Operations Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Hardware Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Network Infrastructure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Analyzing Logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Monitoring Custom Web Parts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Indirect Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Part IV
11
244
245
246
247
249
249
250
252
252
253
254
264
266
269
269
Deployment Scenarios
Deploying a Single Server and a Small Server Farm
Single Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Windows SharePoint Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
SharePoint Portal Server 2003. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Database Automation and Maintenance . . . . . . . . . . . . . . . . . . . . . . . . .
Migrating from WMSDE to SQL Server 2000 . . . . . . . . . . . . . . . . . . . . . .
Small Farm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Windows SharePoint Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
SharePoint Portal Server 2003. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12
xi
Deploying Medium and Large Server Farms
Topologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Preparing for Deploying a Farm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Configuring Network Load Balancing . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Installing and Configuring SQL Server . . . . . . . . . . . . . . . . . . . . . . . . . . .
Installing Internet Information Services and SharePoint Portal Server . . . .
Configuring the SharePoint Portal Server System Architecture. . . . . . . . . .
Creating Portal Sites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
273
273
274
275
276
277
277
278
279
280
281
281
284
288
298
299
301
307
315
xii
Contents
13
Installing and Configuring Windows SharePoint Services
in an Extranet
Setting Up an Intranet and Extranet Deployment . . . . . . . . . . . . . . . . . . . . . .
Preparing the Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Planning for Scale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Next Steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
14
Shared Services
Multiple Portal Sites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Use Intra-Farm Shared Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Configuring Shared Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Adding Portal Sites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Recovery Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Inter-Farm Shared Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Part V
15
318
319
320
337
338
339
339
341
343
345
347
348
349
Administration of Windows SharePoint Services
Configuring Windows SharePoint Services
The Management User Interface for Windows SharePoint Services . . . . . . . . .
Using the SharePoint Central Administration Pages . . . . . . . . . . . . . . . . .
Command-Line Administration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Authentication. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Authentication Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Server Farm Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Setting the Administrative Group for Windows SharePoint Services . . . . . .
Configuring Default E-mail Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Manage Site Owners and Users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Configuring Antivirus Protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Configuring Site Quotas and Locks . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Managing and Customizing Search . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Understanding Search in Windows SharePoint Services . . . . . . . . . . . . . .
Configuring Blocked File Extensions . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
16
317
Windows SharePoint Services Site Administration
Using Templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Team Site Template . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Blank Site Template . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Document Workspace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Meeting Workspace Sites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Customizing, Saving, and Using Templates . . . . . . . . . . . . . . . . . . . . . . .
353
353
354
355
375
376
379
379
380
382
386
389
400
400
403
403
405
406
408
409
409
412
415
Contents
Site Creation Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Creating Subsites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Creating Sites and Subsites from the Command Line. . . . . . . . . . . . . . . .
Allowing Access to Websites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
User Rights Available for Windows SharePoint Services . . . . . . . . . . . . . .
Defining Site Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Customizing Rights for Site Groups. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Using HTML Administration Pages to Manage Site Groups . . . . . . . . . . . .
Using the Command Line to View Site Groups . . . . . . . . . . . . . . . . . . . . .
Assigning Per-List Permissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Controlling Access for All Authenticated Users. . . . . . . . . . . . . . . . . . . . .
Controlling Anonymous Access to a Website . . . . . . . . . . . . . . . . . . . . . .
Creating Unique Permissions for a Subsite . . . . . . . . . . . . . . . . . . . . . . .
Managing Site Creation Rights . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Security and User Rights . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Analyzing Website Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Managing Alerts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Customizing the Message Text for Alerts . . . . . . . . . . . . . . . . . . . . . . . . .
Configuring and Managing Alerts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Part VI
17
xiii
419
420
421
421
422
424
426
426
428
428
433
433
436
437
438
438
438
441
443
445
447
Administration of Microsoft Office SharePoint
Portal Server 2003
Configuring SharePoint Portal Server 2003
A Quick System Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
SharePoint Central Administration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Granting Administrative Access to the Portal Server Farm. . . . . . . . . . . . .
The SharePoint Portal Server Central Administration Page . . . . . . . . . . . .
Server Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Security Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Component Configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Running the Office HTML Viewer Windows Installer Package . . . . . . . . . . .
Portal Site and Virtual Server Configuration. . . . . . . . . . . . . . . . . . . . . . .
Creating Additional Application Pools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Creating Portal Sites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
451
452
452
454
455
455
462
463
466
470
477
479
480
xiv
Contents
18
Managing SharePoint Portal Server 2003
481
Administering Portal Site Settings. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
General Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Manage Users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Manage Security And Additional Settings . . . . . . . . . . . . . . . . . . . . . . . .
Users And Permissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Manage Alerts Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Portal Site Content . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Manage Portal Site Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Manage Top-Level Lists and Document Libraries . . . . . . . . . . . . . . . . . . .
Manage Targeted Links on My Site . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Import Microsoft SharePoint Portal Server 2001 Data . . . . . . . . . . . . . . .
Search Settings And Indexed Content . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
User Profile, Audiences, And Personal Sites . . . . . . . . . . . . . . . . . . . . . . . . .
Manage Profile Database. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Manage Audiences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Manage Personal Sites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Changing Owners of Portal Sites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Part VII
19
482
482
483
483
484
494
497
497
500
500
501
502
502
502
503
505
507
508
Information Management in SharePoint Products and
Technologies
Working with Documents in SharePoint Products
and Technologies
511
Understanding the Document Storage Options . . . . . . . . . . . . . . . . . . . . . . . 512
Form Libraries. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 513
Picture Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 513
Performance Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 515
Content-Related Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 515
Document Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 516
Creating Document Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 523
Security of Document Libraries. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 526
Uploading Documents into a Document Library . . . . . . . . . . . . . . . . . . . . . . . 533
Outside an Office Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 533
Within an Office Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 537
Blocked File Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 538
Modifying Columns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 539
Check-In/Check-Out Processes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 541
About Document Versioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 541
About Checking Documents In and Out . . . . . . . . . . . . . . . . . . . . . . . . . . 545
Contents
Editing Documents in the Document Library . . . . . . . . . . . . . . . . . . . . . . . . .
Content Approval. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Approval Routing in a Backward-Compatible Document Library . . . . . . . . .
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
20
Working with Information Components in SharePoint
Products and Technologies
Lists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
List Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
List Templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Topics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Listings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Areas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Create, Modify, or Delete an Area . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Area Architecture. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Area Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Keywords and Keyword Best Bets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Creating and Managing Keywords . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Views of Keywords and Keyword Best Bets . . . . . . . . . . . . . . . . . . . . . . .
Approval and Publishing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Document Metadata . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
21
The Architecture of the Gatherer
Default Indexes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Role of the Gatherer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
The Indexing Process. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Protocol Handlers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Filters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Plug-Ins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Building the Catalogs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Adding File Types to the Indexing Process . . . . . . . . . . . . . . . . . . . . . . . . . . .
The Architecture of Index Updates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Word Lists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Shadow Indexes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Master Merge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Balancing Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Index Builds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Full Update . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Incremental Update . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
xv
545
547
549
552
553
554
554
561
567
568
573
574
577
579
579
580
580
582
582
583
585
585
586
586
587
588
589
593
594
595
596
596
596
596
597
597
598
xvi
Contents
Incremental (Inclusive) Update . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Adaptive Update . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Frequency of Updates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Starting an Update . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Updates and Permissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
The Gatherer Log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Viewing Gatherer Logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Saving Gatherer Logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Index Propagation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Preparing for Propagation of an Index . . . . . . . . . . . . . . . . . . . . . . . . . . .
Security During Propagation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Propagating a SharePoint Portal Server 2003 Content Index. . . . . . . . . . .
Stopping the Propagation of a Content Index . . . . . . . . . . . . . . . . . . . . . .
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
22
Managing External Content in Microsoft Office SharePoint
Portal Server 2003
Advanced Search Administration Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Creating and Managing Content Sources. . . . . . . . . . . . . . . . . . . . . . . . . . . .
Default Content Sources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Creating a New Content Source . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Crawling Web Content Sources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Managing Rules for Including or Excluding Content. . . . . . . . . . . . . . . . . .
Working with Content Indexes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Creating a Content Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Editing the Properties of a Content Index . . . . . . . . . . . . . . . . . . . . . . . .
Managing Content Indexes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Managing and Editing Search Scopes and Source Groups . . . . . . . . . . . . . . .
Adding a Search Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Using Search Scopes from Other Portal Sites . . . . . . . . . . . . . . . . . . . . .
Windows SharePoint Services Search and MSSearch . . . . . . . . . . . . . . . . . . .
The Topic Assistant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Manage Crawls of Site Directory. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Manage Keywords and Best Bets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
End-User Experience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Crafting the Result Set Using the Thesaurus . . . . . . . . . . . . . . . . . . . . . .
Attribute Mapping for Advanced Search. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
600
600
601
601
602
602
602
603
603
603
604
604
604
605
607
608
609
611
612
614
615
617
617
619
619
621
622
622
623
623
623
624
625
625
628
628
Contents
23
Personalization Services in SharePoint Products and Technologies
xvii
629
User Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 630
Adding User Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 631
Importing User Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 632
LDAP Search Filters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 637
Managing User Profile Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 638
Audiences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 640
Managing Audiences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 640
Compiling Audiences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 641
Viewing Audience Membership . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 642
Managing Audience Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 643
Show Targeted Items to Portal Site Users . . . . . . . . . . . . . . . . . . . . . . . . 644
Personal Sites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 647
Personal Site Views. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 647
Personal Site Navigation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 648
Private View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 648
Public View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 650
Managing Personal Sites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 651
Portal Site Alerts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 653
Manage Portal Site Alerts Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 656
SharePoint Site Alerts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 658
Troubleshooting Alerts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 659
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 660
24
Information Security Policies for SharePoint Products
and Technologies
Password Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Personal Use of Sites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Information Storage Policies. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Administrative Policies. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Logging Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Authorized Web Parts and Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Change Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Information Privacy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Data Classification Schemes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Extranet Considerations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
661
662
664
665
666
666
667
667
668
669
670
670
xviii
Contents
Part VIII
25
Securing SharePoint Products and Technologies
Firewall Considerations for SharePoint Portal Server Deployments
ISA Server 2000 Web Publishing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Assumptions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Setting Up a Web Publishing Rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
SSL Bridging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Configuring Link Translation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Delegation of Basic Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
ISA Server 2000 Server Publishing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Setting Up a Server Publishing Rule . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
26
Single Sign-On in SharePoint Portal Server 2003
Single Sign-On Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
How Single Sign-On Works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Security Recommendations Regarding the Topology of the Server Farm . . .
Configuring Single Sign-On . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Step 1: Set Up Single Sign-On Accounts . . . . . . . . . . . . . . . . . . . . . . . . .
Step 2: Enable the Single Sign-On Service on the Job Server . . . . . . . . . .
Step 3: Configure the Single Sign-On Settings on the Job Server. . . . . . . .
Step 4: Create an Application Definition . . . . . . . . . . . . . . . . . . . . . . . . .
Step 5: Provide Account Information for an Application Definition . . . . . . .
Step 6: Enable the Single Sign-On Service on the Front-End
Web Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Managing Single Sign-On . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Editing an Application Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Deleting an Application Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Managing Account Information for an Application Definition . . . . . . . . . . .
Creating the Encryption Key . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Backing Up the Encryption Key . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Restoring the Encryption Key . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Enabling Auditing for the Encryption Key . . . . . . . . . . . . . . . . . . . . . . . . .
Disabling the Single Sign-On Service. . . . . . . . . . . . . . . . . . . . . . . . . . . .
Creating a Web Part That Uses Single Sign-On. . . . . . . . . . . . . . . . . . . . . . . .
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
673
674
676
677
680
685
687
689
690
691
693
694
695
697
697
698
702
702
704
706
707
707
707
708
709
711
712
713
714
715
716
722
Contents
27
Securing an Extranet Using SSL and Certificates
Enabling SSL for a SharePoint Portal Server 2003 . . . . . . . . . . . . . . . . . . . . .
Troubleshooting. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Obtaining and Installing the Certificate Authority Root . . . . . . . . . . . . . . .
Common Name Does Not Resolve . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Certificate Is Not Trusted . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Inheritance Overrides Not Accepted . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Home Page of the Portal Site Does Not Appear . . . . . . . . . . . . . . . . . . . .
Portal Site or Test Page Fails to Display on One or More
Front-End Web Servers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Part IX
28
xix
723
724
742
742
744
744
744
745
747
747
Maintaining a Server in Windows SharePoint Services
Disaster Recovery in SharePoint Products and Technologies
Backup and Restore Utilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
General Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
The Stsadm.exe Utility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
The SharePoint Migration Tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
SharePoint Portal Server Data Backup and Restore Utility . . . . . . . . . . . .
The SPBackup.exe Utility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
SAN Snapshoting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Recovering SharePoint Sites and Personal Sites . . . . . . . . . . . . . . . . . . . . . .
Backing Up Site Collections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Restoring Site Collections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Backing Up and Restoring Personal Sites . . . . . . . . . . . . . . . . . . . . . . . .
Recovering Individual SharePoint Sites . . . . . . . . . . . . . . . . . . . . . . . . . .
Recovering Portal Sites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Restoring the Backward-Compatible Document Library . . . . . . . . . . . . . . . . . .
Recovering Different Types of Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Backing Up and Restoring Front-End Web Servers . . . . . . . . . . . . . . . . . .
Backing Up and Restoring Search Servers. . . . . . . . . . . . . . . . . . . . . . . .
Backing Up and Restoring Index Management Servers . . . . . . . . . . . . . . .
Backing Up Databases by Using SQL Server Backup Tools . . . . . . . . . . . .
Recovering Different Server Topologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Hot Server Farm Swapping via SQL Log Shipping . . . . . . . . . . . . . . . . . . .
Troubleshooting a Single-Server Restore . . . . . . . . . . . . . . . . . . . . . . . . .
Recovering a Server Farm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Repairing SharePoint Portal Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Uninstalling SharePoint Portal Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Writing a Disaster Recovery Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Best Practices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
751
752
752
752
753
755
758
758
759
759
760
761
762
763
766
767
767
771
771
772
774
775
778
779
781
782
782
783
786
xx
29
Contents
Usage Analysis Tools in SharePoint Products and Technologies
Managing Usage Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Analyzing Website Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Internet Information Services (IIS) Logs . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Configuring the Log Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Setting Up Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Viewing Website Reports Using FrontPage . . . . . . . . . . . . . . . . . . . . . . . . . . .
Troubleshooting. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
30
Default Tools to Customize Windows SharePoint Services
Customizing Web Part Pages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Shared View vs. Personal View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Web Part Page Zones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Web Part Page Creation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Security for Web Parts and Web Part Pages . . . . . . . . . . . . . . . . . . . . . . .
Other Customizations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Serverwide Configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Site-Level Customization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
List and Library Configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Remove !New Tag from New Items . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Themes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Areas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
31
Working with Web Parts
Basic Customization of Dynamic Web Parts . . . . . . . . . . . . . . . . . . . . . . . . . .
Appearance Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Layout Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Advanced Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Custom Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Adding New Web Parts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Browse and Search . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Import . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Purpose and Use of Each Built-In Web Part . . . . . . . . . . . . . . . . . . . . . . . . . .
<Site Name> Gallery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Online Gallery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Connecting Web Parts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
787
788
792
794
795
795
795
798
798
799
800
801
802
804
808
811
811
813
815
815
816
817
817
819
820
823
824
825
827
828
828
829
830
830
836
837
Contents
Managing Settings for Web Part Pages . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Working with Web Part Galleries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Web Part Page Gallery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
<Site Name> Gallery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Virtual Server Gallery. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Online Gallery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Web Part Assembly Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
32
Using Microsoft Office FrontPage 2003 to Customize
SharePoint Products and Technologies Sites
SharePoint Products and Technologies Fundamentals . . . . . . . . . . . . . . . . . .
Web Parts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Lists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Areas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Personal Sites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Views . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Browser-Based Customization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
How to Edit Sites in FrontPage 2003. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Opening a Site . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Becoming Familiar with FrontPage 2003 . . . . . . . . . . . . . . . . . . . . . . . . .
Instant Updates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Caveats to Editing SharePoint Portal Server Sites in FrontPage 2003 . . . . . . .
Web Part Display . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Moving or Backing Up Websites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Working with Areas and Sub-Areas . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Editing Personal Sites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Changing Styles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
FrontPage 2003 Features Disabled when Editing
a SharePoint Portal Server 2003 Site . . . . . . . . . . . . . . . . . . . . . . . . . . .
FrontPage 2003 Features to Understand when Editing
a SharePoint Portal Server 2003 Site . . . . . . . . . . . . . . . . . . . . . . . . . . .
Additional FrontPage 2003 Features that Can Be Disabled when
Editing a SharePoint Portal Server 2003 Site . . . . . . . . . . . . . . . . . . . . .
Most Common Changes Made in FrontPage 2003 . . . . . . . . . . . . . . . . . . . . .
Web Page Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Lists and Document Library Views . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
xxi
838
839
839
840
843
843
845
848
849
850
850
850
850
851
851
851
852
852
852
854
855
855
856
856
856
856
857
858
860
861
864
864
867
xxii
Contents
Advanced Customization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Repeating the Same Content on Multiple Pages . . . . . . . . . . . . . . . . . . .
Advanced Find and Replace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Themes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Image Tracing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Adding Effects to Your Pages with Behaviors . . . . . . . . . . . . . . . . . . . . . .
Layers (Absolute Positioning) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Working with the Data Source Catalog . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Adding a Data Source . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Referencing External Catalogs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Searching for Data Sources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Deleting Data Sources. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Working with Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Data Views . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Adding a Data View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Formatting the Data View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Grouping, Filtering, and Sorting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Working with Hierarchies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Windows SharePoint Services-Based Lists as Data Views. . . . . . . . . . . . . . . .
Using Reports to Measure Site Use and Performance . . . . . . . . . . . . . . . . . .
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
33
The Windows SharePoint Services Object Model
Microsoft.SharePoint Namespace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
The SPSite Class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Microsoft.SharePoint.Administration Namespace . . . . . . . . . . . . . . . . . . . . . .
The AddWPPack Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
The EnumWPPack Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
The Log Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Microsoft.SharePoint.Dsp Namespace . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Microsoft.SharePoint.Meetings Namespace . . . . . . . . . . . . . . . . . . . . . . . . .
The SPMeeting Class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Microsoft.SharePoint.Security Namespace . . . . . . . . . . . . . . . . . . . . . . . . . .
The SharePointPermission Class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Microsoft.SharePoint.SoapServer Namespace . . . . . . . . . . . . . . . . . . . . . . . .
The Alerts Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Microsoft.SharePoint.Utilities Namespace . . . . . . . . . . . . . . . . . . . . . . . . . . .
The SPProperty Bag Class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
The SPEncode Class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
879
879
881
882
887
888
888
889
889
900
901
902
902
902
904
906
914
917
920
923
924
925
926
926
926
927
928
929
929
930
931
931
933
933
934
934
935
935
Contents
Microsoft.SharePoint.WebControls Namespace . . . . . . . . . . . . . . . . . . . . . . .
The SPControl Class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
The FormDigest Control Class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Adding a FormDigest Control Programmatically . . . . . . . . . . . . . . . . . . . .
Adding an AdminFormDigest Control . . . . . . . . . . . . . . . . . . . . . . . . . . . .
The Theme Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Microsoft.HtmlTrans.Interface Namespace . . . . . . . . . . . . . . . . . . . . . . . . . .
Using the Microsoft.HtmlTrans.Interface Namespace . . . . . . . . . . . . . . . .
Implementing Custom Document Conversion. . . . . . . . . . . . . . . . . . . . . .
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
34
The SharePoint Portal Server Object Model
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
The Microsoft.SharePoint.Portal Namespace . . . . . . . . . . . . . . . . . . . . . . . . .
Microsoft.SharePoint.Portal.Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Microsoft.SharePoint.Portal.UserProfiles . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Microsoft.SharePoint.Portal.WebControls . . . . . . . . . . . . . . . . . . . . . . . . . . .
Other Namespaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
35
Building Applications Using Windows SharePoint Services Data
Using Windows SharePoint Services Components . . . . . . . . . . . . . . . . . . . . .
Sharing Windows SharePoint Services Component Data. . . . . . . . . . . . . .
Sharing Windows SharePoint Services Component Data with ASP.NET . . . . . . .
The Business Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
The Technical Requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
The Sample Setup Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
36
Building Applications for Microsoft Office SharePoint
Portal Server 2003
SharePoint Portal Server Web Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Visual Studio .NET Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
AreaService Web Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Search Web Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
UserProfileService Web Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
xxiii
936
936
936
937
938
938
938
939
940
940
941
941
942
942
943
948
949
950
951
951
952
952
952
953
953
986
987
987
988
989
992
996
999
xxiv
37
Contents
Using Visual Studio .NET to Create Web Parts
1001
Web Part Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Web Parts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Placing Web Parts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Web Part Pages. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Web Part Page Rendering. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Web Part Rendering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Page States Explained . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Strong-Naming Assemblies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Code Access Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Creating a Web Part. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Deploying a Web Part. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Debugging Web Parts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Using the CallStack Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Using Tracing in ASP.NET . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Creating Child Controls on a Web Part. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Web Part Caching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Web Part Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Part X
38
Microsoft Office 2003 Integration with SharePoint
Products and Technologies
Windows SharePoint Services with the Microsoft Office System
1027
Windows SharePoint Services and Microsoft Office Integration Features . . . .
Microsoft Office Access 2003 Integration . . . . . . . . . . . . . . . . . . . . . . . . . .
Microsoft Office Excel 2003 Integration . . . . . . . . . . . . . . . . . . . . . . . . . . .
Integration with Outlook . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Integration with FrontPage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
WYSIWYG XSLT Web Editor. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
39
1001
1001
1002
1002
1003
1004
1004
1005
1007
1011
1013
1015
1017
1018
1018
1020
1022
1023
Using Microsoft Office InfoPath with SharePoint Products
and Technologies
1028
1029
1030
1031
1032
1033
1036
1037
InfoPath Form Templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Form Libraries. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Creating a Form Library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Modifying an Existing Form Library . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Creating and Modifying a Form Library View. . . . . . . . . . . . . . . . . . . . . .
Working with Forms in the Form Library . . . . . . . . . . . . . . . . . . . . . . . . .
1038
1042
1043
1049
1050
1053
Contents
xxv
Merging Forms in a Form Library. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Relinking a Form to Its Form Library . . . . . . . . . . . . . . . . . . . . . . . . . . .
Deploying Fully Trusted Forms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Submitting a Form Programmatically . . . . . . . . . . . . . . . . . . . . . . . . . . .
Integrating InfoPath Forms with Web Services for SharePoint Portal Server . . .
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
40
Microsoft Outlook 2003 Integration with SharePoint
Products and Technologies
1067
Viewing SharePoint Products and Technologies Data in Outlook . . . . . . . . . .
Folder Home Pages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Linking Events and Contacts in Outlook 2003 . . . . . . . . . . . . . . . . . . . .
Transferring Outlook Data to a SharePoint Site . . . . . . . . . . . . . . . . . . . . . .
Creating a New List from Outlook Data . . . . . . . . . . . . . . . . . . . . . . . . .
Importing Outlook Data from the Address Book . . . . . . . . . . . . . . . . . . .
Document and Meeting Workspace Sites . . . . . . . . . . . . . . . . . . . . . . . . . .
Controlling Where a User Can Create Workspace Sites. . . . . . . . . . . . . .
Working with Meeting Workspace Sites from Outlook . . . . . . . . . . . . . . .
Working with Document Workspace Sites from Outlook . . . . . . . . . . . . .
Managing Alerts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Managing Integration Features in Outlook . . . . . . . . . . . . . . . . . . . . . . . . . .
Additional Outlook Integration Opportunities . . . . . . . . . . . . . . . . . . . . . . . .
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Part XI
41
1054
1057
1058
1062
1064
1066
1068
1068
1070
1073
1074
1074
1076
1076
1077
1081
1082
1082
1086
1086
Upgrading and Migrating to SharePoint Products
and Technologies
Integrating Exchange Server 2003 with SharePoint
Products and Technologies
1089
Using the Exchange Web Parts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Configuring the Exchange Web Parts . . . . . . . . . . . . . . . . . . . . . . . . . . .
Understanding the Two OWA Modes . . . . . . . . . . . . . . . . . . . . . . . . . . .
Displaying Exchange Data in a Page Viewer Web Part . . . . . . . . . . . . . . . . . .
Creating an E-Mail-Enabled Document Library . . . . . . . . . . . . . . . . . . . . . . .
Configuring the Exchange Public Folder . . . . . . . . . . . . . . . . . . . . . . . . .
Configuring Windows SharePoint Services . . . . . . . . . . . . . . . . . . . . . . .
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1090
1091
1092
1093
1094
1095
1095
1097
xxvi
42
Contents
Upgrading and Migrating to SharePoint Products
and Technologies
1099
Migration Strategies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Upgrading a SharePoint Team Services Website
to Windows SharePoint Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Step 1: Backing Up the SharePoint Team Services Websites . . . . . . . . .
Step 2: Restoring the Windows SharePoint Team Services Website . . . . .
Upgrading to SharePoint Portal Server 2003 . . . . . . . . . . . . . . . . . . . . . . . .
Upgrading Web Parts to the Microsoft .NET Framework. . . . . . . . . . . . . .
Migrating SharePoint Portal Server 2001 Document Library
Information to Windows SharePoint Services . . . . . . . . . . . . . . . . . . . . .
Migration Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1101
1103
1107
1109
1114
1120
1124
1131
1132
Glossary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1133
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1143
Acknowledgments
Principle Author
Bill English
Contributing Authors
Jason Ballard, Todd Bleeker, Margiet Bruggeman, Nikander Bruggeman, Penny Coventry,
James Edelen, Olga Londer, Rebecca Monson, Sue Mosher, Bogdin Odulinski, Bud
Ratliff, Kim Simmons, Chad Solomonson, and David Sterling
Microsoft Press
Acquisitions Editor: Martin DelRe
Acquisitions Editor: Hilary Long
Project Editor: Valerie Woolley
Development Editor: Maureen Zimmerman
Copyeditors: Roger LeBlanc and Lisa Pawlewicz
Technical Editors: Mark Harrison and Gary A. Bushey
Product Team User Assistance
Emily Schroeder, Crystal Thomas, Maria Hristova, Jo Sawyer, and Hannah Love
Product Team Manager
Adam Rosenblatt
Product Team Reviewers
Brad Stevenson, Eric Heino, Michael Herman, Dustin Friesenhahn, Sissie Hsiao,
Anne Archambault, Dmitriy Meyerzon, Bill Griffin, David Taylor, Dan McPherson,
Reza Dianat, Scott Fynn, Steve Gruman, Dan Hamersley, Jimi Ibbitt, Frank Poloney,
Louise Reneau, Clint Covington, Howard Crow, Andrew Datars, Suraj Poozhiyil,
Venky Veeraraghavan, Julie Madhusoodanan, Markus Klein, Brenda Carter, Jorgen
Bergstrom, Bob Lee, Scott Kendall, KC Lemson, Suraj Poozhiyil, Fitzmaurice Lindhorst,
Maurice Prather, Bryan Jeffries, David Vierzba, Greg Foltz, Lana Fly, Noah Chen, Les
Smith, Edson Reyes, Shaofeng Zhu, David Mead, Andrew Miller, Michael Herzfeld,
Scott Rubie, Douglas Tsang, Ryan Phillips, Syeb Muneeb-ul-Haq, Kimmo Forss, Troy
Starr, Dominik Paiha, Alfredo Almada-Mireles, Anne Reese, Anthony Petro, Bryant
Fong, Christopher Hall, Dean Justus, Edson Reyes, Frank Delia, Gabe Bratton, Geno
White, Alex Hankin, Iyaz Allah Baksh, James Scott, James Sturns, Ken Bullock,
Kerry Landen, Kristen Heller, Mark Grossbard, Michael Herman, Naganandhini
Kohareswaran, Nigel Bridport, Pam Kessey, Raymond Hung, Rob Giesel, Robin
Luft-Kite, Sheng Zhou, Shunri Guo, Stephen Young, Steve Peshka, Thomas Rizzo,
Titus Miron, Todd Young, Jason Ma, Xuhao He, Vijay Krishna, Troy Star, Greg Foltz,
xxvii
xxviii
Acknowledgments
Shawn Baden, Mike Brotherton, Paul Bishop, Sarah Minahan, Dan Cui, Kappu Jaykumar, Daren Miller, Keith Bankston, Anuraag Tiwari, Rodrigo Lode, Jared McElwee,
Lana Fly, Michael Magondo, Bob Samer, Tom Constantino, Neelima Jain, Tamara
Williams, Syed Munee-ul-Haq, Kasey Quanrud, Vivek Srinivasan, Osama Hamden,
Mike VandeKerkhof, Sarah Stewart, and Jesse Bedford
PAG Document Writers and Editors
Dan Hamersley, Frank Poloney, Louise Reneau, Steve Gruman, Reza Dianat, Jimi
Ibbitt, Scott Fynn, Alix Mae Hughes, Todd Young, Ben Moebius, Brian Hitchcock,
Carola Klass, William Jones, Robert Marcus, Garry Gross, Jill Going, Ronen Yacobi,
and Scott St. Jean
Resource Kit Tools Editors
Margriet and Nikander Bruggeman
Tools Contributors
Daniel Witriol, Robert Silver, Chris Marshall, Naganandhini Kohareswaran, Daniel
James, Maurice Prather, James Edelen, Thomas Rizzo and Renaud Comte.
Acknowledgments
The book that you now hold in your hands is the result of the collective effort of
many, many people from July 2003 to April 2004. Even though my name is on the
cover, believe me when I say that without the efforts of everyone listed in this
acknowledgments section, you would not be holding a resource kit right now.
This is the ninth book project I’ve worked on in the last three and a half years
and it has been, by far, the most comprehensive and most enjoyable (no offense to
my other co-authors on the other books!). In addition, it has been the most humbling
and rewarding project too. Getting out 1800 pages of content on a new, exciting
software product that is (quite literally) changing how we do business is a rare
opportunity and I’ve thoroughly enjoyed it. There are several people in particular
who I’d like to acknowledge individually because they played such a pivotal role in
either envisioning or seeing this project through to completion.
I’d like to start by thanking Martin DelRe from Microsoft Press, who initially
approached me in June of 2003 about doing this book project. He had the vision
and energy to get this ball rolling, both with an author like myself and with the product team. In addition, he navigated the book through the Microsoft Press approval
process and gained the necessary signatures to get this project in motion. Martin,
thanks for all your work on the front end of this project. I’ll be forever grateful to
you for your vision and assistance in getting this project off the ground.
Secondly, I’d like to thank Neil Salkind from StudioB, my agent, who did an
excellent job in helping me work with all the co-authors and with Microsoft Press to
ensure the contracts were in place to make this a reality. He also offered me some
great advice at key points during this project and I’m grateful for his assistance. As
usual, Neil, you did an outstanding job.
Acknowledgments
xxix
I’d also like to thank my co-authors for turning in some really great chapters.
There were more than a few times, when I was reading through their chapters, that
I’d think “Wow, I like this!” or “Man, this is good stuff!”. It has been a real treat to work
with all of you and I’d like to tip my hat to you for writing some very good content.
The product team had significant input into both the outline and the content.
In fact, each chapter in the book was reviewed by at least one member of either
(and often both) the SharePoint Portal Server team and/or the Windows SharePoint
Services team. In addition, each team had their own editors who reviewed the chapters for terminology and overall flow. More than a few mistakes and technical inaccuracies were caught and more than a few of the product team members made
themselves available for personal interviews to help us understand the technology in
areas where it wasn’t well documented. These members answered e-mails and
endured (at times) our endless stream of questions with grace and patience. Other
product team members were “looped in” to answer specific questions and their
cooperation was deeply appreciated. To each of you on the product teams, thank
you for your input and assistance.
On the SharePoint Portal Server team, I’d like to thank Adam Rosenblatt for his
willingness to look at this project and navigate it through the product team hierarchy
for their approval and support. Without Adam’s help and support, this resource kit
would not be a reality today. Thanks, Adam, for working with Microsoft Press and
for supporting this project the way you did.
Also, I’ve communicated with Emily Schroeder, Crystal Thomas, Hannah Love
and Maria Hristova on a (nearly) daily basis for the last six months. I think they’re
glad they’re not receiving more e-mails from me! But they were the product team
point people who ensured the chapters were passed through the product team
members in a timely fashion and as well as making sure the terminology was correct. Their help and input was invaluable and much of what you see is a direct result
of their efforts. To all four of you, thank you so much for adding high value to the
final product.
At Microsoft Press, Valerie Woolley was our main project editor and she was
tasked with worrying about whether this book was going to be finished on time
<grin> and keeping me going with my authors. Hilary Long ensured that the production schedule was on time to get the book into print as fast as possible. Both
were gracious in working with the common life events that tend to push deadlines
out. Thanks for your patience and professionalism. I’ve enjoyed working with you
two and hope to do it again on another book.
Back here in Minnesota, my wife Kathy has really put up with more than a wife
should. Writing (and editing) a book is time consuming and she’s endured me
working evenings and weekends–more than I should have. Kathy, thanks for being
a great wife, friend and life-long companion. And to David and Anna, my two children, you two give me more joy and meaning in my life than you know right now.
And I’m looking forward to teaching you guys how to ski and tube this summer!
xxx
Acknowledgments
I’d also like to thank several friends of mine whom I’ve grown to love: Mark
and Marcia Schneider, Jay and Dawn Herman, Dave and Merle McGauvran and Rolf
and Sandy Engwall. Your friendship, prayers and support have enabled me to keep
going when things were tough last year. Life’s greatest fulfillments are found in personal relationships and I’ve been blessed by God to have you all in my life.
Contacting the Author
I’ve always made it a policy to have an “open door” to those who purchase books
that I’ve worked on. This one is no exception. If you’d like to contact me, you are
welcome to do so by e-mailing me at [email protected] or by visiting my
company’s web site at www.mindsharp.com. My (virtual) door is always open and
while I might not respond as quickly as I’d like (I do travel quite a bit), I will try to
respond within 72 hours of receiving your e-mail.
Sincerely,
Bill English
MCSE, MCSA, MCT, MVP
Nowthen, Minnesota
April 2004
Part I
Introduction to
SharePoint Products
and Technologies
In this part:
1
Introduction to Microsoft SharePoint Products and Technologies . . . . . . . . . . . . . . 3
2
Installing Windows SharePoint Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3
Installing Microsoft Office SharePoint Portal Server 2003 . . . . . . . . . . . . . . . . . . 53
Chapter 1
Introduction to Microsoft
SharePoint Products and
Technologies
In this chapter:
Comparison of Features in Windows SharePoint Services
and SharePoint Portal Server 2003. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Main Design Goals for SharePoint Products and Technologies . . . . . . . . . . . 6
Architecture and Design Decisions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Important Features and Terminology Used in SharePoint
Products and Technologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Site Administration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Document and Content Storage. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Organizing Documents and Other Content . . . . . . . . . . . . . . . . . . . . . . . . . 19
Search Configuration and Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
SharePoint Team Services 1.0 from Microsoft and Microsoft SharePoint Portal Server
2001 were the original versions of Microsoft SharePoint Products and Technologies,
released in 2001. SharePoint Team Services addressed the Web-based sharing and
communication needs of teams and team websites, and SharePoint Portal Server
2001 addressed the document collaboration, Web portal, and enterprise search
requirements of a portal solution. To deliver these features, Microsoft used the best
available (but different) technology platforms to build SharePoint Team Services and
SharePoint Portal Server 2001.
3
4
Part I: Introduction to SharePoint Products and Technologies
Based on customer feedback and the experience of developing the 2001 version of SharePoint Products and Technologies, Microsoft designed the next generation of SharePoint Products and Technologies to use a common set of Microsoft
Windows Server 2003 services named Microsoft Windows SharePoint Services. This
set of services takes advantage of the performance, stability, and security features of
the Microsoft .NET Framework. You can use Windows SharePoint Services to create
and maintain many team sites. The following applications are based on Windows
SharePoint Services:
■
SharePoint Portal Server 2003
■
Document Workspace sites in Microsoft Office 2003
■
Meeting Workspace sites in Office 2003
■
Third-party developed solutions and Microsoft customer-developed solutions
SharePoint Portal Server 2003 is a server product that adds features you can use
to build and manage integrated, large-scale portal solutions on top of Windows
SharePoint Services.
Windows SharePoint Services is a collection of services for Microsoft Windows
Server 2003 that you can use to share information, collaborate with other users on
documents, and create lists and Web Part pages. You can also use Windows SharePoint Services as a development platform to create collaboration applications and
information-sharing applications.
SharePoint Portal Server 2003 is a scalable, enterprise portal server that is built
on Windows SharePoint Services. You can use SharePoint Portal Server 2003 to
aggregate Windows SharePoint Services sites, information, and applications in your
organization to a single portal. In addition to the features of Windows SharePoint
Services, SharePoint Portal Server 2003 includes the following features:
■
News and topics
■
My Site, with personal views and with public views
■
Information that can be targeted to specific audiences
■
Index functionality and search functionality across file shares, across Web
servers, across Microsoft Exchange Public Folders, across Lotus Notes, and
across Windows SharePoint Services sites
■
Alerts that notify you when changes are made to relevant information, documents, or programs
■
Single sign-on functionality for enterprise application integration
■
Integration with Microsoft BizTalk Server
Chapter 1: Introduction to Microsoft SharePoint Products and Technologies
5
Comparison of Features in Windows SharePoint
Services and SharePoint Portal Server 2003
Table 1-1 compares the features of Windows SharePoint Services and SharePoint
Portal Server 2003.
Table 1-1
Feature Comparisons Between Microsoft Office SharePoint Portal
Server 2003 and Windows SharePoint Services
Feature
Windows SharePoint SharePoint Portal
Services
Server 2003
Alerts
Yes
Yes
Browser-based customization
Yes
Yes
Discussion boards
Yes
Yes
Document libraries
Yes
Yes
Document Workspace
Yes
Yes
Meeting Workspace
Yes
Yes
Lists
Yes
Yes
BizTalk integration
No
Yes
Microsoft FrontPage 2003 integration
Yes
Yes
Microsoft InfoPath 2003 integration
Yes
Yes
Surveys
Yes
Yes
Templates
Yes
Yes
Web Part pages
Yes
Yes
Automatic categorization
No
Yes
Audiences
No
Yes
Topic areas
No
Yes
News
No
Yes
Personal sites
No
Yes
Shared services
No
Yes
Single sign-on
No
Yes
Site directory
No
Yes
User profiles
No
Yes
By using the combined collaboration features of Windows SharePoint Services
and of SharePoint Portal Server 2003, users in your organization can create, manage, and build collaborative websites and make them available throughout the
organization.
6
Part I: Introduction to SharePoint Products and Technologies
To understand the differences in purpose between SharePoint Portal Server
2003 and Windows SharePoint Services, think of them this way:
■
SharePoint Portal Server 2003 is designed to aggregate information, create a
taxonomy, target content to users, and create personal portals (My Site) for
individual users.
■
Windows SharePoint Services is designed to the place where collaboration
takes place as it relates to content development and team interactions.
Main Design Goals for SharePoint Products
and Technologies
The overall design goal for SharePoint Products and Technologies was to unify and
integrate Windows SharePoint Services as a technology platform on which to build
products such as SharePoint Portal Server 2003. This goal of unification and integration was divided into four areas:
■
Consistent SharePoint Products and Technologies experience for users, developers, and IT professionals
■
Consistency and integration with the .NET Framework
■
Integrated storage strategy
■
Trustworthy Computing Initiative: security and reliability
Consistent Experience for Users, Developers, and IT Professionals
Solution developers who use SharePoint Products and Technologies now need to
know only one user-interface technology (ASP.NET Web pages and controls), one
data storage technology (Microsoft SQL Server), and one SharePoint Products and
Technologies object model to create advanced sharing solutions. Developers can
use their choice of .NET Framework development and database tools to develop,
test, and tune their SharePoint Products and Technologies solutions.
Similarly, network administrators can take advantage of their existing knowledge by using well-known tools and procedures based on Windows Server 2003 and
SQL Server to deploy and manage SharePoint Products and Technologies.
Consistency and Integration with the .NET Framework
The strategy of using the .NET Framework, Web services, Microsoft Visual Studio
.NET, and Windows Server 2003 to build SharePoint Products and Technologies is
part of Microsoft’s technology strategy for connecting people, information, applications, and devices. The first advantage of using the .NET Framework in building
SharePoint Products and Technologies is that it is the most scalable, flexible, and
Chapter 1: Introduction to Microsoft SharePoint Products and Technologies
7
secure foundation for building, deploying, and managing enterprise Web applications. SharePoint Products and Technologies workspaces and portal sites share these
attributes as a result of this integration with the .NET Framework. Additionally, integrating SharePoint Products and Technologies with information from virtually any
enterprise application is easy with the support for Web services included in the .NET
Framework.
Integrated Storage Strategy
The long-term strategy for storage technology at Microsoft is for SQL Server technology to become the single repository for absolutely everything. Except for the fulltext search indices created by Microsoft Search technologies and certain pages that
are stored in the files system on front-end Web servers as a performance enhancement, all content, configuration information, and other SharePoint Products and
Technologies data is stored in SQL Server databases. Using a single, consistent, integrated data storage platform creates significant advantages for IT professionals and
developers by increasing their productivity and reducing their day-to-day development, deployment, and management costs.
Trustworthy Computing Initiative: Security and Reliability
The secure, reliable operation of everyday computer systems is at the heart of the
Trustworthy Computing Initiative at Microsoft. All new Microsoft products, including
SharePoint Products and Technologies, adhere to these Trustworthy Computing initiatives. Developers at Microsoft have extensive software security training and apply
their knowledge by performing security audits of each Microsoft software component that they are responsible for. Furthermore, the development teams for SharePoint Products and Technologies groups took advantage of the built-in security and
reliability of Windows Server 2003 and the .NET Framework when they designed,
implemented, and tested the new version of SharePoint Products and Technologies.
Architecture and Design Decisions
SharePoint Portal Server 2003 and Windows SharePoint Services require advanced
planning to be successfully deployed. We’ll discuss several planning issues in depth,
including taxonomy planning (in Chapter 8, “Planning Your Information Structure
Using Microsoft Office SharePoint Portal Server 2003”) and writing information security policies (in Chapter 24, “Information Security Policies for SharePoint Products
and Technologies”). In this section, we’ll outline some high-level decisions that need
to be addressed as part of your SharePoint Products and Technologies deployment.
8
Part I: Introduction to SharePoint Products and Technologies
Integrated Storage
SharePoint Team Services used a hybrid model of Web server, file system, Windows
registry, and SQL Server–based storage to manage documents, lists, views, and configuration information. SharePoint Portal Server 2001 used a document store based
on the Microsoft Web Storage System (the same storage technology used by
Microsoft Exchange Server) for most data storage requirements. Both of these solutions required content to be stored on the same server that hosted the Web portal.
This requirement limited the range of deployment scenarios and scalability.
These storage solutions served the 2001 version of SharePoint Products and
Technologies well. However, these storage solutions did not support the additional
requirements for administration, management, performance, scalability, and functionality that were needed in the next generation of SharePoint Products and Technologies. For example, backup and restore operations are difficult to implement and
manage when the relevant data is spread out among many storage systems on the
server.
Windows SharePoint Services stores all documents, lists, views, and configuration information in SQL Server content stores. Because of this, Windows SharePoint
Services offers true enterprise scalability.
SharePoint Portal Server 2003 uses the same SQL Server content store architecture as Windows SharePoint Services. SharePoint Portal Server 2003 also supports
the option of installing backward-compatible document libraries (Web Storage System–based) for document storage. The backward-compatible document libraries are
compatible with SharePoint Portal Server 2001 document approval and routing, and
they support multiple document profiles for each document library folder. With the
backward-compatible document libraries, you can use a phased strategy to migrate
to SharePoint Portal Server 2003.
Note SharePoint Portal Server 2003 requires a SQL Server content store
for managing ASP.NET portal Web pages, lists, views, and configuration
information. Windows SharePoint Services and SharePoint Portal Server
2003 both use SQL Server content stores and require SQL Server or
Microsoft SQL Server Desktop Engine (MSDE). SQL Server is a separately
licensed product that is not included with Windows SharePoint Services or
SharePoint Portal Server. MSDE is included with Windows SharePoint Services and with SharePoint Portal Server 2003. For a discussion on the differences in use between MSDE and SQL, please see the two installation
chapters in this resource kit: Chapter 2, “Installing Windows SharePoint
Services,” and Chapter 3, “Installing Microsoft Office SharePoint Portal
Server 2003.”
Chapter 1: Introduction to Microsoft SharePoint Products and Technologies
9
ASP.NET Web Part Pages and Web Parts
SharePoint Products and Technologies now uses Web Part Pages and Web Parts
based on the .NET Framework and ASP.NET. SharePoint Team Services and SharePoint Portal Server 2001 used separate technologies to create and display (render)
SharePoint sites in a Web browser. Web pages in SharePoint Team Services were
based on Microsoft FrontPage and Office Web Server technologies, and Web portal
pages in SharePoint Portal Server 2001 were based on Web Storage System, dashboard, and Web Part technologies.
This version of SharePoint Products and Technologies uses ASP.NET Web Part
Pages to create and display SharePoint sites in a Web browser. You can easily integrate Web Parts with Web services, Office, and BizTalk Server to provide powerful
solutions for work sharing, enterprise applications, and portal sites.
Common Collaboration Management Services
SharePoint Portal Server 2001 was designed to provide document version tracking
and check-in and check-out document collaboration functions. However, SharePoint
Team Services was the solution that large numbers of teams used every day to create, review, approve, and manage their Office documents; to plan and hold meetings; and to track project tasks. Document version tracking and document check-in
and check-out are now included in Windows SharePoint Services, where users need
them the most and where all SharePoint Products and Technologies solutions can
take advantage of these document collaboration functions.
Document collaboration is one of the most valuable end-user features in Windows SharePoint Services, and it is the area in which Microsoft made the most
changes. The following list shows the main differences between the document collaboration functions in SharePoint Portal Server 2001 and the document collaboration functions in Windows SharePoint Services:
■
In SharePoint Portal Server 2001, the document libraries based on the Web
Storage System supported multiple document profiles for each document
library folder. In Windows SharePoint Services, the SQL Server content store
supports one set of properties (the equivalent of one document profile) for
each document library. Because of this, you might want to store the properties
of the most common document profile in the area where it would normally
belong, and then store the documents that use secondary document profiles in
a subarea, using one set of properties for each secondary document profile.
■
SharePoint Portal Server 2001 provided both serial and parallel routing and
approval processes. Windows SharePoint Services now provides a simpler,
one-step moderator approval process.
10
Part I: Introduction to SharePoint Products and Technologies
■
SharePoint Portal Server 2001 provided support for document version tracking
using major and minor version numbers. Windows SharePoint Services and
SharePoint Portal Server 2003 use major version numbers only.
■
SharePoint Portal Server 2001 supported access control at the folder level and
subfolder level (and user and group exclusions at the file level). Windows
SharePoint Services and SharePoint Portal Server 2003 support access control at
the site level and the document library level.
Site Creation and Management Services
To improve support for very large numbers of SharePoint sites in this version of
SharePoint Products and Technologies, Windows SharePoint Services now provides
common site creation and management features, such as site templates and self-service creation of Windows SharePoint Services sites. SharePoint Portal Server 2003
adds the following deployment and management features for large organizations: a
site directory that provides an easy-to-use site registration system, enterprise application integration (EAI) solutions with single sign-on support for third-party applications, dynamically configurable site maps, large-scale server topology management,
and the ability to share multiple index and search servers.
Integrated Search Solution
For full-text content indexing and searching, SharePoint Team Services used the
Microsoft Windows Indexing Service, an early version of Microsoft Search technologies included in Microsoft Windows 2000. When SharePoint Portal Server 2001 was
released, it included an updated enterprise version of Microsoft Search technologies.
Windows SharePoint Services uses the full-text searching features from the latest version of SQL Server. SharePoint Portal Server 2003 uses the latest version of
Microsoft Search services and includes the ability to crawl external content.
Personalization and Audience-Targeted Information and Applications
To help individual users find and use the information and tools they need, a portal
solution must support targeted delivery of content, information, and application
functionality. A portal solution includes targeting information and applications to
individuals, teams, divisions, and entire organizations. It also includes effective support for personalized content and support for group-based portal page content.
Windows SharePoint Services provides personalization by offering shared and
personal views of team sites. SharePoint Portal Server 2003 uses audiences to extend
this service. Audiences are dynamic groups of users that share one or more common
properties (for example, business function, department, or team membership). The
properties that determine audience membership can reside in an enterprise directory such as Microsoft Active Directory or any other SQL Server–based database.
Audiences are used to determine which Web Parts appear on a particular Web page,
and they can also act as a filter for the information displayed in those Web Parts.
Chapter 1: Introduction to Microsoft SharePoint Products and Technologies
11
SharePoint Portal Server 2003 also supports creating and managing personal sites
(My Site) that can become a personal storage and sharing location.
Subscriptions and Alerts
In SharePoint Team Services and SharePoint Portal Server 2001, you could use subscriptions to receive messages when your shared documents were changed. The
name of the subscriptions feature has now changed to alerts. Windows SharePoint
Services and SharePoint Portal Server 2003 both continue to support alerts. Windows
SharePoint Services supports alerts on lists and individual items in lists, and SharePoint Portal Server 2003 builds on this functionality by adding support for alerts on
people, areas, searches, and news alerts.
Simple Single-Server Configurations and Highly Scalable Server
Farm Configurations
SharePoint Team Services and SharePoint Portal Server 2001 were deployed as single-server solutions or as groups of servers, but little support was available for creating and deploying highly scalable server farms. Windows SharePoint Services is
specifically designed to vastly improve performance for each server and to support
deployment in highly scalable server farms using multiple stateless front-end servers
connected to one or more back-end content servers.
Important Features and Terminology Used in
SharePoint Products and Technologies
In addition to understanding the technical design of SharePoint Products and Technologies, you also need to understand the new and changed terminology introduced in SharePoint Products and Technologies.
SharePoint Sites and Site Collections
The terminology used to name the components in SharePoint Products and Technologies varies depending on whether you are an end user, a developer, a Windows
administrator, or a SharePoint Products and Technologies administrator. For SharePoint Products and Technologies end users, the terminology used in the SharePoint
Products and Technologies Web interface is consistent with the long-term goals and
direction for SharePoint Products and Technologies. Some of the terminology for
developers is more consistent with the older SharePoint Team Services object
model. The terminology for Windows administrators and SharePoint Products and
Technologies administrators is a mixture of SharePoint Team Services terminology
and Windows SharePoint Services terminology. Microsoft plans to increase the
consistency of the terminology for developers and administrators in future versions
of SharePoint Products and Technologies.
12
Part I: Introduction to SharePoint Products and Technologies
In SharePoint Team Services, the term for the top-level content directory of a
Web server is root Web site. In a multihosting environment, each virtual Web server
that is configured on the Web server contains one top-level (root Web) site. Additionally, the term for a site within a root website in SharePoint Team Services is
subweb. Subweb is a term adopted from Microsoft FrontPage websites (the original
technology on which SharePoint Team Services was built). You can create multiple
subwebs in a root Web site, and you can create subwebs within other subwebs.
In SharePoint Portal Server 2001, the term for the top-level content directory of
a Web server is workspace. The term for a site within a workspace is subdashboard.
You can create additional subdashboards and personal dashboards for subprojects
and individual users.
In the latest version of SharePoint Products and Technologies, the term site (in
the SDK, the term site is called myweb) replaces the previous terms. There are two
types of SharePoint sites you can use to divide site content into distinct, separately
manageable sites: top-level websites and subsites. A top-level SharePoint site is the
parent site of all sites in a site collection. Top-level websites can contain multiple
subsites, and subsites can also contain multiple subsites, continuing for as many levels as your users require. You can use this hierarchy to create a main subsite for your
entire team and create individual subsites or shared sites for side projects. Top-level
websites and subsites permit different levels of control over site features and settings.
Single-Server Scenario
SharePoint Products and Technologies supports both vertical, single-server solutions and horizontal, server farm solutions. This section describes a single-server
configuration.
One of the minimum system requirements for Windows SharePoint Services is
the Windows Server 2003 operating system. Additionally, you must install and configure Internet Information Services (IIS) and ASP.NET before you install Windows
SharePoint Services. When you install Windows SharePoint Services, it creates and
configures a virtual server named SharePoint Central Administration. Additionally, if
you install Windows SharePoint Services in a single-server configuration, it automatically extends the existing default website that was created when you installed IIS.
Windows IIS websites are also referred to as IIS virtual Web servers, virtual
servers, or v-servers. In addition to the two default IIS virtual servers that are created
when you install Windows SharePoint Services, you can configure as many as nine
end-user virtual servers with separate application pools or 99 end-user virtual servers with a shared application pool on a single Windows Server 2003–based computer. Each IIS virtual server can host multiple SQL Server content stores. (For a
discussion of application pools, please consult the Internet Information Services 6.0
Resource Kit, Microsoft Press 2003.)
Chapter 1: Introduction to Microsoft SharePoint Products and Technologies
13
Each SQL Server content store for SharePoint Portal Server 2003 can contain
only one portal site collection. Each SQL Server content store for Windows SharePoint
Services can contain as many as 50,000 site collections, even if the site collection is
hosted under a SharePoint Portal Server 2003 portal site. These numbers point to
a design that will result in fewer portals but many more team sites in most
deployments.
A site collection is a set of websites that share a common GUID and namespace
and have the same owner and administration settings and that reside on the same
virtual server. Each site collection contains a top-level website and can contain one
or more subsites. A site collection serves as the administrative unit for assigning
users to site groups and for granting security rights to site groups. For more information about site administration, see the next section. You can nest a site within
another site. The term for the nested site is subsite. Each site (and subsite) uses the
same SQL Server content database as its parent site.
In SharePoint Portal Server 2003, the term site collection is the equivalent of the
older term site in SharePoint Team Services. In the new version of SharePoint Products
and Technologies, the term site or SharePoint site is the equivalent to the older term
subweb in SharePoint Team Services. Be careful to avoid confusing the overlapping terminology. Table 1-2 outlines the new terms for SharePoint Products and Technologies.
Table 1-2
New Terms for SharePoint Products and Technologies
SharePoint Products and
Technologies terms
SharePoint Products and
Technologies object
model terms
SharePoint Team Services
terms
Windows IIS Web site
SPVirtualServer
Windows IIS virtual server
Site collection
SPSite
Site
Top-level Web site
SPWeb
Root Web site
Subsite
SPWeb
Child Web site
Site (including top-level
sites and subsites)
SPWeb
Subweb (including root Web
sites and child Web sites)
Subsite collection
SPWebCollection
Subweb collection
Site group
SPRole
Role
Cross-site group
SPGroup
n/a
Cross-site group collection
SPGroupCollection
n/a
Rights mapping for a
principle
SPPermission
n/a
Access control list
SPPermissionCollection
Access control list
Security principle
SPUser
n/a
Security principle collection
SPUserCollection
n/a
Area
Area
Category (SharePoint Portal
Server 2001)
14
Part I: Introduction to SharePoint Products and Technologies
Note If you are a developer, note that the SharePoint Products and Technologies object model uses the (sometimes overlapping) names from
SharePoint Team Services for many of the new SharePoint Products and
Technologies components. Use the preceding table to cross-reference
terms from the old and new naming conventions.
Server Farm Scenario
In a server farm scenario, the terminology remains the same, and the requirement
that all SharePoint sites use the same SQL Server configuration database as the toplevel website remains the same. However, you can use multiple stateless front-end
Web servers to support a large number of user connections and to render ASP.NET
Web pages. Logically located behind these front-end Web servers, a SharePoint
Products and Technologies configuration can use many back-end database servers.
You can use multiple content database servers to support multiple site collections and to provide fault-tolerant failover. Optionally, you can use separate database servers to store the configuration database for server farm configuration maps
and site collection-to-content database maps.
Portal Sites
One of the minimum system requirements for SharePoint Portal Server 2003 is Windows SharePoint Services. When you install SharePoint Portal Server 2003, Setup
automatically installs Windows SharePoint Services if it is not already installed.
You can configure only one portal site for each end-user IIS virtual Web server.
The portal site corresponds to the SharePoint Products and Technologies top-level
website for both the virtual server and the site collection rooted at the virtual server.
Security
The new security features in SharePoint Products and Technologies is described in
this section. Included is an introduction to groups, authorization, and authentication.
Site Groups and Rights
SharePoint Products and Technologies uses a security model based on site groups
and rights. Site groups are groups of users with related security requirements. Security rights are assigned to each security group. You can customize the rights assigned
to these site groups or add new site groups to combine different sets of rights. By
default, Windows SharePoint Services includes the following five site groups:
Chapter 1: Introduction to Microsoft SharePoint Products and Technologies
15
■
Administrator. Members have complete control over a website. They can
configure settings, manage users and site groups, and view usage analysis data.
■
Web Designer. Members can use a SharePoint Products and Technologies–
compatible Web page editor, such as Microsoft Office FrontPage 2003, to customize the website.
■
Contributor. Members can interact with Web Parts, lists, and document
libraries. Additionally, they can create and manage personal views and crosssite groups and personalize Web Part pages.
■
Reader. Members can view items in lists and document libraries, view pages
on the site, and create a site using Self-Service Site Creation.
■
Guest. This group is designed to be combined with specific permissions for
specifics lists so that guest users can have access to a specific list without having
access to the entire site. You cannot customize or delete the Guest site group.
If you use one of the SharePoint Products and Technologies upgrade tools to
create the SharePoint Products and Technologies installation, the upgrade tool
inspects the permissions granted to each role in SharePoint Team Services or SharePoint Portal Server 2001 and uses the permissions granted to each role to assign
users to corresponding SharePoint Products and Technologies site groups. For a
complete list of SharePoint Products and Technologies security rights, see Table 1-3.
Table 1-3
SharePoint Products and Technologies Security Rights
Right
Description
Default site groups
Add and Customize
Pages
Permission to create ASP.NET, ASP,
and HTML pages for a website
Web Designer,
Administrator
Add Items
Permission to add items to lists or
documents to document libraries
Contributor, Web
Designer, Administrator
Add/Remove Personal
Web Parts
Permission to add and remove Web
Parts to personalize Web Part Pages
Contributor, Web
Designer, Administrator
Apply Style Sheets
Permission to apply a style sheet to
the entire website
Web Designer,
Administrator
Apply Themes and
Borders
Permission to apply a theme or
border to an entire website
Web Designer,
Administrator
Browse Directories
Permission to browse the directory
structure of a website
Contributor, Web
Designer, Administrator
Cancel Check-Out
Permission to cancel the check-out
action performed by another user
Web Designer,
Administrator
Create Cross-Site
Groups
Permission to create or delete crosssite groups, or to change membership
of a cross-site group
Contributor, Web
Designer, Administrator
16
Part I: Introduction to SharePoint Products and Technologies
Table 1-3
SharePoint Products and Technologies Security Rights
(continued)
Right
Description
Default site groups
Create Sites and Workspaces
Permission to create a new subsite or
workspace, such as a Document
Workspace or Meeting Workspace
Reader, Contributor, Web
Designer, Administrator
Delete Items
Permission to delete list items and
documents from the website
Contributor, Web
Designer, Administrator
Edit Items
Permission to edit existing list items
and documents in the website
Contributor, Web
Designer, Administrator
Manage Lists
Permission to create, edit, or delete
lists and change their settings
Web Designer,
Administrator
Manage List Permissions
Permission to change permissions for
a list or document library
Administrator
Manage Personal
Views
Permission to create, edit, or delete
personal views on lists
Contributor, Web
Designer, Administrator
Manage Site Groups
Permission to create, delete, and edit
site groups, both by changing the
rights assigned to the site group and
by changing which users are members of the site group
Administrator
Manage Web Site
Permission to perform administration
tasks for a particular site or subsite
Administrator
Update Personal Web
Parts
Permission to update Web Parts to
display personalized information
Contributor, Web
Designer, Administrator
Use Self-Service Site
Creation
Permission to use the Self-Service Site
Creation tool to create a top-level
website
Reader, Contributor, Web
Designer, Administrator
View Items
Permission to view items in lists, documents in document libraries, and
Web discussion comments
Reader, Contributor, Web
Designer, Administrator
View Pages
Permission to browse pages in the
website
Reader, Contributor, Web
Designer, Administrator
View Usage Data
Permission to view reports on website usage
Administrator
Cross-Site Groups, Local Groups, and Domain Groups
Cross-site groups, local groups, and domain groups can be members of site groups.
Cross-site groups are collections of users who can be managed as a single
group across multiple SharePoint Products and Technologies sites. Cross-site groups
are configured in SharePoint Products and Technologies, and they can be members
of a site group.
Chapter 1: Introduction to Microsoft SharePoint Products and Technologies
17
Domain groups and local groups can also be members of site groups. However, cross-site groups and site groups cannot be members of local groups or
domain groups.
Authentication
Authentication is the process of verifying the identity of a user or a process. IIS handles authentication for SharePoint Products and Technologies. To be authenticated,
you need a local user account or a domain user account (if working in a networked
domain). In most cases, a domain account is a better choice than a local account.
You can configure authentication (in a Windows SharePoint Services–only
installation) to operate in either pre-existing account mode or account creation
mode. In pre-existing account mode (also known as Domain Mode), SharePoint
Products and Technologies does not automatically create new user accounts. In
account creation mode, Windows SharePoint Services can automatically create new
user accounts in Active Directory. Account creation mode is a feature you must
select when you install Windows SharePoint Services. This feature is not available in
SharePoint Portal Server 2003 because the default is Domain Mode.
Note If you use account creation mode, make sure that IIS is configured
to use basic authentication. SharePoint Products and Technologies no
longer supports IIS digest authentication.
Authorization
SharePoint Products and Technologies stores all security metadata (groups and
rights) in SQL Server content stores. User security metadata for SharePoint Products
and Technologies is not stored in IIS or anywhere else in Windows. After IIS uses a
local computer account or an Active Directory account to authenticate a user, SharePoint Products and Technologies compares the rights assigned to the user by IIS
with the access control information for the SharePoint site to determine which
SharePoint site resources the user is permitted to use.
Note Active Directory is not required for Windows SharePoint Services or
SharePoint Portal Server 2003 to operate. However, without Active Directory, SharePoint Portal Server cannot prepopulate and synchronize the
SharePoint Portal Server profile database with the list of users from Active
Directory, and users’ personal sites are not registered for cross-farm synchronization in a multiserver configuration. For best results, deploy SharePoint Products and Technologies in an Active Directory environment.
18
Part I: Introduction to SharePoint Products and Technologies
Site Administration
Members of the Administrator site group for a top-level website can control settings
and features for the top-level website and any subsites. For example, an administrator of a top-level website can perform any of the following tasks:
■
Add, delete, or change user permissions
■
View usage statistics
■
Change regional settings
■
Manage Web Part catalogs and template catalogs
■
Manage Web document discussions and alerts
■
Change the name, description, theme, and home-page organization of the site
■
Configure settings (for example, regional settings) for the top-level website and
all subsites
■
Update e-mail settings for the top-level website and all subsites
■
Configure Web Parts settings for the top-level website and all subsites
A member of the Administrator site group for a subsite can control settings and
features only for that particular subsite, and the administrator of a site under that
subsite can control settings and features for only that particular second-level subsite.
For example, an administrator of a subsite can perform any of the following tasks:
■
Add, delete, or change user permissions
■
View usage statistics
■
Change regional settings
■
Manage Web Part catalogs and template catalogs
■
Manage Web document discussions and subscriptions
■
Change the name, description, theme, and home-page organization for the
subsite
Document and Content Storage
SharePoint Products and Technologies supports two types of content stores. The primary store is the SQL Server content store. Based on SQL Server technology, the SQL
Server content store provides a single, consistent data storage solution for document
content, list content, and metadata. You can use common Windows and SQL Server
management tools and development tools to easily manage, tune, back up, and
enhance SQL Server content stores.
Chapter 1: Introduction to Microsoft SharePoint Products and Technologies
19
When you install SharePoint Portal Server 2003, you have the option of installing the backward-compatible document store. The backward-compatible document
store is the Web Storage System–based document store used in SharePoint Portal
Server 2001. The backward-compatible document store is provided for users who
require features from SharePoint Portal Server 2001, such as complex document
routing and approval, folder-level security, minor-level version numbers, and multiple document profiles for each folder.
The primary interfaces for the document collaboration features in SharePoint
Products and Technologies are document libraries, which you can add to any SharePoint site. A document library consists of the virtual folder where the files are stored,
the files themselves, and the user-definable descriptive information (metadata) associated with each item in the document library.
Organizing Documents and Other Content
You can configure each SharePoint site with a document library and a corresponding list component. The list component can display customizable views of the metadata for each document.
With SharePoint Portal Server 2003, you can associate documents and other
content in a site with one or more areas. Areas provide an alternative way to navigate and search content in a SharePoint Portal Server 2003 portal site. Areas are similar to categories in SharePoint Portal Server 2001.
In a SharePoint Products and Technologies configuration that uses only SQL
Server content stores, major version numbers are used to track document revisions
(minor version numbers are not supported). A single-step moderator approval
mechanism is used to approve documents.
Search Configuration and Usage
Windows SharePoint Services keeps all content in SQL Server content stores, and it
uses the Microsoft Search full-text indexing and searching technology from SQL
Server. Because of this, Windows SharePoint Services can only index and search
content in SQL Server content stores.
SharePoint Portal Server 2003 uses the latest version of Microsoft Search technology to index both local and external document collections and websites. It supports all the advanced indexing and searching features from SharePoint Portal Server
2001, with improved performance, scalability, and extensibility. SharePoint Portal
Server 2003 can now index and search millions of documents, and it can support
load-balanced queries across multiple catalog servers.
20
Part I: Introduction to SharePoint Products and Technologies
Summary
Windows SharePoint Services and SharePoint Portal Server 2003 provide easy-to-use
sharing tools for your organization. You can use Windows SharePoint Services to
create and maintain many team sites, and you can use SharePoint Portal Server 2003
to build and manage integrated, large-scale portal solutions.
To achieve this significant increase in capability, performance, stability, and
security, the overall architecture of SharePoint Products and Technologies includes
many significant changes. The most important of these changes are the use of the
.NET Framework, Windows Server 2003, and SQL Server for content storage.
To benefit most from the latest version of SharePoint Products and Technologies, you must be familiar with the changes and new features in SharePoint Products
and Technologies, and you must be familiar with the new, consistent terminology
for SharePoint Products and Technologies. This knowledge can greatly increase
your understanding of both basic and advanced SharePoint Products and Technologies concepts.
In this chapter, we have introduced—at a very high level—Microsoft SharePoint Products and Technologies. The following chapters will further specify and
illustrate how to use SharePoint Portal Server 2003 and Windows SharePoint
Services.
Chapter 2
Installing Windows
SharePoint Services
In this chapter:
Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Installing Windows SharePoint Services on a Single Machine
with WMSDE. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Installing Windows SharePoint Services with SQL 2000 . . . . . . . . . . . . . . . 29
Installing Windows SharePoint Services into a Server Farm . . . . . . . . . . . . 40
Uninstalling Windows SharePoint Services . . . . . . . . . . . . . . . . . . . . . . . . . 48
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
This chapter provides all information required to install Microsoft Windows SharePoint Services in several scenarios. We will cover the following subjects:
■
Prerequisites for installing Microsoft Windows SharePoint Services
■
Installing with Microsoft SQL Server 2000 Desktop Engine (Windows)
(WMSDE)
■
Installing with SQL Server 2000
■
Upgrading from WMSDE to SQL Server 2000
■
Integrating an existing Windows SharePoint Services Installation into a SharePoint Portal Server 2003 portal site
■
Installing Windows SharePoint Services into a server farm
■
Uninstalling Windows SharePoint Services
21
22
Part I: Introduction to SharePoint Products and Technologies
Prerequisites
Before installing Windows SharePoint Services, you should review the requirements
and prerequisites for the product to prevent rework. This section describes the hardware and software requirements for installing Windows SharePoint Services and
then delves into several common application coresidency and configuration issues.
Hardware and Software Requirements
Before you install Microsoft Windows SharePoint Services on your Web server, make
sure that you have installed the required hardware and software, as described in
Table 2-1.
Table 2-1
Windows SharePoint Services Requirements
Item
Minimum Requirement
Server Requirements
Operating System
Microsoft Windows Server 2003
(any version)
Recommended Requirement
Windows Server 2003 (any version) with all Service Packs and
hotfixes applied
CPU
1 CPU running at 550 MHz
2 CPUs running at 1 GHz+
(server farm installation)
RAM
512
1 GB+
Disk Space
500 MB
~500 MB+ per site
File System
NTFS
NTFS
Internet Information Services
6.0 in Worker Process Isolation
Mode with Microsoft ASP.NET
enabled
6.0 in Worker Process Isolation
Mode with Microsoft ASP.NET
enabled
Database
WMSDE or SQL Server 2000 with
Service Pack 3
SQL Server 2000 (in a single
server or server farm configuration) with the most current service packs and patches applied
Browser
Microsoft Internet Explorer 5.01
with Service Pack 2
Internet Explorer 6 with the latest Service Pack and hotfixes
applied
Internet Explorer 5.5 with Service Pack 2
Internet Explorer 6
Netscape Navigator 6.2 or later
Chapter 2: Installing Windows SharePoint Services
Table 2-1
Windows SharePoint Services Requirements
Item
Minimum Requirement
Client Requirements
Browser
Internet Explorer 5.01 with Service Pack 2
Internet Explorer 5.5 with Service Pack 2
23
(continued)
Recommended Requirement
Internet Explorer 6 with the latest Service Pack and hotfixes
applied
Internet Explorer 6
Netscape Navigator 6.2 or later
Internet Explorer 5.2 for Macintosh or later
Office System
Microsoft Office 2000
Microsoft Office System 2003
Note Disk space requirements depend largely on the site’s content and
function. If, for example, the site’s function is to simply list activities for a
team, not much space will be needed. By contrast, if the site stores all the
Microsoft PowerPoint presentations for a sales team, the space requirements would be much larger. Be sure to interview your users, plan according to your unique needs, and build in room to grow.
Extract Windows SharePoint Services Installation Files
If you’ve downloaded the Windows SharePoint Services 2.0 files, you can execute
the Stsv2.exe file to start the Microsoft Windows SharePoint Services Setup program; but, to use any command-line installation options (such as the /datadir or
/remotesql=yes properties) to install Windows SharePoint Services, you will need to
extract the setup files by using a decompression utility such as WinZip or PKZip.
You can also simply type stsv2.exe /c /t:c:\temp at the command line to extract
the files to the c:\temp directory (or another directory of your choosing). Should
you extract the files, use the Setupsts.exe file to install the product.
Install Microsoft Internet Information Services (IIS) 6.0
For Windows SharePoint Services to install, IIS 6.0 must be installed in Worker Process Isolation Mode, and ASP.NET must be installed. You can use the Manage Your
Server Wizard to configure the W2K3 box as an application server, which installs all
necessary components for Windows SharePoint Services. Alternatively, you can
install the IIS and ASP.NET components from Add/Remove Programs.
24
Part I: Introduction to SharePoint Products and Technologies
Warning Avoid installing FrontPage Ser ver Extensions (FPSE) from
Microsoft because this is not a supported configuration when installing Windows SharePoint Services. If you must run FPSE, be aware that you should
install it into another virtual server, and that Windows SharePoint Services
will not automatically extend the Default Web Site.
Windows SharePoint Services Database Options
Microsoft SQL Server 2000 Desktop Engine (Windows) (WMSDE) is installed whenever you install Windows SharePoint Services under the following conditions:
■
When installing without specifying the Remotesql flag in the command line
■
When installing from a command line using the remotesql=no flag
■
When selecting the Typical Installation install option in the setup dialog boxes
If you are using the command-line interface to install Windows SharePoint Services or a script to run the installation, you can specify a separate server to use for
your database. See Table 2-2 for an overview of the ways in which Windows SharePoint Services installations use either WMSDE or SQL Server databases.
Table 2-2
Database Installation Configurations for Windows SharePoint Services
Installation Scenario
Database Used
No database on server
WMSDE locally, or connect to a SQL Server on
another machine
SharePoint Team Services 1.0 installed
MSDE 1.0 upgraded to WMSDE
SQL Server installed on local machine, and
default installation run
WMSDE
SQL Server installed on local machine, and
Server Farm option chosen
SQL Server
SQL Server installed on local server, and
Setupsts.exe run with the remotesql=yes
property
SQL Server on the local or a remote machine
SQL Server installed on remote server, and
Setupsts.exe run with the remotesql=yes
property
SQL Server installed on remote server
Chapter 2: Installing Windows SharePoint Services
25
Application Coresidency and Configuration Considerations
Interactions between Windows SharePoint Services and other technologies can
result in problems. This section outlines some of the issues and workarounds available to operate Windows SharePoint Services most effectively in your environment.
For more information about problems, be sure to check http://support.microsoft.com
for the latest Microsoft Knowledge Base articles. See Table 2-3 for an overview of the
applications with which Windows SharePoint Services has issues.
Table 2-3
Windows SharePoint Services Application Compatibility
Application
Limitation
Existing Web applications
Installation disables existing Web applications and
extends the default website unless another virtual
server is specified.
Exchange 2003
If Exchange is installed in a front-end/back-end configuration, Microsoft Outlook Web Access (OWA)
requests might be incorrectly handled and fail.
Microsoft Office XP or Office 2000
Cannot use multiple upload features or other features
that depend on the new features in Office 2003.
Microsoft FrontPage
You can use FrontPage 2003 to modify Windows
SharePoint Services sites; earlier versions of
FrontPage are not compatible.
FrontPage Server Extensions (FPSE)
If the default website’s virtual server is extended with
FPSE 2002, Windows SharePoint Services will not
automatically extend or upgrade it when installed
using the Typical Installation option.
Microsoft Class Server
Class server can use only the default virtual server, so
Windows SharePoint Services must be installed to a
different virtual server.
Installing Windows SharePoint Services with Existing Web
Applications
Windows SharePoint Services should not be installed on a server that is already running another Web application. Any preexisting Web applications on the server will
be disabled during installation. For information about running Windows SharePoint
Services with another Web application, refer to Microsoft Knowledge Base Article
823265 at http://support.microsoft.com/?kbid=823265.
Exchange 2003 and Windows SharePoint Services
When Windows SharePoint Services is installed on a computer that is running
Microsoft Exchange Server, the deployment causes Kerberos authentication to be
disabled in Internet Information Services and can result in incorrect handling of
OWA requests to an Exchange Server.
26
Part I: Introduction to SharePoint Products and Technologies
More Info For information about running Windows SharePoint Services
using Kerberos authentication, refer to Microsoft Knowledge Base Article
832769 at http://support.microsoft.com/?kbid=832769.
When an IIS virtual server is extended with Windows SharePoint Services, the
virtual server is configured to use Integrated Windows authentication (formerly
named NTLM, or Microsoft Windows NT Challenge/Response authentication). By
configuring Integrated Windows authentication on the virtual server, the Windows
SharePoint Services virtual server can run as a domain account, and you do not have
to configure a service principal name (SPN) in Active Directory directory services
(which benefits you by reducing administrative overhead).
This type of authentication prevents appropriate authentication for OWA in
environments where front-end servers run Exchange 2003 and separate back-end
servers run Exchange 2003, Windows Server 2003, and Windows SharePoint Services.
Note Windows Small Business Server 2003 is not affected by this problem because it is by default a single-server setup with OWA and the
Exchange 2003 information store on the same server.
If your environment requires Kerberos authentication, follow these two steps
to configure Kerberos authentication on the virtual server:
1. Enable Kerberos in the IIS Metabase.
2. Configure a Service Principal Name for the Domain User Account.
Using Windows SharePoint Services and Project Server 2003 on the
Same Server
Although Project Server 2003 can be installed on either Windows 2000 (Service Pack
3 or later) or Windows Server 2003, the product was designed specifically to work
with Windows SharePoint Services, which can run only on Windows Server 2003.
Windows SharePoint Services provides collaboration options such as sharing documents for Project Server. When you install both solutions on the same server, you
should install Windows SharePoint Services first, and then install Project Server 2003.
This installation order helps to simplify the configuration of your site.
Chapter 2: Installing Windows SharePoint Services
27
Installing Windows SharePoint Services on a Single
Machine with WMSDE
When you install Windows SharePoint Services using the default commands, the
WMDSE database installs. WMDSE can be installed only on the same server as Windows SharePoint Services and is most appropriate for smaller environments that will
host fewer than 1000 websites. You should also not consider using WMSDE if you
are using very large amounts of data.
The version of WMSDE installed with Windows SharePoint Services is different
from the standard MSDE database, which limited the number of possible concurrent
connections to five and the size of the database to 2 GB. The WMDSE has neither of
those limitations built in. Be aware, however, that remote users still cannot connect
to the WMSDE database, which prevents its use on a remote server, in a server farm
scenario, or in a clustered environment.
Avoiding Installation Issues
Avoid the following two common mistakes when installing Windows SharePoint
Services with WMSDE:
■
Unintentionally damaging the default website
■
Introducing an error that relates to a virtual server running FrontPage 2002
Server Extensions
Before installing Windows SharePoint Services, ensure that all your existing
websites have been backed up because an install of Windows SharePoint Services
extends the default website in IIS. If you already have a website running in the
default website, Windows SharePoint Services will extend that site, which could
have unpredictable results depending on how that site is configured.
If you want to specify the location other than the default website to install the
WMSDE database, use the /datadir= option with the Setupsts.exe command-line
tool. The syntax is as follows:
setupsts.exe /datadir="path\\”
For example, to install the WMSDE database to the d:\program files\wmsdedata\ directory, type the following command:
setupsts.exe /datadir="d:\program files\wmsdedata\\”
You can avoid another issue by verifying that FrontPage 2002 Server Extensions from Microsoft are not running on the virtual server on port 80. (If you
upgraded from Windows 2000 to Windows Server 2003, FrontPage 2002 Server
Extensions were installed by default to port 80.) If FrontPage 2002 Server Extensions
28
Part I: Introduction to SharePoint Products and Technologies
are running on the default virtual server, the virtual server will not be extended
when you install Windows SharePoint Services.
More Info To understand this issue in more detail, see “Virtual Server Is
Running FrontPage 2002 Server Extensions’ Message When You Run Windows SharePoint Services Setup or When You Try to Extend the Virtual Server
with Windows SharePoint” at http://support.microsoft.com/?kbid=823378.
To install Windows SharePoint Services with WMSDE
1. Double-click Stsv2.exe (if you are running the compressed package from the
Web) or Setupsts.exe (if you’re running setup from the CD or have extracted
the compressed package from the Web) to begin the installation.
2. On the End-User License Agreement (EULA) page, read the EULA, select the
I Accept The Terms In The License Agreement check box, and then click
Next.
3. On the Type Of Installation page, select the Typical Installation option button and then click Next.
4. On the Summary page, review your selections and then click Install. The
installation process for Windows SharePoint Services will take place.
5. After the installation completes, your default browser will start and open to the
Team website at http://localhost/default.aspx, as shown in Figure 2-1.
F02XR01
Figure 2-1
A view of the Windows SharePoint Services Base site
Chapter 2: Installing Windows SharePoint Services
29
You can also install Windows SharePoint Services with WMSDE from a command line using the following command: setupsts.exe /qr. You will see all the dialogs, but you will not have to choose all the default options. For more commandline setup options, see Installing Windows SharePoint Services from a Command
Line later in this chapter.
Installing Windows SharePoint Services
with SQL 2000
In situations requiring more than 1000 websites or more than 4 GB of data, use SQL
Server. Windows SharePoint Services and SQL Server can be installed on the same
machine or separate servers. You can even install Windows SharePoint Services into
a server farm with multiple Windows SharePoint Services installations. These scenarios will be covered in the following section.
When installing Windows SharePoint Services, at a minimum the SQL Server
2000 database requires SQL Server 2000 Service Pack 3 (SP3). Unlike the WMSDE
installation, once the installation completes you will need to configure both SQL
Server and the appropriate website.
More Info When you install SQL Server on a Windows Server 2003 computer, you will receive a message stating that the program is not supported on Windows Server 2003. You can click the Continue button to
install the program, and then apply the latest SQL Server service pack
from http://www.microsoft.com/sql/downloads.
Installing Windows SharePoint Services with SQL Server on the Same
Computer
In this section, you will install Windows SharePoint Services to work with SQL
Server. You will install SQL Server, and then configure it to use Windows Authentication. Finally, you will install and configure Windows SharePoint Services to use
the SQL Server database for administration and content.
Note If you are upgrading from a WMSDE installation of Windows SharePoint Services, see the “Upgrading from WMSDE to SQL Server” section
later in this chapter.
30
Part I: Introduction to SharePoint Products and Technologies
To install Windows SharePoint Services with SQL Server, install SQL Server on
the appropriate machine and then follow the steps in the next procedure.
Note Before you begin, be sure to review the prerequisites for installing
Windows SharePoint Services outlined at the beginning of this chapter. For
example, you want to ensure that your server has IIS 6.0 running in process
isolation mode, and that you have ASP.NET installed. Take the time to read
through these prerequisites to prevent problems.
To install Windows SharePoint Services with SQL Server
1. Start the installation by opening the Stsv2.exe file, or double-clicking Setupsts.exe, or typing setupSTS.exe remotesql=yes from a command line and
then pressing Enter.
Note You can automate the Windows SharePoint Services setup installation. From a command line, start the SetupSTS program using the remotesql=yes property. For example, if you extracted your installation files into
the c:\Temp\WSS directory, type c:\temp\WSS\SetupSTS.exe remotesql=yes /qr from a command prompt, and then click OK. The program
installs without intervention and without loading WMSDE. Finally, configure
the SQL Server connections.
2. On the End-User License Agreement (EULA) page, read the EULA, select the
I Accept The Terms In The License Agreement check box, and then click
Next.
3. On the Type Of Installation page, select the Server Farm option button and
then click Next.
4. On the Summary page, review your selections and then click Install. The
installation process for Windows SharePoint Services will take place.
Chapter 2: Installing Windows SharePoint Services
31
Note Once the installation appears to complete, scripts run to restart the
IIS services on your machine. Be patient if you experience pauses of one to
two minutes.
5. After the installation completes, your default browser will start and open to
the Configure Administrative Virtual Server page at http://localhost:22030
/configadminvs.aspx, as shown in Figure 2-2.
Note The administrative port (shown as 22030 in this example) will be different on each machine and different for each install. The Administration
port number is randomly assigned during the install by setup. In a server
farm scenario, you will need to change this port number on each server in
the farm to allow Central Administration to work correctly from a single console to all servers in the farm.
F02XR02
Figure 2-2
Configuring the Administrative Virtual Server Properties
6. By default, the Configure A New Application Pool option button is selected.
Type a name for the new application pool.
32
Part I: Introduction to SharePoint Products and Technologies
Best Practices Although you can install Windows SharePoint Services into
an existing application pool, your database security is at risk because other
Web applications in the same pool can modify Windows SharePoint Services databases. To protect your databases, install Windows SharePoint
Services in its own application pool.
7. Choose the security account you want to use for the application pool. You can
choose the Predefined option button and select the drop-down to choose
between Network Service, Local Service, or Local System, or you can choose
the Configurable option button and type in the User Name, Password, and
Confirm Password fields. Click OK to continue.
Best Practices It is best to use the predefined security accounts because
they most likely already have the required rights to create and modify databases. If you set a network account for your SQL Server services, use this
option.
Tip You can change these options later by using the Internet Information
Services (IIS) Manager, expanding the Application Pools node, right-clicking
the application pool, selecting Properties, and then clicking the Identity tab.
8. The Application Pool Changed page will appear and prompt you to restart the
IIS Services. Do not click OK yet. Minimize this window until you have completed configuring your SQL Server security.
To configure SQL Server security
1. Open Enterprise Manager, and navigate to your SQL Server. Expand the
Security node, right-click the Logins property, and then click the New Login
option. If the account you will use already appears in the Logins pane, rightclick the account and then click Properties.
2. If you have not already created Microsoft Windows NT accounts as SQL Server
service accounts using the Active Directory Users And Computers console,
you must do so before you can assign the account-appropriate permissions.
For more information about how to create secure accounts, see the SQL Server
Chapter 2: Installing Windows SharePoint Services
33
Security Checklist at http://www.microsoft.com/technet/prodtechnol/sql/maintain/security/sp3sec/SP3SEC04.ASP.
3. In the SQL Server Login Properties dialog box, type the name of the account
you will use in the Name field using the DomainName\UserName convention (for example, NT AUTHORITY\NETWORK SERVICE).
4. Click the Server Roles tab, and then select the Security Administrators
option and the Database Creators option from the Server Role list. Click OK
to close this window, and then close Enterprise Manager.
To create or connect to the SQL Server
1. Click the Start button, and then select Run. In the Open box, type iisreset
and then press Enter. The IIS Services will restart.
2. Restore the Application Pool Changed Web page you minimized in step 8 of
the “To install Windows SharePoint Services with SQL Server” section, and then
click OK. The Set Configuration Database page will appear.
3. In the Database Server box, type the name of your SQL Server.
4. In the SQL Server Database Name box, type the name of the database you
will use.
5. In the Database Connection Type section, select the Use Windows Authentication (Recommended Security Level) option button.
Note Although it is possible to connect using SQL Authentication, the environment is much less secure. If you must use SQL Authentication, be certain that you configure the SQL Account with a complex password.
Only if you have previously created the database to which you are connecting should you select the Connect To Existing Configuration Database
check box.
Note If you receive an error message that states “[DBNETLIB][ConnectionOpen (Connect()).]SQL Server does not exist or access denied. (Error code:
17)” make certain that you have the correct name for your server and database, and ensure that the account you specified has Security Administrators and Database Creators roles assigned in SQL Server.
34
Part I: Introduction to SharePoint Products and Technologies
6. In the Active Directory Account Creation section, the default selection is
Users Already Have Domain Accounts, Do Not Create Active Directory
Accounts. If you need to allow users who do not already have domain
accounts created to use your Windows SharePoint Services site, refer to the
“Separate Active Directory Directory Service Organization Unit Deployment”
section of the Microsoft Windows SharePoint Services Administrator’s Guide
located on the companion CD-ROM.
7. Click OK. The Windows SharePoint Services Central Administration page now
appears.
You have set up the administrative database for your Windows SharePoint Services installation.
To extend a virtual server and connect to SQL Server
1. On the SharePoint Central Administration page, click the Extend Or Upgrade
Virtual Server option.
2. On the Virtual Server List page, click the name of the virtual server that you
want to extend. The Extend Virtual Server page will appear. If you want to create a new virtual server, use the Internet Information Services (IIS) Manager or create a new site from the command prompt by using the IIsWeb.vbs
script included with IIS 6.0.
More Info For more information about the tools that come with IIS 6.0,
see the IIS 6.0 Services SDK Documentation.
3. On the Extend Virtual Server page, select the Extend And Create A Content
Database option in the Provisioning Options section, as shown in Figure 2-3.
F02XR03
Figure 2-3
Extend and create a content database
4. In the Application Pools section, select Create A New Application Pool and
type the application pool name, the user name, and the password.
Chapter 2: Installing Windows SharePoint Services
35
Note Although you can choose the Use An Existing Application Pool, you
improve your security and stability by running each virtual server in its own
application pool. Virtual servers could share application pools in cases
where several virtual servers relate to similar functions, or if there will be so
many different application pools that performance will be degraded.
5. In the List owner section, type the user name for your site owner in the
Account Name box (using the DomainName\UserName convention), and
type the e-mail address for that account in the E-Mail Address box.
6. In the Database Information section, you will either select an existing content database or create a new one. If you create a new database, be sure to use
a new database name to avoid overwriting existing content.
7. Specify a URL in the Custom URL Path box if you want to do so.
8. In the Quota Settings section, select a template in the Select A Quota Template box. (If you are not using quotas, there is of course no need to set this
property.)
9. Select the language you will use from the Site Languages section.
10. Click OK to commit the changes. Once the virtual server extension completes,
the browser will display a confirmation page. Click OK to return to the Virtual
Server Settings page; otherwise, to view your extended site, click the link on
the Virtual Server Successfully Extended page, and then choose a template for
your site.
You now have installed Windows SharePoint Services with SQL Server located
on the same machine. To learn more about configuring Windows SharePoint Services, refer to Chapter 16, “Administering Windows SharePoint Services.”
The process for installing Windows SharePoint Services with a remote SQL
Server is the same as installing a SQL Server on the same machine as described earlier, but you will specify the name of the remote SQL Server in the configuration
options.
Upgrading from WMSDE to SQL Server
If you find that your WMSDE installation no longer can meet the number of websites
you host, you can either upgrade or migrate WMSDE to use the more scalable and
robust SQL Server product. If you want to maintain the SQL Server on the same
server as Windows SharePoint Services 2.0, you can upgrade the WMSDE database
itself to SQL Server. If you need to run SQL Server on another computer, you will
need to migrate your data. Both scenarios are outlined in the following sections.
36
Part I: Introduction to SharePoint Products and Technologies
Backing Up Your WMSDE Server
Before you perform any upgrade, you should first back up your server. In the case
of an upgrade from WMSDE to SQL Server on the same machine, the backup serves
as insurance in case anything goes awry. If you are migrating to a remote SQL
Server, the backup can be used to restore the Windows SharePoint Services 2.0 data
to your remote SQL Server machine.
To back up your Windows SharePoint Services sites using the Stsadm.exe tool,
follow these steps:
1. Use Stsadm.exe to list all the sites currently running on your server by typing
stsadm.exe -o enumsites -url YourURL at a command line (where YourURL
is the path to your Windows SharePoint Services virtual server that lists your
site collections).
2. Once you’ve chosen the site you want to back up, type stsadm.exe -o backup
-url http://server_name/site -filename backup.dat where backup is the
name of the backup file you’re creating.
Note These steps do not back up the entire SQL Server database; rather,
they back up the Windows SharePoint Services sites contained within the
database. To actually back up the SQL Server database, the user must use
Enterprise Manager, or osql.exe.
Upgrading WMSDE to SQL Server on the Same Server
If your SQL Server is installed on the same computer as Windows SharePoint Services 2.0, follow these steps:
1. Insert or connect to the SQL Server 2000 installation CD, clicking Autorun.exe
if the installation splash screen does not appear. Click the SQL Server 2000
Components link.
2. Click the Install Database Server link, and then click Next.
3. Select Local Computer in the Computer Name box, and then click Next.
4. On the Installation Selection page, select Upgrade, Remove, Or Add Components To An Existing Instance Of SQL Server, and then click Next.
5. On the Instance Name page, clear the Default check box, select SharePoint
from the Instance Name drop-down list, and then click Next.
6. On the Existing Installation page, the Upgrade option should be selected by
default. If it is not, select it. Click Next.
Chapter 2: Installing Windows SharePoint Services
37
7. On the Upgrade page, the Yes, Upgrade My Programs check box should be
selected by default. If it is not, select it. Click Next.
8. On the Licensing Options page, select the appropriate licensing options, and
then click Next.
9. On the Select Components page, click Server Components options. You will
require the Enterprise Manager and Query Analyzer from Management Tools.
10. Choose any other components you require, and then click Next.
11. On the Start Copying Files page, click Next, and then Finish. The upgrade
process will take place.
12. Download the latest SQL Server service pack from http://www.microsoft.com
/sql/downloads, and then install it on the computer.
Once you’ve completed the upgrade, you can manage your database from the
Enterprise Manager. Your SharePoint sites should work normally.
Migrating WMSDE to a Remote SQL Server or Server Farm
If you are moving to a larger environment with one or many front-end Web servers
and one or many back-end database servers, the process is more complicated. To
switch from WMSDE to SQL Server and move to a server farm, you must perform
steps using the Internet Information Services (IIS), Windows SharePoint Services, and
SQL Server administration tools. You must also take your sites offline for a while. It
is recommended that you perform these steps at a time when usage of your sites is
generally low, and also that you notify users that their site will be offline for a time.
Note Ensure you have backed up the database as described in the “Backing Up Your WMSDE Server” section earlier in the chapter.
The following process assumes that you will continue to use the original Web
server computer as either a stand-alone server or part of a server farm and that you
are moving the databases to a new back-end database server running SQL Server.
The following steps describe how to move from a single-server WMSDE installation to a server farm with SQL Server:
■
Install the SQL Server client tools on the original server running WMSDE and
SQL Server 2000 SP3. The client tools are used to back up and restore the content and configuration databases. The version of WMSDE that is installed with
Windows SharePoint Services does not enable remote connections from SQL
Server client tools.
38
Part I: Introduction to SharePoint Products and Technologies
■
Prepare the destination database server by installing SQL Server 2000 Service
SP3 or later.
■
Using the IIS Manager, stop any virtual servers that are hosting SharePoint sites
so that users cannot access the sites.
■
Disconnect the content databases from the virtual server, and remove Windows
SharePoint Services from the virtual server. In case you decide to reinstall Windows Sharepoint Services and want to reconnect to the database, don’t delete
the content database when prompted to do so.
■
Decide which domain accounts to use for the SharePoint Central Administration virtual server and the content virtual servers, and then, using the Windows
SharePoint Services administration pages, update the SharePoint Central
Administration virtual server to use the domain account.
Note You can use the same account for both SharePoint Central Administration and the other virtual servers, or, for more granular security, you can
choose to use different accounts.
■
Register the instance of WMSDE in SQL Server Enterprise Manager, and then
back up the content and configuration databases.
■
Copy the backup files to the destination server, and restore the content and
configuration databases.
■
In SQL Server, change the database ownership and permissions for the configuration and content databases.
■
Reconnect to the configuration database.
■
Extend the content virtual server, and add the restored content databases to the
virtual server.
■
Update the default content database server for future content database creation.
Chapter 2: Installing Windows SharePoint Services
39
Installing Windows SharePoint Services from a Command Line
To install Windows SharePoint Services from a command line, you can use the following conventions.
When you install Microsoft Windows SharePoint Services, you can use command-line properties and setup options to control how it is installed. For example,
to install Windows SharePoint Services to work with a remote installation of
Microsoft SQL Server, you run Setupsts.exe with the remotesql=yes option to avoid
installing Microsoft SQL Server 2000 Desktop Engine (Windows) (WMSDE). Then,
after the installation, you can specify the SQL Server connection information and
extend your servers.
Setupsts.exe Command-Line Installation Properties
Table 2-4 lists and explains the properties you can use with the command-line Setup
program (Setupsts.exe) for Windows SharePoint Services.
Table 2-4
Setupsts.exe Command-Line Properties
Property
Description
remotesql=yes/no
An optional property that specifies whether or not WMSDE is
installed with Windows SharePoint Services. The default value is No.
Set this property to Yes if you are going to use an existing or remote
installation of Microsoft SQL Server with Windows SharePoint Services.
fulluninstall=yes/no
Specifies whether or not to remove Windows SharePoint Services
from extended virtual servers when performing an uninstall. The
default value is Yes. It is recommended that you use the Add or
Remove Programs control panel to uninstall Windows SharePoint
Services.
provision=yes/no
Specifies whether or not to provision the administrative virtual server,
extend the default virtual server, and create a top-level website during installation. The default value is Yes. Set this property to No if
you want to provision virtual servers later using the Stsadm.exe command-line tool, located in C:\Program Files\Common Files\Microsoft
Shared\web server extensions\60\BIN.
Note The remotesql=yes property also installs Windows SharePoint Services without provisioning the default virtual server, but it does provision the
administration virtual server.
40
Part I: Introduction to SharePoint Products and Technologies
SetupSTS-Supported Command-Line Switches
Not all the standard setup options for Microsoft Windows Installer programs are supported by Windows SharePoint Services. For example, you cannot create an administrative installation point for Windows SharePoint Services (performed for other
programs by including the /a option). Table 2-5 lists and describes the setup options
supported by Windows SharePoint Services.
Table 2-5
Setupsts.exe Command-Line Switches
Option
Description
l <path to log file>
Logs setup messages to the specified file.
q or qn
Runs Setupsts.exe in quiet mode (unattended setup with no user intervention).
qb
Runs Setupsts.exe in basic mode (limited user intervention). Includes a
progress bar.
qf
Runs Setupsts.exe in full mode (user must fill in options during setup).
This is the default option.
qr
Runs Setupsts.exe in reduced mode. Displays reduced user interface
(UI) during installation.
qn+
Runs Setupsts.exe in quiet mode (unattended setup with no user intervention). Displays a Setup Complete dialog box at the end of the
installation.
qb+
Runs Setupsts.exe in basic mode (limited user intervention). Includes a
progress bar and a Setup Complete dialog box at the end of the installation. If you cancel the installation, the dialog box is not displayed.
qb-
Runs Setupsts.exe in basic mode (limited user intervention). Does not
display a Setup Complete dialog box.
x
Uninstalls Windows SharePoint Services.
-
Suppresses all modal dialog boxes. Used only with the /b option.
+
Adds a completion message to the /n option or the /b option.
Installing Windows SharePoint Services
into a Server Farm
Windows SharePoint Services is fully scalable, installing and operating extremely
well in a server farm configuration; however, the increased complexity produces
more potential errors. When you install Windows SharePoint Services into a server
farm, be sure to think through your configuration and implement it carefully.
Chapter 2: Installing Windows SharePoint Services
41
Server Farm with Multiple Host Names Deployment
You can install and configure Microsoft Windows SharePoint Services to allow your
server farm to host several sites on the same virtual server using the same IP address
but use multiple site names and separate content. This configuration is known as a
server farm serving multiple host names. In this configuration, you have a single IP
address (192.168.2.1, for example), but this same IP address can point to the following individual sites:
■
Mary.WoodgroveBank.com
■
John.WoodgroveBank.com
■
ProjectTeam.WoodgroveBank.com
■
Information.WoodgroveBank.com
Each of these sites has its own content, its own set of users, and a different site
owner. Each site can use unique Windows SharePoint Services features and share
the same virtual server using the same IP address. The Web servers and configuration database make the appropriate content available depending on the URL
requested.
This section describes the steps you need to take to configure the servers in
your server farm to serve multiple host names with Windows SharePoint Services.
Preparing the Servers
Before you can install and configure Windows SharePoint Services in your server
farm, you must be sure you meet the hardware and software requirements and plan
out your server farm configuration. The following sections help you determine the
configuration to use.
Hardware and Software Requirements
To be able to set up Windows SharePoint Services in a server farm configuration,
you must meet the criteria described in more detail in the “Prerequisites” section at
the beginning of this chapter.
42
Part I: Introduction to SharePoint Products and Technologies
Installing and Configuring Windows SharePoint Services
After you have prepared the back-end database and front-end Web servers, you can
install and configure Windows SharePoint Services on the front-end Web servers. To
install and configure Windows SharePoint Services on your front-end Web servers,
perform the following steps:
■
Install Windows SharePoint Services. You must install Windows SharePoint Services on each front-end Web server. Using the remote SQL Server
option (setupsts.exe remotesql=yes) allows you to install Windows SharePoint
Services without also installing WMSDE.
■
Create the administration virtual server and configuration database. You
need to create the configuration database when you configure the first front-end
Web server. For subsequent front-end servers, simply connect to the database.
■
Create and extend a virtual server. Before you can create sites, you must
create a virtual server to contain them in IIS. You can create multiple virtual
servers with different IP addresses or host all your sites using the same IP
address and virtual server.
■
Create sites. Creating sites for users is the final step. You can also enable
Self-Service Site Creation so that users can create their own sites. For more
information, see Configuring Self-Service Site Creation in the Windows SharePoint Services Administrator’s Guide.
To perform these steps for a server farm, we recommend you use the command-line administration tool, Stsadm.exe.
Install Windows SharePoint Services with the Remote
SQL Server Option
Install Windows SharePoint Services with SQL Server, as described earlier in this
chapter. After setup, the HTML Administration pages open so that you can configure
the administration virtual server and configuration database. For a server farm environment, you must use the command-line administration tool to create the configuration database rather than HTML Administration. The host header (-hh) parameter
is available only from the command line.
Chapter 2: Installing Windows SharePoint Services
43
Note The host header (-hh) parameter is a one-time-only configuration
choice that you only need to use when creating the configuration database
for a server farm. This parameter puts Windows SharePoint Services in the
scalable hosting mode and only host-named sites should be created in this
configuration.
To create the administration virtual server and configuration database
1. Open a command prompt window, and navigate to the \Program Files\Common Files\Microsoft Shared\Web Server Extensions\60\bin folder.
2. Run the following command to create the administration virtual server:
stsadm.exe -o setadminport -port <port> -admapcreatenew
-admapidname <id for application pool>
-admapidtype <configurableid/NetworkService/LocalService/LocalSystem>
-admapidlogin <user account for the application pool>
-admapidpwd <password>
Note Remember that you can use any unused port between 1023 and
32,767.
3. Run the following command to create the configuration database:
stsadm.exe -o setconfigdb -ds <database server name>
-du <database user> -dp <password> -dn sts_config –hh
Note If you are using Windows authentication, you do not need to specify
the -du parameter or the -dp parameter.
To connect to the configuration database from subsequent front-end Web servers, use the Set Configuration Database page in HTML Administration, or use the following syntax:
stsadm.exe -o setconfigdb -ds <database server name>
-du <database user> -dp <password> -dn sts_config -connect
44
Part I: Introduction to SharePoint Products and Technologies
Note If you are using Windows authentication, you do not need to specify
the -du parameter or the -dp parameter.
With the administration virtual server and configuration database in place, you
can create the virtual server to provide sites for your users. Each front-end Web server
needs at least one virtual server for websites. If you do not want to use the existing
default website, you can create a new virtual server by using the following steps.
To create a virtual server
1. Click Start, point to All Programs, point to Administrative Tools, and then
click Internet Information Services (IIS) Manager.
2. Click the plus sign (+) next to the server name to which you will add a virtual
server.
3. Right-click the Web Sites folder, click New, and then click Web site.
4. Click Next.
5. In the Description box, type the description of your virtual server and then
click Next.
6. In the Enter the IP address to use for this Web site box, select the IP
address you want to use or use the default (All Unassigned).
7. In the TCP port, this website should use the (Default: 80) box; type the port
number to assign to the virtual server. You do not need to assign a host header
because the hosting is handled through Windows SharePoint Services.
8. Click Next.
9. In the Path box, type or browse to the path on your hard disk where the site
content will reside.
10. If you do not want to allow anonymous access to your virtual server, clear the
Allow anonymous access to this Web site check box.
11. Click Next.
12. On the Permissions panel, select the permissions to use and then click Next.
Chapter 2: Installing Windows SharePoint Services
45
Tip The default permissions, Read and Run Scripts (such as ASP), are
recommended. The Execute (such as ISAPI applications or CGI) permission
will be added automatically to the appropriate folders by Windows SharePoint Services.
13. Click Finish.
For more information about creating virtual servers, see the Adding Sites topic
in the Help system for Internet Information Services.
Now that the virtual server has been created, you can extend it with Windows
SharePoint Services. You can use either the command line or the HTML Administration pages to extend the virtual server.
To extend the virtual server from the command line
1. Open a command prompt window, and navigate to the \Program Files\Common Files\Microsoft Shared\Web Server Extensions\60\bin folder.
2. Run the following command to extend the virtual server:
stsadm -o extendvs -url http://servername
-ds <database server name> [-du <database user> -dp <password>
-dn <database name> -ownerlogin <DOMAIN\user>
-owneremail <email address> -ownername <display name>
-donotcreatesite -apcreatenew -apidname <application pool name>
-apidtype <configurableid/NetworkService/LocalService/LocalSystem>
-apidlogin <app pool user account> -apidpwd <app pool password>
Be sure to use the -donotcreatesite parameter when you extend the virtual
server. Without this parameter, a site is automatically created when you extend the
virtual server, and the site will not be affiliated with a host name.
Notice that the -du and -dp parameters are not needed if you are using Windows authentication to connect to SQL Server. It is recommended that you create a
new application pool to use for your virtual servers so that they run in separate processes from the administrative virtual server. Use the same application pool for each
server farm virtual server on each front-end Web server. This application pool
should use a domain account, but it does not need to have database creation rights
in SQL Server. The administration virtual server account will create any databases
required.
46
Part I: Introduction to SharePoint Products and Technologies
To extend the virtual server using the HTML Administration pages
1. On the SharePoint Central Administration page, click Extend or upgrade virtual server.
2. On the Virtual Server List page, click the name of the virtual server to extend.
3. On the Extend Virtual Server page, in the Provisioning Options section,
select Extend and create a content database.
4. In the Application Pool section, select either Use an existing application
pool or Create a new application pool.
Note It is recommended that you create a new application pool for each
virtual server so that they run in separate processes. This application pool
should use a domain account, but it does not need to have database creation rights in SQL Server. The administration virtual server account will create any databases required.
5. If you selected Use an existing application pool, select the application pool
to use. If you selected Create a new application pool, type the new application pool name, user name, and password to use.
6. In the Site Owner section, in the Account name box, type the user name for
the site owner (in the format DOMAIN\username if the user name is part of a
Windows domain group).
7. In the E-mail address box, type the e-mail address that corresponds to the
account.
8. In the Database Information section, select the Use default content database server check box or type the database server name and database name
to use for a new content database.
9. If you want to specify a path for the URL, in the Custom URL path box, type
the path to use.
10. If you are using quotas, select a template in the Select a quota template box
of the Quota Settings section.
11. In the Site Language section, select the language to use.
12. Click OK.
Chapter 2: Installing Windows SharePoint Services
47
Creating Sites
After following the preceding steps, you are ready to create sites for your users. This
is the last step in the process for setting up your server farm. After this step, you can
start adding users and managing the sites.
If you are setting up the multiple host names model for your server farm, you
need to create the mapping for the sites you will create for users. Each host name
and host header name will need an entry in DNS for each virtual server that will host
your sites. Without these entries, name resolution will fail and you will not be able
to access your sites.
To create a new site, perform the following actions:
1. Open a command prompt window, and navigate to the \Program Files\Common Files\Microsoft Shared\Web Server Extensions\60\bin folder.
2. Run the following command to create a site:
stsadm.exe -o createsite -url http://site1.WoodgroveBank.com
-ownerlogin <DOMAIN\user> -owneremail <email address>
[-ownername <display name> -lcid <lcid>
-sitetemplate <site template> -title <title>
-description <description>]
3. Repeat this step for every site you want to create.
Note Should you need to remove the original top-level website for the virtual
server, use the following command-line syntax:
stsadm.exe –o -deletesite -url http://servername
If you are setting up any of the other hosting models for your server
farm, you can simply create the sites.
To create a site
1. Open a command prompt window, and navigate to the \Program Files\Common Files\Microsoft Shared\Web Server Extensions\60\bin folder.
2. Run the following command to create a site:
stsadm.exe -o createsite -url <url>
-ownerlogin <DOMAIN\user> -owneremail <email address>
-ownername <display name>
3. Repeat this step for every site you want to create.
48
Part I: Introduction to SharePoint Products and Technologies
Uninstalling Windows SharePoint Services
If you need to uninstall Windows SharePoint Services, you can choose from several
options that remove the Windows SharePoint Services installation from a particular
virtual server.
There are different degrees to which you can uninstall Microsoft Windows
SharePoint Services. Depending on your needs, you can choose from the following
options:
■
Remove Windows SharePoint Services from a virtual server and preserve the
site content.
■
Remove Windows SharePoint Services from a virtual server and delete the site
content.
You can choose to remove Windows SharePoint Services and delete the
site content in the database. Use this method to remove a virtual server permanently, but continue using Windows SharePoint Services on other virtual servers. For example, use this method if you are finished with a project and no
longer need the associated websites.
Caution When you use this method, you cannot reconnect to the site content later. If you choose to delete the content databases, you are permanently deleting the site content and cannot recover the site data except
from a backup.
Uninstall Windows SharePoint Services Completely from a Server
You can choose to uninstall Windows SharePoint Services by using the Add/Remove
Programs control panel. This method does not delete site content. You can reinstall
and reconnect to the site content. Use this method to repair an installation or to
remove a Web front-end server from a server farm.
All these methods leave the virtual server or server in a clean state, ready to be
used for other websites or applications; however, each method affects the content
and configuration databases in a different way. Table 2-6 explains what happens
when you use each of these remove or uninstall methods.
Chapter 2: Installing Windows SharePoint Services
Table 2-6
49
Windows SharePoint Services Uninstall Scenarios
Method
What Happens to the Databases
Actions During Removal
Remove and
preserve content
The content databases associated
with the virtual server remain
untouched. You can reconnect to
the site content.
The Windows SharePoint Services ISAPI filter
is uninstalled, and the virtual directories for
Windows SharePoint Services are removed
from the virtual server.
The entry for the virtual server
remains in the configuration database.
Any physical directories created by Windows
SharePoint Services under the physical home
directory of the virtual server are removed.
The Port section in the registry for the virtual
server is removed. This means that any managed paths and any URL mapping are
removed.
Remove and
delete content
The content databases are deleted.
You cannot reconnect to the site
content.
The entry for the virtual server is
removed from the configuration
database.
The Windows SharePoint Services ISAPI filter
is uninstalled, and the virtual directories for
Windows SharePoint Services are removed
from the virtual server.
Any physical directories created by Windows
SharePoint Services under the physical home
directory of the virtual server are removed.
The Port section in the registry for the virtual
server is removed. This means that any managed paths and any URL mapping are
removed.
Uninstall
The content and configuration databases associated with the server
remain untouched. You can reinstall
Windows SharePoint Services later
and reconnect to databases. If you
do not want to reconnect, you can
delete the databases by using the
Microsoft SQL Server or Microsoft
SQL Server Desktop Engine (Windows) 2000 (WMSDE) database
administration tools.
Windows SharePoint Services is removed
from any virtual servers.
The Windows SharePoint Services administration virtual server is removed.
The Windows SharePoint Services DLL files
are removed from the installation directory.
Removing Windows SharePoint Services from a Virtual Server
You can choose to remove Windows SharePoint Services but keep the site content
in the content database. This allows you to extend the virtual server again later and
reconnect to the site content. If you leave the content databases intact, you can
reconnect to them, from the same virtual server or from a different virtual server, and
continue hosting the site content using the same URL. Use this method to temporarily remove and then restore a virtual server, or to change which virtual servers are
hosting which content in a server farm setting.
50
Part I: Introduction to SharePoint Products and Technologies
You can remove Windows SharePoint Services from a virtual server by using
HTML Administration or the command-line administration tool. Both of these tools
allow you to either preserve or delete content when you remove Windows SharePoint Services.
Removing Windows SharePoint Services from a Virtual Server by Using
HTML Administration
To remove Windows SharePoint Services from a virtual server by using HTML Administration, use the Remove Windows SharePoint Services from Virtual Server page.
1. Click Start, point to All Programs, point to Administrative Tools, and then
click SharePoint Central Administration.
2. On the Central Administration page, under Virtual Server Configuration, click
Configure Virtual Server Settings.
3. On the Virtual Server List page, select the virtual server you want to configure.
4. On the Virtual Server Settings page, under Virtual Server Management, click
Remove Windows SharePoint Services From Virtual Server.
5. On the Remove Windows SharePoint Services From Virtual Server page, select
one of the following:
■
Remove without deleting content databases. This removes only the
Windows SharePoint Services folders from the virtual server—the content
database remains intact, so you can reconnect to it later using the same
virtual server or a different one.
■
Remove and delete content databases. This both removes the Windows SharePoint Services folders from the virtual server and deletes the
content database. You will not be able to reconstruct the sites previously
stored on that virtual server unless you have a backup.
Figure 2-4 illustrates the options available for removing Windows SharePoint
Services.
F02XR04
Figure 2-4
6. Click OK.
Options for removing Windows SharePoint Services
Chapter 2: Installing Windows SharePoint Services
51
Removing Windows SharePoint Services from a Virtual Server by Using
the Command Line
You can use the unextendvs operation with the Stsadm.exe command-line utility to
remove Windows SharePoint Services from a virtual server. The unextendvs operation takes the -url parameter and the optional -deletecontent parameter. When you
use unextendvs without the -deletecontent parameter, it leaves the content databases in place so that you can reconnect to the content for a virtual server. When
you include the -deletecontent parameter, the content databases are removed and
the virtual server is removed from the configuration database.
For example, to remove Windows SharePoint Services from a virtual server but
preserve the content databases, use the unextendvs operation with syntax as shown
in the following example:
stsadm -o unextendvs -url http://servername
To remove Windows SharePoint Services from a virtual server and remove the
content databases permanently, use the unextendvs operation with syntax as shown
in the following example:
stsadm -o unextendvs -url http://servername -deletecontent
When you use the unextendvs operation with the -deletecontent parameter,
you cannot reconnect to the site content later.
Uninstalling Windows SharePoint Services from the Server Computer
If you want to remove Windows SharePoint Services from a server computer
entirely, you can uninstall by using the Add Or Remove Programs control panel.
Uninstalling Windows SharePoint Services does not remove any chained products
that were installed, such as WMSDE. You must uninstall these programs separately.
You must be an administrator on the server computer to uninstall Windows
SharePoint Services.
When you use the Add or Remove Programs control panel to remove Windows SharePoint Services from a server, it calls a command-line operation, stsadm
-o uninstall, to perform the task. The uninstall operation does not remove any
chained products that were installed. The uninstall operation takes the optional
-deletecontent parameter. When uninstall is used without the -deletecontent parameter, it leaves the content and configuration databases in place so that Windows
SharePoint Services can be reinstalled, and so that you can reconnect to the databases and continue hosting sites. When the -deletecontent parameter is used, the
content and configuration databases are removed, and you cannot recover the site
content.
52
Part I: Introduction to SharePoint Products and Technologies
Summary
This chapter discussed the prerequisites required for installing Windows SharePoint
Services and then outlined how to install Windows SharePoint Services using either
WMDSE or SQL Server. It also described the steps necessary to install Windows
SharePoint Services into a server farm and concluded by discussing how to uninstall
Windows SharePoint Services using several different methods. In the next chapter,
we will discuss how to install SharePoint Portal Server 2003.
Chapter 3
Installing Microsoft Office
SharePoint Portal Server
2003
In this chapter:
Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
Installing SharePoint Portal Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
Migrating from WMSDE to SQL Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
Installing the Component for Backward-Compatible Document Libraries . . 82
Installing SharePoint Portal Server into a
Non–Active Directory Environment. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
Uninstalling SharePoint Portal Server 2003 . . . . . . . . . . . . . . . . . . . . . . . . 86
Repairing SharePoint Portal Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
Troubleshooting SharePoint Portal Server Installations . . . . . . . . . . . . . . . 89
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
Microsoft Office SharePoint Portal Server 2003 can be installed in a variety of ways
with a wide selection of both mandatory and optional components. In this chapter,
we will cover the following subjects:
■
Prerequisites for installing SharePoint Portal Server 2003
■
Installing SharePoint Portal Server 2003
■
Upgrading from Microsoft SQL Server Desktop Engine (MSDE) to SQL
Server 2000
■
Installing the backward-compatible document library
■
Installing SharePoint Portal Server into a non–Active Directory environment
■
Uninstalling SharePoint Portal Server 2003
53
54
Part I: Introduction to SharePoint Products and Technologies
Prerequisites
SharePoint Portal Server 2003 requires Internet Information Server (IIS) 6.0,
which requires Microsoft Windows Server 2003. SharePoint Portal Server 2003
caches content in RAM, so while the minimum requirements for RAM are moderate
(512 MB), if you use more RAM you’ll experience better performance.
Hardware and Software Requirements
Table 3-1 details the minimum and recommended installation requirements for
SharePoint Portal Server 2003.
Table 3-1
Hardware and Software Requirements for SharePoint Portal Server 2003
Item
Minimum Requirement
Recommended Requirement
Windows Server 2003 (any version), although the Web Edition
does not support local installation
of SQL Server or MSDE.
Windows Server 2003 Standard
and Enterprise Editions with all
Service Packs and hotfixes
applied.
CPU
Intel Pentium III 700 MHZ or
higher.
Intel Pentium 4 1GHz or higher.
RAM
512 MB RAM.
512 MB of RAM, with an additional 256 MB for every 512 MB
of content that will be used at a
given time.
Disk Space (Pre-Installation)
300 MB free disk space on boot
partition, 200 MB free disk space in
the Program Files installation directory, and 75 MB free disk space in
the Data Files installation directory.
500 MB plus the amount of RAM
installed of free space on the
boot partition, and 1GB of free
disk space in the Data Files
installation directory.
Disk Space (Post Installation)
Minimum 700 MB free disk space
in the Data Files installation directory, and 2.0 GB free disk space in
the Database (SQL 2000 or MSDE
2000) directory.
Minimum 1 GB free disk space
in the Data Files installation
directory, and 2.0 GB or more
free disk space in the Database
(SQL 2000 or MSDE 2000) directory.
Disk Configuration
Separate drives to store boot partition, pagefile, transaction logs, and
databases.
Mirrored drive for boot and system partition, mirrored drive for
transaction logs, RAID 5 configuration for databases, and single
disk drive for pagefile.
File System
Any partition that will host SharePoint Portal Server data must be
formatted with NTFS.
NTFS.
Server Requirements
Operating System
Chapter 3:
Table 3-1
Installing Microsoft Office SharePoint Portal Server 2003
55
Hardware and Software Requirements for SharePoint Portal Server 2003
Item
Minimum Requirement
Recommended Requirement
Database
Microsoft SQL Server Desktop
Engine (MSDE) or SQL Server 2000
is compatible on all versions of
Windows Server 2003 except when
using Web Edition—in this case,
SQL Server 2000 must be installed
on a remote server and the SQL
Server Desktop Engine cannot be
used.
SQL Server 2000 with the most
current Service Packs and hotfixes applied.
Browser
Microsoft Internet Explorer 5.01
and later for Windows;
Internet Explorer 6.0 for Windows with the latest service
packs and patches installed.
Internet Explorer 5.2 and above for
Mac OS X;
Netscape Navigator 6.2 and above
for Microsoft Windows, Mac, and
UNIX. Only Internet Explorer 5.5
and later allow management of a
portal site.
Client Requirements
Browser
Microsoft Internet Explorer 5.01 or
5.5 with Service Pack 2 and Patch
from Knowledge Base 324929;
Microsoft Internet Explorer 6
with the latest Service Pack and
hotfixes applied.
Internet Explorer 6 with Knowledge Base 324929;
Netscape Navigator 6.2 or later for
Mac, UNIX, or Windows;
Internet Explorer 5.2 for Macintosh or later.
Windows Server Web Edition and SharePoint Portal Server
While it is possible to install SharePoint Portal Server 2003 on Microsoft Windows
Server 2003, Web Edition, there are many limitations that make the use of Web Edition undesirable. For example, Windows Server 2003, Web Edition, cannot extend its
RAM beyond 2 GB, which severely limits the amount of content that the SharePoint
Portal Server 2003 installation could serve. In addition, you have a limit of only two
CPUs, which means that if you’re using application pools, you severely limit your
ability to map specific pools to different processors. Most importantly, however, is
that you are unable to join an Active Directory domain or install either MSDE or SQL
Server, making the only supported configuration a workgroup installation with a
remote installation of SQL Server. Again, installing SharePoint Portal Server 2003 on
Windows Server 2003, Web Edition, is not a recommended configuration.
56
Part I: Introduction to SharePoint Products and Technologies
Internet Information Services (IIS 6.0)
SharePoint Portal Server, like Microsoft Windows SharePoint Services, relies on IIS
6.0. In Chapter 2, “Installing Windows SharePoint Services,” we discussed the
requirements needed to use IIS 6.0, including ASP.NET and Worker Process Isolation
Mode. SharePoint Portal Server 2003 depends directly on the IIS 6.0 architecture
for new technology components such as Application Pools, which are a group of
Web applications that can be configured centrally and set to share the same worker
process.
More Info For more information on Internet Information Services 6.0 architecture, refer to the IIS product documentation at http://www.microsoft.com
/technet/treeview/default.asp?url=/technet/prodtechnol/windowsserver2003
/proddocs/standard/iiswelcome.asp.
Backward-Compatible Document Libraries and Server Farm Limitations
For small, medium, and large server farm deployments, the backward-compatible
document library and SQL Server 2000 cannot be installed on the same computer.
For more information on configuring the backward-compatible document library for
use in a server farm, refer to Chapter 11, “Deploying a Single Server and a Small
Server Farm.”
Product Language
While SharePoint Portal Server 2003 ships in multiple languages, it supports only one
language per installation (whether a single server or a server farm). If you have a
server farm, all SharePoint Portal Server 2003 installations need to be the same language version, and all portal sites in the farm must use the same language. Don’t feel
overly limited by this setup, however, as the portal sites can link to any type of content. If, for example, you have a multinational company that must support sites in Japanese, English, and Spanish, you can link to websites, Windows SharePoint Services
sites (which support multiple language packs), or other SharePoint Portal Server sites
that use any one of those languages. One common configuration calls for downloading and installing the language packs for Windows SharePoint Services, and creating
websites on the same server that use different languages. You could have SharePoint
Portal Server installed in Spanish, but then create a Windows SharePoint Services website in Japanese and another in English. You then control the clients routed to each
website through user profiles or by configuring audiences, which allow all members in a particular group, or all browsers with the default language settings for their
language, to be routed to the appropriate language site.
Chapter 3:
Installing Microsoft Office SharePoint Portal Server 2003
57
You could, for example, create a SharePoint Portal Server site that accommodates a user whose preferred language is English and a user whose preferred language is Italian. Both users have an area on the portal site that provides content and
navigation bars in his or her preferred language. This user experience is provided by
creating one portal area (called the TOP area) and two subareas (English and Italiano). Security features are used to grant access to a specific subarea to a specific
user only; in that subarea, Web Parts and navigation bars are customized to provide, as much as possible, content in the user’s preferred language.
The content itself is in a Windows SharePoint Services site which, using the
language template feature, is completely in the user’s preferred language. These
sites are connected, one for each language, to each area; portal listings are used to
target the site content to the specific area.
Audiences are used to duplicate Web Parts in the TOP area to provide the
(translated) Web Part to the right user. Audiences are also used to target portal listings so that users can add links to content on SharePoint sites to the TOP area.
Finally, two search scopes are defined to provide users with the ability to
search content in their area (and sites) only.
To set up this solution, follow these steps:
1. Create a global group for the primary language of your user community, and
add the appropriate users. For example, your English users would have a
group called EnglishLanguage, and your Japanese users would have a group
called JapaneseLanguage. Follow this pattern for all the languages used in your
environment.
2. Add the users as readers in the portal site by navigating to the Site Settings
page and clicking the Manage Users link in the General Settings section.
3. Specify the content that will be displayed for each language group by creating
audiences for each language-specific global group you’ve created. Complete
this task by clicking the Manage Audiences link on the User Profile, Audiences, And Personal Sites section of the Site Settings page.
4. Verify that the appropriate users have appropriate membership by clicking the
View Audiences link on the Manage Audiences page, clicking the arrow that
appears next to your audience’s description, and then clicking the View Membership link.
5. Create a top-level area that will contain all other language-specific subareas,
and then create a subarea for each language by using the Actions list on the
portal page, and clicking Create Subarea.
6. Customize the top-level area and each language subarea by creating Web Parts
and configuring them to be viewable based on language-specific global
groups.
58
Part I: Introduction to SharePoint Products and Technologies
More Info There is not room to describe all the steps required to perform
this customization in this book. For more detailed step-by-step instructions
on configuring SharePoint Portal Server 2003 with multiple languages, see
“Using Microsoft SharePoint Products and Technologies in Multilingual Scenarios,” at http://www.microsoft.com/technet/prodtechnol/office/sps2003
/maintain/spmultil.mspx.
7. From the Sites page, create a site for each language using the Create Site link
from the Actions list.
Define the search scopes for each language site by navigating to the Site
Settings page for the portal site, clicking the Configure Search And Indexing
link, and then configuring scopes for each language-specific area.
Firewalls
Windows SharePoint Services supports connectivity through firewalls. Depending
on your configuration, for external users to connect to the SharePoint server you
must ensure that the standard HTTP ports 80 and 443 on the firewall are open.
When using a firewall, you must configure SharePoint sites with Basic authentication because Integrated Windows authentication cannot pass through a firewall.
Note For detailed information about how to best configure SharePoint Portal Server with Microsoft ISA Server 2000, see “Announcing the ISA Server
2000 SharePoint Portal Server Deployment Kit,” by Martin Grasdal and
Thomas Shinder, at http://www.isaserver.org/articles/sharepointkit.html.
Application Coresidency and Installation Considerations
SharePoint Portal Server 2003 cannot be installed on just any server, because there
are Microsoft products that will interfere with SharePoint Portal Server and affect its
operation. For instance, installing Windows SharePoint Services prior to installing
SharePoint Portal Server causes conflicts. The following products also can cause
issues with SharePoint Portal Server 2003:
■
Microsoft SharePoint Portal Server 2001
■
Exchange Server (any version)
Chapter 3:
Installing Microsoft Office SharePoint Portal Server 2003
■
Microsoft Site Server (any version)
■
Office Server Extensions
■
Microsoft FrontPage Server Extensions (FPSE)
59
Uninstall the conflicting products before installing SharePoint Portal Server
2003. In some cases, you can make the conflicting products work together (such as
FPSE); see Technet for more detailed information.
Ensure the Account Performing the Installation Has Authority
When preparing for an installation of SharePoint Portal Server 2003, you must
ensure that the account with which you log on to the server has either local administrator or Domain Admin privileges before continuing. In addition, the account that
you’ll specify for SQL Server during setup will also need to be a member of the
Power Users group (if installing on a Member Server) or the Built-In Administrators
group (if installing on a Domain Controller).
Third-Party Database Interoperability
Microsoft SQL Server 2000 is the only database product that SharePoint Portal Server
can use to store the SharePoint Portal Server configuration and content databases;
however, it can connect to almost any third-party database products to store Web
Part information.
Using the Database Engine Option on a Domain Controller
The Microsoft SQL Server Database Engine (MSDE) option is not available when
installing SharePoint Portal Server on a domain controller. If you are to install SharePoint Portal Server on a domain controller, you must either first install SQL Server
2000 Service Pack 3 on the domain controller itself or use a remote server running
SQL Server 2000. If you require MSDE as the database repository, configure the
server running Windows Server 2003 as a member server of a domain.
More Info Best practices are to not run applications such as SharePoint
Portal Server 2003 on domain controllers. Following best practices in this
regard prevents performance issues that can result from processes competing for resources and provides more in-depth security.
60
Part I: Introduction to SharePoint Products and Technologies
Installing SharePoint Portal Server
Installing SharePoint Portal Server 2003 is fairly intuitive. If you’re performing a simple installation, you can choose the default settings and have your environment up
and running quickly. If you have to install SharePoint Portal Server on a domain
controller—or if you’re installing in a larger, more complex environment—a few
decision points will require a bit more explanation. A common example is deciding
when to use a SQL Server database instead of the default MSDE database.
When installing SharePoint Portal Server, many of the first installation steps are
the same whether you plan to install with MSDE or with SQL Server. If you are
implementing a fairly simple SharePoint Portal Server environment (one that won’t
use over 2 GB of information in the portal site and has both SharePoint Portal Server
and the database on the same machine), MSDE will probably be your best choice
(unless, of course, you need to cluster your SQL databases, in which case SQL Server
is required). One advantage of an MSDE scenario is that you don’t have to purchase
SQL Server licenses. If, however, you need to install SharePoint Portal Server on a
domain controller (DC), you must use SQL Server: MSDE is not supported on DCs.
See Table 3-2 for guidelines on when to use MSDE or SQL Server.
Table 3-2
Database Type Guidelines
Condition
Preferred Database Type
If you require more than 2 GB of storage
SQL Server
If you are installing SharePoint Portal Server on a
single server with fewer than 1000 sites
MSDE
If you require database to be located on a server other
than the server running SharePoint Portal Server
SQL Server
If you do not have access to SQL Server, but want to
work with SharePoint Portal Server
MSDE
If you plan to scale out into a server farm scenario
or use any type of multiple-server implementation
SQL Server, because the MSDE
database does not accept remote
connections
If you’re on a tight budget
MSDE
If you need a single-server deployment—for
example, when you need to deploy a single
server for application testing, for development, or
as a proof-of-concept server
MSDE
If you require the ability to cluster your databases
SQL Server 2000 Enterprise Edition
Please note that no database connector exists for databases other than MSDE or
SQL Server (such as Oracle or Sybase) for SharePoint Portal Server–specific information. Therefore, such information—including document content, area configurations, user profiles, and other information generated or hosted by SharePoint Portal
Server or Windows SharePoint Services—must be held in either a SQL Server 2000 or
Chapter 3:
Installing Microsoft Office SharePoint Portal Server 2003
61
MSDE database. If you need to access data that resides in third-party databases, such
as Oracle, you can build Web Parts that specifically reference this data—the SQL
Server/MSDE limitation only prevents provisioning third-party databases from holding SharePoint Portal Server–specific information.
There are some differences in installation when you use SQL Server instead of
the default option, MSDE. Table 3-3 explains which of the following sections apply
to either an MSDE or SQL Server configuration.
Table 3-3
Sections Describing the SharePoint Portal Server Installation
Installation Section
Used By
Installing SharePoint Portal Server
MSDE and SQL Server
Configure Account Settings and Application Pool Identity
SQL Server
Configure Database Settings
SQL Server
Configuring Account and Proxy Settings
MSDE and SQL Server
Configure Server Topology
SQL Server
Create a Portal Site
MSDE and SQL Server
To install SharePoint Portal Server 2003, follow these steps:
1. Insert the SharePoint Portal Server CD into your CD-ROM drive.
Tip If the installation does not start, click Setup.exe or Autorun.exe
located within the SPS2003 folder of your installation CD to begin setup.
2. If your CD-ROM supports Autorun, click the Install Microsoft Office SharePoint Portal Server 2003 Components link.
3. On the Install Microsoft Office SharePoint Portal Server 2003 page, review the
requirements, and then click Next.
4. The installation requires stopping the IIS services before continuing. Click OK
to have the services stopped and to continue with the installation.
Note The services stopped are the World Wide Web Publishing Service,
Simple Mail Transfer Protocol (SMTP), HTTP SSL, and IIS Admin services.
During the installation process, setup resets IIS. There will be a momentary
loss of service on the Web server.
62
Part I: Introduction to SharePoint Products and Technologies
5. Setup installs Windows SharePoint Services, and then the Welcome To The
Microsoft Office SharePoint Portal Server 2003 Setup Wizard page appears.
6. On the Welcome To The Microsoft Office SharePoint Portal Server 2003 Setup
Wizard page, click Next.
7. On the End-User License Agreement page, select the I Accept All Of The
Terms In The License Agreement check box, and then click Next.
8. On the Product Key page, type the product key in the spaces provided and
then click Next.
9. On the Installation Type And File Location page, if you will be installing with
MSDE, click Install with database engine as shown in Figure 3-1. Otherwise,
to install with SQL Server, click Install without database engine. To specify
file locations for programs and data, click Browse, specify a location, and then
click OK. Click Next to continue.
Note If the file locations you specified do not exist, you will be prompted
to create them. On the message that appears, click Yes to create the location, or click No to choose another location.
F03XR01
Figure 3-1
Choosing the database engine option and setting the default installation paths
Chapter 3:
Installing Microsoft Office SharePoint Portal Server 2003
63
10. If installing without the database engine, you will be prompted to provide the
following information as illustrated in Figure 3-2. On the Microsoft Office SharePoint Portal Server 2003 page requesting account information, in the Account
Name box, type the user account name (format DOMAIN\user_name) to be
used for administrative operations that create, modify, or grant access to
the configuration or portal site databases. In the Password and Confirm
Password boxes, type the password for the account and then click Next to
continue.
F03XR02
Figure 3-2 Configuring an account for administrative operations on the
portal site databases
Tip The account must be a member of the Power Users group on this
server. The account must have the Database Creators and Security Administrators ser ver roles on this SQL Ser ver instance. In addition, the
account must be a domain account if you have more than one server in
your configuration.
To reduce the risk of unwanted administrative access to your servers, specifying an account that is a member of the local Administrators
group on the server on which you are installing SharePoint Portal Server is
not recommended.
11. On the Install Microsoft Office SharePoint Portal Server 2003 page, click Next.
64
Part I: Introduction to SharePoint Products and Technologies
Note
It might take up to one minute for the Next button to become active.
12. On the Completing The Microsoft Office SharePoint Portal Server 2003 Setup
Wizard page, click Finish.
Configure Account Settings and Application Pool Identity
Configuring account settings and application pool identity is specific to SQL Server
installations. The following two accounts have to be defined on this page:
■
Default content access account
■
Portal site application pool identity account
The default content access account is required to read and crawl content
sources, such as websites (intranet and Internet) and network resources that are
contained within content indexes. The account creates a full-text index of content
located outside of the portal.
The portal site application pool identity account is used by the default application pool (MSSharePointPortalAppPool) created by SharePoint Portal Server to contain all portal sites. This account must be a domain account, unless you are installing
the single server with a SQL Server configuration, in which case you can use a local
account. It must also be a member of the db_owner database role in SQL Server on
the configuration database. It’s best to use a domain account regardless of your configuration, as it will allow you to extend your configuration should your SharePoint
Portal Server environment grow.
Caution If using Internet Explorer for the first time on the server, you
might be prompted by the Internet Explorer Enhanced Security Configuration
message. Select the In the future, do not show this message check box,
and then click OK to continue.
1. On the Configure Server Farm Account Settings page (shown in Figure 3-3), in
the Default Content Access Account section, select the Specify account
check box. In the User name box, type the account name in the format
DOMAIN\user_name. In the Password and Confirm Password boxes, type
the password for the account.
Chapter 3:
Installing Microsoft Office SharePoint Portal Server 2003
65
F03XR03
Figure 3-3 Configuring the default content access account and portal site application
pool identity during the installation
2. In the Portal Site Application Pool Identity section, in the User name box,
type the account name in the format DOMAIN\user_name. In the Password
and Confirm Password boxes, type the password for the account.
3. Click OK to continue to the next page.
Configure Database Settings
The configure database settings section is specific to SQL Server installations, so
MSDE users can move on to the next section. You will either create a new database
or connect to an existing configuration database and then provide the necessary
database information (SQL Server name and database name) to continue. The
options for configuring the SQL Server database repository are shown in Figure 3-4.
Figure 3-4
F03XR04
Configuring the SQL Server database settings
66
Part I: Introduction to SharePoint Products and Technologies
1. On the Specify Configuration Database Settings For server_name page, in the
Database Connections section, do one of the following:
■
If no configuration database exists, click Create configuration database.
■
If a configuration database already exists, click Connect to existing
configuration database.
2. In the Configuration Database Server section, in the Database server box,
type the name of the computer running SQL Server.
Note If you have a named SQL Server instance, specify both the name of
the computer running SQL Server and the SQL Server instance name in the
format server_name\SQL_instance_name.
3. In the Configuration Database Name section, do one of the following:
■
If you want to use the default database name that is displayed, click Use
default name.
■
If you want to specify a name for the database, click Specify custom
name, and then in the Custom name box, type a name for the database.
4. Click OK to continue to the next page.
Configure Account and Proxy Settings
When you configure server farm account settings during installation, the Web pages
will vary depending on whether you are installing with or without the database
engine. Regardless, the emphasis of this page is for you to specify how you want to
crawl content sources (websites, network resources, and servers) that will be
included in content indexes. The account, also known as the default content access
account, requires read access to the content being crawled for crawls to return successful results.
If configuring SharePoint Portal Server with MSDE, you will be prompted to
provide the contact e-mail address, default content access account, and proxy server
settings as illustrated in Figure 3-5.
Chapter 3:
Figure 3-5
F03XR05
Installing Microsoft Office SharePoint Portal Server 2003
67
Configuring account settings when using MSDE as the database
If configuring SharePoint Portal Server with SQL Server, you will be prompted
for the same information with an MSDE install without the need to specify the
default content access account. Figure 3-6 illustrates the page shown when configuring with SQL Server.
Figure 3-6
F03XR06
Configuring account settings when using a SQL Server database
68
Part I: Introduction to SharePoint Products and Technologies
On the Configure Server Farm Account Settings page, complete the following
steps:
1. In the Contact E-mail Address section, in the E-mail address box, type the
e-mail address that an external site administrator can use to contact the administrator if problems occur when SharePoint Portal Server crawls the external
site.
2. If installing with SQL Server, in the Default Content Access Account section,
select the Specify account check box, and in the User name box, type the
account name in the format DOMAIN\user_name. In the Password box, type
the password for the account, and in the Confirm Password box, type the
password again.
Note To allow for better auditing and extensibility, specify a domain
account with read access to the content being crawled. If necessary, you
can leave the default setting (NT AUTHORITY\NETWORK SERVICE), which
has more rights to data than is necessary to perform this task.
1. In the Proxy Server Settings section, do one of the following:
■
Click Do not connect by using a proxy server.
■
Click Use the proxy server specified, and then specify the proxy server
address, port number, and option to bypass proxy server for local (intranet) addresses.
Note If you are using a proxy server, the account that you use to access
the Internet must have permissions on the proxy server to create a content
index of sites on the Internet. Without permissions, you can crawl only content on your intranet.
2. Click OK to continue with the installation.
Chapter 3:
Installing Microsoft Office SharePoint Portal Server 2003
69
Configure Server Topology
Configuring the server topology is specific to SQL Server installations and involves
determining what database server settings and components should run on each of
the servers configured in a server farm configuration. The various database settings
include:
■
Configuration database server
■
Content database server
■
Component settings database server
■
Single Sign-On credentials
■
Global e-mail server
The various configurable components include: Web, search, index, and job.
To configure the server topology, complete the following steps:
1. On the Configure Server Topology page, review the current settings and then
click Change Components as shown in Figure 3-7.
F03XR07
Figure 3-7
Reviewing the server topology configuration during installation
2. On the Change Component Assignments page, in the Component Assignment section, select a check box to assign a component to a server as illustrated in Figure 3-8.
70
Part I: Introduction to SharePoint Products and Technologies
F03XR08
Figure 3-8
Tip
Changing the component assignments for the server topology
You can assign more than one component to each server.
3. In the Job Server Component section, in the Job server list, select a job
server.
4. If you have installed the server component for backward-compatible document libraries, in the Document Library Server Component (Optional)
section, in the Document library server box, type the name of the server to
run the document library server component.
5. Click OK.
6. On the Configure Server Topology page, click Close.
Create a Portal Site
The final step to installing SharePoint Portal Server is creating the portal site. To create a portal site, you will need to provide the following information:
■
Site name
■
Virtual server name to host portal
■
Site URL name
■
Owner account
■
Owner e-mail address
As noted below, some steps differ slightly depending on whether you are creating a portal using MSDE or SQL Server as the database repository.
1. If installing with SQL Server, on the SharePoint Portal Server Central Administration For server_name page, in the Portal Site and Virtual Server Configuration section, click Create a portal site.
2. On the Create Portal Site For server_name page, in the Portal Creation
Options section, click Create a portal as shown in Figure 3-9.
Chapter 3:
Installing Microsoft Office SharePoint Portal Server 2003
71
F03XR09
Figure 3-9
Creating a portal site during the installation
3. In the Site Name section, in the Name box, type a name for the portal site.
4. In the Site URL section, do the following:
■
In the Virtual server list, select the virtual server for this portal site.
■
In the URL box, type the URL that users will use to connect to the portal
site.
Note By default, this URL is http://server_name/. If you are not creating the
portal site on the Default Web Site but on another virtual server, the URL
includes the port number—for example, http://server_name:port_number/.
5. In the Owner section, do the following:
■
In the Account name box, type the account name for the portal site
owner in the format DOMAIN\user_name.
Note This account must be a domain account. This account is added to
the Administrator site group for the portal site.
■
In the E-mail address box, type the e-mail address for the portal site
owner.
72
Part I: Introduction to SharePoint Products and Technologies
6. Click OK to continue to the next page.
7. On the Create Portal Site Confirmation For Server server_name page, click OK
to begin creating the portal site as shown in Figure 3-10.
F03XR10
Figure 3-10
Confirming the creation of the portal site
The Operation Status page appears. This operation might take a few minutes to
complete.
At the end of a successful portal site creation, the Operation Successful page
appears. On this page, you will find links to launch the portal site, launch the
Administration page, or further configure the portal site.
Automated Installations
If you need to configure a large number of SharePoint Portal Server servers across an
enterprise or want to ensure consistency of installations, you can automate the
installation of SharePoint Portal Server by using either the command line or
Setup.exe with an INI file.
Using the Command Line for Installation
You can use the command line to run setup for SharePoint Portal Server by performing these actions:
1. Log on to the computer running Microsoft Windows Server 2003 as a local or
domain administrator.
2. Open command prompt.
Chapter 3:
Installing Microsoft Office SharePoint Portal Server 2003
73
3. Insert the SharePoint Portal Server CD into your CD-ROM drive.
4. Type cd\ and then press Enter.
5. Navigate to the drive letter for the CD-ROM drive.
6. For help with the setup command line parameters, type setup /?, and then
press Enter.
7. Do one of the following:
■
To install SharePoint Portal Server with the database engine, type setup
/q /o INSTALLMODE=1 PIDKEY=CD_key and then press Enter.
■
To install SharePoint Portal Server without the database engine, type setup
/q /o INSTALLMODE=0 ACCOUNTNAME=DOMAIN\user_name
ACCOUNTPASSWORD=password PIDKEY=CD_key and then press
Enter.
Note
fail.
Ensure that the CD_key has no dashes in it; otherwise, setup might
It is recommended that you turn on verbose logging by adding the following parameter to either of the above: /L*V path_to_log_file.
To monitor progress, open Task Manager and view MasterSetupApp running
in the Applications tab.
Table 3-4 shows the parameters available with the command-line setup, and
Figure 3-11 displays the command-line switches available when running setup.exe.
Table 3-4
Parameters Available with Command-Line Setup
Parameter
Description
PIDKEY=CD_key
CD_key is the key for the product. This is
required to set up SharePoint Portal Server
from the command line.
SPSROOT=path_for_files
Path_for_files is the file path that defines the
installation location for the program files for
SharePoint Portal Server.
SPSSEARCHDATA=path_for_search_files
Path_for_search_files is the file path that
defines the installation location for the content index files.
74
Part I: Introduction to SharePoint Products and Technologies
Table 3-4
Parameters Available with Command-Line Setup
Parameter
Description
INSTALLMODE=[0,1]
To install SharePoint Portal Server with the
database engine, install mode is 1. To install
SharePoint Portal Server without the database
engine, install mode is 0. This is required to
set up SharePoint Portal Server from the command line.
ACCOUNTNAME=DOMAIN\account_name
DOMAIN\account_name is the account name
for the application pool for the installation
without the database engine. This is required
if install mode is 0.
ACCOUNTPASSWORD=password
Password is the password for the account
name for the application pool. This is
required if install mode is 0.
/settings <.ini file>
Automates installation through the use of settings documented in an INI file.
/q
Sets the user interface during installation to
none (“quiet mode”).
/o
Required when passing values for PIDKEY,
SPSROOT, SPSSEARCHDATA, INSTALLMODE, ACCOUNTNAME, or ACCOUNTPASSWORD.
/L[i|w|e|f|a|r|u|c|m|p|v] <log_file.txt>
Specifies the path to the log file. The optional
flags indicate the information to log.
i
Log status messages.
W
Log nonfatal warnings.
e
Log all error messages.
f
List files in use that need replacing.
a
Log start up of actions.
r
Log user-specific records.
u
Log user requests.
c
Log initial user interface parameters.
m
Log out-of-memory or fatal exit information.
p
Log terminal properties.
v
Log verbose output.
*
Log all information.
Chapter 3:
Figure 3-11
F03XR11
Installing Microsoft Office SharePoint Portal Server 2003
75
Command-line switches used with SharePoint Portal Server’s setup.exe
Creating Sites from the Command Line
If you are an administrator of the server computer, you can also create sites by using
the Stsadm.exe command-line tool. To create a top-level website, use the createsite
operation.
Note You can also use the createsiteinnewdb operation to create a toplevel website and a new content database at the same time.
The createsite operation takes the following required parameters: url, ownerlogin,
and owneremail. It also takes the following optional parameters: ownername, lcid,
sitetemplate, title, description, and quota. For example, to create a top-level website
called site1 on http://server_name/sites, you would use syntax similar to the following:
stsadm.exe -o createsite -url http://server_name/sites/site1
-ownerlogin <DOMAIN\user> -owneremail <[email protected]>
-ownername <display name>
Using the Setup.ini File for Installation
If you are installing a large number of servers or want to customize your installation,
you can run SharePoint Portal Server setup in unattended mode by using an .ini file.
When you install SharePoint Portal Server by using an .ini file, no dialog boxes or
error messages that require user intervention are displayed unless there is no entry
76
Part I: Introduction to SharePoint Products and Technologies
in the .ini for a setting. This setup lets you install identical configurations of SharePoint Portal Server on multiple computers in a consistent, automated fashion.
Note You will not be able to set up remote database installations using
the .ini file, as the account name and password listed are valid only for the
MSI session being executed for the SharePoint Portal Server installation,
and they will not extend to create the Administrative Virtual Server or Application Pool. To automate remote database installations, use the command
line.
A Setup.ini file for SharePoint Portal Server 2003 is provided on the root directory of the SharePoint Portal Server CD. A Setup.ini file is also provided for the client
components for backward-compatible document libraries. However, you must create the Setup.ini file for the (server) component for backward-compatible document
libraries. Instructions to do this are provided later in this section.
You can use the Setup.ini file to do the following:
■
Install additional applications (other than SharePoint Portal Server) that use
Microsoft Windows Installer.
■
Specify different command-line arguments for different applications. For example, if you install additional applications, you can specify that one application
installs with no user interface while another application installs with full user
interface.
By default, Setup.ini contains the following code:
[MSI]
ProductName=Microsoft(R) Windows(R) SharePoint(TM) Services
ProductRelativeLocation=WSS\STS.MSI
[MSI]
ProductName=SharePoint Portal Server
ProductRelativeLocation=SPS\SPS.MSI
[MSI]
ProductName=Microsoft SQL Server Desktop Engine
ProductRelativeLocation=SPS\SQLRUN16.MSI
ProductRelativeLocation is the path to the directory that contains the Setup.exe
file.
You can include the parameters shown in Table 3-5 in the Setup.ini file.
Chapter 3:
Table 3-5
Installing Microsoft Office SharePoint Portal Server 2003
77
Parameters in the Setup.ini File
Parameter
Description
PIDKEY=CD_key
CD_key is the key for the product.
SPSROOT=path_for_files
Path_for_files is the file path that defines the
installation location for the program files for
SharePoint Portal Server.
SPSSEARCHDATA=path_for_search_files
Path_for_search_files is the file path that
defines the installation location for the content
index files.
INSTALLMODE=[0,1]
To install SharePoint Portal Server with the
database engine, install mode is 1. To install
SharePoint Portal Server without the database
engine, install mode is 0. This is required to set
up SharePoint Portal Server from the command
line.
ACCOUNTNAME=DOMAIN\account_name DOMAIN\account_name is the account name
for the application pool for the installation
without the database engine. This is required if
install mode is 0.
ACCOUNTPASSWORD=password
Password is the password for the account
name for the application pool. This is required
if install mode is 0.
Warning: When you put the password in the
Setup.ini file, the password is in plain text.
INSTALLLOCATION=path_to_directory
Path_to_directory is the file path that defines
the installation location for additional MSIs that
you include in the Setup.ini file.
Tip Preface the parameters with Arg= and a space, as shown in this example:
[MSI]
ProductName=Microsoft(R) Windows(R) SharePoint(TM) Services
ProductRelativeLocation=WSS\STS.MSI
[MSI]
ProductName=SharePoint Portal Server
ProductRelativeLocation=SPS\SPS.MSI
Arg= INSTALLMODE=0 PIDKEY=CD_key ACCOUNTNAME=Domain\user_name ACCOUNTPASS
WORD=password
[MSI]
ProductName=Microsoft SQL Server Desktop Engine
ProductRelativeLocation=SPS\SQLRUN16.MSI
78
Part I: Introduction to SharePoint Products and Technologies
You can use ProductLocation instead of ProductRelativeLocation for additional
applications.
Using Setup.ini to Install SharePoint Portal Server and an Additional Application
In the following example, the relative location is the path to the directory that contains Setup.exe, so AnotherProduct.msi will be located in a folder called Other in the
same directory as Setup.exe:
[MSI]
ProductName=Microsoft(R) Windows(R) SharePoint(TM) Services
ProductRelativeLocation=WSS\STS.MSI
[MSI]
ProductName=SharePoint Portal Server
ProductRelativeLocation=SPS\SPS.MSI
[MSI]
ProductName=Microsoft SQL Server Desktop Engine
ProductRelativeLocation=SPS\SQLRUN16.MSI
[MSI]
ProductName=Another_Product
ProductRelativeLocation=Other\AnotherProduct.MSI
Passing in different arguments to each application In the following example,
two additional applications are installed, in different locations:
[MSI]
ProductName=Microsoft(R) Windows(R) SharePoint(TM) Services
ProductRelativeLocation=WSS\STS.MSI
[MSI]
ProductName=SharePoint Portal Server
ProductRelativeLocation=SPS\SPS.MSI
Args= INSTALLMODE=1
[MSI]
ProductName=Microsoft SQL Server Desktop Engine
ProductRelativeLocation=SPS\SQLRUN16.MSI
[MSI]
ProductName=Another_Product
ProductLocation=G:\AnotherProduct.MSI
Args= INSTALLMODE=3 INSTALLLOCATION="C:\Program Files\Another_Product_Location"
[MSI]
ProductName= Another_Product_2
ProductRelativeLocation=Other\AnotherProduct2.MSI
Args= INSTALLLOCATION=C:\AnotherProduct2
Installing SharePoint Portal Server with the Database Engine, with No User
Interface Displayed and Verbose Logging
In this example, SharePoint Portal Server will be installed to a folder called SharePoint on drive C, and the log files will be written to drive C using verbose logging.
The SharePoint Portal Server CD is in drive F.
Chapter 3:
Installing Microsoft Office SharePoint Portal Server 2003
79
1. Copy Setup.ini from the SharePoint Portal Server CD to C:\SharePoint.
2. Modify Setup.ini as shown:
[MSI]
ProductName=Microsoft(R) Windows(R) SharePoint(TM) Services
ProductRelativeLocation=WSS\STS.MSI
[MSI]
ProductName=SharePoint Portal Server
ProductRelativeLocation=SPS\SPS.MSI
Args= INSTALLMODE=1 PIDKEY=CD_key
[MSI]
ProductName=Microsoft SQL Server Desktop Engine
ProductRelativeLocation=SPS\SQLRUN16.MSI
3. Open a command prompt and navigate to drive F.
4. Type setup /q /settings c:\setup.ini /L*V c:\log.txt and press Enter.
Using the .ini File to Install the Component for Backward-Compatible Document
Libraries
To use an .ini file to install the server component for backward-compatible document libraries, you must first create an .ini file that contains the default installation
settings that you want to use, such as the installation directory. After you create the
.ini file, you can edit it by using a text editor. By editing the .ini file, you specify
additional options and gain more control over your installation.
To create the .ini file used for unattended setup, you must run the Microsoft
Office SharePoint Portal Server 2003 Setup Wizard. However, instead of installing
SharePoint Portal Server, the wizard stores the settings that you specify in the .ini
file.
Double-byte character set (DBCS) or high-ASCII characters cannot be used in
installation paths when performing an unattended installation. Using these characters results in a failed installation. In addition, no path in the .ini file should be
longer than 140 characters.
Follow these steps to install the component for backward-compatible document libraries by using an .ini file:
1. Log on to the computer running Microsoft Windows Server 2003 as a local or
domain administrator.
2. Perform the following steps to ensure that the proxy server settings for Internet
access are specified correctly:
1. Click Start, point to Control Panel, and then click Internet Options.
2. In the Internet Properties dialog box, click the Connections tab.
3. Click LAN Settings.
80
Part I: Introduction to SharePoint Products and Technologies
4. In the Local Area Network (LAN) Settings dialog box, in the Automatic
configuration section, ensure that both check boxes are cleared.
5. If you use a proxy server, complete step 6 through step 11. Otherwise, go
to step 12.
6. In the Proxy server section, select the Use a proxy server for your LAN
(These settings will not apply to dial-up or VPN connections) check
box.
7. Select the Bypass proxy server for local addresses check box.
8. In the Address box, type a valid proxy server address.
9. In the Port box, type the port number for the proxy server.
10. Click Advanced.
11. In the Proxy Settings dialog box, select the Use the same proxy server
for all protocols check box, and then click OK.
12. Click OK to close the Local Area Network (LAN) Settings dialog box.
13. Click OK to close the Internet Options dialog box.
3. Insert the SharePoint Portal Server CD into your CD-ROM drive.
4. Create an .ini file:
1. On the taskbar, click Start, and then click Run.
2. In Open, type path_to_server_setup_file setup /CreateUnattend path
filename.ini where filename is the name of the .ini file that you want to
create. For example, if the setup file is in the Setup directory on drive D
and you want to create sample.ini on the E drive, type D:\Setup\setup
/CreateUnattend E:\sample.ini.
3. Click OK.
4. Follow the instructions that appear in the setup wizard. All settings that you
choose are included in the .ini file that you create.
5. Edit the .ini file:
1. In a text editor, such as Microsoft WordPad, open filename.ini where filename is the name of the .ini file that you created.
2. Modify parameters in the file for the settings that you want SharePoint
Portal Server setup to use.
3. If you plan to use an unattended installation file on servers with varying storage configurations, ensure that hard-coded paths are valid for each server
configuration before starting the installation. An example of a hard-coded
Chapter 3:
Installing Microsoft Office SharePoint Portal Server 2003
81
path reference is “C:\.” You can force the installer to automatically choose
the correct default path by removing an entry line completely.
4. You can modify the following path in the section starting with [gfn_mid
microsoft web storage system]:
InstallDirectory=C:\Program Files\Common Files\Microsoft Shared\Web Storage Sy
stem
The following restrictions apply:
The path cannot be at the root of a hard drive (for example, do not
change the path to “F:\”).
The entire path consists of only low-ASCII characters (no High-ASCII or
DBCS characters).
The path is no longer than 65 characters.
6. You can also modify the following paths in the section starting with
microsoft sharepoint portal server]:
[gfn_mid
InstallDirectory=”C:\Program Files\SharePoint Portal Server”
Web Storage System Database Directory=”C:\Program Files\SharePoint Portal Serv
er\DMData\Web Storage System”
Web Storage System Streaming Database Directory=”C:\Program Files\SharePoint P
ortal Server\DMData\Web Storage System”
Web Storage System Database Log Directory=”C:\Program Files\SharePoint Portal
Server\DMData\Web Storage System”
7. Run setup:
1. On the taskbar, from the server on which you want to run setup, click Start,
and then click Run.
2. In Open, type installation path\setup /UnattendFile path filename.ini
where filename is the name of the .ini file that you created.
For example, if the SharePoint Portal Server CD is in drive F, you would
type F:\Optional\Server\setup /q /settings c:\setup.ini
3. Click OK.
Migrating from WMSDE to SQL Server
When you install Windows SharePoint Services on a single server choosing the
default settings, your installation will use Microsoft SQL Server 2000 Desktop Engine
(Windows) (WMSDE) for your databases. This is fine in a small-scale environment,
when you are hosting just a few websites, but if your server suddenly gets popular
and you need to start hosting hundreds of sites, you might run into performance and
storage problems or require a clustered database for high availability. If you find
yourself in one of these situations, you can scale out by switching to Microsoft
SQL Server 2000 Service Pack 3 (SP3) as your database back end. For step-by-step
82
Part I: Introduction to SharePoint Products and Technologies
information on migrating from WMSDE to SQL Server 2000, refer to the “Upgrading
from WMSDE to SQL Server” section in Chapter 2.
Installing the Component for Backward-Compatible
Document Libraries
Backward-compatible document libraries allow you to access the same store (the
extensible storage engine Web storage system) that was available in SharePoint Portal Server 2001. If you don’t have a previous version of SharePoint Portal Server, you
will not need to install this feature. If, however, you need to retain the old store system or if you’d like to use the workflow features that come with this database, you
can install the optional component for backward-compatible document libraries on
either a computer that has SharePoint Portal Server 2003 installed or on a computer
without SharePoint Portal Server installed.
Install the Component for Backward-Compatible Document Libraries
Before you can install the component for backward-compatible document libraries,
ensure that the proxy server settings for Internet access are specified correctly by
referring to steps provided earlier in the chapter. Then follow these steps:
1. Insert the SharePoint Portal Server CD into your CD-ROM drive.
2. Click Install optional components.
3. On the installation page for optional components, click Install server and client components for backward-compatible document libraries as shown
in Figure 3-12.
F03XR12
Figure 3-12
Installing the backward-compatible document library components
4. On the Welcome To The Document Library Setup Wizard page, click Next.
5. On the License Agreement page, read the license agreement. If you agree with
the terms of the agreement, click I agree, and then click Next.
6. On the Product Identification page, type the product key in the spaces provided and then click Next.
Chapter 3:
Installing Microsoft Office SharePoint Portal Server 2003
83
7. On the Document library component of Microsoft Office SharePoint Portal
Server 2003 Setup page, specify the location on the server disk where you want
to install the program and data files for the document library component.
If you are installing the optional components on a server that already has
SharePoint Portal Server installed, you cannot choose the location for the program files. If you are installing the optional components on a server that does
not have SharePoint Portal Server installed, you can choose the location for the
program files.
SharePoint Portal Server also installs additional required files on the operating system drive. Click Disk Information for information about the amount of
disk space required and the amount remaining. If there are existing files in the
installation paths, setup removes these files.
More Info The path must meet the following restrictions: can contain no
more than 80 characters; the path name can contain only characters in the
lower ASCII range; and, the path cannot point to a root directory.
8. Click Next. A message that lists services that will be stopped appears.
9. Click OK to stop the services and continue.
The Component Progress page appears.
10. On the Completing the Document Library Setup Wizard page, click Finish.
You might be prompted to restart your computer.
After the setup wizard completes, perform the following steps to make the
optional document library component functional:
1. Change component assignments for the server farm.
2. Create a document library.
3. Manage security for a backward-compatible document library.
Installing the Client Components for Backward-Compatible Document
Libraries
The client components are extensions to Microsoft Windows Explorer and Microsoft
Office applications. There is no individual client application. These extensions integrate SharePoint Portal Server 2003 commands with Windows Explorer and Office
applications. Users can also access document libraries (Web Storage System–based)
from the portal site without installing the client components, but they will not experience the integration with Windows Explorer and Office applications.
84
Part I: Introduction to SharePoint Products and Technologies
You can install the client components by running setup either from the server
or from the SharePoint Portal Server CD. By default, the setup wizard installs client
installation files to the following location on the server: %SystemDrive%\Program
Files\SharePoint Portal Server\ClientDrop\Languages\Language, where Language
corresponds to the language of the client. The following steps outline the procedures for installing the client components:
1. Insert the SharePoint Portal Server CD into your CD-ROM drive.
2. Click Install optional components.
3. On the installation page for optional components, click Install client components for backward-compatible document libraries.
4. On the Welcome To Client Components Setup Wizard page, click Next.
The Install Client Components page appears. This page shows the
progress of the installation.
5. On the Completing The Client Components Setup Wizard page, click Finish.
After you have installed the client components, you must add a Web folder that
points to the document library. The address of the document library is http:
//server_name/document_library_name.
More Info The steps for adding a Web folder vary, depending on your operating system. See your operating system Help for detailed instructions. For
example, in Microsoft Windows 2000 Professional or Microsoft Windows XP
Professional, go to My Network Places and use the Add Network Place
Wizard to add a Web folder. In Microsoft Windows 98, go to Web Folders in
My Computer and use Add Web Folder to add a Web folder.
Repairing the Client Components for Backward-Compatible Document
Libraries
You can repair the client components for backward-compatible document
libraries (Web Storage System–based) of Microsoft Office SharePoint Portal Server
2003 by using Add Or Remove Programs in Control Panel. You can also use the
command line to repair client components.
Repair the Client Components for Backward-Compatible Document
Libraries by Using Control Panel
Using Control Panel, complete the following steps to successfully repair an install of
the client components:
Chapter 3:
Installing Microsoft Office SharePoint Portal Server 2003
85
1. Open Add or Remove Programs.
2. In the Add or Remove Programs dialog box, click Client Components for
Microsoft Office SharePoint Portal Server 2003.
3. Click Change.
4. On the Welcome To The Client Components Setup Wizard page, click Next.
5. On the Maintenance Mode Options page, click Repair the client components of the document management component of SharePoint Portal
Server, and then click Next.
6. On the Ready To Repair The Program page, click Install.
The Install Client Components progress page appears, and Windows
repairs the client components.
7. On the Completing The Client Components Setup Wizard page, click Finish.
Repair the Client Components for Backward-Compatible Document
Libraries from the Command Line
Another method of repairing the client components is to use the command line. The
following steps will repair an installation from the command line.
1. Open a command prompt window.
2. Type “path\setup” /f “path\SPSClient.msi", where path is the path to the
Setup.exe and SPSClient.msi files.
Tip
Include the switch /f to repair the client components.
For example, to repair the client components, where Setup.exe and SPSClient.msi are in E:\Client Files, you would type E:\Client Files\setup” /f “E:\Client
Files\SPSClient.msi”.
Note If you have removed one or more of the installation prerequisites,
you cannot repair the client components unless you disable the prerequisite
check. You can disable the prerequisite check by adding DISABLEPREREQ=1 to the command line. To disable the prerequisite check in the preceding example, you would type E:\Client Files\setup” /f “E:\Client
Files\SPSClient.msi” DISABLEPREREQ=1.
86
Part I: Introduction to SharePoint Products and Technologies
Installing SharePoint Portal Server into a Non–Active
Directory Environment
Active Directory is not required for Windows SharePoint Services or SharePoint Portal Server 2003. However, without Active Directory, you cannot prepopulate and
synchronize the SharePoint Portal Server profile database with the list of users from
Active Directory, and users’ personal sites are not registered for cross-farm synchronization in a multiserver configuration.
SharePoint Portal Server is supported only on servers that are members of a
Microsoft Windows NT 4.0, Windows 2000, or Windows Server 2003 domain. Installing and operating a SharePoint Portal Server computer is supported if your server is
a member of a domain or a member of a workgroup. (Domain installations are more
easily administered, however.) All servers in a server farm must be members of the
same domain.
For best results, deploy SharePoint Products and Technologies in an Active
Directory environment.
Uninstalling SharePoint Portal Server 2003
SharePoint Portal Server 2003 can be uninstalled by using Add/Remove Programs.
Removing SharePoint Portal Server does not remove the following items from your
server:
■
Windows SharePoint Services
■
Microsoft SQL Server Desktop Engine (if installed)
■
Microsoft SQL Server (if installed locally)
■
Component for backward-compatible document libraries.
Microsoft recommends you remove the applications in this order:
1. SharePoint Portal Server
2. Windows SharePoint Services
3. SQL Server Desktop Engine (if installed)
4. SQL Server (if installed locally)
Warning Most files and subfolders located in installation folders will be
removed. All Microsoft SQL Server databases will be detached, but not
removed, from the database server. When you remove SharePoint Portal
Server, all user data is left in the database files. These files are also left
behind if you remove SQL Server Desktop Engine or Microsoft SQL Server.
Chapter 3:
Installing Microsoft Office SharePoint Portal Server 2003
87
Uninstall SharePoint Portal Server
In the case that you will need to uninstall SharePoint Portal Server, perform two
steps: first uninstall SharePoint Portal Server, and then proceed to uninstalling Windows SharePoint Services. The steps for uninstalling SharePoint Portal Server are as
follows:
1. Click Start, point to Control Panel, and then click Add or Remove Programs.
2. In the Add or Remove Programs dialog box, click Microsoft Office SharePoint Portal Server 2003.
3. Click Change.
4. On the Welcome To The Microsoft Office SharePoint Portal Server 2003 Setup
Wizard page, click Next.
5. On the Maintenance Mode Options page, click Remove the server components of Microsoft Office SharePoint Portal Server 2003 as illustrated in
Figure 3-13, and then click Next.
F03XR13
Figure 3-13
Maintenance Mode options for SharePoint Portal Server
6. In the confirmation message box, click Yes to remove SharePoint Portal Server,
as shown in Figure 3-14.
88
Part I: Introduction to SharePoint Products and Technologies
F03XR14
Figure 3-14 Warning message informing how the uninstall will handle files and
SQL databases
7. Click OK to allow Setup to stop the necessary services and continue with the
removal of SharePoint Portal Server. The removal of SharePoint Portal Server
will take a few minutes.
8. Click OK to complete the removal of SharePoint Portal Server.
You can now use Add Or Remove Programs to remove Windows SharePoint
Services and SQL Server Desktop Engine or SQL Server (if installed). For more information on uninstalling Windows SharePoint Service, refer to Chapter 2.
Optionally, after you have removed SharePoint Portal Server, Windows SharePoint Services, and SQL Server Desktop Engine (if installed), you can also remove
the following items if applicable:
1. If your installation of SharePoint Portal Server used SQL Server Desktop Engine,
delete the folder \Program Files\Microsoft SQL Server\MSSQL$SHAREPOINT on
the operating system drive.
2. If your installation of SharePoint Portal Server used Microsoft SQL Server,
remove the following databases associated with SharePoint Portal Server:
■
site_name_PROF
■
site_name_SERV
■
site_name_SITE
■
SharePoint Portal Server configuration database. By default, this database
is named SPS_Config_db.
■
Remove all jobs for the SQL Server instance of SharePoint Portal Server.
All relevant jobs are named site_name_SERV Subscription Cleanup.
3. Remove any application pools that were created by SharePoint Portal Server.
Repairing SharePoint Portal Server
You can repair the installation of SharePoint Portal Server 2003 by selecting the
Change option in the Add Or Remove Programs dialog box, and then choosing
Repair on the Maintenance Mode Options page.
Chapter 3:
Installing Microsoft Office SharePoint Portal Server 2003
89
The Repair option is beneficial when you need to repair or restore the SharePoint Portal Server binary files. A repair does not modify or fix the indexes or databases in use by SharePoint Portal Server.
Troubleshooting SharePoint Portal Server
Installations
There have been documented issues with installing SharePoint Portal Server. This
section will outline the major problems that have been discovered to date.
For further information, refer to the Microsoft Support website at http:
//support.microsoft.com.
“Error 502” Error Message When Trying to Access SharePoint Central
Administration Pages
This message occurs when you run SharePoint Portal Server Setup to install SharePoint Portal Server 2003 and MSDE on the server, and then click Finish on the Completing The Microsoft Office SharePoint Portal Server 2003 Setup Wizard page. The
symptom is that the Configure Server Farm Account Settings page of SharePoint
Central Administration is not displayed in your Web browser window. Instead, you
receive an Error 502 message.
This problem can occur if a proxy server is configured in Internet Explorer but
the Bypass Proxy Server For Local Addresses option is not enabled. SharePoint Portal Server Setup does not look to see whether proxy server settings in Internet
Explorer are configured correctly on the server. The problem can also occur in situations when you install Windows Server 2003 from a Remote Installation Services
(RIS) server by using a RIS image that uses the default proxy server settings for Internet Explorer in which the Bypass Proxy Server For Local Addresses option is not
enabled.
To work around this problem, enable the Bypass Proxy Server For Local
Addresses option in the proxy server settings of Internet Explorer. To do so, follow
these steps:
1. Start Internet Explorer.
2. On the Tools menu, click Internet Options.
3. Click the Connections tab, and then under Local Area Network (LAN) Settings, click LAN Settings.
4. Under Proxy server, select the Bypass proxy server for local addresses
check box, and then click OK.
5. Click OK.
90
Part I: Introduction to SharePoint Products and Technologies
The Configure Server Farm Account Settings Page Does Not Appear
When you run Setup to install SharePoint Portal Server 2003 you might find that the
Configure Server Farm Account Settings page is not displayed and the SharePoint
Central Administration Site is not configured correctly; this problem occurs after you
complete these steps:
1. Specify the user account that you want to use as the Configuration Database
Administration Account on the SharePoint Portal Server page that requests
account information.
2. Click Next on the Install Microsoft Office SharePoint Portal Server 2003 page.
3. Click Finish on the Completing The Microsoft Office SharePoint Portal Server
2003 Setup Wizard page.
Additionally, you might experience the following symptoms:
■
■
When you view SharePoint Portal Server 2003–related settings in Microsoft
Internet Information Services (IIS) Manager, the following symptoms occur:
■
When you expand websites and view the entry for the SharePoint Central
Administration site in the right pane, the State of the site appears as
Stopped.
■
When you right-click the SharePoint Central Administration Site,
click Properties, and then click the Home Directory tab, the value that
is displayed in the Application pool box is <Invalid App Pool>.
■
When you expand Application Pools, the CentralAdminAppPool Application Pool is not listed.
■
If you create a new application pool named CentralAdminAppPool and
you start SharePoint Central Administration, you are repeatedly prompted
to enter your user name and password. After you are prompted to enter
your user name and password several times, you receive the following
error message: “You do not have permission to view this page.”
An error message that is similar to the following message is logged to the
Spsadm.log file:
0000059E UNK 00000000 00000600 Service account name is ’SPSUser’. 0000059E UNK
00000000 00000600 An exception occurred while setting the administration cred
entials. Microsoft.SharePoint.Portal.Topology.p: Error occurred while stopping
services. See the event log for details. --> System.ComponentModel.Win32Exception: The account name is invalid or does no
t exist, or the password is invalid for the account name specified at Microsof
t.SharePoint.Portal.Topology.y.a(q A_0, String A_1, String A_2) ...
Chapter 3:
■
Installing Microsoft Office SharePoint Portal Server 2003
91
An error message that is similar to the following message is logged to the
W3wp.log file:
000002CE UNK 00000000 00000980 Url Path: “/sps/FarmDatabase.aspx”
0000031C UNK 00000000 00000980 ShipAssert 0000 Microsoft.SharePoint.Library.SP
RequestInternalClass.RenderFormDigest(String bstrUrl), Unhandled exception cau
ght during execution of Microsoft.SharePoint.Portal.PageBase::ErrorHandler().
Exception information: Exception information: Microsoft.SharePoint.SPException
: Cannot complete this action. Please try again. --> System.Runtime.InteropServices.COMException (0x80004005): Cannot complete th
is action. Please try again. at Microsoft.SharePoint.Library.SPRequestInternal
Class.RenderFormDigest(String bstrUrl) at Microsoft.SharePoint.Library.a.k(Str
ing A_0) --- End of inner exception stack trace ---
■
The following event is logged to the application event log:
Event Type: Warning
Source: W3SVC
Category: None
Event ID: 1048
Description:
The application ’/
’ belonging to site ’SiteName’ has an invalid AppPoolId ’CentralAdminAppPool’
set. Therefore, the application will be ignored.
This issue occurs if the user account that you configured as the Configuration Database Administration Account in the Account Name box of the
Microsoft Office SharePoint Portal Server 2003 page is specified incorrectly.
This issue can occur if either one of the following conditions is true:
■
You configure a local user account as the Configuration Database Administration
Account, but you do not specify the user account by using the ServerName\UserAccount format.
■
You configure a domain user account as the Configuration Database Administration Account, but you do not specify the user account by using the
Domain\UserAccount format.
To resolve this issue, remove and then reinstall SharePoint Portal Server 2003
on the server. Make sure that you specify the user account that you want to use as
the Configuration Database Administration Account by using either the ServerName\UserAccount format or the Domain\UserAccount format (as appropriate to
your situation). The user account must also be a member of the Power Users group
on the server.
92
Part I: Introduction to SharePoint Products and Technologies
Summary
This chapter outlined the steps to install SharePoint Portal Server 2003 in several scenarios. It began by explaining the prerequisite requirements for a SharePoint Portal
Server 2003 installation, and then continued by outlining how to install SharePoint
Portal Server 2003 with MSDE or SQL Server 2000. The second half of the chapter
touched on installing the components for the backward-compatible document
library, and how to work with SharePoint Portal Server in a non–Active Directory
environment. Finally, we concluded the chapter by explaining how to uninstall and
repair a SharePoint Portal Server 2003 installation.
Part II
SharePoint Products and
Technologies Architecture
In this part:
4
Windows SharePoint Services Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
5
SharePoint Portal Server Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
6
Security Architecture for SharePoint Products and Technologies . . . . . . . . . . . . 125
7
Architecting SharePoint Products and Technologies for Operating
System Topologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
Chapter 4
Windows SharePoint
Services Architecture
In this chapter:
Architectural Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
Physical Configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
IIS Services Used by Windows SharePoint Services . . . . . . . . . . . . . . . . . . 99
Changes Made by Windows SharePoint Services . . . . . . . . . . . . . . . . . . . 100
Web Part Pages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
Customization and Personalization for Web Parts. . . . . . . . . . . . . . . . . . . 105
Exporting Web Parts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
Handling Site Page Requests. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
Templates. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
The Web.Config File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
Microsoft Windows SharePoint Services is the underlying technology on which
SharePoint Products and Technologies run. Understanding the architecture of Windows SharePoint Services, both logical and physical, aids an administrator’s understanding of not only how the product should be configured, but also which settings
have far-reaching effects and which have little impact. This chapter discusses the
components of Windows SharePoint Services and how these components interact
with each other. This includes how Windows SharePoint Services affect Microsoft
Windows Server 2003 services that it runs on and uses.
Although SharePoint Products and Technologies have changed dramatically
from version 1.0, some of the underlying architecture remains the same. Windows
SharePoint Services handles page requests much the same way that SharePoint
Team Services does. In fact, one of the biggest architectural differences between
Windows SharePoint Services and SharePoint Team Services is in the way that Windows SharePoint Services stores data and configuration information.
95
96
Part II:
SharePoint Products and Technologies Architecture
In SharePoint Team Services v1.0, the configuration and site content information was spread out between the local file system, the registry, the Internet Information Server (IIS) metabase, and SQL Server databases. In Windows SharePoint
Services, all data is stored in Microsoft SQL Server 2000 or Windows Microsoft SQL
Server 2000 Desktop Engine (WMSDE) databases. This includes all site content, documents, product information, and configuration settings.
Note The WMSDE database that ships with Windows SharePoint Services
does not have a 2-GB limit. The standard MSDE database that can be
installed with Microsoft Office SharePoint Portal Server 2003 does have a
2-GB storage limit.
Architectural Components
The result of Windows SharePoint Services storing all information in databases is a
complete split between front-end and back-end components. The front-end components in Windows SharePoint Services are Web servers that host the individual sites
and process client requests. Front-end Web servers are referred to as stateless because
they contain no website content or configuration information. To complete a client
request, the front-end server connects to a back-end database to retrieve the needed
data so that it can build and send the Web page to the client. Figure 4-1 shows the
relationship between front-end Web servers and back-end database servers.
Client can make a connection
to any front-end Web server to
request a site page
Load Balancing
Front-end
Web
Front-end
Web
Front-end Web servers can
connect to any back-end
database to retreive site data
Data
Data
Figure 4-1 The logical architecture of Windows SharePoint Services includes a client requesting
pages from front-end Web servers, which in turn get all data from back-end databases
F04XR01
Chapter 4:
Windows SharePoint Services Architecture
97
Note The split between front-end and back-end components in Windows
SharePoint Services is a logical one. Physically, the front-end and back-end
components can exist on the same server or on separate servers.
Improvements over SharePoint Team Services
By separating front-end and back-end components, Windows SharePoint Services
has some dramatic improvements in key areas over SharePoint Team Services. Each
of the improvements in the following list affects configuration decisions:
■
Backup. Consolidating all site content and configuration information into
one type of storage simplifies the backup process.
■
Scalability. Windows SharePoint Services can be scaled down to a single
server that contains both front-end and back-end components, or it can be
scaled up to several front-end Web servers accepting requests and gathering
data from multiple back-end database servers.
■
Availability. Multiple front-end Web servers can host the same site content,
allowing others to take over if one fails. Also back-end databases can be clustered for automatic failover.
■
Integrity of data. Consolidating all the settings and data into one location
and one format protects the data.
■
Customization. Administrators with only an introductory understanding of
Web development, using an HTML editor, can customize the many templates
and properties available in Windows SharePoint Services. For in-depth customizations, a developer needs to know only ASP.NET Web pages and form controls. For back-end customizations, a programming knowledge of SQL Server is
needed.
Front-End Web Servers
The front-end Web servers in Windows SharePoint Services use the Web services
provided by Internet Information Services (IIS) in Windows Server 2003. The purpose of these front-end Web servers is just to service requests from clients. They are
considered stateless because they install only the minimum files and settings needed
to be able to connect to the correct back-end database and retrieve requested site
pages and content.
98
Part II:
SharePoint Products and Technologies Architecture
Back-End Databases
Whether a separate SQL Server or WMSDE is used, the back-end server in Windows
SharePoint Services creates and uses back-end databases. The purpose of having
two database types is to separate the site data from the configuration information. A
database that contains site data is called a content database, while product information and settings are contained in what is called a configuration database. There can
be a single content database in a small environment, but in a large environment
there can be hundreds or even thousands of content databases. No matter how
many content databases exist in a Windows SharePoint Services farm, there is only
one configuration database.
Configuration Database
In a Windows SharePoint Services environment, there can be multiple front-end
Web servers that contain several websites whose content is stored in one of a number of back-end content databases. To keep the front-end Web servers stateless, a
centralized database is needed to keep track of which content database holds the
data for a specific site. When a front-end Web server receives a request for a page
from a site, the first connection it must make is to this configuration database. For
performance reasons, this information is cached on the front-end Web server for
subsequent requests and the cached information is used by the front-end Web server
thereafter.
Content Database
Content databases provide content to the front-end Web servers when it is
requested. All site content—including site documents, list data, Web Part properties,
as well as user names and rights—are stored in content databases. You can create as
many content databases as needed to support the websites on your servers. This can
range from just one to thousands, depending on the number of users.
Physical Configurations
With the split of front-end and back-end services, administrators now have the flexibility to configure Windows SharePoint Services in several ways. By providing any
configuration from a single server to a server farm, Windows SharePoint Services
can scale to suit small to large organizations.
An organization with fewer users can start with a single-server installation of
Windows SharePoint Services. This means that both the front-end and back-end
components are installed on the same physical server. In this configuration, WMSDE
can be used for the back-end databases instead of SQL Server. If the number of users
in an organization grows enough to require a physical separation of front-end and
back-end components, the WMSDE databases can be migrated to SQL Server. To do
Chapter 4:
Windows SharePoint Services Architecture
99
this requires several steps and the use of IIS, Windows SharePoint Services, and SQL
Server administration tools, but it can be done.
A server farm in Windows SharePoint Services can have identically configured
front-end Web servers that all connect to the same configuration database. Load-balancing software such as Network Load Balancing (NLB) or load-balancing hardware
can ensure that client requests are evenly distributed among the front-end Web servers. This not only distributes the load among several front-end Web servers, but it
also allows them to provide failover for each other.
IIS Services Used by Windows SharePoint Services
Windows SharePoint Services works only with a specific set of software. This software
includes Windows 2003 as the operating system with IIS and ASP.NET installed on the
front-end servers. Back-end components require a separate installation of SQL Server
2000 or WMSDE. WMSDE is included as part of Windows SharePoint Services.
Windows SharePoint Services relies on several services that are provided by IIS
for its Web services. Figure 4-2 shows the architecture of how IIS handles Web
requests before Windows SharePoint Services is installed.
Windows 2003
IIS
Virtual Servers
Authentication
Application Pools
ASP.NET
Figure 4-2 Figure displaying required software and underlying services needed by Windows
SharePoint Services front-end Web servers
F04XR02
Virtual Servers
IIS uses virtual servers to give websites administrative, security, and resource boundaries. The default virtual server installed by IIS is named Default Web Site and is
located at the \inetpub\wwwroot folder. Windows SharePoint Services uses virtual
servers provided by IIS to host its websites.
Application Pools
Application pools were introduced as part of IIS 6. Each application pool is an isolated set of worker processes in which Web applications are run. This means that
different application pools use separate processor and memory resources. An application pool is also a security boundary because each application pool requires its
own set of credentials on the server. Windows SharePoint Services uses IIS application pools for handling resource allocation in its websites.
100
Part II: SharePoint Products and Technologies Architecture
Authentication
IIS performs authentication to validate user accounts that try to access its Web services. Authentication works on a per-virtual-server basis in IIS and in Windows
SharePoint Services. Windows SharePoint Services lets IIS handle authentication on
the front-end Web server—so much so that changes to authentication must occur in
IIS administrative tools as well as in Windows SharePoint Services administrative
tools. See Chapter 6, “Security Architecture for SharePoint Products and Technologies,” for full details on the authentication in websites.
ASP.NET
When IIS installs, it has only a minimum configuration and does not install many of
the features that it includes. This is for security reasons. Because many Windows
SharePoint Services components are built on ASP.NET, the Application Server component for ASP.NET must also be installed in IIS before beginning an installation of
Windows SharePoint Services.
Changes Made by Windows SharePoint Services
Although some IIS services, such as application pools and authentication, are used
without modification, other IIS services, such as virtual servers and request handling, are altered to work with the architecture of Windows SharePoint Services.
Figure 4-3 shows the components added and changed in a Windows SharePoint
Services installation.
IHTTP
Handler
Components added by
WSS installation
Components changed by
WSS installation
HTTP.Sys
Extended Virtual
Servers
Admin
CentralAdmnApp
Pool
Default
MSSharePointApp
Pool
Figure 4-3
F04XR03
Illustrates changes to services after the installation of Windows SharePoint Services
Chapter 4:
Windows SharePoint Services Architecture
101
Request Handler
By default, IIS handles all incoming HTTP requests with a kernel-mode driver called
HTTP.sys. The only purpose of this file is to read and route incoming requests. Windows SharePoint Services installs its own handler. This handler is an Internet
Server Application Program Interface (ISAPI) filter called the IHTTP handler.
The IHTTP handler handles all ASP.NET page requests. All other requests, such as
HTML pages that don’t contain ASP.NET code, are handled by HTTP.sys. This process is described in more detail later in this chapter in the “Handling Site Page
Requests” section.
Extending Virtual Servers
For Windows SharePoint Services to be able to use a virtual server, it must be
extended. Extending a virtual server allows it to connect to the configuration database that will in turn direct it to the appropriate content database for site content. If
Windows SharePoint Services is installed on a single server with WMSDE using the
simple installation method, the default IIS virtual server is extended automatically. In
any other case, you must extend each virtual server manually through Windows
SharePoint Services administration tools.
Although you can extend a virtual server through Windows SharePoint Services
administration tools, you cannot create a virtual server using these tools. You must
first create the virtual server through IIS administration tools before extending it in
Windows SharePoint Services. To extend a virtual server, you must be logged on as
a member of the Administrators group on the local computer or as a user that has
the rights to administer both Windows SharePoint Services and IIS.
Application Pools in Windows SharePoint Services
When you extend a virtual server in Windows SharePoint Services, you also choose
which application pool it will use. Windows SharePoint Services uses the application
pool that is used by IIS for its default website. During the installation of Windows
SharePoint Services, one additional application pool is created for the virtual server
that contains the Windows SharePoint Services administrative site. The application
pool created for the administrative site is called CentralAdminAppPool.
Resource Allocation in Application Pools
In Windows SharePoint Services, you can configure a set of virtual servers to share
an application pool or you can place each virtual server in a separate application
pool. Sharing an application pool means sharing memory space and processor
resources. This means that if one of the virtual servers fails, all the virtual servers
could fail. Also, the virtual servers could potentially access each other’s data.
102
Part II: SharePoint Products and Technologies Architecture
Setting up separate application pools for virtual servers requires a lot of memory resources. Each virtual server that is assigned its own application pool needs
about 150 MB of memory.
Management
The Windows SharePoint Services administrative website has a Web page that is just
for management of the default IIS application pool. If you choose to create and
assign new application pools to new or existing virtual servers, you can do so using
Windows SharePoint Services administrative tools. However, you will have to perform other administrative tasks through IIS administrative tools.
There is a difference between an application pool and an application pool
identity. An application pool identity is a user account that is used as the security
context for an application pool. The account designated as the application pool
identity is used to connect the front-end Web server to the back-end databases. The
application pool created during the installation of Windows SharePoint Services is
given an application pool identity during installation.
By default, the account designated as the application pool identity for the CentralAdminAppPool is the configuration database administration account that is set at
the end of setup. This account should be changed only if the password for the CentralAdminAppPool application pool expires or is reset.
The application pool identity for the default website in IIS is set in Windows
SharePoint Services when it is extended. In most cases, this account must be a
domain account. However, if you are installing the single server with SQL Server
configuration, this account can be a local account. This account must also be a member of the db_owner database role in SQL Server on the configuration database.
Virtual Servers vs. Site Collections
If you need to create more websites in a Windows SharePoint Services environment, should you create and extend more virtual servers or should you
create more site collections and sites on existing virtual servers? The
answer depends on the purpose of the added websites.
Anyone who has experience with SharePoint Team Services v1.0 might
notice that Windows SharePoint Services supports far fewer virtual servers
per physical Web server than does SharePoint Team Services v1.0. Windows
SharePoint Services supports approximately 10 virtual servers per physical
Web server, while SharePoint Team Services v1.0 supports approximately
1000. The reason is the architectural change that affects how website
space is allocated in Windows SharePoint Services.
Chapter 4:
Windows SharePoint Services Architecture
In SharePoint Team Services v1.0, there was only one root website per
virtual server. In Windows SharePoint Services, you can have multiple toplevel sites, each with child subsites. Each of these sets of top-level sites
and subsites is referred to as a site collection because they share a common
GUID and namespace. Because of site collections, the number of sites supported in Windows SharePoint Services is much more than the number of
sites that SharePoint Team Services v1.0 can support. When more websites
are needed, you have the choice of creating more virtual servers or creating
more site collections in existing virtual servers.
Whether you should add more site collections or create new virtual
servers depends on a few factors. A virtual server has separate security and
administrative boundaries from other virtual servers and can have separate
resource boundaries as well. Because site collections are contained within
one virtual server, they share these boundaries.
When deciding to go with virtual servers or site collections, you need to
ask the following questions:
■
Does the new site have different authentication needs than existing
sites? The answer to this question is “yes” if you have a need for an
internal site as well as an external site in your organization. In that
case, the new site should be in a separate virtual server from other
sites because all sites in one virtual server must use the same types
of authentication. If the answer is “no,” the same virtual server can be
used.
■
Is there a completely different group of users for the new site with
distinct security needs? Distinct security needs for a particular
group of users might be necessary if you are hosting sites from different organizations or the data in the new site is of a sensitive nature
with high security requirements. Each virtual can be given a separate
application pool, while site collections that reside in the same virtual
server use the same application pool. Because application pools share
memory space and worker processes, the data from all sites within a
virtual server could be compromised if any one of the websites in a virtual server is compromised.
■
Does the new site have higher availability requirements? All sites in
a virtual server share the same application pool memory space and
worker processes. Because of this, one failed website can cause the
others to fail as well.
103
104
Part II: SharePoint Products and Technologies Architecture
Web Part Pages
Web Part Pages in Windows SharePoint Services are designed to take disparate information and consolidate it into one location. The elements—Web Parts—that make
up a Web Part Page in Windows SharePoint Services affect how the page is processed and displayed. Web Parts are grouped on the Web Part Page into containers
called Web Part zones. Each of these components has an important part in the
behavior of Windows SharePoint Services site pages.
Physically, Web Part Pages are ASP.NET files (.aspx) that can be modified in an
HTML editor, such as Microsoft Office FrontPage 2003, that works with Windows
SharePoint Services. There are eight templates that come with Windows SharePoint
Services that can be used to create a Web Part Page. Each of these templates contains a different set of Web Part zones to which Web Parts can be added.
Web Parts
Web Parts are derived from ASP.NET Server Controls, but are designed so that they
are more easily customized than a standard ASP.NET control. Unlike standard
ASP.NET Server Controls, Web Parts remove the properties from the code of the control. The code and properties of a Web Part are separated to allow users to be able
to manipulate the properties without getting into the code. The code of a Web Part
resides in an assembly file that is an ASP.NET dynamic-link library (DLL), while the
properties are loaded into the content database of a site.
When a Web Part is installed, the assembly file is often placed in the \bin subdirectory of the virtual server that is hosting the site. The path for this directory on
a default website in IIS is \inetpub\wwwroot\bin. The other location available for
assembly files is the Global Assembly Cache (GAC). By default, this is the \%systemroot%\assembly directory.
Files stored in the \bin directory are only partially trusted, meaning that these
files cannot automatically save data to the content database or work with the Web
Part object model. Saving a Web Part assembly file to the GAC not only allows the
Web Part to do these things, it also makes the Web Part available to all virtual servers
on a front-end Web server.
Some Web Parts also include additional files, called resource files, which are
needed for the Web Part to display correctly. Any included resource files are also
stored locally on the site server. Resource files can range from images to language
files, depending on the purpose of the Web Part. Resource files can be placed in the
inetpub\wwwroot\wpresources directory, but only if the Web Part assembly file is
in the \bin directory. If the assembly file is located in the GAC, the resource files
must be placed in the <local drive>:\program files\common files\microsoft sharepoint\web server extensions\wpresources directory. Any file that is URL addressable should be considered a resource file and placed in the appropriate
\wpresources directory.
Chapter 4:
Windows SharePoint Services Architecture
105
Web Part Zones
Web Part zones are containers on a Web Part Page that allow a designer to organize
and control the behavior of Web Parts. A Web Part zone is part of a system that
allows Web Parts to act differently than typical ASP.NET Server Controls. Placing a
Web Part within a Web Part zone allows the Web Part to take advantage of the architecture of Window SharePoint Services, while placing a Web Part outside of a Web
Part zone does not.
Static Web Parts
A Web Part zone typically contains one or two Web Parts. However, Web Parts do
not have to be placed into a zone on the Web Part Page. Web Parts that are placed
outside of a Web Part zone are called static Web Parts because they are treated and
act just like a standard Web control. A static Web Part and its properties are stored
within the Web Part Page (.aspx) file. Because of this, a user cannot interact with a
static Web Part or modify it within a browser.
Dynamic Web Parts
Web Parts that are contained within a Web Part zone are called dynamic Web Parts.
This is because unlike with standard Web control or static Web Parts, users can modify the properties of a dynamic Web Part. Web Part zones allow a Web Part to participate in Windows SharePoint Services by connecting the Web Part to a Windows
SharePoint Services content database. The properties of a dynamic Web Part are
saved to a content database so that users can access the properties and manipulate
these properties.
Customization and Personalization for Web Parts
The two views of Web Parts that are used in Windows SharePoint Services are
shared or personal. A shared view is a version of the Web Part that is seen by all
users. A personal view is created when a user changes the view to Personal. The
user can then make changes to one or more of the properties of the Web Part that
are only for that user to see. The architecture of a Web Part allows users to save their
changes and allows Windows SharePoint Services to keep track of each personal
version of a Web Part.
Customization vs. Personalization
Personalization occurs when a user creates a Personal View of a Web Part, while
customization happens when a user makes a change to a Web Part that affects the
Shared View that is seen by all users. A user must have the rights to design a page
106
Part II: SharePoint Products and Technologies Architecture
in order to change the Shared View of a page. By default, Windows SharePoint Services displays pages in Shared View. Once a user switches to a Personal View of the
page and makes a change, the page defaults to Personal View when displayed. A
Web Part page can be designed to default to Personal View if the meta tag WebPartPage DefaultviewPersonal is included in the .aspx code.
Personalization
Once a user switches to the Personal View of a page, personalization is as simple as
adjusting a property in the display of a Web Part on a site page. It can also include
adding a Web Part to a page. The added Web Part can be viewed only by the user
who personalized the Web Part. The properties of a dynamic Web Part are stored in
a Windows SharePoint Services content database. Once a user makes a change to a
property, that change is stored as a personal version of the Web Part. Only properties that are changed from Shared View are stored separately in the database. Windows SharePoint Services reconciles the differences and applies the properties for
the Personal View when the Web Part is rendered for that user.
Controlling Personalization
Web Part zones can be used to control whether a Web Part’s properties can be
changed. By manipulating the properties of a Web Part zone, a designer can choose
to disallow modifications to the Web Parts contained in the zone. They can even
choose to allow customization for a Shared View but disallow personalization in
Personal View. The properties of a Web Part zone cannot be modified through a
browser; they can be modified only with an HTML editor that works with Windows
SharePoint Services.
Regardless of the number of times the properties of a Web Part are modified,
the code in the assembly file never needs to change. All the different versions of a
Web Part reference and use the same assembly file.
Exporting Web Parts
Web Parts are designed so that they can be easily shared among users. A user can
export a Personal View or a Shared View of a Web Part by selecting the Export command from the Web Part menu. When this command is selected, the entire Web Part
is not actually exported. Instead, only the properties of the Web Part are exported.
When a Web Part is installed, the properties are contained in a description file
that has a .dwp extension. A user creates a new version of a description file by
exporting a Web Part. When the Export command is selected from the Web Part
menu, the current state of the properties are read from the content database and
saved to a description file.
Chapter 4:
Windows SharePoint Services Architecture
107
Users who import a Web Part are actually importing only the description file,
not the assembly file or any auxiliary files. When a user imports a .dwp, a new Web
Part is created and the properties specified in the .dwp are applied to this new Web
Part. Then Windows SharePoint Services will save the settings back to the database
and persist them for the next time the user browses to the page. The description file
is read, and the customized properties are loaded into the database as a Personal
View. If the assembly file does not exist locally on the front-end Web server to which
the Web Part is imported, the import will fail.
Description Files
Once a description file is created, it can be edited and elements can be added to
it. Any changes made to the description file are personalizations that override the
default properties of the Web Part. The description file for a different type of Web
Part can contain different elements that apply only to that type of Web Part. The only
required elements in a description file are the Assembly and Typename elements.
However, to display a default name and description for the Web Part after it is
imported, you should also include the Title and Description elements. The following
example shows a description file for an image Web Part:
<?xml version="1.0” encoding="utf-8”?>
<WebPart xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
<Title>Image Web Part</Title>
<FrameType>Default</FrameType>
<Description>Use to display pictures and photos.</Description>
<IsIncluded>true</IsIncluded>
<ZoneID>LeftColumn</ZoneID>
<PartOrder>1</PartOrder>
<FrameState>Normal</FrameState>
<Height />
<Width />
<AllowRemove>true</AllowRemove>
<AllowZoneChange>true</AllowZoneChange>
<AllowMinimize>true</AllowMinimize>
<IsVisible>true</IsVisible>
<DetailLink />
<HelpLink />
<Dir>Default</Dir>
<PartImageSmall />
<MissingAssembly />
<PartImageLarge>/_layouts/images/msimagel.gif</PartImageLarge>
<IsIncludedFilter />
<Assembly>Microsoft.SharePoint, Version=11.0.0.0, Culture=neutral,
PublicKeyToken=71e9bce111e9429c</Assembly>
<TypeName>
Microsoft.SharePoint.WebPartPages.ImageWebPart
</TypeName>
</WebPart>
108
Part II: SharePoint Products and Technologies Architecture
A description file opens and closes with a Web Part element. If an element is
listed with no value, the default value applies. The Assembly element contains the
name of the assembly file for the Web Part. If the assembly file is not present on the
local front-end Web server, the Web Part will not load.
Handling Site Page Requests
When a user tries to connect to a Windows SharePoint Services site, the request goes
through several specific steps before the pages can be displayed in the requesting
client’s browser. Figure 4-4 illustrates the steps that a request goes through before it
can be returned to the client. Windows SharePoint Services handles page requests in
three ways. Pages are handled as either static HTML pages, .aspx pages rendered in
direct mode, or .aspx pages rendered in safe mode.
Client
IIS
HTTP.Sys
Data
IHTTP Handler
Direct
mode
Safe mode
WSS
Data
ASP.NET
Figure 4-4
F04XR04
Illustrates how page requests are handled in Windows SharePoint Services
Routing Page Requests
Windows SharePoint Services works with the IIS architecture, but it adds several
components. The component that handles page requests for IIS, HTTP.sys, is still the
first component to handle requests in Windows SharePoint Services. HTTP.sys is not
changed when Windows SharePoint Services installs, and it performs the same functions for Windows SharePoint Services that it performs for IIS. HTTP.sys listens for
incoming HTTP requests, resolves the URLs to the correct virtual server on the frontend Web server, and authenticates the requesting user.
After HTTP.sys is done with the request, it is passed to an ISAPI filter installed
by Windows SharePoint Services. The purpose of this ISAPI filter (Stsfltr.dll) is to
Chapter 4:
Windows SharePoint Services Architecture
109
pass all other page requests to the correct handler or infrastructure. Stsfltr.dll passes
all static HTML pages to an IIS ISAPI extension. .Aspx pages are passed either
directly to the ASP.NET infrastructure or to the IHTTP handler. Stsfltr.dll also handles
inclusions and exclusions.
Rendering .ASPX Pages
During installation, Windows SharePoint Services defines the association between
types of resources and the handlers for each. This set of mappings is defined in the
<httpHandlers> section of the Web.config file that is discussed later in this chapter.
One of the handlers defined in this section is the IHTTP handler, which is registered
to handle all .aspx requests. The IHTTP handler either passes the ASP.NET page
directly to ASP.NET (direct mode) or runs the page in safe mode.
Direct Mode
Normally when ASP.NET pages are run, the page is read and then compiled into a DLL
file that is saved to the Web server. Because a compiled DLL runs much faster than an
.aspx page, the DLL can be used instead of having to parse the page each time it is
requested. In Windows SharePoint Services, handling ASP.NET pages in this manner is
called direct mode. Only the ASP.NET pages that are in the _layouts directory of the
front-end Web server run in direct mode. The _layouts directory contains fixed application pages used by Windows SharePoint Services, such as the Create List, Create
Field, and Site Settings pages. This directory is considered to be outside the website.
All other ASP.NET pages, including Web Part Pages, run in safe mode.
Safe Mode
ASP.NET pages that are considered to be inside a website are run in safe mode. In
safe mode, .Aspx pages are not allowed to compile code into a DLL. Also, only controls on the page that are on the safe controls list are run. The safe controls list is
included in the Web.config file. All Web Part Pages run in safe mode.
Templates
Windows SharePoint Services comes with templates that are used to create sites and
site pages. Templates can apply to an entire site or to different parts of a site, such
as Web Part Pages, meeting workspaces, lists, areas, and quotas. By default, templates are stored in the Program Files\Common Files\Microsoft Shared\Web Server
Extensions\60\templates directory on the local file system of the front-end Web
server. The use of templates saves database space and increases performance in
Windows SharePoint Services.
110
Part II: SharePoint Products and Technologies Architecture
Saving Database Space
The content database of a site includes a documents table that contains a record for
each page created in a site. Considering the number of sites and pages that Windows SharePoint Services can support, the number of records in this table can be
quite large. Even though the number of records is large, Windows SharePoint Services keep the overall size of the table low by keeping each record in the table relatively empty by default. When a page is created by using a template, the record in
the content database for that page contains only the location of the template used to
create the page. The record does not contain any customization data for the page.
The customization of each site’s page occurs only during the rendering process. During this process, a navigation control looks to the URL of the page and
finds the name of the site. The control uses the site name to find customization information in the content database and makes these customization changes before the
page displays. In essence, each page that is based on the same template is the same,
but users do not realize this because of customizations made during the rendering
process.
Increasing Performance
The use of templates also allows ASP.NET pages to run as they were designed. Normally, an ASP.NET page is read and then saved to a DLL file on the local computer.
Subsequent requests for that page are handled by running the DLL off the local file
system. In Windows SharePoint Services, this is called direct mode. Site pages that
are based on templates run in direct mode. A DLL only needs to be created for each
template instead of for each site’s version of the page. It would not be practical to
have a DLL read into memory for each site’s version of a page.
The Effects of Customization
The performance enhancements in the architecture of templates and site pages
based on templates are lost once a site page is customized. Once the code of a site
page is edited and saved, it can no longer use the template to load.
Once this occurs, Windows SharePoint Services changes the site page’s record in
the documents table of the site content database. It replaces the location of the template in the site pages record with a copy of the entire page. Also, because only templates can run in direct mode, from that point on the page must be run in safe mode.
The Web.Config File
The Web.config file is an XML-based text file that contains configuration information for ASP.NET services. There are multiple Web.config files in Windows SharePoint Services. In a Windows SharePoint Services deployment, Web.config files are
contained in the following folders within the file system:
Chapter 4:
Windows SharePoint Services Architecture
111
■
Local_Drive:\Inetpub\wwwroot—This Web.config file defines configuration
settings for all virtual servers that are on the server. This file is created when a
virtual server is extended.
■
Local_Drive:\Inetpub\wwwroot\wpresources—This Web.config file defines
configuration settings for Web Parts. This file is created when a virtual server is
extended.
■
Local_Drive:\Program Files\Common Files\Microsoft Shared\Web Server
Extensions\wpresources—This folder is used to store Web Part file resources
for assemblies that are placed in the Global Assembly Cache (GAC). The purpose of this Web.config file is to places restrictions on files placed in this folder.
■
Local_Drive:\Program Files\Common Files\Microsoft Shared\Web Server
Extensions\60\CONFIG—This Web.config file along with other .config files
define configuration settings for extending other virtual servers.
■
Local_Drive:\Program Files\Common Files\Microsoft Shared\Web Server
Extensions\60\ISAPI —This web.config file defines configuration settings for
the /_vti_bin virtual directory. This folder holds Web services used by Windows SharePoint Services.
■
Local_Drive:\Program Files\Common Files\Microsoft Shared\Web Server
Extensions\60\TEMPLATE\LAYOUTS—This Web.config file defines configuration settings for the _layouts virtual directory. The _layouts directory is used to
hold trusted application pages that should run in direct mode. Anything placed
in the _layouts directory is accessible by all virtual servers on a front-end Web
server.
■
Local_Drive:\Program Files\Common Files\Microsoft Shared\Web Server
Extensions\60\TEMPLATE\ADMIN\Locale_ID—This Web.config file defines
configuration settings for pages used in the virtual server that contains the
SharePoint Central Administration site.
The \60\CONFIG folder contains .config and .xml files that are used together to
create the Web.config file for a virtual server when it is extended with Windows SharePoint Services. Before copying the Web.config file from the \60\CONFIG folder to the
root folder of the virtual server, Windows SharePoint Services searches the \60\CONFIG folder for any .xml file with a name in the format Webconfig.*.xml and merges its
contents with the Web.config file before writing the resulting Web.config file to the
root path of the virtual server. The actions defined in the .xml file are applied to the
configuration settings of the virtual server. A major advantage to using an .xml file to
supplement the Web.config file is that customizations are not lost when Windows
SharePoint Services is upgraded and the Web.config file is overwritten.
112
Part II: SharePoint Products and Technologies Architecture
Summary
Windows SharePoint Services introduces major improvements over SharePoint Team
Services v1.0. One of the main architectural changes is the consolidation of all data
and product information into database technologies. The result of this is a complete
split of front-end and back-end components that allows for flexibility in the scaling
of a Windows SharePoint Services deployment.
The site architecture of Windows SharePoint Services relies on underlying technologies, while adding to them with its own infrastructure. IIS, ASP.NET, and Windows Server 2003 all provide services that Windows SharePoint Services uses and
builds upon. The infrastructure provided by Windows SharePoint Services processes
client requests and renders pages for clients to view.
Chapter 5
SharePoint Portal Server
Architecture
In this chapter:
Building on Windows SharePoint Services. . . . . . . . . . . . . . . . . . . . . . . . . 114
Changes to Front-End Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
Changes to Back-End Database Components . . . . . . . . . . . . . . . . . . . . . . 117
Physical Configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
Personal Sites vs. My Site . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
User Profiles and Audiences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
Enabling and Configuring Single Sign-On Service . . . . . . . . . . . . . . . . . . . 121
Shared Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
Microsoft Windows SharePoint Services and Microsoft Office SharePoint Portal Server
2003 share the same underlying technologies. This is a change from the first version
of SharePoint Portal Server. Microsoft SharePoint Portal Server 2001 did not share
underlying technology with SharePoint Team Services from Microsoft. In this version
of Microsoft SharePoint Products and Technologies, SharePoint Portal Server, as the
server product, works with and builds upon the architecture of Windows SharePoint
Services. This chapter does not cover the feature differences between SharePoint Portal Server and Windows SharePoint Services. Instead, it focuses on the architectural
differences that are found in SharePoint Portal Server and explains the architecture of
services that are particular to SharePoint Portal Server.
Note When referring to both products as a single unit, we’ll use the term
SharePoint Products and Technologies.
113
114
Part II: SharePoint Products and Technologies Architecture
Building on Windows SharePoint Services
Windows SharePoint Services is required when installing SharePoint Portal Server.
SharePoint Portal Server can install over an existing Windows SharePoint Services
installation, or if Windows SharePoint Services is not yet installed, SharePoint Portal
Server installs Windows SharePoint Services first as part of the installation process.
Additional Services
SharePoint Portal Server includes services that are not offered in Windows SharePoint Services. These services can be viewed in the Services application in Control
Panel and include the Administration service, the SharePoint Portal Alert service, the
Microsoft SharePoint Portal Server Search service, and the Microsoft Single Sign-On
service.
Note During installation, all services that SharePoint Portal Server can
provide are installed regardless of which services you choose to install. The
services are then enabled or disabled based on which services the administrator chooses to provide to users.
Administration Service
SharePoint Portal Server installs an administration service, called SharePoint Portal
Administration, that appears as SPSAdmin in the Services application in Control
Panel. SPSAdmin can stop and start services that SharePoint Portal Server needs,
including SPSSearch. It can also add or delete catalogs and can add or delete search
applications as needed.
SPSAdmin is a service that was written to maintain the configuration of each
server in a SharePoint Portal Server deployment. Essentially, this service runs on
each server in the farm and is responsible for checking the configuration database
every 30 seconds to ensure that the local server is performing its assigned roles.
In the SharePoint Portal Server Central Administration/Component Selection
area, each server in the farm must be assigned at least one role to perform in the
farm. When a role is assigned to a server in the farm, it is recorded in the configuration database. The SharePoint Portal Administration service checks this database
every 30 seconds to ensure that the server is performing its assigned role or roles. If
the service discovers that there is a modification in the server’s roles, the service will
“turn on” or “turn off” those portions of the server’s code to either stop performing
a role or to start performing a role.
For example, let’s assume that there are six front-end Web servers in a large
farm. Now let’s assume that server1, a front-end Web server, is a search server. This
Chapter 5: SharePoint Portal Server Architecture
115
server has a failure and is no longer available. The site administrator gives the role
of search server to server2 and removes the role of search server from server1.
Because the SharePoint Portal Administration service works locally on each server,
each of the five servers that are still online will poll the configuration database and
discover that the Search role has been moved to a different server. When server1
comes back online, the local SharePoint Portal Administration service on server1 will
also discover the change and will stop the search service on server1 automatically
after polling the configuration database.
Note that when you turn off the search service, the server is pulled out of rotation for queries and the new server won’t have any catalogs until the next index
propagation. For indexing servers, all catalogs are removed when the server is
turned off, and a new server is created with no catalogs
SharePoint Portal Alert Service
The purpose of the SharePoint Portal Alert service is to notify a user, when the user
requests it, that there is a change to a designated item, document, list, or document
library on the website. Alerts are managed by the job server.
Microsoft SharePoint Portal Server Search Service
Windows SharePoint Services can perform SQL text queries, but only on content that
resides in a site from which the search query was invoked. Because SharePoint Portal Server has Microsoft SharePoint Portal Server Search service, it can index and perform searches on content that is external as well as internal to the portal site.
Additionally, it can perform searches across servers and portals. Microsoft SharePoint Portal Server Search service is listed in the Services application as SharePointPSSearch. For more information on the indexing capabilities of SharePoint
Portal Server, see Chapter 21, “The Architecture of the Gatherer.”
Microsoft Single Sign-On Service
Third-party enterprise applications such as PeopleSoft, SAP, Siebel, and Lotus Notes
use authentication that is different from Microsoft Windows operating systems and
SharePoint Portal Server. The Single Sign-On service is provided so that disparate
authentication databases, such as Active Directory and a third-party application
database, can map credentials from authenticated Windows users to enable a single
sign-on environment. The Microsoft Single Sign-On service appears as SSOSrv in
the Services application in Control Panel.
Changes to Front-End Components
SharePoint Portal Server has the same front-end/back-end split of components that
Windows SharePoint Services has. Because SharePoint Portal Server has additional
116
Part II: SharePoint Products and Technologies Architecture
services that it can provide, it also has more front-end server roles and has more
back-end database types than does Windows SharePoint Services. Figure 5-1 shows
the components that are available in a SharePoint Portal Server deployment.
Front-end Web
Index
Management
Server
Job
Server
Data
Front-end Web
Search
Server
Data
Figure 5-1 Architecture of SharePoint Portal Server includes front-end Web servers, search servers, a job server, index servers, and back-end databases
F05xr01
Note The split between front-end and back-end components in SharePoint
Portal Server is a logical one. Physically, the front-end and back-end components can exist on the same server or on separate servers. In fact, in a
single-server deployment, all the server farm roles are performed on a single server.
Front-End Servers
Windows SharePoint Services has only one role for front-end Web servers. These
servers host sites and process search requests. SharePoint Portal Server includes the
ability to separate front-end roles for Web servers and also includes separate roles
for index management servers, search servers, and a job server. One or more servers
can fill each role, except for the job server, depending on the number of users that
are supported. There is only one job server per portal site, regardless of how small
or large the environment is.
Job Server
The purpose of a job server is to manage the additional services that are supported
in SharePoint Portal Server that are not available in Windows SharePoint Services.
This includes the following additional services:
Chapter 5: SharePoint Portal Server Architecture
■
Hosting the Single Sign-On pages
■
Importing user profiles
■
Performing audience calculations
■
Crawling and indexing portal site content
■
Hosting the Alerts service
117
Index Management Server
Windows SharePoint Services combines the services of hosting site pages, crawling
content, and processing search queries from clients into one front-end Web server.
SharePoint Portal Server allows these services to be performed separately. An index
management server is dedicated to building and updating indexes, which includes
crawling content and breaking down the crawled information through the indexing
process.
Only one index server can crawl a content source. If you need better performance on crawls, you cannot get it by adding another index management server. To
improve crawl performance, you must upgrade the server that is assigned to a particular content source. Index management servers and the indexing process are covered thoroughly in Chapter 21.
Changes to Back-End Database Components
Windows SharePoint Services installs one configuration database and one or more
content databases for use with its sites. Even though SharePoint Portal Server installs
over Windows SharePoint Services, it does not use any Windows SharePoint Services databases in their original installed state. When a portal site is created in SharePoint Portal Server, an additional three databases are created that are not in a
Windows SharePoint Services deployment. A fourth database is created if the Single
Sign-On service is used. SharePoint Portal Server also makes changes to the configuration database that is installed by Windows SharePoint Services.
In addition to changing existing databases, SharePoint Portal Server also
changes how the front-end Web servers connect to the databases. Windows SharePoint Services front-end Web servers can use Microsoft SQL Server authentication or
Windows authentication to connect to back-end databases, but SharePoint Portal
Server front-end Web servers can use only Windows authentication. Also, Windows
SharePoint Services front-end Web servers use OLE DB to connect to back-end databases. For most connections, SharePoint Portal Server front-end servers use
ADO.Net instead. Only the Microsoft SharePoint Portal Search service uses OLE DB
to connect to back-end databases.
118
Part II: SharePoint Products and Technologies Architecture
Configuration Database
SharePoint Portal Server uses a configuration database in the same manner as Windows SharePoint Services. However, during installation SharePoint Portal Server
adds extensions to the configuration database that is installed by Windows SharePoint Services. These extensions include adding a new schema and modifying tables
by adding new stored procedures. This means that Windows SharePoint Services
cannot connect to a SharePoint Portal Server configuration database and vice versa.
Additional Databases
SharePoint Portal Server ignores the content databases that Windows SharePoint Services installs. Instead, SharePoint Portal Server creates a different location for content databases. In addition, SharePoint Portal Server creates supplementary
databases to support the services that a portal site can provide. These databases
have a hyphenated name that begins with the name given to the portal and ends
with a suffix that identifies the type of database. Table 5-1 has a list of the additional
databases created in SharePoint Portal Server.
Table 5-1
Additional Databases in SharePoint Portal Server
Database Name
Purpose
Portalname_prof
Contains the profile database that holds user profiles and audiences.
Portalname_serv
Stores information for services, such as search and alerts, that are
provided by a portal site. Also called the component settings database.
Portalname_site
Contains site content information and works like the content database in Windows SharePoint Services.
In addition to these three databases, a fourth database is created when the Single Sign-On service is configured. This database stores credential information for the
Single Sign-On service. It does not start with the name of the portal because only
one is created per server farm and instead can be named by the administrator.
Physical Configurations
Like Windows SharePoint Services, SharePoint Portal Server can be scaled from a
single server to a large farm of servers. The difference in these configurations is the
physical separations of the available components. As servers are added to a SharePoint Portal Server deployment, each server becomes more specialized in the services it provides.
Chapter 5: SharePoint Portal Server Architecture
119
Single Server
In a single-server configuration, all components (both front-end and back-end) are
on a single server. This configuration can use a separate installation of SQL Server or
use SQL Server 2000 Desktop Engine for the back-end databases.
Server Farms
Server farms are created in a SharePoint Portal Server environment when components are placed on separate servers. Server farms can range from small to large,
depending on the needs of the environment.
The components that are considered front-end are the Web server hosting the
portal site, the index server crawling the content and creating the index, the search
server that processes client search requests, and the job server that coordinates available services. A small server farm keeps the front-end components on the same
server while separating the back-end databases onto one or more servers. Medium
server farms separate the indexing functions and the job server from the front-end
Web servers and search services. A large farm can handle up to four index management servers, one of which must be a job server, and four search servers, which are
separate from the Web front-end servers. To find out more about deploying server
farms, see the chapters in Part 4, “Deployment Scenarios.”
Personal Sites vs. My Site
Personal sites and the My Site feature are separate features that are both available
only in SharePoint Portal Server. Although the names of these two features are often
used as synonyms for each other, they are not the same. Site administrators need a
good understanding of the architectural differences between the two features to
understand differences in the behavior of each.
Personal sites are Windows SharePoint Services sites that are created for individual users. Every user who has the Create Personal Site right can have a personal
site. By default, the location of a user’s personal site is portalname/personal/username, where portalname is the name of the portal and username is the name of the
individual user.
My Site is a single page located in the SharePoint Portal Server site. By default,
the path for this page is portalname/My Site/default.asp, where portalname is the
name of the portal. Every user who accesses the My Site URL downloads the same
page. However, users often don’t realize this because some of the information on
the page is personalized based on the user’s profile information and information
from the user’s personal site.
So the difference between My Site and personal sites is that My Site is the portal
page through which all users must pass to get to their own personal site. A user links
to his personal site through the My Site page. It is hard to recognize that the My Site
120
Part II: SharePoint Products and Technologies Architecture
portal page is the same for everyone because it has personalization features. My Site
is personalized based on a user’s profile information, and it includes links to document libraries and lists that the user has created on her personal site.
The major architectural difference is that the My Site page is owned and controlled by the site owner, while a personal site is owned and controlled by the user.
This means that a user can customize the contents and views of her personal site;
however, when a user tries to personalize the My Site page, the choices are limited.
User Profiles and Audiences
SharePoint Portal Server includes a way to integrate user profile information into site
pages and to target content to a group of users. User profiles and audiences are contained in the portalname_prof database (where portalname is the name of the
portal).
Populating the User Profile Database
The profile database is a list of user account property information. This information
is obtained by importing information from a directory that contains user accounts or
it is obtained manually by typing in account information. By default, SharePoint Portal Server can import a list of domain users from Active Directory, but code can be
written against the SharePoint Portal Server object model that can be used to import
information from other directory services or applications. User profile information is
stored in a single table in the portalname_prof database. Updates to the database
can be scheduled on a regular basis and can be incremental or full.
Creating Audiences
Audiences are also contained in the user profile database, but they are contained in
a separate table from the one that contains user profiles. Creating an audience
involves creating rules and then compiling the audience. Rules define what user
accounts should be included or excluded from the audience. Rules created for any
audience are stored in a separate table in the portalname_prof database.
When an audience is compiled, the rules are used as a filter against the complete list of user profiles. Because not all account information is imported into the
user profile database, Active Directory is also queried during an audience compilation. Accounts that fit the rule are copied and placed in a separate table that holds the
members of the audience. This table contains the members of all audiences for a portal and is separate from the table that stores the rules. The table that contains audience members is not updated, and remains static until the audience is recompiled.
Chapter 5: SharePoint Portal Server Architecture
121
Enabling and Configuring Single Sign-On Service
Like all services in SharePoint Portal Server, Single Sign-On installs automatically, but
it is not enabled. Enabling the service requires an administrator to be physically at the
server that is designated as the job server for the portal site. The administrator must
specify a SQL Server in the server farm on which a credential database is created.
A developer can develop Web Parts that are Single Sign-On–aware and use
enterprise application definitions to pull information from enterprise applications
and display it on pages within a portal site. The purpose of an enterprise-application definition is to provide the connection from the enterprise application to the
Single Sign-On Web Part on a portal site page. Figure 5-2 shows the relationship
between Single Sign-On Web Parts, enterprise-application definitions, the enterprise
application, and the credentials database.
Single Sign-On Service
Enterprise
Application
Definition
Enterprise
Application
Credential
database
Figure 5-2 SharePoint Portal Server connects users to enterprise applications using the Single
Sign-On service and enterprise application definitions
F05XR02
Authentication with Single Sign-On
Authentication with the Single Sign-On service can be set up to work with groups or
with individual users. In either case, enterprise application definitions are used to
map credentials used by SharePoint Portal Server to credentials used in an enterprise
application.
With group authentication, the individual user is associated with a managed
group account. In this case, the user does not need to know an individual set of credentials. Instead, an enterprise application definition is configured by an administrator to provide the credentials needed. The enterprise-application definition maps the
credentials used in SharePoint Portal Server to the enterprise application without
users needing to provide alternate credentials.
122
Part II: SharePoint Products and Technologies Architecture
Individual authentication is used when users know and manage their own credentials for the enterprise application. In this case, the enterprise-application definitions map the user’s SharePoint Portal Server credentials to individual credentials
needed by the enterprise application that are stored in the credential database. If a
user’s credentials are not yet in the Single Sign-On credential database, the Web Part
redirects the user to the Single Sign-On logon form used to enter his credentials.
Once the credentials are stored in the credentials database, the mapping should
happen automatically so that user intervention is no longer needed.
Shared Services
In SharePoint Portal Server, by default, each portal site is configured as a separate
entity from other portal sites. As a separate entity, a portal site individually supports
and provides needed resources for all services. If the portal sites within a server farm
belong to the same organization and support the same set of users, the use of
shared services can allow the portal sites to consolidate and save resources.
Shared services centralizes the work required to provide services to one portal
site by creating a parent/child relationship between the portal sites. When shared
services is implemented, the portal site that provides the services becomes the parent while all other portal sites become children. Because the parent portal site provides services, the child portal sites are left with only site information—such as
pages, areas, and lists—to support. The following lists how services change when
shared service is implemented:
■
Search and index. With shared services, crawling and index creation are
consolidated in the parent portal site. Search requests from child portal sites
are processed by the parent portal site.
■
Alerts. With shared services, alerts are managed and tracked in a single alert
store in the parent portal site.
■
Personal sites. With shared services, personal sites are created only in the
parent portal site and can be viewed and accessed from the child portal sites.
The My Site portal page is also located in the parent portal site.
■
User profiles. With shared services, a single user profile database is configured in the parent portal site and is accessed by the child portal sites.
■
Audiences. With shared services, audiences are compiled and stored only in
the parent portal site.
■
Single Sign-On service. With shared services, only one Single Sign-On credentials database is created. This database is located and administered only in
the parent portal site.
Chapter 5: SharePoint Portal Server Architecture
123
Shared services is an all-or-nothing configuration at the server-farm level. This
means that if one portal site in a server farm is using shared services, all portal sites
in that farm are using shared services. Once a portal site in a farm is designated as
the parent, all other portal sites in the farm automatically become child portal sites.
It is also a one-way decision, meaning that once you decide to turn on shared services, you can’t turn it off later.
Database Access in Shared Services
When shared services is implemented, child portal sites look to the parent’s configuration database for shared services data. Although some data is still needed from
the original databases used by the child sites after shared services is configured,
most information is retrieved from the parent site’s databases. By default, each portal
site has two user accounts that are used to access databases. These accounts are
called the configuration database administration account and the application pool
account for the portal site.
The configuration database administration account is the account used by the
CentralAdminAppPool application pool to access the configuration database and
all other databases for a portal site. It is recommended that all servers in a server
farm use the same account for the configuration database administration account.
Once shared services is implemented, this recommendation becomes a requirement.
The MSSharePointPortalAppPool is used by the portal site to access the SharePoint Portal Server databases. Although child portal sites must have access to the
parent configuration and content databases for added security, that access can be
limited to read-only.
Summary
Because SharePoint Portal Server 2003 is built on Windows SharePoint Services,
much of the underlying architecture is the same. Both handle page requests and
.aspx pages in the same manner. The main architectural differences lie in the way
the additional services provided by SharePoint Portal Server are handled. As the
server product in Microsoft SharePoint Products and Technologies, SharePoint Portal
Server 2003 has additional services that support a larger and more diverse set of
users. To accommodate this, additional database types and additional front-end
roles are included in SharePoint Portal Server that are not included in Windows
SharePoint Services.
Chapter 6
Security Architecture for
SharePoint Products and
Technologies
In this chapter:
Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
Authorization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
Code Access Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
Communication Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
Microsoft SharePoint Products and Technologies security is layered on top of, and
depends on, the security of underlying products and technologies such as ASP.NET,
Internet Information Services (IIS), SQL Server 2000, and Windows Server 2003.
Needless to say, communication security and firewall configuration are vital as well.
As with any Web application, your SharePoint site is only as secure as its weakest
link; security is a concern across all components of your SharePoint Products and
Technologies deployment. Because SharePoint Products and Technologies security
spans many technologies, you need to have an understanding of security in these
technologies to make all parts of your SharePoint Products and Technologies
deployment work together in a secure fashion.
It is vital to implement a layered approach to security, often referred to as
defense-in-depth. Use of defense-in-depth means that security is addressed at a
number of levels, including organizational security policies, Windows Server 2003
configuration, IIS configuration, ASP.NET configuration, SharePoint Product and
Technologies configuration, communication security, firewall configuration, and
so on.
125
126
Part II: SharePoint Products and Technologies Architecture
SharePoint Products and Technologies make use of a number of technologies
that reduce the risk of security being compromised. These technologies include:
■
Authentication that uses Windows principals and therefore can make use of
strong authentication methods, password policies, account lockout policies,
and encryption
■
Authorization that is based on the permissions model to ensure a high degree
of granular control over access to contents of a site
■
Code access security in .NET Framework that allows you to control code access
to protected resources and operations
■
Security techniques such as Secure Sockets Layer (SSL) and IPSec that allow
you to protect your communications inside and outside the firewall
■
Firewall protection of external sites
In this chapter, we will focus on authentication, authorization, code access
security, and communication security in SharePoint Products and Technologies.
Research has shown that early design of authentication and authorization eliminates
a high percentage of vulnerabilities. Code access security allows code to be trusted
to varying degrees, depending on where the code originates from and on other
aspects of the code’s identity. Communication security is an integral part of securing
your deployment to protect data passed between users and your site, and between
the servers in your deployment. For discussion on security policies for SharePoint
Products and Technologies refer to Chapter 24, “Information Security Policies for
SharePoint Products and Technologies.”
Authentication
Authentication is the process of positively identifying the users of your site. Authentication ensures that the users are who they claim to be. Authenticated clients are
referred to as principals.
In SharePoint Products and Technologies, authentication is based on Windows
security accounts.
For SharePoint sites, ASP.NET is configured to use Windows authentication. In
web.config files, the authentication section is as follows:
<system.web>
<authentication mode="Windows” >
</system.web>
With Windows authentication mode, ASP.NET relies on IIS to perform the
required authentication of a client. IIS authenticates the requesting user against Windows security accounts. After IIS authenticates a client, it passes a user identity to
ASP.NET. (See Figure 6-1.)
Chapter 6: Security Architecture for SharePoint Products and Technologies
127
Access denied
IIS
Client
machine
authorized?
No
Yes
NTFS
permissions
OK?
No
Yes
Yes
IUSR_machinename
user identity
Anonymous
access
enabled?
No
User
No
authenticated?
Yes
Authenticated user
identity
User access token
ASP.NET
Figure 6-1
F06XR01
Passing user identity in Windows authentication mode
You can use a variety of IIS authentication schemes for SharePoint Products
and Technologies user authentication, as follows:
■
Basic. Basic authentication is part of the HTTP 1.1 protocol that is supported
by virtually all browsers. With SharePoint Products and Technologies, it can be
used in the extranet environment. The credentials are transmitted unencrypted.
You should use basic authentication only over SSL; otherwise, basic authentication is not secure.
128
Part II: SharePoint Products and Technologies Architecture
■
Integrated Windows. Integrated Windows authentication is a secure
authentication method that is most suitable for your intranet SharePoint sites. It
does not work over proxy servers. It is implemented as either Kerberos or
NTLM. Kerberos requires Windows 2000 or later operating systems on the client and server computers.
■
Client Certificates Mapping. Clients require X.509 certificates. This is an
optional authentication mechanism that can be used when SSL is enabled
between the client and the server. For example, it can be used on the extranets
when your security policy requires two-level authentication—a system in
which clients are required to provide something they have (a certificate) and
users are asked to provide something they know (authentication credentials).
For configuration details, refer to Chapter 27, “Securing an Extranet Using SSL
and Certificates.”
■
Anonymous. Anonymous authentication allows anonymous access to the
web site. The def ault us er identity used f or a nonymo us ac ces s is
IUSR_machinename. When IIS receives an anonymous request, it impersonates the IUSR_machinename account. In this case, the identity passed to
ASP.NET is IUSR_machinename.
User access in SharePoint Products and Technologies is based on Windows
security principals such as individual user accounts and security group accounts
(DOMAIN\user and DOMAIN\security group).
Note You cannot use distribution lists to control access to content in
Windows SharePoint Services because distribution lists are not Windows
security principals.
In addition to authenticating users for the SharePoint sites access, SharePoint
Portal Server provides a single sign-on (SSO) functionality that allows you to authenticate users to a portal site, and then to retrieve a user’s stored credentials for other
user-aware enterprise business applications from an SSO database when required.
The SSO functionality is implemented by the Microsoft Single Sign-On service
(SSOSrv). SSOSrv provides storage and mapping of credentials such as account
names and passwords so that the portal-based applications can retrieve information
from the third-party applications and back-end systems. This prevents users from
having to authenticate themselves again when the portal-based applications need to
obtain information from other business applications and systems. For details on how
you can enable and configure SSO in SharePoint Portal Server, refer to Chapter 26,
“Single Sign-On in SharePoint Portal Server 2003.”
Chapter 6: Security Architecture for SharePoint Products and Technologies
129
Authorization
Authorization defines which resources and operations the authenticated user is
allowed to access. In Windows SharePoint Services and SharePoint Portal Server,
access to sites is controlled through a role-based membership system by which each
user is associated directly or indirectly with a permission that controls the specific
actions that the user can perform. This membership system is based on site groups.
Using a site group is a way to configure rights for users based on the kinds of tasks
they perform.
Site groups specify what rights the users have on a site. The rights determine
what specific actions the users can perform on the site. Although the concepts of
using site groups are the same in Windows SharePoint Services and SharePoint Portal
Server, because of the additional feature set in the SharePoint Portal Server there are
differences in the user rights and corresponding permissions, as well as the default
site groups. Because of these differences, we will look into authorization in Windows SharePoint Services and SharePoint Portal Server separately.
Authorization in Windows SharePoint Services
In this section, we will look into user authorization to access Windows SharePoint
Services sites as well as administrative tasks related to setting up authorization. Windows SharePoint Services uses site groups to manage site-wide security. Rights
specify the actions that users can perform; in essence, each site group is a collection
of rights.
If you want all users to be able to browse your site, you can enable anonymous
access to the site. Anonymous access is disabled by default.
Note With anonymous access enabled, users can browse the site without
authentication, but they cannot perform any administrative tasks on the
site. The administration pages require authentication.
To run custom code that uses the Windows SharePoint Services object model,
users must have the appropriate permissions assigned to them, just as when they
interact with a site or list through the user interface.
To be authorized to perform administrative tasks that affect settings for all websites and virtual servers on the server computer, a user must be a member of the
local administrators group on the server machine or a member of the SharePoint
administrators group.
130
Part II: SharePoint Products and Technologies Architecture
Site Groups
Windows SharePoint Services includes 21 rights, which are used in the five default
user site groups. The five default user rights groups are Guest, Reader, Contributor,
Web Designer, and Administrator. Table 6-1 shows user rights that are included in
each site group by default.
The rights assigned to the Guest and Administrator site groups cannot be
changed. However, you can customize the rights available in Reader, Contributor,
and Web Designer site groups to include only the rights you want.
You can add new site groups to combine different sets of rights, edit the rights
assigned to a site group, or delete an unused site group.
You cannot assign users directly to the Guest site group, rather users who are
given access to lists or document libraries by way of per-list permissions are automatically added to the Guest site group. The Guest site group cannot be customized
or deleted.
You can manage site groups and permissions by using HTML administration
pages or the command-line administration tool Stsadm.exe. For a detailed description of
specific tasks, refer to Chapter 16, “Windows SharePoint Services Site Administration.”
You can also use the Windows SharePoint Services object model to perform
the management tasks in code. For details, refer to the SharePoint Products and
Technologies Software Development Kit (SDK) at http://msdn.microsoft.com/library
/default.asp?url=/library/en-us/spptsdk/html/SPSDKWelcome.asp.
Table 6-1
Default Windows SharePoint Services Site Groups
and their Rights
Site group name
User rights included by default
Guest
None
Reader
Use Self-Service Site Creation
View Pages
View Items
Contributor
All rights included in the Reader site group, plus:
■ Add Items
■ Add/Remove Private Web Parts
■ Browse Directories
■ Create Cross-Site Groups
■ Delete Items
■ Edit Items
■ Manage Personal Views
■ Update Personal Web Parts
Chapter 6: Security Architecture for SharePoint Products and Technologies
Table 6-1
131
Default Windows SharePoint Services Site Groups
and their Rights (continued)
Site group name
User rights included by default
Web Designer
All rights included in the Contributor site group, plus:
■ Add and Customize Pages
■ Apply Themes and Borders
■ Apply Style Sheets
■ Cancel Check-out
■ Manage Lists
Administrator
All rights included in the Web Designer site group, plus:
■ Create Subsites
■ Manage List Permissions
■ Manage Site Groups
■ View Usage Data
In addition to defining the site groups, you can define your own cross-site
groups. Cross-site groups consist of users and can be assigned to a site group on any
website in a site collection. There are no cross-site groups defined by default.
Site groups are defined per website. Subsites can either use the same permissions as the parent website (inheriting both the site groups and users available on
the parent website) or use unique permissions. When you create a subsite, you can
choose whether to inherit the permissions from the parent website or to create
unique permissions for your subsite.
You can specify unique permissions on a per-list basis. Unlike for sites, you
can add users together with specified permissions directly to a list, in which case the
users are automatically assigned to the Guest site group on the current site if the site
is unique and does not inherit permissions from a parent site. If the current site
inherits permissions, the users are added to the Guest site group on the most recent
unique ancestor site.
The users are granted permissions to a site or list through direct or indirect
membership in a site group. They can be added directly to a site group or added to
a cross-site group that is a member of a site group, or they can be members of a
Windows domain group that is added to a site group. In addition, an individual user
can be directly added to a list in association with a specified permission. Figure 6-2
shows the means by which users are granted permissions to a site or a list.
132
Part II: SharePoint Products and Technologies Architecture
Site
List
Permissions
Site group
Cross-site group
Windows security
group
User
Figure 6-2
F06XR02
Granting user permissions to a site or list in Windows SharePoint Services
Most user rights are dependent on other user rights. For example, you must be
able to view items before you can edit items. If a right is deleted from a site group,
any rights dependent on that right are also deleted. For detailed information about
dependencies on user rights, refer to Table 6-2.
Note In the Windows SharePoint Services object model, unlike the user
interface, rights are not dependent on other rights. To run custom code that
uses types and members in the SharePoint Products and Technologies
object model, users and groups must be assigned the appropriate permissions, just as when interacting with a site or list by using the user interface.
However, in this case there are no dependencies: rights can be assigned
individually without including dependent rights, and they can be assigned to
users and groups in any combination.
Chapter 6: Security Architecture for SharePoint Products and Technologies
Table 6-2
133
Windows SharePoint Services Rights Dependencies
Groups
included by
default
Dependent rights
Right
Permissions
Add and Customize
Pages
Create ASP.NET, ASP,
and HTML pages for a
website
Web Designer,
Administrator
Browse Directories,
View Pages
Add Items
Add items to lists or add
documents to document
libraries
Contributor,
Web Designer,
Administrator
View Items, View Pages
Add/Remove Private Web Parts
Add and remove Web
Parts to personalize
Web Part Pages
Contributor,
Web Designer,
Administrator
Update Personal Web
Parts, View Items, View
Pages
Apply Style Sheets
Apply a style sheet to
the entire website
Web Designer,
Administrator
View Pages
Apply Themes and
Borders
Apply a theme or border
to an entire website
Web Designer,
Administrator
View Pages
Browse Directories
Browse the directory
structure of a website
Contributor,
Web Designer,
Administrator
View Pages
Cancel Check-Out
Cancel the check-out
action performed by
another user
Web Designer,
Administrator
View Pages
Create Cross-Site
Groups
Create or delete crosssite groups, or change
membership of a crosssite group
Contributor,
Web Designer,
Administrator
View Pages
Create Subsites
Create a new subsite or
workspace site, such as
a Document Workspace
site or Meeting Workspace site
Reader,
Contributor,
Web Designer,
Administrator
View Pages
Delete Items
Delete list items and
documents from the
website
Contributor,
Web Designer,
Administrator
View Items, View Pages
Edit Items
Edit existing list items
and documents in the
website
Contributor,
Web Designer,
Administrator
View Items, View Pages
Manage Lists
Create, edit, or delete lists Web Designer,
and change their settings Administrator
View Items, View Pages,
Manage Personal Views
Manage List Permissions
Change permissions for a Administrator
list or document library
Manage Lists, View
Items, View Pages,
Manage Personal Views
134
Part II: SharePoint Products and Technologies Architecture
Table 6-2
Windows SharePoint Services Rights Dependencies
Groups
included by
default
(continued)
Right
Permissions
Manage Personal
Views
Create, edit, or delete
personal views on lists
Contributor,
Web Designer,
Administrator
View Items, View Pages
Manage Site
Groups
Create, delete, and edit
site groups, both by
changing the rights
assigned to the site
group and by changing
which users are members of the site group
Administrator
View Pages
Manage Web Site
Perform administration
tasks for a particular site
or subsite
Administrator
View Pages
Update Personal
Web Parts
Update Web Parts to
display personalized
information
Contributor,
Web Designer,
Administrator
View Items, View Pages
Use Self-Service
Site Creation
Use the Self-Service Site
Creation tool to create a
top-level website.
Reader,
Contributor,
Web Designer,
Administrator
View Pages
View Items
View items in lists, documents in document
libraries, and Web
discussion comments
Reader, Contributor, Web
Designer,
Administrator
View Pages
View Pages
Browse pages in the
website
Reader,
Contributor,
Web Designer,
Administrator
None
View Usage Data
View reports on website
usage
Administrator
View Pages
Dependent rights
Site Creation Rights
Site creation rights (Use Self-Service Site Creation and Create Subsites) control
whether users can create top-level websites, subsites, or workspaces.
Members of the Administrator site group can create subsites from their websites.
However, Self-Service Site Creation is different: it is a feature that is enabled by
administrators and allows users to create their own top-level websites. Users do not
need administrator permissions on the server or virtual server, only permissions on
the website where Self-Service Site Creation is hosted. By default, the Use Self-Service
Chapter 6: Security Architecture for SharePoint Products and Technologies
135
Site Creation right is included in all site groups except the Guest site group, and it
gives users access to the signup page and the ability to use Self-Service Site Creation.
Note The Self-Service Site Creation right is available only on a top-level
website in a site collection.
Self-Service Site Creation allows users to create and manage their own toplevel websites automatically. Self-Service Site Creation is disabled by default—you
must turn on the feature to use it. You enable Self-Service Site Creation for a single
virtual server at a time from the Configure Self-Service Site Creation page for the virtual server that you want to enable. If you want to use it on all virtual servers in your
server farm, you must enable it for every virtual server individually.
Note You can use either HTML administration pages or the command-line
tools enablessc.exe and disablessc.exe to turn on and configure Self-Service Site Creation. Either method allows you to turn on or turn off Self-Service Site Creation and specify the type of information to require when
creating a site. For details, refer to Chapter 15, “Configuring Windows
SharePoint Services.”
Anonymous Access
Anonymous access allows users to view pages anonymously or to contribute anonymously to lists and surveys. When you enable anonymous access in Windows
SharePoint Services, you are enabling access to your site for the IIS anonymous
account IUSR_machinename.
Anonymous access is disabled by default and is controlled at the site level. To
enable anonymous access, you must first verify that IIS is configured to allow anonymous access, and then enable anonymous access for your website by using the Site
Settings. Anonymous access for specific lists is controlled using the per-list permissions. If anonymous access is disabled for your site, it cannot be enabled for a particular list in the site.
You can also grant access to “all authenticated users” to allow all members of
your domain to access a website without having to enable anonymous access.
More Info For detailed description of configuration steps for enabling
anonymous access, refer to Chapter 16.
136
Part II: SharePoint Products and Technologies Architecture
Performing Administration Tasks
Users assigned to the Administrator site group are administrators only for a particular
website. To perform any administrative tasks that affect settings for all websites and
virtual servers on the server computer, a user must be an administrator for the server
computer (also known as a local administrator) or a member of the SharePoint
administrators group, rather than a member of the Administrator site group for the site.
The virtual server administration pages can be accessed only by local computer
administrators or the members of the SharePoint administrators group. This is configured using URL authorization in the web.config file for the Central Administration
pages that is located in the folder <Local Drive>:\Program Files\Common
Files\Microsoft Shared\web server extensions\60\TEMPLATE\ADMIN\1033. The
<authorization> element is defined as follows:
<authorization>
<allow roles="BUILTIN\Administrators” />
<allow users="Domain\SharePoint Administrators account name” />
<deny users="*” />
</authorization>
The SharePoint administrators group is a Windows domain group that has
administrative access to Windows SharePoint Services in addition to the local administrators group. Members of this local administrators group configure the name of a
Windows group to become the SharePoint Administrators group using Central
Administration pages. The name specified in Central Administration pages is the
name in web.config file; when you change the SharePoint administrators group, the
name is changed in the <authorization> element in web.config file.
You can add users to the SharePoint administrators groups, rather than to the
local administrators group, to separate administrative access to Windows SharePoint
Services from administrative access to the local server computer. Members of both
the SharePoint administrators group and the local administrators group have rights
to view and manage all sites created on their servers.
Note The SharePoint administrators group members do not have access
to the IIS metabase, so they cannot perform the following actions for Windows SharePoint Services: extend virtual servers, manage paths, change
the SharePoint administrators group, change the configuration database
settings, and use the Stsadm.exe command-line tool. They can perform any
other administrative action using the HTML Administration pages or the Windows SharePoint Services object model.
Chapter 6: Security Architecture for SharePoint Products and Technologies
137
Authorization in SharePoint Portal Server
In this section, we will look into user authorization access to SharePoint Portal
Server sites, backward-compatible document libraries, and search results.
Similar to Windows SharePoint Services, SharePoint Portal Server uses site
groups to manage site-wide security. Each user is a member of at least one site
group, and access to portal sites is controlled through a site group membership system. After you create a portal site, you can give users access to it by assigning them
to site groups. A user who is not assigned to a site group won’t be able to access the
portal site.
In addition to providing authorization based on the site groups membership,
SharePoint Portal Server provides role-based security for backward-compatible document libraries.
Site Groups
SharePoint Portal Server uses six default site groups to group users with a specific
set of customizable rights. You can also create a custom site group for a specific area
or list and assign a specific set of rights to it. You can edit the rights assigned to a site
group, create a new site group, or delete an unused site group.
The six default SharePoint Server groups are as follows:
■
Reader site group allows users to search, view, and browse content in the site.
■
Member site group allows users to submit listings and create personal sites.
■
Contributor site group allows users to submit content to areas in the site to
which they are granted rights.
■
Web Designer site group allows users to change layout and settings on a Web
page to which they are granted rights.
■
Administrator site group allows users full control of the website.
■
Content Manager site group allows users to manage all settings and content in
an area to which they are granted rights.
You can use site groups to control general access to the portal site as well as
to control access to specific areas in the portal site.
Although the site groups in SharePoint Portal Server and Windows SharePoint
Services are similar in many respects, there are a number of differences:
■
There are two default site groups in SharePoint Portal Server that are not available with Windows SharePoint Services: Member and Content Manager. Both
site groups allow users access to the features that are defined only in the SharePoint Portal Server: Member site group allows you to create personal sites, and
Content Manager allows you to manage areas for grouping content by userdefined criteria.
138
Part II: SharePoint Products and Technologies Architecture
■
There is no default Guest site group in SharePoint Portal Server. This is because
the Guest group is used automatically in Windows SharePoint Services when
you assign per-list permissions.
■
The user rights and the corresponding permissions differ between SharePoint
Portal Server and the Windows SharePoint Services. This is because of the differences in the functionality and feature set of these two products. Some rights
are the same—for example, View Pages. However, the rights that relate to
managing areas, alerts, user profiles, audiences, and search are distinctly different because these features are present only in SharePoint Portal Server.
The SharePoint Portal Server user rights and corresponding permissions are
listed in Table 6-3.
Table 6-3
SharePoint Portal Server User Rights and Corresponding
Permissions
Right
Permissions
Add and Customize Pages
Add, change, or delete HTML pages or Web Part Pages,
and edit the portal site by using a Windows SharePoint
Services–compatible editor
Add Items
Add items to lists, add documents to SharePoint document
libraries, add Web Discussion comments
Add/Remove Personal Web
Parts
Add or remove Web Parts on a personalized Web Part
Page
Apply Style Sheets
Apply a style sheet (.CSS file) to an area or the portal site
Browse Directories
Browse directories in an area
Cancel Check-Out
Check in a document without saving the current changes
Create Area
Create an area on the portal site
Create Personal Site
Create a personal SharePoint site
Create Sites
Create SharePoint sites by using Self-Service Site Creation
Delete Items
Delete items from a list, documents from a document
library, and Web discussion comments in documents
Edit Items
Edit items in lists, edit documents in SharePoint document
libraries, and customize Web Part Pages in SharePoint
document libraries
Manage Alerts
Change alert settings for the portal site and manage alerts
for users
Manage Area
Delete or edit the properties for an area on the portal site
Manage Area Permissions
Add, remove, or change user rights for an area
Manage Audiences
Add, change, or delete audiences
Manage Personal Views
Create, change, and delete personal views of lists
Manage Portal Site
Specify portal site properties and manage site settings
Chapter 6: Security Architecture for SharePoint Products and Technologies
Table 6-3
139
SharePoint Portal Server User Rights and Corresponding
Permissions (continued)
Right
Permissions
Manage Search
Add, change, or delete index and search settings in the
portal site
Manage User Profiles
Add, change, or delete user profile information and
properties
Search
Search the portal site and all related content
Update Personal Web Parts
Update Web Parts to display personalized information
Use Personal Features
Use alerts and personal sites
View Area
View an area and its contents
View Pages
View pages in an area
As in Windows SharePoint Services, users are granted permissions to a portal
site through direct or indirect membership in a site group. However, the difference
in assigning rights is that cross-site groups are not supported in SharePoint Portal
Server; cross-site groups are supported only in Windows SharePoint Services. In
SharePoint Portal Server, users can be added directly to a site group or they can be
members of a Windows domain group that is added to a site group. Figure 6-3
shows the means by which users are granted permissions to a portal site.
Site
Permissions
Site group
Windows security
group
User
Figure 6-3
F06XR03
Granting user permissions to a portal site
You can adjust access to areas of the portal site by assigning users to a site
group for a specific area. You can customize security for each area in the portal by
adding, editing, or removing users or site groups.
140
Part II: SharePoint Products and Technologies Architecture
By default, security settings on a parent area will be applied automatically to all
its subareas. Adding users or groups to a specific area will break the inheritance of
security settings: if you customize the security on a subarea, the subarea will no
longer inherit changes made to the parent area.
Site Creation Rights
Site creation rights (Create Sites and Create Personal Site) control whether users can
create portal sites and personal sites.
The Create Sites right allows users to create portal sites by using Self-Service
Site Creation. As in Windows SharePoint Services, the Self-Service Site Creation is
disabled by default in SharePoint Portal Server—you must turn on the feature to use
it. By default, the new sites are created using the default content database; you can
configure the alternate content database. For details, refer to Chapter 18, “Managing
SharePoint Portal Server 2003.”
The Create Personal Sites right allows users to create a personal site by clicking
My Site on the title bar on the portal home page. Site administrators control the location and site naming format for the personal sites on the portal by using the Manage
Personal Sites page.
Anonymous Access
Anonymous access allows users to view pages on your portal site anonymously or
to perform searches anonymously. When you enable anonymous access in SharePoint Portal Server, you are enabling access to your site for the IIS anonymous
account IUSR_machinename.
Anonymous access is disabled by default and is controlled at the portal-site
level. To enable anonymous access, you must first verify that IIS is configured to
allow anonymous access, and then enable anonymous access for your portal site by
using SharePoint Portal Server Central Administration pages.
If you need to retain the ability to authenticate users as well as provide anonymous access, you can create a new virtual server, extend this virtual server, and
then enable anonymous access for this virtual server by using SharePoint Portal
Server Central Administration. In this case, users who access the original portal site
will require authentication while users who access the new virtual server will have
anonymous access.
Note To create and extend a virtual server, you must be a member of the
local administrators group. To enable anonymous access or manage anonymous access settings, you must be an Administrator on the portal site, a
member of the SharePoint Administrators group, or a member of the local
administrators group.
Chapter 6: Security Architecture for SharePoint Products and Technologies
141
After you have enabled anonymous access for your portal site, you can allow
anonymous users to access and view pages and to perform searches on your portal
site. If anonymous access is disabled for your site, it cannot be enabled for viewing
areas or performing searches.
More Info For detailed instruction on configuration steps for setting up
anonymous access for a portal site, refer to Chapter 18, “Managing SharePoint Portal Server 2003.”
Performing Administration Tasks
SharePoint Portal Server is built on Windows SharePoint Services, so it comes as no
surprise that as far as performing administration tasks are concerned, the permissions remain essentially the same:
■
To perform any administrative tasks that affect settings for all portal sites and
virtual servers on the server computer, a user must be an administrator for the
server computer or a member of the SharePoint administrators group.
■
Users assigned to the Administrator site group are administrators only for a particular portal site.
Security for Backward-Compatible Document Libraries
It is a frequent requirement to restrict access to information in the backward-compatible document library (Web Storage System–based). In some cases, it is required
to restrict the viewing of a document to users who edit or approve it, until it is ready
for a larger audience.
In the backward-compatible document library, SharePoint Portal Server roles
add actions such as check-in, check-out, publish, and approve to traditional fileaccess permissions such as Read, Write, and Change. There are three fixed roles;
each role identifies a specific set of permissions, as follows:
■
Coordinators handle management tasks.
■
Authors add and update files.
■
Readers have read-only access to published documents.
Access permissions for the three roles are fixed and cannot be modified. SharePoint Portal Server also offers the option of denying users access to specific documents. Roles are usually specified at the folder level, although you can add
coordinators at the document-library level for management tasks.
142
Part II: SharePoint Products and Technologies Architecture
Search Results
SharePoint Portal Server recognizes security policies in use on your organization’s
servers, file shares, and databases during searches. This authorization is important,
as it prevents users from finding documents to which they have no access when
they perform searches in the portal site. For detailed discussion on the search architecture, functionality, and configuration, refer to Chapter 21, “The Architecture of the
Gatherer,” and Chapter 22, “Managing External Content in Microsoft Office SharePoint Portal Server 2003.”
Code Access Security
SharePoint Products and Technologies Services use code access security to control
access to protected resources. Code access security is a security mechanism that lets
you assign to a SharePoint Products and Technologies application a configurable
level of trust that corresponds to a predefined set of permissions. Code access security allows code to be trusted to varying degrees, depending on where the code
originates and on other aspects of the code’s identity. Code access security provides
the following functionality:
■
Defines permissions and permission sets that represent the right to access various system resources
■
Enables administrators to configure security policy by associating sets of permissions with groups of code (code groups)
■
Enables code to request the permissions it requires to run, as well as the permissions that would be useful to have, and specifies which permissions the
code must never have
■
Grants permissions to each assembly that is loaded, based on the permissions
requested by the code and on the operations permitted by security policy
■
Enables code to demand that its callers have specific permissions
■
Enables code to demand that its callers possess a digital signature, thus allowing only callers from a particular organization or site to call the protected code
■
Enforces restrictions on code at run time by comparing the granted permissions of every caller on the call stack to the permissions that callers must have
To determine whether code is authorized to access a resource or perform an
operation, the runtime’s security system walks the call stack, comparing the granted
permissions of each caller to the permission being demanded. If any caller in the call
stack does not have the demanded permission, a security exception is thrown and
access is refused.
Chapter 6:
Security Architecture for SharePoint Products and Technologies
143
To allow the administrator to switch levels of trust assigned to an application,
in addition to the ASP.NET default security policy files Windows SharePoint Services
provides two policy files of its own: Windows SharePoint Services Minimal
(WSS_Minimal) and Windows SharePoint Services Medium (WSS_Medium). When a
virtual server is extended to host Windows SharePoint Services, the WSS_Minimal
policy is applied to it by default.
SharePoint Products and Technologies Code Access Security Policies
The WSS_Minimal and WSS_Medium policy files are located by default in the folder
<Local Drive>:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\60\config\. The files are named wss_minimaltrust.config and
wss_mediumtrust.config, respectively. Permissions in WSS_Minimal and
WSS_Medium policy files are listed in Table 6-4.
Table 6-4
Permissions Defined in WSS_Minimal and WSS_Medium Policies
Permission
WSS_Medium
WSS_Minimal
AspNetHostingPermission
Medium
Minimal
Environment
Read: TEMP, TMP, OS, USERNAME,
COMPUTERNAME
FileIO
Read, Write, Append,
PathDiscovery:Application Directory
IsolatedStorage
AssemblyIsolationByUser, UserQuota
specified
Security
Execution, Assertion, ControlPrincipal,
ControlThread, RemotingConfiguration
WebPermission
Connect to origin host (if configured)
DNS
Unrestricted or all subpermissions
granted
SqlClientPermission
Unrestricted or all subpermissions
granted
SharePointPermission
SharePointPermission.ObjectModel
WebPartPermission
WebPartPermission.Connections
Execution
WebPartPermission.Connections
Both WSS_Minimal and WSS_Medium policies extend ASP.NET default policy
files. These policies grant Full trust to assemblies in the global assembly cache
(GAC) and $CodeGen, but they only partially trust the assemblies installed in the /
bin directory of the virtual server.
In addition to the default set of permissions defined by ASP.NET and the common
language runtime, SharePoint Products and Technologies has defined two custom permissions, SharePointPermission and WebPartPermission, as part of the Microsoft.SharePoint.Security namespace located in the Microsoft.SharePoint.Security.dll. All code that
144
Part II: SharePoint Products and Technologies Architecture
tries to access the SharePoint Products and Technologies class libraries needs the
SharePointPermission with the ObjectModel property set to true. For a full list of
SharePointPermission and WebPartPermission attributes, refer to the “Microsoft
Windows SharePoint Services and Code Access Security” whitepaper located at
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/odc_sp2003_ta/
html /sharepoint_wsscodeaccesssecurity.asp.
Based on the requirements and the trust associated with assemblies installed in
the /bin directory of the virtual server extended with SharePoint Products and Technologies, administrators can choose to change the permissions associated with these
assemblies. An easy approach is to change the policy applied to the virtual server by
changing the trust level attribute in the web.config file of the specific virtual server.
The default levels of trust, listed in permissions order, are as follows:
■
Full
■
High (This is an ASP.NET default level, so the SharePointPermission and WebPartPermission will not be granted.)
■
WSS_Medium
■
Medium (This is an ASP.NET default level, so the SharePointPermission and
WebPartPermission will not be granted.)
■
Low (This is an ASP.NET default level, so the SharePointPermission and WebPartPermission will not be granted.)
■
WSS_Minimal
■
Minimal (This is an ASP.NET default level, so the SharePointPermission and
WebPartPermission will not be granted.)
If your code tries to perform an action or access a resource that is protected by
the common language runtime, the default permissions might be insufficient and
your code might need one or more of the default ASP.NET permissions.
Note If you want to use the classes and members in the Microsoft.SharePoint.Portal.SingleSignOn namespace, your code will need an additional
permission, SingleSignonPermission.Access. Refer to Chapter 26 for
detailed instructions.
Chapter 6: Security Architecture for SharePoint Products and Technologies
145
There are several ways to make sure your code has the required permissions to
access the SharePoint Products and Technologies class libraries, as follows:
■
Create a custom security policy and assign the SharePointPermission with the
ObjectModel property set to true to the specific assembly or set of assemblies.
Refer to Chapter 39, “Using Microsoft Office InfoPath with SharePoint Products
and Technologies,” for detailed instructions.
■
Install the assembly in the global assembly cache, as the code in it always has
Full trust. Although installing your Web Part assembly in the GAC is a viable
option, it is recommended that you install Web Part assemblies in the /bin
directory for a more secure deployment. For the full list of pros and cons
of installing an assembly into the GAC, refer to http://msdn.microsoft.com
/library /default.asp?url=/library/en-us/odc_sp2003_ta/html
/sharepoint_wsscodeaccesssecurity.asp.
■
Raise the trust level for the virtual server extended with SharePoint Products
and Technologies by changing the trust level attribute in the web.config file.
For example, to change the policy level of a virtual server from WSS_Minimal
to WSS_Medium, perform the following steps:
1. Open the web.config file of the virtual server in a text editor such as
Notepad.
2. Search for
<trust level="WSS_Minimal” originUrl="“ />.
3. Change the level to the following: <trust
level="WSS_Medium” originUrl="“ />
4. Save the web.config file.
5. Reset Internet Information Services (IIS) by using iisreset in the command
prompt.
Communication Security
Secure communication between the components of a SharePoint Products and Technologies deployment is a vital element of an in-depth security architecture. In SharePoint Products and Technologies deployments, it’s important to apply secure
communication techniques for both inside and outside the firewall. Secure communication provides privacy and integrity of data.
Privacy ensures that data remains private and confidential, and that it cannot
be viewed by eavesdroppers armed with network-monitoring software. Privacy is
usually provided by means of encryption.
Integrity ensures that data is protected from accidental or deliberate (malicious) modification while in transit. Secure communication channels must provide
integrity of data. Integrity is usually provided by using Message Authentication
Codes (MACs).
146
Part II: SharePoint Products and Technologies Architecture
To provide security of communication, you can use the following technologies:
■
Secure Sockets Layer/Transport Layer Security (SSL/TLS). Secure Sockets Layer (SSL) is a public key–based security protocol that comprises a set of
cryptographic technologies that provides authentication, confidentiality, and
data integrity. It is most commonly used to secure the channel between a
browser and a Web server. However, it can also be used to secure communications to and from a database server running Microsoft SQL Server 2000.
■
Internet Protocol Security (IPSec). IPSec provides a transport-level secure
communication solution and can be used to secure the data sent between two
computers. IPSec is a transport-layer mechanism through which you can
ensure the confidentiality and integrity of TCP/IP-based communications
between computers. IPSec is completely transparent to applications because
encryption, integrity, and authentication services are implemented at the transport level.
In this section, we will look into communication security for SharePoint Products and Technologies, including the following topics:
■
Communication with Microsoft SQL Server
■
Communication between index and search servers in the SharePoint Portal
Server server farm deployments
■
Using firewalls to protect SharePoint sites
■
Using SSL for extranet sites
Communication with Microsoft SQL Server
In SharePoint Products and Technologies deployments, connections between the
front-end Web server and the computer running SQL Server are not encrypted. It is
recommended that you implement Secure Sockets Layer (SSL) or otherwise encrypt
server-to-server communications—for example, by using IPSec.
If you decide to use SSL to secure communication with SQL Server 2000, you
need to perform the following steps:
1. On a computer running SQL Server, obtain and install a server certificate.
2. The certificate authority (CA) that issued the certificate must be trusted by connecting clients. To achieve this, on the client computers, such as front-end Web
servers, install the certificate of the issuing CA.
3. On the computer running SQL Server, use Server Network Utility to configure
whether to force all clients to use SSL or to allow clients to choose whether or
not to use SSL.
Chapter 6: Security Architecture for SharePoint Products and Technologies
147
More Info For more information, refer to Microsoft Knowledge Base article
276553, “HOW TO: Enable SSL Encryption for SQL Server 2000 with Certificate Server” at http://support.microsoft.com/default.aspx?scid=276553.
If you decide to use IPsec to secure communication with SQL Server 2000, you
need to perform the following steps:
1. Create an IP Security policy on the database server computer.
2. Export the IPSec policy that you have created, and copy it to the front-end
server computer.
3. On both the database server and the remote server computers, assign the IPSec
policy. An IPSec policy must be assigned before it becomes active.
More Info For more information about IPSec, refer to TechNet at http:
//www.microsoft.com/technet/prodtechnol/windows2000ser v/howto
/ipsecwt.mspx.
Communication Between Index and Search Servers
In a server farm running SharePoint Portal Server, when indexes are propagated
from an index management server to a search server, the transmission is not
encrypted and therefore might not be secure. It is recommended that you implement
IPSec to secure the communication between the index server and the search servers.
To use IPsec to secure the propagation of indexes, do the following:
1. Create an IP Security policy on the index management server computer.
2. Export the IPSec policy to each of the search server computers.
3. On index server and search server computers, assign the IPSec policy to
activate it.
Using Firewalls to Protect the SharePoint Sites
When a SharePoint site provides services across an extranet or is accessible from the
Internet by the general public, it is essential that external access to the site occurs
through a firewall. The firewall inspects all incoming and outgoing traffic, and then
allows or disallows the traffic based on the preconfigured policies.
148
Part II: SharePoint Products and Technologies Architecture
On a simple level, firewalls perform packet filtering: when traffic comes to the
firewall, it compares the data in the IP header with the preconfigured rules to determine whether to allow or deny access. However, to protect SharePoint Portal Server
deployments from external attacks, it is also necessary to check and verify the payload inside the HTTP header. Microsoft Internet Security and Acceleration (ISA)
Server 2000 firewall is an application-layer firewall that, in addition to packet filtering,
provides the ability to examine the content contained in the application-level protocols such as HTTP. Refer to Chapter 25, “Firewall Considerations for SharePoint Portal Server Deployments,” for detailed information on the ISA server configuration for
making your SharePoint sites available to external users without compromising the
security of your internal network.
Using SSL for Extranet Deployments
In the Web environment, SSL is commonly used between Web browsers and frontend Web servers to create a secure communication channel. In SharePoint Products
and Technologies deployments, SSL provides a secure way of establishing an
encrypted communication link with users who connect to the SharePoint sites from
outside the firewall.
For a detailed discussion of SSL and instructions on how to enable it in your
environment, refer to Chapter 27, “Securing an Extranet Using SSL and Certificates.”
Summary
In this chapter, we looked at the security mechanisms SharePoint Products and
Technologies uses to provide secure access for users and reduce the threat of security compromise. User authentication is built on underlying technologies such as IIS
and ASP.NET and uses Windows security principals, while access authorization is
based on a site group membership that associates each user directly or indirectly
with a permission that controls the specific actions that the user can perform. Code
access security allows you to configure granular access for the SharePoint Products
and Technologies application code. Communication security is vital for making sure
that the data is transmitted securely both inside and outside the firewall. Because
SharePoint Products and Technologies security is layered on top of the security of
many underlying technologies, it is important to implement a defense-in-depth
approach that addresses security across all components of your SharePoint Products
and Technologies deployment.
Chapter 7
Architecting SharePoint
Products and Technologies
for Operating System
Topologies
In this chapter:
Specific Requirements for Server and Client . . . . . . . . . . . . . . . . . . . . . . . 149
Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
Administrative Rights . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
User Account Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
Controlling Access to Sites. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
Active Directory–Dependent Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
Specific Requirements for Server and Client
The latest versions of Microsoft SharePoint Products and Technologies have specific
requirements for software and for domain membership. Both Microsoft Office SharePoint Portal Server and Microsoft Windows SharePoint Services must be installed on
Microsoft Windows Server 2003, and most, but not all, configurations require that the
server running either of these applications be a member of a domain. Of course, all
features are available if the domain is a Windows Server 2003 domain, but what if a
network environment does not have a Windows Server 2003 domain? In a Microsoft
Windows NT domain environment, SharePoint Products and Technologies have
much of the same functionality.
149
150
Part II: SharePoint Products and Technologies Architecture
Server Requirements
Although all configurations of Windows SharePoint Services must be installed on a
Windows Server 2003 server, not all configurations require a domain. Single-server
Windows SharePoint Services installations can be installed on servers that are not
members of a domain. In all other configurations, all servers—such as those in a
server farm—must be members of the same domain.
SharePoint Portal Server requires domain membership for all servers in all configurations. Installing and operating a computer running SharePoint Portal Server is
not supported if the server is a member of a workgroup. However, any domain type
can work. This means that SharePoint Portal Server is supported on Windows Server
2003 servers that are members of a Microsoft Windows NT 4.0, Windows 2000, or
Windows Server 2003 domain.
Client Requirements
Regardless of the type of client that connects to SharePoint Products and Technologies, the features that are available are the same. However, these features can be
implemented differently based on the capabilities of the different browsers. Any
Windows, Macintosh, or UNIX client can use the available features, provided the
client runs the following software:
■
Microsoft Internet Explorer 5.01 with Service Pack 2
■
Internet Explorer 5.5 with Service Pack 2
■
Internet Explorer 6
■
Internet Explorer 5.2 or later for Macintosh
■
Netscape Navigator version 6.2 or later
A client program such as Microsoft Office 2003 is not necessary for browsing
but is required if the user contributes to documents on a website. For example, if a
Word document exists on a site and a user would like to edit that document,
Microsoft Word 2003 is required to edit the document directly from the site.
Authentication
Authentication is the process used to validate the user account that is attempting to gain
access to a website or network resource. Authentication for Windows SharePoint Services websites is handled by Internet Information Services (IIS). Windows SharePoint
Services uses the authentication method you specify for a virtual server in IIS to control
authentication for all top-level websites and subsites of that virtual server. Windows
SharePoint Services works with the following authentication methods in IIS:
Chapter 7:
Architecting SharePoint Products and Technologies for Operating System Topologies
■
Anonymous authentication
■
Basic authentication
■
Integrated Windows authentication
■
Certificate authentication (using Secure Sockets Layer)
151
All these methods are available regardless of the type of domain to which the
front-end servers belong.
Administrative Rights
Two sets of users are allowed to perform administrative functions for Windows
SharePoint Services: members of the administrators group for the local server computer and members of the SharePoint administrators group. The SharePoint administrators group is a domain group that is registered with Windows SharePoint
Services. The SharePoint administrative group is not created by default. The user
who installs Windows SharePoint Services can create this group during installation,
and it can contain a domain group, local user, or domain user.
Members of this domain group can perform Central Administration tasks
without having to be given administrator rights to the local server computer. This
is particularly useful in a server farm, because you can grant rights across the
server farm rather than individually for each computer in the server farm. This is
also useful for applications that call the administrative object model for Windows
SharePoint Services. If the application process can be configured to run as a member
of the SharePoint administrators group, it can create new sites, modify quota values
for sites, and so on.
There are some operations that members of the local administrator’s group can
perform that members of the SharePoint administrator’s group cannot perform.
These tasks include:
■
Configuring the SharePoint Central Administration virtual server
■
Enabling full-text search
■
Extending virtual servers in Windows SharePoint Services
■
Managing content databases (i.e., changing properties, etc.)
■
Managing paths (inclusions/exclusions)
■
Running the stsadm.exe command-line utility
■
Setting the configuration database properties
■
Setting the default content database server
■
Setting the SharePoint Administration Group
■
Removing Windows SharePoint Services from a virtual server
152
Part II: SharePoint Products and Technologies Architecture
User Account Mode
When you install Windows SharePoint Services, you must choose which mode you
want to use to allow users access to Windows SharePoint Services sites. Windows
SharePoint Services can work with two modes: domain account mode and Active
Directory account creation mode. Domain account mode is used inside organizations to grant access to users that have existing Windows domain accounts. Active
Directory account creation mode can be used by Internet service providers to create
unique accounts for customers using the Active Directory directory service.
In domain account mode, you use existing domain user accounts. If you
choose Active Directory account creation mode, you are choosing to have accounts
automatically created in the Active Directory organizational unit you specify. In
either mode, you use the same methods to manage users of a site. You add them to
the site by using their existing domain or Active Directory accounts, and then assign
them to site groups to give them the rights they need to use the site.
The choice between user account modes is a one-time-only choice because it
affects how the configuration database for your server or server farm is created. You
cannot change user account modes after creating the configuration database, and
this step is one of the first choices made during installation when using Microsoft
SQL Server. If Windows Microsoft SQL Server 2000 Desktop Engine (WMSDE) is
used, the account creation mode is set to domain account mode and cannot be
changed.
In a Windows 2000 or Windows Server 2003 domain, Windows SharePoint Services can use Active Directory account creation mode. In a Windows NT domain,
the domain account mode is needed.
Controlling Access to Sites
Windows SharePoint Services provides the ability to control site access through the
use of site groups. Site groups let you specify which of your users can perform specific actions in your site. For example, a user who is a member of the Contributor
site group can add content to Windows SharePoint Services lists, such as the Task
list, or a document library.
Because SharePoint Portal Server is designed to work in an Active Directory
environment, some functionality for administrative tasks is unavailable. When adding a user to the portal site by clicking Add Users on the Manage Users page, the
Select Users And Groups – Web Page Dialog dialog box should appear. However,
this feature does not work with Windows NT domains. This dialog box searches for
and adds users to the site. As a work-around try the following steps:
1. On the Site Settings page, in the General Settings section, click Manage users.
2. On the Manage Users page, click Add Users.
Chapter 7:
Architecting SharePoint Products and Technologies for Operating System Topologies
153
3. In the Step 1: Choose Users section, type the name of the user or users to add
in the Users box.
(Enter names in the format DomainName\UserName. For more than one user,
separate each user name with a semicolon character [;].)
4. In the Step 2: Choose Permissions section, select the check boxes next to
the site groups to which the users are to be added, and then click Next.
5. In the Step 3: Confirm Users section, verify the e-mail address, user name,
and display name information of the user or users.
6. In the Step 4: Send E-mail section, select the Send the following e-mail to
let these users know they’ve been added check box to notify users. Type a
message to include, if needed.
7. Click Finish.
Active Directory–Dependent Features
Some features available in SharePoint Portal Server are dependent on Active Directory. Although most features can still be used in a Windows NT environment, they
will need to be configured manually. The features that work with Active Directory
include user profiles and audience compilation.
The user profiles feature in SharePoint Portal Server populates a database of
user profiles by importing the profiles from Active Directory. Without an Active
Directory environment, the accounts must be typed into the user profiles database.
This can be done in the Manage User Profile page in the Central Administration site.
Also, when an audience is compiled in an Active Directory environment, rules are
used as filters against the profile database to create a subset of users. Because not all
profile information is imported into the SharePoint Portal Server profile database,
Active Directory is checked during an audience compilation if any additional information is needed. Without Active Directory the information is limited to what is
manually entered into the user profiles database.
Active Directory Application Mode
The new Active Directory Application Mode (ADAM) lets you run Active Directory
as an application in your Windows Server 2003 domains. An application can use
Active Directory Application Mode to store “private” directory data (data that is relevant only to the application) in a local directory service, perhaps on the same
server as the application, without requiring any additional configuration to the network operating system (NOS) directory. ADAM can support directory-enabled applications running in Microsoft Windows NT 4.0 domains. Because ADAM works with
the Windows-integrated security infrastructure, it can also authenticate users from
Windows NT 4.0 domains.
154
Part II: SharePoint Products and Technologies Architecture
Currently SharePoint Products and Technologies does not integrate with Active
Directory Application Mode. This is because ADAM does not provide actual logon
tokens, but instead provides only LDAP names. SharePoint Portal Products and
Technologies requires logon tokens for authentication.
Summary
Upgrading your domains and forests to Windows Server 2003 domains and forests
with Active Directory is the optimal way of getting the maximum functionality out of
Windows Server 2003. However, not all network environments have a Windows
Server 2003 domain. SharePoint Products and Technologies can be installed into a
Windows NT domain with the loss of only some features. Many features still work,
but require a manual configuration to function with Active Directory.
Part III
Planning and Deployment
In this part:
8
Planning Your Information Structure Using Microsoft Office
SharePoint Portal Server 2003 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
9
Capacity Planning. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185
10
Performance Monitoring in Microsoft Office SharePoint Portal Server 2003 . . . 237
Chapter 8
Planning Your Information
Structure Using Microsoft
Office SharePoint Portal
Server 2003
In this chapter:
Key Information Management Features of SharePoint
Portal Server 2003 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158
Where to Start . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158
Key Decision Areas for SharePoint Portal Server 2003. . . . . . . . . . . . . . . 160
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
Microsoft Office SharePoint Portal Server 2003 has several compelling features and
tools that make it an ideal solution for implementing your information management
system. Managing information well is critical to any organization’s success. Poor
information management leads to inefficient collaboration, ineffective decision-making processes, and lost business opportunities.
SharePoint Portal Server 2003 does not automatically organize your information into an overall taxonomy for you. Instead, you’ll need to plan and implement
your own taxonomy. (A taxonomy is a method of organizing or categorizing information and information resources.) Because each environment is unique, you
should take the planning process seriously and understand that installing SharePoint
Portal Server 2003 is not the same thing as implementing it.
In this chapter, we’ll outline the key decision areas that must be addressed
before a product server is ever built—specifically, during the architecting and planning phases. You shouldn’t be surprised to learn that the key decision areas are built
on the information management features of this product.
157
158
Part III: Planning and Deployment
Key Information Management Features of SharePoint
Portal Server 2003
The key information management features of SharePoint Portal Server 2003 include
the following:
■
Search and indexing
■
Document collaboration
■
Best Bets and keywords
■
Areas and Topics
■
Personal sites (personal site)
■
Audience targeting
■
User profiles
■
Site collections
■
Site directory area
The purpose of this chapter is not to discuss how to implement or administer
each of these features. Instead, the focus of this chapter is on planning for the
implementation for each of these features and showing how they relate to the overall information management picture.
Where to Start
When beginning the planning process for a new information management system,
you’ll need to start by answering two basic questions:
■
What information does your organization need to have and use to be successful?
■
Where is that information right now?
It might seem a bit silly, but most IT professionals bypass these two questions
and immediately get to work on building an information management system without
ever considering where their information currently resides. Because most organizations don’t have an overall structure to their information, they don’t have a good
understanding of where their business-critical information currently resides and, surprisingly, what that information really is (and isn’t). When asked, most project managers and system administrators will acknowledge that the organization’s current
information resides in a plethora of disconnected data islands, including the following:
■
People’s minds
■
E-mail
■
Public folders
■
File servers
Chapter 8: Planning Your Information Structure
■
Local hard drives
■
Databases
■
Web pages and websites
■
Filing cabinets
■
Applications
■
Document management systems
■
Credenzas
■
Users’ home directories
159
These data islands cannot be connected unless they are first identified and
inventoried for the data that they host. Only after an organization knows where its
information resides and what that information is can it really begin the process of
detailing how that information will be accessed using SharePoint Portal Server 2003,
how it will be structured, and how information growth will be accommodated.
This is not an easy process. Much of this work will need to be accomplished at
the team or departmental levels. And this process can become time consuming,
requiring thoughtful analysis and methodical discovery of where employees go to
get the information they need to perform their jobs and what that information is.
Many administrators who are asked to play the role of an information architect
jump ahead and begin the planning process by looking at the organizational chart.
They quickly conclude that they should have site collections for each department, a
child portal site for each division, and perhaps an overall portal site for the entire organization. These hastily determined structures are nearly always modified from their
original configuration because the decisions used to construct them lack any real basis.
Even though SharePoint Products and Technologies is very flexible and can
support both the technical needs of an organization as well as its cultural needs, it’s
not wise to jump ahead of the planning process and start near the end. As you read
through this chapter, you’ll begin to understand what is meant by this, but for now,
the following example will suffice.
You might start the process by quickly looking at your organizational chart and
concluding that you’ll need one document library for each collaboration team in
your organization. However, upon closer inspection, you’ll need a different document library for each unique combination of user permission assignment, document
profile matrix, approval group, and site placement. Unless you know which documents you want to host in a portal site, which ones you want to host in a team site,
and who should access these documents, it will be difficult to know how many document libraries to create and where to create them.
Perhaps your organization will allow the end users to create their own sites and
document libraries. And certainly, SharePoint Portal Server 2003 and Windows SharePoint Services support this. But it is best—at least for capacity-planning purposes—to
have at least a rough idea of what your document library matrix will look like.
160
Part III: Planning and Deployment
As part of the architecting and planning processes, an organization is well
advised to determine where their information currently resides and what that information is. Once you have that information, the planning processes presented in this
chapter for using SharePoint Portal Server 2003 to implement a new structure for
your information will be of more value to you.
Note It is important to understand that many of the planning processes
we discuss in this chapter are ongoing processes an organization will perform well into the future. SharePoint Portal Server 2003 can be implemented without doing much of this work, but most system administrators
and architects who have skipped the planning processes have found that
their implementations were much less effective and successful than those
who did perform the planning processes. Even with good planning, however,
most organizations will need to return to the concepts presented in this
chapter multiple times as they hone their organization-wide taxonomy.
Key Decision Areas for SharePoint Portal Server 2003
There are several key decision areas that you’ll want to address as part of your preimplementation planning process. We’ll discuss these areas in this section.
Planning Search
This section describes the components of the SharePoint Portal Server search functionality. It provides guidelines on planning a customized version of each search
component for your solution.
Overview of Search Functionality
There are four components that contribute to the SharePoint Portal Server search
functionality:
■
Content sources
■
Content indexes
■
Source groups
■
Search scopes
Content Sources
A content source is a location where content is stored. A content source specifies the
starting place for crawling a file system, a portal site, a SharePoint site, an Exchange
Public Folder, a Lotus Notes database or a website. The content can be located in a
Chapter 8: Planning Your Information Structure
161
different portal site on the same server, on another server within your intranet, or on
the Internet.
SharePoint Portal Server builds a content index by crawling the locations specified by the content sources and storing the results—such as Web pages and files.
For some content source types such as file shares and SharePoint sites, the content
index also stores the appropriate security credentials on the crawled content. This
enables the search results to show only items to which a user has access by enforcing the security settings on each document as the result set is built.
You need to consider what information will and will not be hosted in SharePoint Portal Server. For example, documents that will remain on a file server will
need to be crawled if those documents are to appear in the search result set. Knowing that you have those documents and where they currently reside allows you to
make an informed decision about whether the documents should be moved into a
SharePoint document library or crawled and left in their current location.
Generally speaking, older documents that will not change need not be placed
in a SharePoint document library if the only method needed to find those documents is the Search method. However, if users will need to browse the taxonomy
hierarchy to find older documents, you’ll need to move the documents into a SharePoint document library or at least link to them using a links list.
Content Indexes
A content index is a flat text file that holds the data from crawled content in a content
source. Updating a content index requires crawling the locations specified by the
content sources and storing the results on the job server. Propagating a content index
consists of copying the index from the index server to the search servers. A portal site
search returns results from the content indexes stored on the search servers.
Every portal site includes content indexes that allow users to search for documents inside or outside the portal site. After content is included in an index, the content appears in search results on that portal site.
Source Groups
Source groups, topics, and areas are the elements of search scopes. Search scopes
allow you to define the breadth and depth of searches within portal sites and across
portal sites. These assignable components can create very flexible searches.
A source group is a list consisting of one or more content sources. Source
groups are one of the elements used to define search scopes. Source groups are created and managed at the shared services level (if you are using shared services) and
can be assigned in any combination to a portal site search scope. These characteristics allow you to easily define search scopes across portal site boundaries. For example, if you want your marketing portal site users to be able to search content on the
sales portal site, you can create a search scope consisting of a source group that
encompasses all sales portal site data and a source group that encompasses all marketing portal site data.
162
Part III: Planning and Deployment
Search Scopes
A search scope is a list of one or more source groups, in combination with any specified areas and topics located on the portal site on which they are defined. Search
scopes allow users to narrow their searches based on the topics, areas, and content
sources of items on the portal site.
Search scopes can be limited by topics and areas, or by groups of content
sources. Source groups outside the portal site can be grouped, and you can limit
your search scope to exclude or include particular source groups.
Search scopes are defined by a portal site administrator and are exposed only
to the portal site on which they are created. For example, a search scope created on
the Human Resources portal site named “this portal site” might consist of a source
group containing content sources that define all content on the HR file server. This
scope would be available only on the HR portal site.
Note You can use search scopes from remote portal sites to give your overall search scope taxonomy consistency throughout the portal sites in your
organization. This is an advanced topic that is covered in Chapter 22, “Managing External Content in Microsoft Office SharePoint Portal Server 2003.”
Search scopes appear to all users in a drop-down list next to the portal site
search box. These search scopes are typically limited to specific topics and source
groups that are important and common enough to make them useful to users in the
organization as a separate searchable scope.
Planning Content Indexes
SharePoint Portal Server 2003 comes with two content indexes. You can create as
many as you need. However, keep in mind that each search query has to be run on
each index and the results aggregated before they are returned to the user. The
result is that the more indexes you have, the longer search results take to generate.
Also, the more index files you have, the greater the possibility is that ranking in the
result set will be skewed. This is because that ranking is determined on a per-index
file basis and there is no support for single-set ranking when the result set is generated from multiple index files. The advantages of having more (and thus smaller)
index files is that propagation between an Index and Search server in a server farm
scenario is much faster than copying a few very large index files from the Index to
the Search server.
Chapter 8: Planning Your Information Structure
163
Note Advanced Search Administration mode should be enabled so that
you can create and manage additional indexes. In addition, when you create
content sources, you can specify the index in which the content source will
appear and the source group.
When planning content indexes, consider the following factors:
■
Number of documents. If the number of documents is very large, you
should consider breaking the content sources into many content sources with
smaller scopes. Doing this will make the size of the indexes more manageable.
■
Security. The default content access is used as the security context through
which all content sources are crawled. This account needs only Read access,
regardless of which content source it is crawling. You can use nearly any
account, but one must be specified as the Default Content Access Account. The
account should have appropriate access for other internal resources such as
site directories, portal site contents, and shared folders, which are part of the
personal site.
For shared folders, you should use an access account that is a member of
the SharePoint Portal Server administrator group. This level of access allows for
crawling all types of content and its properties in portal sites and site directories.
To provide different accounts for crawling content, you must use include
and exclude rules. You should add rules and include paths that you want to be
crawled with different access accounts. These rules are applied to all content
sources bound to a content index that creates additional crawling. To avoid
duplicate or additional crawling, you need to assign rules only to specific content sources.
■
Scheduling. Creating separate content indexes allows you to use more flexible scheduling that is based on the nature of content in each content source.
Some content sources change quickly and need more updates, while other
content sources are less volatile and require fewer updates.
■
Propagation. Having smaller content indexes provides faster propagation of
content indexes to search servers. However, there is a drawback. When a user
initiates a search, the search engine has to run that query against each index
and then aggregate the results. The more indexes you have, the longer it takes.
In addition, if you’re in a federated search environment, you need to
remember that the number of indexes you have and the size of each will affect
how fast these indexes can be propagated or copied from the indexing servers
to the search servers.
164
Part III: Planning and Deployment
Finally, you should remember that if ranking documents in the result set is
important, you should build your index/source group/content source/search
scope topology in such a way that most queries query only one index file at a
time. Ranking is performed on a per-index file basis, and there is no method supported to group results from multiple index files and have the result set reranked
as a single unit. Another solution is to make sure that your index files are statistically equivalent with the same approximate size and number of documents.
■
Backup and restore. Smaller content indexes also provide more flexibility
when backing up and restoring.
Note SharePoint Portal Server does not allow spaces in content index
names. Spaces are supported in source group names. Also, note that
Non_Portal_Content and Portal_Content exist by default.
Planning Search Scopes
Search scopes should be planned with the end user in mind. By this, we mean that
the Scopes should reflect the most natural way that people will want to search for
information. A good search-scope matrix will allow educated users the ability to
tightly define the portion of the overall index they want to search, giving them a
more lean, yet still meaningful result set. A best practice is to ask representatives
from each interested party, department, division, or team to help you create a
search-scope matrix that will enhance the users’ experience in the portal site by
allowing them to search for targeted information.
You’ll also need to consider using a hierarchical approach to your scope
matrix. For example, let’s suppose you have a research department with three
teams: Chemicals, Data Modeling, and Quality. Each team produces documents of
importance to the larger enterprise. In such a scenario, you might find yourself creating four search scopes: chemicals, data modeling, quality, and research. The fourth
scope, research, would encompass the documents from all three teams. By using a
hierarchical approach, you can give the portal site user flexibility in defining the
portion of the overall index that needs to be searched.
In many cases, building the scope matrix will be more art than technology,
meaning that the search-scope matrix will be built over time in response to constructive feedback. In some environments, you might have to place a small icon near the
Search Web Part that will take the user to a Web page that outlines the various search
scopes in the matrix and the information that will be searched via each scope.
If you’ll be using multiple portal sites, you can create a consistent search-scope
experience across all the portal sites by propagating each scope to the other portal
Chapter 8: Planning Your Information Structure
165
site or sites. If you’re planning to have multiple portal sites, you should also plan to
propagate your scopes across all your portal sites unless you have a specific reason
for not doing this.
Note If you want to see changes to a search-scope definition immediately,
you must reset Internet Information Services (IIS) by using the IISRESET
command. This should be done only during the setup process and not when
the system is live in production.
Planning Content Sources
When operating a corporate portal site with multiple divisional portal sites, you
should, at a minimum, configure content sources as follows:
■
One content source for the corporate portal site.
■
One content source for each divisional portal site.
■
One content source for the people in your organization. This content source is
set up by default. It returns matches based on entries in the profile database as
well as content from a user’s personal site.
■
One content source for each divisional Windows SharePoint Services virtual
server in your organization.
You’ll also need to remember the old adage “garbage in, garbage out.” The
tighter and more defined your content sources are, the leaner and more meaningful
the data in the result set will be. For example, if you need to crawl five documents
on a given website that hosts 200 documents, it would not be a best practice to
crawl the entire website. Your index would end up with 195 unneeded documents.
In a situation like this, you might consider creating one content source to crawl all
five documents or even five content sources, one for each document, depending on
their location in the directory structure and if they are shared via the same share or
different shares.
The point here is to remember that what you crawl gets placed in your index
and you should crawl only information that is required to be in your index. This gets
back to our earlier discussion about where your information is and what it consists
of. Knowing this will help you build a tight list of content sources that will, in turn,
give you a tight index that will return highly meaningful results to your users when
they issue a query in the Search Web Part. Good planning is paramount to a successful deployment.
166
Part III: Planning and Deployment
Planning Source Groups
As a starting point, you should define your source groups as follows:
■
Use one source group for each index. Doing this allows you to broadly define
search scopes for each portal site. For example, if your organization chose to
hold all its indexed content in a single content index, the source group
assigned to that index would allow you to easily define a search scope on all
content managed by that index.
■
Use one source group for each content source. Doing this allows you to more
narrowly define search scopes for each portal site. For example, defining a
separate content source for the corporate portal site and one for each divisional portal site would allow you to easily define a search scope on the portal
site content that each source group crawls.
Note SharePoint Portal Server does not allow spaces in content index
names. Spaces are supported in source group names.
When you select the content source as SharePoint Portal Server Site
Directory, define the address of the portal site for the content source (for
example, http://sales/*), and then save definitions of content source
parameters, the address of the content source automatically changes—for
example, it changes to sps://sales/site$$$site/scope=*.
There is no way to directly crawl the virtual server of another team
site. If you want to have certain site collections indexed, you have two
options. The first is to add the site collection to another site directory manually. The second option—which is less optimal—is to add a separate content source for each site collection. The first option is the preferred and
recommended approach.
Planning Deltas Between Source Groups and Content Indexes
A best practice is to create a source group for each content index so that you’ll have
maximum flexibility in creating the search scopes. To use the example from the preceding sections, you’d create a content source to each document group for each
team (chemicals, data modeling, and quality). You would assign each content source
to its own source group, such as Chemicals Source Group, Data Modeling Source
Group, and Quality Source Group. Then, for the research search scope, you’d select
all three source groups to offer portal site users the ability to search documents
across the research department.
Chapter 8: Planning Your Information Structure
167
Propagating Content Indexes
Index propagation occurs only when the Search application and the Index application are run on two different servers in a medium or large server farm. Propagation
happens automatically at the end of every successful update (or crawl). Before
propagation can be successful, the following conditions must be met:
■
You have configured a search service account for the server farm. This account
must have local administrator permissions on the search (destination) server.
■
The destination server is on a trusted domain.
■
There is sufficient disk space available on the destination server. For each
propagated index, allow for more than twice its size in disk space to accommodate both the current index and the propagating index.
■
SMB (Server Message Block) traffic must be enabled between the two servers,
and if there is a firewall between them, the appropriate ports must be opened
too. These ports include the common Netbios and RPC (Remote Procedure
Call) ports.
Propagation is considered successful if the index is successfully copied to any
one search server. If you have a scenario where propagation is successful to one or
more, but not all, search servers, the search servers to which propagation failed is
taken off line, an error is logged in the event log, and the error appears on the propagation status page.
Note If propagation fails because of lack of disk space on the destination
server, SharePoint Portal Server 2003 logs an error in the Application Log of
the Windows Server 2003 Event Viewer (event log) of both the destination
search server and the index management server.
The contents of a new index are not accessible on the search server
until propagation has been completed. The index is not accessible if propagation fails, even if a previous propagation was successful.
Updating Content Indexes
The four methods for updating content indexes are as follows:
■
Full
■
Incremental
■
Incremental (inclusive)
■
Adaptive
168
Part III: Planning and Deployment
The method used to update the index can have a significant effect on performance. The following topics describe these four methods.
Full Update
During a full update, SharePoint Portal Server updates all content in a content index. A
full update of a content source includes adding new content, modifying changed content, refreshing the content index for existing unchanged content, and removing
deleted content from the content index. This is the most time-consuming and resourceintensive type of update, and it should be done only in the following situations:
■
If you create a new rule that affects only one content source.
■
If files are renamed in a specific content source.
■
If it is the first crawl of a content source.
■
If you include or exclude a new file type.
■
If permissions are changed on documents in the content source. While all
updates pick up permission changes, only the full updates pick up changes to
membership in local groups. This is why it is recommended that you not use
local groups to secure content that SharePoint Portal Server crawls.
■
If there is a power outage. In this case, SharePoint will want to run full
indexes to reset the index. It might be faster to reset the index files and clean
them out before running a full index. (Resetting the index files is discussed in
Chapter 22.)
■
If you change the noise word file.
■
If there is an area name change.
■
If you reset the content index.
Given all these changes that will force you to rerun a full index, it is best that
you plan for them so that the full indexes can be run without overloading either the
indexing server or the content source’s server.
Incremental Update
An incremental update of a content source includes only changed content. SharePoint Portal Server does not remove deleted content from the content index and
does not recrawl unchanged content. For this reason, performing an incremental
update is faster than performing a full update.
You can perform an incremental update if you know that content has changed
but you do not want to perform a full update and you don’t mind having some
deleted content continue to appear in your index. A periodic incremental update
creates the index without using the time or resources required for a full update,
which enables you to perform a full update less frequently.
Chapter 8: Planning Your Information Structure
169
Incremental (Inclusive)
SharePoint Portal Server 2003 introduces another type of update known as the incremental (inclusive) update. This update is similar to the incremental update except
that it includes deleted content. The incremental (inclusive) update also detects
deleted entries in the Microsoft Windows SharePoint Services document libraries and
lists. The incremental update detects modified or new documents and list items only.
The incremental update is the least expensive update if it is used with Windows SharePoint Services sites. The incremental (inclusive) update is more resource
intensive than the regular incremental update and should therefore be run less often
if performance is a top priority for you.
Adaptive Update
An adaptive update, like the incremental update, crawls only the content that, statistically speaking, is most likely to have changed since the last adaptive update.
Because adaptive updates are likely to miss at least some content changes, these
updates will crawl all the content in a content source every two weeks.
Unlike the incremental update, the adaptive update increases its efficiency
every time it is run based on a statistical analysis of the historical information on what
content has and has not changed. The time required for an adaptive update varies
and is based on the different types of content sources and the protocol handler.
The recommended approach is to run adaptive updates daily for large source
groups and more often for smaller source groups. Avoid running full updates whenever possible. However, how you choose to configure your index updates is dependent on your search requirements. If your organization is search intensive and
requires immediate updates to the search indexes as new content is added or
removed, you might need to schedule updates to occur more frequently. You must
balance the search requirements with the time it takes to perform an update and
propagate content indexes.
There is also a scheduling factor to consider too. Updates are both processor
and RAM intensive. You’ll want to ensure that you’re scheduling your updates to
occur when your servers running SharePoint Portal Server and Windows SharePoint
Services are not being backed up, scanned for viruses, or performing any other routine that consumes large processor resources, RAM resources, or both. In addition,
you shouldn’t crawl content sources during their nightly routines either. Therefore,
a best practice is to create a schedule matrix and schedule the crawling of content
sources when those sources are being used the least.
Planning Alerts
Alerts provide notification when information of interest is added or updated on the
portal site and associated content sources. You can define areas of interest and identify how and when you want to be notified. You can add an alert to track new
170
Part III: Planning and Deployment
matches to a search query, changes to content in an area, or a new site added to the
Site Directory.
When configuring alerts, keep in mind that alerts for SharePoint Portal Server
2003 and Windows SharePoint Services are managed separately. There are three key
differences between SharePoint Portal Server alerts and Windows SharePoint Services alerts:
■
SharePoint Portal Server alerts are managed by the user on the My Alerts page,
which is located on the user’s personal site. Windows SharePoint Services
alerts are managed through the Manage My Alerts link on the Site Settings page
of each site.
■
SharePoint Portal Server alert notifications can be delivered to the user’s e-mail
inbox, to the user’s My Alerts Summary Web Part on the personal site, or to
both. Windows SharePoint Services alert notifications can be delivered only
through e-mail.
■
SharePoint Portal Server users can set alerts on more items than Windows
SharePoint Services users can.
SharePoint Portal Server can track alerts for the following items:
■
Search queries
■
Documents
■
Areas
■
New listings and listings in general, such as listings for people, news, new list
items, and so forth
■
Sites added to the Site Directory
■
SharePoint lists and libraries
■
List items (requires modification of a site path rule)
■
Portal site users
Windows SharePoint Services can track alerts on the following items within a site:
■
Lists
■
List items
■
Document libraries
■
Documents
Chapter 8: Planning Your Information Structure
171
When shared services are enabled, management of alert settings is possible
only through the Central Administration interface. Through this interface, you can
set quotas for alerts per user and for all portal sites. You can define and adjust the
default numbers based on the following criteria:
■
The number of users
■
How many alerts each user can have
■
How many alert results you want to be returned per alert
You can adjust these defaults based on the number of users and the alerts per
user setting to determine the maximum settings for alerts at the site level. For example, if your company has 20,000 users and you are setting a limit of 10 search alerts
per user and 20 other alerts per user, your maximum number of alerts for all portal
sites is calculated as follows:
20,000 * 10 = 200,000 (maximum number of search alerts for all sites)
20,000 * 20 = 400,000 (maximum number of other alerts for all sites)
If you’re using shared services, these are the maximum numbers allowed for all
divisional portal sites and the corporate portal site combined. They are not per site
or per portal site.
Note Alerts on portal sites and Windows SharePoint Services sites are
not consolidated.
Planning Topics and Areas
There are basically two ways to find information in the portal site: browse and
search. Topics and areas give portal site users the ability to browse for information.
Portal site users will use the Search Web Part to find information, a topic that is covered in Chapter 22.
A Topic is a specialized area that hosts specific Web Parts and Portal Listings
that expose links to site collections and other URL-addressable content. Topics usually contain highlights of other areas or frequently used content, and they might or
might not be limited to a single subject.
Areas are sites templated to host static information and to provide a method of
structuring (or categorizing) your information and information sources. Similar in
some respects to Topics, areas enable you to organize and structure your data in any
172
Part III: Planning and Deployment
manner that makes sense to your organization so that users can browse the area or
Topic hierarchy to find the information they are looking for.
There are seven types of area templates and Portal Listings. We’ll briefly
describe each one here:
1. TOC (Table of Contents) Category template. This is the home page of the
Topics area hierarchy. It is used to view three levels of topics in your organization. It is the tree view of the Topics areas.
2. Topic Category template.
Topic area.
This is the template used to create an individual
3. News Category template.
News areas.
This is the template used to create individual
4. News Home Category template. This template “rolls up” news items from
News areas under the News Home. If there are subareas—such as Public
News, Corporate News, and Competitor News—you would see each of the latest items from those three areas in the News Home area. There is also a targeted Web Part named News for You, which allows you to target news items to
audiences.
5. Community Category template. This template is designed to create an
online community for any purpose you might have, such as an event or a
social or business concern.
6. Shared Page template. Found under the Page tab of any area when you
click on Change Settings. You can select Inherit the Parent Template, which
allows you to create multiple areas using the same template that hosts different
content.
7. Sites Directory template. This template is used to organize site collections
that are created as part of your overall collaborative effort.
When planning out your topics and areas, you need to gain the insight and recommendations from each interested party who will be using the portal site. How
people think about information will heavily influence how they will want to browse
for information.
For example, let’s suppose you’re on a marketing team charged with next
year’s advertising campaign. You develop a marketing budget for the campaign.
Now, who would have a legitimate business interest in seeing that budget? Well, several groups come immediately to mind: Accounting, Executives, Sales, Marketing,
Content Development, and others. The sales team will quite likely want to browse
for this budget differently than the accountants. Because you can’t possibly read the
minds of your portal site users, a best practice is to glean from them what they think
is the most logical way to structure the data they most commonly use and then to use
Chapter 8: Planning Your Information Structure
173
those discussions with the different groups, teams, and departments to build an area
and Topic hierarchy that makes sense.
Because areas are more flexible than Topics in how static information is presented, you might find yourself using Topics to structure your data and then using
areas to present static information that might or might not be time limited. Areas can
be used to structure data too. An area’s flexibility comes from the fact that different
area templates are available when creating a new area. Each template offers different ready-to-use functionality and Web Part designs. The flexibility of SharePoint
Portal Server also means that planning is an up-front activity that you cannot ignore.
Here are some recommendations when considering areas:
■
Use the area templates to present static, time-limited information. For example,
if your company has an annual summer party, use the Community Category
template to disseminate information about the party and use the date functions
in the area’s properties to automatically remove the area from the portal site
after the party has taken place.
■
Use the Topic Category template to create additional Topic areas and create a
taxonomy based on the subject or topics of your information. But remember
that you can use the Topic areas to create a taxonomy based on nearly any
method of structuring data. For example, you can use the topic areas to create
a taxonomy by
■
Subject
■
Customer
■
Project
■
Security level
■
Author
■
Department
■
Location
■
Or any other method of organizing your data that makes sense in your
unique environment
■
Use the Sites Directory template to create a new or additional Site Directory.
■
Do not create too many top-level areas. If you do, your users will be forced to
scroll sideways and this will diminish their positive experience in the portal site.
■
Base your area (and Topic) hierarchies on static information, not information
that changes often or rapidly. For example, don’t create an area for each customer because some of your customers won’t be with you a year from now
and new ones will continually appear. In this example, a best practice would
174
Part III: Planning and Deployment
be to create a generic Customers area and then organize your customers
according to some other criteria within the Customers area.
Topics enable users to locate information faster by organizing content into logical groups. The following are some recommendations for planning Topics:
■
The tree of Topics should not be too deep—usually not more than three levels.
■
Select topics that users are likely to look for.
■
Find appropriate topics, especially for the top-level Topics, and retain those
Topics for a long period of time rather than changing them frequently.
■
If you have too many Topics, select those that are pertinent to the most users,
or organize the Topics into two levels.
■
Provide Topics that are unique to each portal site.
If you have duplicate Topics, qualify them with appropriate prefixes to avoid
confusion. For example, if you want to create a topic named Contacts for each division, create IT–Contacts, HR–Contacts, and so forth. Alternatively, you can create a
topic named Contacts, with subtopics such as IT, HR, and so forth.
Another example is the Location Topic, which is provided by default when you
create a portal site. In this solution, all locations of organizations in the Corporate
Portal site are listed under the Location Topic. Remove the Location Topic from
other portal sites, or replace it with other topics that are unique and more relevant
to a division.
After defining your Topic structure, you can add content (such as documents, list
items, and persons) to each Topic and sub-Topic. Each Topic or sub-Topic can have
its own document library to which documents are uploaded. You can assign specific
groups to manage each of these Topics and sub-Topics by using the Manage Security
option, which is on the list of actions in the Topic area. By the same token, you can
restrict areas to certain users by using the same security option. By simply assigning
permissions at the area level, you can restrict access to areas in the portal and essentially customize the look and feel of the portal through the use of permissions.
Planning Keywords and Keyword Best Bets
Keywords mark specific content as relevant to a particular word included in a search
so that the specific content appears more prominently in search results. Users with
the Create Area right can create keywords for common searches. The Create Area
right is included by default in the Web Designer, Administrator, and Content Manager site groups. For organizational purposes, you can nest related keywords. For
example, the keyword operating system could contain the keywords Windows 2000
and Windows XP.
Chapter 8: Planning Your Information Structure
175
Users with the Manage Area right can add keyword Best Bets for each keyword
to identify items most relevant to that keyword. The Manage Area right is included
by default in the Web Designer, Administrator, and Content Manager site groups.
Keyword Best Bets are specific to individual keywords. Any Best Bets that you associate with nested keywords will not return Best Bets for keywords up or down the
chain of nesting.
Best Bets are not limited to documents—you can also define people as Best
Bets. For example, you can assign a person who is a subject matter expert in an area
as the Best Bet. This facilitates person-to-person communication and knowledge
transfer in organizations.
When a user types a keyword or synonym for a keyword in the search box, its
keyword Best Bets are shown with the highest relevance in search results. These
items are also identified with a distinctive icon as keyword Best Bets.
Keyword Control with SharePoint Portal Server 2003
SharePoint Portal Server 2003 allows keywords to be created at the portal site level
and documents to be assigned as Best Bets to each keyword. For example, with a
keyword such as SharePoint, a user on the IT portal site with the Manage Area right
can assign a document with technical content as the Best Bet for that keyword.
Then, when IT users search on that keyword through their IT division search scope,
they get the best technical content for it. Likewise, a user with the Manage Area right
on the Sales portal site can create the same SharePoint keyword and assign documents as Best Bets that are more suited to the needs of the Sales division. In all
cases, if the user chooses the all sources search scopes to search for the keyword,
the search returns all documents assigned as Best Bets to that keyword.
Refining Keywords
You can reorganize keywords over time based on users’ needs. For example, you can
refine the keyword definitions based on the most frequently searched keywords. You
can filter the IIS log using a third-party utility to get a better understanding of what
users are looking for. For example, you can filter to learn the ten most frequently
searched keywords in each portal site, and assign Best Bets based on this analysis.
Planning User Profiles
When administrators new to SharePoint hear about importing user profiles from
Active Directory into SharePoint, they usually cringe at the thought of having to manage another directory similar to Active Directory. So let’s put your mind at ease:
importing user profiles from Active Directory into SharePoint Portal Server 2003 does
not create another directory for you to manage. All we’re doing is grabbing the rich
176
Part III: Planning and Deployment
directory information out of Active Directory and using that information in different
ways in SharePoint Portal Server to provide the following features and benefits:
■
Searching for and connecting with people within your organization
■
Generating a personal site in the portal site for individual users
■
Providing better search results
■
Targeting content to audiences
Importing User Profiles
You can import user profile information directly from Microsoft Active Directory
directory services or enter it manually. You can also customize the properties of the
user profile to meet the needs of your organization or to map it to Active Directory
properties.
If you have already invested in an infrastructure based on Active Directory or
any LDAP (Lightweight Directory Access Protocol)-compliant directory, you can
import user information stored in the directories. With Active Directory, use the
Import Profile to import the user information to the SharePoint Portal Server. Importing user profiles requires a domain account. To use the incremental import feature
from Active Directory on a Windows Server 2000–based computer, a domain administrator account is required.
Note While you can import directory information from any LDAP-compliant
database, only Active Directory is supported by Microsoft.
You can import user profiles from the same domain that SharePoint Portal
Server is installed on or from any trusted domain. You can also configure and customize your connection to Active Directory to import users based on specific criteria
as a script in an LDAP query. (For example, you can create a script that selects all the
users that belong to a specific organizational unit [OU], or only users whose e-mail
address property is not empty.)
If you’re using other platforms, you can add users manually or write your own
connector by using the object model. You can add more properties to the user profile if you need to extend the information that you want to be displayed about a
user. However, any such updates will not be propagated, nor will they update Active
Directory.
Chapter 8: Planning Your Information Structure
177
Updating User Profiles
After the first import from the directory, you can schedule incremental updates
based on the frequency of users being added to Active Directory. In most cases,
scheduling incremental updates daily and full updates weekly is sufficient.
Tip Removing a user from Active Directory and fully updating the user profile does not remove a user profile from the profile database. Nevertheless,
a user who is removed from Active Directory is not able to access the
SharePoint Portal Server because users are authenticated through Internet
Information Services, which authenticates users through Active Directory.
Planning Audiences
Audiences allow organizations to target content to users based on any property in
Active Directory or by group membership. Hence, you can build an audience based
on who is a member of a Windows Server 2003 security or distribution group. Moreover, you can create an audience based on any property assigned to the user
account in Active Directory. For example, you can create an audience based on the
Department field in the user account so that those who are assigned to the Accounting Department become members of the Accounting Audience.
Audience Rules
Audiences are created based on a set of rules that you define, based on:
■
Windows security group, distribution list, or organizational hierarchy
■
User profile public property
■
Organizational hierarchy
■
Distribution lists
A rule is a simple query based on properties of user profiles or the membership
of users in security groups and distribution groups. If you have already created security groups or distribution groups in Active Directory, you can create audiences
based on those groups. For example, you can define a rule for an audience group
that reports to or under a specific manager (using the format of domain\managerUserName). You can also create an audience that belongs to a specific department if you have assigned a value to the Department field of user profiles.
178
Part III: Planning and Deployment
Compiling Audiences
After you create or make changes to an audience, you must compile it for use. Compiling an audience group is simply a matter of executing queries to find users who
meet the criteria defined in rules.
Audiences can be compiled at will, or they can be compiled by using a schedule that you create. Any changes to security or distribution group membership, security or distribution member properties, or user profile public properties will not be
reflected in the audience until it has been recompiled.
To a point, you can customize the appearance of the portal site by using audiences and permissions. But the real purpose in using audiences is to target information to an individual user based on the audience rules. When planning for
audiences, you’re basically asking the question, “Who needs to see which information?” and then seeing whether audiences (as opposed to permissions or sites) is the
best way to quarantine the information to those users.
Targeting vs. Alerts
Targeting and alerts provide an efficient way of pushing and pulling information.
The distinction between the two can be summed up as follows:
■
Using alerts, users can choose to be notified about certain types of content.
■
Using targeting, administrators or managers can push specific content to users
and employees.
Targeting and Access Control
In some cases, you can control who can access specific content through access
rights and managing security, but you should be aware of differences between managing security and targeting content and try to use each task as intended:
■
Access control lists (ACLs), rights, and permissions. Are used to manage
security and to limit access to resources. Users’ ACLs are verified each time
they navigate and access the content or perform actions on the portal sites.
■
Audience Targeting. The filtering of content delivery. Targeting content is
based on audiences, not on ACLs, and even Active Directory distribution
groups can be used for audiences. For example, all users have access to the
Links For You Web Part on the home page of a corporate portal site, but the
content of the Web Part can vary for different users based on the items that are
targeted to different audiences.
Chapter 8: Planning Your Information Structure
179
Targeting Links to Personal Sites
The SharePoint Portal Server administrator can target links to a user or a group of
users that will be shown on the Links For You Web Part on a user’s personal site.
This feature, called Manage Targeted Links On Personal Site, is available only on the
portal site that provides shared services.
Planning Personal Sites
The My Site feature of SharePoint Portal Server 2003 enables each employee in the
corporate portal site to create and manage a personal site. Personal sites provide a
mechanism for person-to-person collaboration. Each personal site has two interfaces:
■
The public interface, which is accessible to all users. The owner of the site
decides what information to share.
■
The private interface, which contains information available only to the owner
of the site.
When shared services are enabled in the corporate portal site, this portal site
will host personal sites by default and all personal site links in the other portal sites
will redirect users to http://corp/Mysite or the portal site that is selected to host My
Sites in a shared services deployment.
Prerequisites for Personal Sites
User profiles must be part of the planning for personal sites. To create a personal
site, each user needs a user profile and the required permissions. To enable users to
create personal sites, the portal site administrator must add users to the prebuilt
member site group of the portal site. Audience groups must be created for targeting
links and content.
Web Parts in Personal Sites
Some Web Parts are added to personal sites when they are created. Other Web Parts
can be added after the site has been created. Web Parts perform three main functions:
■
Viewing and managing information that a user has selected. One example is
My Alerts Summary, which shows a list of alerts that a user has subscribed to.
Another is My Links Summary, which presents a list of links that a user has
added.
■
Providing content and links that are targeted to the user by the portal site
administrator or others. Examples of this are Links For You and News For You.
180
Part III: Planning and Deployment
■
Providing content from the system. An example of this is Your Recent Documents, which shows a list of links to documents that have been recently
uploaded or modified by the user.
Note Users can add Web Parts only to their private view. For consistency,
all public views of the personal site look the same unless the user adds
subsites and workspaces, which can be customized.
Changes made to the properties of a user profile through the portal site interface will not be reflected in Active Directory.
Disabling Personal Sites
The ability to create personal sites is enabled by default. There is no specific switch
to turn it off. Rather, access to creating personal sites is controlled through portal site
security. Disabling personal site creation is a matter of setting permissions on the
various groups that have access to the portal site.
Planning Windows SharePoint Services Team Sites
The corporate portal site addresses the needs of all employees for accessing corporate-wide information, divisional portal sites provide information for department levels, and Windows SharePoint Services sites offer collaboration sites for workgroups
and teams. There are different options for deploying team sites. We recommend
(although this is not required) creating a separate virtual server for each SharePoint
team site collection and for each divisional portal site. This configuration provides
the maximum amount of flexibility for granular database backups because each
Windows SharePoint Services Virtual Server has its own content database. This configuration also makes it easier to scale out and host Windows SharePoint Services on
its own front-end Web servers. If you aren’t required to have a one-to-one relationship between your content databases and your site collections, you can host up to
50,000 site collections in a single virtual server.
For the purpose of distributing the load, multiple team site collections can use
their own content database and all site collections can use the server farm configuration database. A separate site collection is assigned for hosting team sites with
cross-divisional usage or work groups that do not have a portal site.
This model of site collections deployment provides the highest level of flexibility for scaling out. This model can be migrated to a separate server farm that has its
own SQL Server cluster. It also provides a scale-out option for many team sites and
allows more resources to be allocated for the corporate portal site, shared services,
Chapter 8: Planning Your Information Structure
181
and the divisional portal site in the existing server farm. Partitioning and associating
site collections for divisional portal sites provides the following benefits:
■
More flexibility to scale out
■
Better load distribution on content databases
■
Easier navigation on divisional portal sites and SharePoint sites
■
Integration of SharePoint site search scopes within the divisional portal site
■
More flexibility with delegation of ownership and administrative tasks
■
More flexibility with backup and restore of individual site collections
The drawback of this model is that it requires more memory because it hosts
each site collection in a separate virtual server.
Configuring SQL Server 2000 Search on Windows SharePoint Services
Sites
You must enable the search feature before your site members can use it. If you want
to enable SQL Server 2000 searching, you must install the full-text searching feature
for SQL Server 2000, and then enable searching in Windows SharePoint Services.
Note that this is not the same as using the Search Web Part in the portal site. The
Search Web Part queries the full-text index produced by MSSearch.exe. MSSearch.exe
is a different search engine than SQL Server 2000 Search. Moreover, you should be
aware that indexes produced by these two different engines cannot be combined or
propagated between portal sites and Windows SharePoint Services sites.
Enabling Searching for SQL Server 2000
To use the search feature with Windows SharePoint Services and SQL Server 2000,
you must have full-text searching installed on your SQL Server computer. Full-text
searching is usually installed by default, but if it is not installed on your server, you
can install it using the SQL Server Setup tools. When configuring the search feature
on a Windows SharePoint Services site, a link to searching content on the site’s associated portal site automatically appears on the Windows SharePoint Services search
results page.
Providing the search feature to team sites allows for a granular search scope.
However, keep the following points in mind:
■
Windows SharePoint Services team site search is provided by SQL 2000 fulltext search. Enabling it creates an additional load on the SQL Server.
■
Configuring search on Windows SharePoint Services team sites does not supplant configuring SharePoint Portal Server–based search and indexing. They
are two entirely separate search engines.
182
Part III: Planning and Deployment
The following topics discuss other considerations for planning Windows SharePoint Services sites:
■
Sites storage management
■
Site collection ownership and administration
■
Sites archiving and autodeletion
Sites Storage Management
Each division will use SharePoint sites in a different way. Some divisions will create
and use more SharePoint sites than others. To support different usage patterns, create a separate quota template for each division (instead of a default quota template),
with an estimate of disk storage allocated at the site collections. You should also create a separate quota template for each site collection and adjust the quota based on
usage of team sites in each organization.
Quotas give the administrator a high level of control over disk storage and content database size for team sites. When these quotas are reached, an e-mail message
will notify the administrator to adjust the size or quota. You can write an SQL query
script to increase quotas by using a simple update statement.
Site Collection Ownership and Administration
For each site collection, assign two owners to manage sites and to be responsible for
users’ requests. Assigning two owners ensures that you do not lose the function
when one owner is unavailable.
If a user tries to access a site to which he or she does not have access, the user
is prompted for authentication three times. After this, a site access request form is
shown, which the user can send to the site owner. Site collection owners also
receive any quota or autodeletion notices, and they have site collection administrator privileges.
Note Making a user a site owner also adds the user to the list of site collection administrators. Removing users from the list of site owners also
removes them from the list of site collection administrators, but it doesn’t
change any other group membership or rights granted to them.
Windows SharePoint Services Sites Archiving and Autodeletion
Sites are usually created for the collaboration of project workgroups or project meetings. In most cases, team sites won’t be used after projects are completed. You
should plan a policy for archiving and removing such team sites to reclaim the stor-
Chapter 8: Planning Your Information Structure
183
age consumed by them. The Windows SharePoint Services administration interface
provides such a capability. Set it to notify owners of site collections if sites are not
used for a period of time. (The default setting is 90 days.) Based on the policy for
retaining data in your organization, you can set up the autodeletion feature to delete
unused sites. As a best practice, you should archive these SharePoint sites before
they are removed because the deletion is permanent and the content will not be
retrievable. You can use smigrate.exe to archive the sites and then allow the autodeletion feature to delete the sites.
Planning and Managing Properties
SharePoint Portal Server 2003 displays the properties (or metadata) of items crawled
by the content index server. The properties are on the Manage Properties Of
Crawled Content page. Based on your business needs, you can manage which properties you want to be shown in the advanced search and trigger alerts when specific
properties change. However, having too many properties takes longer and uses
more resources when content is crawled.
You can customize the properties of a document based on your needs. For
example, you can add a property such as confidential to your documents, to distinguish the confidential documents or allow users to search and quickly locate
these types of documents. To add the property, add a column to your Document
Library view.
When the documents are crawled, the new property is discovered and added
to the list of properties that can be viewed through the Manage Properties tool. In
this case, confidential is shown under:
“urn:schemas-microsoft-com:office:office” namespace.
You can configure the confidential property to be included in Advanced
Search. You can also use this property to trigger an alert if the object has changed.
Summary
In this chapter, we have discussed some of the planning questions and best practices
that should be considered before your SharePoint Products and Technologies implementation. We have discussed how to plan for search and indexing, keywords, Best
Bets, user profiles, audiences, personal sites, and Windows SharePoint Services sites.
You absolutely should not skimp on the planning portion of your overall deployment. Furthermore, the quality of your planning will directly affect the quality of your
deployment and the ability of the user to have a positive portal site experience.
Chapter 9
Capacity Planning
In this chapter:
Topology Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185
SharePoint Products and Technologies Licensing Guidelines . . . . . . . . . . 188
Logical Deployment Considerations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198
Planning Services and User Accounts . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198
Planning Roles, Groups, and Rights. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202
Planning Search . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204
Planning for Growth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210
Choosing the Farm Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216
Performance Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220
Testing for Capacity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235
Capacity planning is one of the most important aspects of enterprise software deployment. Microsoft Office SharePoint Portal Server 2003 is no exception. Without careful
planning and architecture design, it is likely your deployment will fail. This chapter
will guide you through the steps involved in capacity planning and provide you with
information on how to size your expected capacity and plan your topology. It will also
cover testing your built topology to ensure it can handle the required traffic.
Topology Planning
This section will cover various topologies supported by SharePoint Portal Server. It
will provide hardware requirements, software requirements, and infrastructure
requirements for successfully deploying a SharePoint Portal Server solution. Many
of the configurations in this chapter were tested using entry-level Dell servers. The
medium and large farms were also tested using Hewlett-Packard (HP) ProLiant
servers and disk arrays. The performance test results published in this chapter correspond to one of these reference configurations described below.
185
186
Part III: Planning and Deployment
Common Infrastructure Requirements
SharePoint Portal Server requires several common infrastructure components. Not all
of these are required for every topology, but they are covered here because they are
common among multiple topologies.
Network Interfaces
In all topologies except single-server ones, ideally each front-end Web server should
be equipped with at least two network interface cards (NIC). One will connect the
servers to the external network, and one is for communications between the other
server farm computers.
The Ethernet switches should be, at minimum, 100-megabit, full-duplex
switches. If you anticipate growth beyond a five-server, high-availability medium
server farm configuration, you should use gigabit (1000base-T) switches and NICs.
DNS
Each front-end Web server should have access to the corporate domain name
server (DNS). During the construction and configuration of the servers, you should
have the ability to create unique names for the corporate portal site, as well as for
each divisional portal site and site collection. Make sure to reserve meaningful
names for these portal sites.
Active Directory
A Microsoft Windows 2000 Server or Windows Server 2003 Active Directory domain
or Microsoft Windows NT 4 domain is required for a SharePoint Portal Server 2003
deployment. For more information about Active Directory, please refer to the Windows 2003 Resource Kit.
Microsoft SQL Server, SharePoint Portal Server 2003, and Microsoft Windows
SharePoint Services require both local and domain accounts for proper operations.
For a listing of the required accounts, please see Chapter 12, “Deploying a Medium
and Large Server Farm.”
Software Licensing
There are three typical SharePoint Portal Server deployments: small, medium, and
large farms.
Windows SharePoint Services requires Windows Server 2003 licenses. Windows Server is licensed on a Client Access License (CAL) and Server basis. All
employees or employee devices that access a Windows Server 2003 server must
have a CAL, and all servers that provide any Windows Server 2003 functionality must
have a Server license.
Chapter 9:
Capacity Planning
187
The Windows Server External Connector license enables an unlimited number of
nonemployees to access Windows SharePoint Services without any technical limitations or restrictions. (A nonemployee is a person who is not an employee, or similar
personnel of the company or its affiliates, and is not someone to whom you provide
hosted services using the server software.) This license must be obtained for every
server that provides services to nonemployees. Partners and customers can be licensed
by the External Connector whether or not they are members of the Active Directory.
SharePoint Portal Server 2003 is also licensed on a Client Access (CAL)/Server
basis. All employees or employee devices that access a server running SharePoint
Portal Server 2003 must have a SharePoint Portal Server 2003 CAL, and all servers
that provide any SharePoint Portal Server 2003 functionality must have a SharePoint
Portal Server 2003 server license.
The External Connector license enables an unlimited number of nonemployees
to access SharePoint Portal Server 2003 without any technical limitations or restrictions. An External Connector license must be obtained for every server that provides
services to nonemployees. Partners and customers can be licensed by the External
Connector whether or not they are members of the Active Directory.
Because SharePoint Portal Server is built on Windows SharePoint Services, all
SharePoint Portal Server users must also have the appropriate Windows Server 2003
licenses. (See the second paragraph in this section.)
SharePoint Portal Server ships with a version of Microsoft SQL Server 2000 Desktop Engine (MSDE). Customers who want to optimize performance and scalability can
choose to deploy Microsoft SQL Server 2003 with Service Pack 3 (SP3) or later.
SQL Server is licensed on both a CAL/Server and per-processor basis. CALs are
not required for per-processor licenses.
Customers can purchase CALs for all server products on either a per-device or
per-user basis. Customers with shared kiosks can choose to license per device. Customers with multiple devices per employee can choose to license per user. Customers can license a combination of per-user and per-device CALs.
The Core CAL provides an efficient, cost-effective way for customers to license
their SharePoint and Information Worker server solutions across all desktops with
SharePoint Portal Server, Windows Server, Microsoft Exchange Server, and SMS
CALs. The Core CAL includes Software Assurance (SA) so that your organization is
always licensed for the most current technologies. Core CAL customers can also
receive incentive pricing on Microsoft Office Live Communications Server.
188
Part III: Planning and Deployment
SharePoint Products and Technologies Licensing
Guidelines
The following licenses are required for an internal Windows SharePoint Services
deployment:
■
Windows Server 2003 CALs for all employees or employee devices that access
the server.
■
Windows Server 2003 Server licenses for each server providing SharePoint Services functionality.
■
Optional: SQL Server 2000 CAL and Server licenses or SQL 2000 processor
licenses. (See the “SQL Server Licensing Guidelines” section that follows.)
The following licenses are required for an external Windows SharePoint Services deployment (extranet, Internet, or both):
■
Windows Server 2003 CALs for all employees or employee devices that access
the server.
■
Windows Server 2003 Server licenses for each server providing Windows
SharePoint Services functionality.
■
Windows Server 2003 External Connector License for each server that provides
Windows SharePoint Services functionality to partners, customers, or both.
■
Optional: SQL Server 2000 processor licenses. SQL Server must be licensed per
processor for external use. (See the “SQL Server Licensing Guidelines” section
that follows.)
The following licenses are required for an internal SharePoint Portal Server
2003 deployment (intranet only):
■
Windows Server 2003 CALs for all employees or employee devices.
■
Windows Server 2003 Server licenses for each server providing either SharePoint Portal Server or Windows SharePoint Services functionality.
■
SharePoint Portal Server 2003 CALs for all employees or employee devices.
■
SharePoint Portal Server 2003 Server licenses for each server providing SharePoint Portal Server functionality.
■
Optional: SQL Server 2000 CAL and Server licenses or SQL 2000 processor
licenses. (See the “SQL Server Licensing Guidelines” section that follows.)
The following licenses are required for an external SharePoint Portal Server
2003 deployment (extranet, Internet, or both):
Chapter 9:
Capacity Planning
189
■
Windows Server 2003 CALs for all employees or employee devices.
■
Windows Server 2003 Server licenses for each server providing either SharePoint Portal Server or Windows SharePoint Services functionality.
■
Windows Server 2003 External Connector License for each server that provides
either Windows SharePoint Services or SharePoint Portal Server functionality to
partners, customers, or both.
■
SharePoint Portal Server 2003 CALs for all employees or employee devices.
■
SharePoint Portal Server 2003 Server Licenses for each server providing SharePoint Portal Server functionality.
■
SharePoint Portal Server External Connector License for each server that provides Windows SharePoint Services functionality to partners, customers, or
both.
■
Optional: SQL Server 2000 processor licenses. SQL Server must be licensed per
processor for external use. (See the “SQL Server Licensing Guidelines” section
that follows.)
SQL Server Licensing Guidelines
The correct SQL Server licensing option depends on the type of SharePoint Products
and Technologies deployment and current SQL Server license availability, as outlined in the following list:
■
SQL Server 2000 is not required. Windows SharePoint Services ships with
Microsoft SQL Server 2000 Desktop Engine (Windows) (WMSDE), which does
not have the 2-gigabyte (GB) storage limit of MSDE. SharePoint Portal Server
ships with MSDE. Customers can choose to deploy SQL Server 2000 for optimal
performance and scalability.
■
If your customer already owns SQL Server 2000 CALs and plans an internal
SharePoint Products and Technologies deployment only, it might be more costeffective to purchase only the required number of additional SQL Server 2000
Server licenses than to purchase per-processor licenses.
■
If your customer does not already own SQL Server CALs and plans an internal
SharePoint Products and Technologies deployment, they should then calculate
and compare the cost of CAL/Server vs. per-processor licensing for their specific deployment.
■
If your customer plans an external SharePoint Products and Technologies
deployment, they must license SQL Server on a per-processor basis, regardless
of whether or not their employees or employee devices are licensed with SQL
Server CALs. Because SQL Server has dual licensing, it does not have an External Connector license for nonemployees.
190
Part III: Planning and Deployment
Deploying a Single Server with MSDE
A single-server deployment with MSDE is the smallest and least scalable option for
a SharePoint Portal Server solution because it is limited to five concurrent jobs and
has a 2-GB storage limitation. This deployment type is recommended for testing and
development as well as for small organizations that anticipate light usage of their
corporate intranet. This is the least costly deployment option.
Hardware Recommendations
The reference configuration for a single server with MSDE deployment used
throughout the chapter is:
■
1 x 2.4-gigahertz (GHz) Pentium-4 processor
■
1-GB main memory expandable to 4 GB
■
Embedded ATA-100 IDE controller
■
2 x 40-GB IDE ATA-100 disks
■
Embedded 10/100/1000-GB Ethernet interface card (NIC)
Deploying a Single Server Using SQL
A single-server deployment with SQL Server is a step above a single server with
MSDE. Running SQL Server 2000 rather than MSDE provides additional scalability
because MSDE can support only five concurrent jobs and a 2-GB database limit,
while SQL Server does not have this restriction. This deployment type is recommended for small organizations with moderate usage of their corporate intranet or
organizations and medium-sized organizations (less than 10,000 employees) with
light usage of the corporate intranet.
Hardware Recommendations
The reference configuration for a single server with SQL deployment used throughout this chapter is:
■
1 x 2.4-GHz Pentium-4 processor
■
1-GB main memory expandable to 4 GB
■
Embedded ATA-100 IDE controller
■
2 x 40-GB IDE ATA-100 disks
■
Embedded 10/100/1000-GB Ethernet interface card (NIC)
Chapter 9:
Capacity Planning
191
Small Server Farm
A small server farm is a step above a single server with SQL Server. In this scenario,
there are two servers in the farm—one runs the SharePoint Portal Server components, and the other runs SQL Server 2000. Having SQL Server on a separate system
frees up some resources from the server running SharePoint Portal Server, allowing
it to support more users. Also, it is often used in organizations where there is an
existing SQL Server database or where administrative boundaries require certain
administrators to manage SQL Server systems and other administrators to manage
the intranet. Figure 9-1 depicts a small server farm topology infrastructure.
SharePoint
Server
Figure 9-1
F09XR01
SQL Server
Small server farm topology infrastructure
Hardware Recommendations
The reference configuration for a small server farm deployment used throughout the
chapter are given in the following paragraphs.
For a server running SharePoint Portal Server, the following configuration was
used:
■
1 x 2.4-GHz Pentium-4 processor
■
1-GB main memory expandable to 4 GB
■
Embedded ATA-100 IDE controller
■
2 x 40-GB IDE ATA-100 disks
■
Embedded 10/100/1000-GB Ethernet interface card (NIC)
For SQL Server, the following configuration was used:
■
1 x 2.4-GHz Pentium-4 processor
■
1-GB main memory expandable to 4 GB
■
Embedded ATA-100 IDE controller
■
2 x 40-GB IDE ATA-100 disks
■
Embedded 10/100/1000-GB Ethernet interface card (NIC)
192
Part III: Planning and Deployment
Load-Balanced Medium Server Farm
A load-balanced medium server farm is the first topology where SharePoint Portal
Server really starts to scale out. In this scenario, there are four servers: two loadbalanced front-end servers running the Web and search components, a dedicated
indexing server, and a server running SQL Server. This topology performs well and
can support many more users than a small server farm, but there is still no highavailability. This scenario would be used by small organizations with very heavy
usage of their portal site or organizations with up to 50,000 users who have light to
moderate usage of their intranet. Figure 9-2 depicts a load-balanced medium server
farm topology infrastructure.
Front-End/
Search Server
Front-End/
Search Server
Ethernet Network
Index Server
Figure 9-2
F09XR02
SQL Server
Load-balanced medium server farm topology infrastructure
Hardware Recommendations
The reference configuration for a load-balanced medium server farm deployment
used throughout the chapter are given in the following paragraphs.
For a combination of a front-end Web server with a search server (2 Servers),
the following configuration was used:
■
1 x 2.4-GHz Pentium-4 processor
■
1-GB main memory expandable to 4 GB
■
Embedded ATA-100 IDE controller
■
2 x 40-GB IDE ATA-100 disks
■
Embedded 10/100/1000-GB Ethernet interface card (NIC)
For SQL Server, the following configuration was used:
■
1 x 2.4-GHz Pentium-4 processor
■
1-GB main memory expandable to 4 GB
Chapter 9:
Capacity Planning
■
Embedded ATA-100 IDE controller
■
2 x 40-GB IDE ATA-100 disks
■
Embedded 10/100/1000-GB Ethernet interface card (NIC)
193
For a server used as an index management and job server (1 server), the following configuration was used:
■
1 x 2.4-GHz Pentium-4 processor
■
1-GB main memory expandable to 4 GB
■
Embedded ATA-100 IDE controller
■
2 x 40-GB IDE ATA-100 disks
■
Embedded 10/100/1000-GB Ethernet interface card (NIC)
Highly Available Medium Server Farm with SQL Cluster
A highly available medium server farm is just like a load-balanced medium server
farm, except that with a highly available medium server farm there is a SQL Cluster.
The SQL Cluster adds the high availability because any server in this topology can
fail and users will still be able to use their portal sites. In this scenario, there are five
servers: two load-balanced front-end servers running the Web and search components, a dedicated indexing server, and two servers running SQL Server in an active/
passive cluster. The index server is susceptible to failure, but even if it goes down,
the farm will still be able to serve pages. Users just will not be able to get notifications and content indexes will not get updated until the server comes back online.
Figure 9-3 depicts a load-balanced medium server farm topology infrastructure.
Front-End/
Search Server
Front-End/
Search Server
Ethernet Network
Index Server
Figure 9-3
F09XR02
SQL Cluster
Highly available medium server farm topology infrastructure
194
Part III: Planning and Deployment
Hardware Recommendations
The reference configurations for front-end Web and search servers in the server farm
are given in the following paragraphs.
For a combination of a front-end Web server with a search server (2 servers),
you following configuration was used:
■
2 x 2.8-GHz Xeon processors with 512-kilobyte (KB) Cache
■
ServerWorks GC-LE chipset, supporting a 400-megahertz (MHz) FSB
■
2-GB main memory expandable to 6 GB
■
Embedded Wide Ultra3 Smart Array 5i RAID controller
■
4 x 18.2-GB Ultra3 SCSI disks
■
2x embedded BCM5703 10/100/1000-GB Ethernet network interface card
(NIC) ports
■
Redundant power supply and fan
For a server used as an index management and job server (1 server), the following configuration was used:
■
2 x 2.8-GHz Xeon processors with 512-KB CacheServerWorks GC-LE chipset,
supporting a 400-MHz FSB
■
2-GB main memory expandable to 6 GB
■
Embedded Wide Ultra3 Smart Array 5i RAID controller
■
6 x 36.4-GB Ultra320 SCSI disks
■
2x embedded BCM5703 10/100/1000-GB Ethernet NIC ports
■
Redundant power supply and fan
For a SQL Server–based database server (active/passive; 2 servers), the following configuration was used:
■
4 x 2.8-GHz Xeon processors with 512-KB CacheServerWorks GC-LE chipset,
supporting a 400-MHz FSB
■
2-GB main memory expandable to 6 GB
■
Embedded Wide Ultra3 Smart Array 5i RAID controller
■
Smart Array 5300 controller
■
4 x 18.2-GB Ultra3 SCSI disks
■
14 x 72.8-GB Ultra320 SCSI disks with a SCSI-connected clustered storage subsystem (which supports up to 14 disks with HP Smart Array cluster storage)
■
2x NC3163 Fast Ethernet ports
■
Redundant power supply and fan
Chapter 9:
Capacity Planning
195
Minimum Large Server Farm with a SQL Cluster
The minimum large server farm with a SQL cluster is the step above a highly available medium server farm. A minimum large server farm does not actually need a
SQL cluster to be supported, but in practice, almost every large server farm will have
a SQL cluster for high availability. This scenario has seven servers: two load-balanced front-end Web servers, two dedicated search servers, one dedicated indexing
server, and two systems running SQL servers acting as an active/passive cluster. A
minimum large server farm is mainly used by large organizations or medium-sized
organizations with heavy portal site usage. The minimum large server farm configuration is really useful over the high availability medium server farm when there is a
lot of searching in the portal site. Figure 9-4 depicts a minimum large server farm
with a SQL cluster topology infrastructure.
Front-End
Server
Front-End
Server
Ethernet Network
Index
Server
Figure 9-4
F09XR04
Search
Server
Search
Server
SQL Cluster
Minimum large server farm with SQL cluster topology infrastructure
Hardware Recommendations
The reference configurations for front-end and search servers in the minimum large
server farm with SQL Cluster are:
For dedicated front-end Web servers (2 servers), the following configuration
was used:
■
2 x 2.8-GHz Xeon processors with 512-KB CacheServerWorks GC-LE chipset,
supporting a 400-MHz FSB
■
2-GB main memory expandable to 6 GB
■
Embedded Wide Ultra3 Smart Array 5i RAID controller
196
Part III: Planning and Deployment
■
4 x 18.2-GB Ultra3 SCSI disks
■
2x embedded BCM5703 10/100/1000-GB Ethernet NIC ports
■
Redundant power supply and fan
For a server used as an index management and job server (1 server), the following configuration was used:
■
2 x 2.8-GHz Xeon processors with 512-KB CacheServerWorks GC-LE chipset,
supporting a 400-MHz FSB
■
2-GB main memory expandable to 6 GB
■
Embedded Wide Ultra3 Smart Array 5i controller
■
6 x 36.4-GB Ultra320 SCSI disks
■
2x embedded BCM5703 10/100/1000-GB Ethernet NIC ports
■
Redundant power supply and fan
For dedicated search servers (2 servers), the following configuration was used:
■
2 x 2.8-GHz Xeon processors with 512-KB CacheServerWorks GC-LE chipset,
supporting a 400-MHz FSB
■
2-GB main memory expandable to 6 GB
■
Embedded Wide Ultra3 Smart Array 5i controller
■
6 x 36.4-GB Ultra320 SCSI disks
■
2x embedded BCM5703 10/100/1000-GB Ethernet NIC ports
■
Redundant power supply and fan
For SQL Server–based database servers (active/passive; 2 servers), following
configuration was used:
■
4 x 2.0-GHz XEON
■
2-GB main memory expandable to 32-GB Advanced ECC
■
Embedded Wide Ultra3 Smart Array 5i Plus controller
■
KGPSA-xx, PCI Fibre Channel HBA
■
4 x 18.2-GB Ultra3 SCSI disks
■
HP StorageWorks modular SAN array (msa1000) with 2-GB Fibre Channel
storage
Chapter 9:
Capacity Planning
■
28 x 72.8-GB Ultra3 SCSI disks (which supports up to 42 disks)
■
1x embedded NC7770 10/100/1000-GB Ethernet NIC ports
■
Redundant power supply and fan
197
Windows SharePoint Services Server Farm (Optional)
For front-end Web servers (2 servers), the following configuration was used:
■
2 x 2.8-GHz Xeon processors with 512-KB CacheServerWorks GC-LE chipset,
supporting a 400-MHz FSB
■
2-GB main memory expandable to 6 GB
■
Embedded Wide Ultra3 Smart Array 5i RAID controller
■
4 x 18.2-GB Ultra3 SCSI disks
■
2x embedded BCM5703 10/100/1000-GB Ethernet NIC ports
■
Redundant power supply and fan
Maximum Large Server Farm with a SQL Cluster
Large server farms scale out well. The maximum large server farm with SQL cluster
is the largest single farm deployment you can have. You can scale a large farm to
any configuration between the minimum large server farm and the maximum larger
server farm, but because of space constraints, only the minimum and maximum configurations are presented in this. For more information on large farm scaling, please
see Chapter 11.
The maximum supported large server farm with a SQL cluster consists of eighteen servers: eight load-balanced front-end Web servers, four search servers, four
indexing management servers, and two systems running SQL servers acting as an
active/passive cluster. Additionally, a nineteenth server running the optional document management components can be used. The maximum large server farm with
SQL cluster is a highly available SharePoint Portal Server solution supporting large
organizations with moderate to heavy usage. It provides protection from multiple
points of failure. If you need to scale out beyond the maximum large server farm
environment, you will need to use multiple farms and use inter-farm shared services
to connect the farms. Inter-farm shared services is described in Chapter 14, “Shared
Services.”
This type of farm environment was not tested for this chapter, so no specific
hardware recommendations are provided. If you are building a maximum large
server environment, you should contact your hardware vendor, Microsoft representative, or both to discuss hardware recommendations.
198
Part III: Planning and Deployment
Logical Deployment Considerations
The following are considerations for deploying SharePoint Portal Server 2003 in an
organization:
■
A corporate portal site for all employees. This is a required component of
all SharePoint Portal Server 2003 installations. This portal site will usually use
Windows Shared Services if multiple portal sites are present but not required.
See Chapter 14 for more information on Shared Services.
■
Divisional portal sites for each division or project. Additional portal
sites can be created for divisions or important projects within the organization.
Additional portal sites are not required, but medium and large deployments
will usually have many portal sites.
■
Team site collection. The team site collection will encompass teams and
topics that are too small to warrant their own portal site. Team site collections
can be hosted in the corporate portal site or its respective divisional portal site.
A cross-corporate site collection can also be created to facilitate team sites that
do not easily fall into a specific divisional portal site. The cross-corporate site
collection is almost always stored in the corporate portal site.
■
A My Site for each employee. My Sites are personal sites for each user. My
Sites are optional in a portal site deployment. Each My Site is a SharePoint site
with a special template applied. The user who owns the My Site will have full
control of the site and can customize it as she wants. Architecturally, each My
Site is considered a single Site collection.
■
Security. Security considerations must be discussed and determined. By
default, authenticated users will have reader access to everything in the portal
site. All domain users will be authenticated users, therefore all users will have
reader access to everything until the permissions are changed. Security should
be planned before deploying SharePoint Portal Server 2003. Please refer to
Chapter 24, “Information Security Policies for SharePoint Products and Technologies,” for additional information on security practices.
Planning Services and User Accounts
There are two groups of accounts to plan for:
■
Services accounts, which are used to run services such as SQL Server and
SharePoint Portal Server
■
User accounts, such as search, indexing, application pools, and administrative
accounts
Chapter 9:
Capacity Planning
199
Planning Services Accounts
Services accounts are access accounts for SQL Server and SharePoint Portal Server
services. The credentials for these services should not be used as user credentials.
The following topics provide detailed information about the purpose of these
accounts and the credentials that are assigned to them.
SQL Server Services Accounts
If you are using the default instance of a SQL Server 2000 installation, there are two
services that need an account:
■
MSSQLSERVER
■
SQLSERVERAGENT
These should be created as domain accounts called domain\spssql with the
SQL System Administrator database role. This account can be any domain user
account, but it is not required to have special domain permissions.
If you are not using the default instance, these services will be shown as:
■
MSSQL$InstanceName
■
SQLAgent$InstanceName
Be sure to make that account a member of the local administrator group of
each server on which SQL Server is installed.
SharePoint Portal Server Services Accounts
The SharePoint Portal Server services are as follows:
■
Microsoft SharePointPS Search (SharePointPSSearch).
ing and searching over the portal site and external content
■
Microsoft SharePoint Portal Administration (SPSAdmin).
server to administer SharePoint Portal Server services
■
Microsoft SharePoint Portal Alert (SPSAlert). Schedules and sends alerts
and alert results to users on one or more servers running SharePoint Portal
Server
■
Microsoft SharePoint Timer (SPTimer). Sends notifications and performs
scheduled tasks for Windows SharePoint Services
■
Microsoft Single Sign-On (SSOSrv). Provides single sign-on services for
line-of-business applications. This service is not used in this solution
Provides indexEnables the
Use a single domain account—named domain\spssql—for these SharePoint
Portal Server services. It is easier from an administrative standpoint to use the same
200
Part III: Planning and Deployment
account for these SharePoint Portal Server services and the SQL Server services.
However, you can choose to use a different account for SharePoint Portal Server
services and SQL Server services if you have different groups administering SQL
Server and SharePoint Portal Server farms. Be sure to make that account a member
of the local administrator group of each computer running SharePoint Portal
Server. You must also add this domain account to the SharePoint Portal Server
administrators group.
Planning User Accounts
You need two user accounts:
■
Configuration database administration account
■
Default content access account
The following topics describe these accounts.
Configuration Database Administration Account
The configuration database administration account is the user name and password
that SharePoint Portal Server uses when connecting to the configuration database or
when propagating full-text indexes from index management servers to search servers. This account must have administrator rights on both the index management
server and the search server.
Default Content Access Account
This account is used as the default account for crawling content sources defined for
a content index. For internal content, such as portal sites and site directories, you
can use specific access accounts through exclude and include rules. This account
should be a member of the SharePoint Portal Server administrators group so that it
can access and crawl all content sources and their properties. In this case, the
account uses Windows Integrated Authentication for accessing content by default. If
this method of authentication fails, it uses Basic Authentication unless you have
explicitly disabled Basic Authentication access.
Planning the Corporate Portal Site
The corporate portal site is the entry point from which all employees can get the latest corporate-wide information. Usually the corporate portal site is a parent portal
site providing shared services, but this is not always the case. Sometimes a SharePoint Portal Server deployment includes only one portal site, which is the corporate
portal site. In other cases, there are multiple portal sites, but they don’t share services with the corporate portal site. However, the majority of SharePoint Portal
Server deployments will have a corporate portal site providing shared servers to the
Chapter 9:
Capacity Planning
201
divisional portal sites. A corporate portal site is required for a SharePoint Portal
Server deployment.
When planning the corporate portal site, the following aspects need to be
considered:
■
Shared services, including search, user profiles, audiences, and alerts
■
Personal sites
■
Site groups/roles, permissions/rights
■
Areas (topics)
■
News, events, and announcements
■
Keywords and Best Bets
■
SharePoint sites
Each of these is covered briefly later in this chapter and will be covered in full
detail in later chapters.
Planning Additional Portals
Additional portal site content is focused on the employees involved with a specific
topic, usually a division or project. For example, employees in a human resources
(HR) department will access their divisional portal site to find out about news,
events, announcements, and documents related to HR. In organizations with many
large ongoing projects, additional portal sites can be provisioned for these projects
rather than for divisions. For example, a company that manufacturers airplanes can
have a portal site for each different type of plane it manufacturers in addition to or
instead of divisional portal sites. Typically, employees will access their divisional or
project portal site more often than the corporate portal site. This arrangement saves
time and keeps each employee more focused on the type of information they need
instead of requiring them to search it out on the corporate portal site. In that scenario, each divisional or project portal site should share the search services of the
corporate portal site, allowing users to search the enterprise from their divisional
portal site.
Determining whether to use Shared Services is also important when planning
divisional portal sites. Not using shared services can have a significant impact on
farm resources, especially memory.
When planning a divisional or project portal site, consider the following areas:
■
Team sites
■
Associated divisional team sites to divisional portal sites
■
Site groups/roles, permissions/rights
202
Part III: Planning and Deployment
■
Search scopes
■
Areas (topics)
■
News, events, and announcements
■
Document libraries
■
Keywords and Best Bets
Each of these is covered briefly later in this chapter and will be covered in full
detail in later chapters.
Knowing when to create a new portal site versus creating a new site collection
can be difficult. Here are some guidelines to help you make your decision:
■
Create new site collections when collaboration is your primary need and you
can use existing portal sites to meet your taxonomy needs.
■
Create new areas in existing portal sites if you need to present static information and you don’t need to create a new taxonomy.
■
Create new portal sites if you need to implement a new taxonomy or present
such a volume of static information that one or a few areas in existing portal
sites will not be sufficient.
■
Create a new portal site with new associated site collections if you need to
implement the previous three bullet points in concert with each other.
Planning Roles, Groups, and Rights
Creating security groups in Active Directory instead of adding individual users
allows you to manage user rights just by adding or removing users from groups,
rather than assigning the same rights to many users individually. Based on your
business need, you can use default site groups, which provide rights based on the
type of actions each group can do. The default site groups include the following:
■
Reader.
■
Contributor.
■
Web Designer.
in the website
Can create lists and document libraries and customize pages
■
Administrator.
Has full control of the website
■
Content Manager.
■
Member.
Has read-only access to the website
Can add content to existing document libraries and lists
Can create and manage areas, lists, libraries, and sites
Can view and personalize portal site content and create sites
Chapter 9:
Capacity Planning
203
More Info You can also define your own custom roles and site groups with
different rights. For more information, it is strongly recommended that you
read Chapter 24 to thoroughly understand security before deploying SharePoint Portal Server.
You should plan for the following roles and groups:
■
Central administrator group (domain\CentralAdminGroup). Responsible
for administration of the entire server farm, server farm topology, and virtual websites. This group must be a member of the SharePoint Portal Server administrators
group and of the SQL Server system administrators group.
Note You can register only one domain group as the SharePoint Portal
Server administrators group. Therefore, if you want to include other members, you must add them using the user and group management tools for
your domain.
■
Corporate administrator group (domain\CorpAdminGroup). Responsible
for managing site groups, managing list permissions, creating sites, creating portal
sites, and viewing usage analysis data. The corporate administrator group cannot
be customized or deleted, and there must always be at least one member of this
group. Members of this group always have access to, or can grant themselves
access to, any item in the website. This group needs to be a member of Domain
Admins to import user profiles from Active Directory.
■
Managing and updating news group. Based on your company business
rules and security policies, you might need to create a group that only manages
and updates the company news. In this case, be sure to remove inheritance
permissions by selecting unique permissions. This will remove site-level permissions and provide news update rights only to the assigned group. For this
accelerator, you need to create groups for the corporate portal site news area
and also for each divisional news area.
■
Managing and updating topics content group. Based on your company
business rules and security policies, you might need to create a group for each
topic area and assign separate groups for managing each topic or subtopic area
in the corporate and divisional portal sites. In this case, you need to create
groups that can update and upload documents to each topic area.
204
Part III: Planning and Deployment
Planning Search
This section describes the components of the SharePoint Portal Server search functionality. It provides guidelines on planning a customized version of each search
component for your solution.
Overview of Search Functionality
There are four components that contribute to the SharePoint Portal Server search
functionality:
■
Content sources
■
Content indexes
■
Source groups
■
Search scopes
For an in-depth discussion of each of these components, please refer to Chapter 21, “The Architecture of the Gatherer,” and Chapter 22, “Managing External Content in Microsoft Office SharePoint Portal Server 2003.” This chapter will discuss the
planning requirements for content indexes only.
Planning Content Indexes
SharePoint Portal Server 2003 comes with two content indexes—Portal_Content and
Non_Portal_Content. You can create additional content indexes as well; however,
keep in mind that each search query has to be run on each index and the results
must be aggregated before they are returned to the user. The result is that the more
indexes you have, the longer search results take to generate.
Note Advanced search administration mode should be enabled so that
you can create and manage additional indexes. In addition, when you create
content sources, you can specify the index in which the content source will
appear, and you can specify the source group.
When planning content indexes, consider the following factors:
■
Number of documents. If the number of documents is very large, you
should consider breaking the content sources into many content sources with
smaller scopes to make the size of the indexes more manageable. This is
important because the index catalogs are copied across the network. Copying
Chapter 9:
Capacity Planning
205
smaller files at different times can ease the network load, but it is recommended that you have a maximum of four content indexes. Searching will perform about the same with many smaller files as with one very large file.
■
Security. Default content access is used as credentials for crawling all content sources. For content sources outside of your organization, consider using
an account that has read-only access, such as the anonymous account. (See
SharePoint Portal Server 2003 product documentation for information on using
site and path rules.) The account should have appropriate access for other
internal resources—such as site directories, portal site contents, and shared
folders—that are part of the personal site. For shared folders, you should use
an access account that is a member of the SharePoint Portal Server administrators group. This level of access allows for crawling all types of content and
their properties in portals and site directories. To provide different accounts for
crawling content, you must use include and exclude rules. You should add
rules and include paths that you want to be crawled with different access
accounts. These rules are applied to all content sources bound to a content
index that creates additional crawling. To avoid duplicate or additional crawling, you should assign rules only to specific content sources. For details on
how to build content indexes and content sources, see Chapter 21.
■
Scheduling. Creating separate content indexes allows more flexible scheduling based on the nature of contents in each content source. Some content
sources change quickly and need more updates, while other content sources
are less volatile and require fewer updates.
■
Propagation. Having smaller content indexes provides faster propagation of
content indexes to search servers. However, there is a drawback: When a user
initiates a search, the search engine has to run that query against each index
and then aggregate the results. The more indexes that you have, the longer it
takes.
■
Backup and restore. Smaller content indexes also provide more flexibility
when backing up and restoring. For more information about backing up and
restoring content indexes, see Chapter 28, “Disaster Recovery in SharePoint
Products and Technologies.”
You should create content indexes for the corporate portal site, each divisional
portal site, and any set of content sources that have a significant number of documents. For example, when crawling a large Internet site such as www.microsoft.com,
it would be wise to have a separate content index for management purposes.
206
Part III: Planning and Deployment
Note SharePoint Portal Server does not allow spaces in content index
names. Spaces are supported in source group names. Also, note that
Non_Portal_Content and Portal_Content exist by default.
Updating Content Indexes
The four methods for updating content indexes are as follows:
■
Full
■
Incremental
■
Incremental (inclusive)
■
Adaptive
The method used to update the index can have a significant effect on performance. These update methods are discussed in Chapter 21.
Propagating Content Indexes
Propagation happens automatically at the end of every successful update (or crawl).
The following should be taken into consideration when planning content indexes:
■
The destination search server must be on a trusted domain.
■
For every index to be propagated, there must be twice the size of the index in
free space on the destination search server.
Note Team sites under a SharePoint Portal Server portal site are crawled
normally; however, these sites can be searched only from the portal site
itself, not at the team-site level. To search from a team site, SQL Full Text
indexing must be enabled. For information on how to enable SQL Full Text
indexing, please refer to the SQL Server documentation.
Planning Alerts
Alerts provide notification when information of interest is added or updated on the
portal site and associated content sources. You can define areas of interest and identify how and when you want to be notified. You can add an alert to track new
matches to a search query, changes to content in an area, or a new site added to the
Site Directory.
Chapter 9:
Capacity Planning
207
When configuring alerts, keep in mind that alerts for SharePoint Portal Server
2003 and Windows SharePoint Services are managed separately. The three key differences between SharePoint Portal Server alerts and Windows SharePoint Services
alerts are as follows:
■
SharePoint Portal Server alerts are managed by the user on the My Alerts page,
which lives on the user’s My Site. Windows SharePoint Services alerts are managed through the Manage My Alerts link on the Site Settings page of each team
site.
■
SharePoint Portal Server alert notifications can be delivered to the user’s e-mail
inbox, to the user’s My Alerts Summary Web Part on the My Site, or to both.
Windows SharePoint Services alert notifications can be delivered only through
e-mail.
■
SharePoint Portal Server users can set alerts on more items than Windows
SharePoint Services users can.
■
Search alerts consume 2 KB and the other types consume .5 KB of memory on
the search process.
SharePoint Portal Server can track alerts for the following items:
■
Search queries
■
Documents and listings
■
Areas
■
News listings
■
Sites added to the site directory
■
SharePoint lists and libraries
■
List items
■
Portal site users
Windows SharePoint Services can track alerts on the following items within a
site:
■
Lists
■
List items
■
Document libraries
■
Documents
When shared services are enabled at the corporate level, management of alert
settings is possible only through the Corporate Portal Site Settings interface. Through
208
Part III: Planning and Deployment
this interface, you can set quotas for alerts per user and for all portal sites. You can
define and adjust the default numbers based on the following items:
■
The number of users
■
How many alerts each user can have
■
How many alert results you want to be returned per alert
You can adjust the defaults based on the number of users and the alerts-peruser setting to determine the maximum settings for alerts at the site level. For example, if your company has 20,000 users and you are setting a limit of ten search alerts
per user and 20 other alerts per user, your maximum number of alerts for all portal
sites is as follows:
20,000 x 10 = 200,000 is the maximum number of search alerts for all sites
20,000 x 20 = 400,000 is the maximum number of other alerts for all sites
Because all divisional portal sites consume shared services provided by the
corporate portal site, these are maximum numbers allowed for all divisional portal
sites and the corporate portal site combined. They are not per site.
Note Alerts on portal sites and Windows SharePoint Services team sites
are not consolidated.
Planning User Profiles
User profiles have several uses, including the following ones:
■
Searching for and connecting with people within your organization
■
Generating a My Site in the portal site for individual users
■
Providing better search results
■
Targeting content to audiences
Importing User Profiles
You can import user profile information directly from Active Directory or enter it
manually. You can also customize the properties of the user profile to meet the
needs of your organization or to map it to Active Directory properties.
If you have already invested in an infrastructure based on Active Directory or
any Lightweight Directory Access Protocol (LDAP)–compliant directory, you can
import user information stored in the directories. With Active Directory, use Import
Profile to import the user information to SharePoint Portal Server. Importing user
Chapter 9:
Capacity Planning
209
profiles requires a domain account. To use the incremental import feature from
Active Directory on a Windows Server 2000–based computer, a domain administrator account is required.
You can import user profiles from the same domain that SharePoint Portal
Server is installed on or from any trusted domain (although this is not tested in this
chapter). You can also configure and customize your connection to Active Directory
to import users based on specific criteria as a script in an LDAP query—for example,
all users who belong to a specific organizational unit (OU) or only users whose
e-mail address property is not empty.
If you are using other platforms, you can add users manually. You can add
more properties to the user profile if you need to extend the information that you
want to be displayed about a user. However, any such updates will not be propagated, nor will they update Active Directory.
Updating User Profiles
After the first import from the directory, you can schedule incremental updates
based on the frequency of users being added to Active Directory. In most cases,
scheduling incremental updates daily and full updates weekly is sufficient.
Note Removing a user from Active Directory and fully updating the user profile does not remove a user profile from the profile database. Nevertheless, a
user who is removed from Active Directory is not able to access the SharePoint Portal Server because users are authenticated through Internet Information Services (IIS), which authenticates users through Active Directory.
Planning Audiences
Audiences allow organizations to target content to users based on their job or task, as
defined by their membership in a Windows Server 2003 security group, distribution
list, organizational reporting structure, or the public properties in their user profiles.
Audience Rules
Audiences are created based on a set of rules that you define. Definitions are based
on the following items:
■
Windows security group, distribution list, or organizational hierarchy
■
User profile public property
■
Organizational hierarchy
■
Distribution lists
210
Part III: Planning and Deployment
A rule is a simple query based on properties of user profiles or membership of
users in security groups and distribution groups. If you have already created security
groups or distribution groups in Active Directory, you can create audiences based
on those groups. For example, you can define a rule for an audience group that
reports to or under a specific manager (domain\managerUserName). You can also
create an audience that belongs to a specific department if you have assigned a
value to the Department field of user profiles.
Compiling Audiences
After you create or make changes to an audience, you must compile it for use. Compiling an audience group is simply a matter of executing queries to find users who
meet the criteria defined in rules.
Audiences can be compiled at will, or they can be compiled by using a schedule that you create. Any changes to security or distribution group membership, security or distribution member properties, or user profile public properties will not be
reflected in the audience until it has been recompiled.
Compiling audiences can be expensive in terms of processor time as well as
disk I/O, especially if the audience membership query is complex. You should
schedule audiences to be compiled at a time when the server farm and Active Directory are least busy, probably at night. Because audiences are built based on User Profiles, you should also schedule User Imports to occur before audience compilation.
For large groups of audience compilation and complex audience memberships,
there will be a hit on both the processor of the farm servers as well as Domain Controllers because SharePoint Portal Server might query the Active Directory to compile the audiences.
Planning for Growth
This section provides information to help design a deployment that meets your
needs. The chapter describes performance considerations and testing, sizing guidelines, and strategies for scaling the design.
This section discusses the following items:
■
How to estimate system requirements
■
Choosing the appropriate farm solution for your scenario
■
How and when to scale the solution
■
Performance considerations
■
Configuration of test systems
■
Sizing recommendations
Chapter 9:
Capacity Planning
211
Estimating System Requirements
This section helps you to estimate your system requirements so that you can choose
the appropriate hardware and farm deployment. SharePoint Portal Server 2003 can
be configured in a number of ways and can scale to suit specific needs, such as general-purpose intranet, heavy search usage, or heavy team usage and collaboration.
To choose the appropriate design, the following needs must be considered:
■
Understand the users’ work patterns and the specific tasks they perform.
■
Obtain or estimate the size of the entire collection of documents that both
SharePoint Portal Server 2003 and Windows SharePoint Services will store,
including document versions, categories, and folders.
■
Estimate the internal and external site content to be crawled and indexed.
Historical access information from Web logs and third-party monitoring tools
can be used to determine current throughput rates and specific usage patterns if
there is a current intranet. However, if no intranet exists, you must make an estimate
based on a prediction as to what is required to support the overall business need.
End users see a portal site, viewing it either through a Web browser interface
or, in some cases, the Microsoft Office System client. It is inappropriate to size the
design based solely on the number of users. Base the system size and configuration
on the type of transactions (or portal site functions) and on the frequency of transactions. The “transaction arrival rate” is called the throughput rate.
In this section, you will estimate the following factors:
■
Peak throughput for each projected key portal and site type
■
Current and future storage needs
Estimating Peak Throughput
When users browse intranets or the Internet, search for files, check out documents,
or select from a list of choices, this usually causes the display of a new page of information. The more complex functions, such as document management, are especially
resource-intensive and can initiate the display of multiple pages of information. In
general, one user function is approximately equivalent to the display of one new
HTTP page on the user’s desktop. Therefore, throughput measurement is based on
the premise that the number of HTTP pages per second roughly equates to the number of calculated operations per second.
To calculate the peak throughput rates your SharePoint Portal Server farm must
support, you must obtain specific business-related sizing metrics. These sizing metrics differ depending on the type of portal site. For example, the typical user will
access the corporate portal site much less frequently than he will access his divisional portal site or Windows SharePoint Services sites.
212
Part III: Planning and Deployment
The following list provides key sizing metrics, along with typical values as a
guideline:
■
Number of users.
site.
■
Percent of active users per day. The percentage of the users who might
access the portal site during the day. This is typically between 10 percent and
50 percent. This is an important number and one that is usually a point of contention. Most customers like to think that each user hits the corporate or divisional portal site each day, but your experience might prove otherwise.
■
Operations per user per day. Accesses to the portal site Home page,
searches, category browses, document retrievals, media viewing, and so on.
Depending on the user’s role (whether it is reader, author, reviewer, or contributor), this number will usually range between 1 and 10 operations per day.
■
Hours per day. Hours in the business day. Portal site access can cross time
zones, so 10 hours per day might be a typical number for a company spanning
the United States.
■
Peak factor. A ratio of how much the peak usage exceeds the average usage.
You should size the systems for peak usage so that performance does not
degrade during busy periods. A typical ratio is 5 to 1.
The number of potential users with access to the portal
Note Peak factor is an approximate number that estimates the ratio of the
peak portal site throughput to its average throughput. This number typically
ranges from 1 to 5.
Next, using the following formula and the quantitative metrics of each portal
site’s usage characteristics, you will estimate the required portal peak throughput, in
operations per second.
Number of users × Percent of active users per day
× Number of operations per active user per day × Peak factor
360,000 × Number of hours per day
The constant 360,000 is derived from the following equation:
100 (percent conversion) × 60 (minutes per hour) × 60 (seconds per minute)
Break down the operations per active user per day by the type of site and
related functions, such as the following ones:
■
Corporate portal site access
Chapter 9:
■
Divisional portal site access
■
Windows SharePoint Services site usage
■
My Site usage
Capacity Planning
213
The following example illustrates how to estimate required throughput for a
divisional portal site component of the total workload. Table 9-1 shows sample characteristics representing a divisional portal site supporting approximately 10,000
users. This is a reasonably diverse workforce group, using a mix of common portal
site functions and a small percentage of complex functions. Most users typically
access the site through simple activities such as locating information by browsing
categories, searching for documents that match their needs, or reading divisional
news or announcements on the Home page.
Note Document collaboration functions (including document check-in and
document upload) are weighted differently than other functions. These more
complex activities take several steps to accomplish. Therefore, they should
be rated as three times as intense as other functions.
Table 9-1
Characteristics Representing a Divisional Portal Site
Characteristic
Value
Number of potential users
10,000
Percent of active users per day
80
Number of common operations per active user per day
32 × (weight = 1.0) = 32
Number of complex operations per active user per day
+ 8 × (weight = 3.0) = 24
Number of operations per active user per day
56
Number of hours per day
12
Peak factor
4
10000 users × 80 % usage × 56 operations × 4 peak =
41.48 ops/sec
360000 × 12 hours per day
As shown, these characteristics yield a predicted peak throughput requirement
of about 42 operations per second. To run just this portal site, a medium server farm
with two load-balanced front-end Web servers, an indexing server, and a server
running the SQL component would be needed. A rough estimate for performance
is each 1 GHz of processing power in the front-end servers can support 9 to 10
214
Part III: Planning and Deployment
operations per second. Therefore, each server in the farm should be approximately
a 2 x 2-GHz Pentium 4 Server with 2 GB of RAM. This is a close estimate of the hardware requirements needed for the example. If more portal sites are being hosted on
the same farm, higher hardware requirements are necessary.
Rough hardware estimates are based significantly on the type of farm being
used. Because each farm type has resources broken down in different ways, they
have different operations-per-second estimates. A single server farm with MSDE
cannot exceed five concurrent database jobs, and therefore, cannot realistically
exceed five operations per second. For cached operations, a slightly higher operations-per-second rate might be achieved, but on average, it will remain about five
operations per second. A single server farm with SQL Server will be able to support
around 6 to 7 operations per second for each 1 GHz of processing speed. If the
server is constantly doing a lot of indexing, this number will be lower, as the server
will be using processing resources on indexing.
A small server farm environment will be able to support approximately 7 to 8
operations per second per 1 GHz of processing speed. Again, if there is a lot of indexing, the number will be lower. You should restrict indexing activities to periods of light
usage, such as late at night, in single-server and small server farm environments.
Medium server farm environment can handle more requests, not only because
resource-intensive operations such as indexing are offloaded, but because a
medium server farm can support more than one front-end server. It is the front-end
Web servers and search servers that mainly affect the number of operations per second for users. A medium server farm can support approximately 9 to 10 operations
per second per 1 GHz of processing speed on the front-end Web servers.
Large server farms can handle more requests still because the search and Web
components are running on different servers. It’s difficult to estimate the capacity of
large server farms without knowing the breakdown of search requests versus normal
requests. A rough estimate is that a large server farm can support 11 to 12 operations
per second for each 1 GHz of processing power on the front-end Web servers, but
this is a general approximation.
The numbers provided in this section are general guidelines and approximations, as actual results will vary based on the exact hardware you are running. It is
important to run capacity planning tests on your servers to ensure they will be able
to perform adequately. This testing is especially important in a large server farm
environment, where it is harder to gauge the actual hardware requirements without
knowing the exact environment specifications. For example, if there will be a lot of
searching going on in a large server farm, it is important to have many search servers
and to test the whole farm using a script that simulates many searches. Full coverage
of testing servers for capacity will be provided in the “Testing for Capacity” section
later in this chapter.
Chapter 9:
Capacity Planning
215
Estimating Current and Future Storage Needs
Estimate the size of the required content by analyzing the quantity and size of existing documents in shared folders and other existing systems. To determine your current and future storage needs, try to identify current access frequencies and patterns.
Once you have determined the total size of all documents you plan to store in
your SharePoint Portal Server farm, including all team sites, you can start to plan
disk space requirements. You must consider the number of versions for all documents you plan to store. Multiply the number of versions you expect by the total size
of all documents to get the total storage size for documents.
The SQL Server component will be the place the documents are actually
stored. It needs disk space equal to twice the total size of all documents, including
versions, you want to store in all your portal sites. This free disk space is required on
the drive where the SQL Server databases reside. Also, the storage requirement does
not include any operating system or supporting system software. If you plan on storing large quantities of files, you should store the SQL Server databases that SharePoint Portal Server uses on a storage area network (SAN). You should refer to SQL
Server documentation for information on what SAN products are compatible with
SQL Server.
Note SQL Server does not support storing database files on NetworkAttached Storage (NAS), so the free storage requirement must be met on a
local physical disk on the SQL Server or on a SAN.
Once you have determined total document storage for SQL Server, you must
determine the total size of documents being indexed. Take the total size of each
content source—file shares, exchange public folders, and websites—that you want
to index, and add that sum to the total size of all files stored in the server farm. This
number is the total size of all documents to be crawled. Take this number and divide
it by two. That is the total storage required on each indexing server in your farm.
Then divide the number by two again. That is the total space required on each
search server in your farm.
In a single-server environment, all components run on the same system. This
means you need all the storage space on a single system. A single-server environment needs free space equal to 2.75 times the total size of all documents stored if
there are no external content sources. A small server farm separates the SQL Server
storage component from the other components. In a small server farm, the SQL
Server component needs twice the total size of documents to store in free space and
the server that runs the SharePoint Portal Server components needs to have .75 times
216
Part III: Planning and Deployment
the total size of all documents being indexed in free space. Medium and large server
farms follow the breakdown previously described.
Choosing the Farm Design
A well-planned deployment can scale cost-effectively to accommodate increasing
usage or changing workloads while maintaining the required performance. This section covers the following topics:
■
Single-server deployment
■
Small server farm
■
Medium server farm
■
Large server farm
■
Capacity planning
■
Scaling
■
Growth path from a medium server farm to a large server farm
Knowing the usage profile helps you to choose the appropriate architecture.
For example, if your usage profile indicates heavy indexing and searching, you
should deploy the large server farm design. Large server farms contain at least two
dedicated search servers and provide a growth path that enables you to deploy additional dedicated search servers, in addition to index and job servers. If your usage
profile suggests that a majority of the workload will come from heavy team collaboration and significant usage of Windows SharePoint Services sites, consider deploying a dedicated Windows SharePoint Services farm for hosting the Windows
SharePoint Services sites.
Single-Server Design and Performance
The single-server topology is designed to support between 1 and 10,000 users, but
the actual number of users it can support is dependent on the usage profiles and
workload patterns. The preceding example shows there will be only 10,000 users
accessing the portal, but because of the workload mix, a single-server solution
would not be able to adequately handle the required 42 operations per second. A
single server running MSDE as the back-end datastore is designed to support only
5000 users because of the concurrent job restriction MSDE has.
A single-server deployment has all SharePoint Portal Server components and
the SQL Server component running on the same physical computer. This topology
does not scale well. To add capacity, you must move to the next type of farm, and
to do so, you must migrate your current back-end datastore to another server. Unless
Chapter 9:
Capacity Planning
217
you have fewer than 5000 users or very light portal usage, you should not consider
a single-server design for production.
A single-server solution is very good, however, for testing and development. If
you want to stage custom-developed Web Parts or other types of portal modifications that could easily affect performance or stability of your main portal, you should
use a single-server platform. Often developers run a single-server topology for their
development workstations for fast development, debugging, and testing.
Small Server Farm Design and Performance
A small server is designed to support between 5000 and 15,000 users, but the number of users supported ultimately depends on usage profiles and workload patterns.
Again, the preceding example has 10,000 users, but the given workload mix is still
too heavy for this topology. Only a very powerful small server farm would be able
to support 42 operations per second, and it would be more economically feasible to
run a medium server on lower-end hardware than two high-end, expensive servers.
Small server farms scale better than a single-server topology. You still have to
move to a medium farm if you want to scale your capacity to more users or more
operations per second, but it is far easier to scale a small server farm than a single
server. This is because a small server farm already has the back-end SQL Server component installed on a separate physical machine, making the process of adding a
server as simple as changing some check boxes in SharePoint Central Administration
and rebuilding content indexes.
Medium Server Farm Design and Performance
The medium server farm supports between 15,000 and 50,000 users, but the number
of users supported is entirely dependent on the usage profiles and workload patterns. The example in the previous section shows that 10,000 users executing a
given workload mix required a solution capacity of about 42 operations per second.
As results in later sections show, a medium server farm can support about three
times that capacity—or 30,000 users running the sample workload. Note that the
example represents every active user accessing the portal in some manner about
every 20 minutes, and is therefore a reasonably harsh workload. Less intense user
activity will obviously translate to more supported users.
A medium server configuration consists of a three to five server farms,
designed to allow high availability and scalability. The most common medium farm
design consists of two front-end Web servers that also provide the search components for the farm, a dedicated index and job server, and a SQL Server component,
which can be a two-node cluster. The remainder of this section will discuss the
highly available medium server farm with a SQL cluster reference configuration. The
other medium server configurations are similar, but they are not as scalable or highly
available.
218
Part III: Planning and Deployment
In the common medium server farm, each function is implemented on redundant servers, with the exception of the indexing and job server functions. (There can
be only one index and job server per farm.) Even the failure of the index and job
server does not immediately affect availability because the search services are still
available to end users. However, no indexing of new content is possible until the
index and job server becomes available.
In the medium server farm solution, the front-end Web servers also host the
search components for the farm. Consequently, the performance of the front-end
Web servers is predicated on their ability to respond to end-users’ requests to serve
pages and to respond to search queries.
You can scale a base-line medium server farm by using one of the following
two methods:
■
Adding a front-end Web and search server to the Network Load Balancing cluster, thereby increasing the capacity and availability
Note In a medium server farm, you cannot add dedicated search servers,
nor can you add index and job servers. To add such servers, you must
deploy the large server farm. However, you can scale from a medium server
farm to a large server farm after initial deployment.
■
Deploying the medium server farm with a separate dedicated Windows SharePoint Services farm to host SharePoint Portal Services sites
The five-server medium-server farm configuration was tested by applying a
typical usage workload. This workload contains a mix of typical user functions as
might be used on each of the four main types of portal sites or websites: Corporate,
Divisional, Team Sites, and My Sites. This workload and the results obtained with it
are considered to be representative of a majority of users and business usage. If a
specific customer’s workload differs substantially from the workload used, results
and supported throughput for the various functions will vary from those presented
here. Testing will give information for how to take such workload differences into
consideration and how to estimate expected performance.
The tested highly available medium server farm with a SQL cluster (the configuration for which was stated previously in this chapter) provided a sustained
throughput rate of 110 operations per second, where an operation corresponds to a
portal function—for example browse, search, or open document—at an average
CPU consumption of 80 percent on each of the 2 Network Load Balancing (NLB)
Web front-end servers. The average CPU consumption of the active computer running SQL Server was approximately 35 percent (2 × 2.8 GHz CPUs). This indicates a
4 to 1 ratio between front-end Web server processors and SQL Server processors. A
Chapter 9:
Capacity Planning
219
medium server farm, however, supports only two servers, so this solution cannot be
scaled out by adding additional front-end Web servers. The observed network traffic
rate between the front-end Web servers and the simulated client systems was
approximately 5300 KB per second. The search service on the front-end Web servers
was supporting approximately 8 search operations per second. User-perceived performance, as evidenced by the response times reported by the Segue Silk Performer
reports and analysis, was typically sub-second for the simple functions such as navigating to the Home page, browsing, or reading news. Search operations responded
in 1.5 to 2.0 seconds, depending on the query complexity, the number of indexes
that were referenced, and related factors. Document management operations such
as check-out/check-in completed within 2.0 to 2.5 seconds. Opening documents
took no longer than 3 to 5 seconds on average, depending on document type and
document size—larger documents obviously require more time to transfer to the client desktops.
Large Server Farm Design and Performance
The large server farm solution is targeted at large organizations, and particularly at
customers whose usage profiles suggest heavy indexing and searching. The estimated number of seats the design can support will vary based on your customer’s
particular usage profile and workload patterns.
The large server farm solution provides a scalable architecture, consisting initially of at least six servers: two dedicated front-end Web servers, two dedicated
search servers, a dedicated index and job server, and a SQL 2000 Server component,
which can run in an active/passive cluster.
The large server farm solution is highly available and can be scaled in a number of ways, including:
■
Adding dedicated front-end Web servers to the NLB cluster to increase both
capacity and the availability of the solution
■
Adding dedicated search servers and index servers, which is ideal for customers with heavy search and indexing requirements
■
Deploying the large server farm solution with a separate dedicated Windows
SharePoint Services farm to host the SharePoint Portal Services team sites
The tested minimum large server farm with a SQL cluster configuration provided a sustained throughput rate of 125 operations per second, where an operation
corresponds to a portal site function (such as browse, search, open document, and
so on), at an average CPU consumption of 80 percent on each of the two NLB frontend Web servers. The average CPU consumption of the active computer running
SQL Server was approximately 25 percent (4 × 2.0 GHz CPUs). This indicates that a
total of six front-end Web servers could be supported by a large server farm with a
220
Part III: Planning and Deployment
single active quad-CPU computer running SQL Server, providing a total capacity of
about 375 operations per second.
The observed network traffic rate between the front-end Web servers and the
emulated client systems was approximately 5600 KB per second. The search service
on the two dedicated search servers was supporting approximately eight search
operations per second total (per the workload definition), consuming only about 4.5
percent CPU on each of the search servers. User-perceived performance was similar
to that of the medium server farm, with typically sub-second performance for the
simple functions (access Home page, browse, read news, and so on). Search operations responded in 1.5 to 2.0 seconds, depending on the query complexity, number
of indexes, references, and so on. Document management operations (such as
check-out/-in) completed within 2.0 to 2.5 seconds. Opening documents took no
longer than 3 to 5 seconds on average, depending on the file type (Microsoft Office
Word, Microsoft Office Excel, Microsoft Office PowerPoint, and so on) and file
size—larger files obviously requiring more time to transfer to the client desktop
computers.
Adding Capacity
Monitoring servers frequently to determine when additional capacity is needed is an
important factor in capacity planning. Information on how to monitor servers is not
included in this chapter. You should refer to Chapter 10,“Performance Monitoring in
Microsoft Office SharePoint Portal Server 2003,” for detailed information on monitoring servers. For single servers and small farms, the only way to increase capacity is
to move to the next farm level up when CPU and memory have hit their limits. To
add capacity to a medium or large server farm, see Chapter 11.
Performance Considerations
Although much effort has been spent by Microsoft and its partners to design and use
a workload that is representative of typical user type mixes and portal site functions
use, the results obtained are clearly related to that workload definition and the portal
site’s corpus content. Everyone should test their servers for capacity before going
live, but doing so is highly recommended and almost imperative if your workload
differs significantly from the workload used during testing for this chapter.
The following is a summary of key performance results from the testing done
for this chapter:
■
A single server with MSDE cannot handle more than five operations per second
because of the five-job limit MSDE imposes. In this scenario, MSDE is the limiting factor.
Chapter 9:
Capacity Planning
221
■
The single server with SQL Server configuration supported a sustained
throughput of 15 operations per second at 80 percent average CPU consumption. The CPU was the limiting factor here. To scale this server to support more
users would require going to a small server farm.
■
The small server farm supported a sustained throughput of 18 operations per
second at 80 percent average CPU consumption on the server running SharePoint Portal Server. The server running SharePoint Portal Server was the limiting resource in this scenario. The server running SQL Server was 32 percent
busy on average. The best way to scale from this environment is to move to a
load-balanced or highly available medium server farm.
■
The load-balanced farm supported a sustained throughput of 39 operations per
second, with the limiting resource being the two NLB front-end servers running
at 80 percent average CPU. The server running SQL Server was 50 percent busy
on average.
■
The highly available medium server farm with SQL cluster configuration supported a sustained throughput of 110 operations per second, with the limiting
resource being the two NLB front-end servers running at 80 percent average
CPU consumption. SQL Server (2 × 2.8 GHz) was 35 percent busy on average.
The SQL Server used could support a maximum of four front-end servers, providing a total of over 200 operations per second. However, a medium server
farm topology does not support more than two front-end servers, so to scale
from this configuration, you must increase the number of processors in your
front-end servers or move to a large server farm configuration.
■
The minimum large farm configuration with a SQL cluster supported a
throughput of about 125 operations per second, with the limiting resource
being the two NLB front-end Web servers running at 80 percent busy on average. SQL Server (4 × 2.0 GHz) was 25 percent busy. Adding a front-end Web
server would add about 60 operations per second to the total capacity. The
server running SQL Server (4 CPUs) could support a total of six front-end
servers, yielding a total of over 375 operations per second.
■
The search service, running on either the front-end Web servers or on dedicated servers, was not used heavily with the test workload, which employed
between 10 percent and 25 percent search function activity, or 8 to 10 searches
per second. However, search-specific testing showed that a single dedicated
search server can support over 210 search operations per second. The second
search server in the prescribed large server farm configuration is to ensure
availability of the search service if the other server were to fail.
222
Part III: Planning and Deployment
■
The indexing server is easily able to handle real-time indexing of documents
that are checked in. It also performs incremental-type re-indexing in a period
of time suitable for frequent periodic indexing, and it can perform an indexinclusive operation suitable for overnight scheduling. Full re-indexing of large
indexes containing significant content should be achievable over a weekend.
■
Network traffic between the clients and front-end servers, and traffic between
the front-end servers and other configuration systems (search servers, indexing
server, and SQL Server) is not excessive and should be supportable using 100
megabit network segments. For the larger farm configurations, which have
high operation rates, the prescribed network design of two virtual LANs was
used. This design is used to segment differing network traffic (for instance,
HTTP client/front-end traffic and other server intercommunication traffic) onto
two separate LANs so that they do not saturate a network segment and user
response times are not affected by nonclient traffic.
■
Performing database and disk maintenance is strongly recommended. Periodic
execution of an SQL Server query to adjust table statistics and re-index database tables will result in optimal SQL Server database performance. Periodic
examination of logical disk volume fragmentation levels and appropriate remedial action will ensure that the I/O subsystem does not impede performance.
Testing for Capacity
Testing for capacity is one of the most important parts of capacity planning. It will
determine whether your planned topology will actually support the number of users
and operations per second you expect. Testing will be employed after you have
planned your infrastructure using the information presented in the preceding sections. Once the topology is built, before putting it into production, it should be
stressed with both the normal workload mix you expect and the peak workload mix
you expect to ensure that it can easily support the load. There isn’t much that’s
worse for a deployment than spending a lot of time and money planning and building a solution only to put it into production and have it fail because the system could
not handle the load.
This section will discuss tools you can use to stress test your portal sites as well
as how to use those tools. It will also provide some basic performance monitoring
information, but more in-depth performance monitoring information can be found
in Chapter 10. Before proceeding, you should know the most general workload pattern. Typical portal site activity for a general business solution is 20 percent corporate portal site, 15 percent divisional portal sites, 40 percent team sites, and 25
percent My Sites. Your custom workload pattern will probably be different, and you
should apply the information presented to your custom pattern. The examples in
this section will discuss the workload pattern for the general business solution.
Chapter 9:
Capacity Planning
223
Selecting the Stress Test Tool
Several tools on the market allow users to perform load simulation. In this book, the
Microsoft Application Center Test (ACT) tool will be used to generate the tests, as it
is available as part of Microsoft Visual Studio .NET and it allows you to generate load
tests and create reports. If you would like to perform more advanced load simulation work, you will have to purchase third-party solutions such as LoadRunner, as
these solutions have been designed to meet more advanced requirements.
Web Application Stress Tool
The Microsoft Web Application Stress tool is not recommended for testing the performance of SharePoint Portal Server 2003 portal sites, as it cannot handle many
ASP.NET-related features, such as handling view states. This is why it will not be
used for the load simulation of SharePoint Portal Server 2003 portal sites, although
it still can be a useful tool for testing traditional ASP Web applications.
Application Center Test
ACT is designed to stress test Web servers and to analyze performance and scalability problems with Web applications. ACT can simulate a large group of users by
opening multiple connections to the server and rapidly sending HTTP requests. ACT
ships with the Enterprise Edition of Visual Studio .NET. Unfortunately, ACT does not
have some advanced features that the Web Application Stress tool has, such as the
ability to string multiple computers together to perform one large stress test. Each
computer running ACT must perform its own test, and if you want to produce a
large test, you must run ACT individually on many computers and manually aggregate the results. Figure 9-5 shows what the user interface of ACT looks like.
Figure 9-5
F09XR05
The ACT user interface
224
Part III: Planning and Deployment
ACT allows you to create or record scripts (captured by Microsoft Internet
Explorer) and run them at a later stage. Unfortunately, recording a script does not
support authentication, so you must either record a script against a portal site with
anonymous access enabled or write your own script. Creating a new test will provide you with the most basic test you can run. It contains just one line:
Test.SendRequest(“http://localhost”)
This script will send a request to the local server and ask for a response. The
HTTP response code will be recorded. Scripts can then be customized and run several times. It is possible to configure scripts by right-clicking on them and selecting
the properties, as shown in Figure 9-6.
Figure 9-6
F09XR06
ACT test properties
ACT allows the user to configure several settings. One of them is the load level.
A user can specify how many simultaneous browser connections (concurrent users)
should hit the portal site. The other option is to also specify how long the scripts
should run. Remember that the Visual Studio .NET edition of ACT does not allow
you to connect multiple clients as the Web Application Stress tool did. Therefore, to
perform large load tests, you have to run the stress scripts manually on each client
and then merge the results to one report.
To simulate the load tests with multiple users, you have to configure a user
group with the ACT tool. You can do that either manually or by importing a CSV file.
Enabling user groups with multiple users allows the ACT tool to hit the portal site
with unique users instead of using the same user multiple times. Make sure that the
users within the ACT tool also have access rights to the portal site. Otherwise, there
will be access problems.
Make sure that if you are using domain accounts the username field also
includes the domain prefix, as shown in Figure 9-7. Also, to make your life easier, try
Chapter 9:
Capacity Planning
225
to create user names that have an integer at the end that increments by 1 and use the
same password for all of them. That way, you can have the ACT tool generate the
users for you.
Figure 9-7
F09XR07
Users in ACT
Tools Used When Performing Load Simulations
There are a couple of tools that can help you understand the behavior and performance of your portal site. One of them is Network Load Balancing Manager, and the
other one is the performance counter.
Network Load Balancing Manager
If you have any form of load-balanced server farm (medium or large farm), you
should use Network Load Balancing (NLB) Manager during stress testing. NLB Manager allows you to create, configure, and manage all hosts of a Network Load Balancing cluster from a single computer. You can then use NLB manager to bring down
nodes in the cluster to see the effect on performance. For more information on
using NLB Manager, please see the Network Load Balancing section of Chapter 11.
Performance Monitor
Microsoft ships the performance monitor together with the operating system. It is
extremely important to monitor the performance of CPU, Memory Usage, and Network Utilization on each of the servers running SharePoint Portal Server during
stress testing. It is also imperative that you monitor SQL Server performance
counters on the SQL Server component during testing. Before you start your performance measuring, you will have to select from a huge list of performance counters
226
Part III: Planning and Deployment
that might be of interest to you during the load simulation. You can monitor
counters on remote servers, but this is not recommended during stress testing, as the
resources required to send the performance data to the monitoring client might
affect the test results. For more information on performance monitoring and exactly
what to monitor with respect to SharePoint Portal Server, please refer to Chapter 10.
Scenarios for Load Stress Testing
One of the most important tasks before performing any stress tests is to understand
what the different scenarios can be. These scenarios could be written down and
then ordered by weight. It makes sense to test these scenarios, as they represent
most common tasks the users will perform and therefore should result in the fastest
response time possible. There are some tasks for which users simply expect a fast
response time, while there are others where they can accept slower response
times—for example, administrative tasks.
Performance scripts can be created to mimic anticipated load on the portal site.
The scenarios that follow represent the most commonly occurring scenarios, but if
your scenario differs, feel free to adjust according to your customized usage profile.
The Portal Home
SharePoint Portal Server allows you to create several portal sites. These are basically
the main places for information in an enterprise implementation and will be one of
the most requested locations in the intranet. It is important that at least the Home
page opens up in a very fast manner. Normally, the corporate portal site will receive
20 percent of the total farm traffic, and the Home page of the corporate portal site
will receive a significant amount of that traffic.
My Site
Personalization was one of the biggest demands of the users of the previous version
of SharePoint Portal Server. In SharePoint Portal Server 2003, every user can go to
his personal site by clicking My Site in the upper right corner. There is a personal
and shared view for each user. The user can decide between the shared and personal view of the site and do some modifications. As most of the time people will
access mainly their own sites, we will focus on the Personal View page and not on
the Shared View.
The Shared View should be tested if you plan on using the corporate portal site
as a corporate directory. Because the Shared View of the My Site, combined with
user profiles, provides a very nice corporate directory, some organizations will make
use of this feature. In this instance, you should make public My Site views a low
percentage of testing because the public.aspx is one of the most expensive pages to
render. If you do not plan on using Shared Views as a corporate directory, it is not
necessary to include the Shared Views in your stress-testing plans.
Chapter 9:
Capacity Planning
227
Topics
Topics allow the users to browse the portal site’s content by using a logical representation of grouping. Browsing topics is an easier way for users to find information
and is also usually generates many hits on the server. It is important to test the
latency of the topic structure because users are likely to use topics to find information. Users might find it unacceptable if the topic structure takes too long to load.
Team Sites
Windows SharePoint Services allows users to create team sites that are more project
or department specific than the corporate or departmental portal sites. These sites
can be used by teams to upload documents and collaborate and therefore will be
requested many times as well. Microsoft’s research shows that 40 percent of all farm
traffic will be to team sites.
Custom Pages and Web Parts
Adding custom Web Parts to pages is what makes SharePoint Portal Server a flexible
solution. These Web Parts can also have a huge impact on the overall performance
of the system. Custom Web Parts that are not properly developed or that connect to
external resources can dramatically slow down the performance of the system. For
example, if you normally serve 24 pages a second, each page is served in about 40
milliseconds. All Web Parts on that page are rendered in that time. Therefore, it is
important to test each of these Web Parts before importing them into a production
portal site. This procedure would allow the administrator to identify whether the
Web Part could be the bottleneck of the portal site.
Search
One of the most important features of a knowledge management solution is a powerful search engine that not only allows the user to find accurate information
throughout the enterprise but also performs quickly. Therefore, the search performance is also another scenario that has to be tested. Research shows that 25 percent
of the corporate portal site usage is for searches. If your organization plans to use
searches extensively, it is even more important to thoroughly stress test the search
function.
Mixed Scenario
A mixed scenario uses a combination of multiple scenarios to verify how the system
performs when multiple parts of the portal site are being used at the same time. The
mixed scenario represents actually the most realistic and therefore interesting scenario. A mixed scenario is the most important one to test, but doing so requires
using customized ACT scripts.
228
Part III: Planning and Deployment
What Does Not Need to Be Tested
This section focuses on the most widely used workload scenarios. Other scenarios—
such as administrative tasks, document uploads, adding Web Parts to a portal site,
and so on—do not occur as often as the scenarios just mentioned. If your organization has other scenarios, such as document uploads, that are more prevalent than
the general case, you should modify your test plan accordingly.
Testing Methodology
Before running any tests, you should create a table in which you enter the number
of concurrent users that would hit the portal site. You should start with one user and
increment slowly with each subsequent test to see the impact on the portal site. You
do not want to start with a high number of concurrent users and flood your portal
site. That will not give you accurate test results, and you will most likely get frustrated trying to interpret the error-ridden results you get. You can increase the number of the concurrent user threads in the ACT tool in the properties of a test script
as shown in Figure 9-8.
Figure 9-8
F09XR08
Setting the load level
The test load level indicates the number of simultaneous browser connections
that the client will generate while performing the tests against the portal site. It is
important to note that you will need to have enough users in the users profile to be
able to concurrently hit the page. The load level should never be more than the number of users. If it is, the test will fail. The more user connections you have, the more
load you will put on the server. You will also generate additional load on the client
running the test as you. Generating too much load on the client will result in incorrect numbers, as the clients will not be able generate the expected load.
Chapter 9:
Capacity Planning
229
The ideal approach is to generate as much load as possible without affecting
the clients while still maximizing load on the SharePoint Portal Server front-end Web
servers. The client should have no more than 50 percent processor utilization during
stress testing, and the average server load should average from 80 percent to 90 percent. A perfect testing methodology should enable the tester to eventually find the
bottleneck that might be in the system. Although the next chapter will mention several important counters for the performance analysis, the most important ones are
the following ones:
■
ASP.NET Requests/Sec
■
Processor utilization
■
Disk Queue
■
Pages/Sec
Looking at these counters should already give some valuable information
about the portal site’s bottleneck. This information will help determine in the decision-making process what might need to be upgraded to further enhance the portal
site’s performance if that is required.
By performing the incremental increase of the concurrent connections, you
will find out that the more load you generate the smaller the increase for the
requests per second (RPS) will be. The ACT tool shows RPS, but these are the same
as the operations per second discussed previously. Eventually, you will get to the
point where you no longer get a higher RPS when you add users. This is the maximum throughput for the current server. Table 9-2 shows the results of a simple ACT
test that just loads the corporate portal site Home page with 1, 2, 5, 10, and 20 concurrent connections on a single server within a SQL Server environment.
Table 9-2
Results of a Simple ACT Test
Concurrent Connections
1
Test Results
Average requests per second: 12.83
Average time to last byte (msec): 48.75
2
Average requests per second: 17.85
Average time to last byte (msec): 56.09
5
Average requests per second: 20.97
Average time to last byte (msec): 90.11
10
Average requests per second: 21.89
Average time to last byte (msec): 137.15
20
Average requests per second: 22.06
Average time to last byte (msec): 233.50
230
Part III: Planning and Deployment
You can see that the RPS of the portal site stops growing at around 22 RPS. The
other thing that is important to notice is that the latency increases as more load is
generated.
Generating Load and Interpretation of the Results
The purpose of stress testing is to determine how a portal site will perform and to
identify bottlenecks under load. Running scripts for the different scenarios that accurately simulate the expected production traffic will generate load on the servers. The
purpose of a performance test should be to find out the maximum throughput under
load. To better understand what might be acting as the bottleneck of the portal site,
it makes sense to check for several counters on the different servers.
The most interesting point to find out is the throughput capabilities of the portal site. Throughput is the amount of work that the portal site can do in a given time
period. In this case, that would mean finding out how many requests per second the
portal site can handle. Splitting the performance counters into three groups makes
sense. First of all, we have to make sure that the clients are not suffering too much
under the load they are generating. Second, using different counters for the SQL
server and the front-end servers will show us where the bottleneck lies (that is, at
the front end or back end).
All the different scripts can be run with the ACT test tool, and there will be two
kinds of results that can be analyzed. One type is the Web server responses that tell
you whether there were any HTTP errors, how many pages have been processed,
how long it took to open up the page, and so on. The other results are the performance counters that also indicate server hardware-related results.
Types of Scripts
As defined earlier, the most basic script contains just one line:
Test.SendRequest(“http://sps”)
What this script does is send a request to the server http://sps and requests the
default page for the site. Because this is a corporate portal site, the default page is
Default.aspx. The Web server processes the Default.aspx page and returns the result
to the client computer. ACT times this whole transaction and uses that information
to generate RPS data. Running this script will generate performance data for your
server or server farm, but it is not particularly useful unless the only thing your users
do is go to the Home page of the corporate portal site.
Using a mixed-scenario script is much more useful for testing the portal site.
The following script performs the general workload mix on a specified corporate
portal site. This script can be modified for divisional portal sites or to include other
sites. It can also be modified for specific workload mix requirements of your organization. The code for the mixed scenario script is as follows:
Chapter 9:
Capacity Planning
RANDOMIZE
Test.SetGlobalVariable “g_SERVER", “http://<put your server name here>“
SERVER = Test.GetGlobalVariable(“g_SERVER”)
‘*****************************************************************************
‘ Mixed Scenario Script
‘*****************************************************************************
Select Case int(2*RND)
’50% GetHomePage
Case 0
Call GetHomepage
Case 1
Select Case int(10*RND)
’20% GetMyPage
Case 0, 1, 2, 3
Call GetSearch
’15% GetSearch
Case 4, 5, 6
Call GetSearch
’5% GetSiteReg
’5% GetCategories
Case 7, 8, 9
Select Case int(3*RND)
Case 0
Call GetTeamSite
Case 1
Call GetSiteReg
Case 2
Call GetCategories
End Select
End Select
End Select
‘*****************************************************************************
‘ TM_GetHomepage
‘ Purpose: Gets the default homepage
‘*****************************************************************************
Function GetHomepage
GetUrl SERVER & “/default.aspx", “Homepage"
End Function
‘*****************************************************************************
‘ TM_GetMyPage
‘ Purpose: Gets my page
‘Note: In order to have this work you will have to import the users from the AD
‘ on the SharePoint Portal Server portal site and give them the necessary rights
‘to have their own My Sites
‘You will have to also use the PortalCramIt tool to generate the
‘sites so that you will really hit existing My Sites
‘*****************************************************************************
Function GetMyPage
GetUrlMyPri SERVER & “/MySite/default.aspx", “MyPage"
End Function
‘*****************************************************************************
‘ TM_GetSearch
231
232
Part III: Planning and Deployment
‘ Purpose: Gets the default search page
‘Note: We are searching here for the word home, you could of course
‘change that
‘*****************************************************************************
Function GetSearch
GetUrl SERVER & “/Search.aspx?k=Home", “GetSearch"
End Function
‘*****************************************************************************
‘ TM_GetCategories
‘ Purpose: Gets the main categories page
‘*****************************************************************************
Function GetCategories
GetUrl SERVER & “/Topics/default.aspx", “GetCategories"
End Function
‘*****************************************************************************
‘ TM_GetTeamSite
‘ Purpose: Gets a Team Site Homepage
‘Note: In order for this script to work you will have to create
‘a team site and enter its name into the URL below
‘*****************************************************************************
‘Get Team Site gets it own Object because can not access with Reader.
Function GetTeamSite
GetUrl SERVER & “/sites/<name of an existing team site>/default.aspx", “GetTeamSite"
End Function
‘*****************************************************************************
‘ TM_GetSiteRegistry
‘ Purpose: Gets the site registry page
‘*****************************************************************************
Function GetSiteReg
GetUrl SERVER & “/SiteDirectory/Lists/Sites/Summary.aspx", “GetSiteRegistry"
End Function
‘*****************************************************************************
‘ GetUrl
‘ Purpose: Gets the passed in URL. Send the pagename to be logged
‘Note: the number 200 can be replaced by any number you wish as long as these
‘users have been generated in the AD
‘*****************************************************************************
Sub GetUrl(strURL, strPage)
RANDOMIZE
F = INT(200 * RND)
Test.GetCurrentUser
tStart = Timer()
Set oResponse = Test.SendRequest(strURL)
tFinish = Timer()
Test.GetNextUser
End Sub
Sub GetUrlMyPri(strURL, strPage)
Chapter 9:
Capacity Planning
233
RANDOMIZE
F = INT(200 * RND)
Test.GetCurrentUser
Set oUser = Test.GetCurrentUser
oUser.Name = “domain\user” & F
oUser.Password = “password"
tStart = Timer()
Set oResponse = Test.SendRequest(strURL)
tFinish = Timer()
Test.GetNextUser
Set oUser = Nothing
End Sub
After running the script, it is very important to see what the results of the test
have been. ACT automatically generates for each test run a report file that can be
analyzed as shown in Figure 9-9.
Average requests per second:
Average time to first byte (msecs):
Average time to last byte (msecs):
Average time to last byte per iteration (msecs):
Number of unique requests made in test:
Number of unique response codes:
8.90
100.91
106.28
106.28
5
1
Error Counts
HTTP: 0
DNS: 0
Socket:
0
Additional Network Statistics
Average bandwidth (bytes/sec):
Number of bytes sent (bytes):
Number of bytes received (bytes):
Average rate of sent bytes (bytes/sec):
Average rate of received bytes (bytes/sec):
Number of connection errors:
Number of send errors:
Number of receive errors:
Number of timeout errors:
710,950.39
4,567,107
208,704,511
15,223.69
695,681.70
0
0
0
0
Response Codes
Response Code: 200 - The request completed successfully.
Count:
Percent (%):
Figure 9-9
F09XR09
2,669
100.00
ACT test results
The most important information for the stress tester to determine is the average
RPS that were achieved while running the test script. This number is equivalent to
the number of operations per second the server can support. It is important to compare the numbers produced in testing with the numbers that were determined when
planning. The RPS number achieved through ACT should be greater than or equal to
234
Part III: Planning and Deployment
the operations per second determined in planning the portal site. If it is not, your
portal site will not be able to handle the load you planned for.
It is also important to note the average time to last byte. This is the amount of
time a user would have to wait for a requested page. The number is in milliseconds,
so a number greater than 1000 indicates that under the simulated load conditions an
end user would have to wait more than 1 second for the requested page. This number is especially important to pay attention to if your users will not tolerate wait
times.
While the scripts just shown actually already do generate good stress on the
servers, there is one thing that was not taken into consideration so far: the caching
of site components such as style sheets, .gif, .jpg, and so on. If you are testing for
environments over slow links, this is very important. The following script opens the
default Home page, default.aspx, and checks the modified date of the site’s cascading style sheets (CSS) file against the local file if one exists. If the file had not been
downloaded, the script will not download another copy. The code is as follows:
RANDOMIZE
Test.SetGlobalVariable “g_SERVER", “http://<serverURL>“
servername = “<servername or IP>“
SERVER = Test.GetGlobalVariable(“g_SERVER”)
Call GetHomepage
Function GetHomepage
GetUrl SERVER & “/default.aspx", “Homepage"
’in this script we have added only one file. You can add more of
‘these files if you want. (path of these ’ ’
’ can be found out by looking at the page’s source)
GetLastModifiedUrl “/styles/sps.css"
End Function
Sub GetUrl(strURL, strPage)
RANDOMIZE
‘usernumber can be changed to your preference
F = INT(200 * RND)
Test.GetCurrentUser
tStart = Timer()
Set oResponse = Test.SendRequest(strURL)
tFinish = Timer()
Test.GetNextUser
End Sub
Sub GetLastModifiedUrl(strURL)
‘Open a new connection to the Web server
dim oConnection
Set oConnection = Test.CreateConnection(SERVERNAME, 80, False)
If (oConnection Is Nothing) Then
Test.Trace(“Error: Unable to create connection."&Servername)
Else
’Create a new Request
Set oRequest = Test.CreateRequest
Set oUser = Test.GetCurrentUser
Chapter 9:
Capacity Planning
235
’ Set Request properties
oRequest.Verb = “GET”
oRequest.Path = strURL
’ you can modify the date to your preference
Call oRequest.Headers.Add(“If-Modified-Since", “Wed, 2 Apr 2003 02:39:00 GMT”)
’Send the request
Set oResponse = oConnection.Send(oRequest)
end if
End Sub
Summary
This chapter has provided you with the information necessary to plan, purchase,
and test a SharePoint Portal Server installation in your organization. In the following
chapters, you will learn how to build, customize, and manage your SharePoint Portal Server solution. Remember to always plan realistically based on your users’ needs
and test your installation for capacity before deploying it into production. Take the
operations-per-second number you developed during planning by using the algorithm provided and compare this to the RPS number you achieved during testing.
Make sure that the RPS number is higher than the required operations-per-second
number. This will help ensure a successful deployment.
Chapter 10
Performance Monitoring in
Microsoft Office SharePoint
Portal Server 2003
In this chapter:
Monitoring Server Farm Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237
Microsoft SQL Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244
Logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244
Usage Analysis Processing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246
Operation Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269
After your intranet is up and running, changing conditions might require you to scale
out the server farm. This chapter provides guidance on when and how to scale out. It
provides information about how to monitor critical performance counters and analyze
log data to determine the best scale-out strategy based on server farm behavior. It provides information about adding Web servers, search servers, and index servers. It also
addresses strategies for splitting search indexes to improve search performance and for
adding a dedicated Microsoft Windows SharePoint Services–based server farm.
Monitoring Server Farm Performance
This section describes the most important performance counters for gauging server
farm performance and deciding how to scale out your server farm. However, it does
not address scale-out issues related to custom Web Parts or applications. A scenario
that employs custom code might require additional monitoring or change the interpretation of performance counters.
By monitoring a server’s performance on a regular basis, you can recognize
trends as they develop and prevent performance problems. Monitoring also helps
237
238
Part III: Planning and Deployment
you decide when to upgrade hardware and whether upgrades are actually improving the server’s performance.
Use Microsoft Windows Server 2003 System Monitor and Performance Logs and
Alerts to monitor the counters described in this chapter. For more information about performance monitoring, including counters, logs, alerts, and Windows Server 2003 System
Monitor best practices, see “Monitoring Performance” in Windows Server 2003 Help.
General Counters
Table 10-1 lists the general performance counters that should be monitored for all
SharePoint Portal Server–based servers as part of your normal monitoring strategy.
Regular monitoring of these counters helps you understand the general health of the
servers. Some of these counters are also key indicators that can help determine how
and when to scale out the server farm.
Table 10-1
General Server Performance Counters
Object
Counter
Threshold
Description
Processor
Percent processor time_total
80 to 85 percent averaged
over three intervals.
The total percentage of processor
usage for a server.
Network
interface
Bytes total per
50 percent of the available network The rate at which bytes are sent
second_network interface bandwidth—for example, and received over each network
interface
a 100-MB network interface runadapter.
ning at 50,000 KB per second.
Logical
disk
Percent idle
20 percent over idle time_.
time_ (drives C:,
D:, and so on)
Reports the percentage of time during the sample interval that the disk
was idle. If this value is very low,
the logical disk is very busy.
Paging
file
Percent usage
Above 70 percent.
Review this value in conjunction with
memory—available megabytes and
page faults per second—to understand paging activity on the server.
Memory
Available MBs
128 MB—assuming 2 GB of RAM
as prescribed on servers.
The amount of physical memory, in
MBs, immediately available for allocation to a process or for system use
on the server.
Memory
Page faults
per second
20.
A high rate of page faults indicates a
lack of physical memory.
System
Processor
queue length
The number of CPUs + 1.
Exceeding the threshold indicates
that the processors are not fast
enough to process requests as they
occur and that you are running out
of processor power.
Through ongoing monitoring,
trends begin to emerge that
equate requests per second
with CPU consumption.
The number of requests executed per
second; this roughly equates to the
number of HTTP pages per second.
ASP.NET
Requests per
applications second_total
Chapter 10: Performance Monitoring in Microsoft Office SharePoint Portal Server 2003
239
SharePoint Portal Server Counters
Each type of server—index, search, and front-end Web—has performance counters
specific to its function in the server farm. This section lists the counters that should be
analyzed for each server type to determine how and when to scale the server farm.
Front-End Web Servers—Large Server Farm
Analyze the counters in Table 10-2 to determine when to add a new dedicated
front-end Web server to a large server farm. When the counters continuously
approach or exceed any of the thresholds in Table 10-2, you should consider adding another dedicated front-end Web server to the server farm. However, you
should also check the general counters in Table 10-1 to better understand the
server’s performance.
Table 10-2
Performance Counters for Dedicated Front-End Web Servers
Object
Counter
Threshold
Description
Processor
Percent processor
time_total
80 to 85 percent averaged
over three intervals.
The total percentage of processor
usage for a server.
ASP.NET
applications
Requests per
second_total
Through ongoing monitoring,
trends begin to emerge that
equate requests per second
with CPU consumption.
The number of requests executed
per second; this roughly equates
to the number of HTTP pages per
second.
Web service
Get requests per
second_total, individual portal, or
IIS Virtual root
Through ongoing monitoring,
trends begin to emerge that
equate get requests per second
with CPU consumption.
Generally speaking, this is the rate
at which clients are requesting
information from the front-end
Web servers.
Leading Indicators for Front-End Web Servers
The counter percent processor time is the leading indicator of front-end Web
server performance. You should sample percent processor time every 15 minutes; if
it exceeds the indicated threshold on average, consider adding an additional frontend Web server. If your customer has very high performance expectations, you
might need to establish a lower average threshold.
The value that requests per second reaches while percent processor time is at
the threshold indicates the approximate maximum throughput for the server. Adding
a front-end Web server should add this amount of capacity to the server farm.
Impact of Windows SharePoint Services Sites
Be sure to take into consideration the impact of extensive front-end traffic to
Microsoft Windows SharePoint Services sites. If some of your Windows SharePoint
Services sites are generating significant front-end traffic, you might want to scale out
one or more of those sites to a separate server farm, as discussed in the “Dedicated
Windows SharePoint Services Server Farm” section later in this chapter.
240
Part III: Planning and Deployment
Front-End Web/Search Servers—Medium Server Farm
Table 10-3 lists the most important counters for evaluating the performance of a
front-end Web server with the search component in a medium server farm.
Table 10-3
Performance Counters for Front-End Web/Search Servers
Object
Counter
Threshold
Description
Processor
Percent processor
time_total
80 to 85 percent averaged
over three intervals.
The total percentage of processor
usage for a server.
Search
Query rate
10 per second.
The number of queries posted to
the server per second; keep in
mind that in the medium server
farm configuration, the front-end
servers are doing much more than
searching.
Search
Succeeded
queries
This counter should be used
mostly for troubleshooting
search problems.
The number of queries that produce successful searches. Monitor
this counter along with the failed
queries counter if you need to
troubleshoot search problems.
Search
catalogs
Number of
documents
Microsoft has tested up to
5 million documents per
content index.
The total number of documents
in the catalog.
Search
catalogs
Queries rate_
(index names or
all instances)
Indicates which catalogs
are searched most often
by users.
The number of queries posted to
indexes per second; in conjunction
with other performance data, this
can help determine if your index
configuration can be optimized.
Web service
Get requests per
second_total, individual portal, or
IIS virtual root
Through ongoing monitoring,
trends begin to emerge that
equate get requests per second
with CPU consumption.
Generally speaking, this is the rate
at which clients are requesting
information from the front-end
Web servers.
ASP.NET
applications
Requests per
second_total
Through ongoing monitoring,
trends begin to emerge that
equate requests per second
with CPU consumption.
The number of requests executed
per second, which roughly
equates to the number of HTTP
pages per second.
Leading Indicators for Front-End Web/Search Servers
If the search catalog size exceeds 5 million documents, you must add an additional
front-end Web/search server or move the indexing service to one or more dedicated
Index servers. As the number of documents approaches 5 million, propagation and
crawling times become unacceptably long.
The value that requests per second reaches while percent processor time is at
the threshold indicates the approximate maximum throughput for the server. Adding
a front-end Web server should add this amount of capacity to the server farm.
Chapter 10: Performance Monitoring in Microsoft Office SharePoint Portal Server 2003
241
Separating the Effects of Searching from Other Front-End Traffic When deciding
to scale out front-end Web/search servers, you must determine how much of the
CPU load is the result of search operations. As a rule of thumb, when the query rate
counter exceeds the indicated threshold and search operations are consuming about
40 to 50 percent of the overall server capacity, you should consider scaling out to a
large server farm. If the query rate is below the threshold but percent processor time
is exceeding the threshold, front-end Web traffic is bringing the server to capacity
and you should consider adding an additional front-end Web/search server to the
medium server farm.
Be sure to take into consideration the impact of extensive front-end traffic to
Windows SharePoint Services sites. If some of your Windows SharePoint Services
sites are generating significant front-end traffic, you might want to scale out one or
more of those sites to a separate server farm, as discussed in the “Dedicated Windows SharePoint Services Server Farm” section later in this chapter.
Other Factors That Influence Search Performance Keep in mind that other factors can cause heavy search loads—for example, a large content index (which can
slow down search performance) or heavy search query executions against a single
portal in a shared services farm. Make sure that user expectations for search performance are realistic for your environment. Your customer’s requirements for search
response times, including commitments to service-level objectives that define specific
response times for searches, can necessitate adding a server before the thresholds
have been exceeded.
Dedicated Search Servers—Large Server Farm
Table 10-4 lists the most important counters for evaluating the performance of a dedicated search server in a large server farm.
Table 10-4
Performance Counters for Dedicated Search Servers—Large Server Farm
Object
Counter
Threshold
Description
Processor
Percent processor
time_total
80 to 85 percent averaged
over three intervals.
The total percentage of processor
usage for a server.
Search
Query rate
20 per second.
The number of queries posted to
the server per second. Keep in
mind this counter should be
watched on the dedicated search
servers.
Search
Succeeded
queries
This counter should be used
mostly for troubleshooting
search problems.
The number of queries that produce successful searches; monitor
this counter along with the failed
queries counter if you need to
troubleshoot search problems.
242
Part III: Planning and Deployment
Table 10-4
Performance Counters for Dedicated Search Servers—Large Server Farm
(continued)
Object
Counter
Threshold
Description
Search
catalogs
Number of
documents
Microsoft has tested up to
5 million documents.
This counter identifies the total
number of documents in the
catalog.
Search
catalogs
Queries rate_
(index names or
all instances)
Indicates which indexes are
most searched by users.
The number of queries posted to
indexes per second. In conjunction with other performance data,
this counter can help determine if
your index configuration can be
optimized.
Web service
Get requests per
second_total, individual portal, or Windows SharePoint
Portal Services site
With ongoing monitoring,
trends emerge that equate
requests per second with
CPU consumption.
Generally speaking, this is the
rate that clients are requesting
information from the front-end
Web servers.
Leading Indicators for Search Servers
When the percent processor time or query rate counters approach the indicated
thresholds, consider adding a search server to the server farm. In addition, if the
search catalog size exceeds 5 million documents, you must add a search server. As
the number of documents approaches 5 million, propagation and crawling times
become unacceptably long.
Evaluating search performance involves more than simply monitoring the
counters in Table 10-4. For more information, see the “Other Factors That Influence
Search Performance” section earlier in this chapter.
Scale-Out Limitations for Search Servers You can have no more than four search
servers per server farm.
Index Servers
Table 10-5 lists the most important counters for evaluating the performance of an
index server in a large server farm.
Table 10-5
Performance Counters for Index Servers—Large Server Farm
Object
Counter
Threshold
Description
Processor
Percent processor
time_total
80 to 85 percent averaged
over three intervals.
The total percentage of processor
usage for a server.
Search indexer
catalogs
Number of
documents
Microsoft has tested up to
5 million documents.
The number of documents in the
catalog.
Search indexer
catalogs
Index size MB
20 GB.
The current size of index data in
megabytes.
Chapter 10: Performance Monitoring in Microsoft Office SharePoint Portal Server 2003
243
Leading Indicators for Index Servers
The key performance thresholds for index servers are 80 to 85 percent processor
time and 85 percent memory availability. However, the decision to add an index
server is more a function of indexing and propagation time than of monitoring performance counters. When indexing and propagation cannot proceed fast enough to
keep content indexes as up to date as your customer’s business requirements
demand, you should add another index server. For example, if it takes two hours for
an incremental crawl and propagation when you need half-hour updates, consider
adding an index server.
Factors Influencing Index Server Performance
Depending on business requirements, it might be acceptable to have as many as
5 million documents in one content index, but if the rate of change is high and alerts
are popular, you might need two or three index servers for that data. Performance
of an index server also depends on the location of the crawled content and the processing power of the index server. Crawl times depend on many factors, including
the following ones:
■
Content location and network performance. Content location and network performance are related. For example, when crawling content outside of
your corporate LAN, performance might slow down. Crawling sites within your
intranet with adequate bandwidth is generally faster.
■
Type of documents in the index. You might be crawling sites that contain
a variety of document types, such as Microsoft Word, Excel, or Visio, in
addition to HTML files. Some file types are more resource intensive than
others.
■
Frequency and type of content index updates. The update schedule can
be as frequent as a weekly full update with an incremental crawl every 15 minutes or something much less aggressive. You might be able to improve indexing performance by adjusting your crawling schedule to crawl less frequently
if this can be done without affecting your ability to meet the business
requirements.
Scale-Out Limitations for Index Servers
If your existing architecture is a medium server farm, adding an index server
requires that you scale to a large server farm. This also requires the implementation
of two dedicated search servers, which is the minimum supported configuration for
a large server farm.
Microsoft recommends no more than four index servers per large server farm.
244
Part III: Planning and Deployment
Advantages of Adding an Index Server
lowing advantages:
Adding an index server provides the fol-
■
It gives you the ability to crawl more content more quickly.
■
It enables you to separate your content indexes onto separate index servers
based on your customer’s specific indexing requirements. For example, you
can separate internal content indexes from external content indexes.
■
It enables you to use a separate index server for crawling specific content
sources that require much more frequent indexing than other content sources.
Dedicated Windows SharePoint Services Server Farm
Monitor the Internet Information Services (IIS) logs to determine the amount of traffic going to the Windows SharePoint Services sites in the server farm. If you discover
a large amount of traffic going to one or more Windows SharePoint Services sites,
consider moving the busy sites to a dedicated Windows SharePoint Services server
farm. If you see trends from ongoing monitoring that indicate your Windows SharePoint Services site traffic is increasing and will continue to increase, a separate dedicated Windows SharePoint Services site might be the best scaling option. You can
elect to move one or more—or all—of the busiest Windows SharePoint Services site
collections to a separate, dedicated Windows SharePoint Services server farm.
Separating one or more Windows SharePoint Services site collections to a dedicated server farm frees up resources on the front-end Web servers that are dedicated to supporting the corporate and divisional portals. It also enables you to
independently scale out the dedicated Windows SharePoint Services server farm.
Microsoft SQL Server
The percent processor time counter is the leading indicator for Microsoft SQL Server
performance. Examine percent processor time in conjunction with overall memory
capacity, network traffic, and input/output (I/O) subsystem capacity.
Logs
Monitoring system performance in conjunction with IIS logs and SharePoint Portal
Server Usage Analysis logs provides more in-depth information about how your sites
are being used. Windows Server 2003 System Monitor helps you to understand
resource consumption on a per-server basis. The logs provide in-depth Web traffic
analysis data, such as which sites are most heavily used and by whom, how many
visitors use the sites, and peak periods of activity.
Chapter 10: Performance Monitoring in Microsoft Office SharePoint Portal Server 2003
245
Internet Information Services (IIS) Logs
IIS logs include detailed information, such as who has visited sites and what was
viewed, in terms of total visits, average visits, page views, and trends over time.
Careful analysis of the IIS logging data helps you to discover how much traffic is
going to portal sites, how much is going to Windows SharePoint Services sites, and
how much is going to search operations.
You can use IIS log data to help identify bottlenecks and performance issues.
More importantly, you can use this data to identify the SharePoint Portal Server and
Windows SharePoint Services sites that are used most often. This information helps
you to understand the impact of Windows SharePoint Services sites on your frontend Web server traffic and to decide when to move one or more site collections to
a dedicated Windows SharePoint Services server farm.
Setting Up Log Files
Set the logs to be created on a daily basis, which creates a new log file each day for
each virtual server.
Set up SharePoint Portal Server to place the log files on a hard drive separate
from the one that contains the operating system (drive C). Ensure that the local
Administrators group and the IIS_WPG group have the appropriate permissions to
access the log files directory.
Within the Logfiles directory, IIS creates a separate directory for each IIS virtual
server log, with naming based on the virtual server instance number.
To view the directory and log file name for each virtual server through IIS Manager, follow these steps:
1. Right-click a virtual server, click Properties, and then select the Properties
button next to Active log format.
2. The Log File name is displayed at the bottom of the screen.
Reading the Log File Data
The IIS logs are ASCII files that can be read using a text editor, but third-party utilities
are typically used to analyze IIS logs and generate meaningful, formatted reports and
graphical representations of usage data. How the IIS logging information is presented
and accessed depends on the third-party tool used to present the IIS log data. You can
also use Microsoft Commerce Server Web Analytics to gain this information.
IIS log files can also be logged in a database that complies with Open Database
Connectivity (ODBC), such as a Microsoft SQL Server database, and SQL Server Query
Analyzer can be used to generate reports. For more information about configuring
IIS logs to an ODBC database, see “Log File Formats” at http://www.microsoft.com
/technet/prodtechnol/windowsserver2003/proddocs/standard/log_aboutlogging.asp.
246
Part III: Planning and Deployment
Configuring the Log Files
IIS logging is enabled by default for each virtual server. The recommended log file
format is W3C, which is the default. This enables you to specify which fields are
included in the log file. By limiting logging to the W3C fields that are most important
to your customer, you can limit the log file size and simplify the analysis. Depending
on the amount of traffic to your sites, the size of your log files can begin to consume
valuable memory resources and CPU cycles. You need to balance the gathering of
detailed data against the need to limit IIS log files to a manageable size and number.
The following W3C log file fields are the most important for analyzing Web
traffic for scale-out decisions:
■
User name.
■
Server IP address.
generated.
■
Server port.
■
Method. The action the client was trying to perform—for example, a GET request.
■
URI stem. The resource accessed, such as an HTML page, a Common Gateway Interface (CGI) program, or a script (the most relevant resource for a scaling
decision).
■
URI query. The query, if any, the client was trying to perform. One or more
search strings that the client was seeking to match are recorded.
■
Protocol status.
■
Protocol substatus.
■
Win32 status.
The name of the user who accessed the server.
The IP address of the server on which the log entry was
The port number to which the client is connected.
The status of the action, in HTTP terms.
Records additional status of the action, in HTTP terms.
The status of the action, in Windows operating system terms.
More Info For a complete list of W3C log file fields, visit http://www
.microsoft.com/technet/prodtechnol/windowsserver2003/proddocs/standard
/log_customw3c.asp.
Usage Analysis Processing
Usage analysis processing provides usage reports on Windows SharePoint Services
sites. This information can help you to determine which Windows SharePoint Services sites and subsites receive the most visitors.
Usage analysis data is taken from the IIS logs on the front-end Web servers and
gathered into temporary files. When usage analysis processing takes place, the logs
are merged into the content databases on the computer running SQL Server. For
more information, see “Configuring Usage Analysis” in the online SharePoint Portal
Server 2003 Administrator’s Guide.
Chapter 10: Performance Monitoring in Microsoft Office SharePoint Portal Server 2003
247
Usage analysis processing is disabled by default.
To enable usage analysis processing for all virtual servers in the server farm,
follow these steps:
1. Click Site Settings.
2. Click Go to Central Administration.
3. Under Component Configuration, click Configure usage analysis processing.
4. Select Enable logging.
5. Specify a location for the usage analysis log files. The default location is
\systemroot\system32\logfiles\STS. Within this directory, Usage Analysis Processing creates a folder for every virtual server, named according to the IIS virtual
server instance number. Within each virtual server folder, Usage Analysis
Processing creates a folder for each day.
6. Enter the number of log files to create, from 1 to 30. It is recommended that
you set this number to be equal to the number of virtual servers on the frontend Web servers in the server farm. Splitting usage data into many smaller files
rather than placing it into one big file reduces the amount of memory required
to process all the usage data log entries.
7. Creating and updating the logs is processor intensive, so set processing to take
place when site usage is low—for example, between 1:00 A.M. and 4:00 A.M.
Note Give the STS_WPG group read, write, and update permissions to the
directory. Without these permissions, IIS cannot create or update the logs.
Usage Analysis Processing Reports
Even though the data is logged and stored for an entire site collection, when you
view the data in HTML Administration pages, you can see the usage analysis data for
a particular Windows SharePoint Services site or subsite but not for the entire site
collection. A summary of the entire site collection usage is available from the toplevel website for each site collection. Although you can see the total number of hits
for an entire site collection, to see detailed information you must use the Site Usage
Report page for the individual site or subsite.
Site usage reports are useful for identifying which content on your Windows
SharePoint Services sites is being heavily used or used very little. This helps you to
understand which sites are candidates for archiving and which sites should be kept
online. In addition, the site collection usage reports help you track how much storage space your sites are using. This information is gathered as part of the quota
tracking for Windows SharePoint Services sites.
For more information about viewing and analyzing usage analysis data, see “Analyzing Web Site Usage” in the online SharePoint Portal Server 2003 Administrator’s Guide.
248
Part III: Planning and Deployment
To view site usage data for a single site, follow these steps:
1. Navigate to the Windows SharePoint Services site and then click Site Settings.
2. Click Go to Site Administration.
3. Under Management and Statistics, click View site usage data. The Site
Usage Reports page provides a report that contains the following information:
■
The pages that have been accessed on that site, including document libraries
■
The users that have accessed the site
■
The operating system of the user accessing the site
■
The browser type
■
The referrer URL
■
Data that can be displayed by monthly summary or daily summary
■
A site-usage summary for an entire site collection
4. Navigate to the top-level website, and select Site Settings.
5. Select Go to Site Administration.
6. Under Site Collection Administration, select View Site Collection Usage
Summary. This provides a summary of the entire site collection usage.
To better understand what might be the bottleneck of the portal, it makes
sense to check for several counters on the different servers. We can divide the
counters in three different groups, as shown in Table 10-6.
Table 10-6
Counters by Platform
Platform
Counters
Client-Side Counters
Processor(_Total)\% Processor Time
Windows 2003 and IIS Counters
File Cache Flushes/Hits
ASP.net Application Restarts
ASP.net Requests/Second
ASP.net Requests Queued
ASP.net Requests Rejected
ASP.net Request Wait Time
Processor(_Total)\% Processor Time
Memory\Pages/sec
System\Context Switches/sec
Process(inetinfo)\% Processor Time
Process(inetinfo)\Working Set
Process(w3wp)\% Processor Time
Process(w3wp)\Working Set
Process(LSASS)\% Processor Time
Memory\Pages/sec
Chapter 10: Performance Monitoring in Microsoft Office SharePoint Portal Server 2003
Table 10-6
Counters by Platform
249
(continued)
Platform
Counters
SQL Counters
Memory\Pages/sec
System\Context Switches/sec
Process(sqlservr)\% Processor Time
Process(sqlservr)\Working Set
SQLServer:General Statistics\User Connections
SQLServer:Databases\Transactions/sec
SQLServer:Locks\Number of Deadlocks/sec
SQLServer:Locks\Lock Waits/sec
SQLServer:Locks\Lock Wait Time (ms)
SQLServer:SQL Statistics\Batch Requests/sec
Operation Management
Hardware redundancy is an important element for high availability, but ongoing
health monitoring is required to guarantee that this redundancy remains intact. For
example, if one of the front-end Web servers fails and this failure remains undetected,
it jeopardizes the high availability of the Web servers. Ongoing health monitoring and
failure detection are vital to meeting the high availability goals of the infrastructure.
This part of this chapter focuses on the incident and performance aspects of
managing the healthy operation of the architecture. These aspects include the following items:
■
Incident, or fault, management. Fault detection, fault registration, fault assignment, and fault resolution.
■
Performance management. Network and server capacity planning, availability, response time, throughput, and utilization. Statistics collection tools,
traffic modeling techniques, and service probes are required to ensure that service level agreements are fulfilled.
Architectural Components
SharePoint Portal Server is a distributed application framework that uses multitier
architecture. These components can be grouped as follows:
■
Hardware
■
Network infrastructure
■
Operating system
■
SharePoint Portal Server components
250
Part III: Planning and Deployment
Healthy operation requires that you monitor each component and alert system
administrators of problems. Most large enterprises already have policies in place for
managing hardware, networks, and operating systems. The SharePoint Portal Server
architecture does not introduce any new considerations with regard to those items.
Monitoring and Alerting Requirements
The more distributed an environment is, the more it requires monitoring. Failure to
monitor the status of the architecture results in a reactive administrative model in
which action is taken only after the problem has become serious enough for users
to report it. The monitoring solution for this architecture provides a proactive administrative model in which problems are automatically detected before they escalate to
a level that affects the system. To meet this aim, you should be aware of general
monitoring principals and critical elements that need to be monitored.
It is imperative that alerts be used to bring any failure to the immediate attention of the system administrator so that it can be rectified. If this is not done, the
infrastructure can slowly decay until it affects the performance of the website.
The monitoring and alerting infrastructure can also benefit scalability. Defining
alerts based on system usage makes it possible to be proactive and start scaling the
environment before users are affected. For example, an alert can be triggered when
processor utilization on the Web servers is consistently above a preset limit. This can
provide an indication that more servers or upgraded server hardware are required.
The following topics discuss several fundamental monitoring principles.
Monitoring Unobtrusively
A poorly designed or poorly implemented monitoring strategy can adversely affect
system performance or operation. In general, the monitoring solution should have
as minimal an impact as possible on the system it is monitoring, while providing all
relevant information.
For example, when using a probe, it is sufficient to retrieve a single entry,
which indicates that the server is functional, instead of retrieving multiple entries.
The system should be probed only as often as absolutely necessary to provide adequate responsiveness. This limits the additional burden on the servers and applications. Probing a system too soon and too often returns failure data sooner, but it can
place an obtrusive burden on the services.
Avoiding Cascading Failures
If a failure occurs, it can trigger other alerts in the monitoring solution. For example,
if one set of servers running Internet Information Services (IIS) fails, this might place
an additional load on the remaining servers, in turn generating alerts from those
servers. If this happens, you should disable noncritical services or applications to
reduce the load on the remaining servers. You should also evaluate system capabilities to proactively provide extra system capacity in case the problem recurs.
Chapter 10: Performance Monitoring in Microsoft Office SharePoint Portal Server 2003
251
Maintaining a Problem History
You should design the monitoring solution to provide an accurate history of events
and problems. For example, if the network management and monitoring system logs
events in a standard format, the IIS-related entries can be periodically extracted, compiled, and archived in a central location for periodic review later. These extracted logs
provide critical trend data that can be used to perform the following tasks:
■
Identify recurring problems.
■
Support capacity planning.
■
Provide summary information about reliability and availability.
You should consider maintaining an issue log to track problems and solutions
for future reference. If a problem recurs, future users can see how it was previously
resolved.
Maintaining a Written Plan
You need a written plan that provides timely, accurate, consistent, and reusable
responses for every failure, event, or problem. Executing a consistent plan for
addressing recurring events helps avoid wasting time, resources, and money.
Using Effective Notification Techniques
Actively capturing real-time event information is useful only if the responsible parties are notified to implement the action plan. Event notification accomplishes the
following four important goals:
■
It notifies the parties responsible for fixing the problem.
■
It notifies the parties responsible for administration of the system.
■
It notifies the parties affected by the event. Users do not need to know the
details of the problem, but they need to know if there is an interruption, or
anticipated interruption, and when the problem will be resolved.
■
It notifies each party to take appropriate action.
After you have captured an event and have notified the responsible people,
you should do the following:
■
Minimize the impact of the problem.
■
Perform a root-cause analysis to determine the exact nature of the problem.
■
Correct the problem.
■
Create a plan for providing a long-term solution and a reusable action plan
should the event recur.
252
Part III: Planning and Deployment
Monitoring Performance Counters
Most large enterprises have some tools in place for monitoring hardware, software,
and applications. Many of these products provide a central interface for monitoring
and sending alerts to system administrators to notify them of hardware component
failures and loads exceeding thresholds.
Microsoft products such as Microsoft SQL Server 2000, IIS 6.0, and SharePoint
Portal Server 2003 include SNMP Management Information Bases (MIBs), which
make this monitoring possible. An MIB is a set of objects that represent information
about a device. The MIBs store the performance counter results, which are readable
through Windows Server 2003 System Monitor (known as Performance Monitor in
Microsoft Windows 2000).
Certain critical performance counters provide early indicators of loads
approaching thresholds or irregular load behavior. This chapter provides an extensive list of available performance counters.
More Info For more information about how you can log performance
counters, see Windows Server 2003 Help and Support Center and search
for “monitoring server performance.” You can access the Windows Server
2003 Help and Support Center by pressing the F1 key.
Microsoft Operations Manager
Microsoft Operations Manager delivers enterprise-class operations management by
providing comprehensive event management, proactive monitoring and alerting,
reporting, and trend analysis. The Application Management Pack, which is the product support knowledge base included in Microsoft Operations Manager, helps you
reduce the day-to-day support costs associated with running applications and services in a Windows-based environment.
The Microsoft Office SharePoint Portal Server 2003 management pack module
monitors events placed in the Application event log. The module highlights events
that indicate possible service outages or configuration problems so that you can
quickly take corrective or preventative actions. For example, the management pack
module alerts you of the following critical conditions:
■
Data backup or restore failures
■
Core services, such as search, alert notifications, and administration, failures
■
Content source update failures
■
Search propagation of one or more content indexes failures
■
Audience compilation or profile import failures
Chapter 10: Performance Monitoring in Microsoft Office SharePoint Portal Server 2003
253
Hardware Monitoring
To maintain server uptime, systems must operate within closely controlled environmental conditions. Otherwise, system components fail at a greater rate than they
would under normal operating conditions. Therefore, it is important to monitor the
following elements:
■
System temperature. The status of the thermal environment, which might
move out of an acceptable range because of a failed system fan, opened computer hood, or high temperature in the external environment.
■
System fan status.
temperature.
■
UPS battery condition.
supply (UPS).
■
System reboot status.
■
Disk and array status. The status of system drives and arrays, such as hard
and recovered read errors, seek errors, and data request timeouts.
■
SCSI status. The status of Small Computer System Interface (SCSI) systems,
such as SCSI seek errors, timeouts, and read errors; Array Controller prefailure
events; and tape rewrites, rereads, and noncorrectable tape errors.
■
NIC status. Packets received and transmitted with errors and packets discarded.
The system and CPU fan, which affects the system
The battery low status of the uninterruptible power
The server’s condition and reboot counts.
Some hardware vendors provide hardware management agents with defect
detection and alerting features. Depending on the specific vendor implementation,
you can tightly integrate the hardware management agents into Microsoft Operations
Manager (MOM) or other third-party monitoring products that support standard
SNMP MIBs. The ability to tightly integrate the various hardware-specific management agents into monitoring and alerting products is a major strength of operation
management. When selecting the server hardware, evaluate the management facilities offered by the server vendor and determine how well they can be integrated
into your overall solution.
The accelerator architecture has been tested on Hewlett-Packard ProLiant
servers that are equipped with the Insight Manager tool. Insight Manager provides
in-depth fault and performance management of ProLiant servers. Prefailure
alerts provide notification of potential failures before they result in unplanned
downtime. Remote Insight Lights-Out Edition speeds up problem diagnosis and
resolution.
More Info For more information about Insight Manager, see the HewlettPackard Web page at http://www.compaq.com/manage.
254
Part III: Planning and Deployment
Network Infrastructure
The following topics summarize the dependencies between SharePoint Portal
Server 2003 and these network infrastructure components:
■
DNS server
■
Proxy servers
■
Network traffic
■
Network Load Balancing
■
Windows Server 2003
■
SharePoint Portal Server counters
■
Front-end Web servers
■
System performance counters
■
Application performance counters
■
Search servers
■
SQL Server–based servers
DNS Server
Each portal requires a host entry in DNS. This can be a server name or a host header
name for virtual websites. These entries in DNS define the URLs that allow end users
to access the portal. The performance counters for the DNS server are the same as
those for the Windows operating system. (See Table 10-1 for details.)
Proxy Servers
If you specify content sources that require crawling other websites, make sure that
the proxy settings are defined correctly in the Content Source configuration.
Network Traffic
The logical grouping of services to a virtual local area network (VLAN) enables a
service group to make intensive use of a network segment. The services assigned to
a VLAN are contained to just the allowed segments, based on access control lists
(ACLs). Using ACLs ensures that one group does not affect the work of other groups.
The VLAN configuration improves general network performance by not slowing
down other groups that share the network.
Monitor the network traffic in the server farm subnet. If the subnet is too congested, you might consider hosting the front-end Web servers in a subnet different
than that for back-end servers, such as SQL Server–based servers, index servers, and
search servers.
Chapter 10: Performance Monitoring in Microsoft Office SharePoint Portal Server 2003
255
In addition, consider adding a separate subnet for online backup and restore
and monitoring by adding additional NICs to each server to reduce the network traffic on the VLAN that carries the end-user access traffic.
You can measure the traffic in the network by checking the SNMP MIBs of
interface devices, calculated as total bytes per second.
Network Load Balancing
Event log records provide crucial information that can help you analyze and solve
problems. Use the nlb.exe display command to display the most recent event log
records produced by Network Load Balancing. For more information, see Chapter 4,
“Windows SharePoint Services Architecture.”
Windows Server 2003
Windows Server 2003 comes with tools for monitoring various services, including
the Active Directory directory service. This information assists you in determining
when the directory service is experiencing a problem as a result of the operating
system. Windows Server 2003 probes are used across all servers to provide information about the status of the operating system.
Table 10-7 shows the most important operating system performance counters.
You can observe these counters by using Windows Server 2003 System Monitor.
Table 10-7
Performance Counters and Thresholds for Windows Server 2003
Object
Counter
Logical
disk
Free megabytes
Logical
disk
Interval/
minutes
Threshold
Description
15
Less than
10 percent
of logical
disk size.
Shows unallocated disk space. If this
threshold is met, the system is running
out of available disk space.
% free space
15
15 percent.
Shows unallocated disk space. If this
threshold is met, the system is running
out of available disk space.
Logical
disk
% disk time
15
90 percent.
% disk time is the percentage of elapsed
time that the selected disk drive was busy
servicing read or write requests.
Physical
disk
Disk reads/sec,
Disk writes/sec
15
Depends on
manufacturer’s
specifications.
Checks the specified disk transfer rate to
verify that this rate does not exceed the
specifications. In general, Ultra Wide SCSI
disks can handle 50 to 70 I/O operations
per second.
Physical
disk
Current disk
queue length
1
Number of
spindles
plus 2.
This is an instantaneous counter. Observe
the value over several intervals. For
an average over time, use physical
disk\average disk queue length.
256
Part III: Planning and Deployment
Table 10-7
Performance Counters and Thresholds for Windows Server 2003
(continued)
Object
Counter
Interval/
minutes
Threshold
Description
Memory
Available MB
15
4 MB.
If this threshold is met, the system has run
out of available memory. Imminent service
failure is likely.
Memory
Page
faults/sec
5
20 faults/sec.
A high rate of page faults indicates a lack
of physical memory.
Network
segment
% net
utilization
15
Depends
on type of
network.
Determine the threshold based on the
type of network. For Ethernet, 30 percent
is the recommended threshold.
Paging file
Paging
file % usage
15
Above
70 percent.
Review this value in conjunction with
available bytes and pages/sec to understand paging activity.
Processor
% DPC time
total
15
10 percent of
all processor
work deferred.
Indicates work that was deferred because
the server was too busy. Possible processor
congestion.
Processor
% processor
time
1
85 percent
averaged over
three intervals.
Identifies processes that are using a high
percentage of processor time. Upgrade to
a faster processor, or install an additional
processor.
Processor
Interrupts/sec
5
Depends on
processor. For
current CPUs,
use a threshold
of 1500 interrupts per
second.
A dramatic increase in this counter value
without a corresponding increase in system
activity indicates a hardware problem.
Identify the network adapter or disk controller card causing the interrupts. It might
be necessary to install an additional
adapter or controller card.
Server
Bytes
total/sec
5
Dependent
on network
topology.
If the sum of bytes total/sec for all servers
is roughly equal to the maximum transfer
rates of the network, it might be necessary
to segment the network.
Server
Work item
shortages
1
3 shortages.
If the value reaches this threshold, consider
tuning the InitWorkItems or MaxWorkItems
entries in the registry. For more information about this topic, search the Microsoft
Knowledge Base using the keyword
“MaxWorkItems.”
See the Caution following this table
regarding editing the registry.
Server
Queue
length
5
4.
If the value reaches this threshold, there
might be a processor bottleneck. This is
an instantaneous counter. Observe the
value over several intervals.
Chapter 10: Performance Monitoring in Microsoft Office SharePoint Portal Server 2003
Table 10-7
Performance Counters and Thresholds for Windows Server 2003
Object
Counter
System
Context
switches/sec
System
Processor
queue length
Interval/
minutes
257
(continued)
Threshold
Description
15
70,000
switches/sec.
Indicates excessive transitions. There might
be too many applications or services running, or their load on the system might be
too high. Consider offloading this demand.
1
6 averaged
over 5 intervals.
The CPU is not fast enough to process
requests as they occur. For domain controllers, if the replication topology is correct
and the condition is not caused by failover
from another domain controller, consider
upgrading the CPU.
Caution Do not use a registry editor to edit the registry directly unless
there is no alternative. The registry editors bypass the standard safeguards
provided by administrative tools. These safeguards prevent entry of conflicting settings or settings that are likely to degrade performance or damage a
system. Editing the registry directly can have serious, unexpected consequences that can prevent the system from starting and require that the Windows Ser ver 2003 operating system be reinstalled. To configure or
customize the Windows Server 2003 operating system, use the programs in
Control Panel or Microsoft Management Console (MMC) whenever possible.
More Info For more information about operating system monitoring features,
refer to the Windows Server 2003 Help and Support Center. You can access
the Windows Server 2003 Help and Support Center by pressing the F1 key.
SharePoint Portal Server Components
The following three critical SNMP MIBs must be monitored for each server in the
SharePoint Portal Server architecture:
■
Disk
■
Processor
■
Memory
These three general performance counters provide a quick indicator of server
health. These indicators should be used only when required for further investigation
258
Part III: Planning and Deployment
of system behavior or troubleshooting purposes. Table 10-8 provides details about
monitoring these performance counters.
Table 10-8
Object
Performance Counters and Thresholds for All SharePoint Portal Servers
Counter
Interval/
minutes
Threshold
Description
Logical disk Free megabytes
15
<10 percent of
Shows unallocated disk space. If this
logical disk size. threshold is met, the system is running
out of available disk space.
Memory
Available MB
15
4 MB.
If this threshold is met, the system has
run out of available memory; imminent
service failure is likely.
Memory
Page faults/sec
5
700 faults/sec.
A high rate of page faults indicates a lack
of physical memory.
Processor
% DPC
time_total
15
10 percent of
processor work
deferred.
Indicates work that was deferred
because the domain controller was too
busy; possible processor congestion.
Processor
% processor
time_total
1
85 percent busy
averaged over
3 intervals.
Indicates the CPU is overloaded. To determine if CPU load is being used by a process, examine the “% processor time –
process name” counter. Other processes
have their respective counters as well.
System
Context
switches/sec
15
70,000
switches/sec.
Indicates excessive transitions. There
might be too many applications or services running, or their load on the system
is too high. Consider offloading this
demand.
System
Processor
queue length
1
6 averaged
over 5 intervals.
The CPU is not fast enough to process
requests as they occur. If the replication
topology is correct and the condition is not
caused by failover from another domain
controller, consider upgrading the CPU.
System
System
uptime
5
Essential counter for measuring portal
server reliability.
Front-End Web Servers
SharePoint Portal Server 2003 is a Web-based .NET application that runs on an
IIS 6.0 Web server. Windows Server 2003 System Monitor is shipped with
SNMP MIBs—for .NET applications, Web Services, and IIS—that monitor system
behavior.
IIS 6.0 Application Pools
When you create a new portal and extend it to the other front-end Web servers in the
server farm, you have the option to create a new application pool or use an existing
application pool. The decision that you make has the following impacts:
Chapter 10: Performance Monitoring in Microsoft Office SharePoint Portal Server 2003
259
■
Creating a new application pool uses more memory, but it helps the stability of
the portal.
■
If you share one application pool among many portals, you have saved memory space at the cost of cascading failure to other portals if the application pool
doesn’t function properly.
It is essential that you properly configure the application pool to ensure the
health and reliability of an Active Server Pages (ASP) .NET application. All the relevant settings are found on the application pool property sheet.
IIS 6.0 distinguishes between proactive and reactive recycling. IIS performs
proactive recycling for known conditions and reactive recycling for unknown or
dynamic conditions. For proactive recycling, IIS 6.0 checks the elapsed time, the
number of requests completed, the scheduled time, and the amount of memory
used. By default, events are only logged in the application event log if the recycling
occurs based on the memory limit trigger.
Table 10-9 describes the available IIS 6.0 application pool settings, which are
accessible through the IIS MMC snap-in.
Table 10-9
Application Pool Settings for IIS 6.0
Setting
Description
Idle timeout
Controls whether IIS shuts down idle worker processes. Worker
processes serving the application pool are shut down after being
idle for the specified amount of time.
Request queue limit
Controls the size of the request queue. This setting prevents large
numbers of requests from queuing up and overloading the Web
server.
CPU monitoring
Specifies what action is to be taken if a CPU usage threshold is
reached.
Web garden
Controls the number of worker processes for the application pool.
Enable pinging
Specifies how often the Web Administration Service (WAS) pings
each worker process in the application pool to detect its status.
Enable rapid fail
protection
Configures IIS to remove the application pool from service if a
specified number of crashes occur within the specified time period.
If a worker process is removed from service, HTTP.sys responds to
any incoming request with a “503 Service Unavailable” message.
Startup time limit
Specifies the amount of time a process is allowed for startup before
IIS assumes that it has not started correctly and terminates it. Terminated processes are logged in the system event log.
Shutdown time limit
Tells the WAS how to cope with worker processes that hang during
shutdown. If a worker process has not shut down during the specified time limit, it is terminated by the WAS.
ASP.NET supports two groups of performance counters: system and application. System performance counters are exposed in Windows Server 2003 System
Monitor in the ASP.NET System performance counter object, and application performance counters are exposed in the ASP.NET Applications performance object.
260
Part III: Planning and Deployment
Note There is a significant difference between the State Server Sessions
counters found in the ASP.NET System performance object and the Sessions
counters found in the ASP.NET Applications performance object. The former
apply only to the server computer upon which the state server is running.
The latter apply only to user sessions that occur in process.
System Performance Counters
ASP.NET supports the system performance counters detailed in Table 10-10. These
aggregate information for all ASP.NET applications on a Web server computer, or
they apply generally to a system of ASP.NET servers running the same applications.
These can include Web server farms and Web gardens.
Table 10-10
System Performance Counters
Counter
Description
Application restarts
The number of times that an application has been restarted during
the Web server’s lifetime. Application restarts are incremented with
each Application_OnEnd event. This value is reset every time the
IIS host is restarted.
Applications running
The number of applications running on the server.
Requests
disconnected
The number of requests disconnected due to a communications
failure.
Requests queued
The number of requests waiting for service from the queue.
Requests rejected
The total number of requests not executed because of insufficient
server resources to process them. This counter represents the
number of requests that return a 503 HTTP status code, indicating
that the server is too busy.
Request wait time
The number of milliseconds that the most recent request waited for
processing in the queue.
Worker process
restarts
The number of times a worker process has been restarted on the
server computer.
Worker process
running
The number of worker processes running on the server
computer.
Application Performance Counters
ASP.NET supports the application performance counters detailed in Table 10-11,
which you can use to monitor the performance of a single instance of an ASP.NET
application. A unique instance appears for these counters, named __Total__, which
aggregates counters for all applications on a Web server (similar to the global counters
in Table 10-10). The __Total__ instance is always available. The counters will display
zero when no applications are present on the server.
Chapter 10: Performance Monitoring in Microsoft Office SharePoint Portal Server 2003
Table 10-11
261
Application Performance Counters
Counter
Description
Errors total
The total number of errors that occur during the execution of
HTTP requests. Includes any parser, compilation, or run-time
errors. This counter is the sum of the Errors During Compilation,
Preprocessing, and Request Execution counters.
Errors total/sec
The number of errors per second that occur during the execution
of HTTP requests; includes any parser, compilation, or run-time
errors.
Requests failed
The total number of failed requests, including requests that
timed out, requests that were not authorized (status code 401), or
requests not found (status code 404 or status code 414).
Note that the equivalent ASP counter also increments on requests
rejected, which cannot be done (because the rejection is done
by IIS and not the process model).
Requests not found
The number of requests that failed because resources were not
found (status code 404 or 414).
Requests not
authorized
The number of requests that failed due to no authorization (status
code 401).
Requests succeeded
The number of requests that executed successfully (status code 200).
Requests timed out
The number of requests that timed out.
Requests total
The total number of requests since the service was started.
Requests/sec
The number of requests executed per second.
Transactions aborted
The number of transactions aborted.
Transactions committed
The number of transactions committed.
Transactions pending
The number of transactions in progress.
Transactions total
The total number of transactions since the service was started.
Transactions/sec
The number of transactions started per second.
Search Servers
This section describes performance counters available for the following search
services:
■
SharePoint Portal Server Search service
■
SharePoint Portal Server Search Catalog content indexes
■
Index server
262
Part III: Planning and Deployment
SharePoint Portal Server Search
Table 10-12 lists the most important search server performance counters available
through Windows Server 2003 System Monitor.
Table 10-12
Search Performance Counters
Counter
Description
Current connections
The number of currently established connections between the
Search service and all clients.
Queries
Cumulative number of queries posted to the server.
Failed queries
The number of queries that have failed.
Results
The cumulative number of results returned to clients.
SharePoint Portal Server Search Catalogs
Table 10-13 lists the most important content index performance counters available
for each search catalog instance through Windows Server 2003 System Monitor.
Table 10-13
Content Index Performance Counters
Counter
Description
Current connections
The number of currently established connections between the
Search service and all clients.
Queries
Cumulative number of queries posted to the server.
Failed queries
The number of queries that have failed.
Results
The cumulative number of results returned to clients.
Number of documents
The total number of documents in the catalog.
Index size (MB)
Size of catalog data in megabytes.
Index Server
Table 10-14 lists the performance counters available for each search index.
Table 10-14
Search Index Performance Counters
Counter
Description
Number of documents
The total number of documents in the catalog.
Index size (MB)
Size of catalog data in megabytes.
SQL Server
In addition to the general performance counters and alert settings detailed previously for each server, you can capture additional counters that are SQL Server–
related, including the following:
Chapter 10: Performance Monitoring in Microsoft Office SharePoint Portal Server 2003
■
SQLServer:Databases Application Database: Log Growths
■
SQLServer:Databases Application Database: Percent Log Used
■
SQLServer:Databases Application Database: Transactions/sec
■
SQLServer:General Statistics: User Connections
■
SQLServer:Locks: Lock Waits/sec
■
SQLServer:Locks: Number of Deadlocks/sec
■
SQLServer:Memory Manager: Memory Grants Pending
263
Monitoring these elements helps to ensure that the SQL Server databases running within the portal architecture perform optimally and that any issues are dealt
with promptly. It also allows for capacity planning and performance tuning of the
environment, which enables you to provide continuous effective service.
Re-indexing Site Databases
It is critical that you re-index the site database tables after doing lots of updates, such
as updating statistics or bulk loading of profiles, documents, or lists. By re-indexing
the tables in the site database using a simple SQL script, you can improve database
performance by 5 to 25 percent.
To re-index, run the following scripts against the site databases:
■
UPDATE STATISTICS Personalization
■
UPDATE STATISTICS UserInfo
■
UPDATE STATISTICS WebMembers
■
UPDATE STATISTICS Sites
■
UPDATE STATISTICS Webs
■
UPDATE STATISTICS Lists
■
UPDATE STATISTICS WebParts
■
UPDATE STATISTICS Docs
■
DBCC DBREINDEX (Personalization, “, 0)
■
DBCC DBREINDEX (UserInfo, “, 0)
■
DBCC DBREINDEX (WebMembers, “, 0)
■
DBCC DBREINDEX (Sites, “, 0)
■
DBCC DBREINDEX (Webs, “, 0)
■
DBCC DBREINDEX (Lists, “, 0)
■
DBCC DBREINDEX (WebParts, “, 0)
■
DBCC DBREINDEX (Docs, “, 0)
264
Part III: Planning and Deployment
Establishing a Performance Baseline
Monitoring the health of the architecture requires a baseline. It also requires a clear
understanding of load factors introduced by each component of SharePoint Portal
Server 2003, such as:
■
What is the impact of the load introduced by indexing content on resources in
each server?
■
What is the impact of the load on computers running SQL Server? How do
computers running SQL Server behave under different load factors? Which
parameters are more critical?
■
How does IIS 6.0 behave under specific loads, and what can be observed on
front-end Web servers?
■
What should be expected when end users work with the portal through an
office client?
■
What is the difference between load generated by using different SharePoint
Portal Server functions, such as browsing home pages, team site creation, My
Site navigation, or uploading documents?
The IIS log and SharePoint Portal Server Usage Analysis Processing logs can
provide a realistic picture of how a portal is used in each company. Analysis of IIS
logs over time gives important information about the usage patterns of the portal. It
also provides information about what specific portal functions are used more frequently, the number of users accessing the portal, and peak-time usage of the portal
during the day. Tying this information to records collected from performance measurements of the server running SQL Server, the Index server, the Search server, and
the Web server provides a full picture of architecture behavior. With this information, you can establish a server performance baseline.
You should revise the baseline as the load on your portal changes. For example, you might define a baseline for an out-of-the-box portal installation, and as you
add more indexes or more users, define a new baseline. Compare the two to understand the impact of the load on different counters that you are monitoring. The baseline is a useful reference for capacity planning, for distribution of SharePoint Portal
services and components to the other servers, and for adding new servers to the
architecture.
Analyzing Logs
System log files can be scanned for events that indicate an error and for indications
of performance problems. Log file analysis enables you to perform proactive monitoring, in which problematic conditions and indications of impending problems are
identified before they affect customers. The following sections discuss the logs that
are available for monitoring the health of the portal architecture.
Chapter 10: Performance Monitoring in Microsoft Office SharePoint Portal Server 2003
265
Windows Server 2003 Event Logs
You can configure the level of information and types of events to be logged in Windows Server 2003 event logs. Check these event logs regularly to verify that the
required operating system, SharePoint Portal Server, and IIS are running.
More Info The .NET Framework SDK provides customizable components
for managing logs programmatically. For more information about managing
event logs using these components, see the .NET documentation about
event logs at http://msdn.microsoft.com/vstudio/using/understand/perf
/default.aspx?pull=/library/en-us/dnbda/html/exceptdotnet.asp.
SQL Server 2000 Logs
SQL Server 2000 provides logs to monitor server processes, databases, and user
activities. Checking SQL Server logs is the first step in analyzing database-related
problems. After checking logs, you can trace problems by using other tools such as
SQL Server Profiler for detailed analysis and resolution of problems.
When you create a new portal, SharePoint Portal Server creates three new databases, in addition to a configuration database that can be shared among different
portals. When these databases are created, SharePoint Portal Server allocates default
sizes for data files and transaction logs. To avoid the additional overhead added by
the auto-grow feature of SQL Server, you can increase the initial size of data and
transaction files based on your usage prediction. Continually using the auto-grow
feature of data file and transaction logs can slow down database-related activities.
IIS 6.0 and SharePoint Portal Server Usage Analysis Processing Logs
The IIS and SharePoint Portal Server Usage Analysis Processing logs provide extensive information in log files that can detect how end users access and use SharePoint
Portal Server with possible errors. These log files also can be used for peak-usage
analysis and to determine which pages are most frequently used. Peak-usage analysis in conjunction with records obtained from performance monitoring logs can be
used for capacity planning. Based on this information, you can decide if you need
an additional server in the front-end Web server farm.
SharePoint Portal Server Diagnostic Tools
You can configure diagnostic tools through the SharePoint Portal Server Central
Administration interface to detect errors and help with troubleshooting. You can
configure these logs to record SharePoint Portal Server–related messages at the following levels:
266
Part III: Planning and Deployment
■
Do not run logging on this server
■
Log critical events only
■
Log informational events and critical events
■
Log all tracing information
You can choose one of these options for each computer running SharePoint
Portal Server. You can also configure a separate log that keeps track of information
for a specific service. The SharePoint Portal Server services that provide logging
capabilities are as follows:
■
WWW Worker Process (w3wp.exe)
■
Administration Service (spsadmin.exe)
■
Search Service (spssearch.exe)
■
Backup and Restore (spsbackup.exe)
■
Notification Service (spsNotificationService.exe)
■
Single Sign-On Service (ssosrv.exe)
Monitoring Custom Web Parts
Most customers customize the accelerator portal by developing new Web Parts, integrating with other applications, or using third-party Web Parts. Before adding a Web
Part to the production portal, you should evaluate the impact of the load generated
by new Web Parts.
Most companies have a separate development environment for this purpose,
and some have staging environments that closely mimic the production portal configuration, which provides a more realistic picture of the impact of adding new Web
Parts. In any case, you should thoroughly debug and test any custom Web Part and
have a good understanding of the possible load that a new Web Part will generate
in your accelerator portal.
Table 10-15 details the information you can use to compare the performance
baseline of your portal with custom Web Parts against the results of your portal
when it did not include the Web Parts. You can then determine the additional load
and possible impact on other performance counters. These counters are available
through Windows Server 2003 System Monitor.
Chapter 10: Performance Monitoring in Microsoft Office SharePoint Portal Server 2003
267
Table 10-15 Performance Monitoring of Custom Web Parts
Type
Information
Sampling Frequency
General system
information
Average CPU usage
Every two minutes
Average virtual bytes
Every two minutes
Average private bytes
Every two minutes
Average pool paged bytes
Every two minutes
Average pool nonpaged bytes
Every two minutes
Average working set
Every two minutes
Average context switches/sec
Every two minutes
Average pages/sec
Every two minutes
Average interrupts/sec
Every two minutes
Physical disk—average
current queue length
Every two minutes
ISAPI requests processed
Total over a two-hour period
ASP requests processed
Total over a two-hour period
Total requests processed
Total over a two-hour period
Web service—service uptime
Every two hours
Average requests queued
Every two minutes
Average request execution time
Every two minutes
Average request wait time
Every two minutes
ASP.NET
ASP.NET applications
Web service cache
Average requests executing
Every two minutes
Requests total
Total over a two-hour period
Output cache hits
Total over a two-hour period
Output cache misses
Total over a two-hour period
Average output cache entries
Every two minutes
File cache hits
Total over a two-hour period
File cache misses
Total over a two-hour period
File cache flushes
Total over a two-hour period
Average current file cache
memory usage
Every two minutes
Average current files cached
Every two minutes
Kernel: URI cache hits
Total over a two-hour period
Kernel: URI cache misses
Total over a two-hour period
268
Part III: Planning and Deployment
Table 10-15
Performance Monitoring of Custom Web Parts
(continued)
Type
Information
Sampling Frequency
Inetinfo process
information
Average CPU usage
Every two minutes
Average virtual bytes
Every two minutes
Average private bytes
Every two minutes
Average pool paged bytes
Every two minutes
Average pool nonpaged bytes
Every two minutes
Average working set
Every two minutes
Average thread count
Every two minutes
Average handle count
Every two minutes
Average virtual bytes
Every two minutes
Average private bytes
Every two minutes
Average pool paged bytes
Every two minutes
Average pool nonpaged bytes
Every two minutes
Average working set
Every two minutes
Average thread count
Every two minutes
Average handle count
Every two minutes
Average number deployed
Every two minutes
Average CPU usage
Every two minutes
Average virtual bytes
Every two minutes
Average private bytes
Every two minutes
Average pool paged bytes
Every two minutes
Average pool nonpaged bytes
Every two minutes
Average working set
Every two minutes
Average thread count
Every two minutes
Average handle count
Every two minutes
Average aggregate CPU usage
Every two minutes
Average virtual bytes
Every two minutes
Average private bytes
Every two minutes
Average pool paged bytes
Every two minutes
Average pool nonpaged bytes
Every two minutes
Average working set
Every two minutes
Average thread count
Every two minutes
Average handle count
Every two minutes
Average number deployed
Every two minutes
Inetinfo process
information
Web Administration
Service (WAS) process
information
W3WP (worker
process) process
information
Chapter 10: Performance Monitoring in Microsoft Office SharePoint Portal Server 2003
Table 10-15
Performance Monitoring of Custom Web Parts
Type
Information
All system processes
269
(continued)
Sampling Frequency
CPU usage
Every two hours
Virtual bytes
Every two hours
Private bytes
Every two hours
Pool paged bytes
Every two hours
Pool nonpaged bytes
Every two hours
Working set
Every two hours
Thread count
Every two hours
Note For an explanation of specific performance counters, refer to the
Windows Server 2003 Help and Support Center. You can access the Windows Server 2003 Help and Support Center by pressing the F1 key.
Indirect Monitoring
Monitoring the applications that directly use or access your portal provides an enduser view of the responsiveness and reliability of the system. Indirect monitoring
provides a better picture of system response time to client requests, especially in
environments that are geographically disparate. Indirect monitoring provides an
accurate view of application performance and effectiveness.
There are third-party solutions that run scripts to simulate client sample loads
from different locations at specific intervals. You can also use free tools and utilities,
such as HTTPPing, to achieve the same goal. For more information about HTTPPing,
visit the MSDN website at http://msdn.microsoft.com, and search for “HTTPPing.”
Summary
In this chapter, we have outlined some methods and counters you’ll need to use to
effectively monitor SharePoint Portal Server 2003. In the next chapter, we’ll outline
how to use Microsoft Operations Manager to streamline performance monitoring of
your servers.
Part IV
Deployment Scenarios
In this part:
11
Deploying a Single Server and a Small Server Farm . . . . . . . . . . . . . . . . . . . . . . 273
12
Deploying Medium and Large Server Farms . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281
13
Installing and Configuring Windows SharePoint Services in an Extranet . . . . . . 317
14
Shared Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 339
Chapter 11
Deploying a Single Server
and a Small Server Farm
In this chapter:
Single Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273
Small Farm. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 280
This chapter discusses how to deploy a single server or a small server farm. A singleserver deployment has the database installed on the same server as Microsoft SharePoint Products and Technologies, whereas a small farm has SharePoint Portal Server
2003 or Windows SharePoint Services installed on one machine and the database
installed on a separate server. In this chapter, we will cover the effect of these configurations on Microsoft Windows SharePoint Services and Microsoft Office SharePoint Portal Server 2003 deployments.
This chapter does not cover detailed step-by-step instructions on how to install
Windows SharePoint Services and SharePoint Portal Server 2003. For that type of
information, please refer to Chapter 2, “Installing Windows SharePoint Services,”
and Chapter 3, “Installing Microsoft Office SharePoint Portal Server 2003.”
Single Server
The single server must be running Microsoft Windows Server 2003 (Standard, Enterprise, or Datacenter). You must configure the server as a Web server, running Internet Information Services (IIS) in IIS 6.0 worker process isolation mode, and you
must be running ASP.NET. The computer must be using the NTFS file system. You
can deploy a single-server configuration either as a stand-alone single server using
Microsoft SQL Server 2000 Desktop Engine (Windows) (WMSDE) or as a single
server with Microsoft SQL Server 2000 Service Pack 3a or higher.
273
274
Part IV: Deployment Scenarios
Note The WMSDE is a build of MSDE specifically designed for Windows
Components. MSDE has a 2-GB limit to the size of its database, and it limits the number of concurrent connections to 10. With WMSDE, both these
limitations have been removed, but checks have been put in place so that
only Windows Components can modify the structure of the database.
This section will now cover these two options when deploying Windows
SharePoint Services and SharePoint Portal Server 2003.
Windows SharePoint Services
The quickest way to get started with Windows SharePoint Services is to install it on a
single-server computer. This allows you to set up a small-scale installation to host
several websites without performing many steps. Multiple sites and subsites are
grouped in site collections on each virtual server in IIS that is extended with Windows SharePoint Services. An Internet Server Applications Program Interface (ISAPI)
filter maps incoming URLs to specific sites on that virtual server. Scaling is achieved
by adding site collections to an existing virtual server or by adding subsites to an
existing site collection. Each virtual server has its own set of content databases in
WMSDE or SQL Server. The configuration database directs each virtual server to the
appropriate content database for a given website. The content for the top-level website and any subsites within a site collection is stored in the same content database.
When you install Windows SharePoint Services on a single server, you can
choose between WMSDE and SQL Server as follows:
■
WMSDE. By using the default options during setup, WMSDE is automatically
installed and used to create the database for your websites. You do not have to
perform any other configuration steps to create the database. This installation
scenario offers you the ability to host several websites without a great deal of
overhead. You should consider using SQL Server instead of WMSDE if you
anticipate supporting more than 1000 websites, if there are more than 10 active
and large websites, or if you need a clustered database for high availability.
Search features are available only for Windows SharePoint Services with
Microsoft SQL Server 2000. If you are running WMSDE for your database, no
search features are available. If you want to allow full-text searching on your
websites, you must upgrade to SQL Server 2000.
■
SQL Server. Extract the Windows SharePoint Services installation files, and
when the installation process starts, click Cancel. Run setup from the command
line, and use the remotesql=yes property. This property allows you to install
Windows SharePoint Services to work with an existing installation of SQL
Chapter 11: Deploying a Single Server and a Small Server Farm
275
Server 2000—that is, SQL Server must be installed prior to you starting the Windows SharePoint Services setup process. This installation scenario allows you
to support a larger set of websites. When you use this method, you must perform additional steps to configure SQL Server and Windows SharePoint Services to work together. This is also true if you want to use SQL Server with
SharePoint Portal Server. Refer to Chapters 2 and 3 for more information. Such
additional steps could include the creation of additional accounts to use with
SQL Server, configuring the SQL Server database to use Windows authentication, and connecting your extended virtual server to the SQL server where the
configuration and content databases will be created.
For either option, the database size required for Windows SharePoint Services
depends on the number and size of the websites your server supports. You should
not consider using WMSDE if you will need to store more than 2 to 4 GB of data, if
you want the database placed on a different server than Windows SharePoint Services, or if you want to use Windows SharePoint Services search capability.
(Although there is no upper limit to the size of databases when you use WMSDE,
you might find that when databases get to a certain size it will be easier to manage
them by using SQL Server.) For more information on capacity planning, please refer
to Chapter 9, “Capacity Planning.”
For more information on Windows SharePoint Services installation and configuration considerations, please refer to Chapter 2.
Caution During setup, in a default installation, Windows SharePoint Services extends the default virtual server (the default website in IIS) with Windows SharePoint Services. If you have a website running on the default
website in IIS, Windows SharePoint Services will take over that website during installation. Also, before installing Windows SharePoint Services, verify
that Microsoft FrontPage Server Extensions 2002 are not running on the virtual server on port 80. If FrontPage Server Extensions are running on the
default virtual server, Windows SharePoint Services will not extend the virtual server during installation. (If you upgraded from Microsoft Windows
2000 to Windows Server 2003, FrontPage Server Extensions were installed
by default to port 80.)
SharePoint Portal Server 2003
For SharePoint Portal Server 2003, the single server runs the Web component, index
component, search component, and the job server; and it optionally runs the components for backward compatibility with Microsoft SharePoint Portal Server 2001
document libraries. SharePoint Portal Server 2003 is supported only on servers that
276
Part IV: Deployment Scenarios
are members of a Microsoft Windows NT 4.0, Windows 2000, or Windows Server
2003 domain. When you install SharePoint Portal Server 2003, setup automatically
installs Windows SharePoint Services if it is not already installed. The single-server
database options would be as follows:
■
WMSDE. In SharePoint Portal Server 2003 setup, choose to install SharePoint
Portal Server with the database engine on the server. This installs the MSDE to
store the databases. WMSDE has the same limited throughput ability and
capacity with SharePoint Portal Server as it has with Windows SharePoint Services, as discussed in the previous section. It supports databases with a maximum size of 4 gigabytes (GB). If your deployment requires significant
scalability or must store more than 2 to 4 GB of documents, you should use
SQL Server in your deployment.
■
SQL Server. This server has SQL Server installed prior to the start of the
SharePoint Portal Server installation process, and then in the installation process you choose the option to install SharePoint Portal Server without the database engine on the server.
For more information on SharePoint Portal Server 2003 installation and configuration considerations, please refer to Chapter 3.
Database Automation and Maintenance
Once you have installed Windows SharePoint Services or SharePoint Portal Server
on a single server, the deployment is not complete until you have set up maintenance tasks and operational procedures. This is another differentiating aspect that
you should take into consideration when you choose between WMSDE and SQL
Server.
You can complete many of the tasks needed to maintain and back up Windows
SharePoint Services and SharePoint Portal Server 2003 by using the administration
Web pages. (See Chapter 10, “Performance Monitoring in Microsoft Office SharePoint Portal Server 2003,” Chapter 28, “Disaster Recovery in SharePoint Products and
Technologies,” and Chapter 29, “Usage Analysis Tools in SharePoint Products and
Technologies.”) However, there are other SQL Server administrative tasks that you
might want to complete, especially if the website is heavily used, business critical, or
has a high profile. Using the SharePoint Portal Server Central Administration pages,
such database-specific tasks that are not available include backing up the system
databases, monitoring processes, checking for database errors, and the ability to
alert someone when database-related events occur.
The automation and maintenance of database administration tasks is easier
with SQL Server than with WMSDE. You can manage SQL Server 2000 installations
by using the SQL Server Enterprise Manager, which allows for local and remote management of SQL Servers. It also includes administration wizards that are designed to
Chapter 11: Deploying a Single Server and a Small Server Farm
277
make database administration easier. To manage WMSDE databases, you will have
to use the osql command-line tool. Database administration is outside the scope of
this book. More information on database administrative tasks, the SQL Server Enterprise Manager, and the osql utility can be found in SQL Server Books Online, the
January 2004 update of which can be found at http://www.microsoft.com/downloads /
details.aspx?FamilyID=A6F79CB1-A420-445F-8A4B-BD77A7DA194B&displaylang=en.
Migrating from WMSDE to SQL Server 2000
After you have used Windows SharePoint Services or SharePoint Portal Server 2003
with WMSDE for some time, you might run into performance or storage problems
and need to move to a more scaled-out solution. If you find yourself in this situation,
you can switch to using Microsoft SQL Server 2000 as your database instead of
WMSDE.
You can upgrade WMSDE in-place to SQL Server, although it is not recommended. The Windows SharePoint Services instructions to upgrade are inherently
difficult. Instead, you should back up your data, reinstall the operating system,
install SQL, and then install SharePoint Portal Server 2003 and restore your data. This
scenario has been tested and has proved to be much easier than upgrading.
If you are moving to a larger environment, with one or many front-end Web
servers and one or many back-end database servers, the process is more complicated. For more information on migrating WMSDE to SQL Server on the same server
or to a separate server, see the “Migrating from WMSDE to a Remote SQL Server or
Server Farm” section in Chapter 2 and the “Migrating from WMSDE to SQL Server”
section in Chapter 3.
Small Farm
A small server farm has the following two servers:
■
One front-end Web server, running SharePoint Products and Technologies.
This server could have installed Windows SharePoint Portal Services or SharePoint Portal Server 2003 running the Web component, index, search, and job
services. This server can optionally run the components for backward compatibility with SharePoint Portal Server 2001 document libraries, or this can be
installed on a separate server.
■
One server running SQL Server 2000 with Service Pack 3a or higher. You cannot
use WMSDE in a small server farm configuration, as WMSDE cannot be connected to remotely. You can use WMSDE only in a single-server configuration.
278
Part IV: Deployment Scenarios
Note More than one SQL server could be installed—that is, the SQL
Server component can be either a single server or a clustered server. As
long as you are running any supported SQL Server configuration, SharePoint
Products and Technologies will view it as a single-server installation. This
chapter assumes that the SQL component is installed on one server.
Additional servers can be added to this topology to enable higher availability,
higher capacity, or both. These configurations are classified as medium or large
server farms and are discussed in Chapter 12, “Deploying Medium and Large Server
Farms.”
The reasons for having the database on a different server to server, which has
SharePoint Products and Technologies, include:
■
Performance and availability. The number of users a SharePoint deployment
can support increases when the database is on a separate server.
■
Administration or policy boundaries.
■
Security, as in an Internet or extranet deployment scenario, where the Web
server can be separated from the SQL server with a firewall.
■
SQL Server 2000 is already present on a server running other databases.
More Info For more information on the type of farm you should deploy and
planning considerations, please refer to Chapter 9, “Capacity Planning,” and
the chapters in Part 8, “Securing SharePoint Products and Technologies.”
The front-end Web server must have Windows Server 2003 installed and be
running IIS in IIS 6.0 worker process isolation mode with ASP.NET allowed. The
computer must be using the NTFS file system.
This section will now cover the deployment aspects specific to Windows
SharePoint Services and SharePoint Portal Server 2003.
Windows SharePoint Services
The process for installing Windows SharePoint Services with a separate SQL server,
also known as a remote SQL server, is the same as installing Windows SharePoint
Services on the same machine as SQL server as described earlier, except you will
have to specify the name of the remote SQL Server server in the configuration
options.
Chapter 11: Deploying a Single Server and a Small Server Farm
279
SharePoint Portal Server 2003
For SharePoint Portal Server, you must set up and configure a small server farm
according to specific instructions that are detailed in Chapter 12. Briefly, the installation process consists of the following tasks:
■
■
■
Domain Account creation
■
Create a domain account, which for the purposes of this chapter will be
called domain\spsadmin.
■
Add domain\spsadmin to the local Power Users group on the SharePoint Portal Server.
■
Add the domain/spsadmin to the local Administrators group on any
server that hosts the components for backward-compatible document
libraries.
Server Two: SQL Server
■
Configure the MSSQLSERVER and SQLSERVERAGENT services to start
automatically using domain account names, and then confirm that the
service starts successfully at startup.
■
Configure the domain/spsadmin to have the Security Administrators
and Database Creators server roles on this SQL Server instance.
Server One: SharePoint Portal Server 2003
■
As with a single-server installation, ensure that the FrontPage Server
Extensions are not installed.
■
Install SharePoint Portal Server 2003 as detailed in Chapter 3, choosing
the option without database engine.
■
In the Account name box, type domain/spsadmin. This will be used
for administrative operations that create, modify, or grant access to the
configuration or portal site databases.
Warning The following user rights are granted automatically to this account
(the configuration database administration account) on the local server:
Replace A Process Level Token, Adjust Memory Quotas For A Process, and
Log On As A Service. If you change this account by using the Configure Server
Farm Account Settings page, the rights are not revoked automatically for the
previous account. However, you can remove these rights by using Local Security Settings. To open Local Security Settings, click Start, point to Administrative Tools, and then click Local Security Policy.
280
Part IV: Deployment Scenarios
■
On the Component Assignment page, only one server should be present,
the row of check boxes—Web, Search, and Index roles—should be
assigned to this server, and this server should also be selected in the Job
server list in the Job Server Component section.
■
Create a portal site. At the end of a successful portal site creation, the
Operation Successful page appears. You can then further configure the
portal site.
■
Optional: Install and configure the components for backward-compatible
document libraries.
■
Check that the installation is configured correctly and can be accessed as
planned. Such a check should include ensuring that the proxy server settings for Internet access are specified correctly and that you can access
and create information objects such as areas, topics, document libraries,
and lists as planned.
Summary
This chapter discussed the deployment of Windows SharePoint Services and SharePoint Portal Server 2003 in a single-server and small farm configuration. It described
the reasons why you might want to install SharePoint Products and Technologies
using WMSDE and why you might need to migrate to SQL Server, either on the same
machine as a SharePoint Portal Server installation or on a separate server.
Chapter 12
Deploying Medium and
Large Server Farms
In this chapter:
Topologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315
This chapter discusses how to deploy a medium or large server farm. The majority
of the chapter consists of step-by-step instructions that can be used as a guide for
deploying a farm. This chapter does not cover how to determine which type of farm
to use in given situations. For that type of information, please refer to Chapter 9,
“Capacity Planning.”
This chapter should be viewed as a getting-started guide for building a medium
or large server farm. It will cover everything necessary for building both a medium
server farm and a larger server farm. It will also contain instructions for how to
migrate from a medium farm to a large farm.
Topologies
Many permutations of topologies can be built using Microsoft Office SharePoint Portal Server 2003, but only a small number of these topologies are supported by
Microsoft. The simplest topologies are the single-server and small-server-farm topologies, which have been covered in previous chapters.
Medium and large server-farm topologies can get much more complex. A
medium server topology requires at a minimum one front-end Web server running the
search application, one index/job server running SharePoint Portal Server 2003, and
one database server running Microsoft SQL Server 2000 with Service Pack 3a or later.
Additional servers can be added to this topology to enable higher availability, higher
capacity, or both, but you cannot have a medium farm with fewer than four servers.
Several topologies are not supported by Microsoft. When you install one of these
topologies, it will appear to function—that is, you can create the topology on the
281
282
Part IV: Deployment Scenarios
Components Selection page, but it will not be eligible for support and you will not be
able to create a new portal site in it. In addition, unsupported topologies cannot be
backed up or restored. When you open SPSBackup.exe, it will show an error “Topology not supported” and exit. It is strongly recommended that you stay away from
these unsupported topologies. Installing the database component on one of the servers running SharePoint Portal Server is an unsupported topology for a farm. Installing
two or more servers with all (Web/search/index) components is also not supported.
Here are the supported topologies:
■
Small Server Farm. One server running SQL Server 2000 and one server
running SharePoint Portal Server 2003 assigned the Web, Search, Job, and
Index services.
■
Medium Server Farm. One or two servers running SharePoint Portal Server
2003 assigned the Web service (more commonly known as front-end Web servers) and running SharePoint Portal Server 2003 assigned the Search, Job, and
Index services; and one server running SQL Server 2000.
■
Large Server Farm. Two to eight servers running SharePoint Portal Server
2003 assigned the Web service (more commonly known as front-end Web servers), two to four servers running SharePoint Portal Server 2003 assigned the
Search service, one to four servers running SharePoint Portal Server 2003
assigned the Index service (one of which must be assigned the Job Server
role), and any number of servers running SQL Server 2000.
In all supported topologies, you can use a single additional server running
SharePoint Portal Server 2003 for the purpose of running the backward-compatible
document library.
Two factors differentiate a medium farm from a large farm. The first factor is
the server component matrix—you will need more servers to run a minimum large
farm. The second difference is that the Web and search components run on all frontend Web servers in a medium farm, while on a large farm these components must
each run on separate servers. Medium server farms become large server farms by
adding Web/search front-end servers, using Network Load Balancing (NLB) to distribute the load, and by adding search and indexing servers to the server component
matrix. As long as you stay within the boundaries of a prescribed server farm, any
combination of these can be employed. Only four index servers can exist in a large
server farm because each search server can only consume four separate catalogs.
For more information about how each of these components affects performance,
please see Chapter 9. The most common medium-farm topology consists of two
front-end Web servers running search and indexing/job servers, and one SQL component, for a total of four servers. The SQL component can be either a single server
or a clustered server, but because the cluster acts like one system, it will be discussed
here as one component. SharePoint Portal Server does not really care what the SQL
Server topology is because this is abstracted from the server farm deployment.
Chapter 12:
Deploying Medium and Large Server Farms
283
Therefore, you can be running any supported SQL topology and SharePoint Portal
Server views it as a single-server installation for topology purposes. This is the topology that will be covered when discussing medium server farms in this chapter.
Because this topology employs NLB as well as all other components required by a
medium farm, the instructions provided can be used to easily add servers to the
topology.
As mentioned previously, a large server farm is very similar to a medium server
farm, except that the search and Web components run on separate systems and large
server farms can support more servers than a medium farm. The minimum topology
for a large server farm is two front-end Web servers running SharePoint Portal Server
2003, two search servers running SharePoint Portal Server 2003, one index management server running SharePoint Portal Server 2003, and one database component
running Microsoft SQL Server 2000 Service Pack (SP) 3a. The SQL component can be
either a single server or a clustered server, but because the cluster acts like one system, it will be discussed here as one component. The large server farm can be scaled
out by adding front-end Web servers, search servers, or index management servers.
You cannot have more than four search servers or four index management servers
in any farm. Because only four catalogs can be consumed by the search servers, having more than four index management servers will cause search to function improperly, as some content sources will not be searched.
Both medium and large server farms support running one server with the
backward-compatible document libraries. There can only be one server in the
farm that has these components. In addition, each medium and large server farm
requires one job server. The job server role must be assigned to an index management server, in part, because the job server is responsible for indexing all portal
site content and people. Here is a complete list of all the job server activities:
■
Managing the indexing of all portal content
■
Indexing people from the profile database
■
Hosting the Single Sign-On administration pages
■
Performing Audience calculations
■
Running the Alert service for the server farm
■
Importing profiles from Active Directory
The job server is an important role, but one that can be assigned only to an
individual server in the server farm. This is an example of a shared service—a service that runs on a single server in the server farm but is consumed by all servers in
the farm. Shared services is discussed more fully in Chapter 14, “Shared Services.”
The way that the servers know which role they have been assigned in the farm
is handled by the Admin service. When you make a component change between servers in a server farm on the Component Selections page, this information is written to
the Configuration database. The Admin service, which runs on each server running
284
Part IV: Deployment Scenarios
SharePoint Portal Server 2003, checks this configuration database for component
assignment changes every 30 seconds. If it detects a change, the service turns on or off
those portions of the SharePoint Portal Server code to run only the assigned services.
For example, let’s assume you have a server in a large server farm that has been
assigned the index and job server roles. Now, let’s assume that you decide to move
the job server role to another index server in the farm. On both of these servers, all
the SharePoint Portal Server code is installed, but when you make the service assignment change, the Admin service on the first server will “turn off” the job server role
services and the Admin service on the second server will “turn on” the job server
role services and assume these responsibilities. In this manner, each server in the
farm will know its role in the farm, the services it is to run to “complete” the farm,
and when to change its role to meet new role assignments you select on the Components Selection page.
Preparing for Deploying a Farm
Before building a server farm, you need to collect some information and create prerequisite accounts. Table 12-1 shows the information needed to create a portal site
and includes the values for each item used for a medium farm in this chapter. The
numbers and DNS entries filled in are examples. You should fill in your own IP
Address Range and DNS entries based on your environment.
Table 12-1
Roles, IP Addresses, and Names in a Medium Farm
Physical
Server
DNS Name
IP Address
Subnet Mask
Description
n/a
cluster.sps.test.local
172.16.12.200
255.255.0.0
Corporate portal Used for NLB
virtual host
SPS-01
SPS-01.sps.test.local
172.16.12.10
255.255.0.0
Host address
for front-end
Web/search
server SPS-01
If only one NIC
in server, bind
this address and
cluster address
(below). If multiple NICs, choose
the NIC connected
to the internal
network for this
address.
172.16.12.200
255.255.0.0
Cluster address
for front-end
Web/search
server SPS-01
If only one NIC in
server, bind this
address and host
address (above).
If multiple NICs,
choose the NIC
connected to the
external network
for this address.
SPS-01
Notes
Chapter 12:
Table 12-1
Deploying Medium and Large Server Farms
Roles, IP Addresses, and Names in a Medium Farm
285
(continued)
Physical
Server
DNS Name
IP Address
Subnet Mask
Description
SPS-02
SPS-02.sps.test.local
172.16.12.11
255.255.0.0
Host address for If only one NIC in
front-end Web
server, bind this
server SPS-02
address and cluster
address (below).
If multiple NICs,
choose the NIC
connected to the
internal network
for this address.
172.16.12.200
255.255.0.0
Cluster address
for front-end
Web server
SPS-02
SPS-02
SPS-03
SPS-03.sps.test.local
172.16.12.12
255.255.0.0
Index management server
SQL-01
SQL-01.sps.test.local
172.16.12.9
255.255.0.0
Address of SQL
Server (or active
server if cluster)
DocLib
DocLib.sps.test.local
172.16.12.15
255.255.0.0
Optional server
for backwardcompatible document libraries
Notes
If only one NIC in
server, bind this
address and host
address (above).
If multiple NICs,
choose the NIC
connected to the
external network
for this address.
If clustered, this
information should
be used for the SQL
cluster’s active node.
For a large server farm, the information in Table 12-2 will be used.
Table 12-2 IP Addresses and Names in a Large Farm
Physical
Server
DNS Name
IP Address
Subnet Mask
Description
n/a
cluster.sps.test.local
172.16.12.200
255.255.0.0
Corporate portal Used for NLB
virtual host
SPS-01
SPS-01.sps.test.local
172.16.12.10
255.255.0.0
Host address for If only one NIC in
front-end Web
server, bind this
server SPS-01
address and cluster
address (below).
If multiple NICs,
choose the NIC
connected to the
internal network
for this address.
Notes
286
Part IV: Deployment Scenarios
Table 12-2
Physical
Server
IP Addresses and Names in a Large Farm
DNS Name
SPS-01
SPS-02
SPS-02.sps.test.local
SPS-02
(continued)
IP Address
Subnet Mask
Description
Notes
172.16.12.200
255.255.0.0
Cluster address
for front-end
Web server
SPS-01
If only one NIC in
server, bind this
address and host
address (above).
If multiple NICs,
choose the NIC
connected to the
external network
for this address.
172.16.12.11
255.255.0.0
Host address
for front-end
Web server
SPS-02
If only one NIC in
server, bind this
address and cluster
address (below).
If multiple NICs,
choose the NIC
connected to the
internal network
for this address.
172.16.12.200
255.255.0.0
Cluster address
for front-end
Web server
SPS-02
If only one NIC in
server, bind this
address and host
address (above).
If multiple NICs,
choose the NIC
connected to the
external network
for this address.
SPS-03
SPS-03.sps.test.local
172.16.12.12
255.255.0.0
Index management server
SPS-04
SPS-04.sps.test.local
172.16.12.13
255.255.0.0
Search server
SPS-05
SPS-05.sps.test.local
172.16.12.14
255.255.0.0
Search server
SQL-01
SQL-01.sps.test.local
172.16.12.9
255.255.0.0
Address of
SQL Server (or
active server
if cluster)
DocLib
DocLib.sps.test.local
172.16.12.15
255.255.0.0
Optional server
for backwardcompatible document libraries
If clustered, this
information should
be used for the
SQL cluster’s
active node.
Chapter 12:
Deploying Medium and Large Server Farms
287
SharePoint Portal Server farms use many different service accounts. These service
account settings can all use the same account, or they can use different accounts if corporate policies dictate. For the purposes of this chapter, all service account settings will
use the same account. Table 12-3 shows the different service accounts.
Table 12-3
Service Accounts
Server
Service Name
Access Account
Role
SQL Server
MSSQLSERVER
domain\spssql
Database system administrator
SQL Server
SQLSERVERAGENT
domain\spssql
Database system administrator
Web front-end(s),
search, and index
SharePointPS search
domain\spssql
SharePoint Portal Server
administrator
Web front-end(s),
search, and index
SharePoint
administration
domain\spssql
SharePoint Portal Server
administrator
Web front-end(s),
search, and index
SharePoint
portal alert
domain\spssql
SharePoint Portal Server
administrator
Web front-end(s),
search, and index
SharePoint timer
service
domain\spssql
SharePoint Portal Server
administrator
Web front-end(s),
search, and index
Configuration
database
domain\spssql
Administrator right on search
and index servers
Web front-ends
Default content access
account
domain\spssql
Used for crawling content on
the Internet. This should have
elevated privileges to access
content throughout the intranet. Keep in mind that even
though this account can access
all data, users will see only
results for content that they
have access to.
The SharePoint Portal Server administrator must have at least local Power User
rights on each server running SharePoint Portal Server. To grant the account Power
User permissions, follow these steps:
1. Open Administrative Tools, click Computer Management.
2. Expand Local Users and Groups and click the Groups folder.
3. Double-click the Power Users group.
4. Click the Add button.
5. Enter the name of the service account (SPS\SPSSQL) and click OK. Click OK
again to finalize the group membership addition.
288
Part IV: Deployment Scenarios
Configuring Network Load Balancing
Network Load Balancing (NLB) is a clustering technology that allows multiple servers that are configured the same to service clients. It distributes the incoming connections between all the servers in the cluster. In a SharePoint Portal Server farm
environment, NLB is used to distribute load between all the front-end Web servers in
the farm. This gives the farm redundancy and the ability to scale out.
Note Windows Network Load Balancing distributes load and provides
failover for the Web servers only. Although the search services for the
medium server farm operate on the Web server computers, search services
use their own load-balancing mechanisms, and therefore Windows NLB
does not affect them.
SharePoint Portal Server does not depend on NLB, so any load-balancing technology can be used. NLB is discussed here because it comes with all Windows
Server 2003 editions. If your corporate environment uses a different load-balancing
mechanism, feel free to use that instead.
NLB works by setting the same physical (MAC) address on all nodes of the
cluster. In essence, this makes all the machines’ network cards act like a single network card. The MAC address used for NLB cannot be manually configured. It is set
by Windows based on the IP address chosen for the cluster. The following sections
detail configuring and testing NLB for use in a SharePoint Portal Server farm.
To configure the first front-end NIC (SPS-01)
1. In Control Panel, click Network Connections.
2. Right-click Local Area Network Connection and then click Properties.
3. Under This connection uses the following items, click Internet Protocol
(TCP/IP).
4. Click Properties.
5. Click Use the following IP address, and type in the IP address with your
assigned front-end static IP address. (This is the IP address for the machine, not
the cluster.)
6. Type in the subnet mask associated with this IP address.
7. Type in the default gateway with your assigned front-end gateway.
8. Click Advanced.
9. Under IP address, click Add.
10. In the IP Address box, type the cluster IP address, as illustrated in Figure 12-1.
Chapter 12:
Deploying Medium and Large Server Farms
289
F12XR01
Figure 12-1
Setting the cluster IP address on SPS-01
11. Type in the subnet mask associated with the cluster IP.
12. On the DNS tab, remove all DNS entries.
13. Deselect the Register this connections addresses in DNS check box.
14. On the WINS tab, remove all WINS entries.
15. On the LAN Connection Properties page, under This connection uses the
following items, click Network Load Balancing.
16. Click Network Load Balancing again, and then click Properties.
17. On the Cluster Parameters tab, perform the following steps, as illustrated in
Figure 12-2:
a. In the IP Address box, type the cluster IP (172.16.12.200).
b. Type the subnet mask associated with the cluster IP.
c. In the Full Internet Name box, type the DNS name.
d. Change the Cluster operation to the Unicast setting.
Note The Unicast setting can be used only when your server has multiple
Network Interface Cards (NIC), while Multicast will be used when there is
only one NIC. For a further explanation, please see the Windows Server
2003 Resource Kit or the “Network Load Balancing: Configuration Best
Practices for Windows 2000 and Windows Server 2003” white paper.
e. Leave the Allow remote control check box unselected.
290
Part IV: Deployment Scenarios
F12XR02
Figure 12-2
Configuring NLB cluster properties on SPS-01
18. On the Host Parameters tab, perform the following steps, as illustrated by
Figure 12-3:
a. Because this is the first Web/search server, enter Priority 1.
b. In the Dedicated IP Configuration section, enter the address and subnet
mask that you assigned to this machine in step 5.
c. Do not change the initial host state settings.
F12XR03
Figure 12-3
Setting NLB host parameters on SPS-01
Chapter 12:
Deploying Medium and Large Server Farms
291
19. On the Port Rules tab, in the Filtering mode section, verify that multiple
host is enabled and that Portal Server is set to None, as shown in Figure 12-4.
F12XR04
Figure 12-4
Set NLB Port Rules on SPS-01
To configure additional front-end NICs (SPS-02)
1. In Windows Control Panel, click Network Connections.
2. Right-click Local Area Connection and then click Properties.
3. Under This connection uses the following items, click Internet Protocol
(TCP/IP).
4. Click Properties.
5. Click Use the following IP address, and type in the IP address with your
assigned front-end static IP address. (This is the IP address for the machine, not
the cluster.)
6. Type in the subnet mask associated with this IP address.
7. Type in the default gateway with your assigned front-end gateway.
8. Click Advanced.
9. Under IP address, click Add.
10. In the IP Address box, type the cluster IP address as shown in Figure 12-5.
11. Type in the subnet mask associated with the cluster IP.
12. On the DNS tab, remove all DNS entries.
13. Deselect the Register this connections addresses in DNS box.
14. On the WINS tab, remove all WINS entries.
15. On the LAN Connection Properties page, under This connection uses the
following items, click Network Load Balancing.
292
Part IV: Deployment Scenarios
F12XR05
Figure 12-5
Setting the cluster IP address (SPS-02)
16. Click Network Load Balancing again, and then click Properties.
17. On the Cluster Parameters tab, perform the following steps, as shown in
Figure 12-6:
a. In the IP Address box, type the cluster IP (number 1 on the worksheet).
b. Type the subnet mask associated with the cluster IP.
c. In the Full Internet Name box, type the DNS name.
d. Change the Cluster operation to the Unicast setting.
Note The Unicast setting can be used only when your server has multiple
Network Interface Cards (NIC), while Multicast will be used when there is
only one NIC. For a further explanation, please see the Windows Server
2003 Resource Kit or the “Network Load Balancing: Configuration Best Practices for Windows 2000 and Windows Server 2003” white paper.
e. Leave Allow remote control check box unselected.
18. On the Host Parameters tab, perform the following steps, as illustrated in
Figure 12-7:
a. Because this is your second Web/search server, select Priority 2. (For
additional servers, choose numbers in ascending order—3 and then 4, and
so on.)
b. In the Dedicated IP Configuration section, enter the address and subnet
mask that you assigned to this machine in step 5.
Chapter 12:
Deploying Medium and Large Server Farms
293
F12XR06
Figure 12-6
Configuring NLB cluster properties on SPS-02
Figure 12-7
Configuring NLB host properties on SPS-02
F12XR07
19. On the Port Rules tab, in the Filtering mode section, verify that Multiple
host is enabled and that Affinity is set to None as illustrated in Figure 12-8.
20. For large server farms: repeat these steps as necessary for each additional frontend Web server.
294
Part IV: Deployment Scenarios
F12XR08
Figure 12-8
Configuring port rules on SPS-02
Verify the Cluster’s Status
After configuring Network Load Balancing, it is absolutely paramount to test it and
make sure it is working properly. Using Ping.exe and the Network Load Balancing
Manager, you can quickly verify that your cluster is functioning properly.
1. In Administrative Tools, double-click Network Load Balancing Manager.
Note If you run Network Load Balancing Manager from a node in the cluster, you might be presented with a warning that you need to use Multicast
mode for successfully monitoring the cluster. If you did not select Multicast
as the operating mode, you must run the Network Load Balancing Manager
from a machine that is not in the cluster.
2. Right-click Network Load Balancing Cluster, and select Connect to Existing, as shown in Figure 12-9.
3. Enter the DNS of the cluster, and click Connect.
Network Load Balancing Manager might take a minute or two to make all the
connections. You should see all your servers in the cluster listed, and they
should all be showing green, as shown in Figure 12-10.
Chapter 12:
Deploying Medium and Large Server Farms
295
F12XR09
Figure 12-9
Connecting to a cluster in NLB manager
F12XR10
Figure 12-10
NLB Manager listing of all servers in a cluster
4. From a computer not in the cluster, run ping
in Figure 12-11.
–t <DNS name of cluster>,
as shown
296
Part IV: Deployment Scenarios
F12XR11
Figure 12-11
Starting the ping test for a cluster
This will test to make sure the cluster is operational by continuously pinging
the cluster. To test the failover of the cluster, each machine in the cluster needs to be
drainstopped. Drainstopping is used to tell the server to continue processing new
requests but not accept any new requests, thus gracefully taking the server down.
The ping should not stop even though one of the cluster nodes is down. To test
failover, do the following:
1. Return to Network Load Balancing Manager.
2. Right-click the first server in the cluster (SPS-01), click Control Host, and then
click Drainstop, as illustrated in Figure 12-12.
F12XR12
Figure 12-12
Performing Drainstop on SPS-01
3. You will see the server icon turn yellow and its state set to Converging. Wait
about 10 seconds, right-click the cluster name, and choose Refresh. The icon
Chapter 12:
Deploying Medium and Large Server Farms
297
for the first node in the cluster (SPS-01) should be red now, which signals that
it is stopped, as illustrated in Figure 12-13.
F12XR13
Figure 12-13
SPS-01 converging after Drainstop
4. Look at the computer running the ping command and make sure it is still getting a response from the cluster, as shown in Figure 12-14.
F12XR14
Figure 12-14
Ping test is still getting responses
5. Return to Network Load Balancing Manager.
6. Right-click the first server in the cluster (SPS-01), click Control Host, and then
click Start, as shown in Figure 12-15.
7. You will see the server icon turn yellow and its state set to Converging. Wait
about 10 seconds, right-click the cluster name, and choose Refresh. The icon
for the first node in the cluster (SPS-01) should be green now, which signals
that it is started.
298
Part IV: Deployment Scenarios
F12XR15
Figure 12-15
Restarting Network Load Balancing on SPS-01
8. Repeat steps 2 through 7 for each additional node in the cluster.
As long as the ping test passes for each node in the cluster, Network Load Balancing is configured properly. If one or more of the nodes fail the ping test, go back
and reconfigure Network Load Balancing on each failed server as specified in the
previous section.
Installing and Configuring SQL Server
SQL Server is required for a server farm installation or any installation that will have
an extranet or Internet connectivity to the portal site. Running SQL Server on a separate machine from all other SharePoint Portal Server components is required, and it
is recommended that you install SQL Server cluster if you want high availability.
When installing on Windows Server 2003 Enterprise Edition, ensure that you are
installing SQL Server 2000 and SQL Server Service Pack 3a. To verify that you have
SQL Server 2000, on the CD, browse to \X86\binn\ssnetlib.dll. The version number should read 2000.80.311.0.
More Info For detailed instructions on how to install SQL Server 2000,
please refer to the SQL Server 2000 Resource Kit.
Chapter 12:
Deploying Medium and Large Server Farms
299
You must properly configure SQL Server services before installing SharePoint
Portal Server 2003. To configure SQL Server services:
1. Configure the MSSQLSERVER service and the SQLSERVERAGENT service to start
automatically, and confirm that both services start successfully at startup.
2. Configure the service accounts for the MSSQLSERVER service and the SQLSERVERAGENT service to run as domain\spssql on the services corresponding
to the instance of SQL Server you want to use.
3. For clusters, repeat this on each computer that is running SQL Server.
Installing Internet Information Services and SharePoint Portal Server
The SharePoint Portal Server client and administration functionalities depend on a
specific Internet Information Services (IIS) configuration. Install IIS on all front-end
search and index servers (SPS-01, SPS-02, SPS-03—and SPS-04 and SPS-05 for large
server farms) as indicated in the following procedure.
To install Internet Information Services
1. Click Start, and then click Manage Your Server.
2. Click Add or remove a role.
3. Click Next to start the wizard. The Configure Your Server Wizard will gather
information about your system, as shown in Figure 12-16.
F12XR16
Figure 12-16
Starting the Configure Your Server Wizard
300
Part IV: Deployment Scenarios
4. Click Application server (IIS, ASP.NET) from the list of choices, and click
Next as illustrated in Figure 12-17.
F12XR17
Figure 12-17
Selecting Application Server
5. Select the Enable ASP.NET check box.
6. Ensure that the FrontPage Server Extensions box is cleared. Click Next as
shown in Figure 12-18.
F12XR18
Figure 12-18
Setting custom configuration options for Application Server
Chapter 12:
Deploying Medium and Large Server Farms
301
7. Verify the install summary, and click Next to start configuration, as illustrated
in Figure 12-19.
F12XR19
Figure 12-19
Verifying configuration options
8. Repeat these steps for additional servers (SPS-02, SPS-03).
Installing SharePoint Portal Server 2003
Install SharePoint Portal Server 2003 on all Web, search, and index servers (SPS-01,
SPS-02, SPS-03—and SPS-04 and SPS-05 for large portal farms). Please refer to Chapter 3 for detailed instructions on installing SharePoint Portal Server 2003.
Configuring the SharePoint Portal Server System Architecture
When you complete the SharePoint Portal Server 2003 installation, the SharePoint
Portal Server Central Administration page displays. Table 12-4 shows which configuration tasks are prescribed for medium and large server farms. These tasks are
described in subsequent sections. You should complete the appropriate configuration tasks based on the type of server and server farm you are configuring. When
you finish configuring the server farm accounts and connecting to the configuration
database, you should add the servers to the server farm topology.
302
Part IV: Deployment Scenarios
Table 12-4 Tasks Prescribed for Medium and Large Server Farms
Medium Server Farm
Large Server Farm
First
Front-end
Web and
Search
Server
Second
Front-end
Web and
Search
Server
First
Index
Front-end
and Job Web
Server Server
Second
Front-end
Web
Server
Search
Servers
Index
and
Job
Server
Configure the
server farm
accounts
ü
ü
ü
ü
ü
ü
Specify the
configuration
database
ü
ü
ü
ü
Configuration
Task
Connect to
existing configuration database
ü
ü
ü
ü
Configuring the Server Farm Accounts
Perform the steps listed in the following procedure and shown in Figure 12-20 on all
the SharePoint Portal Server–based servers.
Figure 12-20
F12XR20
Configuring server farm accounts
Chapter 12:
Deploying Medium and Large Server Farms
303
To configure the server farm accounts
1. On the Configure Server Farm Account Settings page, in the Default Content
Access Account section, click Specify Account.
Note The Default Content Access Account can be any account, but to work
properly, this account must have Read access to all content you plan on
crawling.
2. In the Portal Site Application Pool Identity section, enter the domain and
user name for the SharePoint Portal Server service account (domain\sqlsps).
3. Enter and confirm the account password.
4. Repeat these steps on each additional server.
Specifying the Configuration Database
SharePoint Portal Server uses a configuration database to store all information about
the configuration and settings of a farm. This database needs to be created by the
first server in your farm and used by each additional server you want to participate
in the same farm.
To create the configuration database (SPS-01)
1. On the Specify Configuration Database Settings For SPS-01 page, perform the
following steps, as illustrated in Figure 12-21:
a. In the Database Connections section, click Create configuration
database.
b. In the Configuration Database Server section, in the Database server
box, enter the name of the server (or virtual server if a cluster) running
SQL Server 2000 (SQL-01).
c. In the Configuration Database Name section, leave the default
settings.
d. Click OK. The Configure Server Farm Account Settings page appears.
304
Part IV: Deployment Scenarios
e. In the Contact E-mail Address section, enter the e-mail address of a system
administrator.
f. In the Proxy Server Settings section, set the appropriate proxy settings
for accessing the Internet.
g. Click OK.
F12XR21
Figure 12-21
Creating the Configuration Database
Note Typically, you should use the default database name. If you have a
special circumstance—such as needing to name the configuration database according to a naming scheme your company set up—you can specify
your own name for the configuration database. Just make sure to write it
down, as it will be needed when installing each additional farm server.
To specify the configuration database (SPS-02, SPS-03 and SPS-04, SPS-05 on
large farms)
1. On the Specify Configuration Database Settings For server_name page, do the
following:
a. In the Database Connections section, click Connect to existing configuration database.
Chapter 12:
Deploying Medium and Large Server Farms
305
b. In the Configuration Database Server section, in the Database server
box, enter the name of the server (or virtual server if cluster) running SQL
Server 2000 (SQL-01).
c. In the Configuration Database Name section, leave the default settings.
(If a custom database name was specified, enter that here instead.)
d. Click OK. The Configure Server Farm Account Settings page appears.
e. In the Contact E-mail Address section, enter the e-mail address of a system
administrator.
f. In the Proxy Server Settings section, set the appropriate proxy settings
for accessing the Internet.
g. Click OK.
2. Repeat these steps for each additional server in the farm.
Adding Servers to the Topology
Now that all of the servers are added to the configuration database, you need to add
them to the server topology.
To add servers to the server farm
1. On the Configure Server Topology page, click Change Components.
Depending on the type of server farm you are adding, perform one of the following steps:
For Medium Server Farms. On the Change Component Assignments page,
in the Component Assignment section, there is a row of check boxes for
each server and there are columns of check boxes to assign Web, search, and
index roles. For each front-end Web server (SPS-01, SPS-02), select Web and
Search. For the index server (SPS-03), select Index as illustrated in Figure 12-22.
For Large Server Farms. On the Change Component Assignments page, in
the Component Assignment section, there is a row of check boxes for each
server and there are columns of check boxes to assign Web, search, and index
roles. For each front-end Web server (SPS-01, SPS-02), select Web. For each
search server (SPS-04, SPS-05), select Search. For the index server (SPS-03),
select Index as illustrated in Figure 12-23.
2. In the Job Server Component section, select an index server from the Job
server list.
3. In the Document Library Server Component (Optional) section, make
sure the Document library server box is left empty.
306
Part IV: Deployment Scenarios
F12XR22
Figure 12-22
Assigning servers to the medium farm topology
Figure 12-23
Assigning servers to the large farm topology
F12XR23
Specifying the Global E-mail Server
If you want portal sites in your farm to send e-mail alerts and e-mail invitations to
other sites on those portal sites, you need to specify a global e-mail server for the
farm, as outlined in the following procedure and illustrated in Figure 12-24.
Chapter 12:
Figure 12-24
F12XR24
Deploying Medium and Large Server Farms
307
Configuring Global E-mail Server settings
To specify a global e-mail server
1. On the Configure Server Topology page, click the name of the current global
e-mail server (should currently be “unknown”).
2. Enter the Fully Qualified Domain Name (FQDN) of your e-mail server, an e-mail
address to send from, and a reply-to e-mail address.
Note The e-mail address you specify to have the e-mail sent from must
have anonymous SMTP access. If your server requires authentication for
the specified user, the portal site will be unable to send e-mail alerts.
Creating Portal Sites
Each portal site you want to have must be created separately on its own virtual
server, and each will need to have its own URL. The following sections detail all the
steps involved with creating new portal sites.
Creating Virtual Servers
Working in a load-balanced environment, the following IIS virtual server parameters
must be configured the same on each front-end Web server:
■
Virtual Web name
308
Part IV: Deployment Scenarios
■
Virtual Web IP address
■
Application pool
■
Virtual Web-file system directory name and location
To create the virtual servers for a new portal site
1. Open Administrative Tools and then click Internet Information Services.
2. Right-click the Web Sites container, point to New, and then click Web site.
3. Follow the directions to start the wizard. On the Web Site Description page,
enter a description (such as “SharePoint Cluster,” which is used in Figure 12-25),
and then click Next.
F12XR25
Figure 12-25
Entering a description for the virtual server
4. On the IP Address And Port Settings page, select the IP address of the cluster
in the Enter the IP address to use for this Web site box. Leave the default
TCP port of 80 in the TCP port this Web site should use (Default 80) box,
as illustrated in Figure 12-26.
5. On the Web Site Home Directory page, enter the path to the folders that contain the Web site for the virtual server, as illustrated in Figure 12-27. (This can be
any physical file folder except Inetpub\wwwbin, because that folder is already
used by the default virtual server.) Deselect the Allow anonymous access
check box, and then click Next.
6. On the Web Site Access Permission page, verify that only Read and Run scripts
(such as Active Server Pages [ASP]) are selected, and then click Next. Finish the
wizard.
7. Repeat the preceding steps on each front-end Web server.
Chapter 12:
Deploying Medium and Large Server Farms
309
F12XR26
Figure 12-26
Configuring IP and Port Settings
Figure 12-27
Configuring the home directory
F12XR27
More Info For more information, see “Extending Virtual Servers” in the
SharePoint Portal Server 2003 Administrator’s Guide, which is accessible
from the Start menu.
Creating a Portal Site
Once IIS is installed and configured on each server running SharePoint Portal Server
and the farm topology is set up properly, it is time to create portal sites on the farm.
Each portal site has its own content and settings. Each portal site hosted on the farm
310
Part IV: Deployment Scenarios
can be considered to be a separate entity. If you use shared services, which are covered in Chapter 23, “Personalization Services in SharePoint Products and Technologies” you can share indexing, My Sites, and user profiles between portal sites to
conserve resources. This section will describe how to create the first portal site in
the farm, but the same procedure can be applied for each additional portal site to be
created. (See Figure 12-28.) A portal site farm must contain at least one portal site.
Figure 12-28
F12XR28
Creating a portal site
To create a portal site
1. Click Start, point to All Programs, point to SharePoint Portal Server, and
then click SharePoint Central Administration.
2. In the Portal Site and Virtual Server Configuration section, click Create a
Portal Site.
3. On the Create a Portal Site page, verify that Create a portal is selected.
4. Fill in the Site Name of the Portal (in this example, Woodgrove Bank), select
the virtual server created previously (SharePoint Cluster), and enter the
account and e-mail address of the portal site owner. (See Figure 12-28.)
5. Click OK to continue. Click OK to confirm portal creation. A progress bar will
display the status of the creation.
Note If portal site creation fails, check the log file to determine the cause
of failure. Correct the problem and try again. Often a creation failure is
related to accounts not having proper permissions.
Chapter 12:
Deploying Medium and Large Server Farms
311
After you have created the portal site on the first load-balanced server, you
must extend it to subsequent virtual servers.
To extend the portal site to the virtual servers
1. On the Operation Successful page, in the Server Extension Links section,
click Link to a Virtual Server Extension Page for server-name (SPS-02), as
illustrated in Figure 12-29.
F12XR19
Figure 12-29
Portal creation finished page
2. The Virtual Server List administration page for that front-end Web server opens.
Click the name of the virtual server to which you want to extend the portal site
(SharePoint Cluster) as illustrated in Figure 12-30.
3. This opens the Extend Virtual Server administration page. Click Extend and
map to another virtual server.
4. On the Windows SharePoint Services Extend And Map To Another Virtual Server
page, in the Server Mapping section, click the name of the virtual server the
portal site was created on in the list.
5. In the Application Pool section, click Use an existing application pool,
select the portal site application pool that was created previously in this chapter, and then set the application pool. Click OK.
6. SharePoint Portal Server will now contact each front-end server to update its
configuration. You might be prompted for local administrator credentials for all
the other SharePoint Portal Server–based servers joined to the topology. On the
Refresh Config Cache On Other Web Servers page, click OK as illustrated in
312
Part IV: Deployment Scenarios
Figure 12-31. (You will see SPS-04, SPS-05 listed as well if you are performing
a large farm installation.)
F12XR30
Figure 12-30
Extending the portal site to other virtual servers
7. Repeat as necessary for each front-end server.
F12XR31
Figure 12-31
Extending the virtual server completed successfully
Chapter 12:
Deploying Medium and Large Server Farms
313
Note If the server has Internet Explorer Enhanced Security Configuration
enabled, you must add each server’s administration website to Internet
Explorer’s Trusted Sites list.
Now that the portal site is created, it should be verified to ensure it is functioning properly.
Open Internet Explorer. In the address bar, type the address of the portal site
you created (for example, http://cluster.sps.test.local). It should look similar to
Figure 12-32.
Figure 12-32
F12XR32
The successfully created portal site
Configuring Alternate URLs
The portal site has been created but is accessible only by the URL http://cluster.sps
.test.local. This URL is the default portal URL and is used for crawling portal site
content, but a different URL can be configured to allow easier access by end users.
An alias record should be created in DNS for the URL end users will access, and that
address should be specified in Alternate Access Mappings (shown in Figure 12-33)
in SharePoint Central Administration.
314
Part IV: Deployment Scenarios
Figure 12-33
F12XR33
Setting alternate access URLs
Note If you do not know how to set up an alias record in DNS or do not
have permissions to do so, you should contact your DNS administrator to
get this set up.
More Info Extranets and Alternate Access Mappings will be covered in further detail in Chapter 13, “Installing and Configuring Windows SharePoint
Services in an Extranet.”
To configure Alternate Access Mappings
1. Click Start, point to All Programs, point to SharePoint Portal Server, and
then click SharePoint Central Administration.
2. In the Portal Sites and Virtual Server Configuration section, click Configure alternate portal site for intranet, extranet, and custom access.
3. Click the arrow next to the mapping name to configure, and then click Edit on
the menu.
Chapter 12:
Deploying Medium and Large Server Farms
315
4. In the Intranet URL box, enter the address of the alias that was set up in DNS
(http://woodgrovebank).
5. Click OK.
Summary
In this chapter, you learned about medium and large server farms. You should be
able to plan a farm and successfully build that farm. The chapter also covered configuring and testing Network Load Balancing. You are now ready to implement
additional portal sites and customize your main portal site.
Chapter 13
Installing and Configuring
Windows SharePoint
Services in an Extranet
In this chapter:
Setting Up an Intranet and Extranet Deployment . . . . . . . . . . . . . . . . . . . 318
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 338
Note At the time we had to go to press with this chapter, the information on how
to use Microsoft Office SharePoint Portal Server 2003 extranets was in the beta
stages of being written. Therefore, this chapter will focus entirely on Microsoft
Windows SharePoint Services. For more information on how to use SharePoint Portal Server extranets, please visit http://office.microsoft.com/home
/office.aspx?assetid=FX010909721033&CTT=6&Origin=ES790020011033.
—Bill English
Business-to-business collaboration and resource sharing allows a company and its
partners to work more effectively towards reaching business goals. A connection to
the Internet facilitates the flexibility and convenience of accessing data at any time
or place. Although an extranet portal might be convenient for your employees, your
extranet is typically a mission-critical necessity for both partners and internal business
units that work with them. Therefore, partners and business units are very sensitive
to the timeliness of the extranet service. Business functions often depend on the data
that is exchanged, so delays can be very costly. The extranet needs to be reliable, and
the partners and business units need to be able to contact someone who can quickly
resolve issues when they arise.
317
318
Part IV: Deployment Scenarios
Although the title of this chapter and the preceding paragraph focus heavily on
the concept of setting up an extranet for business partners, you will find information
in this chapter about how to deploy a Windows SharePoint Services intranet as well.
Because, after all, our internal customers are just as important as those who use the
extranet!
If you are running an extranet that does not require advanced security, setting
up access to the portal site is as easy as passing out the URL to the portal site and
ensuring that each user has been added to the portal site with at least Read permission.
Situations in which you might want to run an extranet without advanced security
include using the portal site to offer public information for anonymous users and
working in an enterprise where each division has its own portal site and security settings but you need to allow users from other divisions access to your portal site content.
In either situation, advanced security such as SSL and client certificates might be in
order, but it is plausible that using the built-in security in the portal site might be
appropriate, too. It really depends on the sensitivity of the information being passed
back and forth between the client and the server and how trusted the communication
path is between these two parties.
Setting Up an Intranet and Extranet Deployment
This section describes the steps you need to take to configure the servers in your
server farm to serve the same content for both an intranet and extranet.
You can install and configure Windows SharePoint Services to allow your
server farm to provide the same content to both an intranet and an extranet site.
There are two ways to make this happen:
■
Use two virtual servers on separate server computers, configured differently, or
■
Use two virtual servers on one machine. One virtual server running on port 80
exposed via the firewall and the second virtual server running on a different
port that can be accessed via the internal network.
Following is the procedure to use two virtual servers on separate computers:
■
One virtual server is configured with Integrated Windows authentication and
an internal address so that internal users can be authenticated automatically
and view the content from inside the intranet. For example, http://My_Server.
■
The other virtual server is configured with another authentication type (for
example, Basic authentication with Secure Sockets Layer [SSL]) and an external
address so that external users can log in and view the content across the Internet
(for example, https://My_Server.extranet.example.com).
Both of these virtual servers point to the same content: changes made to a site
on the extranet are reflected on the intranet, and vice versa. The only differences are
the URL used to access the content and the authentication method used to log in. It
Chapter 13: Installing and Configuring Windows SharePoint Services in an Extranet
319
is recommended that both environments use Windows domain accounts to authenticate users, whether you choose Integrated Windows authentication, Basic authentication, or some other authentication method.
Caution Be aware that you can configure your virtual servers to use both
Basic authentication and Integrated Windows authentication at the same
time. When the client connects to the server, it will attempt authentication
via the most secure method. If that method fails, it will attempt to authenticate the user via the next most secure method. The virtual server will continue
this process for as many authentication methods as are configured until it
succeeds or all methods fail.
You might consider this technique if you do not want to actually create
two virtual servers. You can create only one virtual server and configure it to
allow both authentication methods.
Preparing the Servers
Before you can install and configure Windows SharePoint Services for both an intranet
and an extranet, you must be sure you meet the hardware and software requirements.
The following sections help you review the requirements.
Hardware and Software Requirements
To be able to set up Windows SharePoint Services in an intranet and extranet configuration, you must meet the following criteria:
■
The front-end Web servers must be running Microsoft Windows Server 2003
(Standard or Enterprise Edition). Notice that the hardware requirements for
Windows SharePoint Services are the same as the Windows Server 2003 installation requirements.
Note If you are installing Windows SharePoint Services on Windows
Server 2003 Web Edition, you must be running the SQL database on a different server. They cannot coexist on this platform. Therefore, you must use
the remotesql=yes parameter to install Windows SharePoint Services on a
computer running Windows Server 2003 Web Edition. In addition, the Web
Edition of Windows 2003 will not support running either the Index or Search
applications for SharePoint Portal Server, which means that when running a
server farm, you can use the Web Edition only if your Web front-end servers
are not also configured to be Search, Index, or Job Servers.
320
Part IV: Deployment Scenarios
■
■
The front-end Web servers must be configured as Web servers (running
Internet Information Services in IIS 6.0 worker process isolation mode)
and must be running ASP.NET. For more information about installing
and configuring IIS and ASP.NET, see the Windows Server 2003 Family
documentation.
■
The front-end Web servers must be using the NTFS file system. Microsoft Windows includes a conversion utility (Convert.exe) that you can use to convert
an existing file allocation table (FAT) volume to NTFS—without losing data.
The back-end servers must be running Microsoft SQL Server 2000 Service
Pack 3 or later.
Note It is not required to have a dedicated SQL server in smaller deployments. Smaller organizations might choose to run a number of services on
one machine, including Windows SharePoint Services and SQL. On the other
hand, for large deployments you might want to have multiple SQL servers to
balance the load across servers.
■
The client computers must be running Microsoft Internet Explorer 5 or later (with
the best results coming from Microsoft Internet Explorer 5.5 or later) or Netscape
Navigator 6.2 or later to use Windows SharePoint Services website features.
Planning for Scale
You can use the same front-end Web server to host both your intranet and extranet
virtual servers, or you can split them across two separate servers. If you anticipate a
heavy load on either your intranet or extranet, you should use separate front-end
Web servers for each environment so that heavy use of your extranet server does not
affect the availability of your intranet server and vice versa. This section describes the
steps you need to take to use separate front-end Web servers for each environment.
You can also use multiple front-end Web servers to host both virtual servers, as in a
standard server farm, to reduce potential downtime.
An important performance feature of Windows SharePoint Services is the ability
to load balance across Web front-end servers, which will make the most of a server
farm environment. Windows SharePoint Services works with most standard loadbalancing methods available. Each method has its own set of pros and cons relative
to cost, processing power, and scale. You can use any of the following methods with
Windows SharePoint Services:
■
Software solutions, such as Network Load Balancing. Software, such as
Network Load Balancing (NLB) services in Windows Server 2003. This method is
inexpensive but offers only limited scalability. NLB runs on the Web front-end
Chapter 13: Installing and Configuring Windows SharePoint Services in an Extranet
321
servers and uses the TCP/IP networking protocol to route requests. Because
NLB (and other software load-balancing solutions) run on the Web front-end
servers, it uses the Web front-end system resources, trimming the resources
you can use for serving Web pages. However, the impact on system resources
is not great, and a software solution can handle up to 32 Web front-end servers.
■
Software configuration solutions, such as using the domain name system
to route requests. You can configure your domain name system (DNS) to
create a primitive load-balancing system. For more information about DNS, see
your Windows Server 2003 documentation.
■
Hardware load balancing. This method uses hardware such as a router or
switch box. Load-balancing hardware uses your network to direct website traffic between your Web front-end servers. Load-balancing hardware is more
expensive to set up than software but does not use up any of your Web frontend server resources to run and is the most scalable method. Windows SharePoint Services can be used with any load-balancing hardware. In addition,
hardware load balancing provides the best use of your Web front-end server
resources.
You do not need to perform any configuration steps to make Windows SharePoint Services work with any of these load-balancing methods. Simply set up the
load-balancing method in your server farm, and either install or continue using Windows SharePoint Services.
Preparing the Database Back-End Servers
To set up your database back-end servers, you must perform the following steps:
■
Install SQL Server 2000, Service Pack 3. You can use SQL Server 2000
Standard or Enterprise Edition with Windows SharePoint Services. For more
information about installing SQL Server, see the SQL Server 2000 documentation.
■
Set a strong password for your SQL Server administration account. You
must know both the administrator user account and password to be able to
connect between Windows SharePoint Services on the front-end Web servers
and SQL Server on the back-end servers. You should set a strong password
for the administration account. If you are using Windows Authentication (recommended), you should use a domain account with permissions to create databases in SQL Server. If you are using SQL Server authentication, the
“sa” account should have a strong password. For more information about
setting the administrator user name and password, see the SQL Server 2000
documentation.
■
Configure the authentication method for connections between the Web
servers and SQL Server. For better security in your server farm, you should
use Microsoft Windows NT authentication, rather than SQL Server authentication,
322
Part IV: Deployment Scenarios
for connections between your front-end Web servers and the database backend servers. Windows NT authentication uses a domain user account to control
access to SQL Server, rather than storing credentials in the registry and passing
them across the network as in SQL Server authentication.
You configure the authentication method for SQL Server by using the SQL
Server Enterprise Manager.
To configure authentication for SQL Server
1. On the database back-end servers, click Start, point to All Programs, point to
Microsoft SQL Server, and then click Enterprise Manager.
2. Click the plus sign (+) next to Microsoft SQL Servers.
3. Click the plus sign (+) next to SQL Server Group.
4. Right-click the SQL server name, and click Properties.
5. In the Properties dialog box, click the Security tab.
6. Under Authentication, click Windows only and then click OK.
Configuring the Intranet Front-End Server
To configure your intranet front-end Web server, you must perform the following steps:
■
Configure the intranet server as a Web server. You must be running
Internet Information Services (IIS) 6.0 on your Web server, and you must set it
to run in IIS 6.0 worker process isolation mode instead of IIS 5.0 isolation
mode. To communicate with SQL Server 2000 on the back-end servers, you
must also configure the front-end Web server to use the TCP/IP protocol rather
than Named Pipes (the default).
■
Create the intranet virtual server and configure the authentication
method. If you are not using the default virtual server in IIS, you must create
a new virtual server and map it to the host name of the server that will provide
the content. The simplest way to set up an extranet is to use the default virtual
server in IIS. Whichever method you choose, you must specify the authentication
method (Integrated Windows authentication in this case) to use for the virtual
server.
■
Install Windows SharePoint Services in the server farm configuration, and
create the administration virtual server and configuration database. You
must install Windows SharePoint Services on each front-end Web server. Using
the remote SQL Server option allows you to install Windows SharePoint Services
without also installing Microsoft Data Engine (MSDE). You must also create the
administration virtual server and configuration database. You need to create the
configuration database only when you configure the first front-end Web server;
Chapter 13: Installing and Configuring Windows SharePoint Services in an Extranet
323
for subsequent front-end servers (including the extranet server), you can simply
connect to the Windows SharePoint Services configuration database.
■
Extend the intranet virtual server. Before you can create sites, you must
extend the intranet virtual server. The intranet virtual server is connected to the
same content databases as the extranet virtual server so that they provide the
same site content.
To perform these steps for a server farm, you should use the command-line
administration tool, Stsadm.exe.
Configuring the Intranet Server as a Web Server
IIS is not enabled by default in Windows Server 2003. To make your front-end server
into a Web server, you must enable IIS.
To enable IIS and configure it to use IIS 6.0 worker process isolation mode
1. Click Start, and then click Manage Your Server.
2. On the Manage Your Server page, click Add or remove a role.
3. On the Preliminary Steps page, click Next.
4. On the Server Role page, click Application server (IIS, ASP.NET) and then
click Next.
5. On the Web Application Server Options page, accept the default of ASP.NET
and then click Next.
6. On the Summary Of Selections page, click Next.
7. Click Finish.
8. Click Start, point to Administrative Tools, and then click Internet Information Services (IIS).
9. In Internet Information Services manager, click the plus sign (+) next to the
server name, right-click the Web Sites folder, and select Properties.
10. In the Properties dialog box, click the Service tab.
11. In the Isolation mode section, clear the Run WWW service in IIS 5.0 isolation mode check box and then click OK.
Note The Run WWW service in IIS 5.0 isolation mode check box is
selected only if you have upgraded to IIS 6.0 on Windows Server 2003 from
IIS 5.0 on Windows 2000. New installations of IIS 6.0 default to IIS 6.0
worker process isolation mode.
324
Part IV: Deployment Scenarios
Creating the Intranet Virtual Server and Configuring Authentication
When IIS is configured and ready to work with SQL Server, you can create the virtual
server you need to host the intranet sites.
To create a virtual server
1. Click Start, point to Programs, point to Administrative Tools, and then click
Internet Information Services.
2. Click the plus sign (+) next to the server name you want to add a virtual server to.
3. Right-click the Web Sites folder, click New, and then click Web site.
4. Click Next.
5. In the Description box, type the description of your virtual server and then
click Next.
6. In the Enter the IP address to use for this Web site box, select the IP
address you want to use, if appropriate, or use the default (All Unassigned) if
that fits your deployment.
7. In the TCP port this Web site should use (Default: 80) box, type the port
number to assign to the virtual server.
You do not need to assign a host header, because the hosting is being handled
through Windows SharePoint Services.
8. Click Next.
9. In the Path box, type or browse to the path on your hard disk where the site
content will go.
10. If you do not want to allow anonymous access to your virtual server, clear the
Allow anonymous access to this Web site check box.
11. Click Next.
12. On the Web Site Access Permissions page, select the permissions to use and
then click Next. The default permissions, Read and Run Scripts (such as ASP), are
recommended. The Execute (such as ISAPI applications or CGI) permission will be
added automatically to the appropriate folders by Windows SharePoint Services.
13. Click Finish.
Now you can configure the authentication method to use for the intranet
virtual server.
To configure the authentication method for the intranet virtual server
1. On the intranet front-end Web server, in Internet Information Services,
right-click the virtual server that will be used for the intranet site, and then click
Properties.
Chapter 13: Installing and Configuring Windows SharePoint Services in an Extranet
325
2. On the Directory Security tab, under Authentication and access control,
click Edit.
3. Select the Integrated Windows authentication check box, and clear all
other authentication method check boxes.
4. Click OK to close the Authentication Methods dialog box.
5. Click OK again to close the Properties dialog box.
Installing and Configuring Windows SharePoint Services on the
Intranet Front-End Web Server
You must install Windows SharePoint Services in the server farm configuration. To do so,
you use the setupsts.exe command with the remotesql property on the command line.
To install Windows SharePoint Services with the Remote SQL Server option
1. Insert the Windows SharePoint Services compact disc into your CD drive.
2. Open a command prompt window, and navigate to the root folder on the
CD drive.
3. Run the following command:
setupsts.exe remotesql=yes
4. Follow the prompts to install Windows SharePoint Services.
After setup, you can create the administration virtual server and configuration database. If you want to set up a server farm environment, you can use the
command-line administration tool to create the configuration database and include
the -hh parameter.
Table 13-1 displays the Stsadm.exe command-line utility that will create the configuration database or specify the connection to an existing configuration database.
Setting the configuration database is required before a virtual server can be extended.
Table 13-1
Stsadm.exe Command-Line Utility
Required Parameters
Optional Parameters
-databaseserver (ds)
-connect
-databaseuser (du)
-databasepassword (dp)
-databasename (dn)
-hh
-adcreation
-addomain
-adou
326
Part IV: Deployment Scenarios
A sample syntax is as follows:
stsadm.exe -o setconfigdb [-connect] -ds <database server> [-du <database user>]
[-dp <database user password>] [-dn <database name>] [-hh] [-adcreation]
[-addomain <AD domain> [-adou <AD OU>]
To create the administration virtual server from the command line
1. Open a command prompt window, and navigate to the \Program Files
\Common Files\Microsoft Shared\Web Server Extensions\60\bin folder.
2. Run the following command to create the administration virtual server:
stsadm.exe -o setadminport -port <port> -admapcreatenew -admapidname <id for
application pool> -admapidtype <configurableid/NetworkService/LocalService
/LocalSystem> -admapidlogin <user account for the application pool>
-admapidpwd <password>
An example of this is as follows:
stsadm.exe –o setadminport –port 1035 –admapcreatenew –admapidname DefaultAppPool
-admapidtype configurableid –admapidlogin DOMAIN\user1 –admapidpwd [email protected]
In the preceding Stsadm.exe example, Setadminport sets the port number for
the administration virtual server for Windows SharePoint Services. The ssl parameter is
used to specify a Secure Sockets Layer (SSL) connection to the port. The admap...
parameters are used to specify the IIS application pool to use or to create a new IIS
application pool for the administration virtual server. See Table 13-2 for a listing of
the required and optional stsadm.exe parameters relative to creating a virtual server
from the command line.
Table 13-2
Stsadm.exe Parameters
Required Parameters
-port
Optional Parameters
-admapcreatenew
-admapidloginname
-admapidnametype
-admapidpwdlogin
-admapidtypepwd
-ssl
Parameter
Definition
admapcreatenew
Specifies that a new application pool is created in Internet Information Services (IIS).
admapidlogin
The user name to use for running processes in the administrative
application pool. This value must be a Windows NT user account
name and must be qualified with a domain name—for example,
DOMAIN\name.
Chapter 13: Installing and Configuring Windows SharePoint Services in an Extranet
Table 13-2
Stsadm.exe Parameters
327
(continued)
Parameter
Definition
admapidname
The administrative application pool ID.
admapidpwd
The password that corresponds to the admapidlogin.
admapidtype
The identity type to use for the administrative application pool.
For example, you can use an account you have created in the
directory (configurableid) or one of three predefined accounts
(NetworkService/LocalService/LocalSystem).
Note You can use any unused port between 1023 and 32767. The application pool account must have database owner (DBO) rights to the SQL Server
computer to be able to create the configuration database. You should use a
dedicated domain account for this account rather than a user’s login account.
Also, you should use the same account for each application pool that hosts
the same content.
If you have used a domain account that does not already have database creation
rights in SQL Server, you can give the account this access in SQL Server Enterprise
Manager. This is a one-time only change. Once you have granted database creation
permissions to the account used by the Windows SharePoint Services administration
virtual server, this account can create any subsequent databases. You do not need
database creation rights to connect to a configuration database, which you will do
when you set up the front-end Web server for the extranet.
To grant database creation rights in SQL Server
1. On your SQL Server computer, click Start, point to Programs, point to
Microsoft SQL Server, and then click Enterprise Manager.
2. In Enterprise Manager, click the plus sign (+) next to Microsoft SQL Servers,
click the plus sign (+) next to SQL Server Group, and then click the plus sign (+)
next to your SQL Server.
3. Click the plus sign (+) next to Security, right-click Logins, and then click New
Login.
4. In the Name box, type the account in the form DOMAIN\name.
Note If Windows SharePoint Services is running under the NT Authority
\NetworkService account, the login ID should be “Domain\Machinename$”.
328
Part IV: Deployment Scenarios
5. Click the Server Roles tab.
6. In the Server Role list, select the Security Administrators and Database
Creators check boxes, and then click OK.
After you configure the administrative virtual server (and grant SQL Server
rights to the new application pool account, if necessary), you must restart IIS by typing
iisreset on the command line. After IIS is reset, you can continue configuring Windows SharePoint Services to work with your remote SQL Server.
To create the configuration database from the command line
Run the following command to create the configuration database:
stsadm.exe -o setconfigdb -databaseserver <database server name>
-databasename sts_config
The syntax shown is for Windows authentication. If you are using SQL Server
authentication, you must also specify the -du and -dp parameters with the database
username and password. To connect to the configuration database from subsequent
front-end Web servers, use the following syntax:
stsadm.exe -o setconfigdb -databaseserver <database server name> [-databaseuser
<database user> -databasepassword <password>] -databasename sts_config
Following is an example of what a command might look like:
stsadm.exe –o setconfigdb –My_server –databaseuser DOMAIN\user1 –databasepassword
[email protected] –databasename My_co_database
To create the administration application pool and configuration database
using HTML Administration pages
1. When setup finishes, you are taken to the Configure Admin Virtual Server
page.
2. In the Application Pool section, select Create a new application pool.
3. Under Select a security account for this application pool, select Configurable.
4. In the User name box, type the domain account to use for the application
pool.
This account must have DBO rights to the SQL Server computer to be able to
create the configuration database. You should use a dedicated account for this
account rather than a user’s login account. Also, you should use the same
account for each application pool that hosts the same content.
5. In the Password box, type the password for the account, confirm it, and then
click OK.
The application pool is created, and you are taken to a confirmation page. You
must restart IIS to accept the change.
Chapter 13: Installing and Configuring Windows SharePoint Services in an Extranet
329
6. After restarting IIS, click the link to continue, and on the Create Configuration
Database page, in the Configuration Database section, enter the server name
and database name to use.
7. Select Use Integrated Windows authentication (more secure, recommended).
8. In the Active Directory Account Creation section, select Users already
have domain accounts if you are using a Windows domain, or Automatically create active directory accounts for users of this site if you are using
Active Directory outside of a Windows domain.
9. If you selected Automatically create active directory accounts for users of
this site, you must fill in the Active Directory Domain and Organization
Unit information.
10. Click Submit.
11. On the SharePoint Central Administration page, in the Server Configuration
section, click Set default content database server.
12. On the Content Database Server page, in the Content Database Server section,
enter the server name, administrator account username, and password.
13. Click Submit.
Extending the Intranet Virtual Server
With the administration virtual server and configuration database in place, you can
extend the virtual server to host the intranet sites. You can use either the command
line or HTML Administration pages to extend the virtual server.
To extend the virtual server using the command line
1. Open a command prompt window, and navigate to the \Program Files
\Common Files\Microsoft Shared\Web Server Extensions\60\bin folder.
2. Run the following command to extend the intranet virtual server:
stsadm.exe -o extendvs -url http://servername -ownerlogin <DOMAIN\username>
-owneremail <e-mail address> [-ownername <display name> [-databaseuser
<database user> -databaseserver <database server> -databasename
<database name> -databasepassword <database password> -lcid <locale
ID> -sitetemplate <template name> -apcreatenew -apidname
<application pool name> -apidtype <configurableid/NetworkService/
LocalService/LocalSystem> -apidlogin <DOMAIN\username> -apidpwd <password>]
Example:
stsadm.exe –o extendvs –url http://My_Server –ownerlogin DOMAIN\user1
–owneremail [email protected] –ownername [email protected] –databaseuser
[email protected] –databaseserver SQL_Server –databasename My_Co_Database
–databasepassword [email protected] –lcid 1033 –sitetemplate Sales_Template
–apcreatenew –apidname NewAppPool -apidtype configurableid –admapidlogin
DOMAIN\user1 –apidpwd [email protected]
330
Part IV: Deployment Scenarios
Note that while the apid... parameters are optional, it is recommended that you
create a new application pool for the virtual server. Use a dedicated application pool
account, not a user login account. The application pool account for a virtual server
does not need database owner rights on the SQL Server computer. Note that the -du
and -dp parameters are not needed if you are using Windows authentication to connect to SQL Server.
To extend the virtual server using HTML Administration pages
1. On the Central Administration page, in the Virtual Server Configuration section, click Extend or upgrade virtual server.
2. On the Virtual Server List page, click the name of the virtual server to extend.
3. On the Extend Virtual Server page, in the Provisioning Options section, click
Extend and create a content database.
4. In the Application Pool section, select Create a new application pool.
5. Under Select a security account for this application pool, click
Configurable.
6. In the User name box, type the domain account to use for the application pool.
You should use a dedicated account for this account rather than a user’s login
account. Also, you should use the same account for each application pool that
hosts the same content.
7. In the Password box, type the password for the account and then confirm it.
8. In the Site Owner section, in the User name box, type the user name for the
site owner (in the format DOMAIN\username if the username is part of a Windows domain group).
9. In the E-mail box, type the e-mail address that corresponds to the account.
10. In the Database Information section, enter the following database connection information:
■
In the Database server box, type the server name for your SQL Server.
■
In the Database name box, type the name to use for your content
database.
11. If you want to specify a path for the URL, in the Custom URL path box, type
the path to use.
12. If you are using quotas, select a template in the Select a quota template box
of the Quota Template section.
13. In the Site Language section, select the language to use.
14. Click OK.
Chapter 13: Installing and Configuring Windows SharePoint Services in an Extranet
331
Note For a basic test scenario where you are hosting the same content
from two virtual servers, you can create a second virtual server on the intranet
front-end server and extend it using the Extend and connect to an existing
content database. On the Extend And Connect To An Existing Content Database page, select the first virtual server you extended. When you click OK,
the content will be hosted from both virtual servers.
Configuring the Extranet Front-End Server
To configure your extranet front-end Web server, you must perform the following steps:
■
Configure the server as a Web server. You must be running IIS 6.0 on your
Web server, and you must set it to run in IIS 6.0 worker process isolation mode
instead of IIS 5.0 isolation mode.
■
Switch to using the TCP/IP protocol for the connections between the Web
servers and SQL Server. To communicate with SQL Server 2000 on the backend servers, you must configure the front-end Web servers to use the TCP/IP
protocol rather than Named Pipes (the default).
■
Create a virtual server and configure the authentication method. Before
you can create sites for your extranet, you must create the virtual server to contain
them in IIS and specify the authentication method to use (Basic authentication
with Secure Sockets Layer in this case).
■
Install Windows SharePoint Services in the server farm configuration. You must install Windows SharePoint Services on each Web front-end
server. Using the remote SQL Server option allows you to install Windows
SharePoint Services without also installing Microsoft Data Engine (MSDE). You
must also create an application pool for the extranet sites and connect to the
configuration database after installation.
■
Extend the virtual server. Before you can create sites, you must extend the
extranet virtual server. The extranet virtual server is connected to the same content
databases as the intranet virtual server so that they provide the same site content.
To perform these steps for a server farm, you should use the command-line
administration tool, Stsadm.exe.
IIS is not enabled by default in Windows Server 2003. To make your front-end
servers into Web servers, you must enable IIS.
To enable IIS and configure it to use IIS 6.0 worker process isolation mode
1. Click Start, and then click Manage Your Server.
2. On the Manage Your Server page, click Add or remove a role.
332
Part IV: Deployment Scenarios
3. On the Preliminary Steps page, click Next.
4. On the Server Role page, click Application server (IIS, ASP.NET) and then
click Next.
5. On the Web Application Server Options page, accept the default of ASP.NET
and then click Next.
6. On the Summary Of Selections page, click Next.
7. Click Finish.
8. Click Start, point to Administrative Tools, and then click Internet Information Services (IIS).
9. In Internet Information Services manager, click the plus sign (+) next to the
server name, and then right-click the Web Sites folder and select Properties.
10. In the Properties dialog box, click the Service tab.
11. In the Isolation mode section, clear the Run WWW service in IIS 5.0 isolation mode check box, and then click OK.
When IIS is configured and ready to work with SQL Server, you can create the
virtual server you need to host the extranet sites.
To create a virtual server
1. Click Start, point to Programs, point to Administrative Tools, and then click
Internet Information Services.
2. Click the plus sign (+) next to the server name you want to add a virtual
server to.
3. Right-click the Web Sites folder, click New, and then click Web site.
4. Click Next.
5. In the Description box, type the description of your virtual server and then
click Next.
6. In the Enter the IP address to use for this Web site box, select the IP address
you want to use.
7. In the TCP port this Web site should use (Default: 80) box, type the port
number to assign to the virtual server.
8. In the Host Header for this site (Default: None) box, type the header you
want to use and then click Next.
9. In the Path box, type or browse to the path on your hard disk where the site
content will go.
Chapter 13: Installing and Configuring Windows SharePoint Services in an Extranet
333
10. Clear the Allow anonymous access to this Web site check box, and then
click Next.
11. On the Web Site Access Permissions page, select the permissions to use and
then click Next.
If other users are allowed to contribute to the site, you must select at least the
Read, Write, and Browse check boxes. If your virtual server allows scripts to
be run, you must also select the Run scripts (such as ASP) check box. If you
want to allow ISAPI applications or CGI scripts to be used on your virtual
server, you must also select the Execute (such as ISAPI applications or CGI)
check box.
12. Click Finish.
Now you can configure the authentication method to use for the extranet virtual server.
To configure the authentication method for the extranet virtual server
1. On the extranet front-end Web server, in Internet Information Services,
right-click the virtual server that will be used for the extranet site, and then
click Properties.
2. On the Directory Security tab, under Authentication and access control,
click Edit.
3. Select the Basic authentication check box, and clear all other authentication
method check boxes.
4. Click OK to close the Authentication Methods dialog box.
5. On the Directory Security tab, under Secure communications, click Edit.
6. In the Secure Communications dialog box, select the Require secure channel (SSL) check box and then click OK.
7. Click OK again to close the Properties dialog box.
Note You must have a certificate before you can enable SSL. For more
information about SSL certificates, see the topics “About Certificates” and
“Setting Up SSL on Your Server” in IIS 6.0 online Help. For more information about IIS authentication methods, see the topic “About authentication”
in IIS 6.0 online Help.
After you have configured the authentication method, you can install Windows
SharePoint Services.
334
Part IV: Deployment Scenarios
Installing and Configuring Windows SharePoint Services on the
Extranet Front-End Web Server
You must install Windows SharePoint Services in the server farm configuration. To
do so, you use the setupsts.exe command with the remotesql property on the command line. Follow the procedure detailed earlier in this chapter, “To install Windows
SharePoint Services with the Remote SQL Server option.”
To set the application pool for the administration virtual server and connect
to the configuration database from the command line
1. Open a command prompt window, and navigate to the \Program Files
\Common Files\Microsoft Shared\Web Server Extensions\60\bin folder.
2. Run the following command to create the administration virtual server:
stsadm.exe -o setadminport -port <port> -admapcreatenew -admapidname
<id for application pool> -admapidtype configurableid -admapidlogin
<DOMAIN\username> -admapidpwd <password>
Example:
stsadm.exe –o setadminport –port 1035 –admapcreatenew
–admapidname NewAppPool –admapidtype configurableid
–admapidlong DOMAIN\user1 –admapidpws [email protected]
Note You can use any unused port between 1023 and 32767. You should
use a dedicated account for the application pool account rather than a user’s
login account. Also, you should use the same account for each application
pool that hosts the same content.
3. Restart IIS by running iisreset on the command line.
4. Run the following command to connect to the configuration database:
stsadm.exe -o setconfigdb -ds <database server name> [-du <database user>
-dp <password>] -dn sts_config
The syntax shown is for Windows authentication. If you are using SQL Server
authentication, you must also specify the -du and -dp parameters with the database
username and password.
To set the application pool for the administration virtual server and connect
to the configuration database using HTML Administration pages
1. When setup finishes, you are taken to the Security And Configuration
Database page.
Chapter 13: Installing and Configuring Windows SharePoint Services in an Extranet
335
2. In the Application Pool section, select Define a new application pool.
3. Under Select a security account for this application pool, select
Configurable.
4. In the User name box, type the domain account to use for the application pool.
This account must have DBO rights to the SQL Server computer to be able to
create the configuration database. You should use a dedicated account for this
account rather than a user’s login account. Also, you should use the same
account for each application pool that hosts the same content.
5. In the Password box, type the password for the account, confirm it, and then
click OK.
6. The application pool is created, and you are taken to a confirmation page. You
must restart IIS to accept the change. To restart IIS, type iisreset on the command line.
7. After restarting IIS, click the link to continue, and on the Create Configuration
Database page, in the Configuration Database section, enter the server name
and database name for the existing configuration database.
8. Select Use Integrated Windows authentication (more secure, recommended).
9. Select the Connect to existing database check box.
10. In the Active Directory Account Creation section, select Users already
have domain accounts if you are using a Windows domain, or Automatically create active directory accounts for users of this site if you are using
Active Directory outside of a Windows domain.
11. If you selected Automatically create active directory accounts for users of
this site, you must fill in the Active Directory Domain and Organization
Unit information.
12. Click Submit.
13. On the Central Administration page, under Server Configuration, click Set
default content database server.
14. On the Set Default Content Database Server page, in the Content Database
Server section, enter the server name, administrator account username, and
password.
15. Click Submit.
336
Part IV: Deployment Scenarios
Extending the Extranet Virtual Server
With the administration virtual server and configuration database in place, you can
extend the virtual server to host the extranet sites. You can use either the command
line or HTML Administration pages to extend the virtual server.
To extend the extranet virtual server
1. Open a command prompt window, and navigate to the \Program Files
\Common Files\Microsoft Shared\Web Server Extensions\60\bin folder.
2. Run the following command to extend the extranet virtual server.
stsadm.exe -o extendvsinwebfarm -url https://www.servername.extranet.com
-vsname <virtual server name> [-apcreatenew -adpidname <application pool
name> -apidtype configurableid -apidlogin <DOMAIN\name> -apidpwd <password>]
The -vsname parameter is the IIS name of the internal virtual server you extended
earlier. For example, if you are using a site named “mysite” in IIS, the -vsname value
would be mysite. It is recommended that you create a new application pool for the
virtual server. Use a dedicated application pool account, not a user login account.
The application pool account for a virtual server does not need database owner
rights on the SQL Server computer. Note that the -du and -dp parameters are not
needed if you are using Windows authentication to connect to SQL Server.
To extend the virtual server using HTML Administration pages
1. Click Start, point to Programs, point to Administrative Tools, and then click
SharePoint Central Administration.
2. In the Virtual Server Configuration section, click Extend or upgrade virtual
server.
3. On the Virtual Server List page, click the virtual server you want to extend.
4. On the Extend Virtual Server page, click Extend and map to another virtual
server.
5. On the Extend And Map To Database Another Virtual Server page, in the
Server Mapping section, in the Host name or IIS virtual server name list,
select the name of the host or virtual server that you want to use.
6. In the Application Pool section, click Create a new application pool.
7. Under Select a security account for this application pool, click Configurable.
8. In the User name box, type the domain account to use for the application pool.
You should use a dedicated account for this account rather than a user’s login
account. Also, you should use the same account for each application pool that
hosts the same content.
9. In the Password box, type the password for the account and then confirm it.
Chapter 13: Installing and Configuring Windows SharePoint Services in an Extranet
337
10. Click Submit.
11. To set up the SMTP parameters after extending the virtual server, click Start,
point to Programs, point to Administrative Tools, and then click SharePoint Central Administration.
12. Under Virtual Server Configuration, click Configure virtual server settings.
13. On the Virtual Server List page, click the virtual server you want to configure.
14. Under Virtual Server Management, click Virtual server e-mail settings.
15. Under Mail Settings, configure the Outbound SMTP server, the From address,
and the Reply-to address.
16. Click OK.
Creating Sites
After following the steps just shown, you are ready to create sites for your users.
This is the last step in the process for setting up your intranet/extranet server farm.
After this step, you can start adding users and managing the sites.
To create a site
1. Open a command prompt window, and navigate to the \Program Files
\Common Files\Microsoft Shared\Web Server Extensions\60\bin folder.
2. Run the following command to create a site:
stsadm.exe -o createsite -url <url> -ownerlogin <DOMAIN\username>
-owneremail <email address> [-ownername <display name> -lcid <lcid>
-sitetemplate <site template> -title <title> -description <site description>]
Repeat this step for every site you want to create. Note that because both your
intranet and extranet virtual servers connect to the same content database, the same
sites are available in each environment.
Next Steps
Your server farm is now set up for serving the same content on both an intranet and
extranet. You can start adding users and managing sites, or you can perform the following optional, but recommended, steps:
■
You should help protect your administration virtual server either by using a
firewall to block access or by using Secure Sockets Layer (SSL) for the port.
■
As your sites increase in number and size, you will want to be able to add content databases or change connections to the content databases.
338
Part IV: Deployment Scenarios
Summary
This chapter has described the setup process for configuration of Windows SharePoint Services to provide both an intranet and extranet deployment to serve the
same content to both sets of clients.
We have addressed the crucial issues from preparing your servers to configuring SQL Server and IIS. As indicated in this chapter, a topic of prime importance is
planning for and securing the extranet. Therefore, you need to pay special attention
to the sections that deal with setting up authentication methods.
Chapter 14
Shared Services
In this chapter:
Multiple Portal Sites. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 339
Use Intra-Farm Shared Services. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 341
Configuring Shared Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343
Adding Portal Sites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 345
Recovery Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 347
Inter-Farm Shared Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 348
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 349
This chapter discusses the shared services functionality of Microsoft Office SharePoint Portal Server 2003. Shared services provide common storage and management
capabilities for alerts, audiences, user profiles, My Sites, and search between multiple portal sites on the same farm or between farms. This chapter will discuss when
and why shared services should be used and how to enable shared services.
Multiple Portal Sites
There are many reasons an organization would choose to run multiple portal sites on
the same server farm. For example, there could be a corporate news portal site that
has information about what is going on in the company and then portal sites for each
division, such as Legal, Human Resources (HR), or Marketing. That is a perfectly fine
structure, but you could also choose to have a corporate portal site with divisional
topics in that portal site, and then have portal sites for each major team. For example,
a software company might have portal sites for each product. It is really up to each
individual organization to determine the structure of the server farm.
There are several things to consider when determining how many portal sites
to use, however. The first consideration is resources. Full portal sites consume a significant amount of RAM. They can also use a lot of processing power, depending on
the number of users. In a single-server environment or small server farm, it is expensive
to host many non–shared services portal sites. Each non–shared services portal site
339
340
Part IV: Deployment Scenarios
will have its own search applications—catalogs, content sources, search scopes, and
crawling schedules—as well as its own My Site directories and audiences.
The benefit of multiple non–shared services portal sites is that each portal site
is a completely separate entity. This scenario might be useful for partner extranets,
where you want no connection to your corporate portal site. In such a scenario, you
would want partners to have access to controlled information about your company.
For example, giving partners access to the corporate portal site would give them
access to see public My Sites of any user of the portal site. If you just want to give
partners access to contact information for specific users of your company, you
would need to have a completely separate portal site for partners (or even separate
portal sites for each partner) or get very deep into changing permissions on public
My Sites on the corporate portal site.
The major disadvantage of multiple non–shared services portal sites is that
additional administrative effort and administrative costs are incurred. It is difficult to
manage multiple discrete portal sites, as each additional site takes more time to set
up, configure, and maintain. Each portal site has different settings, and keeping
track of what settings each site has can be daunting and time consuming for the
SharePoint Portal Server administrator. Depending on the number of non–shared
services portal sites, you might need to share the burden of administration among
multiple server administrators. This will add cost as well. Also, having multiple non–
shared services portal sites can be confusing for users who have accounts on each
of those portal sites—for example, a salesperson who has an account on the corporate portal site as well as on the partner portal site. That user will have a different My
Site on each portal site and will get different search results on each portal site. These
factors should be taken into consideration.
The other increased cost of running multiple non–shared services portal sites is
resources. A single-server environment with 4 GB of RAM can host up to 10 non–
shared services portal sites without incurring a performance penalty. The amount of
content in the portal site and the site’s peak usage will ultimately determine how
many non–shared services portal sites can be hosted on a single server. If usage is
light, up to 10 non–shared services portal sites can be hosted, but if usage of all the
portal sites is heavy, you should not run more than 4 or 5 non–shared services portal
sites. To increase the capacity of the farm, additional machines must be purchased
and the farm must be reconfigured. Both are costly ventures, requiring skillful planning to ensure minimal downtime. In addition, much data will be stored multiple
times. Audience compilation and user profiles will be stored in a separate database
for each portal site, so any information that is present in multiple portal sites will be
stored multiple times. Search catalogs will be built on a per–portal site basis, meaning that if any content source, such as company press releases, is present in more
than one portal site, it is indexed in both the corporate portal site and the partner
portal site. That same content will be crawled twice, taking up processor time, and
it will be stored in two different catalogs, taking up twice the space.
Chapter 14:
Shared Services
341
Use Intra-Farm Shared Services
Intra-farm shared services can be the answer to the problem with multiple portal
sites we just discussed. It will not help in a situation where multiple non–shared services portal sites are needed to separate the entities, but it will help alleviate the
resource and management difficulties. Additional portal sites in a farm running
shared services will take up far fewer resources, except for the corporate portal site.
The corporate portal site is the top-level, or parent, portal site of the farm. This portal
site will host all the shared services—search applications, audiences, user profiles,
and My Sites. It will consume roughly the same amount of memory as a non–shared
services portal site. With shared services enabled, you will be able to host up to
100 portal sites on a single server without incurring a performance penalty. Again,
as with non–shared services portal sites, the total number of portal sites per server
that can be hosted ultimately depends on site content and usage.
Note You do not want to enable shared services on a server farm where
there is only one portal site. Because shared services add additional databases for the shared services data, running shared services with only one
server will actually give you slightly lower performance. You can always enable
shared services later when a second portal site needs to be created.
Administration is easier with shared services also. Because there is only one
location to configure search, audiences, user profiles, and My Sites for the entire
farm, these components are much simpler and faster to manage. Troubleshooting
can be easier as well. Search can be a problematic component of SharePoint Portal
Server to fix when it breaks. Because there is only one search application for the
entire server farm with shared services, there will be only one instance to monitor
and fix, rather than several.
Each portal site will still have its own Site Settings configuration, which will be
the responsibility of the portal site owner to manage, but resource-intensive operations, such as audience compilation and crawling, will be reserved for farm administrators. The link for each of these will still show up on the Site Settings page, but
you will get a notice that shared services is enabled and that you will need to contact
the administrator of the corporate portal site, as shown in Figure 14-1.
The end-user experience will be improved with shared services as well. If a user
performs an “All Content Source” search on any portal site in the farm, that user will
get the same search results as if he searched directly from the parent portal site.
When the user visits his My Site, it will be the same no matter what portal site he is
using. This is because the My Site link actually redirects the user to the My Site on the
corporate portal site no matter what portal site he is using, unless you manually designate a separate personal site portal. You might consider using a separate personal site
342
Part IV: Deployment Scenarios
portal if you have a huge number of personal sites and you want to segregate all those
sites on a different server to increase performance. As you can see in Figure 14-2,
the URL for My Site (as seen in the status bar in the lower left corner) points to
portal.woodgrovebank.com even though the user is on the Partners portal site. All
public My Sites will be the same for all portal sites in the farm as well. All this leads to
a more seamless end-user experience while still implementing multiple portal sites.
F14XR01
Figure 14-1
Shared services enabled warning
Figure 14-2
My Site URL redirection
F14XR02
Chapter 14:
Shared Services
343
Note The only time the user experience is not seamless is when the user
clicks to go to his My Site from a child portal site and then wants to navigate back. Usually in the upper-right corner of the portal site, there is a link
to go up to the level above where he is. For a user’s My Site, this link will
always be the root of the corporate, or parent, portal site. If the user comes
from a different portal site and wants to use the link, it might be somewhat
awkward. In this instance, the user should use the browser’s Back button to
return to the site he was on.
Configuring Shared Services
To use shared services, you first must enable shared services on the server farm.
Shared services provide common storage and management capabilities for alerts,
audiences, user profiles, My Sites, and search. If you run a multiple portal site environment on your server farm without activating shared services, you are required to
manage each of the preceding issues separately on each portal site.
Shared services can be enabled from any server in the farm from which you
can access SharePoint Central Administration. Usually, it is configured from a frontend Web server.
Note After you enable shared services, you cannot easily change the
selections that you are making in the following steps. Be sure to make
appropriate decisions for your organization before continuing.
To enable shared services
1. Click Start, point to All Programs, point to SharePoint Portal Server, and
then click SharePoint Central Administration.
2. On the SharePoint Portal Server Central Administration page, in the Component Configuration section, click Manage shared services for the
server farm.
3. On the Managed Shared Services page, in the Shared Services Provider section,
click Provide shared services.
4. In the Portal site that provides shared services list, click the name of the
corporate portal site as shown in Figure 14-3.
344
Part IV: Deployment Scenarios
F14Xr03
Figure 14-3
Selecting the corporate portal site to enable shared services
5. If you want to share My Sites by using a separate personal sites portal, select
the Use personal site services check box and enter the URL of the portal site
hosting the My Sites (the corporate portal site) as shown in Figure 14-4.
F14XR04
Figure 14-4
Configuring My Sites redirection
Chapter 14:
Shared Services
345
6. In the Direct Access to Search Service section, enter the domain account
used for managing search and content services (DOMAIN\spssql).
Note Server farms that use shared services can use a specific account to
access search and index resources. This account does not have to be the
same account that is used by the portal site that provides shared services.
Adding Portal Sites
Using shared services is pointless unless you have multiple portal sites. Using the
steps that follow will create an additional portal site. These are the same steps for
creating both a non–shared services portal site (when shared services is not
enabled) and a child portal site (when shared services is enabled). In our example,
our main portal site is at partners.woodgrovebank.com. The portal site to be created
in our example will be accessible at partners.woodgrovebank.com.
To create an additional portal site, first create a new virtual server in Internet
Information Services (IIS) by following these steps:
1. On a front-end Web server, open Internet Information Services Manager.
2. Expand the server.
3. Right-click the Web Sites folder, point to New, and then click Web Site.
4. Click Next to start the wizard. Enter a description for the website as shown in
Figure 14-5. Click Next to continue.
F14XR05
Figure 14-5
Creating a new virtual server
346
Part IV: Deployment Scenarios
5. Enter an IP address to bind to if you have multiple network interface cards
(NIC); otherwise, enter a host header as shown in Figure 14-6. Click Next to
continue.
F14XR06
Figure 14-6
Configuring a host header
6. Enter a path for the website. This path cannot be the same as one used
by another website. You should create a new folder under your default home
directory for IIS sites (located by default at C:\Inetpub\wwwroot). Clear
the Allow anonymous access to this Web site check box. Click Next to
continue.
7. Leave Web Site Access Permissions at their default (Read, Run scripts). Click
Next to continue. Click Finish to complete the wizard.
8. Repeat steps 1 through 7 on each front-end Web server.
9. Go to SharePoint Portal Server Central Administration.
10. In the Portal Site and Virtual Server Configuration section, click Create a
portal site.
11. Enter a name for the portal site, and select the virtual server you just created as
shown in Figure 14-7. Enter an owner account and e-mail address. Click OK.
Click OK again to confirm portal site creation.
12. For additional front-end servers, on the SharePoint Portal Server Central
Administration page, in the Portal Site and Virtual Server Configuration
section, click Extend an existing virtual server from the Virtual Server
List page.
Chapter 14:
Shared Services
347
F14XR07
Figure 14-7
Creating a new portal site
13. This opens the Extend Virtual Server Administration page. Click Extend and
map to another virtual server.
14. On the Windows SharePoint Services Extend And Map To Another Virtual
Server page, in the Server Mapping section, click the name of the virtual
server the portal site was created on in the list.
15. In the Application Pool section, click Use an existing application pool,
select the portal site application pool that was created previously in this chapter, and then set the application pool. Click OK.
16. Repeat steps 12 through 15 for each additional front-end server.
Recovery Considerations
You can restore portal sites by using the SharePoint Portal Server Data Backup and
Restore utility, which is covered in detail in Chapter 30, “Default Tools to Customize
Windows SharePoint Services.” However, the following rules apply when restoring
portal sites to farms that use shared services:
■
Within a shared services server farm, the corporate (parent) portal site provides
all shared services for the divisional (child) portal sites in the server farm. If the
corporate portal site is disabled or deleted, all divisional portal sites become
unavailable until the corporate portal site is restored.
348
Part IV: Deployment Scenarios
■
When the corporate (parent) portal site no longer exists on the server farm, the
divisional (child) portal sites continue to operate as if they were still members of
an intra-farm shared services configuration. However, you cannot connect to a
divisional portal site while the corporate portal site is down or disabled. If the corporate portal site cannot be restored, an independent portal site can be restored
to the server farm, and it will automatically become the master portal site. This
makes it possible to repair the server farm after the corporate portal site is lost.
The Backup and Restore utility is sensitive to the type of portal site being
restored. If the corporate (parent) portal site is available, any portal site being
restored automatically becomes a divisional (child) portal site and consumes shared
services from the corporate portal site. You cannot restore a divisional portal site
into a server farm that is missing the corporate portal site. The corporate portal site
must be restored before a divisional portal site can be restored.
Inter-Farm Shared Services
Inter-farm shared services are much like regular shared services, except that a different
farm hosts the shared applications—search, audiences, profiles, and My Sites. This
model allows additional scalability because large farms that are at capacity can have
their services shared with an additional farm. It can also work well for smaller farms
that want more portal sites but don’t want to make the jump to a larger farm topology.
By adding a single server or small server farm, more portal sites can be supported in
the organization.
Note To use inter-farm shared services, all server farms must be in the
same domain and all SharePoint database access accounts must have permission to access the configuration and content databases of the corporate
(parent) portal site.
Only SharePoint Portal Server farms that use SQL Server are supported in
an inter-farm scenario. Servers using MSDE cannot participate in inter-farm shared
services.
To configure inter-farm shared services
1. Open SharePoint Portal Server Central Administration on one of the
front-end Web servers. In the Component Configuration section, click Manage shared services for the server farm.
2. In the Shared Services Consumer section, select the Use shared services
check box.
Chapter 14:
Shared Services
349
3. Enter the name of the configuration database server and configuration database
for the farm you would like to share services from, as shown in Figure 14-8.
F14XX08
Figure 14-8
Setting up inter-farm shared services
Summary
In this chapter, you learned about shared services and works. Shared services is
incredibly useful when hosting multiple portal sites on the same farm, by sharing
search, My Sites, profiles, and audience information between farms. This lowers the
resource cost of hosting portal sites and allows more than 15 portal sites to be
hosted on a single farm. Finally, this chapter detailed how to set up and configure
both inter-farm and intra-farm shared services.
Part V
Administration of Windows
SharePoint Services
In this part:
15
Configuring Windows SharePoint Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353
16
Windows SharePoint Services Site Administration . . . . . . . . . . . . . . . . . . . . . . . 405
Chapter 15
Configuring Windows
SharePoint Services
In this chapter:
The Management User Interface for Windows SharePoint Services . . . . . 353
Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 375
Server Farm Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 379
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 403
It is important to plan the Microsoft Windows SharePoint Services configuration
prior to actually doing the install so that you make the best use of your administrative
time. For instance, if you think through who needs access to data in the site collections, you can capitalize on security inheritance and minimize the number of times
you need to set up security. However, most of the configuration options we will
discuss in this chapter can be changed once the site collection is created.
Configuration of a Windows SharePoint Services site is accomplished using the
Windows SharePoint Services Central Administration Web page. Site and Site Collection Administration is accomplished using the Site Settings Administration Web pages
that are accessed directly from the Windows SharePoint Services site.
The Management User Interface for Windows
SharePoint Services
Because the focus of this chapter is on the administration of the Windows SharePoint Services installation as a whole and not on specific sites, we’ll be using the
Windows SharePoint Services Central Administration HTML pages.
One way you can gain access to SharePoint Central Administration (shown in Figure 15-1) is to go to Start, Programs, Administrative Tools, and then SharePoint Central
Administration. This will take you to the Windows SharePoint Services Central Administration page. If the title at the top of the screen references SharePoint Portal Server,
make sure you click the Windows SharePoint Services link in the left-most column of
the screen.
353
354
Part V: Administration of Windows SharePoint Services
Figure 15-1
F15XR01
Windows SharePoint Services Central Administration settings
Using the SharePoint Central Administration Pages
Each of the four main menu selections has submenu items that have several options.
As you work with these menus and submenus, remember that you can always return
to the Windows SharePoint Services Central Administration page by using the Back
button on your Web browser or by clicking the Windows SharePoint Services link in
the left-most column of the Central Administration page.
Configuring Virtual Servers
You can configure settings for the virtual server by clicking the Configure Virtual
Server Settings link (which was also shown in Figure 15-1). After clicking the link,
you might have a number of virtual servers listed, as shown in Figure 15-2. Select the
one you want to configure.
Figure 15-2
F15XR02
List of virtual servers
Chapter 15:
Configuring Windows SharePoint Services
355
The following option can be set at the virtual server level and will affect all
sites on that virtual server:
The Self-Service Site Creation setting can be set at the virtual server level and
will affect all sights on a virual server. This setting, shown in Figure 15-3, allows you
to either enable or disable Self-Service Site Creation. Microsoft Windows SharePoint
Services allows members of the Administrator site group to create subsites off of
their websites by default. These subsites can by fully functioning SharePoint sites—
complete with a home page, document libraries, and so on—and they can even have
their own unique permissions. If administrators decide this is a capability they would
like to extend to users, they can enable the Self-Service Site Creation feature. The
user does not need administrator permissions on the server or virtual server, only
permissions on the website where Self-Service Site Creation is hosted. The user
simply enters some basic information and the new top-level website is created with
the user as the owner and administrator. When you enable Self-Service Site Creation,
you free yourself from having to create top-level websites on demand for your
users—they can do it themselves.
Note This feature allows users to create top-level sites, not just subsites
in another collection. Users with this capability can create entirely new site
collections.
Figure 15-3
F15XR03
Virtual server settings
Command-Line Administration
On occasion, you might want command-line tools to accomplish some tasks either
because it is not convenient to use the HTML administration pages or because you
want to automate a procedure. In such cases, you can use a command-line utility.
356
Part V: Administration of Windows SharePoint Services
Windows SharePoint Services includes Stsadm.exe for command-line administration of Windows SharePoint Services servers and sites. The Stsadm.exe tool provides a method for performing the Windows SharePoint Services administration tasks
to run once, to be used in batch files, or to be used within a script. The commandline tool has a more streamlined interface than HTML Administration pages, yet it
allows you to perform many of the same tasks.
Note You must be an administrator of the server computer to be able to
use the Stsadm.exe tool, and the command must be run from the server
running Windows SharePoint Services.
Configuring Self-Service Site Creation from the Command Line
Use the enablessc operation to turn on and configure Self-Service Site Creation from
the command line. The enablessc operation requires the URL parameter, and optionally takes the requiresecondarycontact parameter. For example, to turn on Self-Service
Site Creation for a server called My_Server and require two contact names for each
site, you would use the following syntax:
stsadm -o enablessc -url http://My_Server –requiresecondarycontact
To disable Self-Service Site Creation, use the disablessc operation. The disablessc
operation takes only the URL parameter. To turn off Self-Service Site Creation for
My_Server, use the following syntax:
stsadm -o disablessc -url http://My_Server
Configure Site Collection Using Confirmation and Deletion
Websites based on Microsoft Windows SharePoint Services can become inactive for
many reasons. Perhaps a site was set up for documents relating to a project that is finished, or perhaps a user was trying out Windows SharePoint Services and created a
site that he or she no longer needs. Because inactive sites take up space on the servers, it’s important to check with site owners to see whether their sites are still needed
or have become inactive. In Windows SharePoint Services, new administrative options
allow you to automatically send notices to site owners requiring them to confirm that
their sites are in use. You can also delete unconfirmed sites automatically. These features give you a way to control the number of unused websites on your server.
After a specified time defined by the administrator, the site owners are sent an
e-mail notification asking the owners to either reactivate or delete their unused websites. The notification e-mail text contains links to confirm that a site is active or to
delete a site. After the notification is sent, there are three possible outcomes:
■
If a site is in use, the site owner will click a link to confirm that the site is active
and preserve the site. When the owner clicks the confirmation link, the timer
is restarted, and the owner will be notified again after the same time period.
Chapter 15:
Configuring Windows SharePoint Services
357
■
If a site is not in use, the site owner can delete the site by following instructions
in the notification e-mail or do nothing. The site owner continues to receive
periodic e-mail notifications (the period is defined by the administrator) until
use is confirmed or the site is deleted.
■
If a site is not in use, you have turned on the automatic deletion feature, the
site owner is queried a specific number of times (a number configured by the
administrator), and use is not confirmed, the site is automatically deleted.
Automatic deletion is an advanced administrative feature that can delete
unneeded sites without any administrative intervention and without any backup
mechanism. To prevent a site from being deleted without any notification, you must
turn on site use confirmation before you can turn on automatic deletion. Also, the
site owner must always be sent at least two confirmation notices before a site can be
deleted.
By default, site use confirmation is turned off. To require confirmation of use,
you can specify the interval to wait before sending the first notification and how frequently to continue sending notifications if site use is not confirmed. Notices are
sent to the e-mail address specified in the site for the site collection owner and the
secondary owner (if a secondary contact has been identified).
Warning Be sure to back up websites regularly so that you can restore a
recent copy if a site is unintentionally deleted.
As an example, if you specify 60 days in the Start Sending Notifications box,
when a user creates a site, the first notification will be sent after 60 days. If the user
confirms that the site is in use at that time, another 60 days will pass before the user
gets another notification.
Note The exact time of the physical deletion will depend on when you have
scheduled the background process called Checking For And Automatically
Deleting Unused Web Sites. This process can be set to run daily, weekly, or
monthly and is set at the virtual server level, so it will potentially affect all
sites on that virtual server.
The Start Sending Notifications Days field must be a value between 30 and 365.
(The initial notification value controls when the first confirmation notice is sent to a
new site or to a site that has been confirmed as in use. This value does not control
the frequency of notifications, only the number of days to wait before the initial
notification.)
358
Part V: Administration of Windows SharePoint Services
Regardless of the value you place in the Start Sending Notifications field, if
you choose daily notification, the value must be between 28 and 168 days. As you
look at the options, it will be obvious that the relationship between the values in
the fields must make sense. For instance, you can’t set the Start Sending Notifications field for 15 days, and the Check For Unused Site Collections setting to
monthly notification, because that makes no sense. It would be impossible to start
sending notifications 15 days after the site was last used if the system is only checking on a monthly basis. However, when you set incompatible values, the user interface will give you a warning, as it always does, at the top of the window in red
lettering. See Figure 15-4.
Figure 15-4
F15XR04
Error for Automatic Deletion settings
Manage User Rights for Virtual Server Settings
As an administrator, if you want to allow or limit certain actions your users perform,
you can disable or enable the associated right on the virtual server. For example, if
you do not want users to be able to add pages to a website, you can disable the Add
And Customize Pages right. When you disable a right on a virtual server, it cannot be
assigned to any site group and, as a result, cannot be granted to any user of a site
on the virtual server.
Note If a user already has a right, and you disable that right, the right is
also disabled for that user.
Chapter 15:
Configuring Windows SharePoint Services
359
Manage Security Settings for Web Part Pages
This setting is used for administration of the Web Parts and Web Part Pages you use
on this virtual server. Specify whether users can create connections between Web
Parts in a website and whether the Online Web Part Gallery is available. (See Figure 15-5.)
Figure 15-5
F15XR05
Web Part connections
Web Part Connections and Online Web Part Gallery Settings
Use these settings to control whether users can connect Web Parts within a site and
whether they have access to the online Web Part gallery. The online Web Part gallery
contains many Web Parts that users can use on their sites. Adding Web Parts or making
connections to Web Parts might affect your server security and performance. For
example, if you allow Web Part connections and a user connects a complex Web Part
to a large data set, the Web Part Page that contains those Web Parts could load very
slowly when a user goes to it. Also, if a user connects to a Web Part that contains a
scripting error or malicious code, that Web Part could open a security hole in the user’s
site or, potentially, on your server. However, in most scenarios, the default settings that
allow Web Part connections and an Online gallery will be the preferred setting because
the feature of connecting Web Parts presents powerful collaboration solutions.
You can change these configuration options at the virtual server level. By
default, both security options are enabled at the server level. You need to change
these options only if you do not want to allow either Web Part connections or access
to the online Web Part gallery.
When making virtual server setting changes in a farm environment, if a change
is made on one virtual server, SharePoint will display a page asking if you want to
synchronize the other servers in the farm.
You must be an administrator of the local server computer or a member of the
SharePoint administrators group to configure security and performance options for
Web Parts and Web Part Pages.
360
Part V: Administration of Windows SharePoint Services
Virtual Server General Settings
The Virtual Server General Settings page contains several options that apply
throughout the virtual server. When you configure a setting for a virtual server, it
takes priority over settings applied on specific sites of that virtual server. For example, if you disable alerts for a virtual server, no site or subsite can use alerts. For
more information about how each setting is treated at different levels, see the specific topic for that setting.
The settings you can configure on the Virtual Server General Settings page are
detailed in the following sections.
Time Zone to Use for the Virtual Server
Select a time zone to use for all sites created on this virtual server as shown in Figure 15-6. The time zone setting can also be changed for a top-level or subsite. To
change the time zone for a site, click Site Settings, and then under the heading
Administration, click Go To Site Administration. Now from the Top-Level Site
Administration menu, click Change Regional Settings under the heading Management And Statistics.
Figure 15-6
F15XR06
Time Zone and Quota Template settings
Configuring Time Zone from the Command Line
If you prefer to change the time zone setting from the command line, use the
Stsadm.exe command with the following parameters:
Stsadm.exe –o setproperty –pn defaulttimezone
You will need to know the numerical value for the time zone you want to use.
Replace the defaulttimezone parameter with this numerical value.
Default Quota Template for Sites Created Under the Virtual Server
You can specify the default quota template to use. (See Figure 15-6.)
Chapter 15:
Configuring Windows SharePoint Services
361
Microsoft Windows SharePoint Services allows you to specify quotas for sites
so that you can manage site and server resources. You can create multiple sets of
quotas, called quota templates, and use them in different Site Collections of the
server farm or to suit different users. You can use locks to stop sites from exceeding
your storage quota limits and to block all users from accessing a site if necessary.
When you create a top-level website, you can create it using the default template or a different template. Quota templates and the settings specified in them are
stored in the configuration database for your server or server farm. Quota values
apply to top-level websites and are applied when you create such sites. You can
specify a default template to use for all top-level websites created on a virtual server,
for example, or you can specify the template to use when you create the top-level
website. The values listed in the quota template are copied into the database for the
top-level website and are referenced from there.
Note If you change the values for a quota template, those changes apply
only to new top-level websites created using that template, not to existing
ones. If you want to apply the template changes to existing sites, you can
use the SharePoint Central Administration User Interface and re-apply the
quota template to existing sites. Alternatively, you can use the Windows
SharePoint Services object model or make the change with a SQL Server
quer y. Likewise, when you delete a quota template, the template is
removed from the configuration database, but any top-level websites created using that template will retain the quota values. If you want to remove
quotas from all sites using a particular quota template, you must use the
object model or perform a SQL Server query.
If there are no templates, you can create a template by using the Manage
Quota Templates page. Note that when you specify a default template for the virtual
server, you can still select a different template when you create a site.
Applying Quota Template Changes from the Command Line
If you prefer to apply the quota template from the command line, use the
Stsadm.exe command with the following parameters:
Stsadm –o setproperty –pn defaultquotatemplate –pv <property value>
Replace
<property value>
with the actual name of the template.
Name Smart Tag and Presence Settings
Use this setting to enable or disable presence information for site members. Online
presence allows users of your site to see whether other users are online and to send
instant messages to them. To use online presence, your users must have Microsoft
362
Part V: Administration of Windows SharePoint Services
Office 2003 installed, must be running Microsoft Windows Messenger version 4.6 or
later or MSN Messenger version 4.6 or later on their client computers, and must have
valid accounts with the .NET Messenger or Exchange Instant Messaging service. Note
that the e-mail address for the instant messaging account must be the same as the
e-mail address for the user account in Windows SharePoint Services. See Figure 15-7.
Figure 15-7
F15XR07
Smart Tag, Upload Size, and Alert settings
Maximum Upload Size
This is the place to specify the maximum file size to allow when files are uploaded
to a website on this virtual server. See Figure 15-7.
Setting the Maximum File Upload Size from the Command Line
If you prefer to change the maximum file upload size setting from the command
line, use the Stsadm.exe command with the following parameters:
Stsadm –o setproperty –pn max-file-post-size –pv <property value>
Replace
<property value>
with a numerical value, in megabytes (MB).
Note Even though you can increase the Maximum Upload Size to a much
larger number, Microsoft’s recommendation is not to exceed 50 MB for best
performance. Note that this applies to the Upload Multiple Files feature in
Office 2003. We have successfully tested uploading much larger file sets
using the Web Folder client with the drag-and-drop method.
Alert Settings
This setting allows you to enable or disable alerts for all sites under the virtual
server, and it allows you to configure default settings for alerts. See Figure 15-7.
Chapter 15:
Configuring Windows SharePoint Services
363
Because websites based on Microsoft Windows SharePoint Services are meant
to help groups of users work together, they tend to grow quickly and change often.
Keeping up with these changes can be difficult for users, especially if they aren’t
checking on the site every day. To help users stay in touch with changes on a site,
Windows SharePoint Services includes a feature called Alerts, an e-mail notification
service. (They will also appear in the My Alerts when this Web Part is present on site
pages.) When documents, lists, or items in a list on a server running Windows SharePoint Services are created, modified, or deleted, users who sign up for alerts receive
messages informing them that changes have been made.
Note Before alerts can work for a particular site, the e-mail server settings must be configured at the server or virtual server level. In SharePoint
Team Services v1.0 from Microsoft, alerts were called Web subscriptions.
Users can create alerts to track items within a site, such as:
■
Lists. Users are notified of changes to the list, such as when an item is added,
deleted, or changed in a list.
■
List items.
■
Document libraries. Users are notified of changes to the document library,
such as when a document in a document library is added, deleted, or changed,
or when Web discussions are added, changed, deleted, closed, or activated for
a document.
■
Documents. Users are notified of changes in a particular document or
when Web discussions are added, changed, deleted, closed, or activated for
a document.
Users are notified of changes to a particular item in a list.
When a user creates an alert for one of these items, she can specify what types
of events will trigger an alert. Alerts can be generated whenever a document or list
item is added, updated, or deleted in a document library or list, or when a Web discussion on a document or list changes. A user can specify one of these events or
select all of them to be notified whenever anything changes on the list, list item,
document, or document library they want to track.
Users also have the ability to decide how often they want to receive alerts:
immediately, daily, or weekly. Immediate alerts are sent as individual e-mail messages, and daily or weekly alerts are combined into summary messages for the entire
website.
Users can change their alerts by using the My Alerts On This Site link on the
Site Settings page of their website.
364
Part V: Administration of Windows SharePoint Services
Configuring Alerts from the Command Line
You can manage alerts from the command line by using the GetProperty and SetProperty operations with Stsadm.exe. You can set the properties shown in Table 15-1 to
configure how alerts work.
Table 15-1
Managing Alerts from the Command Line
Property
Description
alerts-enabled
Turn alerts on or off.
alerts-limited
Specify whether users are limited to a specific number of
alerts.
alerts-maximum
Specify the maximum number of alerts users can create.
job-immediate-notification
Specify how often to check for immediate alerts (in minutes).
job-daily-notification
Specify the time of day (using a 24-hour clock) to send out
daily alerts.
job-weekly-notification
Specify the day of the week and time of day (using a 24-hour
clock) to send out weekly alerts.
The following example shows the syntax to use to turn off alerts:
stsadm.exe -o setproperty -p <port> -pn alerts-enabled -pv false
Note A user must have the View Items right (included in the Contributor
site group by default) to sign up for alerts.
Web Page Security Validation
Use this setting to enable or disable security validation for website pages. This setting specifies how long to wait before the security validation expires for a given
page.
Web Page Security Validation enhances security by imposing a time limit on
pages when the user is submitting information to the server. This feature ensures
that the connection between the browser and the server is more secure and that data
is not altered on a user’s behalf without his knowledge. When users take too long
before submitting changes to the server, they receive a message informing them that
they must go back to the previous page and retry the operation.
In most installations, a setting of 30 minutes is usually appropriate. If site users
experience frequent time-outs because of long data transfer times, consider increasing the interval. However, you should not turn off Web Page Security Validation, as
it helps to maintain the security of your server.
Select Never to keep the validations from expiring. However, this is not recommended, as you would obviously be creating a security vulnerability. See Figure 15-8.
Chapter 15:
Figure 15-8
F15XR08
Configuring Windows SharePoint Services
365
Security Validation and User Name/Password settings
Sending User Names and Passwords in E-mail
Use this setting to specify whether user names and passwords are sent in e-mail
messages to new users. This setting is used for Active Directory user account mode
only. See Figure 15-8.
E-mail Inserts
Use this setting to enable or disable e-mail-enabled document libraries and to specify
the public folder path for e-mail attachments and how frequently to check for new
attachments. See Figure 15-9.
Figure 15-9
F15XR09
E-Mail-enabled Document Library settings
Windows SharePoint Services includes the ability to link a document library
with a public folder based on Microsoft Exchange 2000 or later. Any documents
attached to messages in the public folder can be automatically inserted into the document library, and the document library displays the document as well as the from
366
Part V: Administration of Windows SharePoint Services
address, subject line, and date and time that the attachment was inserted into the
document library. Note that the body text of the e-mail message is not preserved. It
remains in the public folder, but it is not transferred to the document library.
Therefore, a user can simply send e-mail with an attached document to the
public folder, and the document will be automatically added to the correct document library on a SharePoint site. For example, if you are using an XML template to
store invoice information, a user could fill out the XML invoice and e-mail it to the
public folder. The XML file then is posted to the document library and would be
available for rolling up into larger reports on invoices or for easy retrieval.
To configure this page, in the Public Folder Server And Root Path box, type the
name of the computer running Microsoft Exchange Server and the path to the root
folder for Exchange Server public folders on that server. See Figure 15-9.
If you choose to allow e-mail attachments, specify the frequency and times to
check for e-mail attachments in the public folder.
Event Handlers
Use this setting to enable or disable event handlers.
Windows SharePoint Services allow you to bind an event handler to a document library. With this feature, you can use document library events to start other
processes, such as workflow processes. You can develop managed code that leverages document library events and create an application based on Windows SharePoint Services to perform whatever actions you need. When you combine document
libraries, your own event-handling managed code, and possibly XML forms, you can
create even complex workflow processes that are easy for users to work with. See
Figure 15-10.
Figure 15-10
F15XR10
Event Handler settings
For example, in the healthcare industry, when a new patient is admitted to a hospital, a lot of paperwork needs to be generated and it needs to be done in a specific
Chapter 15:
Configuring Windows SharePoint Services
367
order. You can write an application that interacts with XML forms in a document
library to accomplish the following tasks:
■
Track when a new admissions form is added to the document library
■
Extract the insurance information, and forward it to the billing application
■
Notify the staff in the appropriate section of the hospital to pull the patient’s chart
Table 15-2 shows events that can be tracked for document libraries.
Table 15-2
Events Tracked for Document Libraries
Event
Description
Insert
A new document is added to the document library
Update
An existing document is edited
Delete
An existing document is deleted
Move
A document is moved or renamed
Copy
A document or folder is copied
Check In
A document is checked in
Check Out
A document is checked out
Cancel Check-Out
Changes made to a checked-out document are undone
If you are following along on your own server’s Central Administration Pages,
we have now explored all the options under Virtual Server General settings. Now
click the Back button in your Internet Explorer and resume with the second menu
item under the main heading Virtual Server Management. See Figure 15-11.
Figure 15-11
F15XR11
Virtual server management
368
Part V: Administration of Windows SharePoint Services
Manage Content Databases
You can create or delete content databases, or change the capacity settings for a particular content database. You can create multiple content databases for each virtual server.
Microsoft Windows SharePoint Services uses a database to store and manage
site content. Just as each virtual server can host multiple top-level websites, each virtual server can rely on multiple content databases to store site content. If you are
running Windows SharePoint Services on a single server, hosting just a few sites, you
can probably use the same content database for all your sites. If you want to add
capacity in a server farm, you will most likely need several content databases to
store site data for each virtual server.
To make it easier to manage site content for large server farms, you can also set
limits on how many top-level websites can store content in a single content database. You can specify a warning limit and a maximum limit for the number of sites.
When a warning limit or maximum limit is reached, an event is logged in the server’s
Windows NT Event Log so that you can take action. When a maximum limit is
reached, no more sites can be created using that content database.
When you create a new site, the databases are queried and the new site’s content is added to the database that has the most available space. For example, suppose your virtual server has three content databases, all are set to warn you when
they reach 2000 sites, and all have a maximum of 2025 sites. When the first content
database reaches 2000 sites, an event is logged. When it reaches 2025 sites, no more
sites can be created in that database. When you are close to the limit on two of the
three content databases and you know that you’ll need to host more than 2000 additional sites, it is time to create another content database.
You can specify any number of sites for the warning and maximum number of
sites. To determine an appropriate number for your situation, divide the amount of
available disk space on the database server by the estimated size for each site (plus
a buffer). If you are using quotas, divide the disk space by the disk space quota
(plus a buffer).
A buffer allows the number of sites to grow beyond the warning level but not
exceed your disk space. The size of the buffer is up to you, but make sure to provide enough space for growth so that you don’t exceed the maximum number
before you can react to a warning event. When the maximum number is reached, no
more sites can be created in that content database. Be sure to create a buffer large
enough so that your users can continue to create sites as required, without having to
constantly create new content databases.
Content databases are created and managed at the virtual server level. When
you create a new content database (or when you extend a virtual server), you specify the database connection settings for the content database. You can update these
settings if, for example, the database server name changes.
You can create or delete content databases, and specify settings such as the
database server to use for the content and how many top-level websites to allow per
content database in a server farm setting, by using pages in HTML Administration. In
Chapter 15:
Configuring Windows SharePoint Services
369
HTML Administration, you can view the full list of content databases for your virtual
server and see at a glance the current warning and maximum level of sites for the
content database.
Managing Content Databases by Using HTML Administration
You can specify a default server to store content databases for all your virtual servers. This allows you to create a new content database when you extend a virtual
server, without having to specify a location or supply the user name and password.
To specify a default content database server
1. Click Start, point to All Programs, point to Administrative Tools, and then
click SharePoint Central Administration.
2. On the Central Administration page, under Server Configuration, click Set
default content database server.
3. In the Database section, type in the database server name.
If you are using Microsoft SQL Server authentication, you must also supply the administrator account user name and password.
4. Click OK.
You can create multiple content databases for each virtual server. There are
two situations in which you create a new content database: when you extend a new
virtual server, and when your other content databases are getting full. You use a different method to create the content databases in each of these cases.
In most cases, you create a content database when you extend a virtual server.
When you extend a virtual server, the warning level is set to 9000 sites and the maximum is set to 15,000 sites. To change this after the virtual server is extended, you
use the Manage Content Databases page. You can also create additional content
databases by using this page.
To create a new content database for a virtual server
1. Click Start, point to All Programs, point to Administrative Tools, and then
click SharePoint Central Administration.
2. On the Central Administration page, under Virtual Server Configuration,
click Configure virtual server settings.
3. On the Virtual Server List page, click the virtual server you want to configure.
4. On the Virtual Server Settings page, under Virtual Server Management, click
Manage content databases.
5. On the Manage Content Databases page, under Content Databases, click Add
a content database.
370
Part V: Administration of Windows SharePoint Services
6. In the Database section, select either Use default content database server
or Specify database server settings.
If you select Specify database server settings, type in the database
server name and database name. If you are using SQL Server authentication,
you must also supply the administrator account user name and password.
7. In the Database Capacity Settings section, type a number in the Number of
sites before a warning event is generated box.
8. Type a number in the Maximum number of sites that can be created in
this database box.
9. Click OK.
You can also change database connection settings, warning levels, and maximum site levels for a content database.
To change settings for a content database
1. Click Start, point to All Programs, point to Administrative Tools, and then
click SharePoint Central Administration.
2. On the Central Administration page, under Virtual Server Configuration,
click Configure virtual server settings.
3. On the Virtual Server List page, select the virtual server you want to configure.
4. On the Virtual Server Settings page, under Virtual Server Management, click
Manage content databases.
5. On the Manage Content Databases page, under Content Databases, click the
name of the database you want to change.
6. To change database status, in the Database Status box, select Ready or Offline.
7. To change the number of sites allowed for a content database, in the Database
Capacity Settings section, enter a new warning and maximum number.
8. Click OK.
If you want to remove a content database, you do so from the Manage Content
Databases page as well. Note that when you remove a content database, the site
data stored in that database is not deleted. You can reconnect to the content database later to restore the sites.
To remove a content database
1. Click Start, point to All Programs, point to Administrative Tools, and then
click SharePoint Central Administration.
2. On the Central Administration page, under Virtual Server Configuration,
click Configure virtual server settings.
3. On the Virtual Server List page, select the virtual server you want to configure.
Chapter 15:
Configuring Windows SharePoint Services
371
4. On the Virtual Server Settings page, under Virtual Server Management, click
Manage content databases.
5. On the Manage Content Databases page, under Content Databases, select the
database you want to change.
6. On the Manage Content Database Settings page, in the Remove Content
Database section, select the Remove content database check box.
7. Click OK.
You can reconnect to a content database that you have removed by adding it
again. To reconnect to an existing content database, you need to use the same database
server and database name. There are additional steps if you are reconnecting to a content database after restoring the database to a new server farm. For more information,
refer to Chapter 28, “Disaster Recovery in SharePoint Products and Technologies.”
When you remove a content database, the site data stored in that database is
not deleted. You can reconnect to the content database later to restore the sites.
Removing a Content Database from the Command Line
The Unextendvs property can be used with the Stsadm command line to remove
Windows SharePoint Services from a particular virtual server. And if you use the
deletecontent parameter, you can delete the content databases for the virtual server
at the same time. A sample syntax is as follows:
stsadm.exe -o unextendvs -url <url> [-deletecontent] E-mail settings –
Specify the outbound e-mail server to use and the e-mail addresses to use
when sending e-mail from the server. E-mail settings can also be configured at the
server level and used as the default settings.
Microsoft Windows SharePoint Services sends alerts and other administrator messages by using an SMTP server. This feature is also required for end-users to request
access to a site or list. You can specify which SMTP server to use and set the e-mail
address to use for sending alerts and receiving replies for all sites. See Figure 15-12.
Figure 15-12
F15XR12
Mail settings
372
Part V: Administration of Windows SharePoint Services
Remove Windows SharePoint Services from a Virtual Server
You can remove Windows SharePoint Services either permanently or temporarily by
using HTML Administration or the command-line administration tool. Both of these
tools allow you to either preserve or delete content when you remove Windows
SharePoint Services.
You can use the unextendvs operation with the stsadm.exe command-line utility to remove Windows SharePoint Services from a virtual server. For example, to
remove Windows SharePoint Services from a virtual server but preserve the content
databases, use the unextendvs operation with syntax such as the following:
Stsadm –o unextendvs –url http://My_Server
To remove Windows SharePoint Services from a virtual server and remove the
content databases permanently, use the unextendvs operation with syntax such as
the following:
Stsadm –o unextendvs –url http://My_Server –deletecontent
If you want to remove Windows SharePoint Services from a server computer
entirely, you can uninstall it by using Add Or Remove Programs in Control Panel.
Uninstalling Windows SharePoint Services does not remove any related products,
such as the Microsoft SQL Server 2000 Desktop Engine (WMSDE), that were
installed. You must uninstall these programs separately.
Define Managed Paths
Using this setting, you can add or remove included and excluded paths to control
which areas of the URL namespace are managed by Windows SharePoint Services.
Many organizations installing Microsoft Windows SharePoint Services already
have a Web server or server farm in use and must be able to identify areas of the
existing URL namespace that should not be managed by Windows SharePoint Services. For example, if you have a Web application on your Web server already and
you install Windows SharePoint Services, you need a way to specify that Windows
SharePoint Services will not attempt to control content in or settings for that path.
In addition, the Define Managed Paths setting allows you to specify the paths
to use for Self-Service Site Creation. You can restrict Self-Service Site Creation users
to specific paths when they create sites. By default, the /sites path is created and
added as a path for Self-Service Site Creation users when you enable Self-Service Site
Creation. You can create other paths for Self-Service Site Creation users, or you can
remove the /sites path when you manage paths.
Note that you can also specify inclusions and create new paths when you use
Create A Top-Level Web Site from Windows SharePoint Services Central Administration.
If you select the Define Managed Paths item under Web Site Address, you will find that
you can specify paths to include or exclude, and you can even add new paths.
You can manage two categories of paths: included and excluded. An included
path indicates that Windows SharePoint Services manages that path. An excluded
path indicates that a different application manages the path and that Windows
Chapter 15:
Configuring Windows SharePoint Services
373
SharePoint Services should leave it alone. Included paths can be further categorized
into the following two types:
■
Explicit inclusions. Includes only the specific path that you set. Use explicit
inclusions, for example, if you want Windows SharePoint Services to manage
a specific path (such as /portal) but not any possible sites below it (such as
/portal/webapp).
■
Wildcard inclusions. Includes any sites below the path that you set so that
you don’t have to add them individually. This is the type of inclusion to use for
Self-Service Site Creation, when you want users to be able to create top-level
websites underneath a specific path, such as /sites.
Note Web server performance declines linearly with the number of inclusions and exclusions. You can minimize the performance impact by using
wildcard inclusions rather than many explicit inclusions, and by putting as
many excluded applications under the same excluded path as possible.
Included and excluded paths are used only for directories, not pages in a website, and they are recursive. (For example, if you exclude /mango, Windows SharePoint Services ignores any URL beginning with /mango/ or equal to /mango.)
Exclusions take precedence over inclusions, so if you accidentally set a particular
path to be both included and excluded, the path is excluded. Inclusions are evaluated by length; longer URLs are checked before shorter URLs, so an inclusion
for http://My_Server/sites/teams is evaluated before an inclusion for http://My_Server
/teams.
You can manage paths by using HTML Administration or the command-line
administration tool. You can use the addpath and deletepath operations to manage
paths on the command line. Both operations take the -url and -type parameters. The
-type parameter has three values: exclusion, explicitinclusion, and wildcardinclusion.
For example, to add a new wildcard inclusion to manage all sites at the top level of
http://My_Server, you would use syntax such as the following:
Stsadm –o addpath –url http://My_Server/ -type wildcardinclusion
You can also remove an included or excluded path by using the command line.
For example, to remove an exclusion for the site at http://server1/hrweb/webapp, you
would use syntax such as the following:
Stsadm –o deletepath –url http://My_Server/hrweb/webapp
Create or Delete a Top-Level Website
You can create a new top-level website or delete an existing top-level website. If you
are an administrator of the server computer, you can also create sites and subsites by
374
Part V: Administration of Windows SharePoint Services
using the Stsadm.exe command-line tool. To create a top-level website, use the createsite operation. To create a subsite, use the createweb operation.
Note You can also use the createsiteinnewdb operation to create a toplevel website and a new content database at the same time.
The createsite operation takes the following required parameters: url, ownerlogin, owneremail, and the following optional parameters: ownername, lcid, sitetemplate, title, description, and quota. For example, to create a top-level website
called site1 on http://server_name/sites, you would use syntax similar to the following:
Stsadm.exe –o createsite –url http://My_Server/sites/site1 -ownerlogin
<DOMAIN\user> -ownermail [email protected] –ownername <display name>
Select from Virtual Server List
Note that this item simply loops you back to the virtual server list so that you can
choose a different virtual server if you are done configuring the last one you
selected.
Configure Data Retrieval Service Settings
A data retrieval service implements a new data-binding technology that enables data
consumers and data sources to communicate with each other through SOAP and
XML. Data retrieval services are XML Web services that return XML data from different data sources. A data retrieval service is installed and runs on a server extended
with Microsoft Windows SharePoint Services. Windows SharePoint Services comes
with a default set of data retrieval services for working with data in SharePoint lists,
OLEDB, and XML data sources. Client applications and data-bound Web Parts, such
as the Spreadsheet Web Part, can use a data retrieval service to query the data source
supported by the particular data source.
Configuring Data Retrieval Services from the Command Line If you are using a
third-party data retrieval service, you can register a service by using the command
line. Register these services by using Stsadm.exe with the binddrservice and
removedrservice operations. The binddrservice and removedrservice operations
register individual data retrieval services for specific settings. When you register a
service, it appears on the HTML Administration pages under the appropriate setting.
For each operation, you specify the following required parameters: servicename and
setting. The setting parameter takes any of the following values: enabled, responsesize, timeout, or update.
For example, to register a data retrieval service called Service1 to the list of services that an administrator can enable or disable, you would use the following syntax:
Stsadm.exe –o binddrservice –servicename Service1 –setting enabled
Chapter 15:
Configuring Windows SharePoint Services
375
And to remove Service1 from the list of services that can allow data updates,
you would use the following syntax:
Stsadm.exe –o removedrservice –servicename Service1 –setting update
The binddrservice operation registers a data retrieval service for the list of data
retrieval services that pertain to a specific setting on the Data Retrieval Services Settings page. Specify the service name and then the setting. Settings include enabled,
responsesize, timeout, and update.
The required parameters for the Binddrservice operation are –servicename and
–setting. There are no optional parameters for this operation.
Following is sample syntax for the Stsadm.exe command when using the binddrservice operation to register a data retrival service:
Stsadm.exe –o binddrservice –servicename <service name> -setting <enabled/responsesize/timeout/update>
Use the properties listed in Table 15-3 to configure data retrieval services for
your virtual server, server, or server farm. Specify whether data retrieval services are
enabled, whether the virtual server should inherit the server farm settings, the time
an adapter will wait for a response from the back-end data source, the maximum
size for data returned from the back-end source, and whether adapters can execute
requests that contain updatable queries.
Table 15-3
Properties to Configure Data Retrieval Services
Property Name
Values
data-retrieval-services-enabled
true/false
data-retrieval-services-inherit
true/false
data-retrieval-services-responsesize
An integer value in kilobytes (KB) between 1 and
100,000
data-retrieval-services-timeout
An integer value in seconds between 1 and 100,000
data-retrieval-services-update
true/false
Authentication
Securing your corporate computers and the information on them is a vast topic. It will
range from protecting corporate assets from viruses and unauthorized access to protecting them from acts of nature. However, we will limit our discussion here to the
concept of authentication. Authentication is the process by which the user’s identity
will be verified as one that is allowed to log in. It is different than authorization, which
is verifying that the identity has authority to access specific resources. None of the
work we have done so far will do us much good if we have not carefully thought
through and configured the appropriate access for the sites we’ve created, so let’s
explore authentication methods supported by Windows SharePoint Services.
376
Part V: Administration of Windows SharePoint Services
Authentication Methods
You configure authentication for websites based on Microsoft Windows SharePoint
Services by configuring authentication methods in Internet Information Services
(IIS). Windows SharePoint Services uses the authentication method you specify for
a virtual server in IIS to control authentication for all top-level websites and subsites
of that virtual server. Windows SharePoint Services works with the following authentication methods in IIS:
■
Anonymous authentication. Anonymous authentication provides access to
users who do not have Microsoft Windows NT server accounts on the server
computer (for example, website visitors). IIS creates the anonymous account
for Web services, which is often named IUSR_computername. When IIS
receives an anonymous request, it impersonates the anonymous account.
You can enable or disable anonymous access in IIS for a particular virtual
server, and enable or disable anonymous access for a site on that virtual server,
by using HTML administration pages for IIS Administration pages. Anonymous
access must be enabled in IIS before you can enable it for a website on that
virtual server.
Once you have enabled anonymous access for the virtual server with the
HTML administration pages for IIS, you will need to actually enable this same
level of access for each individual website. To do so, from the website page
itself (a feature that is not available from Central Administration), click Site Settings, click Go To Site Administration under the heading Administration, and
then click Manage Anonymous Access under the heading Users And Permissions. Note that by default, anonymous users can access nothing and you will
need to choose either Entire Web Site or Lists And Libraries.
■
Basic authentication. Basic authentication is an authentication protocol
supported by most Web servers and browsers. Although Basic authentication
transmits user names and passwords in easily decoded clear text, it has some
advantages over more secure authentication methods in that it works through
a proxy server firewall and ensures that a website is accessible by almost any
Web browser. If you use Basic authentication in combination with Secure Sockets Layer (SSL) security, you can help protect the user names and passwords,
making your user information more secure.
Note It is strongly recommended that you use SSL any time you use Basic
authentication to ensure a secure deployment.
Chapter 15:
Configuring Windows SharePoint Services
377
■
Integrated Windows authentication. Integrated Windows authentication
(also known as Windows NT Challenge Response) encrypts user names and
passwords in a multiple-transaction interaction between client and server, thus
making this method more secure than Basic authentication. Disadvantages are
that this method cannot be performed through a proxy server firewall, and
some Web browsers (most notably, Netscape Navigator) do not support it. You
can, however, enable both this method and Basic authentication at the same
time, and most Web browsers will select the most secure option. (For example,
if both Basic and Integrated Windows authentication are enabled, Microsoft
Internet Explorer will try Integrated Windows authentication first.)
■
Certificates authentication. Certificates authentication provides communications privacy, authentication, and message integrity for a TCP/IP connection.
By using the SSL protocol, clients and servers can communicate in a way that
prevents eavesdropping, tampering, or message forgery. With Windows SharePoint Services, SSL helps secure authoring across firewalls and allows more
secure remote administration of Windows SharePoint Services. You can also
specify that SSL be used when opening any website based on Windows SharePoint Services.
You can change authentication methods for virtual servers hosting websites
based on Windows SharePoint Services, and you can change the authentication
method used for the SharePoint Central Administration site. You can also enable
Secure Sockets Layer (SSL) security in IIS to help protect your sites or the administration port for your server.
Caution It should be strongly noted that enabling SSL after establishing the
Windows SharePoint Services site is very difficult. The reason is that Windows SharePoint Services in some cases uses the https:// protocol behind
the scenes when interfacing with the database. This then makes changing
the URL after the fact a difficult task.
Changing Authentication Methods
Each virtual server can use a different authentication method in Internet Information
Services (IIS). You can even enable multiple authentication methods if you are using
the same website content in more than one environment. For example, if you have a
website that is primarily for internal use within your organization, you would most
likely choose Integrated Windows authentication. (It should be noted here that Internet Explorer must be your organization’s standard browser.) If, however, your use of
the site changes and you must allow your organization’s members to access the site
externally through a firewall, you might also want to enable Basic authentication.
378
Part V: Administration of Windows SharePoint Services
Note Basic authentication is less secure than Integrated Windows authentication. It is recommended that you use Basic authentication with SSL to
help make your environment more secure.
When you change authentication methods in IIS, you do not need to change
any settings in Windows SharePoint Services. For example, if you decide to use Integrated Windows authentication instead of Basic authentication, you make the
change only in IIS.
To change authentication methods
1. Click Start, point to All Programs, point to Administrative Tools, and then
click Internet Information Services (IIS) Manager.
2. Click the plus sign (+) next to the server name that contains the virtual server
you want to change.
3. Click the plus sign (+) next to Web sites.
4. Right-click the virtual server, and then click Properties. (See Figure 15-13.)
F15XR13
Figure 15-13
Properties of the virtual server
5. On the Directory Security tab, under Authentication and access control,
click Edit.
6. Select the check boxes for the authentication methods you want to enable, and
clear the check boxes for the authentication methods you want to disable. (See
Figure 15-14.)
Chapter 15:
Configuring Windows SharePoint Services
379
F15XR14
Figure 15-14
Authentication methods
7. Click OK to close the Authentication Methods dialog box.
8. Click OK again to close the Properties dialog box.
Server Farm Configuration
Certain settings that must be made at the server or server-farm level will have a significant impact on your Windows SharePoint Services sites. You can configure these
settings from the SharePoint Central Administration page for your server. This page
controls settings for a particular server in a server farm, and it also contains links to
other servers in the server farm so that you can configure settings for those servers
as well. Most of these settings can also be controlled from the command line, using
the Stsadm.exe tool. The following actions can be taken from the SharePoint Central
Administration page:
Setting the Administrative Group for Windows SharePoint Services
To install Windows SharePoint Services, you must be a member of the local administrators group on the server computer. This group also gives users the permissions needed
to control settings on the Central Administration pages and to run the command-line
tool Stsadm.exe. You can also allow a specific domain group, in addition to the local
administrators group, to have administrative access to Windows SharePoint Services.
You can add users to this group rather than to the local administrators group to separate administrative access to Windows SharePoint Services from administrative
access to the local server computer.
380
Part V: Administration of Windows SharePoint Services
Members of the SharePoint administrators group do not have access to the IIS
metabase, so they cannot perform the following actions for Windows SharePoint
Services:
■
Extend virtual servers (They can, however, create top-level websites or change
settings for a virtual server.)
■
Manage paths
■
Change the SharePoint administrators group
■
Change the configuration database settings
■
Use the Stsadm.exe command-line tool
Members of the SharePoint administrators group can perform any other administrative action using the HTML Administration pages for Windows SharePoint
Services.
Members of both the SharePoint administrators group and the local administrators group have rights to view and manage all sites created on their servers. This
means that a server administrator can read documents or list items, change survey
settings, delete a site, or perform any action on a site that the site administrator can
perform.
Configuring Default E-mail Settings
Windows SharePoint Services sends alerts and other administrator messages by
using an SMTP server. You can specify which SMTP server to use and set the e-mail
address to use for sending alerts and receiving replies for all sites by using the SharePoint Central Administration e-mail settings. You can also specify different settings
for a specific virtual server. At either level, you can specify the following settings:
outbound SMTP server, from address, reply-to address, and character set to use.
Using HTML Administration to Configure E-mail Settings
You use the Configure E-Mail Server Settings page to specify e-mail settings for your
server.
To specify e-mail settings for a server or server farm
1. On the SharePoint Central Administration page, under Server Configuration,
click Configure e-mail server settings.
2. In the Outbound SMTP server box, type the name of the SMTP mail server to
use for sending messages.
3. In the From address box, type the e-mail address to send e-mail messages
from.
Chapter 15:
Configuring Windows SharePoint Services
381
This address appears in the From box of any e-mail messages from the
server. No e-mail messages are sent to this address, so you can use an unmonitored e-mail address if you want.
4. In the Reply-to address box, type the e-mail address that users can reply to.
If a user replies to an e-mail message from the server, it will be sent to this
address. You should use an address that is monitored for the reply-to address.
5. In the Character set box, select the character set to use.
6. Click OK.
You can also specify e-mail settings for a particular virtual server. The virtual
server settings override the settings specified on the SharePoint Central Administration pages. Use these steps when you want a virtual server to use a different SMTP
server for alerts than the one specified in the server settings.
To specify mail settings for a virtual server
1. On the SharePoint Central Administration page, under Virtual Server Configuration, click Configure virtual server settings.
2. On the Virtual Server List page, click the name of the virtual server you want to
configure.
3. Under Virtual Server Management, click SharePoint e-mail configuration.
4. In the Mail Settings section, in the Outbound SMTP server box, type the
name of the SMTP mail server to use for sending messages.
5. In the From address box, type the e-mail address to send e-mail messages
from.
This address appears in the From box of any e-mail messages from the
server. No e-mail messages are sent to this address, so you can use an unmonitored e-mail address if you want.
6. In the Reply-to address box, type the e-mail address that users can reply to.
If a user replies to an e-mail message from the server, it will be sent to this
address. You should use an address that is monitored for the reply-to address.
7. In the Character set box, select the character set to use.
8. Click OK.
Using the Command Line to Configure E-mail Settings
You can also configure e-mail settings from the command line by using the e-mail
operation with Stsadm.exe. The e-mail operation takes the following required parameters: outsmtpserver (the outgoing SMTP server), fromaddress (the e-mail address
to send messages from, which can be an unmonitored address), replytoaddress
382
Part V: Administration of Windows SharePoint Services
(the e-mail address to send replies to, which must be a monitored address), and codepage (the codepage to use). In addition, you can use the optional url parameter to
specify settings for a particular virtual server.
The e-mail operation uses the following syntax:
stsadm.exe -o email -outsmtpserver <smtp server> -fromaddress <from address>
-replytoaddress <reply-to address> -codepage <codepage> [-url <url>]
For example, to configure the e-mail settings to use the server \\SMTPServer
and to use [email protected] as both the from and reply-to address, you
would use syntax similar to the following:
stsadm.exe -o email -outsmtpserver SMTPServer -fromaddress [email protected]
-replytoaddress [email protected]
To set the http://myserver virtual server to use a different codepage, you
would use syntax similar to the following:
stsadm.exe -o email -outsmtpserver SMTPServer -fromaddress [email protected]
-replytoaddress [email protected] -codepage <codepage> -url http://myserver
Manage Site Owners and Users
Using HTML Administration Pages to Manage Users
and Cross-Site Groups
To manage users and cross-site groups, you follow the Manage Users link on the Site
Settings page to the Manage Users page. By using this page, you can view a list of
users and cross-site groups, check which site group a user or cross-site group is
assigned to, add new users and cross-site groups, delete users and cross-site groups,
or assign users and cross-site groups to site groups. When you add new users or
cross-site groups, you also have the option to send an e-mail message to them, inviting
them to use the site. You can even include a custom message in the invitation e-mail
message. For example, you can describe your site and what it should be used for, or
you can add a personal message to the default e-mail invitation.
Note If you do not see the Manage Users option on your Site Settings
page, you are probably in a subsite that uses the permission settings of a
higher-level website of the server or vir tual server. To work with user
accounts and permissions, either go to the parent-level website or change
to using unique permissions for the subsite.
If you want to view which site groups a user is a member of, you use the Manage
Users page.
Chapter 15:
Configuring Windows SharePoint Services
383
To view site group membership for a user or cross-site group
1. On the website you want to manage, click Site Settings.
2. On the Site Settings page, under Administration, click Manage Users.
The users and cross-site groups added to the website and the site groups
they are a member of are displayed on the Manage Users page.
3. From the Manage Users page, you can change which site group a user or crosssite group is a member of.
To change site group membership for a user or cross-site group
1. On the Manage Users page, select the check box next to the user or cross-site
group name you want to change.
2. Click Edit Site Group of Selected Users and Groups.
3. In the Site Group Membership area, select the site group you want the user
or cross-site group to be a member of.
4. Click OK.
You can also add new users and cross-site groups to your site from the Manage
Users page.
To add a new user or cross-site group
1. On the Manage Users page, click Add Users.
2. In the Step 1: Choose Users section, in the text box, type the user’s e-mail
address or the cross-site group’s name.
3. In the Step 2: Choose Permissions section, select the site group that the user
will belong to and then click Next.
4. In the Step 3: Confirm Users section, verify the e-mail address, user name,
and display name information.
5. In the Step 4: Send E-mail section, if you want to send an invitation, select
Send the following e-mail to let these users know they’ve been added,
and type the subject and body text information to send in the e-mail message.
6. Click Finish.
You can delete users or cross-site groups from all site groups by using the Manage Users page. Note that this does not delete the user or cross-site group account,
but it does remove all rights to the website.
To delete a user or cross-site group from all site groups
1. On the Manage Users page, select the check box next to the user or cross-site
group you want to delete.
384
Part V: Administration of Windows SharePoint Services
2. Click Remove Selected Users.
3. On the confirmation message that appears, click OK to remove the users.
Managing Users in a Site Collection
Every website with unique permissions has a Manage Users page that the site’s
administrator can use to add, modify, or delete users. In addition to this page, the
top-level website in a website collection also includes a page that server administrators or the site collection administrator can use to view and delete users. This page
lists all users for the site collection, including the users of the top-level website and
users of any subsites in the site collection. When you remove a user from this list,
the user is removed from all sites and subsites in the site collection.
To remove a user from a top-level website
1. On the top-level website, click Site Settings.
2. Under Administration, click Go to Site Administration.
3. On the Top-Level Site Administration page, under Site Collection Administration, click View site collection user information.
4. Select the check box next to the user you want to remove, and then click
Remove Selected Users.
Managing Users from SharePoint Central Administration
If you are an administrator on the server computer or a member of the SharePoint
administrators group, you might have administrative rights to change settings on the
Site Settings page for any individual site on your server. What happens when a toplevel website owner leaves your organization or a user must be added to or
removed from a site that you do not have administrative rights for? The SharePoint
Central Administration page includes a link for managing users for sites even if the
administrator does not have rights to the site. You can add users or cross-site groups,
remove users or cross-site groups, change site-group membership, and change owners without having to be an administrator on a specific site. You do, however, need
to know the URL for the site and the specific user name that you want to change.
To change the owner of a site collection
1. Click Start, point to All Programs, point to Administrative Tools, and then
click SharePoint Central Administration.
2. On the SharePoint Central Administration page, under Security Configuration, click Manage site collection owners.
3. On the Manage Site Collection Owners page, in the website URL box, type the
URL to the site, and then click View.
4. The information for the current site owner and secondary owner is automatically filled in on the page when you click View.
Chapter 15:
Configuring Windows SharePoint Services
385
5. In the Site Owner section, in the User name box, type the account name for
the new owner.
6. If you have a new secondary contact name, type the account name in the
Secondary Owner section.
7. Click OK.
If you are an administrator on the server computer and need to change the
owner of a site that you do not have administrative access to, you can make the
change from the SharePoint Central Administration page.
To add a new site user
1. Click Start, point to All Programs, point to Administrative Tools, and then
click SharePoint Central Administration.
2. On the SharePoint Central Administration page, under Security Configuration, click Manage Web site users.
3. On the Manage Web Site Users page, in the Site URL box, type the URL to the
site, and then click View.
4. In the Add a User section, in the Account name box, type the account name
for the new user.
5. In the Display name box, type the full name for the new owner.
6. In the E-mail address box, type the e-mail address for the new user.
7. In the Site group box, select a site group to add the user to, and then click
Update.
You can also delete a user or change a user’s site-group membership from this page.
To delete a site user or change site-group membership
1. Click Start, point to All Programs, point to Administrative Tools, and then
click SharePoint Central Administration.
2. On the SharePoint Central Administration page, under Security, click Manage
Web site users.
3. On the Manage Web Site Users page, in the Site URL box, type the URL to the
site, and then click View.
4. In the Enter Site User section, in the Account name box, type the user
account you want to change or delete, and then click View.
5. To change site-group membership, select the check box for the site group you
want the user to be a member of and then click Update.
6. To remove the user from all site groups, select the Delete this user account
check box and then click Update.
386
Part V: Administration of Windows SharePoint Services
Using the Command Line to Manage Users
You can add a user account to your site by using the adduser operation. The
adduser operation takes the url (of the site where you want to add the user), userlogin, useremail, username, and role parameters, plus the optional parameter siteadmin. You use the siteadmin parameter to specify that the user is the site collection
administrator or owner of the site collection. Note that if you are using Active Directory account creation mode, you do not need to specify the userlogin parameter;
you would use the useremail parameter to identify the user instead. (For more information about Active Directory Account creation mode, see Chapter 2, “Installing
Windows SharePoint Services.”)
For example, to add User1 as an administrator for http://My_Server/site1 in
domain account mode, you would type
stsadm.exe -o adduser –url http://My_Server/site1 –userlogin DOMAIN1\User1
-useremail [email protected] -username "User 1" -role administrator
You use the deleteuser operation to remove users from a site. The deleteuser
operation takes the url and userlogin parameters. To remove User1 from
http://server1/site1, you would type
stsadm.exe -o deleteuser –url http://My_Server/site1
–userlogin DOMAIN1\User1
You can assign a user to a site group from the command line by using the userrole operation. The userrole operation takes the url, userlogin, role, and add or
delete parameters. For example, to add the user User1 to the Contributor site group
for site http://server1/site1, you would type
stsadm.exe -o userrole –url http://My_Server/site1 –userlogin DOMAIN1\User1
-role contributor -add
Note that this does not remove the user from any site groups she was previously a member of.
Configuring Antivirus Protection
Windows SharePoint Services now allows you to help protect your users from
uploading or downloading files that contain viruses. When you have installed an
antivirus scanner that is compatible with Windows SharePoint Services, you can
enable the antivirus protection feature for your server. When you enable the antivirus protection feature, files are checked for viruses when a user adds a document to
a document library or list, or when a user views a document in a document library
or list. If a virus is found, the scanner attempts to clean the file; if the file cannot be
cleaned, the scanner blocks the file from being added or viewed.
Consult your antivirus software vendor to find out whether they offer a virus
scanner for use with Windows SharePoint Services and for information about installing the virus scanner. Or, for a list of antivirus software vendors that support antivirus
Chapter 15:
Configuring Windows SharePoint Services
387
protection for Windows SharePoint Services, see the Windows SharePoint Services
Partners website.
Note If a file is uploaded and is later identified as containing a virus, the
user will not be able to open the file. In this situation, however, the user
might still be able to save the file locally and open it from his computer.
You enable and configure antivirus protection at the server level. When
enabled, antivirus protection is available for all document libraries on all sites and
subsites on your server or for all servers in your Web farm. You can use HTML
Administration pages or the command-line tool to configure antivirus protection.
You must install Windows SharePoint Services–compatible antivirus software
on any server computer running Windows SharePoint Services before you can
enable antivirus protection in Windows SharePoint Services. If you are in a serverfarm configuration, antivirus software must be installed on every Web front-end
server in the server farm. Consult your antivirus software vendor to find out whether
they offer a virus scanner for use with Windows SharePoint Services and for information about installing the virus scanner.
Note McAfee Security is providing a virus scanner for customers using Windows SharePoint Services. For information about their virus scanner, go to the
McAfee website (http://www.McAfee.Com). Or, for a list of antivirus software
vendors that support antivirus protection for Windows SharePoint Services,
see the Windows SharePoint Services Partners website.
Using HTML Administration Pages to Configure Antivirus Protection
You use the Configure Antivirus Protection page in the SharePoint Central Administration pages to enable and configure antivirus protection.
To enable antivirus protection for your server or Web farm
1. Click Start, point to Programs, point to Administrative Tools, and then click
SharePoint Central Administration.
2. On the SharePoint Central Administration page, under Security Configuration,
click Configure antivirus protection.
3. Select the Scan documents on download check box.
4. Select the Scan documents on upload check box.
388
Part V: Administration of Windows SharePoint Services
5. If desired, select the Attempt to clean infected documents check box.
6. In the Time out scanning after ___ seconds box, type the number of seconds to allow before timing out the scanning process.
The default time is 300 seconds, or 5 minutes. This should be enough
time to allow the antivirus processes to finish without affecting performance.
The default time is recommended, but you can adjust this time if you are experiencing performance issues.
7. In the Allow scanner to use up to ___ threads box, type the number of
threads to allow the scanning process to take up.
By default, the number of threads is set to 5, which should be sufficient
for even a large number of sites. The default number of threads is recommended, but you can reduce the number of threads if you are experiencing
performance slowdown.
8. Click OK.
Using the Command Line to Configure Antivirus Protection
You can also configure antivirus protection by setting properties on the command line.
To set a property, you use the Stsadm.exe tool with the setproperty operation. The
properties listed in Table 15-4 are available for use in configuring antivirus protection.
Table 15-4
Properties Available for Use in Configuring Antivirus Protection
Property Name
Description
Values
avcleaningenabled
Specifies whether antivirus cleaning is enabled or disabled
yes/no
avdownloadscanenabled
Specifies whether documents are
scanned on download
yes/no
avnumberofthreads
Specifies the number of threads
to use for antivirus processes
A numerical value, the
number of threads to use
avtimeout
Specifies how long to wait before
timing out an antivirus process
A numerical value, in
seconds
avuploadscanenabled
Specifies whether documents are
scanned on upload
yes/no
The following example shows the syntax to use when setting an antivirus
property:
stsadm.exe -o setproperty -pn <property name> -pv <property value>
For example, to set the avtimeout property to 200, you would use the following syntax:
stsadm.exe -o setproperty -pn avtimeout -pv 200
Chapter 15:
Configuring Windows SharePoint Services
389
Configuring Site Quotas and Locks
If you are using Windows SharePoint Services in a large environment, such as at an
Internet Service Provider (ISP) or in a large intranet, you need to be able to maintain
control over your server resources and carefully monitor areas such as storage space
and site security. You must be able to ensure that one user’s site cannot use so many
resources that other sites can no longer function. Windows SharePoint Services
allows you to specify quotas for sites so that you can manage your site and server
resources. You can set quota limits for the following item:
■
Storage. When you set a quota limit for storage, you can set two values: a
warning value and a maximum value. When a site passes the warning limit, an
e-mail message is sent to the site administrator and owner notifying them that
their site is nearing their storage quota. When a site meets the maximum limit,
another e-mail message is sent to the owner and administrator, and no new
content can be added to the site.
Note The size of the data reported by quotas does not necessarily match
the size of the storage in SQL Server. This is because the quota feature
estimates storage figures for empty sites (sites that contain no user content) and includes those figures in the quota, as well as the actual storage
from the database. The estimated size of an empty site includes the real
size of the template pages for Windows SharePoint Services, such as the
forms pages and pages in the _layouts directory, which are not normally
counted because there is only one copy of these pages for all sites.
Although each site has a unique URL to the pages, the site does not have a
unique instance of the page.
You can create multiple sets of quotas, called quota templates, and use them in
different areas of your Web farm or to suit different users. For example, in an ISP setting, you could have the following quota templates:
■
Free. Applied to free or demonstration sites, it restricts users to 10 MB of
storage and 5 users.
■
Standard. Applied to monthly-fee sites, it allows site owners up to 25 MB of
storage and 50 registered users.
■
Premium. Applied to extranet sites for large corporate customers, it allows
organizations up to 10 GB of storage and unlimited user accounts.
You must be an administrator of the local server computer or a member of the
SharePoint administrators group to be able to manage quotas and quota templates.
390
Part V: Administration of Windows SharePoint Services
Enabling Quotas
The quota feature is disabled by default in Windows SharePoint Services—there
are no default quota values or templates. To enable quotas, you use the following
methods:
■
To use quotas for your server or Web farm, you create a quota template.
■
To use quotas for a particular virtual server, you assign a default quota template
to that virtual server.
■
To use quotas for a particular top-level website, you assign a quota template to
the top-level website when you create the site.
■
To use a set of quota values for a single site only, you can apply specific quota
limits to the site itself, independent of any quota template.
You can reverse your decision to use quotas at any point in the hierarchy. For
example, applying a default quota template to a virtual server does not mean that all
top-level websites under that virtual server must use the quota limits—it only means
that they can. Settings that you apply to a single site can be cleared if you no longer
want to use quotas.
About Quota Templates
Quota templates and the settings specified in them are stored in the configuration
database for your server or server farm. Quota values apply to top-level websites
and are applied when you create a top-level website. You can specify a default template to use for all top-level websites created on a virtual server, for example, or you
can specify the template to use when you create the top-level website. The values
listed in the quota template are copied into the database for the top-level website
and are referenced from there.
Note If you change the values for a quota template, those changes apply
only to new top-level websites created using that template, not to existing
top-level websites. If you want to apply the template changes to existing
sites, you must use the Windows SharePoint Services object model to make
the change with a SQL Server query. Likewise, when you delete a quota template, the template is removed from the configuration database, but any
top-level websites created using that template will retain the quota values.
If you want to remove quotas from all sites using a particular quota template, you must use the object model and perform a SQL Server query.
Chapter 15:
Configuring Windows SharePoint Services
391
Managing Quota Templates
You manage quota templates from the SharePoint Central Administration pages for
your server or Web farm. You can create or delete templates or change the values in
the templates.
To create a quota template
1. Click Start, point to All Programs, point to Administrative Tools, and then
click SharePoint Central Administration.
2. On the Central Administration page, under Component Configuration, click
Administer quotas and locks.
3. On the Administer Quotas And Locks page, click Manage Quota Templates.
4. On the Manage Quota Templates page, in the Template name area, click Create a new quota template.
5. In the Template to start from: box, select a template to base your new template on.
6. In the New template name box, type the name to use for your new quota
template.
7. Select the Limit site storage to a maximum of: ___ MB check box, and then
type the amount of storage to allow at a maximum.
8. In the Storage Limit Values section, select the Send warning e-mail when
site storage reaches ___ MB check box, and then type the amount of storage
to allow before sending a warning e-mail.
9. In the Invited User Limits section, select the Limit invited users to a maximum of: ___ users, and then type the number of users to allow.
The user limit option is availablenly in Active Directory account mode.
10. Click OK.
When you click OK, the new template is added to the list of available
templates and the page is refreshed.
You can delete a quota template if you change your quota structures. However,
remember that deleting a quota template will not delete quota values from sites that
were created using the quota template. If you want to remove quotas from all sites
using a particular quota template, you must use the object model and perform a SQL
Server query.
To delete a quota template
1. Click Start, point to All Programs, point to Administrative Tools, and then
click SharePoint Central Administration.
392
Part V: Administration of Windows SharePoint Services
2. On the Central Administration page, under Component Configuration, click
Administer quotas and locks.
3. On the Administer Quotas And Locks page, click Manage Quota Templates.
4. On the Manage Quota Templates page, in the Template name area, click Edit
an existing template.
5. In the Template to modify: box, select the quota template you want to
delete.
6. Click Delete.
7. When you click OK, the template is removed from the list of available templates and the page is refreshed.
You can change individual quota values in a template. The new values apply
only to new top-level websites created using the quota template. The changed values are not applied to existing sites unless you use the object model to update the
values in the database.
To change an existing quota template
1. Click Start, point to All Programs, point to Administrative Tools, and then
click SharePoint Central Administration.
2. On the Central Administration page, under Component Configuration, click
Administer quotas and locks.
3. On the Administer Quotas And Locks page, click Manage Quota Templates.
4. On the Manage Quota Templates page, in the Template name area, click Edit
an existing template.
5. In the Template to modify: box, select the quota template you want to
change.
6. Update the options you want to change, and then click OK.
7. When you click OK, the template is updated and the page is refreshed.
Specifying a Quota Template for a Virtual Server
When you extend a new virtual server, you can specify a quota template to use as
the default quota template for that virtual server on the Extend And Create Content
Database page. Any new top-level websites that you create under the virtual server
will automatically use the values in the default quota template. You can change the
default quota template for a virtual server from the Virtual Server Settings page.
Keep in mind that changing the default quota template does not change quota values for existing top-level websites. Only newly created top-level websites will use
the new quota template.
Chapter 15:
Configuring Windows SharePoint Services
393
To change the default quota template for a virtual server
1. Click Start, point to All Programs, point to Administrative Tools, and then
click SharePoint Central Administration.
2. On the Central Administration page, under Virtual Server Configuration,
click Configure virtual server settings.
3. On the Virtual Server List page, select the name of the virtual server you want
to change.
4. Under Virtual Server Management, click Virtual server general settings.
5. In the Default Quota Template section, select the quota template to use as
the default template when new top-level websites are created.
6. Click OK.
Specifying Quota Values for a Specific Site
If you want to specify a different set of limits for a particular site, you can do so.
Specifying quota values for a single site is an easy way to turn on quotas on a siteby-site basis. Similarly, if you need to make an exception to a quota template for a
particular site, you can change the quota value for just that site. Keep in mind, however, that it is possible to lock a site simply by changing the quota value. If you
already have quotas set for a particular site and want to update the value, be sure to
check the site’s current quota levels before making the change. For example, suppose the current quota level for site storage is 25 MB and a site has 21 MB. If you
change the value to 20 MB, the site will be locked as soon as you save the change.
To prevent locking a site accidentally, be sure to check the current storage or invited
user count for the site before making a change to the quota values.
If you do not know what the existing quota values are for a site, you can use
the SharePoint Central Administration page to view the current values and the current data (storage used and number of users) for the site.
To view current quota values and data for a site
1. Click Start, point to All Programs, point to Administrative Tools, and then
click SharePoint Central Administration.
2. On the Central Administration page, under Component Configuration, click
Administer quotas and locks.
3. On the Administer Quotas And Locks page, click Site Quota Settings and
Locks.
4. In the Select a top-level Web site section, type the URL in the Enter the top
level Web site URL box, and then click View Data.
5. In the Site Quota Information section, view the settings listed to see the
quota settings and current values.
394
Part V: Administration of Windows SharePoint Services
To view the current data for a site, you can also use the Site Collection Usage
Statistics Summary page for the top-level website.
To view quota data for a site
1. On the site you want to view data for, click Site Settings.
2. Under Administration, click Go to Site Administration.
3. Under Site Collection Administration, click View site collection usage
summary.
After you have checked the site quota data, you can change the quota values
for a site. Note that this action does not change the quota template, and the change
does not affect any site except the site you specify.
To change quota values for a site
1. Click Start, point to All Programs, point to Administrative Tools, and then
click SharePoint Central Administration.
2. On the Central Administration page, under Component Configuration, click
Administer quotas and locks.
3. On the Administer Quotas And Locks page, click Site Quota Settings and
Locks.
4. In the Select a top-level Web site section, type the URL in the Enter the toplevel Web site URL box, and then click View Data.
5. In the Site Quota Information section, change the Limit storage to a maximum of __ MB amount, Send warning e-mail when site storage reaches
__MB amount, or Maximum users allowed: amount setting.
6. Click OK.
Note The user limit option is available only in Active Directory account
mode.
Managing Locks
You can use locks to stop sites from exceeding your storage quota limits and to
block all users from accessing a site if necessary. Sites are locked automatically
when they exceed the maximum storage quota. You can also lock a site manually,
if, for example, it is in violation of your site use policies. Depending on the type of
lock, the result of a locked site is different. The differences are as follows:
■
When a site is locked for exceeding a storage quota limit, users who attempt to
upload new content see a disk full error.
Chapter 15:
■
Configuring Windows SharePoint Services
395
When a site is locked manually, users who attempt to view the site will see an
access denied message.
Sites can be unlocked by different methods, depending on the reason for the
lock. Site administrators can unlock sites by themselves if the sites are locked for
exceeding quota limits. Only a server administrator can clear a manual lock. Table 15-5
lists the lock reasons and methods for unlocking sites.
Table 15-5
Lock Reasons and Methods for Unlocking Sites
Server Administrator
Action to Unlock
Site Administrator
Action to Unlock
Storage limit exceeded
Change the quota value, or clear
the Adding Content Prevented lock
Delete excess site content
or documents
Manual lock by server
administrator
Clear the All Access Prevented lock
None
Lock Reason
If you need to lock a site and deny all users access to it, either temporarily or
permanently, you do so by using the Site Quota Settings And Locks page.
To lock a site manually
1. Click Start, point to All Programs, point to Administrative Tools, and then
click SharePoint Central Administration.
2. On the Central Administration page, under Component Configuration, click
Administer quotas and locks.
3. On the Administer Quotas And Locks page, click Site Quota Settings and
Locks.
4. In the Select a top-level Web site section, type the URL in the Enter the toplevel Web site URL box, and then click View Data.
5. In the Site Lock Information section, select Adding content prevented or
No access.
6. If you want to further document the reason for the lock, type an explanation in
the Additional lock reason information: box.
7. Click OK.
When a site has been locked manually, you can unlock it by using the Site
Quota Settings And Locks page.
To unlock a site
1. Click Start, point to All Programs, point to Administrative Tools, and then
click SharePoint Central Administration.
396
Part V: Administration of Windows SharePoint Services
2. On the Central Administration page, under Component Configuration, click
Administer quotas and locks.
3. On the Administer Quotas And Locks page, click Site Quota Settings and
Locks.
4. In the Select a top-level Web site section, type the URL in the Enter the toplevel Web site URL box, and then click View Data.
5. In the Site Lock Information section, select Not locked, and then click OK.
Configuring Usage Analysis
If you want to know what kind of impact your website has, you need to track how
many users visit your site, the type and number of hits your site receives, and other
site-usage information. Microsoft Windows SharePoint Services includes features
that analyze the usage of your site. Summary and detailed usage reports supply
information such as:
■
Number of page hits for each individual page
■
Number of unique users
■
Browser and operating system information
■
Referring domains and URLs
Tracking usage information can be useful for identifying which content on
your site is being heavily used (and therefore should be kept) and which content is
not being heavily used (and might be a candidate for archival). In addition to site
usage statistics, you can also keep track of how much storage space your site is taking up and the level of activity your site is generating. This information is gathered
as part of the quota tracking for sites. For more information about quotas, see the
“Configuring Site Quotas and Locks” section earlier in this chapter.
The usage reports rely on usage log data gathered from the websites and
stored in the content database for each virtual server. The log data is a summary
record of transactions on your website. When you view a usage report in Windows
SharePoint Services, the data is arranged into a list format. You must be a member
of the administrator role (or have the View Usage Data right) for a site to view the
site usage statistics.
You configure the settings for processing the usage log by using commands in
HTML Administration pages. From the SharePoint Central Administration page, you
can control the following items:
■
Whether or not to log usage data. Usage analysis is not enabled by
default. If you want to use the usage analysis features for your server, you
must enable the usage analysis logging process. Log files are created daily to
track usage information. When the log file is processed, a flag is added to indicate that is has been processed. If you do not want to track usage analysis
Chapter 15:
Configuring Windows SharePoint Services
397
data and you want to conserve disk space, you can turn off data logging for
usage analysis.
■
Where the log files are stored and how many log files to create. By
default, the log files are in c:\Windows\system32\LogFiles\STS. Inside this
folder is a folder for every virtual server, and under those folders are folders for
each day. You can specify any other location you prefer. You can specify that
up to 30 log files are created.
Note If you choose a different log file location, you must be sure to give
the STS_WPG user group Read, Write, and Update permissions to the directory. Without these permissions, the usage log files cannot be created or
updated by IIS. For more information about setting permissions for a directory, see the Microsoft Windows Help system.
■
Whether or not to process the usage logs and when to do so. By default,
the log files are set to be processed every day at 1:00 A.M. You can schedule
the usage log to be processed at a more convenient downtime for your websites. You can also specify the end time for the usage log processing. If your
websites are primarily used by internal employees, for example, you might
schedule the log to be processed at night, when demand on the sites is lower
than during working hours. If you have multiple servers, you can stagger the
processing. For example, you can configure the processing to start at midnight
and stagger it by 15 minutes so that server1 starts at 12:00, server2 starts at
12:15, server3 at 12:30, and so on.
In Microsoft Windows SharePoint Services, usage analysis data is gathered
from the front-end Web servers and collected into temporary files. When the daily
log processing takes place, the data is merged into the content databases on the
back-end servers. Usage data is collected for an entire site collection on one server
at a time. Even though the data is logged and stored for an entire site collection,
when you view the data in HTML Administration pages, you can see only the data
for a particular website or subsite, not for the entire site collection.
Note Although you can see the total number of hits for a site collection on
the Site Collection Usage Summary page, for detailed information you must
use the Site Usage Report page for the individual site or subsite.
Usage data is kept for up to three months in the database for historical purposes. Daily information is stored for 31 days, and monthly information is stored for
398
Part V: Administration of Windows SharePoint Services
24 months. Note that usage analysis processes rely on the Microsoft SharePoint
Timer service to manage the timing of log processing.
Note Because usage analysis processing runs only once a day, when you
enable usage analysis processing, you will not see any data until the next
day. Log processing is done only for a single day’s worth of data. If you turn
off the log processing for a week but leave the data logging turned on, the
next time you turn on processing, it will process only one day’s worth of log
files. The log files for all of the days before that will remain unprocessed.
You control settings for usage analysis processing from the SharePoint Central
Administration page. You must be an administrator of the local server computer
or a member of the SharePoint administrators group to configure usage analysis
settings.
Note When you configure usage analysis processing for a server, it takes
effect for any existing virtual servers. If you later add a virtual server, you
must configure usage analysis processing again to enable usage analysis
for the new virtual server.
To configure usage analysis processing for a server
1. Click Start, point to All Programs, point to Administrative Tools, and then
click SharePoint Central Administration.
2. Under Component Configuration, click Configure usage analysis processing.
3. In the Logging Settings section, select the Enable logging check box.
4. In the Log file location box, type the location to store the log file.
The default location for the log file is c:\Windows\system32\LogFiles\STS.
5. In the Number of log files to create box, type a number from 1 to 30.
In general, you should use a number that is one to three times the number of database servers in your server farm, with a maximum number of 30 log
files.
6. In the Processing Settings section, select the Enable usage analysis processing check box.
Chapter 15:
Configuring Windows SharePoint Services
399
7. Under Run processing between these times daily, specify the range of
times to start the usage analysis log processing. In the Start box, select the earliest time of day to begin running log processing. In the End box, select the latest time to begin running log processing.
8. Click OK.
Managing HTML Viewers
Included with Windows SharePoint Services is the ability to connect to an HTML
viewing server. The HTML viewing server provides support for users who want to
view the content of files on the Windows SharePoint Services website but do not
have Microsoft Word, Excel, or PowerPoint from Office 97 (or a newer release of
Microsoft Office) installed on their local computer. Even users who have only a Web
browser (Microsoft Internet Explorer or Netscape Navigator) can view content by
having the native Office file format converted to HTML at the time the user opens
the file. Although there is a slight delay while the transformation takes place, the
converted file is extremely close to the WYSIWIG formatting of the original. In addition to transforming files on the fly for end users, administrators can use a batch
process mode of HTML Transformations to convert the contents of entire folders
to HTML.
Note By default, the HTML viewing service supports only the following document types: .doc, .xls, .ppt, and .pps.
Transformation of a supported document can take from 1 to 30 seconds,
depending on the complexity and size of the document as well as the speed and
available resources of the dedicated computer. To provide for this ability and assure
a fast response time, you should dedicate a separate computer to this service as the
process is very CPU intensive.
After the server is set up, it can be administered through the Configure HTML
Viewer page in SharePoint Central Administration pages. For more information
about setting up an HTML Transformation Server, see the “HTML Transformations
Service for Windows SharePoint Services” white paper on the Office 11 Resource Kit
(Beta) website.
To configure Windows SharePoint Services to use HTML Transformations
1. Click Start, point to Administrative Tools, and then click SharePoint Central Administration.
2. Under Server Configuration, click Configure HTML Viewer.
3. Select the Turn on HTML Viewer check box.
400
Part V: Administration of Windows SharePoint Services
4. In the Path to HTML Viewer Server box, type the full URL to the transformation server.
5. In the Maximum Cache Size box, type the maximum size to allow for the
HTML viewing cache.
6. In the Maximum File Size box, type the maximum file size to view.
7. In the Timeout Length box, type the length of time to wait before ending an
HTML viewer process.
8. Click OK.
Managing and Customizing Search
Microsoft Windows SharePoint Services enables users to search all website content
on a particular virtual server. Because all site information (including documents) is
stored in a database, the search model will allow searching of all site content.
The type of search you use for Windows SharePoint Services depends on the
other software you are running in your server system, as outlined here:
■
If you have Microsoft SharePoint Portal Server “v2.0” installed, you can use the
search features included with SharePoint Portal Server “v2.0” to search your
websites from a portal site.
■
If you are running Microsoft SQL Server 2000, Windows SharePoint Services uses the SQL Server 2000 full-text searching features to search for website
content.
Search features are available only for Windows SharePoint Services with SQL
Server 2000 or with SharePoint Portal Server “v2.0”. If you are running Microsoft SQL
Server Desktop Engine 2000 (MSDE) for your database and do not have SharePoint
Portal Server “v2.0” , no search features are available. If you want search, you must
either upgrade to SQL Server 2000 or use SharePoint Portal Server “v2.0” to search
your website.
Understanding Search in Windows SharePoint Services
Search is available per virtual server. This means that search is either turned on or off
for all top-level websites and subsites on a particular virtual server. Subsites inherit
the search settings from parent sites. If search has not been enabled for a virtual
server, the search links will not appear in the websites that reside on that virtual
server.
Search can query most lists and all document libraries on your site. Search cannot query lists of lists (such as the Quick Launch bar) or surveys. Users can search
the entire site or a single list page within the site (for example, for a particular contact in the Contacts list).
Chapter 15:
Configuring Windows SharePoint Services
401
Searching with SQL Server 2000
If you are using SQL Server 2000, you can enable full-text searching for your websites. SQL Server 2000 full-text searching is a good solution for searching Windows
SharePoint Services websites in small or medium organizations; however, SQL
Server 2000 full-text search does not scale well to large server farms. Search catalogs
can use up to 40 percent of the hard disk space that data uses. There is a hard limit
of 256 search catalogs per server; plus you will encounter performance issues when
you reach 1 million rows in the search catalog table. If you are running a large server
farm, it is not advisable to offer search features for all of them. Consider adding
search for premium customers if you are an ISP or Application service provider
(ASP), or for only a limited number of sites if you are hosting websites based on
Windows SharePoint Services inside a large organization.
SQL Server 2000 full-text search supports only one language for each database.
If you are supporting Windows SharePoint Services websites in several languages
and want to enable full-text search in those languages, consider hosting each language on a separate virtual server with a separate database for each language.
SQL Server 2000 performs linguistic analysis on full-text search catalogs. The following list includes the languages for which linguistic analysis packages are
available:
■
Neutral
■
Dutch
■
English (UK)
■
English (US)
■
French
■
German
■
Italian
■
Japanese
■
Korean
■
Simplified Chinese
■
Spanish (Modern)
■
Swedish
■
Traditional Chinese
■
Thai
The neutral linguistic analysis package is provided for use with languages not on
this list. For more information about SQL Server, full-text search, and languages, see
the SQL Server 2000 documentation. You can download the documentation from the
following site: http://www.microsoft.com/sql/techinfo/productdoc/2000/books.asp.
402
Part V: Administration of Windows SharePoint Services
When you enable full-text search in Windows SharePoint Services, a new,
empty catalog is created by default and named ix_databasename. Content is added
to this catalog as it is added to your new website. Aside from enabling and disabling
full-text search, any search management or monitoring must be done from within
SQL Server 2000 with the SQL Server administration tools. For more information
about managing full-text search in SQL Server 2000, see “Administering Full-Text
Features Using SQL Enterprise Manager” in the SQL Server Books Online system at
http://www.microsoft.com/sql/techinfo/productdoc/2000/books.asp.
Enabling Search for SQL Server 2000
To use search with Windows SharePoint Services and SQL Server 2000, you must
have full-text searching installed on your SQL Server computer. Full-text searching is
usually installed by default, but if it is not installed on your server, you can install it
easily with the SQL Server Setup tools.
To install full-text indexing with SQL Server 2000
1. On your SQL Server computer, run the SQL Server 2000 Setup program.
2. On the setup screen, click SQL Server 2000 Components, and then click
Install Database Server.
The Microsoft SQL Server 2000 Installation Wizard opens.
3. On the Welcome screen, click Next.
4. On the Computer Name screen, select the computer type, and then click Next.
5. On the Installation Selection panel, select Upgrade, remove, or add components to an existing instance of SQL Server, and then click Next.
6. On the Instance Name panel, clear the Default check box, and then in the
Instance Name box, select your SQL Server instance for Windows SharePoint
Services and click Next.
7. Select Add components to your existing installation, and then click Next.
8. On the Select Components panel, in the Sub-Components list, select FullText Search, and then click Next.
9. Click Next again to begin the installation.
10. Click Finish.
After you have configured SQL Server 2000 to support full-text searching,
you’re ready to enable search for Windows SharePoint Services.
To enable search for Windows SharePoint Services
1. On your server computer running Windows SharePoint Services, click Start,
point to All Programs, point to Administrative Tools, and then click SharePoint Central Administration.
Chapter 15:
Configuring Windows SharePoint Services
403
2. Under Component Configuration, click Configure full-text search.
3. In the Search Settings section, select the Enable full-text search and indexing check box.
4. Click OK.
Note Full-text searching does not include any file types other than .doc,
.xls, .ppt, .txt, and .htm in the search results
If you are using the full-text searching for Microsoft SQL Server 2000, the following filters are installed by default: .doc, .xls, .ppt, .txt, and .htm. You can
install custom filters to allow you to search other file types. For more information about adding filters to SQL Server full-text searching, see the SQL Server
2000 documentation as stated above along with the site URL.
Configuring Blocked File Extensions
Microsoft Windows SharePoint Services provides the ability to restrict certain kinds
of files from being uploaded or retrieved, based on the file extension. For example,
a file with the .exe file extension could potentially contain code that runs on client
computers when it is downloaded. Because it has the .exe file extension, the file can
be run on demand when it is downloaded. If files with the .exe file extension are
blocked, users can neither upload nor download a file with the .exe extension, and
potentially dangerous content in the .exe file cannot be downloaded. This feature
does not prevent all exploits based on file types, nor is it designed to do so.
Summary
In this chapter, we have addressed the process for configuring Windows SharePoint
Services sites.
The first crucial step is, of course, the planning. You will achieve a much better
site for your users if you carefully plan what data you will share and exactly who
should have access to that data. If your users have a good experience the first time
they access the site, they will be much more likely to return and use this very powerful tool for managing corporate information assets.
We have addressed how to use the management user interface both through
SharePoint Central Administration as well as through Site Settings on the Web page
itself. Often times you can configure a particular setting by going through either
Central Administration or Site Settings. At first this might seem confusing, but as you
become more familiar with the interface, you will find it is a great advantage.
Chapter 16
Windows SharePoint
Services Site Administration
In this chapter:
Using Templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 406
Site Creation Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 419
Allowing Access to Websites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 421
Managing Site Creation Rights . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 437
Statistics. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 438
Managing Alerts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 441
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 447
This chapter will focus on skills and topics you will need to effectively administer
Microsoft Windows SharePoint Services sites for your enterprise. You will learn how
to create sites and then how to apply templates, lists, documents, and other workspaces to your sites so that you can maximize Windows SharePoint Services. In addition, you will find information about how to configure security for the sites and
subsites in your collections.
Your users can contribute to sites by using nothing more than a Web browser.
However, if you use a Windows SharePoint Services–compatible client program,
such as Microsoft Office 2003, you can work seamlessly with the site, saving files to
libraries, editing documents in the client program, and moving or linking that information to your site.
You can add information to the SharePoint site, such as events, names, and
phone numbers of people with whom your team communicates, and to-do items.
You can also do the following:
■
Post documents to share with other team members
■
Hold newsgroup-style discussions
■
Take a poll of the team to make a decision
405
406
Part V: Administration of Windows SharePoint Services
As team members add or delete documents, lists, discussions, and surveys,
Windows SharePoint Services automatically updates links to the content so that it’s
always easy to find. You can also create alerts so that you are notified of changes to
the site.
Pages in the site will display lists of information, allowing team members to
organize the information any way they want, such as by subject, due date, or author.
For example, you can do the following:
■
Restrict the display to see only the set of information that applies to you
■
Hide information that doesn’t interest you
■
Change the order in which the information is listed
■
Set up customized views to make it easy for your team members to focus
quickly on pertinent information
To use the features described, you will want to acquaint yourself with the management interface where most of these features will be available to create and configure. From the site’s Web page, select Site Settings from the top of the window.
(See Figure 16-1.) This will take you to the page for site administration. Throughout
this chapter, we will be exploring administration tasks that you will access through
this menu structure.
Figure 16-1
F16XR01
Web Site Administration main menu
Using Templates
When creating sites to serve business needs, one of the first things you will need to
decide is what you want your site to look like. For instance, do you want to include
sections for announcements, members, and events? Will you want a separate part of
the page to display news items or links to other pages? Fortunately, you don’t have
to build this view of information each time you create a new site because Windows
Chapter 16: Windows SharePoint Services Site Administration
407
SharePoint Services includes predefined views called site templates. Alternatively,
you will be able to customize a site and then save a site template based on that new
design for use on other sites. A site template includes all the pages, information, and
styles needed to create a site, including any list templates used in the site. Another
kind of template, called a list template, includes all the pages, information, and styles
needed to create a single list.
The first time you access the newly created site, you will have the opportunity
to select a template from a page that shows all templates available on the server and
site collection. This set is filtered based on the site language and the site definition
ID that your site is based upon. As mentioned earlier, these templates can be customized for the site. (See Figure 16-2.)
Note Each template maintains its identify via site definition ID. For example, a site based on the Meeting Workspace template has a different site
definition ID than a site based on the Team Site template. As an example, if
you create a Meeting Announcements custom list template from the
Announcements list in a site based on a Meeting Workspace template, that
template is not available from within a site based on the Team Site template.
Figure 16-2
F16XR02
Template selection
Templates are also known as site definitions. Later we will explore how you
can create your own customized templates or site definitions. For now, we’ll focus
on the site definitions that are available on the server by default.
408
Part V: Administration of Windows SharePoint Services
Team Site Template
Figure 16-3 shows what the default Team Site template looks like.
Figure 16-3
F16XR03
Team website
From here, you can customize the team’s website. However, note the number
of features that are available by default for your use on this page. You can easily add
announcements, events, and links by simply clicking the Add button in each of the
Web Parts. Direct your attention to the lefthand column of the screen, where you
will see other features that are included by default in the Team Site template. (Refer
to Figure 16-3.)
The items provided include:
■
A shared document library, where users of the site can easily create and upload
documents
■
A link to make it easy for users to create a picture library
■
Two predefined lists already created:
■
A contacts list, where you can add information about people your team
works with
■
A task list, to keep track of work that you or your team needs to complete
■
A general discussion board, which is a place to hold newsgroup-style discussions on topics relevant to your team.
■
A link to make it easy to create a survey to quickly poll team members about
a particular concept or topic. If the survey is set up so that respondents’ names
are visible, the All Responses view enables you to see how each team member
responded.
Chapter 16: Windows SharePoint Services Site Administration
409
Blank Site Template
The Blank Site template is shown in Figure 16-4.
Figure 16-4
F16XR04
A website using the Blank Site template
This page can be customized exactly as you want through the Modify Shared
Page drop-down menu in the upper-right corner of the screen. (Refer to Figure 16-4.)
Unlike the Team Site template, the Blank Site template will not automatically set up
any document or picture libraries for you, nor will it set up lists or discussion forums.
Document Workspace
A Document Workspace site is a Microsoft Windows SharePoint Services site that
is centered on one or more documents. Colleagues can easily work together on a
document—either by working directly on the Document Workspace site copy or by
working on their own copy, which they can update periodically with changes that
have been saved to the Document Workspace site copy.
Creating a Generic Document Workspace Site
You might need to contact an administrator to grant you permission to create Document Workspace sites. Once you have the required permission, you can use the
following steps to create a generic document workspace site:
1. Go to a Microsoft Windows SharePoint Services website where you have permission to create Document Workspace sites.
2. On the top link bar, click Create.
3. On the Create page, under Web Pages, click Sites and Workspaces.
4. Enter a title, description, and URL, and click a permission setting. Then click
Create.
410
Part V: Administration of Windows SharePoint Services
5. On the Template Selection page, click Document Workspace in the Template
box, and then click OK.
You have just created a generic Document Workspace site, and by clicking on
Add new document, you can upload any document on which you plan to collaborate. (See Figure 16-5.)
Figure 16-5
F16XR05
Generic Document Workspace site
A Document Workspace site includes many of the same Web Parts included
with sites based on the Team Site template, such as:
■
Announcements
■
Contacts
■
Events
■
General Discussion
■
Links
■
Members
■
Shared Documents
■
Tasks
Creating a Private Document Workspace Site
An alternate method is to create a private Document Workspace site for a document
already published in a document library. (See Figure 16-6.) To do this, follow these
steps:
1. In a Web browser, go to the document library where the document is stored.
2. Point to the name of the document, and click the Edit arrow that appears.
Chapter 16: Windows SharePoint Services Site Administration
411
3. Click Create Document Workspace.
Figure 16-6
F16XR06
Creating a Document Workspace site
When you create a Document Workspace site that is based on a document in
a document library, the Document Workspace site carries the same name as the
document on which it is based. (See Figure 16-7.) The document is then stored in a
separate document library in the new Document Workspace site. This document can
be published back to its source location, in the original document library, from the
Document Workspace site. To publish your document back to the source, all
you need to do is click the drop-down arrow to the right of the document and select
the Publish To Source Location menu item. The Source Location is the originating
document (and document library) from which the document workspace was
created.
Figure 16-7
F16XR07
Document Workspace site based on a single document
412
Part V: Administration of Windows SharePoint Services
Note The ability to publish a document back to its original location is available only in a Document Workspace site created from a document that is
already stored in a document library. This feature is not available in Document Workspace sites created by using the Create page on a Windows
SharePoint Services site. This is because when a workspace is created and
then a document is added to the workspace, there is no source location to
which to publish the document.
Meeting Workspace Sites
When you create your websites, you can base them on one of the following five
Meeting Workspace site templates:
■
Basic Meeting Workspace
■
Blank Meeting Workspace
■
Decision Meeting Workspace
■
Social Meeting Workspace
■
Multipage Meeting Workspace
These templates are designed to optimize planning, posting, and working together
on meeting materials, as well as following up after a meeting or series of meetings.
Basic Meeting Workspace
This template includes all the basics to plan, organize, and track your meeting. The
template contains the following lists and their associated Web Parts: Objectives,
Attendees, and Agenda. (See Figure 16-8.)
Figure 16-8
F16XR08
Basic Meeting Workspace site
Chapter 16: Windows SharePoint Services Site Administration
413
Blank Meeting Workspace
This template creates a blank Meeting Workspace site for you to customize based on
your requirements. (See Figure 16-9.)
Figure 16-9
F16XR09
Blank Meeting Workspace site
Decision Meeting Workspace
This template includes features for reviewing documents and recording decisions
reached at the meeting. The template contains the following lists, library, and their
associated Web Parts: Objectives, Attendees, Agenda, Document Library, Tasks, and
Decisions. (See Figure 16-10.)
Figure 16-10
F16XR10
Decision Meeting Workspace site
414
Part V: Administration of Windows SharePoint Services
Social Meeting Workspace
This template helps you plan social occasions. It features a discussion board and a
picture library to post pictures of the event. The template contains the following
lists, library, and their associated Web Parts: Attendees, Directions, Image/Logo,
Things To Bring, Discussions, and Picture Library. (See Figure 16-11.)
Figure 16-11
F16XR11
Social Meeting Workspace site
Multipage Meeting Workspace
The Multipage Meeting Workspace site template includes all the basics to plan, organize, and track your meeting with multiple pages. This Meeting Workspace site contains the following lists and their associated Web Parts: Objectives, Attendees, and
Agenda. It also contains two blank pages for you to customize based on your
requirements. (See Figure 16-12.)
Figure 16-12
F16XR12
Multipage Meeting Workspace site
Chapter 16: Windows SharePoint Services Site Administration
415
Customizing, Saving, and Using Templates
Although you cannot open any of the templates and edit them, you can change the
workspace that is created from one of these templates. Basic customization can be
done from within the browser by using links from the Home, Create, and Site Settings pages of the website. From the browser, you can perform basic customizations
such as the following:
■
Add a list.
■
Change the layout of the home page.
■
Change the picture on the home page.
■
Add a Web Part to a Web Part Page.
■
Change a site’s display name (not the URL).
■
Apply a theme.
The Windows SharePoint Services Help files contain more information about
customizing websites from within the browser.
Once you have customized the workspace site, you can save it as a site template so that other users in the site collection can create similar sites later. Saving a
site template you have customized to your specifications qualifies as a best practice
that makes it easy to have a consistent look and feel across your sites.
To create a site template based on a website, you must be a member of the
Administrators site group for the current website. To add the new site template to
the Site Collection gallery, you must have the Add Item right for the Site Template
gallery, which is included by default in the Web Designer and Administrator site
groups for the top-level website in a site collection. Administrators of a site collection can also import a site template created by another user or software vendor, and
they can add the new template to the available site templates in the site collection.
You must go to the Site Administration page for the top-level website in a site collection to manage the Site Template gallery.
When a user creates a site template, it is automatically added to the Site Template gallery for the site collection.
To add a template to the Site Template gallery
1. On the top-level website, click Site Settings.
2. Under Administration, click Go to Site Administration.
3. Under Site Collection Galleries, click Manage site template gallery.
4. On the Site Template Gallery page, click Upload Template.
416
Part V: Administration of Windows SharePoint Services
5. In the Name box, type the path to the template, or click Browse.
You can upload multiple templates by clicking Upload Multiple Files.
6. Click Save and Close.
To delete a template in the Site Template gallery
1. On the top-level website, click Site Settings.
2. Under Administration, click Go to Site Administration.
3. Under Site Collection Galleries, click Manage site template gallery.
4. On the Site Template Gallery page, click the Edit icon next to the template
name.
5. On the Site Template Gallery: <Name> page, click Delete.
Site templates do not include the following items:
■
Security settings, such as a list of users or groups with permissions to the site
from which the template was created
■
Personalizations to Web Part Pages
■
Web discussions from the original site
■
Alerts from the original site
■
Web Part assemblies that were added to the original site
To create a site template
1. On the site, click Site Settings.
2. Under Administration, click Go to Site Administration.
3. Under Management and Statistics, click Save site as template.
4. In the File name box, type the file name to use for the site template file.
5. In the Template title box, type the title you want to use for the template in the
Site Template gallery.
6. In the Template description box, type a description for the site template.
7. If you want to include the existing site content, select the Include content
check box.
8. Click OK. (See Figure 16-13 and Figure 16-14.)
Chapter 16: Windows SharePoint Services Site Administration
417
F16XR13
Figure 16-13
Creating a new site template
Figure 16-14
Saving a site as a template
F16XR14
Once you have saved the template, it automatically will be a part of the Site
Template gallery and available to the site collection. (See Figure 16-15.)
The next time you create a site that is part of the collection under the site
where you saved the template, this new template will be an available option. (See
Figure 16-16.)
418
Part V: Administration of Windows SharePoint Services
F16XR15
Figure 16-15
Site Template gallery
Figure 16-16
Template selection
F16XR16
Selecting a Customized Template from the Command Line
Administrators can also create sites based on the site templates available in the
Server Template gallery from the command line by using stsadm.exe. To create a site
based on a template in the Central Template gallery, the administrator must use the
createsite (to create a top-level website) or createweb (to create a subsite) operations on the command line, and specify the template name as _GLOBAL_#number,
where number refers to the template ID. For example, if you have a site template in
the Central Template gallery with the ID 2, you could use the following syntax to
create a site based on that template:
Stsadm.exe –o createsite –url <url> -ownerlogin <DOMAIN\username> -owneremail
<[email protected]> –sitetemplate _GLOBAL_#2
Chapter 16: Windows SharePoint Services Site Administration
419
Note To find the template ID for a global template, you can use the
enumtemplates operation. The enumtemplates operation with the
Stsadm.exe command lists the templates currently in the Central Template
gallery.
Site Creation Process
Depending on the amount of customization and control you want to allow your
users, you can let them create either top-level websites or subsites. The Self-Service
Site Creation feature gives users the ability to create top-level websites on their own.
For more information on the Self-Service Site Creation feature of SharePoint Portal
Server 2003, see Chapter 15, “Configuring Windows SharePoint Services.”
Users can also create subsites of any site for which they have the Create Sites
And Workspaces right. The Create Sites And Workspaces right is included in the
Administrator site group by default, so any member of the Administrator site group
for a site can create a subsite of that site. You can assign this right to other site
groups by using the Manage Site And Workspace Creation page.
If you want to control top-level website creation yourself, you can disable SelfService Site Creation and create top-level websites (site collections) on your users’
behalf from SharePoint Central Administration. To create a top-level website outside
of Self-Service Site Creation, you must be an administrator of the local machine on
which the site will reside or a member of the SharePoint administrators group.
Note When you are running a server farm with multiple host names or are
in Active Directory account mode, you cannot create a top-level website
from SharePoint Central Administration. To perform this action in Active
Directory account mode, you must use the command line or object model.
To create a top-level website from SharePoint Central Administration
1. Click Start, point to All Programs, point to Administrative Tools, and then
click SharePoint Central Administration.
2. Under Virtual Server Configuration, click Create a top-level Web site.
3. On the Virtual Server List page, click the virtual server under which you want
to create the top-level website.
420
Part V: Administration of Windows SharePoint Services
4. To create a site under a predefined URL path for the virtual server, on the Create Top-Level Web Site page, select Create site under this URL; in the Site
name box, type the name for the top-level website; and then in the URL path
box, select the path to use.
The name and URL path are combined with the server name to create the full
URL to the site. For example, on http://servername, if you create a top-level
website at the /sites URL path and use Site001 as the name, the full path to the
new top-level website is http://servername/sites/site001.
5. To create a site at a predefined URL path, select Create site at this URL, and
then in the URL path box, select the URL to use for the top-level website.
The site is created at the top level of the URL path you select. For example,
on http://servername, if you select /portal as the path, the site is created at
http://servername/portal.
6. In the Site Collection Owner section, type the account name (in the form
DOMAIN\username) and e-mail address (in the form [email protected])
for the user who will be the site owner and administrator.
7. If you want to identify a user as the secondary owner of the new top-level website (recommended), in the Secondary Owner section, type the account name
and e-mail address for a secondary owner and administrator of the new site.
8. If you are using quotas, in the Quota Template section, select a quota template to use.
9. In the Site Language section, select the language to use for the top-level website.
10. Click OK.
The site owner can select a template for the site when first browsing to the
URL, or you can browse to the URL on the confirmation page and select one yourself. You must alert the site owner and secondary owner when you have created the
site with the URL. They are not notified automatically when you create a site.
Creating Subsites
You can create a subsite of a current site by using the Manage Sites And Workspaces page.
1. On a site, click Site Settings.
2. Under Administration, click Manage sites and workspaces.
3. On the Manage Sites And Workspaces page, click Create.
4. On the New SharePoint Site page, in the Title and Description section, type
the title and description for the new subsite.
5. In the URL name box, type the URL for your subsite.
Chapter 16: Windows SharePoint Services Site Administration
421
6. In the User Permissions section, select either Use same permissions as
parent site or Use unique permissions.
Select Use same permissions as parent site if you want to share users with
the parent site, or select Use unique permissions if you want to maintain a
separate list of users for your subsite.
7. In the Language section, select the language to use.
8. Click Create.
9. On the Template Selection page, select a template to use, and then click OK.
Creating Sites and Subsites from the Command Line
If you are an administrator of the server computer, you can also create sites and subsites by using the Stsadm.exe command-line tool. To create a top-level website, use
the createsite operation. To create a subsite, use the createweb operation.
Tip You can also use the createsiteinnewdb operation to create a top-level
website and a new content database at the same time.
The createsite operation takes the following required parameters: url, ownerlogin, and owneremail. It also takes the following optional parameters: ownername,
lcid, sitetemplate, title, description, and quota. For example, to create a top-level
website called site1 on http://server_name/sites, you would use syntax similar to the
following:
Stsadm.exe -o createsite -url http://server_name/sites/site1 -ownerlogin
<DOMAIN\user> -owneremail <[email protected]> -ownername <display name>
The createweb operation requires the url parameter and takes the following
optional parameters: lcid, sitetemplate, title, description, convert (used to convert an
existing folder to a website), and unique (used to specify unique permissions for the
subsite). To create a subsite called subsite1 under the site you just created, you
would use syntax similar to the following:
Stsadm.exe –o createweb –url http://server_name/sites/site1/subsite1
Allowing Access to Websites
One of an administrator’s main concerns will be granting the appropriate access to
the appropriate users for each site and site collection. This topic explains the rights
and site groups you can assign to users by using operations in Stsadm.exe and by
using HTML Administration. We will discuss the concepts and then the tools provided by Microsoft to ease the burden of this administrative task.
422
Part V: Administration of Windows SharePoint Services
Microsoft Windows SharePoint Services provides the ability to control site
access by all the following means:
■
Site groups. Site groups let you specify which of your users can perform
specific actions in your site. For example, a user who is a member of the Contributor site group can add content to Windows SharePoint Services lists, such
as the tasks list, or a document library.
■
Anonymous access control. You can enable anonymous access to allow
users to contribute anonymously to lists and surveys or to view pages anonymously. Most Internet websites allow anonymous viewing of the site but ask
for authentication when someone wants to edit the site or buy an item on a
shopping site.
Note You can also grant access to “all authenticated users” to allow all
members of your domain as well as trusted domains to access a website,
without having to enable anonymous access.
■
Per-list permissions. You can manage permissions more finely by setting
unique permissions on a per-list basis. For example, if you have a document
library containing sensitive financial data for the next fiscal year, you can
restrict access to that list so that only the appropriate users can view it. Per-list
permissions override site-wide permissions for the lists.
■
Subsite permissions. Subsites can either use the same permissions as the
parent website (inheriting both the site groups and users available on the
parent website) or use unique permissions different from those of the parent
site (so that you can create your own user accounts and add them to site
groups).
User Rights Available for Windows SharePoint Services
Windows SharePoint Services includes 21 rights. One of those 21 rights, Self-Service
Site Creation, is available only on a top-level website and is not available for use on
subsites. The 21 rights are used to create the five default user site groups. You can
change which rights are included in a particular site group (except for the Guest and
Administrator site groups) or create a new site group to contain a specific list of
rights. Table 16-1 is a list of rights and the groups those rights are granted to by
default.
Chapter 16: Windows SharePoint Services Site Administration
423
Table 16-1 User Rights for Sites
Right Name
Rights Granted
Default Groups
Add and Customize
Pages
Grants permission to create ASP.NET,
ASP, and HTML pages for a website
Web Designer, Administrator
Add Items
Grants permission to add items to
lists or documents to document
libraries
Contributor, Web Designer,
Administrator
Add/Remove
Personal Web Parts
Grants permission to add and
remove Web Parts to personalize
Web Part Pages
Contributor, Web Designer,
Administrator
Apply Style Sheets
Grants permission to apply a style
sheet to the entire website
Web Designer, Administrator
Apply Themes and
Borders
Grants permission to apply a theme
or border to an entire website
Web Designer, Administrator
Browse Directories
Grants permission to browse the
directory structure of a website
Contributor, Web Designer,
Administrator
Cancel Check-out
Grants permission to cancel the
check-out action performed by
another user
Web Designer, Administrator
Create Cross-Site
Groups
Grants permission to create or
delete cross-site groups, or to change
membership of a cross-site group
Contributor, Web Designer,
Administrator
Create Sites and
Workspaces
Grants permission to create a new
subsite or workspace, such as a
Document Workspace or Meeting
Workspace
Reader, Contributor, Web
Designer, Administrator
Delete Items
Grants permission to delete list items
and documents from the website
Contributor, Web Designer,
Administrator
Edit Items
Grants permission to edit existing list
items and documents in the website
Contributor, Web Designer,
Administrator
Manage Lists
Grants permission to create, edit, or
delete lists and change their settings
Web Designer, Administrator
Manage List
Permissions
Grants permission to change permissions for a list or document library
Administrator
Manage Personal
Views
Grants permission to create, edit,
or delete personal views on lists
Contributor, Web Designer,
Administrator Contributor,
Web Designer, Administrator
Manage Site Groups
Grants permission to create,
delete, and edit site groups, both
by changing the rights assigned to
the site group and by changing
which users are members of the
site group
Administrator
424
Part V: Administration of Windows SharePoint Services
Table 16-1
User Rights for Sites
(continued)
Right Name
Rights Granted
Default Groups
Manage Web Site
Grants permission to perform
administration tasks for a particular
site or subsite
Administrator
Update Personal
Web Parts
Grants permission to update
Web Parts to display personalized
information
Contributor, Web Designer,
Administrator
Use Self-Service
Site Creation
Grants permission to use the
Self-Service Site Creation tool to
create a top-level website
Reader, Contributor, Web
Designer, Administrator
View Items
Grants permission to view items in
Reader, Contributor, Web
lists, documents in document libraries, Designer, Administrator
and Web discussion comments
View Pages
Grants permission to browse
pages in the website
Reader, Contributor, Web
Designer, Administrator
View Usage Data
Grants permission to view reports
on website usage
Administrator
Defining Site Groups
Windows SharePoint Services uses site groups to manage site-wide security. Each
user is a member of at least one site group. Each site group possesses corresponding
rights. Rights are actions that users can perform, such as Manage Lists. With Windows SharePoint Services, you can use the following default site groups: Guest,
Reader, Contributor, Web Designer, and Administrator. In addition, Windows SharePoint Services allows you to edit the rights assigned to a site group, create a new site
group, or delete an unused site group. You manage site groups in Windows SharePoint Services with either HTML Administration pages or the command-line administration tool. You cannot change the rights assigned to the Guest and Administrator
site groups, and you cannot assign users directly to the Guest site group.
Note You can add user accounts to a website without assigning them to a
site group. For example, if you are creating new user accounts for the website, you can create the user accounts and then assign the users to site
groups later. You can also remove a member from all site groups. However,
a user who is not assigned to a site group has no access to the website.
Windows SharePoint Services includes the following site groups by default:
■
Guest. The Guest group has limited rights to view pages and specific page
elements. This site group is used for giving users access to a particular page or
Chapter 16: Windows SharePoint Services Site Administration
425
list without granting them rights to view the entire site. Users cannot be explicitly added to the Guest site group; rather, users who are given access to lists or
document libraries by way of per-list permissions are automatically added to
the Guest site group. The Guest site group cannot be customized or deleted.
■
Reader. The Reader group has rights to view items, view pages, and create
a top-level website using Self-Service Site Creation. Readers can only read a
site; they cannot add content. Note that when a reader creates a site using SelfService Site Creation, she becomes the site owner and a member of the Administrator site group for the new site. This does not affect the user’s site group
membership for any other site.
■
Contributor. The Contributor group has Reader rights, plus rights to add,
edit, and delete items; browse directories; manage personal views; add,
remove, or update personal Web Parts; and create cross-site groups. Contributors cannot create new lists or document libraries, but they can add content to
existing lists and document libraries.
■
Web Designer. The Web Designer group has Contributor rights, plus rights
to cancel check-out, manage lists, add and customize pages, define and apply
themes and borders, and apply style sheets. Web Designers can modify the
structure of the site and create new lists or document libraries.
■
Administrator.
The Administrator group has all rights from other site
groups, plus rights to manage site groups, manage list permissions, create sites
and workspaces, and view usage analysis data. The Administrator site group
cannot be customized or deleted, and there must always be at least one member
of the Administrator site group. Members of the Administrator site group always
have access to, or can grant themselves access to, any item in the website.
Note The owner and secondary owner of a site collection are members of
the Administrator site group for their site, but they are also identified separately in the configuration database as site collection owners. This owner
flag can be changed only by using the Manage Site Collection Owners page
in Central Administration or by using the site owner operation with
Stsadm.exe. If you remove an owner from the Administrator site group for
the site, the owner retains the owner flag in the database and can still perform website administrative tasks.
These site groups are defined per website. Users assigned to the Administrator
site group are administrators only for a particular website. To perform any administrative tasks that affect settings for all websites and virtual servers on the server computer, a user must be an administrator for the server computer (also known as a
426
Part V: Administration of Windows SharePoint Services
local machine administrator) or a member of the SharePoint administrators group,
rather than a member of a site’s Administrator site group.
Customizing Rights for Site Groups
You can create a new site group or customize an existing site group (except for the
Guest and Administrator site groups, which cannot be customized) to include only the
rights you want. For example, if you want only the Web Designers to be able to edit
lists on the site, you can remove the Edit Items right from the Contributor site group.
Some rights depend on other rights. You must be able to view items before you
can edit items. If a right is removed from a site group, any rights dependent on that
right are also deleted. For example, when the View Items right is deleted, the Add
Items, Edit Items, and Delete Items rights are also deleted. In the same way, if you
add a right that requires another right, the required right is also added. So, if you
grant the Edit Items right to a user, the View Items right is granted automatically.
Using HTML Administration Pages to Manage Site Groups
You can manage site groups from the Site Administration page for your Web site. To
manage site groups, follow the Manage Site Groups link on the Site Administration
page to the Manage Site Groups page. (See Figure 16-17.) On this page, you can
view a list of site groups, change which rights are included in a site group, add a
new site group, or delete a site group.
Figure 16-17
F16XR17
Manage Site Groups page
To view a list of site groups
1. On the Site Settings page for your website, under Administration, click Go to
Site Administration.
2. On the Site Administration page, under Users and Permissions, click Manage site groups.
Chapter 16: Windows SharePoint Services Site Administration
427
3. The site groups available for the website are displayed on the Manage Site
Groups page. (See Figure 16-17.)
To add a new site group
1. On the Manage Site Groups page, click Add a Site Group.
2. In the Site Group Name and Description area, type the name and description for your new site group.
In the Rights area, select the rights you want to include in the new site group.
3. Click Create Site Group.
Figure 16-18 illustrates this process.
Figure 16-18
F16XR18
Add a site group
You can create a new site group based on an existing site group, and even
copy the members of the existing site group into your new site group.
To copy an existing site group
1. On the Manage Site Groups page, click the site group you want to copy.
2. On the Members Of “Site Group Name” page, click Edit Site Group
Permissions.
3. On the Edit Site Group “Site Group Name” page, click Copy Site Group.
4. On the Copy The Site Group “Site Group Name” page, in the Site Group
Name and Description area, type the name and description for your new site
group.
5. If you want to copy the users from the existing site group into your new site
group, select the Copy users from “Site Group Name” check box.
428
Part V: Administration of Windows SharePoint Services
6. In the Rights area, select any additional rights that you want the site group to
contain, and clear any rights that you do not want the site group to contain.
7. Click Create Site Group.
You can also edit an existing site group to change the rights assigned to that
site group.
To edit an existing site group
1. On the Manage Site Groups page, click the site group you want to change.
2. On the Members Of “Site Group Name” page, click Edit Site Group
Permissions.
3. On the Edit Site Group “Site Group Name” page, select the rights you want to
include and clear any rights that you do not want.
4. Click OK.
If you find that a site group is not used, you can delete the site group.
To delete an existing site group
1. On the Manage Site Groups page, select the check box next to the site group
you want to delete.
2. Click Delete Selected Site groups.
Using the Command Line to View Site Groups
You can view the list of site groups from the command line in Windows SharePoint
Services by using the enumroles operation. This operation takes the -url parameter,
and then simply lists the names of the site groups for that URL, so you can use the
correct site group name when assigning permissions to users. For example, to view
the list of site groups for a site at http://myserver/site1, you would type the following
command:
Stsadm –o enumroles –url http://myserver/site1
Assigning Per-List Permissions
Windows SharePoint Services provides the ability to control permissions on a per-list
basis. If you have sensitive information stored in a list and you do not want to
expose the information to all members of your site, you can set permissions for just
that list to control which users can view, edit, or add items to that list. You can grant
permissions to a list or document library to individual users, to groups of users, or
to a site group. Per-list permissions work for any list or document library in a website based on Windows SharePoint Services (for example, Announcements, Tasks,
Shared Documents, and so on).
Chapter 16: Windows SharePoint Services Site Administration
429
List permissions can be changed by any user who has the Manage List Permissions right (by default, included in the Administrator site group) or Full Control permissions for that list. By default, all members of a website (all users assigned to a site
group, except for the Guest site group) have access to all lists and document libraries on that website. Each site group has a predefined level of permissions for all lists
and document libraries. The default list permissions are as follows:
■
View items (given to the Reader site group by default)
■
View, insert, edit, delete items (given to the Contributor site group by default)
■
View, insert, edit, delete items; change list settings (given to the Web Designer
site group by default)
■
View, insert, edit, delete items; change list settings; change list security
In addition, you can set advanced permissions, which allow you to grant any
of the following rights for a user or site group:
■
Manage Lists (given to the Web Designer site group by default)
■
Manage List Permissions
■
Manage Personal Views (given to the Contributor site group by default)
■
Cancel Check-Out (applies only to document libraries; given to the Web
Designer site group by default)
■
Add List Items, Edit List Items, and Delete List Items (given to the Contributor
site group by default)
■
View List Items (given to the Reader site group by default)
Note Members of the Administrator site group always have the highest
level of permissions for all lists and document libraries. You cannot change
list or document library permissions for the Administrator site group. Also,
any site group that has the View Lists Item right (such as Reader) can continue to see the list name, description, number of items, and time when the
list was last modified, even though they cannot view the list contents directly.
To control permissions for a list, go to the list itself or to the Customize “Listname”
page for the list.
430
Part V: Administration of Windows SharePoint Services
View Permissions for a List
Navigate to the list, and then in the left pane, click Modify Settings And Columns.
(See Figure 16-19.)
Figure 16-19
F16XR19
Viewing permissions for a list
On the Customize “Listname” page, in the General Settings section, click
Change Permissions For This <list/document library>. (See Figure 16-20.)
Figure 16-20
F16XR20
Changing permissions on a list
The Change Permissions: “Listname” page displays the users and any groups
that have access to the list, and it shows the permissions level each user or group is
assigned. You can change the list permissions for all members of a particular site
group by modifying that site group’s permissions.
Chapter 16: Windows SharePoint Services Site Administration
431
To change list permissions for a particular site group
1. Navigate to the list, and then in the left pane, click Modify settings and
columns.
2. On the Customize “Listname” page, in the General Settings section, click
Change permissions for this <list/document library>.
3. Select the check box next to the site group you want to change. (See Figure 16-21.)
F16XR21
Figure 16-21
Changing permissions given to a site group
For example, click the check box next to Web Designer to change the permissions for all members of the Web Designer site group.
4. Click Edit Permissions of Selected Users.
5. In the Choose Permissions section, select the level of permissions to allow
and click OK.
You can also grant permissions to individual users or to user groups instead of
to all members of a site group. Remember that when you grant a user or group permissions to a specific list in your site, they are added to the Guest site group if they
are not already members of the site. Note that a member of the Guest site group cannot navigate to a page within the site unless you give them the exact page URL.
To assign list permissions to a specific user or group
1. Navigate to the list, and then in the left pane, click Modify settings and columns.
2. On the Customize “Listname” page, in the General Settings section, click
Change permissions for this <list/document library>.
3. On the list toolbar, click Add Users.
4. In the Step 1: Choose Users section, in the Users area, in the text box, type
the network domain name or e-mail address for the user or group you want to
assign permissions.
432
Part V: Administration of Windows SharePoint Services
5. In the Step 2: Choose Permissions section, under Permissions, select the
level of permissions for the user or group, and then click Next.
6. In the Step 3: Confirm Users section, verify that the e-mail address, user
name, and display name for the user or group are correct.
7. If you want to notify the user or group of their permissions with an e-mail
message, in the Step 4: Send E-Mail section, select the Send the following
e-mail to let these users know they’ve been added check box, and fill in
the text you want to send.
8. Click Finish.
If you want to restrict your list to a specific set of users, you must both grant
access to the individual users and remove access from other site members.
To remove list permissions for a user, group, or site group
1. Navigate to the list, and then in the left pane, click Modify settings and
columns.
2. On the Customize “Listname” page, in the General Settings section, click
Change permissions for this <list/document library>.
3. Select the check box next to the site group, user, or group you want to remove
permissions for, and then click Remove Selected Users.
If you no longer want to use unique permissions for a particular list, you can
reset the permissions to use the website’s general permissions.
To reset permissions to the default state
1. Navigate to the list, and then in the left pane, click Modify settings and
columns.
2. On the Customize “Listname” page, in the General Settings section, click
Change permissions for this <list/document library>.
3. Click Inherit permissions from the parent Web site.
4. Click OK to change to inherited permissions.
Note The Inherit Permissions link does not appear unless the list permissions have already been customized.
Chapter 16: Windows SharePoint Services Site Administration
433
Controlling Access for All Authenticated Users
If you want all authenticated users of your intranet to be able to access your website,
rather than adding each user individually or in groups, you can configure your site
to allow all users on your network rights to use the site. You can also specify which
site group (either Reader or Contributor) to assign to all authenticated users.
To allow all authenticated users rights to a top-level website
1. On your site, click Site Settings.
2. Under Administration, click Go to Site Administration.
3. On the Site Administration page, under Users and Permissions, click Manage anonymous access.
4. In the All Authenticated Users section, under Allow all authenticated users
to access site, select Yes.
5. Under Assign these users to the following site group, select a site group.
6. Click OK.
Controlling Anonymous Access to a Website
If you want users to be able to contribute to your site anonymously, you can configure your site to allow anonymous access. Anonymous access is used to allow
users to browse sites without authenticating (a standard Internet scenario),
respond anonymously to surveys, or even contribute to a list or document library
anonymously.
Anonymous access relies on the anonymous user account on your Web server.
This account is created and maintained by your Web server (Internet Information
Services [IIS]), not by Windows SharePoint Services. On IIS, the anonymous user
account is usually IUSR_ComputerName. When you enable anonymous access in
Windows SharePoint Services, you are enabling that user account for your website.
Enabling Anonymous Access
Anonymous access is disabled by default and is controlled at the site level. If you
want to allow anonymous access (such as for an Internet site, where you want visitors to be able to browse without authenticating), you must enable anonymous
access by assigning rights to the anonymous user. To enable anonymous access, you
must first be sure that IIS is configured to allow anonymous access, and then on the
Site Settings pages for your website, you can enable anonymous access.
434
Part V: Administration of Windows SharePoint Services
To allow anonymous access for a virtual server in Internet
Information Services
1. Click Start, point to All Programs, point to Administrative Tools, and then
click Internet Information Services (IIS) Manager.
2. Right-click the virtual server you want to enable anonymous access for, and
then click Properties.
3. Click the Directory Security tab.
4. In the Authentication and access control section, click Edit.
The Authentication Methods dialog box appears.
5. Select the Enable anonymous access check box. (See Figure 16-22.)
6. Click OK to close the Authentication Methods dialog box.
7. Click OK to close the Properties dialog box.
F16XR22
Figure 16-22
Enabling anonymous access
You might need to restart IIS for this change to take effect. After anonymous
access has been turned on for the virtual server in IIS, you can enable anonymous
access for a specific top-level website.
To enable anonymous access for a top-level website
1. On your site, click Site Settings.
2. Under Administration, click Go to Site Administration.
3. On the Site Administration page, under Users and Permissions, click Manage
anonymous access.
Chapter 16: Windows SharePoint Services Site Administration
435
4. In the Anonymous Access section (shown in Figure 16-23), select a level of
access to allow:
■
Entire Web site
■
Lists and libraries
■
Nothing
5. Click OK.
F16XR23
Figure 16-23
Changing anonymous access settings: team website
Per-List Permissions and Anonymous Access
You can control anonymous access for your entire site by using the Manage Anonymous Access page, or you can control anonymous access for specific lists by using
the per-list permissions feature. If anonymous access is disabled for your site, it cannot be enabled for a particular list in the site.
To enable anonymous access for a list
Verify that anonymous access is enabled for your site by performing the following
steps:
1. Navigate to the list, and then in the left pane, click Modify settings and
columns.
2. In the General Settings section, click Change permissions for this <list/
document library>.
3. On the left of the screen under Actions, click on Change anonymous
access.
4. Select the level of permissions to give anonymous users, and then click OK.
436
Part V: Administration of Windows SharePoint Services
Creating Unique Permissions for a Subsite
When you create a subsite, you can choose whether to inherit the permissions from
the parent website or to create unique permissions for your subsite. (See Figure 16-24.)
Depending on your choice, you get one of the following results:
■
If you choose unique permissions, the default site groups are created (Guest,
Reader, Contributor, Web Designer) but are not populated. The Administrator
site group is also created, and the subsite creator is assigned to this site group.
You can add users to the subsite and assign them to site groups, and they will
have permissions only on your subsite, not on the parent website.
■
If you choose to inherit permissions, all the security from the parent website is
used for the subsite, with the exception of per-list permissions. If you add a
user to a list, the user is added to the parent website.
Figure 16-24
F16XR24
Subsite permissions
Switching to a Different Permissions Model
If you set up your subsite with unique permissions but find that you need to share
permissions with your parent website instead, you can switch to inherited permissions. There are some drawbacks to making this switch, however, such as:
■
Switching from unique to inherited permissions is not reversible. The users and
site groups from your subsite are deleted when you switch to inherited, and
your subsite reverts to the permissions set for the parent website.
■
Items that have per-list permissions set lose those permissions. All lists revert to
the site-wide permissions.
You can also switch from using inherited permissions to using unique permissions. In this case, the transition is simpler. The current permissions are duplicated
when you switch, and the link to the parent website’s permissions structure is broken.
Chapter 16: Windows SharePoint Services Site Administration
437
From that point on, any changes you make to the permissions affect only the subsite. When you switch from inherited to unique permissions, per-list permission settings remain intact.
Note Switching between permissions models can create some strange
scenarios. For example, any user who has the Create Subsites right can create
a subsite. By default, this right is included only in the Administrator site
group, but if you assign it to another site group, members of that group can
create subsites with unique permissions and become administrators of the
new subsites. If such a user then chooses to switch to using the parent website’s permissions, the user will no longer be an administrator of the subsite.
You use the Site Settings page for your subsite to switch to a different permissions model.
To set unique permissions by using HTML Administration pages
1. On the subsite, click Site Settings.
2. Under Administration, click Go to Site Administration.
3. On the Site Administration page, under Users and Permissions, click Manage permission inheritance.
4. In the Permissions section, select Use unique permissions.
5. Click OK.
If you want to return to using the same permissions as the parent website, you
can also change back by using HTML Administration pages.
Managing Site Creation Rights
By default, when Self-Service Site Creation is enabled, all members of the Reader,
Contributor, Web Designer, and Administrator site groups have the Use Self-Service
Site Creation right. They can use this right to create a top-level website on a virtual
server from the Create Web Site page. Another right, the Create Subsites right, is
available to members of the Administrator site group by default. This right allows the
user to create a subsite or a workspace site from the Create page or the Manage Sites
And Workspaces page.
You control which users have the Use Self-Service Site Creation right by changing the rights in a site group. You can control which users have the ability to create
sites and workspace sites by changing which site groups have the Create Subsites
right, or by using the Enable Site And Workspace Creation page in Site Settings. You
must be a member of the Administrator site group for a site to control these rights.
438
Part V: Administration of Windows SharePoint Services
For detailed instructions on how to implement Self-Service Site Creation, see
Chapter 15, “Configuring Windows SharePoint Services.”
Security and User Rights
User rights grant users the ability to perform certain actions on a website and restrict
other users from performing those actions. Some rights do not completely restrict certain actions. The Apply Themes And Borders and Apply Style Sheets rights allow users
to make changes to an entire website. Any user with the Add And Customize Pages
right, however, can perform the same changes on a page-by-page basis in the actual
HTML code. Be aware that if you give a user the Add And Customize Pages right (by
assigning them to a site group that contains the right), you are also giving them the ability to change the theme, border, and style sheets for individual pages in your website.
When you assign rights to site groups, be sure to assign the appropriate rights,
and do not unintentionally allow members of the site group to perform more actions
than you want on your website. Conversely, be sure that members of the site group
are not unintentionally restricted from performing the actions they need to perform.
Statistics
If you want to know what kind of impact your website has, you need to track how
many users visit your site, the type and number of hits your site receives, and other
site-usage information. Microsoft Windows SharePoint Services includes features
that analyze the usage of your site. Summary and detailed usage reports supply
information such as the following:
■
Number of page hits for each individual page
■
Number of unique users
■
Browser and operating system information
■
Referring domains and URLs
Analyzing Website Usage
Tracking usage information can be useful for identifying which content on your site
is heavily used (and therefore should be kept) and which content is not being
heavily used (and might be a candidate for archiving). In addition, it shows the sort
of information your visitors are most interested in so that you know where to invest
your future efforts. You can also keep track of how much storage space your site is
taking up and the level of activity your site is generating. This information is gathered as part of the quota tracking for sites.
The usage reports rely on usage log data gathered from the websites and
stored in the content databases for each virtual server. The log data is a summary
record of transactions on your website. When you view a usage report in Windows
SharePoint Services, the data is arranged into a list format. You must be a member
Chapter 16: Windows SharePoint Services Site Administration
439
of the administrator role (or have the View Usage Data right) for a site to view the
site usage statistics.
To configure usage analysis processing for a server
1. Click Start, point to All Programs, point to Administrative Tools, and then
click SharePoint Central Administration.
2. Under Component Configuration, click Configure usage analysis
processing.
3. In the Logging Settings section, select the Enable logging check box.
4. In the Log file location box, type the location to store the log file.
The default location for the log file is %Windir%\system32\LogFiles\STS.
5. In the Number of log files to create box, type a number from 1 to 30.
In general, you should use a number that is one to three times the number of
database servers in your server farm, with a maximum number of 30 log files.
However, note that more log files will increase the traffic load on the servers,
thereby potentially degrading performance. It is actually the traffic on the
server and sites that will dictate the size of the log files, so this is the main factor to consider when deciding how many log files to create.
6. In the Processing Settings section, select the Enable usage analysis processing check box.
7. Under Run processing between these times daily, specify the range of
times to start the usage analysis log processing. In the Start box, select the earliest time of day to begin running log processing. In the End box, select the latest time to begin running log processing.
8. Click OK. (See Figure 16-25.)
F16XR25
Figure 16-25
Configuring usage analysis processing
440
Part V: Administration of Windows SharePoint Services
You can view a Site Usage Report about a site from the Site Administration
page. (See Figure 16-26.)
Figure 16-26
F16XR26
Viewing site usage data
To view site usage report data
1. On the site you want to view data for, click Site Settings.
2. Under Administration, click Go to Site Administration.
3. Under Management and Statistics, click View site usage data.
You can view the quota settings for an entire site collection. Note that this feature is not available at the subsite level.
To view quota settings for a site collection
1. From the portal, click Site Settings.
2. Click Go to SharePoint Portal Server central administration.
3. Click Windows SharePoint Services in the left window pane.
4. Under Component Configuration, click on Manage quotas and locks.
5. Click Manage site collection quotas and locks.
6. Type the URL of the top-level website, and click View Data.
Two new fields will be revealed to you: Site Lock Information and Site Quota
Information.
To view usage data and quota information for a site collection
1. On the top-level website of the site collection, click Site Settings.
2. Under Administration, click Go to Site Administration.
3. Under Site Collection Administration, click View site collection usage
summary.
Chapter 16: Windows SharePoint Services Site Administration
441
This page will also show you the amount of disk space used by the content in
the site collection as well as the total number of users who have been added to the
site collection.
Managing Alerts
Because websites based on Microsoft Windows SharePoint Services are meant to
help groups of users work together, they tend to grow quickly and change often.
Keeping up with these changes can be difficult for users, especially if they aren’t
checking on the site every day. To help users stay in touch with changes on a site,
Windows SharePoint Services includes a feature called alerts, an e-mail notification
service. When documents, lists, or items in a list on a server running Windows
SharePoint Services are created, modified, or deleted, users who sign up for alerts
receive messages informing them that changes have been made.
Note Before alerts can work for a particular site, the e-mail server settings must be configured at the server or virtual-server level. In SharePoint
Team Services from Microsoft, alerts were called Web subscriptions, but the
functionality has not changed significantly.
Users can create alerts to track items within a site, such as:
■
Lists. Users are notified of changes to the list, such as when an item is added,
deleted, or changed in a list.
■
List items.
■
Document libraries. Users are notified of changes to the document library,
such as when a document is added, deleted, or changed in a document library
or when Web discussions are added, changed, deleted, or closed.
■
Documents. Users are notified of changes in a particular document or when
Web discussions are added, changed, deleted, or closed.
Users are notified of changes to a particular item in a list.
When a user creates an alert for one of these items, he can specify what types
of events will trigger an alert. Alerts can be generated whenever a document or list
item is added, updated, or deleted in a document library or list, or when a Web discussion on a document or list changes. Users can specify one of these events or
select all of them to be notified whenever anything changes on the list, list item,
document, or document library they want to track.
Users also have the ability to decide how often they want to receive alerts:
immediately, daily, or weekly. Immediate alerts are sent as individual e-mail
442
Part V: Administration of Windows SharePoint Services
messages, and daily or weekly alerts are combined into summary messages for the
entire website.
Users can change their alerts by using the My Alerts On This Site link on the
Site Settings page of their website. (See Figure 16-27.)
Figure 16-27
F16XR27
Setting up alerts with HTML Administration pages
Note A user must have the View Items right (included in the Contributor
and Reader site groups by default) to sign up for alerts.
To configure alerts at the virtual-server level
1. From the portal page, click Site Settings.
2. Under General Settings, click Go to SharePoint Portal Server central
administration.
3. Under Portal Site and Virtual Server Configuration, click Configure virtual server settings from the Virtual Server List page.
4. On the next screen, which is the Virtual Server List page, click the name of the
virtual server you want to configure.
5. Under Virtual Server Management, click Virtual server general settings.
6. Under Alerts, turn on the alerts for this virtual server and specify either unlimited or the maximum number of alerts that a user can create.
To configure e-mail settings at the virtual-server level
1. From the Portal site, click Site Settings.
2. Under General Settings, click Go to SharePoint Portal Server central
administration.
Chapter 16: Windows SharePoint Services Site Administration
443
3. In the left window pane, click Windows SharePoint Services.
4. Under Server Configuration, click Configure default e-mail server settings.
5. Specify the Outbound SMTP server, From e-mail address, and Reply-toe-mail address settings.
6. Click OK.
Customizing the Message Text for Alerts
For Windows SharePoint Services, you can customize the contents of the alert messages. Keep in mind that while you can alter the contents of the message, there is
still no mechanism for identifying and extracting exact text changes within a document or list item. You can, however, customize the text in the message and re-order,
add, and remove fields from the message.
Note You must be an administrator on the local server computer to edit
the XML templates for Windows SharePoint Services.
The message text for immediate, daily, and weekly alerts is based on content
in a series of XML templates on the server computer. To customize the message text,
you must edit the XML templates that contain the message text. The templates are
stored on the front-end Web server at \\Program Files\Common Files\Microsoft
Shared\Web Server Extensions\60\Template\LCID\XML, where LCID is the locale
ID. (See Figure 16-28.)
Figure 16-28
F16XR28
The message text XML template files
444
Part V: Administration of Windows SharePoint Services
Table 16-2 shows the parts of an e-mail alert for immediate notification of
changes to a list item and which part each XML file constructs.
Table 16-2
Immediate E-mail Notifications Constructed by XML Files
XML File
Displayed Content
NotifSiteHdr.xml
Alert result http://Server_Name/sites/Site_Name Site_Display_Name
NotifListHdr.xml
List_Display_Name Summary
NotifItem.xml
File_Name was modified by User_Name at 10/12/2003 8:01 P.M.
NotifSiteFtr.xml
Go to My Alerts to edit, delete, or view your alerts.
To create a custom message for an alert, make customizations to the appropriate XML file as indicated in Table 16-2.
Caution Editing any of the XML templates for Windows SharePoint Services can break the templates and, consequently, break the mechanism for
sending alerts. Be sure to edit only the message text in the template and
keep a backup copy of the original templates in case you need to revert to
the originals. For more information about customizing XML templates, see
the Windows SharePoint Services Software Development Kit.
You can edit the XML templates to include any of the tags shown in Table 16-3.
Table 16-3
Tags for Use in XML Message Text Files
Tag
Description
AlertFrequency
The time interval for sending an alert. Possible values include 0
(immediate), 1 (daily), or 2 (weekly).
EventType
The type of event. Possible values include 1 (item added), 2 (item
modified), 4 (item deleted), 16 (discussion added), 32 (discussion
modified), 64 (discussion deleted), 128 (discussion closed), and
256 (discussion activated).
ItemName
The title of the item.
ItemUrl
The absolute URL for the item.
ListName
The name of the list.
ListUrl
The absolute URL for the list.
ModifiedBy
The display name of the user who modified the item.
MySubsUrl
The absolute URL for the My Alerts On This Site page in Site
Settings.
Chapter 16: Windows SharePoint Services Site Administration
Table 16-3
Tags for Use in XML Message Text Files
445
(continued)
Tag
Description
SiteLanguage
The locale identifier (LCID) for the language used on the site.
For example, 1033 is the LCID for U.S. English.
SiteName
The title of the site.
SiteUrl
The absolute URL for the site.
TimeLastModified
The time at which the item was last modified.
You can use any XML editing tool, such as Notepad, to edit the templates.
Keep in mind that any changes you make to this message text are used for all alert
messages sent to all users of your server. If you are in a server farm environment,
you must edit the templates on each server in the server farm or copy the edited
templates to each server in the server farm. You must be an administrator of the
local server computer to edit the XML templates for Windows SharePoint Services.
Note In the XML templates, you use numerical values instead of text to
specify frequency and event types. So, if you want to set the AlertFrequency to
weekly, you would use the value 2 in the template rather than typing “weekly”.
See the description column in Table 16-3 for the tag named AlertFrequency.
Configuring and Managing Alerts
You can view alerts for a website or subsite and delete alerts that are no longer
needed. If you are a server administrator or a member of the SharePoint administrators group, you can use SharePoint Central Administration pages to configure settings for alerts, such as the following:
■
View alert settings.
■
Turn alerts on or off.
■
Specify how many alerts users can create.
You can also use the Stsadm.exe command-line tool to configure alert settings
if you are a server administrator. Using the command line, you can do the following:
■
Turn alerts on or off.
■
Specify how many alerts users can create.
Alerts use the Windows SharePoint Services e-mail settings to send alert items.
When you configure alert settings, be sure that you also double-check the e-mail settings for your virtual server. For step-by-step instructions, see the “To configure
alerts at the virtual-server level” section earlier in the chapter.
446
Part V: Administration of Windows SharePoint Services
Managing Alerts with HTML Administration
You can use HTML Administration pages to view and delete alerts on your site. To
manage alerts, you use the Manage User Alerts page in the Site Administration
pages.
1. On the Site Settings page for the website, under Administration, click Go to
Site Administration.
2. Under Management and Statistics, click Manage user alerts.
3. On the Manage User Alerts page, select a user name in the Display alerts for
___ box, and then click Update.
4. To delete an alert, select the check box next to the alert, and then click Delete
Selected Alerts.
Configuring Alerts for a Virtual Server
You can also change alert settings for a virtual server. Changes you make on the
virtual server affect all websites under that virtual server. To change settings for a virtual server, you use commands on the Virtual Server Settings page. You must be a
member of the SharePoint administrators group or an administrator of the local computer to change virtual server settings.
1. On the server that contains the virtual server, click Start, point to All Programs, point to Administrative Tools, and then click SharePoint Central
Administration.
2. On the Central Administration page, under Virtual Server Configuration,
click Configure virtual server settings.
3. On the Virtual Server List page, click the virtual server you want to configure.
4. On the Virtual Server Settings page, under Virtual Server Management, click
Virtual server general settings.
5. In the Alerts section, next to Alerts on this server are, click On or Off.
6. Under Maximum Number of alerts that a user can create, specify a number of alerts. If you want users to be able to create as many alerts as they want,
select Unlimited number.
7. Click OK.
Using the Command Line to Configure Alerts
You can manage alerts from the command line by using the GetProperty and SetProperty operations with Stsadm.exe. You can set the properties shown in Table 16-4
to configure how alerts work.
Chapter 16: Windows SharePoint Services Site Administration
Table 16-4
447
Properties for the Stsadm.exe Command-Line Utility
Property
Description
alerts-enabled
Turn alerts on or off.
alerts-limited
Specify whether users are limited to a specific number of alerts.
alerts-maximum
Specify the maximum number of alerts users can create.
job-immediate-notification
Specify how often to check for immediate alerts (in minutes).
job-daily-notification
Specify the time of day (using a 24-hour clock) to send out
daily alerts.
job-weekly-notification
Specify the day of the week and time of day (using a 24-hour
clock) to send out weekly alerts.
The following example shows the syntax to use to turn off alerts:
Stsadm.exe –o setproperty –p <port> -pn alerts-enabled –pv false
Summary
In this chapter, we have covered a number ways you can administer and manage
your websites. You have learned how to create sites and subsites. We have
addressed the various templates you can use as you create new sites and the features each will provide by default. You should have a good understanding of the
default site groups and the 20 rights that you can assign to those groups. We have
talked about various access methods, including setting up anonymous access for
sites that will be used by the public at large. We covered setting up alerts so that you
or others can be notified when content on a website or in a specific document
library changes. Finally, we briefly addressed how to set up website usage analysis
so that you can identify which content on your sites is heavily used to aid in your
planning for performance.
As we have discussed each item, we’ve identified how to do the task from the
HTML Administration pages and, in most cases, have indicated how to complete
the same task with the command-line utility, stsadm.exe.
This chapter is by no means exhaustive of all that you will eventually want
to know about administering your websites, but it should be a great springboard to
launch most of your administrative tasks.
Part VI
Administration of
Microsoft Office
SharePoint Portal
Server 2003
In this part:
17
Configuring SharePoint Portal Server 2003 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 451
18
Managing SharePoint Portal Server 2003 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 481
Chapter 17
Configuring SharePoint
Portal Server 2003
In this chapter:
A Quick System Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 452
SharePoint Central Administration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 452
Creating Additional Application Pools . . . . . . . . . . . . . . . . . . . . . . . . . . . . 477
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 480
As a classic example of a multitiered distributed architecture, Microsoft Office SharePoint Portal Server 2003 presents some unique administration requirements. While
the administration tools provided with Microsoft Windows SharePoint Services
discussed in the previous two chapters serve to configure and manage each server
individually, they do not suffice when faced with the multitude of servers that are
usually involved in using SharePoint Portal Server 2003. If multiple database servers,
Web servers, and other component servers are present in this environment, each will
require a single place to go that allows for configuration and management of the
individual servers and of the farm as a whole.
The Web-based tool provided with SharePoint Portal Server 2003 is called SharePoint Central Administration. By maintaining a list of all portal sites in the farm, this
tool allows the administrator to configure the many services provided by each portal
site on a per-portal-site basis. Furthermore, by using the list of all servers in the farm,
the administrator is able to quickly navigate to those servers to perform server-level
management of the servers’ portal site services. It also allows the administrator to perform ongoing management tasks such as portal site management, which includes site
content and security administration, user profile and personal site management, audience creation and management, as well as search and index management.
This chapter will concentrate on showing the portal site configuration tasks an
administrator will have to perform both after installation and on an ongoing basis as
new servers are added or removed from the farm. This will include the configuration
of virtual servers and the subsequent creation of portal sites on those virtual servers.
451
452
Part VI: Administration of Microsoft Office SharePoint Portal Server 2003
A Quick System Overview
To properly set the stage for what the administrator does in configuring SharePoint
Portal Server 2003, let us review the many component services that provide the
product with its functionality. A total of four types of servers are part of a server farm
for which configuration tasks must be performed:
■
Web. This type of server receives HTTP requests from the client community
and serves the portal site content in the form of Web Pages.
■
Index. These servers crawl all portal site content, as well as chosen external
content, and created index files used when users utilize the search feature of
the portal site.
■
Search. This type of server receives queries from users’ search requests, handles the queries by using the index files created by the index servers, and
returns the matching results.
■
Job. This server coordinates scheduled jobs, such as content crawls by the
index server or profile imports from Active Directory.
Additionally, there are three more server types that provide support services to
the farm:
■
Database Server. All portal site configuration information, site security settings, and content is stored in multiple databases in one or more required database servers.
■
E-Mail Server. These optional servers will relay alert messages from the portal
site to administrators and users.
■
HTML Viewer Server. This optional type of server installed from the
Office 2003 Resource Kit can be set up to convert standard Microsoft Office
documents to HTML on behalf of users who do not have Microsoft Office or
the Office Viewers installed.
To qualify as a potential Web, index, search, or job server in the farm, each of
these types of servers will need to have SharePoint Portal Server 2003 installed
on them. Not only must each server be assigned its role in the farm, but each service
that the server will provide must also be configured and tailored to the specific environment to achieve the desired effect.
SharePoint Central Administration
After installing SharePoint Portal Server 2003, you might notice that you do not yet
have a working portal site. You will have to designate all the server types just
mentioned and configure their services before you can create a portal site.
Chapter 17:
Configuring SharePoint Portal Server 2003
453
The install does create an administration website on the server. This is the site
from which the SharePoint Portal Server Central Administration Web pages are
served via Internet Information Services (IIS). During installation, a random port is
generated for this administration website as a simple form of security and to avoid
using port 80, which will be needed for the actual portal site users will access.
Therefore, to administer a portal site through a server named woodgrove on which
the administration website was installed on port 9999, the administrator would use
the following URL in his browser to navigate to the main portal site administration
page: http://woodgrove:9999/sps/. Figure 17-1 depicts the SharePoint Portal Server
Central Administration Web page displayed in the browser for this scenario.
Figure 17-1
F17XR01.bmp
The SharePoint Portal Server Central Administration page
There are two considerations with this random port assignment: first, this means
that each server for the portal site has a different administration port; second, you
might need to secure this port. Even though only user accounts armed with the
knowledge of the random portal site and with appropriate administrator privileges can
modify settings, all traffic is still unencrypted between the administrator’s workstation
and the server being managed. This can be an issue in your environment because
some configuration pages require assigning service accounts and their passwords.
To resolve the first problem, we want to simplify remote administration by
changing the port number so that it is consistent on all servers on the server farm.
This allows the administrator to type the URL for the central administration pages
without going through the Site Settings page for each server. You will need to be
logged on as a member of the local administrator’s group to perform these tasks.
Standardize the port number for the Central Administration pages
1. Open a command prompt.
2. Navigate to %Program Files%\Common Files\Microsoft Shared\web server
extensions\60\BIN.
454
Part VI: Administration of Microsoft Office SharePoint Portal Server 2003
3. Type stsadm.exe -o setadminport -port port_number, and then press Enter.
For example, to specify 8088 as the common port, type
stsadm.exe -o setadminport -port 8088
4. Close the command prompt.
5. Update the shortcut for SharePoint Central Administration on the All Programs
menu for other servers. Do this by using the following steps:
a. On the taskbar, click Start, point to All Programs, point to SharePoint
Portal Server, and then point to SharePoint Central Administration.
b. Right-click SharePoint Central Administration, and then click Properties.
c. On the Web Document tab, in the URL box, replace the existing port
number with the updated port number.
For example, if the updated port number is 8088 and the existing URL is
http://localhost:10505/sps/Default.aspx, change 10505 to 8088 so that the
URL is http://localhost:8088/sps/Default.aspx.
d. Click OK.
Keep in mind that this affects the port for the Windows SharePoint Services
Central Administration pages as well because they are served out of the same virtual
server.
To resolve the security issue, encryption is required and available by configuring IIS with a security certificate and then configuring the administration website to
require a secure channel with Secure Sockets Layer (SSL). Refer to the SharePoint
Portal Server 2003 documentation on Office Online at http://office.microsoft.com
/home/default.aspx for details on how to set this up. Assuming that the SSL certificate is already installed on the servers, the following command will set all servers for
the portal site to require SSL when accessing the administration pages:
stsadm.exe –o –setadminport –ssl
Granting Administrative Access to the Portal Server Farm
One of the first configurations relating to a portal server that you need to understand
and set is administrative access control. There are two high-level administrator types
for a portal site.
Users who are members of the local Administrators group on a portal server
have full administrative access to the server’s configuration and potentially all the
portal site’s content. If the user has Administrators group membership on a portal
server that is playing the Web front-end server role, that user will be able to access
all content and perform all site administration tasks. On non-front-end Web servers,
such members are able to determine settings for the entire farm of servers with
respect to their farm service roles simply by navigating to the SharePoint Portal
Central Administration page on that server.
Chapter 17:
Configuring SharePoint Portal Server 2003
455
Another way to grant portal site administrator privilege to a user is to assign user
accounts (or group accounts) to what is called the SharePoint administrators group
account. The account is defined by navigating to the Set SharePoint Administrative
Group Account link found in the Security Configuration section of the SharePoint
Portal Server Central Administration page. Even though the location implies a user
account, in actuality, any Active Directory account can be assigned here, including
group accounts.
Tip It is considered a best practice to assign an Active Directory Global
Group account as the SharePoint administrators group account to avoid
accidentally losing administrative access should the user account be
deleted.
There are a few tasks that a user associated to the SharePoint administrators
group account cannot perform. Following is a list of tasks that only the local administrator can perform:
■
Extend or unextend a virtual server
■
Change the SharePoint administrators group
■
Manage paths (inclusions and exclusions)
■
Change the configuration database
The SharePoint Portal Server Central Administration Page
The main SharePoint Portal Server Central Administration page has four categories
of links leading to appropriate configuration subpages. These categories and links
allow for configuration of each of the components’ servers, services, and features
that relate to the functionality of the farm. The four categories are Server Configuration,
Portal Site and Virtual Server Configuration, Security Configuration, and Component
Configuration. The remainder of this chapter will be organized by these categories.
The Portal Site and Virtual Server Configuration links will be covered last as part of
an overall discussion on virtual servers as they relate to portal site creation.
Server Configuration
The Server Configuration category of links is used to configure server topology such as
Web, index, search, and job server assignments; database server settings; e-mail server
information; and server farm account settings. This area, depicted in Figure 17-2, is the
first area to go to every time a new server is added to the server farm.
456
Part VI: Administration of Microsoft Office SharePoint Portal Server 2003
Figure 17-2 The Ser ver Configuration links on the SharePoint Por tal Ser ver Central
Administration page
F17XR02.bmp
Configure Server Topology
This link is to a page that is used to view and assign the components of SharePoint
Portal Server for each server in the farm and to remove servers from the farm. This
page also allows administrators to change the components that servers in the farm
will service. In effect, the four server types discussed earlier are defined by assigning
respective servers one or more components to service. For example, a Job Server is
defined by assigning to it the Job service component.
There are three main sections to the Configure Server Topology page: Database
Server Settings, Component Assignments, and Problems With This Configuration.
Figure 17-3 shows the first two sections of the page.
Figure 17-3
F17XR03.bmp
The Configure Server Topology page, which is used for component assignment
Database Server Settings
Because everything, including configuration, is stored in a database, it makes sense to
have to configure database settings first. There are four databases that are used in the
Chapter 17:
Configuring SharePoint Portal Server 2003
457
portal site, but only the first three are configurable with respect to which SQL Server
will host that database. Following is an explanation of those three databases and a few
other items appearing in this section of the Configure Server Topology page:
■
Configuration Database Server. The configuration database maintains connections between servers and content databases, stores server settings, and
identifies which content is to be provided by which virtual servers. There is
one configuration database per stand-alone server or per server farm. Each
server in the farm must be associated with the configuration database by connecting it to that database. The default name of the database is SPS_01_Config.
Typically, the page will already display the server assigned during the product’s post-installation Portal Configuration Wizard. Therefore, clicking the
listed server will show a page displaying the name of the existing configuration
database (as well as the database server name). Also, the option of disconnecting the managed server from that database will be displayed. This is the preferred method for removing a server running SharePoint Portal Server from the
server farm.
■
Content Database Server. The content database is where all portal site content will be placed. By default, the server hosting the portal site content database is the same as the configuration database. This can be changed here to
distribute the database load. Also, because the portal site will have many
sites—and potentially thousands—more than one database on more than one
server can be manually defined. However, only one server is designated as the
default database server on whose databases new sites will be created. When
you create a new site, the databases on the designated default database server
are queried and the new site’s content is added to the database that has the
most available space. The default database name for the first portal site content
database is composed of the first eight characters of the first portal site’s name,
followed by a number, and followed by _SITE. For example, if the portal site
is named Woodgrove, the content database would be Woodgrov1_SITE. Keep
in mind that even though this is the default database used for both portal and
team sites, a separate database can be defined and used to contain team sites.
■
Component Settings Database Server. This database stores service information for each portal site in a deployment. For example, each time SharePoint
Portal Server 2003 updates an index, it creates a gatherer log entry in a table in
the component settings database for the portal site. The default database name
will start the same way as the content database but end with _SERV. Using the
same example as in the previous paragraph, the database would be named
Woodgrov1_SERV.
■
Profile Database Server. The profile database is used to store the content
for the My Site feature, which gives each portal site user a personal site. It will
458
Part VI: Administration of Microsoft Office SharePoint Portal Server 2003
always default to the same server as the configuration database server and cannot be changed here. This database name will end with _PROF. Using the same
example as before, the database would be named Woodgrov1_PROF.
■
Global E-Mail Server. Even though this is not a database server, it appears in
this section and should be configured for the farm. The farm can operate without having an e-mail server defined; however, the alert feature will not function. The alert feature allows users to subscribe to lists and documents and be
alerted via e-mail when those lists or documents change. The configuration
page allows you to set the SMTP e-mail server name or IP address (which can
be Microsoft Exchange, the IIS SMTP service, or any third-party SMTP server
that accepts Anonymous connections) that the alerts should show the change
notification as coming from and to whom replies will be sent, as well as the
character set used for the e-mails. Keep in mind that this is a global setting for
the farm. If a certain server needs to be pointed to a different e-mail server
(such as for a portal server residing outside of a firewall), that server can have
its e-mail server setting changed on its Windows SharePoint Services Central
Administration page.
■
Single Sign-On Credentials. If you are wondering about Single Sign-On
credentials, they too do not have anything to do with databases and are configured with an optional setting used in highly customized portal site implementations. Single Sign-On allows you to store and map an application’s
account credentials to user account credentials. This prevents users from having to sign on again when portal-based applications retrieve information from
business applications, such as third-party enterprise resource planning and
customer relations management (CRM) systems.
By using Single Sign-On, you can centralize information from multiple backend applications through a single portal site that uses application definitions. By
using application definitions, you can minimize and automate the sign-on process to
these applications in a more secure environment. In addition, SharePoint Portal
Server 2003 provides an easy interface for developers to create and extend this
feature.
Component Assignments
The Component Assignments area lists all servers that have been assigned some role
in the server farm. Servers that are assigned as database servers or e-mail servers will
not have a hyperlink, while servers that play one of the following key component
roles will have a hyperlink: Web, Search, Index, and Job. This makes sense because
the hyperlink leads to the SharePoint Central Administration pages as serviced by the
virtual server on that server, which of course requires SharePoint Portal Server 2003
to be installed on that server.
To assign or change the component roles that the listed servers will play, click
the Change Components button at the bottom of the page. This can be useful if, for
Chapter 17:
Configuring SharePoint Portal Server 2003
459
example, you add servers to your server farm. You add a server to the farm by first
installing SharePoint Portal Server 2003 on the server. You will then be able to see it
as a server to which you can assign one of the four component roles (Web, Search,
Index, or Job).
You will need to have at least one Web server to service the client HTTP
requests and serve out the portal site content. Because a portal site needs to offer
search capability, you will have to assign at least one index server to create indexes
from the content it crawls and one search server to handle the client requests using
these indexes. Finally, you will need to assign one job server to handle scheduling
of the index crawls among other services. All four roles must be assigned to a server
before a portal site can be created.
To change component assignments for the server farm
1. On the SharePoint Portal Server Central Administration For server_name page,
in the Server Configuration section, click Configure server topology.
2. On the Configure Server Topology page, click Change Components.
3. On the Change Component Assignments page, in the Component Assignment section, do one of the following:
■
Select a check box to assign a component to a server.
■
You can assign more than one component to each server.
■
Clear a check box to remove the assignment of a component to a server.
4. In the Job Server Component section, in the Job server list, select a job
server.
5. If you have installed the server component for backward-compatible document libraries, in the Document Library Server Component (Optional)
section, in the Document library server box, type the URL of the server to
run the document library server component.
6. If you are not using SSL, the URL should be of the form http://server_name or
server_name.
7. If SSL is enabled or enforced on the document library server, the URL must be
an https address (for example, https://server_name).
8. Click OK.
In a single-server scenario, one server plays all roles. However, in larger environments you will want to distribute the services for availability and performance
reasons. Refer to Chapter 9, “Capacity Planning,” to determine how many servers of
each server type you will need. Also refer to Chapter 12, “Deploying Medium and
Large Server Farms,” for additional details on recommended server role configuration scenarios.
460
Part VI: Administration of Microsoft Office SharePoint Portal Server 2003
Problems With This Configuration
Found at the bottom of the Configure Server Topology page, the Problems With This
Configuration section simply provides reminders of any missing server-role component configurations. If all required components have been configured, you will see
the following message:
“There are no issues at this time. Your farm is fine.”
Otherwise, you will see messages reminding you of configuration tasks you should
perform.
One last item to cover on this page is the Remove Server button. Click this button
to remove servers from the farm only in the following situations:
■
The server does not have SharePoint Portal Server installed on it.
■
The server running SharePoint Portal Server is unresponsive or offline.
■
The server is running the optional component for backward-compatible document libraries only.
Before you remove a server from the server farm, you must remove all dependencies from the server, unless it is the last computer remaining in the server farm.
Configure Server Farm Account Settings
This is a very important page, as it relates to the user accounts used by the various services to perform their tasks as well as to some connectivity settings the services might
need. If you are wondering why we’ve skipped the four links following the Configure
Server Topology link in the Server Configuration section of the SharePoint Portal Server
Central Administration page, it is because navigating to them will show that they point
to the same configurations discussed on the Configure Server Topology page.
You can configure the following settings on the Configure Server Farm Account
Settings page:
Contact E-mail Address
As part of the HTTP header in the requests it makes to crawl content, SharePoint
Portal Server 2003 provides an e-mail address to each website it crawls when creating an index. If a problem occurs while crawling (for example, the crawler is hitting
the site too much), the administrator of the website can contact this address. All portal sites on the server provide this e-mail address to the crawled site while creating
indices. For this reason, the e-mail address for the server farm administrator is typically specified.
Configuration Database Administration Account
The configuration database administration account is the user name and password
that SharePoint Portal Server uses when connecting to the configuration database or
when propagating full-text indexes from index management servers to search servers.
Chapter 17:
Configuring SharePoint Portal Server 2003
461
At a minimum, this account must be a member of the Power Users local group on
all the front-end Web servers, index management servers, and search servers. This
account must also be a member of the local Administrators group on the document
library server. In addition, this account must be a member of the Security Administrators and Database Creators server roles on Microsoft SQL Server.
Default Content Access Account
The default content access account is the user name and password used by the
index component servers to crawl content outside the portal site. There are many
aspects to consider when choosing this account, including the following ones:
■
When SharePoint Portal Server connects to external servers to create content
indexes of sites hosted on the external Internet server, it connects to those
servers by first providing the default content access account to establish a
connection. If this account has not been configured, SharePoint Portal Server
provides the anonymous account. The account used must have Read permissions for the websites and servers being crawled.
■
If there is a proxy server to pass through to get out to the Internet to crawl
external content, the account mentioned above must have proxy permissions
on the proxy server to browse externally to be able to crawl the sites and
create a content index of these Internet sites. Without permissions, the index
servers can crawl only content on the local intranet.
■
The access account should be a member of the SharePoint administrators
group. If the access account is not a member of the SharePoint administrators
group, the server will crawl the site but the content index will not be secure
because all users will be able to access the documents. In the case of intranet
crawls, it means that some data might not be included in the content index
because the account might not be able to access all the sites under a Windows
SharePoint Services site.
Portal Site Application Pool Identity
This account is used by the default application pool (MSSharePointPortalAppPool)
created by SharePoint Portal Server to contain all portal sites. It is the account used
by the application pool to do the initial lookup to determine which content database
stores the user-requested URL’s data. It is also used to access the indices on search
servers, and it plays a role in importing data from Active Directory if the Profile
Import feature is enabled.
The following is a list of security considerations for this account:
■
In a multiserver portal site, the account must be a domain account and must
have the db_owner role on the Configuration Database.
■
This account must be a member of the local Administrators group on document library servers.
462
Part VI: Administration of Microsoft Office SharePoint Portal Server 2003
Proxy Server Settings
With this link, you can set SharePoint Portal Server 2003 index servers to use a proxy
server when they create crawls of external websites so that they can create full-text
indexes of those sites. Proxy servers are generally used to enhance the security of
intranets by working along with a firewall to prevent unauthorized access in from or
out to the Internet. Proxy servers can also enhance performance by caching recently
accessed Web pages, which minimizes download time.
By default, SharePoint Portal Server uses the proxy server setting defined for
the default content access account. The default content access account derives its
proxy server setting from the current proxy server settings in the Microsoft Internet
Explorer application on the crawling server.
Changes to the proxy settings for the SharePoint Portal Server computer do not
affect other applications on the server. For example, configuring the server to use a
proxy server that is different from the proxy server used by Internet Explorer does
not affect Internet Explorer.
Changing the proxy settings on the Search Server Settings page affects servers
running the index component only. For other servers, you can change the proxy settings from the Configure Server Farm Account Settings page.
Security Configuration
The Security Configuration section is used to view or configure security settings for
Microsoft SharePoint Products and Technologies for servers in the server farm,
including blocked file types and antivirus configuration if third-party antivirus software has been installed. Figure 17-4 displays the Security Configuration section,
which is the next area on the SharePoint Portal Server Central Administration page
that you might want to configure before creating your first portal site.
Figure 17-4 The Security Configuration section on the SharePoint Portal Server Central
Administration page
F17XR04.bmp
Set SharePoint Administrators Group Account
As mentioned previously, the SharePoint administrators group account is where you
assign a domain user or group as the administrator of the farm.
Chapter 17:
Configuring SharePoint Portal Server 2003
463
Manage Site Collection Owners and Manage Website Users
The purpose of these two links relate to managing access to sites and will be discussed in Chapter 18, “Managing SharePoint Portal Server 2003.”
Manage Blocked File Types
Windows SharePoint Services provides the ability to restrict certain kinds of files
from being uploaded or retrieved, based on the file extension. By default, several
standard file extensions are blocked, including any file extensions that are treated as
executable files by Microsoft Windows Explorer. Files with curly braces, { or }, are
also blocked automatically. Because the list of blocked file types is maintained by
file extension, all files that use a file extension on the list cannot be uploaded or
downloaded, regardless of the file’s intended use.
The list of file extensions is controlled for the entire server or server farm and
is recorded in the configuration database. Additional file extensions can be blocked
(up to 1024 file types) by adding them to the list.
One thing to keep in mind is that when the list of file extensions is changed,
the change affects both new files being added to a website and files already posted
to a website. Users will be able to rename or delete a file with a blocked file extension but will not be able to perform any other actions.
Even though this option appears in the Security Configuration section, it is
important to realize that technically this is just a file-extension checking mechanism.
For example, if the .mp3 file type is blocked and the user renames the file as .mpz,
the portal site will not block the uploaded file.
Configure Antivirus Settings
When you install an antivirus scanner that is compatible with SharePoint Portal
Server 2003, you can enable the antivirus protection feature for all servers for the
portal site on the Configure Antivirus Settings page. In a server farm deployment,
you will have to install antivirus software on every front-end Web server in the
server farm.
Remember that having such antivirus software installed on your front-end
servers will affect their performance and scalability. You will have to configure your
servers with additional processing power to compensate for the additional overhead.
Component Configuration
The Component Configuration links are used to manage search settings, configure
Single Sign-On, manage shared services, and to configure usage analysis, HTML
viewer settings, and diagnostic settings. If you have installed the optional backwardcompatible document library component (for compatibility with SharePoint Portal
Server 2001), you can also configure document libraries (Web Storage System–based)
464
Part VI: Administration of Microsoft Office SharePoint Portal Server 2003
from here. All the links in this section found on the SharePoint Portal Server Central
Administration page are shown in Figure 17-5.
Figure 17-5 The Component Configuration section on the SharePoint Portal Server Central
Administration page
F17XR05.bmp
Manage the Search Service
This link leads to a page that allows the administrator to manage how and when the
index servers crawl content, to specify where the index servers store temporary files,
and to specify other Search Service–related settings. Refer to Chapter 21, “The Architecture of the Gatherer,” and Chapter 22, “Managing External Content in Microsoft
Office SharePoint Portal Server 2003,” for details about the index and search services. Chapter 18 will also cover these links in the context of ongoing management
tasks relating to the search services.
Manage Settings for Single Sign-On
As stated earlier, Single Sign-On is a feature relating to integration with enterpriselevel third-party applications. For more information see Chapter 26, “Single Sign-On
in SharePoint Portal Server 2003.”
Configure HTML Viewer
Included with Windows SharePoint Services is the ability to connect to an HTML
Viewer server. An HTML Viewer server provides support for users who want to view
the content of files on the Windows SharePoint Services website but do not have
Microsoft Office Word, Excel, or PowerPoint from Microsoft Office 97 (or a later
release of Office) installed on their local computers. Even users who have only a
Web browser (Microsoft Internet Explorer or Netscape Navigator) can view content
by having the native Office file format converted to HTML on the fly. Although a
slight delay occurs while the transformation takes place, the converted file is
extremely close to the WYSIWYG formatting of the original. In addition to the process of transforming files on the fly for end users, administrators can use a batch
Chapter 17:
Configuring SharePoint Portal Server 2003
465
process mode to convert the contents of entire folders to HTML ahead of time and
give users better response when requesting those documents.
By default, the HTML Viewer server supports only the following document
types: .doc, .xls, .ppt, and .pps.
Transformation of a supported document can take from 1 to 30 seconds,
depending on the complexity and size of the document as well as the speed and
available resources of the dedicated computer. To provide for this ability and assure
a fast response time, you should dedicate a separate computer to this service.
To install the service, find the htmlview.exe file in the Microsoft Office 2003
Resource Kit and extract it on a server that will handle the conversion process. Using
the required instructions found with the HTML Viewer files, you will have to install
Microsoft Office 2003 along with the HTML Viewer on the chosen server.
Installing Office for the HTML Viewer
To create an Office HTML Viewer server, you must install a customized version of
Office 2003 to the dedicated Office HTML Viewer server. Before creating this installation, find the ENG11PROBYPASS.MST and HTMLTRBACKEND.MSI files from the
package that included this document. Copy these two files (ENG11PROBYPASS.MST
and HTMLTRBACKEND.MSI) to the local computer and folder where the setup.exe
for Office 2003 will be run.
Office 2003 must be installed in order to create an Office HTML Viewer server.
From the command prompt of the workstation, enter the following command line
from the folder where the ENG11PROBYPASS.MST file is stored:
setup TRANSFORMS=ENG11PROBYPASS.MST
Or you can add the path to the file using the TRANSFORMS property, as shown
in the following example:
setup TRANSFORMS="<path>\ENG11PROBYPASS.MST"
You can also add further customizations, but they are not needed and, in fact,
might conflict with settings in the ENG11PROBYPASS.MST file.
You should accept the default install location for Office (C:\Program Files\
Microsoft Office\).
Tip You should not use Office 2003 from the console on the Office HTML
Viewer server. It is only for use by the HTML Viewer server. The customizations to Office on the server provide for a specialized installation. Use of
Office from the console could slow down the server. Also, if an HTML viewing action takes place while Office is in use for other purposes, it would dramatically affect the responsiveness of all other applications or services on
the server.
466
Part VI: Administration of Microsoft Office SharePoint Portal Server 2003
Note The specialized installation of Office on the Office HTML Viewer server
is provided to help mitigate any possible security threats by reducing the
exposure of Office access points to external users. The configuration of Office
used for the Office HTML Viewer sets macro security to High. Setting macro
security to High turns off macro support for executables. Macros embedded
in documents or files will not run during the file conversion process. Any documents or files that retrieve data on the fly from remote servers or custom
applications will not function. Content within the document or file must be
static to be converted. However, VBA projects (source code) in any documents
or files will make a roundtrip through the HTML viewing process.
Running the Office HTML Viewer Windows Installer Package
After the Microsoft Office 2003 install process completes, run the Microsoft Office
HTML Viewer install package on the Office HTML Viewer server by using the
following command line:
HTMLTRBACKEND.MSI
This file is a Windows Installer file that places necessary Office HTML Viewer
executables and Office customizations on the computer.
You can also run this file by double-clicking it from within Windows Explorer
or referencing it in the Run utility (Start menu, Run option). When it starts, a setup
dialog box requesting you to specify where to install files appears. You should
accept the default install location. If the HTMLTRBACKEND.MSI file does not start, it
is likely that MSIEXEC.EXE is not installed on the computer or it is not the most recent
version. The latest version of MSIEXEC.EXE is available from the www.microsoft.com
website.
When the HTMLTRBACKEND.MSI file finishes, the installation and customization process of Office 2003 is also complete. It is now necessary to instruct Windows
SharePoint Services where to find the Office HTML Viewer server.
After installing the HTML Viewer service on a host, the administrator can configure the portal site to use the viewer by navigating to its configuration page from
the SharePoint Portal Central Administration page depicted on Figure 17-6.
Keep in mind that the resource requirements for this service are very high and
can severely affect the performance of any server not dedicated to this task. It is
therefore recommended to dedicate a server to host this service. The steps and
parameter settings are explained next.
Chapter 17:
Figure 17-6
F17XR06.bmp
Configuring SharePoint Portal Server 2003
467
The HTML Viewer Configuration page
To configure Windows SharePoint Services
1. In the Path to HTML Viewer Server box, type the full URL to the server hosting HTML viewing.
2. In the Maximum Cache Size box, type the maximum size to allow for the
HTML viewing cache.
3. In the Maximum File Size box, type the maximum file size to view.
4. In the Timeout Length box, type the length of time to wait before ending an
HTML Viewer process.
5. Click OK.
Configure Diagnostic Settings
This link leads to a page that allows the administrator to change logging settings for
the various services and processes, view and manage her diagnostic logs, and configure automatic reporting settings for certain types of events.
Logging Settings
The Logging Settings section on the Configure Diagnostic Settings page shows a list
of components that run on the various portal servers, allowing each to have its logging settings modified. The components that allow their logging levels to be modified are as follows:
■
WWW Worker Process
■
Notification Service
468
Part VI: Administration of Microsoft Office SharePoint Portal Server 2003
■
Single Sign-On Service
■
Administrative Service
■
Search Service
■
Search Filter Process
■
Backup – Restore
■
Audience Job
■
Third Party Applications
For each component, you can edit the logging level as follows:
■
Do not log event for this component
■
Log critical events only
■
Log informational events and critical events
■
Log tracing information
Note You should select Log Tracing Information only for troubleshooting purposes. Logging tracing information might affect performance and disk use.
You can also choose to save a copy of the log automatically after a specified
number of days, and you can choose to delete logs automatically after a specified number of days to save disk space.
View Diagnostic Logs
This section allows for viewing and deleting the log files created by the components
defined in the Logging Settings section just described.
To view and delete diagnostic logs
1. On the SharePoint Portal Server Central Administration For server_name page, in
the Component Configuration section, click Configure diagnostic settings.
2. On the Configure Diagnostic Settings For server_name page, in the View Diagnostic Logs section, in the Diagnostic logs list, select a diagnostic log, and
then do one of the following:
a. To view the selected log, click View Log.
b. To delete the selected log, click Delete. You cannot delete a log file that
is in use.
c. To delete unused log files, click Delete Unused Log Files.
Chapter 17:
Configuring SharePoint Portal Server 2003
469
Automatic Error Reporting
SharePoint Portal Server 2003 can be configured to automatically send reports to
Microsoft of errors that cause it to crash. Automatic error reporting uses a connection
that uses the HTTP over SSL (https) protocol, which is more secure than an ordinary
Internet connection. The data that Microsoft collects is used strictly for the purpose
of tracking down and solving problems that users are experiencing. The information
is stored in a secure database with limited access.
You can view the Microsoft Error Reporting Data Collection Policy from a link
in the Automatic Error Reporting section. There is a link to this page on the SharePoint
Portal Server Central Administration For Server server_name page.
The procedure to configure automatic error reporting for this server involves
configuring the Error Reporting settings from Local Computer Policy in Microsoft
Management Console. You must be logged on to the computer as a member of the
local Administrators group to complete this procedure.
To configure automatic error reporting
1. On the taskbar, click Start, and then click Run.
2. Type gpedit.msc and then click OK.
3. In Group Policy Object Editor, under the Local Computer Policy node,
expand the Computer Configuration node.
4. Right-click Administrative Templates, and then click Add/Remove Templates.
5. In the Add/Remove Templates dialog box, click Add.
6. Select AER_LanguageID.ADM, and then click Open. For example, for English,
you would select AER_1033.ADM. For more information about language IDs,
see “Regional and Language Settings” in the SharePoint Portal Administrator’s
Guide.
7. Click Close to close the Add/Remove Templates dialog box.
8. Under the Computer Configuration node, expand the Administrative Templates node.
9. Expand the Application Error Reporting node.
10. Click the Queued Reporting node.
11. In the details pane, right-click Bypass queue and send all reports, and then
click Properties.
12. On the Properties page, on the Setting tab, click Enabled.
13. Click OK.
14. Close Group Policy Object Editor.
470
Part VI: Administration of Microsoft Office SharePoint Portal Server 2003
Portal Site and Virtual Server Configuration
At this point, we have configured almost all the core service features for the portal
servers in the farm. We are now ready to discuss the configuration options and procedures relating to the creation of portal sites. The links in the Portal Site And Virtual
Server Configuration section are used to extend and configure virtual servers required
to host portal sites and team sites, create and manage portal sites, and configure portal site information such as external access settings and quota configurations.
Because all websites including portal sites need to be serviced through a virtual
server preconfigured in IIS, we will begin our discussion there and end with the
actual portal site creation procedure. Figure 17-7 depicts the links of the Portal Site
And Virtual Server Configuration section we will be discussing.
Figure 17-7 The Portal Site And Virtual Server Configuration section on the SharePoint Portal
Server Central Administration page
F17XR07.bmp
Extending Portal Virtual Servers
As with Windows SharePoint Services, for a virtual server to provide front-end Web
services for sites, it must be extended. Extending a virtual server associates the
appropriate application pool, installs the Windows SharePoint ISAPI filter to the virtual server, and creates the appropriate files in the virtual server’s folder.
However, in the portal site scenario, you do not have to extend the virtual
server before creating your portal sites. This is different from Windows SharePoint
Services, which requires that this step be performed before any sites can be created. The
portal site creation process auto-extends the virtual server as part of the process.
That said, you might be wondering why the Extend An Existing Virtual Server From
The Virtual Server List Page option even exists on the SharePoint Portal Server
Central Administration page. It is there to configure front-end Web servers that are
added to the farm after the portal site has been created. Read the “Creating Portal
Sites” section at the end of this chapter for details on how to extend virtual servers
in a multiportal farm.
Once you have extended a virtual server, it will appear on the Virtual Server
List page that appears when you click Configure Virtual Server Settings from the
Chapter 17:
Configuring SharePoint Portal Server 2003
471
Virtual Server List page. Selecting a virtual server on that page brings you to the Virtual Server Settings page depicted in Figure 17-8, which will allow you to configure
that server. We now will examine the various configuration options the Virtual
Server Settings page provides. Keep in mind that any settings that contradict similar
settings that you have defined at the portal site level will be superseded by the
virtual server’s settings.
Figure 17-8
F17XR08.bmp
The Windows SharePoint Services Virtual Server Settings page
Configure Self-Service Site Creation
You might want to give your user community the ability to create new sites for themselves on the fly by enabling Self-Service Site Creation. If this feature is enabled, any
user can create new top-level websites without an approval process.
Careful consideration must be given before turning this feature on, as you are
potentially relinquishing control over the propagation of sites and site content in
your organization. If you turn it on and don’t check its usage, you might find yourself with a portal site filled with unused sites created at the user community’s whim.
To address this issue, a “dead-web cleanup” feature is provided that is described in
the next section.
Configure Site Collection Use Confirmation and Deletion
To help mitigate the loss of disk and database space as a result of unused site collections, this option allows the administrator to set time limits that define how long
to wait to delete unused site collections. There are also parameters that allow the
administrator to define how many times to e-mail the owners of these unused sites
to warn them of the deletion. If activity on the site is detected or if the owner of the
site responds to the e-mailed warning, the site will not be deleted. Keep in mind that
472
Part VI: Administration of Microsoft Office SharePoint Portal Server 2003
this feature will work only if the usage analysis processing is turned on at the portal
site level.
Security Settings
This area of the SharePoint Portal Central Administration page, depicted previously
in Figure 17-8, is used to configure the list of available rights for any sites hosted by
a particular server, as well as how to handle Web Part Pages. Details follow for each
of the two links.
Manage User Rights for the Virtual Server
This link is also referred to as the Virtual Rights Mask. It is used if you want to make
sure that certain rights are not available to anyone using any of the site collections
hosted by the virtual server, regardless of site group membership. You can disable
those rights by deselecting the rights you want to block.
A situation in which you’d use this setting is when you want to ensure that
users cannot change the themes to their sites. You can disable the Apply Themes
right at the virtual server level so that users must use the default theme of the site
template when any site or workspace is created.
Manage Security Settings for Web Part Pages
Web Parts are the main programming mechanism through which the portal site Web
pages provide their functionality. A Web Part has server-side code, client-side code,
or both that eventually translates to user-viewable rendered HTML. The code behind
these Web Parts can pass parameter values and other data to other Web Parts that
have been written by the programmer to receive that data. Web Parts that have been
written with this kind of functionality are called “Connected” Web Parts because
they use the Web Part Connections programming feature.
Connected Web Parts pass data to each other, and therefore might expose that
data and violate existing security policy constraints. Also, these kinds of Web Parts
tend to have more code running either at the client or server to support the connections. As an administrator, you can turn off Web Part Connection support at the
virtual server level to improve security or to improve the performance of the server.
The other configuration you might want to set on this page pertains to whether
or not you want to have your user community see Web Parts that have been
published on the Microsoft website. The feature is turned on by default, but if it’s
disabled, it will cause the site pages to show only the default Web Parts created at
install time as well as those posted by the administrator.
Virtual Server Management
Because Microsoft SharePoint Portal 2003 is based on Windows SharePoint Services,
which in turn handles all Web requests through an ISAPI filter in IIS, it follows that
some virtual server configuration tasks are required. The settings for these tasks are
Chapter 17:
Configuring SharePoint Portal Server 2003
473
available via the Virtual Server Management section of the Virtual Server Settings
page depicted in Figure 17-9. Refer to Chapter 15, “Configuring Windows SharePoint
Services,” for details about most of the settings found here. The most important link
in this section is the Define Managed Paths link, which will be described next.
Figure 17-9
F17XR09.bmp
The Virtual Server Management section on the Virtual Server Settings page
Define Managed Paths
When client URL requests come in to the server on the listening port (usually port 80)
defined on any virtual server that has been extended with Windows SharePoint Services, the Windows SharePoint Services ISAPI filter first looks at the URL to determine whether the path requested is to be serviced by Windows SharePoint Services.
The filter makes that determination by comparing the requested path to the Managed Path list. By default, all paths under the virtual server’s home folder are implicitly
included.
However, an administrator might want the same virtual server that serves the
portal site to also serve other subwebs that are not part of Windows SharePoint
Services. For example, the administrator might want the path /tsweb, which represents a Web interface to terminal services, to be excluded from any portal Windows
SharePoint Services processing. This is accomplished on this page by explicitly
excluding the path.
On this page, it is also possible to append additional managed paths. For
example, the default path intended for team site hosting, created at install time, is
the /sites URL. If another path is preferred, such as /dept or /team, simply add the
paths using the Add A New Path section of the page. Then, when a team site is
created, the administrator will be able to select these additional paths as alternate
creation paths for the new team site.
Create Top-Level Website
The virtual server hosting a portal site can also host team sites. This is accomplished
by