Planning and architecture for Office SharePoint Server 2007, part 1

Microsoft Corporation

Published: February 2009

Author: Microsoft Office System and Servers Team (o12ITdx@microsoft.com)

Abstract

This book provides information and guidelines to lead a team through the steps of planning the deployment of a solution based on Microsoft Office SharePoint Server 2007. The audiences for this book are business application specialists, line-of-business specialists, information architects, IT generalists, program managers, and infrastructure specialists who are planning a solution based on Office SharePoint Server 2007. This book also includes links to planning worksheets for recording information related to your planning and deployment activities.

This book is the first part of a two-part series. You can find the other part at the following link:

•         Planning and architecture for Office SharePoint Server 2007, part 2 (http://go.microsoft.com/fwlink/?LinkId=85548&clcid=0x409)

The content in this book is a copy of selected content in the Office SharePoint Server technical library (http://go.microsoft.com/fwlink/?LinkId=84739) as of the date above. For the most current content, see the technical library on the Web.

The information contained in this document represents the current view of Microsoft Corporation on the issues discussed as of the date of publication. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented after the date of publication.

This document is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS DOCUMENT.

Complying with all applicable copyright laws is the responsibility of the user. Without limiting the rights under copyright, no part of this document may be reproduced, stored in or introduced into a retrieval system, or transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or otherwise), or for any purpose, without the express written permission of Microsoft Corporation.

Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document. Except as expressly provided in any written license agreement from Microsoft, the furnishing of this document does not give you any license to these patents, trademarks, copyrights, or other intellectual property.

Unless otherwise noted, the example companies, organizations, products, domain names, e-mail addresses, logos, people, places and events depicted herein are fictitious, and no association with any real company, organization, product, domain name, e-mail address, logo, person, place or event is intended or should be inferred.

© 2009 Microsoft Corporation. All rights reserved.

Microsoft, Access, Active Directory, Excel, Groove, InfoPath, Internet Explorer, OneNote, Outlook, PowerPoint, SharePoint, SQL Server, Visio, Windows, Windows Server, and Windows Vista are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries.

The names of actual companies and products mentioned herein may be the trademarks of their respective owners.

Contents

Getting Help. xxiii

I. Plan overall design. 25

Plan overall design. 26

How to use this Planning Guide. 26

What is Microsoft Office SharePoint Server 2007?. 27

Examples of solutions based on Office SharePoint Server 2007. 29

Establishing the planning team.. 31

Planning for governance. 31

Plan sites and features. 33

Plan sites. 33

Plan portal sites. 34

Plan Internet presence sites. 35

Plan other sites. 36

Plan customizations. 36

Plan personalization sites. 37

Plan site collections. 37

Plan security. 37

Plan search needs. 38

Plan business intelligence integration. 38

Plan document and records management 38

Plan workflows. 39

Plan forms. 39

Plan site maintenance. 39

Worksheet 40

Plan Shared Services Providers. 41

About SSPs. 41

Determining Shared Services Provider needs. 42

Sharing content across multiple SSPs. 44

Sample project plan: Microsoft Office SharePoint Server 2007 deployment 46

Sample template: SharePoint Products and Technologies governance plan. 47

II. Plan governance. 48

Plan governance. 49

What is governance?. 51

What should be governed?. 51

Who should determine governance policies?. 53

How should governance be implemented?. 54

Establishing and governing a SharePoint service. 56

What is a SharePoint service?. 56

Elements of a successful service. 56

What to govern in a SharePoint service. 57

Creating multiple services. 59

Implementing and governing information architecture. 61

What is information architecture?. 61

Resources for planning information architecture. 62

Governing information architecture. 63

Case study: Governing information architecture to eliminate content chaos. 64

Governance features in Office SharePoint Server 2007. 69

IT service features. 69

Site templates. 69

Quotas. 69

Locks. 70

Workflows. 70

Features. 70

Self-service site creation. 70

Records management 71

Information architecture features. 71

Content types. 71

Content approval 71

Versioning. 72

Site Content and Structure page. 72

Information management policies. 72

Information rights management 73

Blocked file types. 75

Sample code acceptance checklist for IT organizations. 76

Resources for SharePoint development best practices. 77

Code acceptance checklist 78

Security. 78

Session management 79

Validation. 79

Sensitive data. 80

Exception handling. 80

Web parts. 81

Documentation. 82

General software development best practices. 83

Printable version of the sample code acceptance checklist 85

III. Plan Web site structure and publishing. 87

Plan Web site structure and publishing. 88

Determine the information architecture of your site. 89

What is information architecture?. 89

General planning recommendations. 89

Using information architecture to plan the structure of your site. 91

Using information architecture to plan for people and personalization. 91

Using information architecture to plan for business data. 92

Using information architecture to plan for search. 92

Download this book. 92

Determine sites and subsites. 93

Planning site collections. 93

Planning sites and subsites. 94

Site templates included in Office SharePoint Server 2007. 95

Comparison of the publishing templates. 98

Recording your site structure decisions. 99

Download this book. 100

Plan site navigation. 101

Review of Office SharePoint Server navigation controls. 102

Navigation controls on master pages. 102

Navigation controls on layout pages. 104

Navigation Web Parts. 105

Planning navigation. 106

Planning the user experience. 106

Planning navigation on pages. 107

Download this book. 107

Plan Web pages. 108

Elements of Web pages. 108

Planning master pages. 112

Planning content pages. 113

Planning layout pages. 114

Using layout pages to restrict authoring. 116

Setting restrictions on field controls. 116

Allowing or restricting Web Part zones. 117

Summary. 117

Download this book. 118

Plan Web page authoring. 119

Plan browser-based authoring. 121

Plan Page Editing toolbar customizations. 121

Plan HTML Editor toolbar customizations. 122

Plan reusable content 123

Plan dictionary customizations. 124

Plan additional resources. 124

Plan smart-client authoring. 125

Worksheet 127

Download this book. 127

Plan variations. 128

About variations. 128

Variations and content approval 129

Planning target variation sites. 130

Variations and site navigation. 131

Variations and content deployment 131

Variations and Web Parts. 132

Planning your variation sites. 133

Worksheet 133

Download this book. 133

Plan content approval and scheduling. 134

Plan governance. 134

Plan content moderation or workflow approval 134

Plan where and how content can appear 135

Plan scheduling. 135

Governance and scheduling in a content deployment scenario. 135

Download this book. 135

Plan content deployment 136

What is content deployment?. 136

About deployment jobs and paths. 137

Content deployment security. 138

Configuring content deployment 138

Record content deployment plans. 139

Worksheet 139

Download this book. 139

Plan for collaboration sites. 140

About collaboration sites. 140

Determine number of collaboration sites. 140

Specific paths. 140

Additional paths. 141

Worksheet 141

Download this book. 141

Plan for multilingual sites. 142

Determine your multilingual needs. 142

Identify language requirements. 142

Determine internationalized domain name mappings. 143

Determine whether you want to use site variations. 144

Plan for multilingual site deployment 144

Determine your language pack requirements. 144

Determine supplemental language support requirements. 146

Determine requirements for word breakers and stemmers. 146

Download this book. 148

IV.  Plan for personalized content and sites. 149

Plan for personalized content and sites. 150

Plan for people and user profiles. 150

Plan for audiences. 151

Plan for personalized Web Parts. 151

Plan for My Sites. 151

Managing social networking. 152

Plan for people and user profiles. 153

About people and user profiles. 153

Plan connections to Profile Services. 155

Plan user profile properties. 156

Default user profile properties. 157

Additional user profile properties. 158

Plan people and relationships. 159

Plan policies. 160

Plan policies for people features. 161

Plan policies for the properties of user profiles. 162

Policy replication. 164

Plan for finding people. 164

Plan additional personalization functionality. 165

Worksheets. 166

Plan for audiences. 167

About audiences. 167

Plan key audiences. 168

Plan content targeting to audiences. 169

Worksheet 171

Plan for personalized Web Parts. 172

About personalized Web Parts. 172

Plan for public profile Web Parts. 173

Default Web Parts for public profiles. 173

Additional Web Parts for public profiles. 174

Plan for personal site Web Parts. 174

Default Web Parts for personal sites. 174

Additional Web Parts for personal sites. 175

Plan for personalization site Web Parts. 175

Default Web Parts for personalization sites. 175

Additional Web Parts for personalization sites. 176

Plan additional Web Parts for My Sites. 177

Plan for suggested Web Parts on My Sites. 177

Plan for lists and libraries Web Parts on My Sites. 179

Plan for business data Web Parts on My Sites. 180

Plan for dashboard Web Parts on My Sites. 181

Plan for filter Web Parts on My Sites. 182

Plan for miscellaneous and custom Web Parts on My Sites. 183

Plan for personalized Web Parts on other sites. 184

Worksheet 184

Plan My Sites. 185

About My Sites. 185

About the public profile page. 186

About personal sites. 187

About personalization sites. 188

Plan for personalized sites. 188

Activate the My Site feature. 189

Plan My Site policies. 192

Plan for personalization sites. 192

Worksheet 194

V.  Plan workflows. 195

Plan workflows. 196

What are workflows?. 197

About business processes. 197

Workflows in Office SharePoint Server 2007. 197

Understanding workflow. 200

Technology Basics of Workflow and SharePoint Products and Technologies. 202

Windows Workflow Foundation. 202

Windows SharePoint Services. 205

Workflow and Windows SharePoint Services 3.0. 207

Combining Windows Workflow Foundation and Windows SharePoint Services. 208

Workflow in Windows SharePoint Services: A Scenario. 210

Authoring a Workflow. 210

Associating a Workflow with a Document Library or List 210

Starting a Workflow. 211

Interacting with a Workflow. 213

Summarizing the Process. 216

Authoring Windows SharePoint Services Workflows. 218

Authoring Workflows with Visual Studio 2005 and WF Workflow Designer 219

Authoring Workflows with Office SharePoint Designer 2007. 221

Workflow and Office SharePoint Server 2007. 224

Combining Windows Workflow Foundation, Windows SharePoint Services, and Office SharePoint Server 224

Workflow in Office SharePoint Server: A Scenario. 226

Authoring Office SharePoint Server Workflows. 231

Authoring Workflows with Visual Studio 2005 and WF Workflow Designer 231

Authoring Workflows with Office SharePoint Designer 2007. 231

Making a technology choice. 233

Conclusion for Understanding Workflow in the SharePoint Products and Technologies. 234

Resources. 234

About the Author 234

Plan workflows: Next steps. 235

Planning workflows: Next steps. 235

VI.  Plan InfoPath Forms Services. 236

Plan InfoPath Forms Services. 237

InfoPath Forms Services planning articles. 238

Before you begin designing form templates. 238

Planning form template design. 238

Planning form template deployment 238

Planning server supportability and maintenance. 238

Scenario planning. 239

Scenario 1: Expense-Report Submission. 239

Scenario 2: Insurance claims processing. 240

Scenario 3: Online government permits. 241

Plan what form templates are needed. 243

Create an inventory of current forms. 243

Survey the advantages of online forms. 244

Assess the need for new form templates. 245

Determine form template complexity. 245

Worksheet 246

Plan custom form templates. 247

Plan form template design infrastructure requirements. 248

Server requirements. 249

Network requirements. 249

Security requirements. 249

Plan server-side data connections needed for form templates. 251

Scenarios for the use of data connections. 251

Scenario 1: Intranet: Authenticated user submitting data through e-mail 251

Scenario 2: Extranet: Basic authentication submitting data through e-mail 252

Scenario 3: Intranet: HTTP post to application server 252

Database data connection. 252

HTTP post data connection. 253

SharePoint library submit data connection. 253

SharePoint list data connection. 253

Web service data connection. 253

XML file data connection. 254

Plan deployment of form templates. 255

Browser-compatible form templates. 255

Scenario: Insurance claims processing. 256

Plan deployment of administrator-approved form templates. 257

Determine the impact of anonymously accessible form templates. 259

Identify the need for anonymously accessible form templates. 259

Internet scenario. 259

Corporate scenario. 259

Security and usage considerations for anonymously accessible form templates. 260

Bandwidth and capacity considerations for anonymously accessible form templates. 260

Plan for naming form templates. 261

Plan for upgrading form templates. 262

Plan for retiring form templates (Office SharePoint Server) 263

Plan version control for form templates. 264

Document Retention. 264

Capacity Planning. 264

Plan for mobile device access to form templates. 266

Plan workflow for form templates. 268

Custom workflow form templates. 268

Workflows for form template approval 268

Workflows launched from a form.. 268

VII.  Plan for business intelligence. 270

Plan for business intelligence. 271

Determine business data and business intelligence needs. 273

About business intelligence. 273

Plan Office SharePoint Server 2007 features for business intelligence. 274

Plan data integration features of Office SharePoint Server 2007. 275

Plan information presentation and reporting features of Office SharePoint Server 2007. 276

Plan business data scenarios. 277

Plan purpose-based scenarios. 277

Plan process-based scenarios. 278

Plan IT-based scenarios. 278

Determine business intelligence needs for your organization. 279

Worksheets. 280

Determine scope of business intelligence analysis. 281

About business intelligence scope planning. 281

Business intelligence principles. 281

Business intelligence examples. 282

Plan data connection management 283

About data connection management in Office SharePoint Server 2007. 283

Plan access to external data. 283

Plan access to data connection libraries. 284

Plan key performance indicators. 285

About KPIs. 285

Plan data sources for KPIs. 287

Plan KPIs in reports. 289

Plan KPIs in dashboards. 289

Plan KPIs in My Site. 290

Worksheets. 291

Plan reports. 292

About reports. 292

Plan Web Parts for reports. 293

Plan reports for the Report Center site. 294

Plan the reports library. 296

Plan other features of the Report Center site. 296

Worksheets. 297

Plan dashboards and filters. 298

About dashboards and filters. 298

Plan Web Parts for dashboards. 300

Plan Excel Web Access Web Parts for dashboards. 300

Plan business data Web Parts for dashboards. 301

Plan KPI Web Parts for dashboards. 302

Plan filters. 302

Plan automatic filter Web Parts. 303

Plan filters that use user-specified values. 304

Plan filters that use values selected from a list 304

Worksheets. 306

Plan Excel Services security. 307

About Excel Services security. 307

Plan user authentication. 308

Plan communication among servers. 309

Plan external data authentication. 309

Integrated Windows authentication. 310

SSO authentication. 310

None. 312

Unattended service account 312

Security settings. 313

File access method. 313

Data encryption. 314

Trusted file locations. 314

Trusted data providers. 316

Trusted data connection libraries. 317

View Only permissions. 317

External data connections. 318

.odc files. 318

Managing .odc files. 319

User-defined functions. 319

Worksheets. 320

Determine resource requirements to support Excel Services. 321

About Excel Services topologies. 321

Data access models. 322

Excel Services topologies. 323

Plan for simultaneous client connections. 335

Plan for concurrent Excel Calculation Services session requests. 335

Excel Services performance testing. 336

Hardware configuration. 337

Data set attribute tables. 337

Performance test results. 341

Limit the number and duration of open sessions. 349

Plan rendering Excel KPI data. 351

About rendering Excel KPI data. 351

KPI List Web Parts for Office SharePoint Server 2007. 351

Excel KPI and SQL Server 2005 Analysis Services. 351

Plan Excel reports against OLAP cubes. 352

About building Excel reports against OLAP cubes. 352

OLAP functions. 352

OLAP formulas. 352

Plan access to Excel spreadsheets. 353

About spreadsheet management 353

Plan a strategy to control access to workbooks and ensure data integrity. 353

Plan a strategy to restrict access to individual data objects within workbooks. 353

Plan external data connections for Excel Services. 355

About Excel Services connections to external data. 355

Connections and Excel workbooks. 356

Embedded and linked connections. 356

Data providers. 357

Authentication to external data. 357

Windows authentication. 358

SSO.. 359

None. 359

Data connection libraries and managed connections. 359

Reusing connections. 360

Managing connections. 360

Securing connections. 360

Excel Services security and external data. 360

Trusted file locations. 361

Trusted data connection libraries. 361

Trusted data providers. 362

Unattended account 362

Trusted subsystem and delegation. 362

Step-by-step server configuration for external data. 363

Adding a trusted data provider for Excel Services. 364

Allowing external data for Excel services. 365

Setting the unattended account 367

Configuring Office Server single sign-on. 368

Creating a data connection library. 379

Trusting a data connection library on Excel Services. 381

Exposing the data connection library in the Office client 382

Step-by-step workbook configuration for external data. 387

Creating a new connection. 387

Reusing an existing connection from a data connection library. 389

Specifying the server authentication for an existing connection. 391

Frequently asked questions. 394

How do I get Microsoft Access data into my workbooks on Excel Services?. 394

How do I use other workbooks as data sources on Excel Services?. 394

Why don't my Windows authentication connections work even when I have correctly configured Kerberos in my farm?. 394

If the credentials are not delegated, how can Excel Services make per-user permission checks on files?  395

What is the guidance around using local cubes on the server?. 395

How can I have more control over how external data is accessed from the server?. 395

What factors should I consider regarding performance and external data?. 396

How can I secure my data so that it is viewable only from a workbook published to Excel Services?  396

I followed the instructions in this article, but when I load my workbook on the server I see some unsupported features error talking about Query Tables. How can I fix it?. 397

I have an ODBC connection, and therefore I do not have an .odc file. How can I use my connection with a data connection library so that it will work on Excel Services?. 398

How do View Only permissions and .odc files in a data connection library work?. 398

Plan for business data connections with the Business Data Catalog. 399

About the Business Data Catalog. 399

Plan connections to the Business Data Catalog. 400

Plan business data presentation. 402

Worksheets. 403

Plan for business data profiles. 404

About business data profiles. 404

Plan connections to the Business Data Catalog. 404

Plan to include business data content sources. 405

Plan properties of business data profiles. 405

Worksheets. 408

Plan business data lists. 409

About business data lists. 409

Plan business data columns. 409

Plan dependent columns. 410

Plan business actions in business data lists. 411

Plan Web Parts for business data lists. 411

Worksheets. 412

Plan business data Web Parts. 413

About business data Web Parts. 413

Plan core business data Web Parts. 414

Plan specialized business data Web Parts. 415

Plan KPI Web Parts. 416

Plan Excel Web Access Web Parts. 416

Plan SQL Server 2005 Analysis Services Web Parts. 417

Plan filter Web Parts connected to business data Web Parts. 417

Plan deployment of Web Parts. 417

Worksheets. 418

Plan business data actions. 420

About business data actions. 420

Plan the scope of business actions. 421

Plan properties for business actions. 422

Plan Business Data Action Web Parts. 423

Plan custom business actions. 423

Worksheet 423

Plan for business data search. 424

About business data search. 424

Plan business data search. 425

Plan Shared Services Providers for business data. 425

Plan business data content sources. 426

Plan search properties for business data. 427

Plan access and security for business data search results. 428

Plan search scopes for business data. 429

Plan keywords for business data. 429

Plan business data tabs in the Search Center site. 430

Example. 430

Worksheets. 431

VIII.  Plan search. 433

Plan search. 434

Why two search services?. 434

Plan the search team.. 435

Plan to crawl content 435

Plan the end-user search experience. 435

Identify your search team.. 436

About the search planning team.. 436

About the search planning process. 436

Plan the search deployment and operations teams. 437

Worksheet 437

Plan to crawl content 438

About crawling and indexing content 439

Identify the sources of content that you want to crawl 439

Plan content sources. 440

Crawl different types of content 442

Crawl content on different schedules. 443

Full and incremental crawl schedules. 444

Reasons to do a full crawl 445

Limit or increase the quantity of content that is crawled. 447

Other considerations when planning content sources. 453

Content sources summary. 453

Plan for authentication. 454

Plan protocol handlers. 455

Plan to manage the impact of crawling. 456

Plan crawl rules. 457

Specify a different content access account 458

Plan search settings that are managed at the farm level 459

Indexing content in different languages. 460

Worksheet 461

Plan the end-user search. 462

Plan what users see when performing a query. 463

Search user interface levels. 463

Plan custom scopes. 465

Advanced Searches. 473

Plan properties for search. 474

Plan what users see in search results. 479

Plan keywords, best bets, and synonyms. 479

Plan the relevance of search results. 485

Plan whether to use federated locations and federation Web Parts. 487

Plan the appearance of links. 488

Plan search-based alerts. 489

Security considerations for search. 490

Sharing data across Web parts. 490

Exclude content from a crawl 490

IX.  Plan communication. 492

Plan communication. 493

Communications components. 493

Plan presence integration. 494

About online presence. 494

Advantages of incorporating online presence. 495

Organizational considerations. 495

Software requirements. 495

E-mail account requirements. 495

Plan incoming e-mail (Office SharePoint Server) 497

About incoming e-mail 497

Key decisions for planning incoming e-mail 497

Basic scenario. 497

Advanced scenarios. 498

Configuration options and settings modes. 501

Before configuring incoming e-mail 501

Plan the Microsoft SharePoint Directory Management service. 502

Directory management service configuration options. 502

Worksheet 503

Plan outgoing e-mail (Office SharePoint Server) 504

About outgoing e-mail 504

General requirements. 505

Outbound SMTP server 505

From and Reply-to addresses. 505

Character set 506

X.  Plan document management 507

Plan document management 508

What is document management?. 510

The elements of a document management system.. 510

The planning process. 511

Download this book. 512

Identify document management participants and stakeholders. 513

Worksheet 514

Download this book. 514

Analyze document usage. 515

Worksheet 517

Download this book. 517

Plan document libraries. 518

Plan document libraries. 518

Plan the flow of content 522

Promoting document libraries from Office client programs. 523

Download this book. 524

Plan content types. 525

What are content types?. 525

Properties integration with the 2007 Office release. 526

About column templates. 527

About folder content types. 527

Planning document content types. 527

Planning list content types. 529

Planning document conversions. 530

After planning content types: next steps. 531

Worksheets. 531

Download this book. 532

Plan versioning, content approval, and check-outs. 533

Plan versioning. 533

Plan content approval 534

Plan check-in and check-out 535

Worksheet 536

Download this book. 536

Plan Information Rights Management 537

Information Rights Management in Office SharePoint Server 2007. 537

Worksheet 538

Download this book. 538

Plan workflows for document management 540

Worksheet 541

Download this book. 541

Plan information management policies. 542

About information management policies and policy features. 542

About information management policy reporting. 544

About information management policy integration with the 2007 Office system applications. 544

Policy features available in Office SharePoint Server 2007. 545

Plan information management policies. 545

Worksheet 546

Download this book. 547

Plan enterprise content storage. 548

Typical large-scale content management scenarios. 549

Large-scale authoring environment 549

Large-scale content archive. 549

Extremely large-scale content archive. 550

Site collections: content storage benefits and limitations. 550

Benefits of storing content in the same site collection. 550

Limits on storing content in the same site collection. 551

Sites: content storage benefits and limitations. 551

Benefits of storing content in the same site. 552

The Document Center site. 552

Limits on storing content in the same site. 552

Libraries: content storage benefits and limitations. 553

Benefits of storing content in the same library. 553

Limits on storing content in the same library. 553

Using indexed columns to improve view performance. 553

Folders: content storage benefits and considerations. 554

Summary of recommendations. 555

Download this book. 555

XI.  Plan records management 556

Plan records management 557

What is records management?. 558

Elements of a records management system.. 558

Overview of records management planning. 560

Download this book. 561

Identify records management 562

Worksheet 563

Download this book. 563

Develop the file plan. 564

About records, active documents, and archived documents. 564

Determine what is a record. 565

Complete the file plan. 567

Worksheet 569

Download this book. 569

Design the Records Center 570

About the Records Center site. 570

Planning document libraries for records retention. 571

Planning metadata. 572

Planning records metadata. 572

Planning additional metadata. 573

Planning policies. 574

Planning the record routing table. 575

Worksheets. 577

Download this book. 577

Plan how records are collected. 578

Techniques for moving files into the Records Center site. 578

Manually sending content to the Records Center site. 578

Using managed e-mail folders in Microsoft Exchange Server 2007 to send e-mail and files to the Records Center site. 579

Using a custom solution to send files to the Records Center site. 579

Completing your plan. 580

Download this book. 581

Plan physical records retention. 582

Using Office SharePoint Server to manage physical records. 582

Physical records and the Records Center site. 582

Lists and physical records. 583

Case study: Physical records management at Microsoft 585

Planning physical records retention. 585

Worksheet 587

Download this book. 587

Plan e-mail message records retention. 588

Using a Records Center site for e-mail message retention. 589

Using Exchange Server 2007 with Office SharePoint Server to manage e-mail message records  590

Managing e-mail message records without Exchange Server 2007. 591

Planning e-mail message records retention. 592

Worksheets. 593

Download this book. 593

XII.  Plan site and content security. 595

Plan site and content security. 596

Plan site security. 597

About site security elements. 597

About assigning permissions. 598

About fine-grained permissions and permission inheritance. 600

Permission inheritance and fine-grained permissions. 600

Permission inheritance and subsites. 600

Choose which levels of site security to use. 601

Plan for permission inheritance. 601

Worksheet 602

Determine permission levels and groups to use. 603

Review available default groups. 603

Review available permission levels. 605

Determine whether you need additional permission levels or groups. 605

Do you need custom groups?. 606

Do you need custom permission levels?. 606

Worksheet 607

Define custom permission. 608

Customize an existing permission level 608

Copy an existing permission level 608

Create a permission level 609

Choose which security groups to use. 610

Determine which Windows security groups and accounts to use for granting access to sites. 610

Decide whether to use all authenticated users. 611

Decide whether to allow access to anonymous users. 611

Worksheet 612

Choose administrators and owners for the administration hierarchy. 613

Levels of administration. 613

Worksheet 614

XIII.  Plan for site creation and maintenance. 615

Plan for site creation and maintenance. 616

Plan for site maintenance and management 617

Plan for site maintenance. 617

Plan for managing site collections. 618

Plan site collection quotas. 618

Plan site use confirmation and deletion. 619

Worksheet 620

Plan process for creating sites. 621

Determine who can create sites and a method for site creation. 621

Plan for Self-Service Site Management 622

Plan for custom site creation processes. 623

Worksheet 624

Planning worksheets for Office SharePoint Server 2007. 625

Planning worksheets by task. 625

Planning worksheets by title. 633

Getting Help

Every effort has been made to ensure the accuracy of this book. This content is also available online in the Office System TechNet Library, so if you run into problems you can check for updates at:

http://technet.microsoft.com/office

If you do not find your answer in our online content, you can send an e-mail message to the Microsoft Office System and Servers content team at:

o12ITdx@microsoft.com

If your question is about Microsoft Office products, and not about the content of this book, please search the Microsoft Help and Support Center or the Microsoft Knowledge Base at:

http://support.microsoft.com

I. Plan overall design

The articles in this chapter include:

•      Plan sites and features

•      Plan Shared Services Providers

•      Sample template: SharePoint Products and Technologies governance plan

•      Sample project plan: Microsoft Office SharePoint Server 2007 deployment

Plan overall design

In this article:

•      How to use this Planning Guide

•      What is Microsoft Office SharePoint Server 2007?

•      Examples of solutions based on Office SharePoint Server 2007

•      Establishing the planning team

•      Planning for governance

How to use this Planning Guide

The content in this planning guide is designed to lead a team through the steps of planning and deploying a new solution based on Microsoft Office SharePoint Server 2007. The audiences for this guide are business application specialists, line of business specialists, information architects, IT generalists, program managers, and infrastructure specialists who are planning a solution based on Office SharePoint Server 2007. Before using this guide, we recommend that you:

•      Review the Product evaluation for Office SharePoint Server 2007 (http://technet.microsoft.com/en-us/library/cc261970.aspx) to learn about the features of Office SharePoint Server 2007. This will help ensure that Office SharePoint Server 2007 meets your functional and IT needs, and it will help you envision and plan your solution.

•      Define the organizational goals you want to achieve with a solution based on Office SharePoint Server 2007.

•      Define the vision and scope of the solution.

This planning guide has been organized into two stages. The first stage guides you in determining the types of Web sites your organization needs, the features of each site, and the interactions among the sites that meet your enterprise goals. Out of this stage of planning, you will develop a set of worksheets that will help determine the details of your site and feature needs. These worksheets will help you record information such as:

•      Sites and site hierarchies

•      Relationships between sites

•      Features of sites

•      Site customizations

Along with filling in the worksheets that accompany this document, we recommend that you incorporate your site and feature planning decisions into a conceptual design document that:

•      Defines the purpose of the solution you are planning

•      Describes the implementation of the solution

•      Provides data, flowcharts, illustrations, and other information needed to plan the solution deployment

After you have determined how your solution will work, the second planning stage guides you in making a series of deployment planning decisions. In this stage, you will develop a set of worksheets that will help determine the implementation of your deployment. These worksheets will help you record information such as:

•      Deployment design

•      Physical topologies

•      Database design

•      Security design

•      Service-level agreements

Along with filling in the worksheets that accompany this document, we recommend that you incorporate your deployment planning decisions into a design specification document that:

•      Defines hardware requirements

•      Describes the physical system design

•      Provides data, diagrams, and other information useful to the team implementing the deployment

After you plan your sites and features and plan the deployment, the Deployment for Office SharePoint Server 2007 guide will guide you in implementing your Office SharePoint Server 2007 deployment. The process is illustrated below:

This guide includes a companion set of worksheets for recording information related to your planning and deployment activities. To best achieve your solution planning and deployment goals, use the supplied worksheets to record the results of your planning decisions as you use this guide.

Note:

For a description of the steps needed to plan the migration and deployment of an existing solution to Office SharePoint Server 2007, see Upgrading to Office SharePoint Server 2007 (http://technet.microsoft.com/en-us/library/cc303420.aspx).

What is Microsoft Office SharePoint Server 2007?

Microsoft Office SharePoint Server 2007 is a rich server application for the enterprise that facilitates collaboration, provides full content management features, implements business processes, and provides access to information essential to organizational goals and processes. It provides an integrated platform to plan, deploy, and manage intranet, extranet, and Internet applications across and beyond the enterprise.

Office SharePoint Server 2007 facilitates the creation and deployment of feature-rich and content-rich Web sites, including organizational portal sites, Internet presence sites, team collaboration sites, and specialized sites such as content repositories or meeting workspaces. Although Office SharePoint Server 2007 is customizable and has a rich object model, it comes with a full set of features, such as ready-to-use Web site and portal templates, Web Parts, lists, libraries, workflows, and site variations to tailor content to different cultures, markets, and geographic regions.

By using Office SharePoint Server 2007, you can plan and implement business processes that integrate with existing systems by means of XML-based electronic forms and the Business Data Catalog. Workflows included in Office SharePoint Server 2007 automate common business processes such as document review and approval, issue tracking, and signature collection. Office SharePoint Server 2007 workflows are based on the Windows Workflow Foundation, and Office SharePoint Server 2007 supports developing and deploying custom workflows to implement enterprise-specific business processes.

Solutions based on Office SharePoint Server 2007 can provide organization-wide access to business intelligence and other information stored in Office SharePoint Server 2007 or in line-of-business systems such as SAP. The Business Data Catalog enables you to include data from back-end systems in lists, Web Parts, pages, and search results. Excel Services in Microsoft Office SharePoint Server 2007 provides access to real-time, interactive Office Excel 2007 spreadsheets from a Web browser. You can plan to integrate reports, key performance indicators, and business dashboards into your solution. Office SharePoint Server 2007 search provides access to information, people, and expertise.

You can plan and implement content management solutions based on Office SharePoint Server 2007. Microsoft Content Management Server 2002 functionality has been integrated into Office SharePoint Server 2007 and enhanced to support authoring, staging, and publishing custom Web sites. Office SharePoint Server 2007 document management features support each stage of documents' life cycles, from template creation to document authoring, reviewing, sharing, auditing, and ultimately archiving or destroying. Records management capabilities built into Office SharePoint Server 2007 help your enterprise collect, manage, and dispose of corporate records in a consistent and uniform manner based on your company's policies.

Because Office SharePoint Server 2007 is built on and includes the full features of Windows SharePoint Services 3.0, it is an ideal tool for collaboration. Windows SharePoint Services 3.0 provides a consistent, familiar framework for lists and document libraries, site administration, and site customization. The extensible Windows SharePoint Services 3.0 framework facilitates building custom solutions that span multiple sites and complex architectures.

For a full Office SharePoint Server 2007 product and feature overview, see the Product evaluation for Office SharePoint Server 2007 (http://technet.microsoft.com/en-us/library/cc261970.aspx) guide.

Examples of solutions based on Office SharePoint Server 2007

Here are examples of typical solutions that can be built using Microsoft Office SharePoint Server 2007:

•      Online news magazine   A publishing organization uses Office SharePoint Server 2007 to build their branded online magazine site. Article submissions come from inside and outside the organization to be reviewed and accepted by staff editors. This Internet site has a strong community presence because users can log on for personalized information, and it has an extensive search component.

The Internet site includes subsites for current news and editorials; blogs; and regular columns about politics, business, health, people, personal finance, and science and technology. The site also enables users to sign in to interact with each other and to comment on articles published on the site.

•      Controlled distribution of financial data to clients and business partners   A bank deploys a solution based on Office SharePoint Server 2007 to take advantage of Excel Services. The solution enables bank managers to communicate efficiently with clients by providing controlled access to specified workbooks that can be rendered with view-only permissions in a Web browser. The workbooks are accessible in document libraries on a portal; this enables the bank to restrict the availability of financial data to clients who have authenticated access to the portal.

•      Online permit application   A local government agency uses Office SharePoint Server 2007 and Microsoft Office InfoPath 2007 to provide permit application and approval to contractors over the Internet. Contractors use the Web site to apply for permits using an online service. Data entered into the permit application Web form is submitted to a database in the government's Department of Building Inspections network.

After the application data is submitted, a new permit request (a multi-part Office InfoPath 2007 form) is automatically populated to a workspace. When the form is opened, the requesting contractor's company and permit application data is populated into the form's fields. If the request is approved, an electrical permit (also populated with the requestor's contact data and relevant information) is rendered in HTML and posted to the Department of Building Inspections permit site, where the contractor can view and print the permit for posting at the construction site.

•      Departmental portal site   A product development department within a medium-sized company uses Office SharePoint Server 2007 to take advantage of its search, content aggregation, business application integration, collaboration, and personalization features. The department develops a portal site that becomes an essential part of the product development process, hosting their knowledge base, product specifications, an organization chart, individual My Sites for team members, and a home page that broadcasts schedule information, product success stories, and other important news. The installation grows from an isolated small server farm into a well-developed medium server farm implementation that uses a combination of intra-farm and inter-farm shared services within a larger deployment across the entire company.

•      Equity research   A large investment bank uses Office SharePoint Server 2007 to develop a set of Web sites that facilitate quickly developing, reviewing, and publishing equities research notes, reports, and models in a variety of formats. Using the integrated Office SharePoint Server 2007 platform, the solution designers implement a portal site for authoring and reviewing research notes and models; an Internet site for presenting the content to customers; a staging site to test the Internet site; and a records repository site for retaining models and research notes to meet regulatory requirements. Using custom features, the set of sites (distributed over multiple server farms) supports the rapid and automated flow of content from site to site and from team member to team member as content moves through its stages toward publication.

•      Records management   An appliance manufacturer's legal division implements a records management solution using the Office SharePoint Server 2007 Record Repository site template. Based on their file plan, the division implements and configures policies, content types, and document libraries to retain each type of record the division manages. The records managers adjust easily to the record repository site's familiar SharePoint interface while taking advantage of its built-in records management features. These features support properly storing incoming records, retaining each type of record for the legally mandated period, putting records on hold, and approving of their disposition. The records management programmable interface let teams in the organization integrate their document management and e-mail systems with the record repository site using the Web service APIs.

•      Corporate Internet presence site   An international automobile manufacturer has headquarters in Germany; a major subsidiary in Michigan serving the North American market; and regional offices throughout Europe, Asia, and North America. The products are sold internationally, and distinct manufacturing operations serve each regional market. The company's Internet presence Web site is built, administered, and authored using Office SharePoint Server 2007. It is the focal point for the corporate marketing efforts, and it includes subsites for each product line along with areas for press releases, investment information, company information, and career opportunities.

Each corporate brand has its own marketing department with individuals responsible for writing that brand's content and updating it on the Web site. The corporate communication department controls the look and feel of the site to make sure the branding and messaging are consistent. The site includes site variations that tailor its content to different languages, cultures, markets, and geographic regions.

Using Office SharePoint Server 2007 Web sites, the writers for each brand author the site's content and route it for review and approval while managing the creation of multilingual content versions. Using scheduled workflows, the approved and localized content is copied to staging sites where it is tested and ultimately deployed to the public site.

Establishing the planning team

A well-planned solution based on Microsoft Office SharePoint Server 2007 will promote better collaboration, content management, knowledge discovery, and business processes across your organization while being secure, cost-effective, and manageable for your IT department. To satisfy this broad set of goals, it is important to identify key stakeholders across all relevant disciplines and include them in your planning team. They include:

•      Managers and other organizational leaders who understand the requirements of the business processes that Office SharePoint Server 2007 will be used to implement.

•      IT professionals and business unit IT specialists who will be tasked with proposing a solution that implements the desired business processes, and with deploying and maintaining the solution across one or more server farms.

•      Site designers to plan the user experience and visual design of the sites and the templates that will comprise the solution.

•      Developers to determine the scope and design of required custom features, such as workflows, forms, and Web Parts.

•      Testers who will ensure that the site's features are correct and that site deployment and administration function as specified.

Planning for governance

Governance is the set of policies, roles, responsibilities, and processes that you establish in your enterprise to guide, direct, and control how it uses technologies to accomplish business goals. Deploying Office SharePoint Server 2007 in your enterprise provides rich new capabilities such as online collaboration, document management, business intelligence, and Web publishing. To strike the right balance between the needs of the users of Office SharePoint Server 2007 and the IT professionals who deploy and operate it, we recommend that you form a governing body that includes representatives of all stakeholders in the Office SharePoint Server  deployment. This body can then create and enforce rules that govern the use of Office SharePoint Server in the enterprise.

To help you determine the aspects of your Office SharePoint Server 2007 deployment to govern and for descriptions of governance techniques, see Plan governance.

For additional information to help your governance planning and implementation, we provide a Web page, Governance Information for SharePoint Server 2007 (http://go.microsoft.com/fwlink/?LinkId=90916&clcid=0x409,) that provides a rich set of SharePoint Products and Technologies governance resources, including:

•      Feature articles and white papers about governance

•      Content about governance for IT pros

•      Content about governance for developers

•      Links to governance-related tools

•      Links to partner organizations with governance-related services and products

•      Links to governance-related community resources

The Governance Information for SharePoint Server 2007 page will be updated frequently with new feature articles and other resources.

Plan sites and features

In this article:

•      Plan sites

•      Plan site collections

•      Plan security

•      Plan search needs

•      Plan business intelligence integration

•      Plan document and records management

•      Plan workflows

•      Plan forms

•      Plan site maintenance

•      Worksheet

One outcome of planning a solution based on Microsoft Office SharePoint Server 2007 is a determination of the types of Web sites and portal sites to implement, and a list of the features that you need to plan for each site. Record this information in the Determine Sites and Portals planning worksheet.

As you fill out the worksheet, use the guidelines in this article to list the types of portal sites, Internet presence sites, and other site types you need for your solution, and then list for each site:

•      The sets of users who will participate in the site or portal. When you know who the site serves, you can more easily determine the appropriate security settings for the site.

•      Requirements for searching.

•      Customization needs.

•      Personalization needs.

•      Features that you need to plan for each portal or site, such as business intelligence, document management, forms, or workflows.

Plan sites

The first step in planning a solution based on Microsoft Office SharePoint Server 2007 is to determine the set of portal sites, Internet presence sites, team sites, and specialized sites that your organization and its customers need. Determining this affects subsequent planning decisions, such as where the sites will be implemented in your server topology, what features to plan for each site, how processes that span multiple sites are implemented, and how information is made available across one or more sites.

Worksheet action

As you plan the set of portal sites, Internet sites, and other sites, list each site separately in the Determine Sites and Portals planning worksheet (http://go.microsoft.com/fwlink/?LinkId=73282&clcid=0x409).

Plan portal sites

Portal sites based on Office SharePoint Server 2007 provide a focal point for finding relevant, personalized information in an organization. You can plan divisional and rollup portal sites that are based on the scale and structure of your organization and that aggregate organizational information, and you can plan interactive application portals where team members can perform tasks in your organization.

Planning portal sites by organizational hierarchy

Plan the basic portal sites you need based on the scale and structure of your organization. Each of these portal sites should contain information needed for a project or division within your larger organization, and each will link to collaboration sites relevant to that project or division. Some portal sites for larger divisions or projects will also aggregate information found on all the smaller portal sites devoted to smaller divisions or projects.

Use the following guidelines when planning portal sites based on your organizational structure:

Divisional or team portal sites   Plan to create one portal site for an entire small organization, or one for every division or project of 50–100 people within a medium-sized to large organization. In large organizations, there might be several levels of portal sites, with each portal site focusing on the content created and managed at its level of the organization.

You can design a portal site for members of your organization to collaborate on content related to your business or organizational goals. These can be self-contained or they can work with other sites as part of a publishing process. Often, these portal sites will have a mixture of collaborative content used internally and content intended for publication to an audience.

Rollup portal sites   A rollup portal site contains general cross-organization content. It lets users across divisions find information, experts, and access to organization-wide processes. It often contains subsites that are scoped to the overall organizational information architecture and are usually mapped to the structure of the divisional or project portal sites. For each organization or distinct Shared Services Provider (SSP), plan to create a centralized rollup portal site with an aggregated view of all related portal sites.

Planning application portal sites

An application portal organizes team processes and provides mechanisms for running them. Application portals often include digital dashboards and other features for viewing and manipulating data related to the portal's purpose. The information presented in an application portal site usually comes from diverse sources, such as databases or other SharePoint sites.

For example, the human resources organization in an enterprise could design an application portal site to provide employees with:

•      Access to general information such as employee handbooks and career opportunities.

•      Ways to do common tasks, such as submitting timecards and expense reports.

•      Dashboards for viewing personalized information such as an employee's salary and benefits history.

As another example, the internal technical support organization in an enterprise could design a Help Desk application portal to provide technical support to members of the enterprise. Features of the application portal could include:

•      Access to a knowledge base of past support incidents and best-practices documentation.

•      Ways to do common tasks, such as starting a support incident or reviewing the status of an ongoing incident.

•      Integration with communications features that support online meetings and discussions.

•      Personalized views of data. For example, support managers could view dashboards providing views of their team members' productivity and customer satisfaction ratings. Support engineers could view their current unresolved incidents.

In the Determine Sites and Portals planning worksheet, list each divisional, rollup, and application portal site that you plan to create. Be sure to identify the name and purpose of the portal site. For more information about planning portal sites, see Chapter overview: Plan site structure and navigation (Project Server) (http://technet.microsoft.com/en-us/library/cc197502.aspx).

Plan Internet presence sites

Internet presence sites are customer-facing sites. They are usually branded and are characterized by consistent stylistic elements, such as colors, fonts, and logos in addition to structural elements such as navigation features and the structure of site pages. Although the appearance of an Internet site is tightly controlled, the content of the site may be dynamic and may change frequently.

For example, a corporate presence Internet site communicates important company information to customers, partners, investors, and potential employees, including descriptions of products and services, company news, annual reports, public filings, and job openings. As another example, an online news Internet site provides frequently updated information, along with interactive features such as stock tickers and blogs.

Because an Internet presence site represents your enterprise to an external audience, you might stage and test the site and then publish it — either based on a schedule or as needed — to its public "production" location. A staging site is a mirror of the production site that you use to test content before it's published. Using a staging site can help ensure that published content meets stringent standards. Staging sites also allow content authors to work on servers located on your company's intranet, while Internet users are using production servers in your perimeter network. A built-in content deployment feature makes it easy to move content from the staging to the production servers.

Record your staging and production Internet presence sites in the Determine Sites and Portals planning worksheet. For more information about planning Internet presence sites, see Plan Web site structure and publishing.

Plan other sites

You can plan to allow portal site or Internet site users to create additional sites. For example, you can plan to give each team member who uses a portal site a My Site, which is a team site based on Windows SharePoint Services 3.0 with public and private views. You can also allow team members to create other sites, such as Document Workspace sites, as they collaborate. Similarly, you can give users of an Internet site access to collaboration sites as part of a Web-based service. For example, you can give them permissions to create Meeting Workspace sites and participate in online meetings as part of their experience of using your site.

In addition to portal sites and Internet sites, Office SharePoint Server 2007 includes the ability to create the following specialized sites of use in the organization:

Document Center site   This is a large-scale library useful as an enterprise-wide knowledge base or historical archive. It includes features that can help users navigate, search, and manage a large number of documents in a deep hierarchy by using a set of specialized Web Parts.

Records Center site   Records management is the management of files and documents that provide evidence of activities or transactions performed by the organization. The Records Center site is designed to implement the storage component of a records management solution based on Office SharePoint Server 2007.

Record your other site needs in the Determine Sites and Portals planning worksheet. For more information about collaboration site planning, see Plan for collaboration sites. For more information about Document Center sites, see Plan document libraries. For more information about Records Center sites, see Design the Records Center site.

Plan customizations

You can plan to customize your portal sites, Internet sites, or team sites. For example, if you are planning a site to provide an Internet presence for your enterprise, you can brand the site by customizing its master pages to include your organization's logo and color scheme.

You can also customize your site by adding functionality. Office SharePoint Server 2007 has a complete object model and is built on the .NET framework. For more information about programming Office SharePoint Server 2007, see the Office SharePoint Server 2007 Software Development Kit.

For each site or portal that requires customization, make a note in the Customization column of the Determine Sites and Portals planning worksheet. For more information about customization, see Plan Web site structure and publishing.

Plan personalization sites

A personalization site is a filtered view of the content of a portal site or Internet site that provides users of that site with targeted content based on the user's role or preferences. When you plan a portal or Internet site based on Office SharePoint Server 2007, you can design a personalization site based on that site. Users can then choose to view the general content displayed by the portal or Internet site or they can view the related personalization site, which filters the content so that it is more relevant to a particular user's specific information needs or tasks.

If you plan to design a personalization site for any site you listed in the Determine Sites and Portals planning worksheet, record your decision in the Personalization column of the worksheet. For more information about personalization sites, see Plan for personalized content and sites.

Plan site collections

After you determine which sites and portal sites your solution requires, the next step is to plan how these sites and portals are implemented across site collections. A site collection is a hierarchical set of sites that can be managed together. Sites within a site collection have common features, such as shared permissions, galleries for templates, content types, and Web Parts, and they often share a common navigation. All sites in a site collection are stored together in the same SQL database. A portal site is often implemented as a site collection with the top-level Web site as the home page of the portal.

In general, when planning a solution based on Microsoft Office SharePoint Server 2007, put each of the following types of sites in separate site collections:

•      Portal sites

•      Internet sites (staging)

•      Internet sites (production)

•      All team sites related to a portal site or Internet site

•      Document Center sites

•      Records Center sites

For more information about planning Office SharePoint Server 2007 site collections, see Plan Web site structure and publishing.

Plan security

Planning security includes planning for authentication and authorization of users and groups of users. Authentication is the process by which Office SharePoint Server verifies who a user is. Authorization determines what actions a user is allowed to perform on a given object such as a list item, a library, or a site.

Elements of security planning include:

•      Determining the authentication methods to use.

•      Determining the categories of users of your solution.

•      Determining permission levels to assign to users and groups.

•      Planning groups of users and assigning those groups permissions.

•      Planning the scopes at which permissions will be applied, such as lists, libraries, or sites.

For more information about planning Office SharePoint Server 2007 security, see Chapter overview: Plan site and content security (http://technet.microsoft.com/en-us/library/cc288189.aspx).

Plan search needs

Planning search includes determining the scope of content that can be searched from each site, configuring your server farms to index the content and search for it efficiently and securely, and optionally planning customizations of the search user interface. Depending on your requirements, the search scopes in different sites can vary widely. For example, in a portal site used to plan and create products, the scope of searching could include product specifications, internal marketing documents, meeting notes, and other information of internal value. The scope of search in the Internet site in which the public learns about these products would be limited to content describing your organization's products and services, but not the internal content.

In preparation for search planning, for each site or portal site in your Determine Sites and Portals planning worksheet, indicate the scope of what can be searched for by each set of users. For more information about search planning, see Plan search.

Plan business intelligence integration

Business intelligence enables the members of an organization to gather, store, analyze, and access business data. Office SharePoint Server 2007 includes business intelligence capabilities that help organizations preserve data integrity while enabling powerful data searching, integration, analysis, rendering, and sharing.

In preparation for business intelligence planning, in the Business Intelligence column of your Determine Sites and Portals planning worksheet, indicate all sites and portal sites that require business intelligence integration. For more information about business intelligence planning, see Plan for business intelligence.

Plan document and records management

A document management system is implemented to control the flow of documents in your organization — how they are created, reviewed, published, and consumed, and how they are ultimately disposed of or retained. Because nearly all solutions will include these activities, expect to plan a document management implementation. Document management planning considerations include how content will be organized in document libraries, the metadata to define for each type of content, the workflows that will be required during the content's lifecycle, and the policies to apply to the content.

A record is a document or other physical or electronic entity in an organization that serves as evidence of an activity or transaction performed by the organization. Records management is the process by which an organization determines what types of information are records, how to manage them through their retention periods, and how to ultimately destroy or archive them. Office SharePoint Server 2007 includes features that help organizations implement records management systems and processes. Work with your organization's legal department to determine if records management should be included in your solution.

In preparation for document and records management planning, in the Document and Records Management column of your Determine Sites and Portals planning worksheet, indicate all sites and portals that require document or records management planning. For more information about document management planning, see Plan document management. For more information about records management planning, see Plan records management.

Plan workflows

Workflows implement business processes on documents, Web pages, and list items in Microsoft Office SharePoint Server 2007. For example, a workflow can route a document for review, track an issue through its various stages of resolution, or guide a contract through an approval process. Office SharePoint Server 2007 includes workflows that address primary content management needs, such as reviewing or approving documents for publication, along with specialized workflows for tracking issues, managing multiple language translations of content, and managing other processes. You can create custom workflows using Microsoft Visual Studio 2005 or Office SharePoint Designer 2007.

To prepare for workflow planning, in the Workflows column of your Determine Sites and Portals planning worksheet, indicate all sites and portals that require workflow planning. For more information about planning workflows, see Plan workflows.

Plan forms

In a solution based on Office SharePoint Server 2007, forms can be used to gather information and display data from a variety of sources, to automate business processes, and to enhance collaboration scenarios. For example, for an Internet site, you can plan to use forms to survey current users and to sign up new users. For a human resources portal site, you can plan to use forms for submitting timecard information, selecting benefits, or reviewing the performance of employees.

To prepare for forms planning, in the Forms column of your Determine Sites and Portals planning worksheet, list all sites and portals that require forms planning. For more information about planning for forms, see Plan InfoPath Forms Services.

Plan site maintenance

Site maintenance includes:

•      Planning for site cleanup and general site management.

•      Determining how you will let site users create team sites and other subsites, and how to track these sites.

•      Finding and removing stale sites.

•      Keeping the performance of your portals and Internet sites at an acceptable level.

Because you need to plan site maintenance for all your sites and portals, you do not need to register this in your Determine Sites and Portals planning worksheet. For a full discussion of site maintenance planning, see Plan for site creation and maintenance.

Worksheet

Use the following worksheet to record the information discussed in this article:

•      Determine Sites and Portals planning worksheet (http://go.microsoft.com/fwlink/?LinkId=73282&clcid=0x409)

Plan Shared Services Providers

A Shared Services Provider (SSP) provides a common set of services and service data to a logical grouping of Web applications and their associated sites. This article describes how SSPs work in Microsoft Office SharePoint Server 2007 and includes recommendations on planning for SSPs.

About SSPs

Services provided by an SSP

The following shared services are provided by each SSP:

•      Personalization services   provides user profiles based on data imported from directory services, My Sites with personal information that can be shared by all users in the SSP and managed by privacy policies, and content targeting by audience, Office client application, or personalization site links.

•      Business Data Catalog   provides a single unified schema for data stored in line-of-business applications.

•      Excel Services   provides shared worksheets and a way to analyze business data from data connection libraries by using reports in dashboard pages.

•      Office SharePoint Server Search   crawls all sites on Web applications using the SSP to create a single index of all content, data, and metadata.

•      Portal usage reporting   enables SSP administrators to view aggregated information about site usage across the entire site hierarchy. SSP administrators can also enable usage reporting for administrators of individual sites and site collections.

Consuming services from an SSP

When a server farm is installed, you create the default SSP as one of the first post-setup tasks. Each SSP contains all of the available (installed) shared services.

•      You associate SSPs with specific SharePoint Web applications.

•      A SharePoint Web application can only be associated with one SSP.

•      All site collections and sites within a SharePoint Web application consume services from the same SSP.

•      Shared services cannot be enabled or disabled at the site collection or site level. All services that are available from the SSP are available to all sites within the Web application.

Farm-level SSP configuration

A server farm can host one or more SSPs. A server farm can also consume services provided by an SSP on a different server farm.

•      Intra-farm shared services   The server farm uses the services of an SSP hosted on the server farm.

•      Inter-farm shared services   The server farm uses the services of an SSP on a different server farm. A server farm that is consuming services from a different farm might not contain any SSPs. The one limitation to this configuration is that Excel Services is not available outside the farm that hosts this service. If Excel Services is required by a farm, the farm must host shared services locally.

In most single-farm environments, one SSP provides services for an entire organization. Multiple SSPs are only used in deployments that have a proven need for securely isolated content.

Geographic SSP configuration

Providing shared services over the WAN is not supported. For example, a regional farm in Africa cannot consume shared services from a central farm in Europe. The African farm must host its own SSP. However, users in Africa can connect to a central farm in Europe and consume shared services from the central farm.

While hosting shared services over the WAN is not supported, a central farm can be configured to crawl content across the WAN. For example, a central farm in Europe can crawl the content of a regional farm in Africa. This configuration provides a method of hosting enterprise-wide search. In this scenario, the central farm is not hosting shared services to the regional farm and the regional farm is not consuming shared services from the central farm.

Determining Shared Services Provider needs

The biggest design decision around providing shared services is how many SSPs to plan for.

Planning for a single SSP

In many cases, a single SSP can provide services for an entire organization.

•      A single SSP in a farm provides shared services to Web applications hosted on that farm.

•      All users in the SSP can share personal information, search for content, and access business data, according to each of their permissions.

•      Access to content can be limited by content targeting, privacy policies, and other features based on SharePoint groups and security.

A single SSP should be used if:

•      There is no explicit reason to use multiple SSPs.

•      Users will collaborate or share content and data across the organization.

•      Users will search organization-wide for people working in the organization.

Planning for multiple SSPs

The most important criteria that determine if you need more than one SSP are your requirements for isolation of content. For example, if your server farm hosts applications for more than one class of users, separate SSPs can help create the secure isolation between these classes of users. Plan to use a separate SSP for each of the following types of applications:

•      Intranet   Intranet content includes team sites, My Sites, and published intranet content. This type of application is typically available only to users within your organization that have an account within your directory management system.

•      Partner Web   A partner Web application typically hosts site collections and sites for collaboration between both internal employees and partner users. Using a separate SSP ensures that partner users cannot search on or access sensitive information within your Intranet environment.

•      Customer Web site   A customer Web site that is available for anonymous users requires a dedicated SSP. The configuration of services within the SSP will be very different than those that are configured for other types of applications that you use for collaboration within your organization.

•      Records Center   There are typically legal issues involved concerning the privacy of information in records centers. Because of this, use a separate SSP to crawl this content so that these records do not appear in search queries that originate from other SSPs.

Because each additional SSP that you add decreases the overall performance of the server farm, carefully consider your needs for implementing more than one SSP.

The following deployment scenarios might require the use of two or more SSPs:

•      Deployments with legal requirements for content isolation, such as financial services organizations, or deployments with one or more confidential projects that require full content isolation. To achieve full content isolation, you must also crawl and index the content in a separate index. Note that each SSP supports one index.

•      Geographically distributed deployments with each location having a discrete set of users and content that is more easily managed separately in each region.

•      Hosted deployments with customers that do not share any content or data.

The advantages of using separate indexes include:

•      Isolating content indexes to increase security. For example, you might want to isolate highly sensitive content, such as content stored in a records center.

•      Scaling out when the capacity of one index server is insufficient.

•      Efficiently crawling geographically dispersed content. Note that we do not recommend attempting to crawl content over a slow link, because the content being crawled must be sent over that link. To crawl content over a geographically dispersed area, consider installing a separate server farm with its own SSP in each geographical area.

It is important to note that Office SharePoint Server 2007 does not provide a way to combine indexes. Instead, queries are automatically routed to the SSP associated with the Web application from which the end-user initiated the query.

Even though all content that is crawled using a particular SSP is indexed in a single index, a query does not necessarily return search results for all items in the index that match that particular query. Instead, other search features filter or modify content after it has been crawled. For more information about these features, see Plan the end-user search.

Whenever possible, use only one SSP to crawl all content for your organization. Typically, if content on a Web application that uses a separate SSP is relevant enough to be included in a content source for your SSP, the Web application should use the same SSP as the Web applications that are crawled using your SSP.

In some cases, you might want to include a subset of content in your organization from a Web application that uses a different SSP. We recommend that you carefully plan how related information is stored across site collections. You should also plan which SSPs are associated with the Web applications that contain those site collections. If you must crawl content on a Web application that uses a different SSP, ensure that the user account used to crawl the content (either the default content access account or a different content access account defined by a crawl rule) has read permission to the content. For more information about crawling content, see Plan to crawl.

Before you create multiple SSPs, consider using other means to isolate content:

•      Use SharePoint groups to limit permissions and authorization to the correct users and groups.

•      Use exclusive search scopes to prevent people from searching for certain content.

•      Use audiences to target content to specific groups of users.

•      Limit access to sites to specific users or groups. Some content on these sites will appear in search results.

Use multiple SSPs if all of the following criteria are met by your deployment:

•      Groups of users work on isolated projects, do not share personal information, do not have a business need to view sites for other projects, and do not collaborate across teams or projects.

•      The users have no business need to search for content, data, or metadata in other groups, and might have a compelling business reason to not view content or data.

Sharing content across multiple SSPs

Even with the full content isolation of multiple SSPs, it is possible to override that isolation in rare cases if it is necessary.

•      Content on sites using one SSP can be crawled by another SSP by adding the start address to an external content source.

•      Trusted My Site host locations can be used to enable users to view personalized information about users in other SSPs.

These practices add additional administration costs while compromising the advantages of multiple SSPs. Typically, they are only done during ongoing operations, such as when a user changes locations in a geographically distributed deployment, or when content is relevant across an organization with groups that are otherwise isolated. Good planning for deployment and careful use of multiple SSPs can reduce the necessity of these practices.

See Also

Plan for personalized content and sites

Plan search

Plan for business intelligence

Configure portal usage reporting (http://technet.microsoft.com/en-us/library/cc288189.aspx)

Sample project plan: Microsoft Office SharePoint Server 2007 deployment

Planning and deploying an enterprise Web site solution based on Microsoft Office SharePoint Server 2007 is a large-scale team project that encompasses multiple planning, deployment, and customization tasks. You can use Microsoft Office Project to help you plan your large scale projects, control the project work, schedules and finances, and keep project teams aligned. To help you envision the steps required to plan, deploy, and customize Office SharePoint Server 2007, you can download a sample Office SharePoint Server 2007 deployment project plan that was created by using Office Project 2007.

Note:

Because each Office SharePoint Server 2007 deployment is unique, you should use this project plan as a sample only.

You can download the sample project plan in either of two formats:

•      Sample project plan: Office SharePoint Server 2007 deployment (Office Project 2007 format) (http://go.microsoft.com/fwlink/?LinkId=101328&clcid=0x409)

•      Sample project plan: Office SharePoint Server 2007 deployment (Office Project 2003 format) (http://go.microsoft.com/fwlink/?LinkId=102043&clcid=0x409)

Sample template: SharePoint Products and Technologies governance plan

Governance is the set of roles, responsibilities, and processes that you put in place in an enterprise to guide the development and use of a solution based on SharePoint Products and Technologies. As part of your governance planning, you must identify the stakeholder teams and individuals who will compose the governance body that defines the scope and objectives of governance in your organization. The governance body should then determine the governance strategy for the organization, map out the policies that will implement the strategy, and determine how the strategy will be enforced across the organization.

This sample template is designed to help an enterprise's governance body record its decisions, including governance objectives, stakeholders, policies, support, and other elements of the governance plan.

Read this paper online at:

SharePoint Products and Technologies governance plan (http://go.microsoft.com/fwlink/?linkid=92333&clcid=0x409)

II. Plan governance

The articles in this chapter include:

•      What is governance?

•      Establishing and governing a SharePoint service

•      Implementing and governing information architecture

•      Governance features in Office SharePoint Server 2007

•      Sample code acceptance checklist for IT organizations

Plan governance

Governance is the set of policies, roles, responsibilities, and processes that you establish in your enterprise to guide, direct, and control how it uses technologies to accomplish business goals. Deploying Microsoft Office SharePoint Server 2007 in your enterprise provides rich new capabilities such as online collaboration, document management, business intelligence, and Web publishing. To strike the right balance between the needs of the users of Office SharePoint Server 2007 and the IT professionals who deploy and operate it, we recommend that you form a governing body that includes representatives of all stakeholders in the Office SharePoint Server  deployment. This body can then create and enforce rules that govern the use of Office SharePoint Server in the enterprise.

The articles in this chapter can help you determine the aspects of your Office SharePoint Server 2007 deployment to govern and include discussions of governance techniques. The articles include:

•      What is governance?

Defines governance and introduces two key areas to govern: the IT services that host Office SharePoint Server 2007, and the information architecture used in your portals and other Office SharePoint Server sites.

•      Establishing and governing a SharePoint service

Describes typical elements of an IT service that hosts Office SharePoint Server 2007, suggests key success factors in governing an Office SharePoint Server service, and provides an example of a three-tiered service.

•      Implementing and governing information architecture

Introduces the concept of information architecture, recommends how to govern information architecture, and presents a case study illustrating the benefit of effective information architecture to promote collaboration across an enterprise.

•      Governance features in Office SharePoint Server 2007

Reviews a set of Office SharePoint Server 2007 features that your organization can use to help govern your Office SharePoint Server service or your enterprise’s information architecture.

•      Sample code acceptance checklist for IT organizations

Provides a sample code acceptance checklist to help you ensure that the solutions that you deploy provide the intended benefits without exposing your enterprise to unnecessary risk. Use this list as a starting point for your own checklist to verify the quality of solutions that are submitted for deployment. Along with providing a check after a solution has been developed, your code acceptance checklist can make a good training tool.

The content in these topics is also available as a printable guide. To download the guide, see Downloadable book: Governance guide for Office SharePoint Server (http://technet.microsoft.com/en-us/library/cc718727.aspx.)

White paper: Chaos no more: Steps for building governance into Microsoft Office SharePoint Server 2007 (http://technet.microsoft.com/en-us/library/cc262879.aspx.)

White paper: SharePoint Products and Technologies governance checklist guide (http://technet.microsoft.com/en-us/library/cc261826.aspx.)

White paper: SharePoint Products and Technologies customization policy (http://technet.microsoft.com/en-us/library/cc263010.aspx.)

Sample template: SharePoint Products and Technologies governance plan

Governance Information for SharePoint Server 2007 (http://go.microsoft.com/fwlink/?LinkID=92729&clcid=0x409)

What is governance?

Governance is the set of policies, roles, responsibilities, and processes that you establish in an enterprise to guide, direct, and control how the organization uses technologies to accomplish business goals. Effective governance anticipates the needs and goals of both your organization's IT teams and its business divisions. Governance also provides policies and guidelines that make the deployment of products and technologies such as Microsoft Office SharePoint Server 2007 both manageable for IT and also effective as a business tool. Governance can help protect your enterprise from security threats or non-compliance liability. It can also help ensure the best return on your investment in technologies, such as by enforcing best practices in content management or information architecture.

Every organization has unique needs and goals that will affect its approach to governance. No single approach will fit the cultures or requirements of all organizations. For example, larger organizations will probably require more governance than smaller ones.

Because deploying Office SharePoint Server 2007 introduces new ways of sharing information, collaborating, and implementing business processes in your organization, there are unique considerations for governing Office SharePoint Server  that you may not have previously encountered. The content in these governance articles is provided to both promote the need for governance of Office SharePoint Server deployments and to provide example of the types of Office SharePoint Server activities and processes that your organization should consider governing.

In this article:

•      What should be governed?

•      Who should determine governance policies?

•      How should governance be implemented?

What should be governed?

Office SharePoint Server helps organizations gain control over their content, develop insights about their content, streamline their business processes, access information, and share information. For an Office SharePoint Server deployment to succeed, these organizational needs should be met in a way that is consistent with the constraints and policies of the organization's IT department. Governance is the method by which your enterprise balances these requirements. To keep solutions based on Office SharePoint Server both effective and manageable your organization should consider governing one or more of the following areas:

•      Information architecture

A key contributor to an enterprise's efficiency and effectiveness is how quickly and accurately its information workers can find and use content and data. Without properly designed and governed information architecture, an enterprise's effectiveness can be diminished. For example:

•      Inconsistent use of metadata can make it difficult to search for and compare related items of information.

•      Poorly designed and managed storage of content can cause a proliferation of duplicate versions of documents. As a result, users cannot identify the authoritative version.

•      Poorly cataloged and managed storage of data can cause decision-makers to use the wrong data.

•      Poorly designed portal navigation can make it difficult to find work-critical sites and information.

•      Poorly presented information can reduce the ability of some users to access the information.

Governing your enterprise's information architecture is a key to the successful use of Office SharePoint Server 2007 and requires the participation of business managers, content managers, information workers, site designers, and IT professionals.

•      IT Service hosting SharePoint Server

A common problem in an enterprise is the proliferation of individually managed Web servers running Windows SharePoint Services 3.0 or Office SharePoint Server 2007. Although it is inevitable that individual teams will drive the adoption of one or more SharePoint products and technologies, ungoverned adoption can cause problems. For example:

•      Each server can become an island of information, forming a patchwork of sites that lack a common search index, navigation, or security scheme.

•      Some servers may host applications that are insecure and that compromise the enterprise.

•      Poorly trained users may create requests for support on local servers that are unknown to the support team.

•      Critical activities like regulatory compliance may be administered inconsistently across servers.

•      Regular maintenance activities, such as backing up and restoring data and installing product updates, may not be done correctly because of poor training or because servers are not configured consistently.

•      Site owners may switch teams or leave the enterprise, making it unclear who owns content or causing sites to be locked.

The early adoption of Office SharePoint Server 2007 will often occur inconsistently in your enterprise as individuals or small teams deploy and start using it. As the use of the product in your enterprise increases, we recommend that your IT department plans and implements a set of well-governed hosting services that makes Office SharePoint Server 2007 available in a controlled way.

•      Customization policy

Office SharePoint Server 2007 includes customizable features and capabilities across multiple product areas, such as business intelligence, forms, workflow, and content management. However, customization introduces new risks to the stability, maintainability, and security of the Office SharePoint Server environment. To support customization in a controlled manner, develop a customization policy that addresses the following:

•      The customization tools that are allowed.

•      The method for handling source code, such as how it will be maintained in a source control system, how it should be documented, and so forth.

•      Development standards, such as coding best practices.

•      Testing and verification standards.

•      Required packaging and installing methods.

•      The types of customizations supported.

For more information on processes for managing customizations, see the white paper SharePoint Products and Technologies customization policy (http://go.microsoft.com/fwlink/?linkid=92311&clcid=0x409).

•      Branding

If you are designing an information architecture and set of sites for use across the enterprise, consider including branding in your governance policies. By implementing a branding policy, you help ensure that sites consistently use enterprise imagery, fonts, themes, and other design elements.

•      Training

Consider a training plan in your governance plans. Although Office SharePoint Server has an intuitive, Web-based interface and includes online help, using and especially administering sites based on Office SharePoint Server can be a challenge to some users. This can be further complicated by the set of capabilities available to various users based on their permissions levels. Additionally, the set of governance policies your IT and business divisions implement may require explanation. By properly training your user community, you can increase satisfaction with your SharePoint implementation and reduce support costs.

Who should determine governance policies?

A successful deployment of Office SharePoint Server must provide the functionality that the enterprise's business divisions require in a way that is manageable and sustainable by the enterprise's IT organization. It therefore requires an ongoing dialog and partnership between IT professionals, business managers, and information workers in the enterprise. To achieve this, effective governance of a deployment of Office SharePoint Server requires the participation of all of these stakeholders in a governance body.

Consider including the following roles when you create the body that will govern your enterprise's Office SharePoint Server services and information architecture:

•      Executive stakeholders Key executives should define the overall goals of the governance body, provide it with authority, and periodically evaluate the success of the implemented practices and policies.

•      Financial stakeholders The governance rules and processes should help increase the return on the enterprise’s investment in SharePoint products and technologies. To ensure this, financial officers should participate in the governance body.

•      IT leaders IT leaders must help develop their service offerings and determine how to achieve their IT responsibilities (such as providing security and maintaining reliability) while providing the features required by the business teams.

•      Business division leaders Business leaders represent the teams that do the primary work of the enterprise and drive the architectural and functional requirements of the Office SharePoint Server deployment. They should help determine the enterprise's information architecture and organizational taxonomy standards and work with the IT leaders to achieve service level agreements and other support policies.

•      Compliance officers Governance includes ensuring that an enterprise meets its regulatory and legal requirements and manages its corporate knowledge. If your enterprise has roles that are responsible for compliance or legal oversight, include representatives from those disciplines in your governance body.

•      Development leaders Leaders in your software development organization should help determine what customization tools should be allowed, how to verify code security, and other code-related best practices.

•      Information workers The members of your organization that do its day to day work should help ensure that the Office SharePoint Server services and information architecture meet their needs.

How should governance be implemented?

Every enterprise is unique and should determine the best way to implement its own governance plan. The following are suggested stages of a governance implementation for your enterprise to consider:

•      Determine initial principles and goals The governance body should initially develop a governance vision, policies, and standards that can be measured to track compliance and to quantify the benefit to the enterprise. For example, at this stage, the initial corporate metadata taxonomy could be determined along with the initial IT service offerings. The initial principles, goals, and standards should be published and publicized.

•      Develop an education strategy The governance policies that you determine must be publicized to your enterprise, and you should have ongoing education and training plans. Note that this includes training in the use of Office SharePoint Server and training in the governance standards and practices. For example, your IT department could maintain a frequently asked questions (FAQ) page on its Web site to respond to questions about its Office SharePoint Server service offerings. Your business division could provide online training that describes the implementation and use of the document management system in the enterprise.

•      Develop an ongoing plan Because successful governance should be ongoing, the governance body should meet regularly. Ongoing activities include incorporating new requirements in the governance plan or reevaluating and adjusting governing principles or standards. Conflicts may need to be resolved as competing needs arise, such as between your IT department and one or more business divisions. Your governance body should report regularly to its executive sponsors to promote accountability and to help enforce compliance across the enterprise. Keep in mind that, although this sounds laborious, the goal is to increase the return on your investment in Office SharePoint Server, maximize the usefulness of your Office SharePoint Server solution, and increase the productivity of your enterprise.

See Also

Governance features in Office SharePoint Server 2007

Governance Information for SharePoint Server 2007 (http://go.microsoft.com/fwlink/?LinkID=92729&clcid=0x409)

Establishing and governing a SharePoint service

When you develop an IT service to support Microsoft Office SharePoint Server 2007, a key to success is your enterprise’s ability to govern the service to ensure that it meets the business needs of your internal customers in a secure and cost-effective way. This article describes typical elements of an IT service that hosts Office SharePoint Server 2007, suggests key success factors in governing an Office SharePoint Server service, and provides an example of a three-tiered SharePoint service.

•      What is a SharePoint service?

•      Elements of a successful service

•      What to govern in a SharePoint service

•      Creating multiple services

What is a SharePoint service?

A SharePoint service is an IT service that offers hosted sites and portals based on SharePoint products and technologies. Among the things that a service provides are:

•      Sites and portals at a scope, such as site collection, Web application, or server farm

•      Backup and restoration

•      Content storage

•      Support for customizations

•      Security

•      Service levels that are based on speed and availability

Elements of a successful service

As you envision and implement your Office SharePoint Server service, consider the following elements that can contribute to the success of the governing effort:

•      Form and use a governing group

Your IT service that supports Office SharePoint Server should be governed by a group that includes executive stakeholders, business division leaders, influential information workers, IT managers, and IT technical specialists, among others. The goal of the governing group should be to oversee the service. In this capacity, the governing group defines the initial offerings of the service, defines the service's ongoing policies, and meets regularly to evaluate success.

•      Communicate about the services

The governance policies that you develop must be publicized to your enterprise. Maintain a Web site that describes the set of services.

•      Encourage use of the service

Discourage users from deploying their own servers and instead, encourage them to use the service. Isolated servers may not be configured in accordance with IT security policy and the enterprise’s regulatory requirements. Furthermore, users who deploy their own servers may fail to properly back up their servers or fail to keep servers up to date with software patches and updates. Finally, content on servers that are not governed by the service may not be crawled by the enterprise’s indexing service, which may create isolated pockets of content.

•      Create multiple services

You should offer a set of services that support Office SharePoint Server. For example, one service could provide thousands of sites for collaboration and another could support very large, mission-critical sites, such as enterprise portals. A set of Office SharePoint Server services enables you apply unique governance rules and policies at various levels of service. Another benefit of a range of services is that you can vary the cost that you assess to organizations based on their level of service. Lastly, a tiered service enables you to phase in services in a manageable way.

What to govern in a SharePoint service

As you design IT services that support Office SharePoint Server, your governing group should determine the limits and policies that control the following elements of your services:

•      Quota templates

A quota template consists of values that specify how much data can be stored in a site collection. The value also indicates the limit that triggers an e-mail alert to the site collection administrator. You can associate quotas with sites that are offered at various service levels to govern the growth of Office SharePoint Server in your enterprise. You can also set limits on the maximum size of uploaded files available per service level.

•      Self-service provisioning

You can enable users to create their own top-level Web sites by visiting an IT-hosted page and supplying data about the site’s intended usage. The site can then be provisioned based on a custom workflow. For various levels of service, you can govern the size of such sites and control their longevity.

•      Customization policy

A primary benefit of using sites that are based on Office SharePoint Server is the ability of site owners to customize them. For example, site owners might change a site's appearance or provide new functionality, such as a custom Web part or workflow. Carefully consider the amount of customization that is allowed and supported at each level of service, because some types of customizations are global to the server farm. For example, services that allow self-service site creation may include thousands of sites that share a single Web application. In this instance, you could limit customizations to only those supported by the user interface, such as adding Web parts to pages. In a service that provides virtual or physical isolation of the server farm, such as for an enterprise portal site, you might allow a large range of customizations, such as custom event handlers and workflows. For a full discussion of the range of customizations supported by Office SharePoint Server 2007 and the risks and benefits of supporting each type of customization at various levels of service, see the white paper SharePoint Products and Technologies customization policy (http://go.microsoft.com/fwlink/?linkid=92311&clcid=0x409).

•      Asset classification

You can develop and implement a classification system for sites and content supported by your service that identifies the value of the information to your organization. For example, using metadata, you could classify content as having high, moderate, or low business value. Each classification would then cause other behaviors – for example you could require that high value content be transferred only in encrypted form, or you could require that an approval process be run on medium impact content before it can be published on a public-facing Web site.

•      Lifecycle management

Your service should provide lifecycle guidelines or tools for active sites and unused sites. For lower service levels, you could, for example, implement a mechanism that lets only site owners create sites that last six months before the user would have to extend the request for the site. Also, you can implement a tool that looks for sites that have not been used for a specified period of time and deletes them. Lifecycle management also means integrating your service with the records management tools and processes in place in your organization. For more information, see Plan records management. See Governance and manageability tools on CodePlex (http://go.microsoft.com/fwlink/?LinkID=114564&clcid=0x409) for a set of governance and manageability samples and tools, including the “MS IT Lifecycle management tool,” designed to help IT professionals.

•      Branding and templates

A site template is a set of saved customizations on a site definition. (See Working with Site Templates and Definitions (http://go.microsoft.com/fwlink/?LinkId=119099&clcid=0x409) for more information.) You can choose which site templates to make available, especially for lower levels of your service, in which the owner cannot substantially customize the site. Use site templates to provide branding and other elements that identify the purpose of the site and associate it with your enterprise.

•      Data protection

Features that provide data protection include backup and recovery. You can vary the level of data protection you offer based on the service levels you provide (where higher levels may require charges to the site owner). For each level of service, plan the frequency at which you will back up sites and the response time you will guarantee for restoring sites. For more information, see Plan for data protection and recovery (http://technet.microsoft.com/en-us/library/cc263031.aspx).

•      Training

A well-trained user community provides benefits to IT. It reduces support calls, encourages adoption, helps ensure proper use of Office SharePoint Server, and helps users understand their responsibilities in using the Office SharePoint Server service. For each level of service, consider requiring the appropriate level of training. Even for a basic service, users with site administration privileges will have access to many features that affect the functionality of the site. Online training, such as tutorials, for these users can help them take the best advantage of their site.

Creating multiple services

Users of your enterprise’s Office SharePoint Server service will require sites that meet a range of purposes, such as:

•      Short-lived, single-purpose workspaces for planning events

•      Team sites for general collaboration

•      Divisional portals for large workgroups to manage their business processes

•      Enterprise portals to broadcast information and supply services to the entire organization

Consider dividing your Office SharePoint Server service into a set of services that meets the range of needs in your enterprise. Each user of a particular service would get the same level of support and would be charged a similar cost. As more complex or costly solutions are needed, you could add new services to support them. One benefit of this approach is that you can introduce one service at a time, which eases the burden on your IT staff. Work with executive stakeholders, business division leaders, and IT managers to determine the requirements of each level of service and the order in which services are introduced.

The following table illustrates a sample approach to creating a tiered set of services. In this example, three service levels are offered. Note that values provided are not recommendations but are supplied as samples:

Sample approach to a set of services

Basic Service

Advanced Service

Premium Service

Description

A server farm used to host tens of thousands of customer site collections.

It is intended to support short-lived sites along with small team sites.

A server farm that is designed to host a small number of portal sites.

It is applicable to customers with some requirements for server-side customizations that will not interfere with other sites hosted on the same servers.

A server farm dedicated to hosting a large, highly customized or highly critical site.

The topology is scalable depending on the agreed upon hosting requirements between the customer and the hosting team.

Example

Collaboration site to plan an event

Division portal including integration with line-of-business data and custom workflows

Enterprise portal that includes large-scale integration with multiple back-end systems

Scope

Site collection

Web application

Server farm with multiple Web applications

Customizations

Only customizations available in the user interface are supported.

Some server-side customizations are supported, such as custom site templates. All customizations are tested and reviewed before being accepted for deployment.

Extensive customizations are permitted. All customizations are tested and reviewed before being accepted for deployment.

Cost to user

None to minimal

Moderate

High

Self-service provisioning?

Yes

No

No

Content storage limits

500 MB

2 GB

Unlimited

Backup frequency

Twice weekly

Daily

Daily

Backups maintained for

14 days

30 days

60 days

Implementing and governing information architecture

By planning and governing your enterprise’s information architecture, you help ensure that your solution that is based on Microsoft Office SharePoint Server 2007 will meet your organizational needs. Effective information architecture makes it easy for users of your solution to find and store information and improves the quality of that information. This article:

•      Introduces the concept of information architecture

•      Points to available resources to help your organization’s information architects plan and implement your information architecture in Office SharePoint Server 2007

•      Recommends how to govern your Office SharePoint Server information architecture

•      Presents a case study that illustrates the benefit of effective information architecture to promote collaboration across an enterprise

In this article:

•      What is information architecture?

•         Resources for planning information architecture

•      Governing information architecture

•      Case study: Governing information architecture to eliminate content chaos

What is information architecture?

Information architecture in Office SharePoint Server is the organization of information in an enterprise — its documents, lists, Web sites, and Web pages — to maximize the information’s usability and manageability. Factors that contribute to the successful implementation of information architecture include:

•      How easy it is to find information

•      How information is stored and retrieved

•      How users navigate to information

•      How redundant or overlapping information is

•      What metadata is available for each type of information

•      What templates are used for creating information

•      How well the information architecture is governed

The goals and implementation of information architecture will vary depending on the type of solution you are creating. For example:

•      If you are designing the information architecture of an enterprise’s intranet portal site, you might focus on how metadata will be used to characterize the site’s content, the organization of the content in sites and document libraries, the availability of that content in portal sites, and the templates to use for creating content.

•      When you design the information architecture of an Internet presence Web site, you might focus on how the site is organized into a hierarchy of sub-sites and Web pages, how that hierarchy is exposed in the site’s navigation features, and how easy it is to search for content on the site.

Information architecture decisions may also affect the flow of information. For example, in an intranet portal site, information may initially be drafted in sites that are not available to most members of the organization. To make that information useful and actionable across the organization, the information architecture design could include methods and guidelines for promoting information to locations that are available to all users.

Depending on the size of your organization, you should consider including an information architect on your team who is responsible for designing and implementing your solution based on Office SharePoint Server. Information architects have expertise in structuring information in large Web environments such as intranet portal sites.

Resources for planning information architecture

The following table presents resources that are available to help information architects plan the information architecture of your Office SharePoint Server solution:

Information architecture resources

To plan …

See …

The structure of sites and subsites

•      Determine sites and subsites

Document libraries

•      Analyze document usage

•      Plan document libraries

•      Plan enterprise content storage

Navigation

•      Plan site navigation

Metadata

•      Plan content types

Content expiration

•      Plan information management policies

Records management

•      Plan records management

Moving content

•      Plan content deployment

•      Plan workflows

Templates

•      Working with site templates and definitions (http://go.microsoft.com/fwlink/?LinkID=119099&clcid=0x409)

Content approval

•      Plan versioning, content approval, and check-outs

Standardization across sites

•      SharePoint Cross-site Configurator (http://go.microsoft.com/fwlink/?LinkID=108592&clcid=0x409)

Information management policies

•      Plan information management policies

Governing information architecture

Information architecture in an enterprise should be governed. When you govern the architecture of information, you ensure the following conditions:

•      Information in the organization is manageable by the organization's information technology (IT) team by specifying how that information architecture is implemented and maintained.

•      Information architecture meets the regulatory requirements, privacy needs, and security goals of the enterprise.

•      Information architecture meets the organization’s business goals. Remember that poorly designed and governed information architecture can subtract from an organization’s effectiveness. Well designed and governed information architecture can multiply that organization’s effectiveness.

Governance of information architecture requires the participation of all groups that have a stake in its success. Because the ultimate purpose of information architecture is to meet the needs of the business, it is essential that representatives of the enterprise’s business units have a primary role in this governance group. If possible, include a professional information architect in your planning team and have that person participate in the governing group. Along with these primary stakeholders, representatives of the IT and legal organizations should be included. Depending on the type of enterprise, you may decide to include other participants. One key participant is the executive sponsor of the governing group. Although this person may not attend all sessions of the governing group, inclusion of this role is essential so that the governing group is kept accountable to its mission. Furthermore, the executive sponsor helps to ensure that benchmarks are used that help mark the progress of the ongoing effort of governing information architecture.

The best way to run the information architecture governing group will be based on the culture and methodologies of your enterprise. However, here are some general guidelines:

•      Meet regularly and allow enough time, especially in early sessions, to consider all the issues.

•      Exemplify good information architecture practices in your own deliberations, such as by using a well designed collaboration site to record your deliberations and maintain its artifacts.

•      Report to the wider organization (and gather requirements across the organization) by using a Web site and online surveys.

•      Maintain a set of milestones and a shared calendar.

•      Consider piloting information architecture practices in some divisions of the organization and using that experience to incrementally improve the information architecture practices across the wider organization.

Case study: Governing information architecture to eliminate content chaos

Fabrikam, Inc. is a world-wide manufacturer and exporter of automobile parts, including fuel and water pumps, shock absorbers, brake pads, and various engine parts. The company has 13,000 employees world-wide and more than fifty manufacturing plants across multiple geographical divisions. Fabrikam’s IT organization owns deployment, operations, and support of information technologies such as e-mail, file management, and Internet technology, along with development of information technology solutions, such as the corporate Web site.

Content at Fabrikam had historically been stored in shared file directories which were distributed across local file servers at the various locations of the company. This contributed to a chaotic content situation. Mass duplication of key content made it difficult to determine the “official” version of a file. Content metadata taxonomy was very limited, based on what the file system could support. Because divisions of the corporation created unique, custom templates for common documents such as work orders, sales proposals, or human resource documents, it was difficult to compare documents side by side across divisions.

As the inadequacies of their information architecture that was based on file shares became more evident, managers at Fabrikam mandated adoption of new, portal-based technologies. They did this to accomplish several goals:

•      Modernize their information architecture

•      Move content from file shares to libraries in portal sites

•      Provide central access to content and applications such as expense report submissions

•      Provide a home page for central communications to Fabrikam employees

The next step in the evolution of Fabrikam’s information architecture had begun.

The following diagram illustrates the initial architecture of the Fabrikam portal. A corporate portal at the top of the architecture provided a central location from which to broadcast general corporate information. At the next level, a few sites provided shared resources to the organization, such as human resources, legal services, and financial services.

Below the shared resources level in the Fabrikam architecture were divisional portals for the various regional offices of Fabrikam. Initially, North America, Europe, and East Asia were piloted. Gradually other divisional portals were added: Australia, Africa, and South America. Each divisional portal contained repositories for its policies, product designs, research and development, and customer data.

The result of the change from collaboration that is based on file shares to collaboration that is based on portals was disappointing to the sponsors of the portal effort and to the Fabrikam work force. “Content chaos” had not been alleviated. It had just moved from file shares to portal sites.

Because key functions at Fabrikam, such as materials purchasing, customer relationships, parts design and specification, and even some human resources processes, occurred at the divisional level, each division had developed local content to support these functions. Policy statements, parts blueprints and specifications, personnel documents, documents related to customer relationships, and similar content was created and managed locally. Templates and metadata schema for these documents diverged across divisional portals. As metadata became more specific to each division it became more difficult to search for content from one division to another. When a document was found across divisions, it was often copied to another division’s portal to make it more accessible. This process made it increasingly difficult to find the “official” version of a document as duplicates proliferated. Also, some documents in divisional portals were secured in such a way that employees of other divisions could not view them. Although this was appropriate when a document was being drafted, there was no guideline for when and how a document should be made viewable across the enterprise.

To address the growing discontent with the portal, a strategy team was formed, comprising managers across the various Fabrikam divisions along with core IT team members and portal architects. The team had the following tasks:

•      Evaluate the current state of the Office SharePoint Server portal deployment.

•      Recommend necessary changes to the portal.

•      Determine how to measure improvement over time.

The team that developed the portal strategy concluded that the current portal taxonomy’s “divisional” organization was the root to the problem. Each division was duplicating processes and hoarding content without taking advantage of the expertise and best practices developed in peer divisions. This contributed to poor collaboration, wasted resources, and content chaos. Their insight was to move towards a more “operational” organization for the enterprise portal. Shared resources such as information technology and finance were currently exposed in the portal taxonomy above (and visible to) all divisions. The team that developed the portal strategy concluded that other operational disciplines, such as customer relationships, vendor relationships, plant configuration, and research and design should be moved from divisional silos to the same level as the shared resources in the site’s hierarchy. Metadata instead of the content’s location would associate information with the various divisions.

The following illustration is the revised architecture of the Fabrikam portal:

Reorganizing the Fabrikam portal in this way had the additional benefit of forcing collaboration across parts of the enterprise that had similar responsibilities but were not accustomed to working together on standards and processes. For example, storing design files in a central repository forced the various divisions to standardize on a tool for designing automobile parts. This change saved money and reduced training time. Also, best practices in design were made available for engineers to view across the enterprise and to use as a basis for new design projects.

Here is a summary of the benefits of the redesigned portal architecture:

•      Provides central access to information.

•      Reduces duplication of content.

•      Makes the official version of each item of content evident.

•      Standardizes metadata.

•      Standardizes templates.

•      Fosters collaboration and sharing of best practices.

The redesign and reimplementation of the portal was just the start. The team that developed the portal strategy received executive sponsorship to become a governing group of the portal. As a result, the group represented the needs of portal users by developing policies and standards. This helped ensure accountability across the organization and provided a forum for evaluating and evolving the portal — both to improve portal features but also to help maximize the return on the enterprise’s investment in the Office SharePoint Server technology. The governance body oversaw the following elements:

•      Metadata standards

•      Template standards

•      Guidelines for when information needed to be made available across the enterprise

•      Compliance with corporate and governmental regulations

•      Training standards

•      Branding standards for content

Fabrikam started seeing a large return on their portal investment. A year into the project, the strategy team did an inventory of content and found that out of 500,000 documents, only 230 were duplicates. They identified millions of dollars in savings due to the centralization of efforts. And a survey of their employees showed a large increase in satisfaction with the portal. Collaboration was healthy at Fabrikam.

See Also

What is governance?

SharePoint Cross-site Configurator (http://go.microsoft.com/fwlink/?LinkID=108592&clcid=0x409)

Governance features in Office SharePoint Server 2007

This article reviews a set of Microsoft Office SharePoint Server 2007 features that your organization can use to help govern your Office SharePoint Server 2007 IT service or your enterprise’s information architecture. It also includes links to Web articles to help you plan and use each feature.

Note:

For information about how to organize your enterprise's governing body, see What is governance?

In this article:

•      IT service features

•      Information architecture features

IT service features

By offering an IT service that hosts SharePoint sites and by providing related services in the enterprise, your organization can more effectively control the proliferation of SharePoint sites, ensure cost-effectiveness, and maximize the benefits of collaboration. This section describes features in Office SharePoint Server 2007 that are useful in maintaining and governing an Office SharePoint Server service.

Site templates

Site templates are a set of customizations applied to a site definition. By using a site template, an Office SharePoint Server service can promote consistent branding, site structure, and layout in the sites that users create. You can create customized site templates for provisioning sites and use them instead of the templates that are included in Office SharePoint Server as part of your Office SharePoint Server service.

For more information, see Working with site templates and definitions (http://go.microsoft.com/fwlink/?LinkId=119281&clcid=0x409).

Quotas

A quota specifies limits to the amount of storage that a Web site can use. Quotas enable you to warn users when their sites approach their storage limit. This process prevents users from adding additional content when the limit is reached. For more information, see Manage site quotas and locks (http://technet.microsoft.com/en-us/library/cc263050.aspx).

Locks

Locks prevent users from either adding content to a site collection or using the site collection at all. For example, you may lock a site that violates of a usage policy. For more information, see Manage site quotas and locks (http://technet.microsoft.com/en-us/library/cc263050.aspx).

Workflows

Workflows are programs that implement business processes for users of a Office SharePoint Server site. They are associated with items in the site, such as documents, forms, or list items. Workflows have many applications as part of an IT service. For example, you can use a workflow to provision a new site, track a support issue, or take action when a site's quota is exceeded.

For more information, see Workflows in Windows SharePoint Services (http://go.microsoft.com/fwlink/?LinkId=119282&clcid=0x409) and Understanding workflow.

Features

A feature is a container for various defined extensions for Office SharePoint Server 2007 and Windows SharePoint Services 3.0, and is composed of a set of XML files that are deployed to Web servers. You can deploy a feature as a part of a site definition or a solution package, and you can individually activate a feature in Office SharePoint Server sites.

A site administrator can transform a SharePoint site's functionality by toggling a particular feature on or off in the user interface. Features make it easier to activate or deactivate functionality in the course of a deployment, and provide a means for administrators to easily transform the template or definition of a site. Features can be hidden, which prevents site users from manually deactivating them.

By having new site functionality implemented as features, you make it easier for administrators to control sites and enforce a governance plan. A technique named feature stapling enables you to attach a feature to all new instances of sites that use a given site definition without modifying the site definition. This lets you control the features that users of your service can access. For more information, see Feature Stapling (http://go.microsoft.com/fwlink/?LinkId=119283&clcid=0x409) and Working with features (http://go.microsoft.com/fwlink/?LinkID=105337&clcid=0x409).

Self-service site creation

You can enable users to create their own top-level Web sites by using the Self-Service Site Creation feature. Allowing workgroups to create and own unique site collections promotes better collaboration within the workgroups. Also, enabling self-service site creation frees IT resources for other tasks. A key decision in governing self-service site creation is to determine at which level of your service it is supported.

For more information, see Configure Self-Service Site Creation (http://technet.microsoft.com/en-us/library/cc261685.aspx.)

Records management

A record is a document or other electronic or physical entity in an organization that serves as evidence of an activity or transaction performed by the organization. Records require retention for some time period to meet legal, business, or regulatory requirements. Records management is the process by which an organization determines what types of information should be considered records, how records should be managed while they are active, and for how long each type of record should be retained. Records management includes the performance of records-related tasks such as disposing of expired records, or locating and protecting records related to external events such as lawsuits.

Office SharePoint Server 2007 includes features that can help organizations implement integrated records management systems and processes. To ensure that information workers can easily participate in your enterprise's records management system, 2007 Microsoft Office system applications, such as Microsoft Office Outlook 2007 and Microsoft Office Word 2007, also include features that support records management practices.

For more information, see Plan records management.

Information architecture features

A portal Web site's information architecture determines how the information in that site — its sites, Web pages, documents, lists, and data — is organized and presented. Your enterprise can increase the return on its portal investment by creating a governance body that develops and enforces information architecture standards and policies. A well-governed architecture makes information in the enterprise easier to find, share, and use.

This section describes Office SharePoint Server 2007 features that are useful when you implement your enterprise's information architecture and govern its usage.

Content types

Content types enable enterprises to organize, manage, and handle content in a consistent way. They define the attributes of a type of list item, document, or folder. Each content type can specify metadata properties to associate with items of its type, available workflows, templates, and information management policies. Use content types to encourage consistent information management policies, metadata requirements, and other policies. To govern content types, consider associating event receivers and workflows with the forms that are used to modify the content types. As a result, changes to a content type are validated and approved.

For more information, see Plan content types.

Content approval

Content approval is the method by which site members with approver permissions control the publication of content. A document draft awaiting content approval is in a pending state. When an approver reviews the document and approves the content, it becomes available for viewing by site users with read permissions. A document library owner can enable content approval for a document library or Web pages library and can optionally associate a workflow with the library to run the approval process.

Use content approval to formalize and control the process of making content available to an audience. For example, an enterprise that publishes content might require a legal review and approval before publishing the content.

For more information, see Plan versioning, content approval, and check-outs.

Versioning

Versioning is the method by which successive iterations of a document are numbered and saved in Office SharePoint Server. As a governance tool, versioning prevents users with read permissions from viewing drafts of documents.

For more information, see Plan versioning, content approval, and check-outs.

Site Content and Structure page

The Site Content and Structure page in the top-level site in a site collection manages the content and structure of a SharePoint site collection. Because site navigation in Office SharePoint Server is based by default on the hierarchy of sites and subsites, this feature can also be used to configure site navigation. When porting a Web site to Office SharePoint Server 2007, you can use the Site Content and Structure page to restructure the site to match your enterprise's needs.

For more information, see Work with site content and structure (http://go.microsoft.com/fwlink/?LinkId=107711&clcid=0x409).

Information management policies

An information management policy is a set of rules for a type of content, or for a location where content is stored, where each rule in a policy is a policy feature. For example, an information management policy feature could specify how long a type of content should be retained, or it could provide document auditing. Information management policies enable you to control who can access your organizational information, what they can do with it, and how long the information should be retained.

You can associate a policy with a list, document library, or content type. When you do this, any document associated with the library, or any document of the content type, includes the information management policy. The relationship between a document and its associated information management policy is maintained even when that document is opened in a 2007 Microsoft Office system client program. For example, if a policy prevents a document from being printed, that policy can be enforced even when the document is opened in a 2007 Office system client program.

When you configure an information management policy, you can optionally write a policy statement that is displayed in 2007 Office system client programs to inform document authors about the policies that are enforced on a document. This is a recommended best practice.

Office SharePoint Server 2007 includes the following information management policy features:

•      The Auditing policy feature logs events and operations that are performed on documents and list items. You can configure Auditing to log events such as editing documents, viewing them, or changing a document's permissions level.

•      The Expiration policy feature helps dispose of content in a consistent way that can be tracked and managed. You can set content of a specific type to expire on a particular date, or within a calculated amount of time after some document activity (such as creating the document). After the document expires, you can determine the actions that the policy control will take. For example, the policy can delete the document, or define a workflow task to have Office SharePoint Server route the document for permission to destroy it.

•      The Labeling policy feature specifies a label to associate with a type of document or list item. Labels are searchable text areas that Office SharePoint Server generates based on metadata properties and formatting that you specify.

•      The Barcode policy feature enables you to track a physical copy of a document. You create a unique identifier value for a document and then insert a barcode image of that value in the document. By default, barcodes are compliant with the common Code 39 standard (ANSI/AIM BC1-1995, Code 39), and you can use the object model of the policies to plug in other barcode providers.

To track how information management policies are being used in each Web application in your solution, you can use Office SharePoint Server Central Administration to configure information management policy usage reporting. Information management policy reports help you monitor how consistently your organization uses policies. Because information management policies are often implemented to help an organization comply with regulations, frequent monitoring of policy usage can help you ensure that your organization is compliant.

Information management policy features are extensible. For more information about how to create custom information management policy features, see the Microsoft Office SharePoint Server 2007 Software Development Kit (http://go.microsoft.com/fwlink/?LinkId=119284&clcid=0x409). For more general information about information management policies, see Plan information management policies.

Information rights management

Information Rights Management (IRM) enables content creators to control and protect their documents. The contents of documents that use IRM are encrypted and supplied with an issuance license that imposes restrictions on users.

Microsoft Office SharePoint Server 2007 supports IRM for documents that are stored in document libraries. File formats of documents that can use IRM in Office SharePoint Server 2007 include:

•         Microsoft InfoPath

•         Microsoft Word

•         Microsoft Excel

•         Microsoft PowerPoint

•         Word Open XML

•         Excel Open XML

•         PowerPoint Open XML

To add other file types, an administrator must install protectors — programs that control the encryption and decryption of documents that use rights management — for each new type of file.

For more information, see

Plan Information Rights Management.

Blocked file types

You can restrict files from being uploaded or downloaded to a server by basing the restriction on their file name extension. For example, you can block files that have the .exe extension, because such files can be run on the client computer and may contain malicious software.

By default, many file types are blocked, including file types treated as executable by Windows Explorer. For a complete list of the default blocked file types, see Manage blocked file types (http://technet.microsoft.com/en-us/library/cc262496.aspx).

Sample code acceptance checklist for IT organizations

Web sites that are based on Microsoft Office SharePoint Server 2007 often include custom solutions. The ability to customize sites by adding custom solutions gives Office SharePoint Server 2007 power and flexibility. However, a poorly designed or implemented executable module that runs in a SharePoint farm can do harm even beyond the scope of the Web application for which it was intended. Poorly implemented custom solutions can introduce security or performance risks, increase the cost of support, complicate deployment, and reduce productivity.

Because the impact of installing custom solutions in a SharePoint server farm can be either positive or negative, we recommend that you to carefully evaluate all custom solutions before deploying them in your production environment. Among the areas to evaluate are the following:

•      Was the solution developed, tested, and piloted consistently with the best practices described in Design and build sites for Office SharePoint Server 2007 (http://technet.microsoft.com/en-us/library/cc261852.aspx) and in white papers such as Implementing Microsoft Office SharePoint Server 2007 and Windows SharePoint Services 3.0 Solutions (http://go.microsoft.com/fwlink/?LinkId=114834&clcid=0x409)?

Along with requiring that the solution be developed in accordance with general best practices, we recommend that you have developers submit a checklist to verify that their solutions have been coded and tested according to best practices.

To help you ensure that the solutions that you deploy provide the intended benefits without exposing the enterprise to unnecessary risk, you can use the following sample code acceptance checklist. Use this list as a starting point for your own checklist to verify the quality of solutions that are submitted for deployment. Along with providing a check after a solution has been developed, your code acceptance checklist can make a good training tool. By providing developers with the list before they implement their customizations, you communicate your expectations of the quality of the solutions that they will develop and submit.

Important:

This sample checklist is for informational purposes only. It cannot be assumed that all code acceptance issues are covered in this checklist or that additional measures may not be required applicable for your organization. No warranty, either express or implied, is created by this checklist.

In this topic:

•      Resources for SharePoint development best practices

•      Code acceptance checklists

•      Printable version of the code acceptance checklist

Resources for SharePoint development best practices

This section contains a list of resources that you can provide to developers to help them design and implement solutions that meet your IT requirements for usability, supportability, performance, and security.

•      Microsoft Office SharePoint Server 2007 SDK (http://go.microsoft.com/fwlink/?LinkID=72208)

•      Windows SharePoint Services 3.0 SDK (http://go.microsoft.com/fwlink/?LinkID=113927)

•      Development Tools and Techniques for Working with Code in Windows SharePoint Services 3.0 (http://go.microsoft.com/fwlink/?LinkId=123413)

•      Working with ASP.Net 2.0 Web parts and WSS 3.0 (http://go.microsoft.com/fwlink/?LinkId=123429)

•      Best Practices: Common Coding Issues When Using the SharePoint Object Model  (http://go.microsoft.com/fwlink/?LinkId=123414)

•      Windows SharePoint Services Developer Center (http://go.microsoft.com/fwlink/?LinkId=123428)

•      MSDN Webcast: Essentials of Application Security (Part 1 of 3): Secure Communications (Level 200)  (http://go.microsoft.com/fwlink/?LinkId=123430)

•      SharePoint Server 2007 Developer Portal (http://go.microsoft.com/fwlink/?LinkID=119449)

•      Microsoft Anti-Cross Site Scripting Library V1.5 (http://go.microsoft.com/fwlink/?LinkId=123431)

•      Improving Web Application Security: Threats and Countermeasures (http://go.microsoft.com/fwlink/?LinkId=123432)

•      Exception Management Architecture Guide (http://go.microsoft.com/fwlink/?LinkId=123433)

•      SharePoint Products and Technologies White Paper: Implementing Microsoft Office SharePoint Server 2007 and Windows SharePoint Services 3.0 Solutions (http://go.microsoft.com/fwlink/?LinkId=114834)

•      How to programmatically test for canonicalization issues with ASP.NET (http://go.microsoft.com/fwlink/?LinkId=123434)

•      Validating ASP.NET server controls  (http://go.microsoft.com/fwlink/?LinkId=123435)

•      MSDN Webcast: Digging into Server-Side State Management (http://go.microsoft.com/fwlink/?LinkId=123436)

•      SharePoint Products and Technologies customization policy (http://go.microsoft.com/fwlink/?linkid=92311)

•      SharePoint Products and Technologies Customization Best Practices (http://go.microsoft.com/fwlink/?LinkID=123984)

Code acceptance checklist

This section organizes the code acceptance checklists by the following categories: security, session management, validation, sensitive data, exception handling, Web parts, documentation, general software development best practices. For a printable and modifiable version of the entire checklist, see Printable version of the code acceptance checklist.

Note:

Checklists that are supplied in this document are provided as a sample that you can use to develop your own code acceptance checklist based on the needs of your enterprise. Use it as a starting point to develop your own checklist.

Security

This section of the code acceptance checklist contains suggested items to help ensure that solutions that are submitted for deployment in a SharePoint environment have been developed by using best security practices.

[ ]

The application uses an inclusion list (known, valid, and safe input) rather than an exclusion list (rejecting known malicious or dangerous input).

[ ]

All user input is encoded with IOSec when displayed to clients.

[ ]

Character encoding is set by the server (ISO-8859-1 is recommended).

[ ]

Plain text passwords are not present in Web.config, Machine.config, or any files that contain configuration settings. Utilities such as Aspnet_setreg.exe and Trustee or the identity setting in AppPool on IIS 6.0 or IIS 7.0 are used to encrypt credentials.

[ ]

If cookies contain sensitive data, they are marked secure.

[ ]

Input surfaces in Web parts and other customizations include boundary checks, input data integrity checks, and appropriate exception handling to protect from cross-site scripting and SQL injection.

[ ]

The design addresses potential canonicalization issues.

[ ]

You avoid using AllowUnsafeUpdates. You use ValidateFormDigest() and, if necessary, use elevated privileges to interact with SharePoint objects. In cases where AllowUnsafeUpdates must be used, you ensure that AllowUnsafeUpdates is set to False in your try-catch-finally block, or you use a Dispose() method (as required by the IDisposable interface) to avoid security issues.

Session management

This section of the code acceptance checklist contains suggested items to help ensure that solutions that are submitted for deployment in your SharePoint environment have been developed by using best practices for managing sessions.

[ ]

Session state is strong, unpredictable, and protected from unauthorized access or replay attacks.

[ ]

Session lifetime is limited to 30 minutes maximum of inactivity.

[ ]

Session identifiers are not passed in the URL, and the ASP.NET feature, cookieless session, is not used.

[ ]

The session state service is disabled if not used.

Validation

This section of the code acceptance checklist contains suggested items to help ensure that solutions that are submitted for deployment in your SharePoint environment have been developed by using best practices for validating input .

[ ]

Input validation is applied at all identified entry points (including form fields, querystrings, cookies, HTTP headers, and Web service parameters).

[ ]

The ASP.NET validateRequest option is enabled, if possible.

[ ]

Data is validated for type, length, format, and range.

[ ]

Security does not rely on client-side validation. Instead, validation is performed on the server side.

[ ]

The application consistently uses standardized input validation such as RegEx throughout.

Sensitive data

This section of the code acceptance checklist contains suggested items to help ensure that solutions that are submitted for deployment in your SharePoint environment have been developed by using best practices for protecting sensitive data.

[ ]

The application does not log sensitive data in clear text.

[ ]

Sensitive data is not stored in cookies.

[ ]

Sensitive data is not stored in unencrypted, hidden form fields or query strings. It is maintained by using server-side state management.

[ ]

SSL, IPSEC with encryption, or application layer encryption prior to transmittal is used to protect sensitive data during transmission.

[ ]

Sensitive data is not cached. Output caching is off by default.

[ ]

Sensitive data that is transferred via e-mail uses S/MIME encryption or Information Rights Management  (IRM), depending upon the intended recipient.

Exception handling

This section of the code acceptance checklist contains suggested items to help ensure that solutions that are submitted for deployment in your SharePoint environment have been developed by using best practices for handling exceptions.

[ ]

The application uses a standardized approach to structured error and exception handling throughout.

[ ]

Error-handling code inherits from the SPException class to maintain a consistent SharePoint look and feel for errors.

[ ]

The application fails securely in the event of error and exceptions.

[ ]

Exception conditions do not allow a user to bypass security checks to run privileged code.

[ ]

The application returns generic custom error messages to the client.

[ ]

The code uses exception handling. The code catches only the exceptions that you know about. For example, do not use try{} catch(Exception ex){} unless you throw the error again.

[ ]

If code uses exception filters, it is not sensitive to filter execution sequence (filter runs before finally block).

[ ]

Application errors do not contain sensitive information or information that could be used to exploit the fault. .

Web parts

This section of the code acceptance checklist contains suggested items to help ensure that solutions that are submitted for deployment in your SharePoint environment have been developed by using best practices for developing Web parts.

[ ]

Custom Web parts (including resource files) are contained within a SharePoint Feature and are packaged as a SharePoint solution in order to be deployed.

[ ]

The configuration of Web parts that are being deployed gives the administrator the flexibility of deploying to the Web application level or lower.

[ ]

You use the SharePoint Web part infrastructure's standardized set of connection interfaces for Web parts to exchange information with each other at run time.

[ ]

Source code for third party Web parts solutions, whenever possible, is provided with adequate documentation to ensure good technical support.

[ ]

All custom Web parts utilize the SharePoint architecture to ensure consistent behavior across the application for functionality such as single sign-on, feature deployment, and so on.

Documentation

You should require adequate documentation to ensure that customizations that you are being asked to deploy are installable, supportable, and well tested. Furthermore, documentation indicates that all errors that are generated by the customizations are properly described and diagnosed. This section of the code acceptance checklist contains suggested items to help ensure that solutions that are submitted for deployment in your SharePoint environment have been developed using best practices for documentation.

[ ]

Customizations are accompanied by installation instructions that detail how to install and uninstall the package. Architecture diagrams that are related to the installation of the solution are included. If it is not possible to roll back a solution, this must be explained in the installation instructions so that you can discuss the risks and prepare a plan for a system recovery.

[ ]

Customizations are accompanied by test documents and results.

[ ]

Customizations are accompanied by a list of all dependencies. This could include account/passwords, Web services, databases, other solutions or Features, patches, tool sets or libraries, and other dependencies.

[ ]

A list of all event entries that are generated by the customizations and the actions to take are supplied. This can take the form of a table of error codes, where the severity and root cause of each code is supplied.

[ ]

Optionally, source code is provided to expedite validation and testing by the IT organization.

[ ]

Customizations that are an upgrade of previously deployed customizations are accompanied by documentation that describes the changes, considerations in upgrading the customizations, and rollback instructions.

General software development best practices

This section of the code acceptance checklist contains suggested items to help ensure that solutions that are submitted for deployment in your SharePoint environment have been developed by using best practices for software development.

[ ]

Assemblies have a strong name. (Dynamically generated ASP.NET Web page assemblies cannot currently have a strong name.)

[ ]

You use delay signing as a way to protect and restrict the private key that is used in the strong name and signing process.

[ ]

Assemblies include declarative security attributes (with SecurityAction.RequestMinimum) to specify minimum permission requirements.

[ ]

Highly privileged assemblies are separated from lower privileged assemblies.

[ ]

If an assembly is to be used in a partial-trust environment (for example, it is called from a partial-trust Web application), then privileged code is in a separate assembly.

[ ]

You rely on a native configuration file to support the application instead of changing the configuration to the Web.config.

[ ]

You use .NET Framework 2.0, 3.0, or 3.5.

[ ]

You use a single .NET Framework version. You do not mix multiple versions.

[ ]

Your code is 64 bit compatible.

[ ]

Your application does not try to directly access any SharePoint databases. Data stores in SharePoint databases are only updated by using the SharePoint object model.

[ ]

You avoid hard coding strings and labels. You use resources or language files instead.

[ ]

When referencing the SPWeb or SPSite objects, you employ a using statement or, alternatively, you use an explicit call of the .Dispose method to ensure proper use and disposing of the memory objects.

[ ]

You use caching as appropriate to reduce unnecessary round trips. For Web parts, you expose the cache expiration (duration) as a Web part property.

[ ]

When packaging your solution, you include a Code Access Security policy for the solution and, if necessary, include your assembly in the Safe Controls list though the solution.

[ ]

When logging code, you use the Portal Log class to log the SharePoint Unified Logging Service (ULS) logs.

[ ]

If you need to update multiple list items by using remote code, you use the Web service to update list items. You only use SPListItem.Update() if you have to update more than one item at a time by using local OM-based code.

[ ]

When using the Count property of a SPListItemCollection, you only call it once and then store it in a variable that you can refer to when looping. You do not call it inside a loop.

[ ]

The solution uses the AppSettings object to implement XML mapping. (This can be provided by using the settings persistence framework in .NET 2.0, 3.0, or 3.5.) The solution avoids creating custom XML files and a strongly typed object for XML mapping.

[ ]

Installation and deployment logging are provided in the event logs to enable appropriate operational troubleshooting during installation and uninstallation.

Printable version of the sample code acceptance checklist

For a printable version of the sample code checklist that you can edit, download the list as a Word 2007 document (.doc).

Sample code acceptance checklist for IT organizations (http://go.microsoft.com/fwlink/?LinkId=125134)

III. Plan Web site structure and publishing

The articles in this chapter include:

•      Determine the information architecture of your site

•      Determine sites and subsites

•      Plan site navigation

•      Plan Web pages

•      Plan Web page authoring

•      Plan variations

•      Plan content approval and scheduling

•      Plan content deployment

•      Plan for collaboration sites

•      Plan for multilingual sites

Plan Web site structure and publishing

Microsoft Office SharePoint Server 2007 includes features you can use to implement the structure, navigation, and appearance of Web sites and to control how your sites are authored, approved, and published. The articles in this chapter will guide you in planning your Web site's structure, authoring environment, and publishing environment.

The articles in this chapter include:

•      Determine the information architecture of your site suggests methods for surveying and recording the information requirements of your Web site. This is an important preliminary step in Web site planning.

•      Determine sites and subsites introduces Office SharePoint Server 2007 site collections, sites, and subsites, and recommends a method for planning and recording your site's structure.

•      Plan site navigation reviews the Office SharePoint Server 2007 navigation model and provides guidance about planning your site's navigational experience.

•      Plan Web pages first introduces the elements of Web pages: master pages, content pages, layout pages, style sheets, Web Parts, and server field controls. Next, this article provides guidance about how to plan each element of the Web pages in your publishing site.

•      Plan Web page authoring describes the two methods of authoring Web sites based on Office SharePoint Server 2007 — browser-based authoring and smart-client authoring — and it also describes how to plan and configure your Web site's authoring environment.

•         Plan variations describes how to plan and implement a set of Web sites that all derive from a source site, so that content can be tailored to suit different cultures, markets, or geographic regions.

•      Plan content approval and scheduling describes how to plan your team's method of approving content for publication and how to configure that content's publication schedule.

•      Plan content deployment describes how to plan the deployment of Web site content from an authoring or staging server environment to a production environment.

•      Plan for collaboration sites describes how to plan collaboration sites in your authoring or production environment to be available for teams or groups of users to collaborate on projects or to share information.

•      Plan for multilingual sites describes how to determine the multilingual needs of your Web sites and plan for multilingual site deployment.

•      White paper: Plan for building multilingual solutions (http://technet.microsoft.com/en-us/library/cc262942.aspx) describes how to use Office SharePoint Server 2007 in scenarios where content is managed across different languages.

•      White paper: Information architecture in Office SharePoint Server (http://technet.microsoft.com/en-us/library/cc262985.aspx) describes the process that a medium to large organization might undergo when deploying Office SharePoint Server 2007 in a practical scenario.

•      Downloadable book: Web Publishing and Planning Guide with Microsoft Office SharePoint Server (http://technet.microsoft.com/en-us/library/cc262535.aspx) describes features you can use to implement the structure, navigation, and appearance of Web sites and to control how your sites are authored, approved, and published.

Determine the information architecture of your site

In this article:

•      What is information architecture?

•      General planning recommendations

•      Using information architecture to plan the structure of your site

•      Using information architecture to plan for people and personalization

•      Using information architecture to plan for business data

•      Using information architecture to plan for search

What is information architecture?

A Web site's information architecture determines how the information in that site — its Web pages, documents, lists, and data — is organized and presented to the site's users. Information architecture is often recorded as a hierarchical list of site content, search keywords, data types, and other concepts.

Analyzing the information to be presented in an Internet or intranet Web site is an important early step in the site planning process, and this step provides the basis for planning:

•      How the site will be structured and divided into a set of subsites.

•      How data will be presented in the site.

•      How site users will navigate through the site.

•      How information will be targeted at specific audiences.

•      How search will be configured and optimized.

Although this article provides some guidance on how to analyze the information requirements of your Internet or intranet site, you will want to include an information architect or analyst on your site's planning and design team to ensure that your Web site plans fully take into account the information architecture needs of your organization.

General planning recommendations

It is useful to divide information analysis for Web site planning into the following stages:

•      Survey existing content and Web site structure   Your current Internet or intranet site reflects its current information architecture. Analyze and record how information and content are distributed across your current sites and subsites. Look at logs or other analysis tools to see what content is most and least frequently accessed.

•      Survey user requirements   Survey the current and intended site users and record the types of information they create or use. What information do they need in their daily work? Are they able to find that information easily? Does the current Web site structure help them understand the relationships among the different types of information the site contains? Is there missing information? Note any problems the users are having in finding or using information with the site's current architecture.

•      Survey business requirements   Survey the managers of the business unit or organization that the Web site is being designed for. What are the business needs of the site? Should the units or divisions of the business be reflected in the information architecture of the site? How will information be shared across business units or isolated within one unit? If the site is targeted at customers, what information should they first encounter? How will they explore information about products or services?

Use your analysis to create a detailed outline of your organization's content needs.

Using information architecture to plan the structure of your site

Your information architecture analysis will determine the structure of your Internet or intranet site. By dividing the information architecture into business processes, projects, or large content groupings, and by using those divisions to sketch out a hierarchy of subsites and content within each site, you can plan where information belongs within that hierarchy. For more information about planning the structure of Internet and intranet sites based on Microsoft Office SharePoint Server 2007, see Determine sites and subsites.

Using information architecture to plan for people and personalization

Your information architecture should include information about users. This information can come from Microsoft products and technologies, such as Microsoft® Exchange, the Active Directory® directory service, and Microsoft SQL Server™. It can also come from industry standard directories for tracking people, such as Lightweight Directory Access Protocol (LDAP), or from line-of-business applications.

Collecting user information will enable you to create unified and consistent user profiles across the organization. This will in turn help you in planning My Sites, which are special SharePoint® sites personalized for each user.

The people-related concepts recorded with your information architecture will also help you determine how to group site users based on the business processes they participate in, the distribution lists and social networks they belong to, the content they are likely to create or view, or the organizational structure in which they work. For more information about planning for people and personalization, see Plan for personalized content and sites.

Using information architecture to plan for business data

Your information architecture includes the business data your enterprise uses. By using Office SharePoint Server 2007, business data can be presented in the context of your site structure, so that it is available to those audiences that need it. For example, in an enterprise's intranet portal solution, employee payroll data — which must be available across the enterprise's divisional boundaries — could be presented in the central portal site for the enterprise.

Data that is used by a limited audience could be presented in the subsites or portals used by that particular audience. For example, a customer support team could view and interact with customer support incidents in a portal site used only by that team, and a sales team could view customer data in a portal dedicated to managing customer relationships.

Use your information analysis research to help you determine where the data in your existing business applications should be exposed in your enterprise's portals and Internet sites, so that it is available to site users who need it. For more information about business data planning, see Determine business data and business intelligence needs.

Using information architecture to plan for search

As you plan your information architecture, keep track of concepts, search terms, and properties that your site's users will use when searching for information on your site. You will want this data when creating the search schema for the site.

Keep in mind that users may search for content by using broad conceptual terms to describe what they need. Your information architecture survey will be useful as a tool to help map users' terminology and concepts to the underlying information they are looking for. For more information about search planning, see Plan search.

Download this book

This topic is included in the following downloadable book for easier reading and printing:

•      Web Publishing and Planning Guide with Microsoft Office SharePoint Server (http://go.microsoft.com/fwlink/?LinkID=92330)

See the full list of available books at Downloadable books for Office SharePoint Server 2007 (http://technet.microsoft.com/en-us/library/cc262788(TechNet.10).aspx).

See Also

Determine sites and subsites

Plan for personalized content and sites

Determine business data and business intelligence needs

Plan search

Determine sites and subsites

To determine the sites and subsites of your Internet or intranet site based on Microsoft Office SharePoint Server 2007, use your information architecture research (see Determine the information architecture of your site) to help plan one or more Office SharePoint Server 2007 site collections, each consisting of a top-level site and a set of subsites. This article introduces Office SharePoint Server 2007 site collections, sites, and subsites, and it recommends a method for recording your site structure decisions.

Note that we do not provide full guidance about how to map the results of your information architecture research to a particular site structure. However, the concepts and methods described in this article should help your design team members successfully convert their information architecture analysis into a useful solution based on Office SharePoint Server 2007.

In this article:

•      Planning site collections

•      Planning sites and subsites

•      Site templates included in Office SharePoint Server 2007

•      Recording your site structure decisions

Planning site collections

A site collection is a set of Web sites that has the same owner, shared administration settings, common navigation, and other common features and elements. Each site collection contains a top-level Web site and (usually) one or more subsites.

Grouping your Internet or intranet site's content and features into a site collection provides the following benefits:

•      For site designers, a site collection's galleries and libraries (such as the Master Page Gallery or the Site Collection Images library) provide a means for creating a unified, branded user experience across all of the site collection's subsites.

•      For site administrators, a site collection provides a unified mechanism and scope for administration. For example, site security, policies, and features can be managed for an entire site collection; site collection usage reports, audit log reports, and other data can help administrators track site security and performance.

•      For site authors, a site collection's shared content types, Web Parts, authoring resources, workflows, and other features provide a consistent authoring environment.

•      For site users, a site collection's unified navigation, branding, and search tools provide a unified Web site experience.

Below are some examples of solutions that benefit from being implemented as site collections:

•      Authoring and collaboration portal site   A site collection to support people in your organization who are working together to produce content useful for your organizational goals. Often, this type of portal site will include collaborative content that is not published but is only used internally, along with content intended for publication to an outside audience.

•      Publishing site   A site collection configured to let the content's audience view and interact with the site's content. Publishing sites are often implemented as two site collections — a production site collection that is the published site used by the content's audience and a staging site collection that is a mirror of the production site, used by the authoring team to view site content and test site features. For details on deploying content from a staging to a production site collection, see Plan content deployment.

•      Application portal sites   Portal sites that provide a Web-based view of business applications. Examples include:

•      Project Server portal site   A portal site in a large organization devoted to schedules and processes tracked in Microsoft Office Project Server 2007.

•      Microsoft Excel Web access portal site   A portal site that makes shared spreadsheets available to site users, and that often includes other business data made available by using the data connection library and the business data catalog.

•      Custom business application portal site   A portal site devoted to a business application used in your organization, such as a timecard reporting application.

Planning sites and subsites

A site collection consists of a top-level site and one or more subsites. Each subsite can be based on any Office SharePoint Server 2007 site template and can have other unique settings, along with unique content. Partition your site collection content into subsites to get finer control of the appearance, content, and features of the various pages in your site collection. The features of subsites that you can configure uniquely include:

•      Templates   A subsite can have a unique template. See Site templates included in Office SharePoint Server 2007, below, for details.

•      Security   You can define unique groups of users for a subsite. See Plan site and content security for details.

•      Navigation   To fine-tune your site's navigation experience, you can configure unique navigation links in each part of your site's hierarchy. Site navigation primarily reflects the relationships among the sites and subsites in a site collection. Therefore, planning navigation and planning sites and subsites are closely related activities. See Plan site navigation

for details.

•      Web pages   Each subsite can have a unique Welcome page and other pages. See Plan Web pages for details.

•      Site layouts   You can make unique layouts or master pages available in a subsite. See Plan Web pages for details.

•      Search   A subsite can have unique search settings. For example, you can specify that a particular subsite never appears in search results. See Plan search for more information about search planning.

•      Content types   A subsite can have unique content types. See Plan content types for details.

•      Workflows   A subsite can have unique workflows. See Plan workflows for details.

Site templates included in Office SharePoint Server 2007

Use the information in this section to help you identify which Office SharePoint Server 2007 site template to use for each site in your Office SharePoint Server 2007 solution. Although you can use a Office SharePoint Server 2007 template as it is initially configured, you can also modify any template's default settings by using the Office SharePoint Server 2007 site administration pages. In addition, you can modify a template's design and features by using Microsoft Office SharePoint Designer 2007 or Microsoft Visual Studio®.

The table below lists each template included in Office SharePoint Server 2007 and describes its purpose and general category. The categories are:

•      Publishing   Sites for presenting information to an audience. These templates include features that support creating and publishing pages based on page layouts.

•      Enterprise   Sites that provide features of use in the enterprise, either because of their scale or because they provide features commonly used in large organizations.

•      Meetings   Sites that provide features to support planning and running meetings.

•      Collaboration   Sites to support teams collaborating and disseminating information.

Template

Purpose

Category

Collaboration Portal

A starter site hierarchy for an intranet divisional portal. It includes a home page, a News site, a Site Directory, a Document Center, and a Search Center with Tabs. Typically, this site has an equal number of contributors and readers. Collaboration portals often include subsites based on templates in the Collaboration category.

Publishing

Publishing Portal

A starter site hierarchy for an Internet-facing site or a large intranet portal. This site can be customized easily to supply distinctive branding. It includes a home page, a sample press releases subsite, a Search Center, and a login page. Typically, this site has many more readers than contributors.

This site enables content approval workflows by default for a more formal and controlled publishing process. It also restricts the rights of anonymous users to only be able to see content pages, but not to be able to view Office SharePoint Server 2007 application pages.

Publishing

Document Center

A site to centrally manage documents in your enterprise.

Enterprise

Records Center

A site designed for records management. Records managers can configure the routing table to direct incoming files to specific locations. The site prevents records from being modified after they are added to it.

Enterprise

Site Directory

A site for listing and categorizing other sites in your organization.

Enterprise

Search Center

A site for delivering the Office SharePoint Server 2007 search experience. The site includes pages for search results and advanced searches.

Enterprise

Search Center with Tabs

A site for delivering the search experience. The welcome page includes a search box with two tabs: one for general searches, and another for searches for information about people. You can add and customize tabs to focus on other search scopes or result types.

Enterprise

My Site Host

A site used for hosting personal sites. The home page will always redirect to the user's My Site.

Enterprise

Basic Meeting Workspace

A site to plan, organize, and capture the results of a meeting. It provides lists for managing the agenda, meeting attendees, and documents.

Meeting

Blank Meeting Workspace

A blank meeting site for you to customize based on your requirements.

Meeting

Decision Meeting Workspace

A site for meetings that track status or make decisions. It provides lists for creating tasks, storing documents, and recording decisions.

Meeting

Social Meeting Workspace

A site to plan social occasions.

Meeting

Multipage Meeting Workspace

A site to plan a meeting, and to capture the meeting's decisions and other results. It provides lists for managing the meeting agenda and attendees, along with two blank pages for you to customize based on your requirements.

Meeting

Team Site

A site for a team to quickly organize, author, and share information. It provides a document library and lists for managing announcements, calendar items, tasks, and discussions.

Collaboration

Blank Site

A blank site for you to customize based on your requirements.

Collaboration

Document Workspace

A site for colleagues to work together on a document. It provides a document library for storing the primary document and supporting files, a tasks list for assigning to-do items, and a links list to point to resources related to the document.

Collaboration

Wiki Site

A site for a community to brainstorm and share ideas. It provides Web pages that can be quickly edited to record information and then linked together through keywords.

Collaboration

Blog Site

A site for a person or team to post ideas, observations, and expertise that site visitors can comment on.

Collaboration

The following section provides more details about the publishing site templates.

Comparison of the publishing templates

Most solutions based on Office SharePoint Server 2007 will include one or more site collections based on a publishing template. The table below lists additional information to help you understand and evaluate the two main publishing site templates: Collaboration Portal, for intranet divisional or team portal sites and Publishing Portal, for Internet presence sites or large enterprise portal sites.

Element

Collaboration Portal

Publishing Portal

Initial structure

A top-level site and four subsites, including a Document Center site, a News site, a Search site, and a Site Directory site.

A top-level site and two subsites, including a Press Releases site and a Search site.

Publishing via workflow?

No

Yes

Master page

Default.master

BlueBand.master

Top-level site default layout page

defaultlayout.aspx

WelcomeSplash.aspx

Search visibility?

Yes

Yes

Site collection features

Collect Signatures Workflow, Disposition Approval Workflow, Office SharePoint Server Publishing Infrastructure, Office SharePoint Server Standard Site Collection Features, Reporting, Routing Workflows, Translation Management Workflow

Collect Signatures Workflow, Disposition Approval Workflow, Office SharePoint Server Publishing Infrastructure, Routing Workflows, Translation Management Workflow

Top-level site features

Office SharePoint Server Publishing, Office SharePoint Server Standard Site Features, Team Collaboration Lists, Translation Management Library

Office SharePoint Server Publishing

Anonymous and Restricted Readers rights

Same as Reader.

Anonymous users and Restricted Readers cannot see Office SharePoint Server 2007 application pages, they can only see content pages.

Recording your site structure decisions

For each site collection in your solution based on Office SharePoint Server 2007, use a spreadsheet program such as Microsoft Office Excel 2007 to record your site and subsite planning decisions. Enter each site on a separate row of the spreadsheet. If you have multiple site collections in your solution, use a separate worksheet for each site collection.

The map that you create of your sites and subsites will provide essential data to use in your subsequent planning activities, such as planning site navigation, site features, and site security. Here are some recommended columns of information to record for each row in your sites and subsites spreadsheet:

•      Parent Site   The site directly above the current site in the site collection's hierarchy. For example, in sites based on the Collaboration Portal, the top-level site is the parent site of the Document Center site.

•      Purpose   The purpose of the current site. For example, for a site based on the Document Center site template, "a site to store product specifications and related marketing materials."

•      Template   The site template to use when creating the site, such as "Record Center."

•      Primary Audience   The group of users the site is primarily intended for, such as "product development group."

•      Site Owner   The individual or team responsible for administering the site. For example, for a site based on the Record Center site template, the site owner could be "Corporate Legal Department IT."

As needed, add other columns unique to your solution's goals. Then, as you plan your site structure, record your decisions in your sites and subsites spreadsheet.

Download this book

This topic is included in the following downloadable book for easier reading and printing:

•      Web Publishing and Planning Guide with Microsoft Office SharePoint Server (http://go.microsoft.com/fwlink/?LinkID=92330.)

See the full list of available books at Downloadable books for Office SharePoint Server 2007 (http://technet.microsoft.com/en-us/library/cc262788(TechNet.10).aspx.)

See Also

Determine the information architecture of your site

XII.  Plan site and content security

Plan site navigation

Plan site navigation

In this article:

•      Review of Office SharePoint Server navigation controls

•      Planning navigation

Site navigation provides the primary interface for site users to move about the sites, subsites, and pages that compose your Internet or intranet portal site. Microsoft Office SharePoint Server 2007 includes a set of customizable and extensible navigation features that help orient users of your Internet or intranet portal site and enable them to move among its sites and pages.

Office SharePoint Server 2007 bases its navigation model on the hierarchical structure of the site collection. By using the navigation features, you can link to the following:

•      A site's subsites

•      A site's peer sites

•      Sites higher in the site structure

•      Web pages in a site

Additionally, you can create links to arbitrary locations, such as to an external Web site.

Navigation links in Office SharePoint Server 2007 are security-sensitive. If a site user does not have permissions to a site or page that is linked from the site navigation, the user will not see the link. Also, pages and subsites can be configured to be available only to members of an audience. Users who are not members of that audience will not see links to sites and pages targeted at that audience.

As described in Plan Web pages , pages in sites based on Office SharePoint Server 2007 are composed of three elements: master pages, layout pages, and page content. In planning your portal's navigation, you make decisions about all of these elements:

•      You configure global portal navigation elements, and site-level (current) navigation elements on master pages.

•      You can add navigation elements that provide tables of contents, dynamic access to content based on a query, or authored links to layout pages.

•      You can allow tables of contents, dynamic access to content based on a query, or authored links in page content. Note that letting authors add navigation elements to page content lessens site designers' control of a portal's navigation experience.

•      Additionally, you can use breadcrumbs to display a set of links that show the site hierarchy starting from the current page up to the top-level site in the portal.

Office SharePoint Server 2007 navigation is based on the Microsoft ASP.NET 2.0 model which enables you to customize:

•      The site map provider.

•      The data source (which anchors and filters the structure provided by the site map provider).

•      The menus (which control the visual appearance of the navigation elements and how deep a hierarchy to show).

Review of Office SharePoint Server navigation controls

Navigation controls can be displayed on master pages, layout pages, and—by using Web Part zones—directly in a page's content.

Navigation controls on master pages

A master page defines the outer frame of the Web page in an Internet or intranet portal site. Master pages contain the elements that you want all pages in your site to share, such as branding information, common commands such as Search, and navigation elements that you want to be available throughout the site. This includes global navigation, which is typically constant throughout the portal, and current navigation, which is typically relative to the site that the user is currently viewing.

Master pages also provide the menu style of the navigation controls. You can configure master page menu style by using Microsoft Office SharePoint Designer or Microsoft Visual Studio.

Global navigation

Global navigation, which appears as "top link bars" in default site templates, typically links to the primary sites in a portal site. It is common for the global navigation to appear at the top of each page in a portal site. To give users the flexibility to switch from one primary site to another from anywhere within the portal site, the global navigation usually stays constant in all of the portal's sites and subsites. For example, an Internet portal site that is used to market an enterprise's products could have a subsite for each line of its products. By exposing each product's subsite in the portal site's global navigation, site designers can enable users to easily switch from one subsite to another without having to return to the portal site home page.

By default, all subsites one level below the top-level site of a portal site are added to the global navigation. Site administrators can remove a site from the global navigation by using the Site Navigation Settings page, and they can configure global navigation so that no subsites are displayed (that is, only the home page link is shown). Other global navigation configuration features include:

•      Linking to all of the top level site's Web pages.

•      Linking to specified external sites.

•      Linking to specified sites or pages that are anywhere in the portal site.

•      Organizing links under headings.

•      Manually sorting the items on the global navigation bar.

In a portal site, a subsite's owners can override the global navigation settings of the top-level site and define different global navigation settings for their subsite and the sites below it. All global navigation features, such as linking to external sites and organizing links below headings, can be defined uniquely in a subsite.

By using Office SharePoint Designer or Microsoft Visual Studio 2005, you can further customize the appearance and functionality of global navigation. For example, you can:

•      Customize the cascading style sheets to change the appearance of global navigation.

•      Modify the data source, for example to trim the number of sites shown in global navigation.

•      Modify the menu style of the navigation. For example, you can select fly-out menus or specify how many levels of the site hierarchy to show in navigation.

Current navigation

Current navigation, which is called the Quick Launch in default site templates, typically highlights the important content in the current site and links to related sites. It is common for current navigation to appear on the left of each page in a portal site.

By default, current navigation shows a site's pages and its sibling sites (that is, the sites that share the same parent site). This enables users to explore the content of the current site or move to a site on the same level in the site hierarchy. Portal site administrators can configure current navigation to inherit its navigation items from its parent site. Other current navigation configuration features include:

•      Linking to sibling sites.

•      Linking to all pages in the current site.

•      Linking to specific external sites or to pages in the current site.

•      Organizing links under headings.

•      Manually sorting the items in the current navigation.

As with global navigation, you can further customize the appearance and functionality of current navigation by using Office SharePoint Designer or Microsoft Visual Studio 2005.

Breadcrumb navigation

Breadcrumb navigation displays a dynamically generated set of links at the top of Web pages, to show users their current position in the site hierarchy. Most master pages have a single breadcrumb navigation control. By using Office SharePoint Designer or Microsoft Visual Studio, you can configure the breadcrumb navigation control. For example, you can specify a custom navigation provider, and you can remove breadcrumb navigation from a layout page.

Note:

The default.master master page, which displays form and view pages, includes two breadcrumb controls, a global breadcrumb which contains sites only, and a content breadcrumb, which contains sites and the current page. Some collaboration site templates, such as the Team Site template, also include two breadcrumbs on all Web pages.

Navigation controls on layout pages

A layout page defines a layout for a Web page by providing Microsoft ASP.NET controls in which the contents of pages are displayed. To customize layout page, use Microsoft Office SharePoint Designer 2007 or Microsoft Visual Studio. You can add navigation controls to a layout page to support navigation links in Web pages.

When a navigation control is inserted on a layout page, Web pages that use that layout page will display the control along with the page's contents. For example, you can define a layout page that includes a Summary Links navigation control (see below) so that a set of links to relevant pages and sites always appears when a page is displayed.

Office SharePoint Server 2007 includes the following navigation controls that can be added to layout pages:

•      Summary Links

•      Table of Contents

•      Content Query

Summary Links

The Summary Links control provides a way to add a set of links to a page. You can control the appearance, organization, and presentation of the links that you add to a Summary Link control.

You can add a Summary Link control to a layout page in three ways:

•      You can add it directly to the layout page and configure the links. When you do this, any page that uses the layout page will display the links.

•      You can add it as a field control on the layout page. When you do this, you can optionally configure the links, and you can optionally allow authors to modify the links and add new ones.

•      You can add it as a Web Part to a Web Part zone. When you do this, authors can modify the links, add news ones, and delete the Summary Link control.

For example, in a portal site in which you publish topics from a technical support knowledge base, you can add a Summary Link field control to the layout pages used for articles, to provide links to related sites containing relevant information, and you can permit authors to add links. This enables authors add links to content that is related to a page's content. For more information about configuring Summary Link controls, see the Office SharePoint Server 2007 online Help.

Table of Contents

The Table of Contents control provides a way to add a table of contents of all or part of your portal site to a layout page, so that pages using that layout include the table of contents. It uses the same navigation provider as the global and current navigation in the site's master pages. When you add a Table of Contents control to a layout page, you specify which part of your site collection the control should expose, how the links are presented, and how they are organized.

You can add a Table of Contents control to a layout page in two ways:

•      You can add it directly to the layout page and configure it. When you do this, any page that uses the layout page will display the table of contents.

•      You can add it as a Web Part to a Web Part zone. When you do this, authors can modify the scope of the Table of Contents control or it.

For example, if you are presenting a set of articles in an online news site, you can add a Table of Content control directly to the article pages' layout so that users can switch from one article to another from any article page. For more information about configuring Table of Contents controls, see the Office SharePoint Server 2007 online Help.

Content Query

You can use a Content Query control to link to pages or other items that are displayed based on a query that you design. For example, if you are presenting articles in an online news site, you could add a Content Query control to your site's Welcome Page layout so that new articles are highlighted on that page. You can build complex queries by using the Content Query field control. For example, you can specify which sites in your site collection to query, which lists to use, and what audience to target. You can also filter queries based on lists or libraries metadata.

You can add a Content Query control to a layout page in two ways:

•      You can add it directly to the layout page and configure it. When you do this, any page that uses the layout page will display the results of the query.

•      You can add it as a Web Part to a Web Part zone. When you do this, authors can modify the query or delete the Content Query control.

For more information about configuring Content Query controls, see the Office SharePoint Server 2007 online Help.

Navigation Web Parts

A Web Part is a control that authors can insert into a Web Part zone on a page and configure. The Summary Links, Table of Contents, and Content Query controls each have Web Part counterparts that page authors can insert into Web Part zones on pages. The Web Parts have the same configuration features and the same functionality as their related controls, but are configurable when the writer inserts them on the page rather than when the site designer inserts them on the page's layout. To make navigation Web Parts available for page authors to insert on a page, you must include one or more Web Part zones on the page's layout page.

If you allow authors to insert navigation Web Parts onto pages, you reduce the control you have over your portal site's navigation because authors can then control part of the navigation experience of site users. This might be appropriate in a loosely controlled environment such as a collaboration site within an organization, where individual authors need the ability to point users to content related to the author's work. It is less appropriate in a more tightly controlled environment such as an Internet presence site, in which the navigation experience is planned and implemented in a consistent, controlled way by the site's designers and planners.

Note:

If you want to include Web Part zones on layout pages but prevent authors from inserting navigation Web Parts into these zones, you can change the permissions required to use navigation Web Parts in your site's Web Parts gallery to make those Web Parts unavailable to authors based on their permission level.

Planning navigation

Navigation planning includes planning the user experience you want to create in your Internet or intranet portal site and deciding whether or not authors will be able to insert navigation elements directly onto their pages.

Planning the user experience

Your navigation decisions are closely related to your decisions about the structure of sites and subsites in your site hierarchy. For each site in your site hierarchy, you can choose to inherit the global or current navigation from its parent site, or you can plan unique settings. To help record your decisions, use the same spreadsheet that you used to record you site and subsite decisions in the topic Determine sites and subsites.

The site structure worksheet should include a row for each site in your site hierarchy. In the worksheet, record the following additional columns of information for each site and subsite:

•      Global navigation Record whether the site has unique global navigation settings or inherits its global navigation from its parent. If the site has unique global navigation, specify which subsites and additional sites to display.

•      Current navigation Record whether the site has unique current navigation settings or inherits its current navigation from its parent. If the site has unique current navigation, specify whether to display its subsites, its peer sites, or additional sites. Also specify whether to include links to the site's Web pages.

The decisions you make about your portal site's navigation will reflect its unique purpose and structure. When you plan navigation, consider the tradeoff between having too many navigation links, which could make your site confusing, and having too few, which could make it hard for site users to locate critical information. Also, keep the following in mind:

•      Inheriting the parent site's navigation can place the current site in a larger context. In an intranet site, this can help information workers use the other sites in the site collection to accomplish their tasks. On the other hand, if users of a site do not have to go to other sites to complete their tasks, consider defining a unique global navigation at the site so that site users are not distracted by irrelevant global navigation links. For example, records managers using a Records Center site might not need to go outside of the Records Center to accomplish their tasks, and so would not benefit from a set of inherited global navigation links.

•      Showing peer sites on the current navigation can imply that the peer sites have a similar purpose as the current site. For example, in an Internet site that markets a set of products, this can help site users go to descriptions of related products and services. On the other hand, if users of a site are not likely to want to visit peer sites, consider not displaying them in the current navigation. For example, a university's Internet site with subsites for each graduate school could omit peer links from each site's current navigation because students interested in a particular discipline, such as medicine, are unlikely to want to visit sites related to other disciplines.

Planning navigation on pages

You can add navigation field controls to layout pages. You can also add Web Part zones to layout pages and allow authors to add navigation Web Parts to these zones. As with other page element planning decisions, you should plan navigation on pages based on how much control you want to have over the page-viewing experience:

•      To tightly control site navigation, you can put navigation field controls directly on layout pages and eliminate Web Part zones from page layouts, or restrict the use of navigation Web Parts in those zones. For example, in a corporate Internet presence site with millions of site users, you might decide to restrict authors from inserting navigation controls.

•      To allow a more varied, albeit less consistent, site navigation, you can put Web Part zones on layout pages and allow authors to insert navigation Web Parts onto their pages. For example, in an intranet portal site in which authors and site users are part of the same workgroup, you might decide to let authors control the navigation experience of their content by adding navigation Web Parts to their pages.

You should plan navigation on pages as part of your general Web page planning. The topic Plan Web pages  includes worksheets in which you can record your page navigation decisions for each type of page layout in your portal.

Download this book

This topic is included in the following downloadable book for easier reading and printing:

•      Web Publishing and Planning Guide with Microsoft Office SharePoint Server (http://go.microsoft.com/fwlink/?LinkID=92330.)

See the full list of available books at Downloadable books for Office SharePoint Server 2007 (http://technet.microsoft.com/en-us/library/cc262788(TechNet.10).aspx.)

See Also

Plan Web pages

Determine sites and subsites

Plan Web pages

In this article:

•      Elements of Web pages

•      Planning master pages

•      Planning content pages

•      Planning page layouts

•      Using layout pages to restrict authoring

Planning Web pages includes designing the appearance of your published content, determining where writers can add content on pages, and controlling which authoring features writers can use. An effective plan for Web pages helps to ensure that each type of content that your organization will publish is properly designed and available to achieve your publishing goals.

To help you understand your design options, this article first introduces the elements of pages: master pages, content pages, layout pages, style sheets, Web Parts, and server field controls. Next, this article provides guidance on how to plan each element of the Web pages in your publishing site. Because the design and configuration of layout pages helps restrict what authors can do on Web pages, this article includes guidance about using layout pages to restrict authoring.

Elements of Web pages

When a Microsoft Office SharePoint Server 2007 site user opens a Web page in a SharePoint site, that page is rendered based on a set of elements that have each been planned and designed separately in the Web site. Separating elements of a page in this way allows site planners and designers to treat different elements of the site in unique ways. For example, a site's branding and navigation can be planned and designed separately from the design of the site's content pages, so that the branding can be applied across all site content and can be updated in one place. Similarly, layout of pages can be designed separately from page content, allowing the same content to be displayed in different ways as appropriate.

A Web page based on Office SharePoint Server 2007 is an ASPX page that is dynamically rendered out of its constituent parts. The parts of the page are illustrated below:

The following elements compose a Web page on a SharePoint site:

•      Master page   Defines the outer frame of the Web page. A master page contains the elements that you want all pages in your site to share, and it provides a single place to control all of those elements. Typically, a site uses a single site master page, although large Internet sites might use more. For example, a corporate Web site that is used to publicize more than one product could use separate master pages so that the content for each product is properly branded.

Note:

There are two types of master pages: site master pages and system master pages. The site master page is used on published Web pages in your site. It is the master page that site users and visitors see when viewing published pages. The system master page supplies the layout of pages in the site used by site designers and authors when interacting with the site's user interface and is also used in some team site templates, such as the Wiki Site and the Document Workspace site templates. This article primarily describes planning considerations for site master pages.

Master pages for all sites in a site collection are stored in the Master Page Gallery in the top-level site in the site collection. Because the Master Page Gallery is a SharePoint library, master pages have all the features of documents in Office SharePoint Server 2007, such as versioning, auditing, workflow, check-in and check-out, and content approval.

Typically, master pages include the following elements:

•      Branding elements, such as corporate logos and color schemes.

•      Shared navigation elements.

•      Shared features, such as search commands and Help commands.

•      Links to cascading style sheets. (Cascading style sheets control page appearance, colors, and fonts.)

The publishing site templates included in Office SharePoint Server 2007 include site master pages that you can use as a starting point in your page design. To customize an existing master page or create a new one, use Microsoft Office SharePoint Designer 2007 or Microsoft Visual Studio.

•      Page content   A single Pages library contains all of a site's content pages. Each item in a Pages library is a single Web page. Because the Pages library is a SharePoint library, the Web pages it contains have all the features of documents in Office SharePoint Server 2007, such as versioning and content approval.

Note:

Although all pages in a site are in a single Pages library, Web solutions based on Office SharePoint Server 2007, such as intranet portal sites and Internet presence sites, typically consist of a tree of sites, each with its own Pages library.

Authors can create and edit Web pages by using either of the following methods:

•      Browser-based editing. Authors create pages using the Create Page command and edit them using the Edit Page command. When creating a page, an author picks a content type and page layout, such as "(Article Page) Article page with image on right."  When editing a page, authors use the editing commands available on the page to add content, pick images, and do other editing tasks.

•      Converting documents. Authors can convert documents of supported formats into Web pages. Office SharePoint Server 2007 includes converters for documents of .docx and .docm file formats.

See Plan Web page authoring for more information about planning how Web pages will be authored, including information about configuring document converters.

The columns associated with a Web page's content type contain the page's HTML content. They also contain links to images to display with the page and a link to the page's layout. For example, pages of the default Article Page content type include the following columns:

This column

Contains this content

Byline

The author's name

Article Date

The date the article is published

Page Content

The body of the article

Page Image

A graphic to accompany the article

Image Caption

A caption for the page image

Rollup Image

A graphic to display in search results

Page Layout

The page containing the article's layout

Each column of content for a page is associated with a particular field control in the page's layout pages in which the content for that column is authored and displayed.

•      Layout Page   An Active Server Pages (ASPX) page that defines a layout for a type of content page. When a SharePoint site user opens a page in a browser, that page's associated layout page is first combined with the active master page (which supplies the outer frame of the page) and then the contents of the page are poured into the field controls on the layout page.

Because a layout page must display content that is stored in the columns of a content type, it must be designed for a particular content type. For example, a layout page that is associated with the Article Page content type would have several field controls, including:

•      A Page Content field control to hold the contents of the Page Content column in the Article Page content type.

•      A Page Image field control to hold the image linked to from the Page Image column of the Article Page content type.

Although a layout page must be designed for a single content type, a content type can be associated with multiple layouts. For example, Office SharePoint Server 2007 includes two layout pages for the Article Page content type: one that displays the image on the left side of the page and another that displays the image on the right.

Along with controls to display the contents of a page, a layout page can include other page elements, including:

•      Web Parts

•      Web Part zones

•      Server controls

•      Cascading style sheet links to control page appearance, colors, and fonts

For example, a page layout for a business article could include a server control that displays a stock ticker. The stock ticker would be displayed along with a page's contents whenever that layout page is used.

Layout pages for all sites in a site collection are stored in the Master Page Gallery in the top-level site in the site collection. Because the Master Page Gallery is a SharePoint library, layout pages also have all the features of documents in Office SharePoint Server 2007, such as versioning and content approval.

Publishing sites that you create using Office SharePoint Server 2007 include layout pages that you can use as a starting point in your page design. To customize an existing layout page or create a new one, use Microsoft Office SharePoint Designer 2007 or Microsoft Visual Studio.

Planning master pages

Master pages supply the shared framing elements of the page, including the branding of the site, its navigation features, and other common elements such as search fields and help commands. This article can help you plan your site master pages. It does not provide guidance on designing master pages' appearance or functionality. For more information about master page design, see Page design roadmap (http://technet.microsoft.com/en-us/library/cc261968.aspx.)

The site master page supplies the context of the page and should remain consistent as the user interacts with your site. We recommend that you do not change the site master page as a site user navigates from one page to another within a single site in your site collection. To supply consistent branding and user interface, you can use the same site master page across all sites in your site collection.

You might decide to change the master page in subsites in your site hierarchy to change the branding in some subsites. For example, an enterprise's Internet presence site might consist of subsites that each present a different brand of products. You can change the site master page for each subsite to reflect the distinct product brand that each subsite presents.

Before you plan master pages, plan your site structure, as described in Plan Web site structure and publishing. By using the site information that you recorded in the topic Determine sites and subsites, list the name of each site in your site collection in the Site column of the Plan master pages worksheet (http://go.microsoft.com/fwlink/?LinkId=73318&clcid=0x409). Then, for each site, fill in the following information in the worksheet:

1.   In the Master page column, list the name of the master page to use in the site, such as "BlueBand.Master."

2.   In the Custom column, specify the information that applies to your situation.

•      If the master page will be customized for the current site, select Yes.

•      In the Based on column, type the name of the template that it will be based on, or type None if the master page will be completely custom.

•      If the master page will not be custom for the current site, select No.

•      If the site will inherit its master page from its parent site, type the name of the parent site in the Inherits from field. (Your documenting site inheritance now will be useful later if you decide to customize the master page elsewhere in your site hierarchy and you want to identify the sites that will be affected by the changes to the master page.)

•      If the master page will be applied at the current site, leave the Inherits from field blank.

3.   Optionally in the Notes column, list instructions about how to customize the master page or about the tool to use to customize the master page, such as Office SharePoint Designer 2007.

Planning content pages

Each content page in Office SharePoint Server 2007 consists of text, images, and other content stored as an entry in a Pages library. Planning content pages includes:

•      Determining the page content types that meet your content needs.

•      For each page content type, determining the columns to use for storing content.

Office SharePoint Server 2007 includes three page content types:

•      Welcome Page   Typically, the home page of a publishing site. It includes:

•      Columns for images to display.

•      A column for page content.

•      Columns for links to display with the page.

•      Article Page   The primary content page type. This page is designed for general-purpose Web page content. It includes:

•      Columns for images and image captions.

•      A column for page content.

•      Columns for links to display with the page.

•      A byline column.

•      Redirect Page   A page to redirect the reader to another page.

Additionally, because all three page content types inherit from the generic Page content type, they all include:

•      Columns to schedule the page's start and end dates.

•      Columns describing contact information for the author.

•      An image to display with the page when it is listed in a table of contents or other list.

•      Audience targeting information.

When planning content pages, we recommend that you use the page content types that are included in Office SharePoint Server 2007 as a starting point. The Welcome Page and Article Page content types have been designed to be generally useful and to apply across a wide range of contexts. The primary content column in both content types is the Page Content column, which is capable of holding any HTML content. Authors and site designers can control the appearance of their content by using HTML and the cascading style sheets framework. By so doing, they may not need to design other content types." Also, by carefully choosing which layout (see Planning page layouts) to use for each type of content based on the Article Page or Welcome Page, you can introduce more variety in your content presentation without requiring the introduction of additional content types.

To modify a page content type, add columns to it that will contain the new HTML, image, or other type of content. (Create columns in the Site Column Gallery to use them on multiple page types.) For example, you may want to add an "About the author" field to certain article pages, to include biographical information about page authors. To do this, add a column, of type "Publishing HTML," to the Site Column Gallery (so that it can be used in other content types), and then add that column to the Article Page content type.

After modifying a page content type, you must modify its associated layout pages by adding field controls to display the additional columns of content. For example, after adding an About the Author column to the Article Page content type, you would add an About the Author field control to associated layout pages to display the contents of that column. Planning layout pages is discussed below, in the section Planning page layouts.

To plan article pages, use the Plan article pages worksheet (http://go.microsoft.com/fwlink/?LinkId=73316&clcid=0x409). The leftmost column in the worksheet contains all the columns in the Article Page content type. Use the other columns in the worksheet to list each type of content that you want to present in your site, such as Article, Press Release, and Job Posting. After you list the types of content across the top of the worksheet, indicate, for each type of content, the columns that you want to use for that type of content, such as "Article date" and "Page content." If you determine that you need a column that is not available, add it in the first column of the Plan article pages worksheet.

It is less likely that you will need more than one welcome page to use across your site, but if you do, use the Plan welcome pages worksheet (http://go.microsoft.com/fwlink/?LinkId=73320&clcid=0x409) to plan which columns to display in each type of welcome page. However, for each subsite in your portal or Internet presence site, you will most likely want to provide a unique welcome page.

Planning layout pages

A layout page defines a layout for a content page by providing field controls into which the contents of the content page are displayed. Each layout page is associated with a particular content type, and multiple layout pages are often available for a single content type (for example, to provide alternate layouts for localized versions of content or to add or remove the display of certain fields and features from a page layout. You can create or customize a layout page, including adding new controls to display page content along with additional controls such as Web Parts and server controls, using Microsoft Office SharePoint Designer 2007 or Microsoft Visual Studio.

Office SharePoint Server 2007 includes a set of page layouts for the Welcome Page and Article Page content types. The layouts for article pages include:

This page layout ...

Contains these page elements ...

Article page with body only

A basic page with a title and page content area.

Article page with image on left

A page with a title, page content, a page image on the left, and areas for a byline, article date, and image caption.

Article page with image on left

A page with a title, page content, a page image on the right, and areas for a byline, article date, and image caption.

Article page with summary links

A page with a title, page content, article date, byline, and a Summary Links Web Part, in which site authors can add a list of hyperlinks.

For the Welcome Page, the page layouts include:

This page layout ...

Contains these page elements ...

Welcome page with summary links

A welcome page with content and image areas, along with two Summary Links Web Parts.

Welcome page with table of contents

A welcome page with content and image areas, along with a Table of Contents Web Part to display a hyperlinked table of contents of the site.

Welcome splash page

A simple welcome page with just an image and two Summary Links Web Parts in which your authors can add hyperlinks.

If you are using the page content types and layouts that are included with Office SharePoint Server 2007, there are no additional planning steps needed. Authors will be able to choose page types and associated layouts when they create new pages. However, if you either add new fields to a page content type or if you create entirely custom content types for publishing pages, you should plan layout pages that reflect the new or changed content types.

You can also modify a layout page by adding Microsoft ASP.NET 2.0 controls, such as Web Parts and Web Part zones, to the page. For example, you can add a Content Query Web Part, which displays a set of links returned by a configurable query, to a layout page. Note that if you place a Web Part on a layout page outside of a Web Part zone, you must configure the Web Part, and authors will not be able to change its configuration. For example, if you add a Content Query Web Part directly to a layout page, you would "lock in" the query it uses and authors would not be able to modify it.

To plan layouts for Article Pages, Welcome Pages and other page content types, use the Plan layout pages worksheet (http://go.microsoft.com/fwlink/?LinkId=73317&clcid=0x409). Create a separate worksheet for each page content type in your site, such as Article Page. For each page type, list its associated layout pages, provide descriptions of the layouts, and add notes on customizing or creating the layout pages. For example, if you add a second image field to the Article Page content type, you should specify to add a second image-displaying field control to each page layout associated with the Article Page content type.

Using layout pages to restrict authoring

Depending on your publishing goals, you can restrict how much freedom authors have to format their Web page content or to add items such as images and hyperlinks to pages in your site. For example, in a highly controlled Internet presence site, you may want all formatting to be defined in cascading style sheets associated with your layout pages and you may want to block writers from overriding style definitions by using inline formatting. In contrast, in a collaborative site, such as an intranet portal, you may want to give authors full freedom to format their pages and add other page items, such as Web Parts providing views of data. For example, in an intranet portal used to collaborate on product specifications, you may want to enable writers to freely use styles, hyperlinks, images, and Web Parts to maximize their ability to communicate their ideas.

You can place restrictions on layout pages in the following ways:

•      You can set properties on field controls in layout pages that restrict what authors can do.

•      You can remove Web Part zones from layout pages to restrict authors from inserting and configuring Web Parts on their pages, or you can set restrictions on Web Part zones to limit how authors can use them.

Setting restrictions on field controls

By opening your site in Microsoft Office SharePoint Designer 2007 or Microsoft Visual Studio 2005 you can edit the tags associated with field controls to restrict the types of Office SharePoint Server 2007 authoring features writers can use when editing pages in the browser window. For example, in field controls that are bound to columns of type Publishing HTML, features you can allow or restrict include:

•      Setting fonts

•      Inserting images

•      Inserting tables

•      Adding hyperlinks

•      Adding text markup, such as bold and italics

You can set authoring restrictions on other column types. For example, in field controls that are bound to columns of type Publishing Image, you can allow or restrict hyperlinks from images.

When you restrict an authoring feature on a layout page in Microsoft Office SharePoint Designer 2007 or Microsoft Visual Studio 2005, the related page editing commands in Office SharePoint Server 2007 become unavailable. For example, if you restrict table editing in a field control that contains content of type Publishing HTML, table editing commands, such as Edit Table will be unavailable in the Edit Content toolbar.

Allowing or restricting Web Part zones

A Web Part is a server control that authors can insert into Web Part zones on pages. Web Parts display information based on their functionality, such as presenting site navigation links, SharePoint list contents, or database analytical information.

When a layout page includes one or more Web Part zones, the Web Part zones are available on pages using that layout, which enables authors to insert available Web Parts onto their content pages. If you allow authors to insert Web Parts on pages, you reduce your control over users' experience of the site. For example, a writer could insert a Table of Contents Web Part onto a page that exposes parts of your site that your do not want users to navigate to from the current page.

You can restrict authors from adding Web Parts to pages by opening the associated layout pages in Microsoft Office SharePoint Designer 2007 or Microsoft Visual Studio 2005 and removing Web Part zones from them. Similarly, when designing new layout pages, omit Web Part zones to limit authors' ability to add functionality to the pages associated with those layout pages.

You can also include Web Part zones in layout pages but restrict their usage. By setting a Web Part zone's properties, you can populate the Web Part zone with one or more Web Parts and allow authors to edit the properties of those Web Parts but not let them add other Web Parts to the Web Part zone.

Summary

The following table shows layout restriction recommendations for tightly controlled, moderately controlled, and loosely controlled authoring environments:

Level of control

Typical site

Restriction recommendations

Tight

Internet presence

Strict limitations on editing field controls; other field control limitations, such as no hyperlinks from image field controls; Web Parts are placed directly on the layout page and not in Web Part zones

Moderate

Enterprise intranet portal site

Moderate or no limitations on editing field controls; Web Part Zones containing Web Parts, but authors are restricted from adding/removing Web Parts

Loose

Divisional or team portal site

No limitations on editing field controls; Web Part Zones allowed

To record your decisions about authoring restrictions on layout pages, use the Plan layout pages worksheet (http://go.microsoft.com/fwlink/?LinkId=73317&clcid=0x409). Edit the worksheet for each page content type in your site on which you want to place restrictions. Record your restriction requirements in the Notes field for each layout type.

Download this book

This topic is included in the following downloadable book for easier reading and printing:

•      Web Publishing and Planning Guide with Microsoft Office SharePoint Server (http://go.microsoft.com/fwlink/?LinkID=92330.)

See the full list of available books at Downloadable books for Office SharePoint Server 2007 (http://technet.microsoft.com/en-us/library/cc262788(TechNet.10).aspx.)

See Also

Plan Web page authoring

Plan content approval and scheduling

Plan Web page authoring

In this article:

•      Plan browser-based authoring

•      Plan smart-client authoring

•      Worksheet

Web page authoring is the process by which writers add content to a publishing site such as a corporate Internet site or intranet portal site. Web page authoring is available in a site when the Office SharePoint Server publishing features are activated in the site. For information about which site templates include the publishing features, see Determine sites and subsites.

Note:

Before reading this topic, review Plan Web pages, which describes layout pages, field controls, and other elements of Web pages mentioned in this topic.

Microsoft Office SharePoint Server 2007 supports two methods of Web page authoring:

•      Browser-based authoring   Content creators work directly in the Web browser by using Office SharePoint Server 2007 browser-based features such as the Page Editing toolbar and the HTML Editor toolbar.

•      Smart-client authoring   Content creators work in an authoring application and use the Office SharePoint Server 2007 document conversions feature to convert from the document's native format to Web page (that is, HTML) format.

Determining whether to use browser-based authoring or smart-client authoring and conversions depends on how your team produces content, along with other factors. The following table describes some of the pros and cons of each method.

Authoring method

Pros

Cons

Browser-based authoring

•      Convenient. Allows editing a Web site in place.

•      Incorporates Office SharePoint Server 2007 document management features such as versioning, approval, workflows, and check-in and check-out.

•      Simpler. Does not require the steps of approving content in client applications, then converting the content, then approving the content again as Web pages.

•      Can't take advantage of templates available in client authoring applications.

•      Authors may be more comfortable working in familiar client authoring applications.

Smart-client authoring.

•      Facilitates publishing an existing body of content.

•      Useful when the team that authors content is separate from the team that designs and publishes the Web site.

•      Authors don't need to learn a new user interface.

•      May be a more appropriate tool for writing lengthy, complex documents.

•      After a document is converted, all browser-based document management features become available on the converted Web page.

•      Converted content must be reviewed and possibly edited in the Pages library, adding a separate step.

•      Converters for a client application may need to be developed and tested.

•      Converter programs used by the document conversion feature require server administration and load balancing.

•      No support for reusable content.

Before reading about the planning options for browser-based and smart-client authoring, you should review the elements of Web pages in Office SharePoint Server 2007 by reviewing Plan Web pages.

Plan browser-based authoring

Planning browser-based authoring includes planning which resources and commands to make available to authors, and planning the editing experience in the field controls in which authors create content.

Note:

A related set of planning considerations — planning how content will be approved and published — is discussed in Plan content approval and scheduling.

Plan Page Editing toolbar customizations

The Page Editing toolbar contains UI elements that provide access to page editing commands and related tools, along with workflow commands. This toolbar is available to team members who have at least the Contribute permission level.

The Page Editing toolbar contains two areas that you can customize:

•      Page editing menu commands   The set of commands for writing, reviewing, and approving Web pages.

•      Quick access buttons   Make frequently used commands available, based on the page's context. For example, the Check In to Share Draft button is only available when a page is checked out.

You can plan and implement page editing menu commands and quick access buttons to provide functionality to your content team. For example, if your organization has an art order process that you want to automate, you could add an Art Order command to the Tools menu on the Page Editing toolbar or implement an Art Order quick access button. Note that you can implement a command as both a menu command and a button.

For more information about implementing commands and buttons in the Page Editing toolbar, see the Office SharePoint Server 2007 Software Development Kit (http://go.microsoft.com/fwlink/?LinkId=71218&clcid=0x409.)

Plan HTML Editor toolbar customizations

The HTML Editor toolbar provides the commands used by authors to edit Web page content in a field control:

You can customize the HTML Editor toolbar to provide additional editing features to authors or to restrict them from using some features.

•      Add buttons to provide new functionality You can add new editing features to Office SharePoint Server 2007 and provide buttons on the HTML Editor toolbar to give authors access to the features. For example, if your publishing portal is used to create highly technical content, you could add an equation editor feature and provide a button for authors to access it.

•      Add inline styles You can replace the default styles of page elements by adding references to style sheets in layout pages. When you do this, authors will be able to pick the styles available for the current page element by using the Styles menu on the HTML Editor toolbar.

•      Add table formats The HTML Editor comes with a set of predefined table formats that can be customized to fit the styling of an individual page. Each table format consists of a collection of cascading style sheets classes for each table tag. For example, you can customize the appearance of the first and last rows of a table, the odd and even rows, or the first and last column.

•      Add custom image pickers In any field that includes an Insert Image command, you can replace the default image picker with a custom one. For example, if you have a very large, searchable repository of images, you can create an interface that lets authors search that repository when they edit Web pages.

•      Restrict access to editing features As described in Plan Web pages, you can restrict how much freedom authors have to format their Web page content or to add items such as images and hyperlinks to pages in your site by restricting access to editing features. By opening your site in Microsoft Office SharePoint Designer 2007 or Microsoft Visual Studio 2005 you can edit the tags that are associated with field controls to restrict the types of Office SharePoint Server 2007 authoring features writers can use when editing pages. For example, you can prevent authors from:

•      Setting fonts

•      Linking to external addresses

•      Adding headings to content

•      Making text bold, italic, underlined, or italicized

•      Adding tables

For more information about customizing the HTML Editor toolbar, see the Office SharePoint Server 2007 Software Development Kit (http://go.microsoft.com/fwlink/?LinkId=71218&clcid=0x409.)

Plan reusable content

The top-level site in a publishing portal or Internet presence portal includes a Reusable Content list that is available in every site in the site collection in which the Office SharePoint Server publishing feature is enabled. Reusable content items can be implemented as HTML or text. By using the Open a new window to insert reusable content button on the HTML Editor toolbar, authors can browse the available reusable content and then insert it.

When you create a reusable content item in the Reusable Content list, you can specify whether or not it can be automatically updated.

•      If you specify that an item is automatically updated authors will not be able to change it after they insert it on a page. For example, you can implement a copyright statement or an enterprise's name, address, and other contact information as automatically updatable items. Doing this helps to prevent authors from incorrectly using those items.

When an author inserts an automatically updated item on a page, the URL of the item is inserted instead of the item's contents. When a Web browser loads a page that contains an automatically updated item, the Web browser replaces the URL with the contents of the item. Therefore, changes to automatically updated items in the Reusable Content list do not have to be propagated to pages that use them. They are immediately available the next time a page is opened in a Web browser.

•      If you do not specify that an item is automatically updated authors will be able to change it after they insert it on a page. This is useful if you want to define the proper form for a block of content but you want authors to provide the content itself. For example, in a site that provides product descriptions, in which you want each description to follow a particular tabular form, you could create a generic Product Description Table item in the Reusable Content list, which authors could insert and then overwrite.

Plan dictionary customizations

The Office SharePoint Server 2007 Page Editing toolbar includes a Spelling command that checks the spelling of content in all fields on a page that contain HTML content. The Spelling command indicates spelling errors and provides commands for fixing or ignoring them.

You can add a custom dictionary to your publishing Internet or intranet portal site, to prevent words that are unique to your content from being reported as spelling errors. For example, if your site includes unique product names, you can add them to the custom dictionary.

Note:

To create a custom dictionary to supplement the dictionaries included in Office SharePoint Server 2007, create a document library named "Spelling" in the top-level site of your portal's site collection. In that library, upload a text file named "Custom Dictionary.txt". Add each properly spelled word to the Custom Dictionary.txt file on a separate line of plain text in the file. Only one Custom Dictionary.txt file is supported for a site collection. Words of any language supported by your site can be added to the Custom Dictionary.txt file.

Plan additional resources

When you create a publishing site, Office SharePoint Server 2007 creates the libraries listed in the following table that you can use to store additional resources that content creators can use.

Use this location

To store these items

That apply to this level in the site hierarchy

Master Page Gallery

Master pages and layout pages

Site collection

Documents

Documents used in page authoring

Current site

Site Collection Documents

Documents used in page authoring

Site collection

Images

Images used in page authoring

Current site

Site Collection Images

Images used in page authoring

Site collection

Style Library

Custom cascading style sheets and Extensible Stylesheet Language (XSL) styles

Site collection

Note that the default image picker used in Office SharePoint Server 2007 allows users to browse the contents of the Site Collection Images library and the current site's Images library.

Plan smart-client authoring

Smart-client authoring is the method whereby content creators work in an authoring application and use the Office SharePoint Server 2007 document conversions feature to convert from the document's native format to Web page (that is, HTML) format. Office SharePoint Server 2007 includes converters that create Web pages from Office Word 2007 documents and from Microsoft Office InfoPath 2007 forms. Office SharePoint Server 2007 also includes a generic Extensible Stylesheet Language Transformation (XSLT) converter that enables users to apply an XSL transformation to an XML document. You can develop and install converters for other document formats. (For more information about document conversions, see "Planning document conversions," in Plan document libraries.)

Note:

In smart-client authoring, the document library containing the source documents and the library containing the converted Web pages must be in the same site collection.

You implement smart-client authoring in the following steps:

1.   Plan the content type Associate a document template and matching document converter with a content type that is based on the Document content type.

2.   Configure the document converter A document converter's configuration must specify:

•      The Pages library in which to store the converted content. Because there is a single Pages library in each site in your publishing site hierarchy, this also identifies where in your site hierarchy the content will go.

•      The layout page in which the converted content will be displayed. Every Web page must point to a single layout page that defines how the page will be displayed. Pick an appropriate layout page from the Master Page Gallery, which is in the top-level site in the site collection.

•      The field on the selected layout page in which the contents of the converted page will be displayed. Layout pages can have one or more Page Content field controls to hold the contents of a Web page. You must indicate a single Page Content field control for displaying the contents of the converted document.

•      When the conversions should run. Conversions can run immediately or based on a schedule controlled by the server's administrators. It is recommended that you schedule conversions in a production environment. Contact your server administrators and set this option according to their instructions.

3.   Plan cascading style sheets handling The Office SharePoint Server 2007 converters that transform Office Word 2007 documents into Web pages do the following things:

•      Extract a set of cascading style sheets style definitions based on the Office Word 2007 paragraph definitions in the source document and, by default, store them in a specified field of the converted Web page.

•      Insert class references in the converted Web page to apply the extracted cascading style sheets style definitions.

•      Convert inline styles in Office Word 2007 documents, such as font formatting, into inline cascading style sheets styles in converted Web pages

To more tightly control the appearance of Web pages on your site, you can configure the Office SharePoint Server 2007 Word-to-HTML converters to remove the extracted set of cascading style sheets style definitions and not store them with converted Web pages. When you do this, the converter will still insert class references in converted Web pages. To resolve those class references, you can define a set cascading style sheets style definitions and associate them with layout pages or master pages in which the converted Web pages will be displayed. (A set of those styles based on the default Office Word 2007 paragraph styles is defined in the file Rca.css and is associated by default with the layout pages included in Office SharePoint Server 2007.)

Note:

The Office SharePoint Server 2007 Word-to-HTML converters cannot be configured to remove inline cascading style sheets styles generated for inline formatting in the source document. To prevent inline styles from overriding your cascading style sheets style definitions, prohibit authors from using inline formatting in their source documents.

Note:

The Office SharePoint Server 2007 Word-to-HTML converters cannot convert inline images into images in the output Web pages, and inline images in source documents will be missing from the converted Web pages. To avoid this, authors should store their images in a picture library in the site collection and insert images into their source documents as hyperlinks to the stored images.

Worksheet

Use the following worksheet record your Web page authoring decisions for a type of content:

•      Plan Web page authoring worksheet (http://go.microsoft.com/fwlink/?LinkId=74540&clcid=0x409)

In the worksheet:

1.   Record the site URL. This is the site containing the Pages library in which Web pages will be stored.

2.   Provide a content description. For example, "product descriptions" or "feature articles."

3.   Indicate the authoring team responsible for creating the content.

4.   Describe new resources or commands to add. For example, "Add Art Order button to Page Editing toolbar."

5.   Indicate if smart-client authoring will be used to author pages in this site.

6.   If smart-client authoring will be used, record the source Document library URL, the source document content type, and the document template to use.

7.   If smart-client authoring will be used, record the layout page that will contain the converted content and the content field that will display the converted content.

8.   If smart-client authoring will be used, indicate whether or not cascading style sheets style definitions should be retained for use with the converted content. If cascading style sheets style definitions will be retained, indicate the field in which to store the extracted cascading style sheets style definitions. If cascading style sheets style definitions will not be retained, indicate where the cascading style sheets styles for the converted page will be defined.

Download this book

This topic is included in the following downloadable book for easier reading and printing:

•      Web Publishing and Planning Guide with Microsoft Office SharePoint Server (http://go.microsoft.com/fwlink/?LinkID=92330.)

See the full list of available books at Downloadable books for Office SharePoint Server 2007 (http://technet.microsoft.com/en-us/library/cc262788(TechNet.10).aspx.)

See Also

Plan content approval and scheduling

Plan document libraries

Plan Web pages

Plan variations

In this article:

•      About variations

•      Variations and content approval

•      Planning target variation sites

•      Variations and site navigation

•      Variations and content deployment

•      Variations and Web Parts

•      Planning your variation sites

About variations

Many organizations have a global reach. However, even in domestic markets, organizations must reach a diverse customer base that may speak multiple languages, or that may need to target specific information based on regional differences, various mobile devices, or corporate branding. These types of organizations need Web sites that deliver tailored content to suit different cultures, different markets, and different geographic regions. Producing and maintaining variations of a site can be difficult and time-consuming. To simplify the process for site architects and site administrators, Microsoft Office SharePoint Server 2007 uses variations.

The variations feature in Office SharePoint Server 2007 makes the same content available to specific audiences across different sites by copying content from the source variation site to each target variation site. If necessary, the content can then be customized in the target variation site. For example, content in a target variation site can be localized before it is published.

By default, variation sites redirection is based on the language setting of the browser from which the user is visiting the site. For instance, if a user's default browser language is French, Office SharePoint Server 2007 will redirect that user to the French variation site. This behavior can be customized by replacing the default redirection page (VariationRoot.aspx) with a different page. This new page, for instance, can implement logic that identifies the user's preferred language, the user's device, or another basis for varying sites. For more information about customizing variation sites redirection, see the article How to: Customize the Variation Root Landing Logic (http://go.microsoft.com/fwlink/?LinkId=80449&clcid=0x409).

You initially define variations of a site by creating variation labels, one for each desired variation. A variation label is an identifier that is used to name and configure a new variation site. You select one variation label as the source, which represents the site where most of the new content enters the system. The corresponding variation labels are the target labels, representing the sites to which content is copied. (Office SharePoint Server 2007 supports up to 50 labels.) You create variation sites from variation labels by using the Create Hierarchy command on the Variation Labels page of the Office SharePoint Server 2007 site administration pages.

Only one set of variation labels can be defined for a site collection. The corresponding variation sites can start anywhere in the site hierarchy. The source variation site and the target variation sites are always created as subsites of the variations home site. Users who visit the variations home site are redirected to the appropriate variation site. (An optional Variation Picker control lets users pick which variation site to view by using a menu. You add this control to master pages by using Microsoft Office SharePoint Designer 2007.)

In the simple example shown below, three variation sites — labeled "A", "B", and "C" — are one level below the variations home site, which, in this example, is the top-level site in the site collection.  "A" is the source variation site. Pages authored and published (approved as new major versions) in that site are copied to the target variation sites, "B" and "C".

Each variation site is created by using the same site template used to create the variations home site. If the variations home site has content, such as Web pages or images that you want to include in the variation sites, you must copy that content to the source variation site after creating the variation sites. That content will then be propagated to the target variation sites after it is approved for publication. Similarly, if the variations home site has subsites that you want to also be subsites of each variation site, you must manually create those subsites below each variation site. Pages published in subsites of a source variation site will be propagated to the equivalent subsite in each target variation site.

Variations and content approval

Content approval is the method by which site members with approver permissions control the publication of content. In content approval, content is considered published when a new major version is approved, because major versions are viewable by users with read permissions. Content approval in variation sites requires major and minor versioning in the Pages libraries on the source and target variation sites. For a full discussion of Office SharePoint Server 2007 versioning and approval, see Plan versioning, content approval, and check-outs.

Content approval has unique considerations when planning variations:

•      On the source variation site, when a page is submitted for approval, an e-mail is generated and sent to the owners of the target variation sites. When the page is then approved, it is enabled for copying to the target sites. You can configure the variations feature so that content is automatically copied to the variation sites by a timer job, or you can choose to manually propagate variation content.

•      On target variation sites, a page copied from the source variation site is always assigned a minor version. If the page is new to the target site, it will be assigned version 0.1.  If the page already exists on the target variation site, the copied page will be assigned the next available minor version. For example, if a target site has version 2.1 of a page and a new variation of that page is copied to the target site, the page becomes version 2.2.

Note:

Changes to content originating on the source variation site may replace changes made to the content in the target site. For example, in language variations, if the source site is in one language and the target site is in another, the following situation could occur: An editor changes a localized page on the target site, assigning it a new minor version, 1.1.  Then, a writer on the source site changes the same page, which is copied to the target site as version 1.2; this supersedes the version 1.1 changes to the page. In this example, an editor for the target site would have to retrieve the previous version of the topic, accept the new version, or merge the new and previous versions into a new version.

Planning target variation sites

Your planning goals for target variation sites will vary depending on the type of variation sites you are implementing. For example, if the variation sites are based on languages, you may want the pages in the target variation sites to look the same as the pages in the source variation site. If the variations are based on devices, you will probably want the pages in the target sites to look different from the pages in the source sites, so that they fit the devices intended to display them.

You may decide to use custom master pages, layout pages, or style sheets for variation sites. For example, in site variations based on devices, you could define simpler page layouts for those variations that are displayed on devices with limited screen sizes. Master pages, layouts, and style sheets are only managed in the top-level site of a site collection, so you must make all changes to these resources in one of the following locations in the top-level site.

Resource

Location

Master Page

Master Page Gallery

Layout Page

Master Page Gallery

XSL styles and cascading style sheets

Style Library

For more information about planning page layouts and master pages, see Plan Web pages.

You must use the same content type (either the Page content type, or a content type based on the Page content type) for all variation sites' Page libraries. The easiest way to do this is to use a content type that is defined in the Site Content Type Gallery in the top-level site.

If you need custom columns for one or more variation sites' pages, add them to the content type you are using in your Page libraries. For example, if the variation sites are based on language differences, you can add a column that indicates if the page has been localized. For more information about planning content types and columns, see Plan content types.

If the source variation site has subsites with the publishing feature enabled, the subsites' pages will be propagated to target variation sites. This works even if a target variation site's structure has been modified, because the variations feature tracks the source and target sites' Pages libraries locations. However, if you rename or delete a Pages library from a target variation site, the variations feature will no longer work.

In some site variations solutions, it is not necessary to edit or change the content on the target variation sites. For example, if your variation sites are device-dependent, you may want the identical content displayed on all devices but with different layouts and master pages for each type of device. When this is the case, you can simplify your target variation sites by disabling their authoring features, such as the page-authoring console also disabling required check-outs.

Note:

Disable the Office SharePoint Server 2007 authoring console by using Office SharePoint Designer 2007.

Variations and site navigation

If you are using site variations, plan your site navigation experience carefully. In Office SharePoint Server 2007, site navigation links are automatically generated and displayed in the outer frame (the master page portion) of a Web page. Often, site navigation is configured to display links to the current site's peer sites. In variation sites, where the current site's peers are variations of the same site, you may not want to give site users the ability to navigate in this way.

For more information about navigation planning, see Plan site navigation.

Variations and content deployment

The Office SharePoint Server 2007 content deployment feature copies content from a source Office SharePoint Server 2007 site collection to a destination site collection. The entire source site collection, a subset of sites, or single pages can be copied.

When deploying variation sites, it is best to deploy all sites simultaneously. Because subsites or individual Web pages can be deployed separately, a set of Web pages across variation sites can get out of sync on the destination site collection. For example, if a new page is added to the source variation site and that site is deployed earlier than a target variation site, users redirected to the page in the target variation site (or explicitly choosing the page by using the Variation Picker control) may not be able to view it.

For more information about content deployment planning, see Plan content deployment.

Variations and Web Parts

A Web Part is one of the building blocks of pages based on Office SharePoint Server 2007. Most Web Parts are designed to display a specific type of data, such as text, HTML, or images. Office SharePoint Server 2007 includes a set of Web Parts, and you can also develop or import Web Parts.

Web Parts are propagated along with variation sites' pages. However, depending on a Web Part's functionality, it may not work in the context of variation sites. For example, the List Web Part uses the globally unique identifier (GUID) of a list to reference that list. Because the List Web Part does not update the GUID when the page is propagated as part of a variation site, the Web Part will try to reference the list in the source variation site, which will not be the intended functionality and may not work. To prevent unintended Web Parts behavior such as this, you can configure the variations feature not to copy Web Parts to target variation sites.

If you do choose to copy Web Parts as part of variation sites, make sure that they have been developed for use in a site variations context. For more information about Web Parts development, see the Office SharePoint Server 2007 Software Development Kit (http://go.microsoft.com/fwlink/?LinkId=71218&clcid=0x409).

Planning your variation sites

Worksheet action

Use the Plan Variations worksheet (http://go.microsoft.com/fwlink/?LinkId=80667&clcid=0x409) to record your variation sites planning decisions:

1.   On the worksheet, record the purpose of the variation sites, such as "device-dependent variation sites."

2.   Record the variations home site's URL.

3.   Indicate if subsites of the variations home site should be copied to the source variation site and, if so, enter the names of the subsites to copy.

4.   Indicate if content in the variations home site should be copied to the source variation site and, if so, describe the content to copy.

5.   Describe how variation sites should be propagated: automatically or manually.

6.   Under "Variation sites," list each variation site in a separate row. Indicate which variation site is the source site.

7.   For each variation site, indicate any custom layouts, master pages, or columns to provide, and supply additional notes as needed.

Worksheet

Plan variations worksheet (http://go.microsoft.com/fwlink/?LinkId=80667&clcid=0x409)

Download this book

This topic is included in the following downloadable book for easier reading and printing:

•      Web Publishing and Planning Guide with Microsoft Office SharePoint Server (http://go.microsoft.com/fwlink/?LinkID=92330.)

See the full list of available books at Downloadable books for Office SharePoint Server 2007 (http://technet.microsoft.com/en-us/library/cc262788(TechNet.10).aspx.)

Plan content approval and scheduling

In this article:

•      Plan governance

•      Plan scheduling

•      Governance and scheduling in a content deployment scenario

In addition to planning how much control you want users to have over altering the appearance of your Microsoft Office SharePoint Server 2007 Web site, you also need to plan how much governance you want content contributors to have over your site content. Governance refers to the rules and processes that you want to establish for your site. For example, you may want users to impose restrictions and functionality when authors create content. You have the option of giving users no control, simple moderation, or the ability to start a workflow after they submit content. You can also plan restrictions on where and what type of content an author can place in certain areas of your site.

At this time you also need to understand how the scheduling process works. Users can set a publish and unpublish date by setting the appropriate schedule.

Plan governance

There are two steps in planning governance. The first step is to determine how and if you want content to go through an approval process. The second step is to determine what content can appear in specific areas of your site.

Plan content moderation or workflow approval

Content moderation and workflow approval is the method by which site members with Approver permissions control the publication of content. In Office SharePoint Server 2007, governance can fall within three moderation and workflow approval categories:

1.   None   If you choose to implement no moderation or workflow, after an author submits content for publishing it goes live immediately. If a document library is configured to support major and minor versions of content and no content moderation is used, users who have Read permissions will be able to see minor versions of the content.

2.   Simple moderation   You configure this if you want content manually approved by a member of the Approver group after an author submits it for publishing. Simple moderation is the default in the Corporate Intranet Presence Template in Office SharePoint Server 2007. In the Intranet Presence Template, document libraries and image libraries are also configured to use simple moderation.

3.   Approval workflow   You configure this if you want a workflow to run the approval process. Using a workflow makes the approval process more automated and takes advantage of the built-in workflow features, such as automatically sending e-mail to approvers, adding approval tasks to approvers' task lists, and letting authors track the status of the approval process. The pages list in the Internet Presence Template includes a default approval workflow. Users can also develop their own custom approval workflow. See the Office SharePoint Server 2007 Software Development Kit (http://go.microsoft.com/fwlink/?LinkId=71218&clcid=0x409) for more information about creating custom workflows.

Plan where and how content can appear

Governance also dictates where you want content to appear on your site by introducing restrictions over where certain types of content can appear. You specify this by configuring the site settings for the site templates or page layouts you want authors to use. For example, you may want authors to use a publishing site template, but restrict them from using a Team Site template. Likewise, you can also force users to use the page layout where a graphic always appears on the left side of the page as opposed to the right side.

Plan scheduling

Users have the ability to schedule when they want content to appear, but they can only do this if they create content that uses major or minor versioning. For more information about versioning, see the article Plan versioning, content approval, and check-outs.

The scheduled start times and dates are initiated by a timer service that has a one-minute lag time. It runs on a 24-hour clock, and it continually checks for pages and items in the document library or image library that is ready for publishing.

Governance and scheduling in a content deployment scenario

The content deployment feature is designed for sites that use a multi-farm topology. For more information about multi-farm topologies see Design logical architecture and Deployment for Office SharePoint Server 2007. A multi-farm topology consists of separate authoring, publishing, and possibly staging farms. If you are implementing a multi-farm topology, you need to apply all the governance considerations outlined in this article for each farm in your environment.

Download this book

This topic is included in the following downloadable book for easier reading and printing:

•      Web Publishing and Planning Guide with Microsoft Office SharePoint Server (http://go.microsoft.com/fwlink/?LinkID=92330.)

See the full list of available books at Downloadable books for Office SharePoint Server 2007 (http://technet.microsoft.com/en-us/library/cc262788(TechNet.10).aspx.)

Plan content deployment

In this article:

•      What is content deployment?

•      About deployment jobs and paths

•      Content deployment security

•      Configuring content deployment

•      Record content deployment plans

What is content deployment?

Content deployment copies content from a source Microsoft Office SharePoint Server 2007 site collection to a destination site collection. The entire source site collection can be copied, or a subset of sites can be copied. In either case, content deployment is incremental by default, deploying only changed pages and related assets (such as images). A Quick Deploy feature supports deployment of a single page by authors.

Note:

For the content deployment Quick Deploy feature to work, the source and destination site collections must have the Office SharePoint® Server Publishing Infrastructure feature enabled.

In most content deployment scenarios, the source site collection, from which content is being deployed, is in a separate server farm from the destination site collection. Typically, the destination server farm (the "production" farm) will have tightened security to minimize the actions that can be done in the production environment, and it is not expected that authoring will be done in the production environment (changes to the production environment might be overwritten by the content deployment feature). In most content deployment scenarios, the source farm and the production farm are in independent Active Directory® directory service domains. For a full discussion of content deployment topologies, see Design content deployment topology.

In content deployment, the base URL of the source site collection can be different from the base URL of the destination site collection. The Content Deployment feature will fix links in the source content to work correctly in the destination location.

Content deployment only copies content — Web pages and resources used by the copied pages. It does not deploy programs, assemblies, features, configuration information such as web.config files. When a Web page is deployed, any items in the content database that the page depends on — such as images, style sheets, or layout pages — will also be deployed.

Content deployment deploys the most recent major and minor versions of a content item. For example, if version 2.7 of a Web page is being deployed, the most recent major version (2.0) of the page, along with the most recent minor version (2.7), will be copied to the destination site.

If an item has an associated publishing schedule (see Plan content approval and scheduling), the scheduling information is deployed along with the item so that the schedule is followed in the destination site collection. For example, if an item that is scheduled to be published at 6:00 A.M. is deployed at 3:00 A.M., site users on the destination site will not be able to view the content until 6:00 A.M.

About deployment jobs and paths

In content deployment, a content deployment job copies specified content on a specified schedule by using a specified path.

A content deployment path defines a source site collection from which content deployment can initiate, along with a destination site collection, and it also provides the following:

•      Authentication information that gives content deployment jobs permissions to the destination site collection. To deploy content to the destination site collection, deployment jobs must have SharePoint Central Administration credentials on the destination server. Jobs can connect by using the source farm's Central Administration application pool account, Integrated Windows authentication, or basic authentication.

•      Information about whether or not to deploy user names associated with the content (such as authors' names).

•      Information about how to deploy permissions on the content. See Content deployment security for details.

After a path is defined, one or more content deployment jobs can be defined, which deploy content by using the path. A deployment job specifies:

•      The sites within the source site collection to deploy.

•      The frequency at which to run the job and deploy the content.

•      Whether to deploy all content, or just content that has been changed or added since the last time the job ran.

•      Whether to send e-mail when a job succeeds or fails, and the e-mail address or addresses to use.

Each time a path is defined in a site that has the Office SharePoint Server Publishing Infrastructure feature enabled, a Quick Deploy job is created for use on that path. A Quick Deploy job is a deployment job that runs on a specified schedule (every 15 minutes by default) and deploys all Web pages in the site's Pages library that have been marked for deployment since the last time the Quick Deploy job ran. Any member of the Quick Deploy users group (which is created in sites that have the Office SharePoint Server Publishing Infrastructure feature enabled) can mark a Web page for deployment by using the Quick Deploy command.

Note:

It is possible to have a path defined in sites that do not have the Office SharePoint Server Publishing Infrastructure feature enabled. However, paths created in this way will not have associated Quick Deploy jobs. If you want to add a Quick Deploy job to a path that was defined in a site that does not have the Office SharePoint Server Publishing Infrastructure feature enabled, first enable the Office SharePoint Server Publishing Infrastructure feature on the source site collection, then delete the current path and recreate it. The path will then have a Quick Deploy job associated with it.

Content deployment security

Permissions to content on the destination server farm will usually be different from permissions to content on the source farm. In many publishing solutions, the destination farm authenticates users by using a different Active Directory domain than the one used in an authoring or staging environment, and there may not be a trust relationship between the two domains.

When configuring a content deployment path, you can choose from the following security options:

•      All   Deploys all security-related information with content, including role definitions, access control lists (which map users and roles to the content they have permissions to view or edit), and users. This option is useful if the same set of users has the same permissions on the source and destination farms. For example, when deploying from an authoring farm to a staging farm, this option might be best because the same users need access to both sets of content.

•      Role Definitions Only   Deploys role definitions and access control lists that map the roles to the content, but does not deploy users. In this option, the same roles apply in the source and destination server farms, but different users are assigned to those roles in each farm.

•      None   Deploys no security information. Security on the destination farm must be managed by the administrators of that farm by assigning users and roles to the farm's sites and content. For example, when deploying from a staging farm to a corporate Internet presence site, this option helps ensure that the security of the two farms is managed separately.

For more information about Office SharePoint Server 2007 roles and security, see Plan for security roles (Office SharePoint Server).

Configuring content deployment

Configure content deployment between two server farms by using the following steps:

1.   On the destination server farm, create an empty site collection based on the Blank Site template to receive the initial deployment job.

2.   On the destination farm, on the Content Deployment Settings page in Office SharePoint Server 2007 Central Administration, configure the farm to accept incoming deployment jobs, assign a front-end server as the import server to manage incoming deployment jobs, and specify whether or not to require encryption on the connection between the source and destination farms.

3.   On the source farm, on the Content Deployment Settings page, assign a front-end server as the export server to manage outgoing deployment jobs.

4.   On the source farm, on the Manage Content Deployment Paths and Jobs page in Office SharePoint Server 2007 Central Administration, create one or more deployment paths.

5.   On the source farm, on the Manage Content Deployment Paths and Jobs page, create one or more deployment jobs for each path.

6.   Run the initial deployment job to initiate the content on the destination farm.

7.   If the path does not deploy all security information, then on the destination farm, create the initial set of users, roles, and permissions on content and sites.

Record content deployment plans

Use the Plan content deployment worksheet (http://go.microsoft.com/fwlink/?LinkID=77804&clcid=0x409) to record your content deployment plans:

•      In the first section of the worksheet, record each server farm in your content deployment topology and note its purpose. For each farm, provide the URLs of the export server, the import server, or both. Also record the Active Directory domain used by the farm.

•      In the next section of the worksheet, record each path to create. For each path, supply the source and destination Web applications and site collections. Also record how much security information to deploy along the path: all, roles only, or none.

Worksheet

Plan content deployment worksheet (http://go.microsoft.com/fwlink/?LinkID=77804&clcid=0x409)

Download this book

This topic is included in the following downloadable book for easier reading and printing:

•      Web Publishing and Planning Guide with Microsoft Office SharePoint Server (http://go.microsoft.com/fwlink/?LinkID=92330.)

See the full list of available books at Downloadable books for Office SharePoint Server 2007 (http://technet.microsoft.com/en-us/library/cc262788(TechNet.10).aspx.)

See Also

Design content deployment topology (http://technet.microsoft.com/en-us/library/cc262004.aspx.)

Plan for collaboration sites

In this article:

•      About collaboration sites

•      Determine number of collaboration sites

•      Specific paths

•      Additional paths

•      Worksheet

About collaboration sites

With Microsoft Office SharePoint Server 2007, you have the ability to support collaboration sites in your environment. These sites do not need to be associated with a particular portal site collection or part of a publishing site collection. They can be stand-alone sites, available for teams or groups of users that need to collaborate on projects or share information, for either a short or a long period of time. For example, a team at an engineering firm might want a collaboration site to discuss current project status, assign tasks, or arrange group lunches, without having this internal information published to the corporate intranet.

Collaboration sites can be made available for searching from your portal or publishing site, so that information from these sites is not lost to your organization. However, for easier data recovery and maintenance, collaboration sites should be hosted either on a separate Web application or in separate content databases in the same Web application as your portal or publishing site.

You can create these sites for your users, or you can allow the users to create these sites on their own. For more information about planning site creation, see Plan process for creating sites.

Determine number of collaboration sites

Estimate approximately how many collaboration sites to expect in your environment, and how many such sites you are willing to support. If you require users to request a collaboration site, you can control how many are created. If you allow users to create their own collaboration sites, you will have many of these sites in your environment.

Specific paths

You have the ability to use specific paths in Windows SharePoint Services 3.0 to contain your SharePoint site collections, similar to the way that folders contain files or documents in the file system. By default, when you create a Web application, two paths are created for you:

•      Root path (/)   This is an explicit inclusion that can contain one site collection. For example, if you want a URL to appear as http://company_name/default.aspx, you would create the site collection at this root path.

•      Sites path (/sites)   This is a wildcard inclusion that can contain many site collections. For example, when you use the /sites path, the URL for a site named Site_A would be similar to http://server_name/sites/Site_A/default.aspx.

Note:

The name of the /sites path varies depending on the installation language.

Additional paths

You can also create additional paths, allowing you to group site collections. Then, when you create a site collection, you can choose to:

•      Create the site collection at the root of the Web application (if no site collection has already been created there).

•      Create the site collection under the /sites path.

•      Create the site collection under any additional paths that have been made available for that Web application.

In general, the /sites path should be sufficient for most installations. However, consider using other paths for the following situations:

•      You have a complex installation and anticipate having a large number of site collections, and you want to group similar sites together. For example, you could use /personal for individual user sites and /team for group collaboration sites, rather than using /sites for all.

•      You want to be able to add a filter to your firewall or router to constrain a specific namespace to internal access only. For example, you could expose the /team path for external collaboration but not /personal.

Worksheet

Use the following worksheet when you determine paths for sites:

•      Site paths worksheet (http://go.microsoft.com/fwlink/?LinkId=73149&clcid=0x409)

Download this book

This topic is included in the following downloadable book for easier reading and printing:

•      Web Publishing and Planning Guide with Microsoft Office SharePoint Server (http://go.microsoft.com/fwlink/?LinkID=92330.)

See the full list of available books at Downloadable books for Office SharePoint Server 2007 (http://technet.microsoft.com/en-us/library/cc262788(TechNet.10).aspx.)

Plan for multilingual sites

In this article:

•      Determine your multilingual needs

•      Plan for multilingual site deployment

Microsoft Office SharePoint Server 2007 has several features that enable you to support users in different regions or users who speak different languages. You can use these features to create Web sites in different languages, map internationalized domain names (IDNs) to your Web sites, and configure site variation settings that make it easy to track site updates and changes across several duplicate sites.

If your organization needs to support users in different regions or users who speak different languages, you need to do the following as you plan your overall site structure and navigation:

Determine your multilingual needs   This includes identifying all of the languages that you want your Web sites to support, understanding how Office SharePoint Server 2007 multilingual features can help you support users in different regions or users who speak different languages, and identifying the specific Office SharePoint Server 2007 multilingual features you want to use.

Plan for multilingual site deployment   This includes identifying the components that you need to deploy in order to support multilingual sites, such as language packs, operating system language support, and word breakers.

Determine your multilingual needs

To determine your multilingual needs, you need to:

•      Identify the languages that you need to support.

•      Identify the internationalized domain names (IDNs) that you need to support.

•      Determine whether you want to use the site variations feature.

Identify language requirements

Usually, you need to create sites in multiple languages if:

•      You want to provide Web site content to users in different regions.

•      You are required by government regulation or organizational policy to provide Web site content in more than one language.

Be sure to consult all potential site owners as you determine your language requirements, and be sure to list all languages that you might need to support in the future. It's easier to install language support during initial deployment rather than waiting to install language support when your servers are running in a full production environment.

Also, do not assume that you need to create a Web site or a site collection in multiple languages just because your document library contains documents in multiple languages. A document library can contain documents in multiple languages without requiring you to create Web sites or site collections in multiple languages. For example, the document library for an English site collection can contain documents that are written in French and documents that are written in Japanese.

Determine internationalized domain name mappings

Internationalized domain names (IDNs) are special domain names that can contain non-ASCII characters. Although the Internet's current Domain Name System (DNS) cannot handle host names that contain non-ASCII characters, a special encoding known as Punycode is used to convert the non-ASCII characters into a structured ASCII representation that the Domain Name System can handle. Office SharePoint Server 2007 enables you to use IDNs in your Web site addresses, but to do so you must use the alternate access mappings (AAM) feature to map the IDN to the Punycode representation of the IDN. When you do this, users can access your Web sites by using non-ASCII characters in Uniform Resource Locators (URLs). Assuming you configure alternate access mappings for IDNs correctly, Office SharePoint Server 2007 supports IDN URLs in:

•      Address bars that are used to navigate to sites.

•      Link fields and rich text boxes.

•      Links in 2007 Microsoft Office system clients.

•      Links that are created for lists and document libraries.

Office SharePoint Server 2007 does not support IDN URLs for Web pages that provide design functionality or administration functionality. For example, you can't specify an IDN for SharePoint Central Administration. In addition, Office SharePoint Server 2007 does not support IDN URLs for host header–based site collections or URLs that contain anything that System.Uri does not define as a character, such as some bidirectional language characters and complex script characters. System.Uri is a class within Microsoft .NET Framework 2.0.

If you want users to access your Web sites with IDN URLs, you need to configure alternate access mappings that map the internal URL (that is, your Web site's IDN URL) to the public URL (that is, the Internet-facing Punycode URL). To determine the alternate access mappings, do the following:

•      Create a two-column table, label the first column Internal (IDN) URL, and label the second column Public (Punycode) URL.

•      List each of the IDNs you intend to use in the first column. Be sure to contact every site administrator so you get a complete list of IDNs.

•      Determine the Punycode representation for each of your IDNs, and put the result in the second column next to the IDN. Most domain name registrars have free Web-based tools that will convert an IDN to its Punycode representation.

You can use this table to configure alternate access mappings when you deploy Office SharePoint Server 2007.

Note:

To access a Web site with an IDN URL, users must use a Web browser that supports IDN URLs, such as Windows Internet Explorer 7.0.

Determine whether you want to use site variations

Variations, a feature of Office SharePoint Server 2007, enable site administrators to make the same information available to specific audiences across different sites by maintaining customizable copies of the content from the source variation in each target variation. A variation consists of a label, which is a set of subsites and pages in a named tree within a site collection. For example, if you want four language variations of your site, you need to create four labels, one for each language. The site administrator selects one label to be the source label, which is where most of the new content enters the system. The corresponding labels are the target labels. For a multi-language site, you may want to use the primary language of your organization as the source label; you can only have one source label.

To ensure seamless synchronization, when a change is made to a page within the source label, you can set it so that the updated page is copied either manually or automatically to the target labels. The change can be as minor as correcting a spelling error or as major as a complete rewrite of the content. The copy appears as a new draft item in the target site; it does not replace the existing content. The content owner for the target label makes the decision to accept the change as is, translate the change, or ignore the change. The same applies if a user in the source label creates a new site or publishes a new page. Site administrators can choose to ensure the automatic or manual creation of a variation's corresponding site and pages.

To learn more about the variation feature, see Plan variations.

Plan for multilingual site deployment

To plan for multilingual site deployment, you need to identify which language features and components need to be installed or configured on your servers. These can include:

•      Language packs.

•      Supplemental language support.

•      Word breaker support.

Determine your language pack requirements

Based on your language needs, identify the language packs that need to be installed on your front-end Web servers. Language packs enable you to create SharePoint sites and site collections in multiple languages without requiring separate installations of Office SharePoint Server 2007. Language packs are installed on your front-end Web servers and contain language-specific site templates. When you create a site or a site collection based on a language-specific site template, the text that appears on the site or the site collection is displayed in the site template's language. For example, when you choose to create a site in French, the site's toolbars, navigation bars, lists, and column headings appear in French. Likewise, if you choose to create a site in Arabic, the site's toolbars, navigation bars, lists, and column headings appear in Arabic, and the default left-to-right orientation of the site changes to a right-to-left orientation to properly display Arabic text.

The list of available languages that you can use to create a site or site collection is generated by the language packs that are installed on the front-end Web servers. By default, sites and site collections are created in the language in which Office SharePoint Server 2007 was installed. For example, if you install the Spanish version of Office SharePoint Server 2007, the default language for sites, site collections, and Web pages is Spanish. If you need to create sites, site collections, or Web pages in a language other than the default Office SharePoint Server 2007 language, you must install the language pack for that language on your front-end Web servers. For example, if you are running the French version of Office SharePoint Server 2007 and you want to create sites in French, English, and Spanish, then you need to install the English and Spanish language packs on your front-end Web servers.

Note:

By default, when you create a new Web page within a site, the Web page uses the site's language-country ID to display text.

Language packs for Office SharePoint Server 2007 are not bundled or grouped into multilingual installation packages: you must install a specific language pack for each language you want to support. Also, language packs must be installed on all of your front-end Web servers to ensure that each Web server can render content in the specified language.

The following table lists the language packs that are available for Office SharePoint Server 2007:

Language

Language-Country ID

German

1031

Japanese

1041

Note:

Additional language packs might be available in the future. Also, if you need to support a language for which there is no language pack, you can still create a Web site or site collection in that language by creating custom Web pages.

Even though you specify a language for a site, some user interface elements such as error messages, notifications, or dialog boxes may not display in the language that you choose. This is because Office SharePoint Server 2007 relies on several supporting technologies — such as Microsoft .NET Framework, Microsoft Windows Workflow Foundation, Microsoft ASP.NET, and Microsoft SQL Server 2005 — and some of these supporting technologies are localized into only a limited number of languages. If a user interface element is generated by one of the supporting technologies, and if the supporting technology is not localized into the language that the site administrator specified for the site, the user interface element will appear in English. For example, if a site administrator creates a site in Hebrew and the Microsoft .NET Framework component displays a notification message, the notification message will not display in Hebrew because Microsoft .NET Framework is not localized into Hebrew. This situation can occur when sites are created in any language except the following: Chinese, French, German, Italian, Japanese, Korean, and Spanish.

In addition, some text might originate from the original installation language, which can create a mixed-language experience. This type of mixed-language experience is typically seen only by content creators or site administrators and is not seen by site users.

For more information about installing language packs, see Deploy Language Packs in Office SharePoint Server 2007 (Beta 2).

Determine supplemental language support requirements

Based on your language needs, you might have to install supplemental language support on your servers for complex script languages or East Asian languages. The components that support these types of languages are part of the operating system and must be installed before you install any Office SharePoint Server 2007 language features or components.

You need to install supplemental language support for complex script and right-to-left languages if you want to create Web sites in any of the following languages:

•      Arabic

•      Armenian

•      Georgian

•      Hebrew

•      Indic

•      Thai

•      Vietnamese

You need to install supplemental language support for East Asian languages if you want to create Web sites in any of the following languages:

•      Chinese

•      Japanese

•      Korean

If necessary, you must install supplemental language support on each of your servers, including your front-end Web servers and your application servers. For more information about installing supplemental language support, see the documentation for your operating system or see Deploy Language Packs in Office SharePoint Server 2007 (Beta 2).

Determine requirements for word breakers and stemmers

Word breakers and stemmers find word boundaries (word breaking) and conjugate verbs (stemming) in full-text indexed data. The rules for word breaking and stemming differ for different languages, and you can specify different rules for different languages. Word breakers for each language enable the resulting terms to be more accurate for that language. In the case where there is a word breaker for the language family, but not for the specific sub-language, the major language is used. For example, the French word breaker is used to handle text that is French Canadian. If no word breaker is available for a particular language, the neutral word breaker is used. With the neutral word breaker, words are broken at neutral characters such as spaces and punctuation marks.

As a best practice, make sure that you install the appropriate word breaker and stemmer for each of the languages that you need to support. Word breakers and stemmers must be installed on all of the servers that are running the Office SharePoint Server Search service.

The following table lists the languages for which Office SharePoint Server 2007 provides word breakers and stemmers:

Language

Language

Language

Arabic

Hindi

Portuguese Portugal

Bengali

Hungarian

Punjabi

Bulgarian

Icelandic

Romanian

Catalan

Indonesian

Russian

CHS

Italian

Serbian Cyrillic

CHT

Japanese

Serbian Latin

Croatian

Kannada

Slovak

Czech

Korean

Slovenian

Danish

Latvian

Spanish

Dutch

Lithuanian

Swedish

English

Malay

Tamil

Finnish

Malayalam

Telugu

French

Marathi

Thai

German

Neutral

Turkish

Greek

Norwegian

Ukrainian

Gujarati

Polish

Urdu

Hebrew

Portuguese Brazil

Vietnamese

Download this book

This topic is included in the following downloadable book for easier reading and printing:

•      Web Publishing and Planning Guide with Microsoft Office SharePoint Server (http://go.microsoft.com/fwlink/?LinkID=92330.)

See the full list of available books at Downloadable books for Office SharePoint Server 2007 (http://technet.microsoft.com/en-us/library/cc262788(TechNet.10).aspx.)

IV.  Plan for personalized content and sites

The articles in this chapter include:

•      Plan for personalized content and sites

•      Plan for people and user profiles

•      Plan for audiences

•      Plan My Sites

•      Plan for personalized Web Parts

Plan for personalized content and sites

In this article:

•      Plan for people and user profiles

•      Plan for audiences

•      Plan for personalized Web Parts

•      Plan for My Sites

•      Managing social networking

Microsoft Office SharePoint Server 2007 enables users to easily share information about themselves and their work. This sharing of information encourages collaboration, builds and promotes expertise, and targets relevant content to the people who need to see it. You can tailor content to each user in any organization, while enabling administrators to set policies to protect privacy.

These features are built upon a database of properties that integrates data about people from many kinds of business applications and directory services.

Good understanding and planning of personalization features is crucial for creating effective Office SharePoint Server 2007 applications.

Plan for people and user profiles

Profile Services is the shared service for people and personalization features. Profile Services connects to databases of information about people from various sources, and integrates that information into user profiles that are the basis for powerful personalization features. Planning for people and user profiles includes:

•      Planning connections to Profile Services.

•      Planning user profiles.

•      Planning personalization features.

•      Planning policies.

•      Planning to find people.

•      Using the People, profiles, and policies worksheet (http://go.microsoft.com/fwlink/?LinkID=73268&clcid=0x409).

For more information about planning for people and user profiles, see Plan for people and user profiles.

Plan for audiences

You use audiences to target content to the users who most need to see it, based on properties, organizational relationships, distribution lists, or SharePoint groups. Planning for audiences includes:

•      Planning key audiences.

•      Planning content targeting to audiences.

•      Using the People, profiles, and policies worksheet (http://go.microsoft.com/fwlink/?LinkID=73268&clcid=0x409).

For more information about planning for audiences, see Plan for audiences.

Plan for personalized Web Parts

You use personalized Web Parts to provide personalized content to sites and Web pages, starting with My Sites. Different Web Parts target content in different ways. Planning for personalized Web Parts includes:

•      Planning for public profile Web Parts.

•      Planning for personal site Web Parts.

•      Planning for personalization site Web Parts.

•      Planning additional Web Parts for My Site.

•      Planning for personalized Web Parts on other sites.

For more information about planning for personalized Web Parts, see Plan for personalized Web Parts.

Plan for My Sites

My Sites are special SharePoint sites that are personalized for each user. SharePoint sites have three distinct views: a public profile anyone can see, a personal site for each person for document storage and easy collaboration, and a unified experience linking to all personalization sites for that person. Planning for My Sites includes:

•      Using My Site templates.

•      Activating the My Site feature.

•      Planning My Site policies.

•      Planning for personalization sites.

For more information about planning for My Sites and the many kinds of personalized sites, see Plan My Sites.

Managing social networking

Social networking as a concept involves the ability for a technology platform to provide enhanced information and interaction capabilities with regard to people and resources. Social networking features include:

•      My sites

•      Colleagues Web Part

•      Colleague Tracker Web Part

•      SharePoint Sites, Links and Membership Web Parts

•      In Common With Web Part

•      Presence Information

For more information about managing social networks, see White paper: Managing social networking with Microsoft Office SharePoint Server 2007 (http://technet.microsoft.com/en-us/library/cc262436.aspx.)

Plan for people and user profiles

In this article:

•      About people and user profiles

•      Plan connections to Profile Services

•      Plan user profile properties

•      Plan people and relationships

•      Plan policies

•      Plan for finding people

•      Plan additional personalization functionality

•      Worksheets

Information about the users in your organization is stored in user profiles within Profile Services. Profiles Services is managed by a services administrator that has additional permissions that are not available to Shared Services Provider (SSP) administrators. Services administrators import information about users from directory services, such as Active Directory directory service and Lightweight Directory Access Protocol (LDAP).

When planning an initial deployment of Microsoft Office SharePoint Server 2007, you must plan connections between directory services and Profile Services, plan the properties of user profiles, plan the policies for displaying and changing user profiles, and plan how user profiles are used by other personalization features, such as personalized sites.

About people and user profiles

Before you can personalize the sites and content within your organization, you have to understand who the users are in your organization, how they work together, and what information they want to know about each other.

Information about users can come from Microsoft products and technologies, such as Microsoft Exchange, Active Directory, and Microsoft SQL Server. It can come from industry standards for tracking people, such as LDAP. It can also come from line-of-business applications, such as SAP. This enables you to bring all of the properties from these diverse data sources together to create unified and consistent user profiles across the organization.

The properties and data from these sources are stored in user profiles that are managed by Profile Services. User profiles identify connections among users, such as common managers, workgroups, group membership, and sites. In this way, the relationships among users in your organization can be used to encourage more efficient collaboration with colleagues and across teams. This collaboration includes the ability for users to find each other by using user-specific search features.

User profiles and user profile properties can also be used in implementing personalization features, such as building My Sites and content targeting. User profiles are more than just groupings of imported and custom properties about users in your organization. The properties are also used in the public page of My Site to display information about the relationships of each user to other users and content in your organization. This also includes a list of documents shared by each user, and the policies that define how information about users is displayed and shared.

Each user's public profile includes sections that have the following information:

•      Properties   Some of these properties are public and appear on the public profile page, but many of these properties are only visible to administrators. SSP administrators are the only users who can see and edit all user profile properties at the SSP level. Site collection administrators can see values of SSP-level properties in the user information list on the site collection, but cannot edit the actual user profiles and properties. They can edit site-level properties that are included in the user information list, but these are not added to user profiles stored in Profile Services.

•      Social networking   This includes the sites, distribution lists, and security group memberships for the user, and a separate section listing the user's current colleagues. When viewing someone else's public profile, users can also see the colleagues they have in common with that user.

•      Documents   A list of shared documents for the user, including documents on all sites where the user is a member, and organized in tabs by site.

•      Policies   This is available to administrators only unless the administrators grant users the ability to override certain policies. This section is used to set how the information in other sections is displayed, and who can see it.

All of these features are presented to encourage collaboration and reinforce connections among users in your organization. A quick review of the public profile tells the viewer who somebody is, what they are working on, and who they work with. It also enables administrators to make decisions about who can see all of this information and how it is shared. Good planning for users and personalization consists of considering the best way to deploy Office SharePoint Server 2007 to effectively present all of this information. This information should include:

•      A list of connection sources for user profiles, including Active Directory, LDAP, and business applications, such as SAP or Siebel that track users. Include the location, authentication type, accounts, and any other information needed to connect Profile Services to each source.

•      A list of the people features that are available from within user profiles, along with the policy setting, default access policy, and override and replication policies for each feature.

•      A list of user profile properties managed by the SSP administrator, along with the same policy information used for features. Add columns for each connection source to record the property mappings that you want to use.

•      A list of portal sites and site collections and a note recording who is planning the user information list properties for each site collection.

•      If the SSP administrator is planning user properties at the site collection level, record a list of properties and decide if they are best stored in the user profile so they are available for site collections across the SSP, or added later to the user information list for a site collection. The properties in user information lists in a site collection are based on replicated properties of user profiles, but are not connected to user profiles. Properties added to the information list are not stored in the user profile. These properties are not imported, so you do not have to worry about planning property mappings.

Worksheet action

Use the People, profiles, and policies worksheet (http://go.microsoft.com/fwlink/?LinkID=73268&clcid=0x409) to record this information.

Plan connections to Profile Services

Profile Services is used to connect user-based properties of data sources, such as line-of-business applications and directory services (primarily Active Directory and LDAP), with user profiles and properties that enable many of the features of Office SharePoint Server 2007.

Profile Services is available from the SSP administration pages. From the Import Connections link on the User Profiles and Properties administration page, you can connect directly to Active Directory or LDAP to import user profiles from those sources into Office SharePoint Server 2007. Services administrators select the properties from directory services to import to user profiles.

You can also add business data properties that contain information about users to existing user profiles by connecting to the Business Data Catalog, selecting a relevant entity from a registered business data application, and either mapping that entity to an existing profile property or adding it as a new property. These properties augment the existing profiles imported from directory services. You cannot create or import entirely new user profiles from the Business Data Catalog.

You can import the properties from all of these sources into user profiles by connecting to the relevant service or database and mapping the unique identifier for each property in the shared service to the unique identifier of the corresponding property in the business application. These connections can be made regardless of the authentication method used by the business application.

The service maintains the connections with the relevant business applications and updates the properties of user profiles during regularly scheduled imports from all relevant data sources. Data is not exported, however, so the user profile database cannot overwrite the source databases.

Planning for user profiles consists of starting with the default properties of user profiles in Office SharePoint Server 2007, identifying the connections to directory services that you need to supplement those properties with the information about users you already have, and considering additional business data that enables you to connect users to line of business applications. The key planning principle is consistency across data sources for all users in your organization.

Worksheet action

Use the People, profiles, and policies worksheet (http://go.microsoft.com/fwlink/?LinkID=73268&clcid=0x409) to record your planning decisions. Include a list of connection sources for user profiles, including Active Directory, LDAP, and business applications, such as SAP or Siebel that track users. Include the location, authentication type, accounts, and any other information needed to connect Profile Services to each source.

Profile Services enables you to collect information about users in your organization across directory services and business applications so that consistent and timely information is always available. Information about users is synchronized across the deployment to all site collections that use the same SSP. This information can also be used by personalization features to increase the value of collaboration and relationships in your organization.

Plan user profile properties

User profiles and properties are available to administrators from the User Profiles and My Sites section of the Shared Services Administration page. User profiles can be viewed by everyone else from the public profile page of each user's My Site.

Every site that uses the same SSP receives the same basic set of properties from the user profile store and displays them in the site's user information list. SSP administrators can add additional properties to the user information list across all site collections that use the same SSP. Administrators of each site collection cannot add properties to user profiles, but they can add properties to the user information list for certain users, depending on their particular business needs. When you plan for user profiles, you should consider several factors:

•      What are your existing and planned directory services? These services will form the foundation for user profiles. Decide which properties you will use for your core user profiles, based on those that are relevant across your organization (or across the SSP in an organization that has multiple sets of shared services). Properties that can be used when finding users, creating audiences to use when targeting content, and establishing relationships between colleagues and workgroups are essential. Start by reviewing the list of properties in directory services, followed by the default properties provided by Office SharePoint Server 2007, and modify that list according to these considerations.

Worksheet action

Use the People, profiles, and policies worksheet (http://go.microsoft.com/fwlink/?LinkID=73268&clcid=0x409) to record the planned properties.

•      Which line-of-business applications do you use that have information about users? Which properties can be mapped to the properties of directory services?

Worksheet action

Use the People, profiles, and policies worksheet (http://go.microsoft.com/fwlink/?LinkID=73268&clcid=0x409) to record these mappings, and note which mappings should have priority if there is a conflict. Be sure to add the line-of-business applications to your list of business applications that must be registered in the Business Data Catalog, and integrate them into business intelligence planning.

•      Based on your business intelligence planning, what other, non-user related properties of business applications might be useful for users in your organization? You can use these properties in personalized Web Parts to target business data based on audiences.

Worksheet action

Use the Site creation worksheet (http://go.microsoft.com/fwlink/?LinkId=73138&clcid=0x409) to record this information.

•      How many records of users are you planning to import from all sources, and how often do you want to schedule imports? The frequency of scheduled imports will depend on the number of records, how heavily you are using personalization features, and when you can schedule imports to have the least impact on performance and availability. Let your IT administrators know this information so they can include it in their deployment planning.

•      Which site-level user profile properties do you anticipate? In some organizations, this might be dictated centrally. At other organizations, this decision might be left to the discretion of each site collection administrator.

Note:

The My Site public profile replaces the Windows SharePoint Services 3.0 user profile when Office SharePoint Server 2007 is installed. If your initial deployment of Office SharePoint Server 2007 is installed over a Windows SharePoint Services 3.0 installation, be aware that your user profile information will be replaced, and plan accordingly.

Default user profile properties

•      Office SharePoint Server 2007 provides a set of default properties. You will want to review these properties and the policies that apply to them before deciding which changes to make, which properties to keep or remove, and which additional properties to create. For more details about default user profile properties and policies, see Additional user profile properties later in this article.

Additional user profile properties

The default user profile properties and the properties imported from connections to directory services and business applications can be supplemented with additional properties tracking key information that is not available from other sources.

You should plan to add properties at the SSP or site collection level depending on the business needs you identified in earlier planning. Key business needs can often be addressed by creating new properties that associate users with important business processes. For each major concept in your information architecture, consider whether there is a custom property that could be added to user profiles to link users in your organization to information about that concept. These properties can then be used by search to find users, or by personalization features to target content to users. Properties do not have to be visible in public profiles or My Sites, and properties can be useful for search or personalization without being displayed in public profiles or My Sites.

To limit the scope of your planning, prioritize the most important opportunities to improve user profiles. Focus on adding properties that enable key business needs or scenarios for each site collection. If the property relates to a less central business process for the site collection, or if the property seems relevant but does not address specific scenarios, wait until a specific need is identified during regular operations instead of planning to add the property during initial deployment. It is possible you might not need to add many new properties at all, but it is worth considering in case there are any obvious needs.

Configure property choice lists

Property choice lists enable Profile Services administrators to suggest acceptable values or limit the values for any property by listing the suggested or approved choices, which then appear to users in a list of values for the property. Property choice lists can either leave the choices up to the user, or define a list of choices that can be added manually or imported from (or exported to) a comma-delimited file. The latter type of property choice list, a defined property choice list, is a powerful way to suggest useful values for a custom property. You can also decide to prevent the inclusion of irrelevant values by limiting the choices to the defined list.

You can also use property choice lists to enable users to select multiple values for the same property. Many kinds of information about users involve more than one value. For example, you can use a property choice list to enable employees to list their professional certifications and other official qualifications, all of which appear as values for the property.

As an example of using a defined list to make information easier to find and promote collaboration, consider an organization that adds a custom property for areas of expertise. The SSP administrator identifies 10 top areas of expertise that are most relevant for users across the site collections that use the SSP. These areas are recorded as values in a defined property choice list for the Area of Expertise property. The same properties are mapped to managed properties by the search administrator, and the site collection administrators for each site collection can then identify Best Bets associated with keywords for each area of expertise. Now when users search for common keywords, experts for each relevant area will appear at the top of search results.

Worksheet action

Use the People, profiles, and policies worksheet (http://go.microsoft.com/fwlink/?LinkID=73268&clcid=0x409) to record whether the property uses a defined list, the property choice list values, and whether the list is open or closed. This enables you to more easily configure properties during initial deployment.

For more information about how user profile properties are used by search, see Plan search.

Plan people and relationships

The relationships among different users who use the sites in your organization are displayed in the public profile page for each user, and also in each user's personal site home page. SSP administrators can also see information about these relationships from the user profiles stored in Profile Services. This relationship information includes:

•      Site membership (a global view of all memberships for each user).

•      Distribution list membership.

•      Security group membership (including by default only e-mail–enabled groups).

•      Colleagues (who use both the My Colleagues Web Part and the In Common With Web Part).

When you plan the structure of your site collections, one key part you will plan is the membership for each site. Users are added as members by adding them or a group including them to the Member group for each site. Sites should be provided for all key business processes and divisions, and include the proper users.

Membership in distribution lists and security groups will exist for all but the newest organizations. The planning period for Office SharePoint Server 2007 is a good time to review user and group permissions to ensure that users have the correct permission levels to do their jobs. Planners for personalization features will want to talk to security planners to incorporate any changes into their own planning.

This is also a good time to review distribution lists and reorganize them to reflect information architecture planning. Redundant distribution lists can be discontinued, and new distribution lists can be created to meet additional needs.

Colleagues automatically include all people within each user's immediate workgroup — which includes one's manager, peers, and direct reports—so no specific planning is needed. In organizations that have key relationships that cross workgroups, managers or other users might want to add people to My Colleagues lists for certain workgroups. SSP and site collection administrators should encourage managers to make these changes after initial deployment, or allow managers earlier access to the initial deployment so they can verify the organizational hierarchy and make the changes to directory services.

Planning for users and relationships starts with planning for membership in sites, distribution lists, and SharePoint groups based on security considerations, your organizational hierarchy, and the roles of individuals and teams of users in your organization.

Consider how users currently collaborate, based on common managers or common tasks across workgroups, and then consider ways in which you might improve that collaboration by using new distribution lists or groups, or by adding users as colleagues. Consider other functionality that relies on membership in these groups. For example, membership can be used to target content to specific audiences. You can then decide how much of this information is shared and how it is shared by planning for policies.

Worksheet action

Use the People, profiles, and policies worksheet (http://go.microsoft.com/fwlink/?LinkID=73268&clcid=0x409) to record all planning decisions.

Plan policies

When planning for personalization of your portal sites, you must carefully consider the availability of information about users in your organization. Not all information is appropriate for everyone to see. Some information should only be available to users and administrators to preserve privacy. Other information can and should be shared freely with other users to encourage collaboration. The decision about what information to share is an important one that depends on the particular needs of each organization.

Office SharePoint Server 2007 provides a set of configurable policies so that Profile Services administrators can make the right information available to meet the needs of their organization. Policies might vary between SSPs, so it is a good idea for the planning team to review collaboration needs across the organization to develop a plan for implementing the right mix of policies.

Every personalization feature and property exposed in user profiles and personal sites has a recommended default policy that can be customized based on the needs of each organization. Each policy is made up of two parts:

•      Policy setting   Some personalization features provides information that is critical for key business processes in an organization. Other information might be inappropriate for sharing across an organization. Some information will be useful for some users to share, but not other users, so that different policies are needed for different users. The planning team can decide to change the policies by feature or property to meet the business needs of their organization. The specific options are:

•      Enabled   The feature is visible to users other than the SSP administrator, depending on the default access setting.

•      Required   This property must contain information, and the information is shared based on default access. Forms containing these features or properties cannot be submitted until the required information is provided. For example, the Manager property is often mandatory so that it can be used to provide information for the My Workgroup feature and audiences based on an organization's reporting hierarchy.

•      Optional   The property is created and its values might or might not be provided automatically. Each user decides whether or not to provide values for the property or leave the property empty. For example, the telephone number of a user is often left blank, and each user can decide whether or not to provide a telephone number visible to other users. The My Colleagues feature is optional, but rather than being blank the list of colleagues that includes everyone in the current workgroup is visible by default to users who have access. Users can decide to opt out by removing colleagues from the list, or expand the list by adding additional colleagues.

•      Disabled   The property or feature is not visible to anyone but the SSP administrator. It does not show up in personalized sites or Web Parts, and cannot be shared.

•      User Override   Properties that have the User Override option selected allow users to change the default access policies for user profile properties. With this option selected, each user can decide who can see the values they entered for the property. If this option is not selected, only administrators can change default access settings.

•      Replicable   Properties and features that have the Replicable option selected can be replicated to other SharePoint sites, but only if the default access is set to Everyone and the User Override option is not selected.

•      Default privacy setting   The privacy setting determines who can see information for a particular personalization feature. Available settings include:

•      Everyone   Every user who has viewer permissions to the site can see the relevant information.

•      My Colleagues   Every user in this user's My Colleagues list can see the information for this user.

•      My Workgroup   Every colleague in the user's workgroup can see the information.

•      My Manager   Only the user and the user's immediate manager can see the information.

•      Only Me   Only the user and the site administrator can see the information.

Plan policies for people features

Some organizations will allow individual SSP administrators to configure policies, and other organizations will want to implement a consistent policy across the organization. By setting expectations for policies during initial planning, you can avoid later confusion, surprises, and misunderstandings. Whatever your decision, you should make the policies clear to users in your organization when they begin using Office SharePoint Server 2007, so they can expect that certain information about them and their work will be available to others.

Policies can vary depending on the purpose of the sites in your SSP. Consider your information architecture planning and site hierarchy when deciding which policies to use. For example, a site based around collaboration is likely to have a less restrictive set of policies than a site designed as a document repository.

Also consider who is using your sites. Customer-facing sites will have entirely different policy considerations compared to collaboration sites, and a central portal site for a large organization might have less need to share information than a departmental site. Many of these issues will be handled as part of security planning, but privacy policies and security considerations are sufficiently related that it is a good idea to consider them together.

Policies that have fewer restrictions mean that users will be viewing public profiles more frequently, which affects how often you must update user profiles and compile audiences. In organizations that have a large number of users, this could affect performance and capacity planning.

Worksheet action

Use the People, profiles, and policies worksheet (http://go.microsoft.com/fwlink/?LinkID=73268&clcid=0x409) to record policy decisions for every feature and property.

Site and SSP administrators should share policy decisions with IT professionals in the organization. Some issues that could conceivably affect IT planning include:

•      The expected frequency of updating user profile information.

•      The expected frequency of compiling audiences.

•      The effect on performance and capacity of servers running Profile Services.

•      The effect on security planning.

For more information about the default policies and available policy settings, see Policies for Profile Services.

Plan policies for the properties of user profiles

Properties — such as account name, preferred name, work telephone number, department, title, and work e-mail address — are mandatory by default because in most organizations those are key methods of enabling collaboration and developing organizational relationships. Many of them are also used by Office SharePoint Server 2007 in enabling other features, such as colleagues and audiences.

By default, users cannot override these properties because it is important to Profile Services administrators that access to information stay consistent and predictable.

By default, most properties are visible to everyone, but sensitive information, such as non-work telephone numbers, are limited to users who have been selected as colleagues. A couple of other properties are of private interest only.

Different organizations might have different needs. For example, a company that has many employees in the field might find that mobile telephone information is important for everyone to see. Other organizations might keep all non-work telephone numbers completely private. Organizations focused around small-team collaboration might want to limit more properties to a core group of colleagues.

When planning the policy setting for a property, consider the following factors:

•      Consider making a property required if:

•      The property is used by key user features.

•      The property is associated with key business data for applications in the Business Data Catalog.

•      The property is used in creating audiences.

•      Administrators for Profile Services expect consistent and meaningful values for the property.

•      Consider disabling a property if:

•      The property will rarely be used.

•      The property will distract from more important properties. Note, however, that you can change the display settings for properties to hide them from users viewing public profiles, the Edit Details page, or the My Colleagues Web Part.

•      Consider selecting optional if you decide to provide default values for properties, but still want users to be able to remove the information, or if you want to allow each user to provide the relevant value for the property.

When planning default access policy, consider the following factors:

•      If you want to use the property in search so that users can be found by searches for the property, set the default access policy to Everyone. Properties that have more restrictive access will not be used by search.

•      If the property is useful across workgroups and other divisions in your organization and does not contain sensitive information, consider making it visible to everyone.

•      If the property is mostly useful for collaboration within an immediate workgroup or within a particular group of individually selected colleagues, consider making it visible only to colleagues.

•      If the property is of a private or sensitive nature, consider making it visible only to the immediate manager, or in some cases, only the individual user. What is considered private information can vary from organization to organization.

When deciding whether to allow users to override the policies for properties, consider the following factors:

•      Configure key user profile properties that need consistent values and clear administrator control so that users cannot override them. Override should be enabled only when the access to a property is not central to the needs of an organization.

•      Users should be able to override the access policy for a property if the sensitivity of the information can vary between different users, and the administrator cannot predict a single policy for all users. For example, an employee's hire date might be considered private to one employee and a point of pride to another.

•      Users should be able to override properties that might be relevant to different groups of users over time, by changing the default access policy.

•      For more information about the default policies and available policy settings, see Policies for Profile Services.

Policy replication

Another factor to consider is what information will be replicated from the SSP to user information lists on SharePoint sites. You can limit replication of information by making policies more restrictive, or by limiting the information that is replicated. Only properties can be replicated. Properties that have the Replicable option selected are replicated to other SharePoint sites, but only if the default access is set to Everyone and the User Override option is not selected.

Every site that uses the SSP will use the replicable properties in user information lists. Properties set to Everyone that are not replicable can be seen in the public profile, but those properties do not appear in user information lists. If a property is not replicated, the values for the property in the user information lists for SharePoint sites remain, but changes are no longer replicated and must be made by the site collection administrator.

Worksheet action

Use the People, profiles, and policies worksheet (http://go.microsoft.com/fwlink/?LinkID=73268&clcid=0x409) to record which properties you want in the user information lists.

Plan for finding people

Office SharePoint Server 2007 enables users to find other users based on their expertise and role in the organization. By default, the following methods of finding people are enabled:

•      People search scope   A search scope is provided that limits search results to the public profiles in the user profile store for the SSP. Regardless of the search terms used, only users who match those terms appear in search results.

•      People tab in the Search Center site   The People tab in the Search Center site provides options for finding users. You can find users by name or related subject, or by users-related properties, such as title and department.

•      Advanced search   Users can be found by advanced searches that search by user profile property values. Every user profile that matches the value of the selected profile appears in search results.

•      From values for user profile properties   You can find users without explicitly searching by clicking values for users to find other users who have the same value for the property. These properties can be displayed in user profiles, in user information lists, in SharePoint lists, or in general search results.

•      Refined searches   You can refine search results for a people search to include only results for users who have a specific value in their user profiles.

•      Group by social distance   By default, all searches for users are grouped by social distance. That is, users who work most closely with the user viewing search results are grouped first, followed by users more distantly.

Regardless of the search method used, the people search results contain links to the public profiles of each user, and links to contact them by e-mail or messaging programs.

When planning for users, you might want to consider supplementing the default people search scope and Search Center tab with customized search scopes and tabs for more specific groups of users.

SSP administrators will want to consult the information architecture and site hierarchy to identify key business concepts that might relate to specific groups of users that might be sought out by users across sites. Then, they can work with the SSP administrator for search to develop search scopes and people search tabs for those specific groups. They can also use their knowledge of the user profiles they manage to identify other useful groups of users and create additional specific search scopes and search tabs for those groups.

Site collection administrators can create site-level search scopes for users who are members of their site collection.

Worksheet action

Use the People, profiles, and policies worksheet (http://go.microsoft.com/fwlink/?LinkID=73268&clcid=0x409) to record planned search scopes and search tabs.

People search planning also feeds back into user profile planning. Initial planning might reveal individuals or groups of users that you would like to make easier to find, but the right properties might not exist to allow those users to be found easily.

Worksheet action

Use the People, profiles, and policies worksheet (http://go.microsoft.com/fwlink/?LinkID=73268&clcid=0x409) to record these new properties to be implemented during deployment.

Plan additional personalization functionality

Profile Services is used to provide personalized information to My Sites and other pages by using audiences and targeted Web Parts.

For more information about planning audiences, see Plan for audiences.

For more information about My Sites, see Plan My Sites.

For more information about targeted Web Parts in general, see Plan for personalized Web Parts.

Worksheets

Use the following worksheets to plan for people and user profiles:

•      People, profiles, and policies worksheet (http://go.microsoft.com/fwlink/?LinkID=73268&clcid=0x409)

•      Site creation worksheet (http://go.microsoft.com/fwlink/?LinkId=73138&clcid=0x409)

Plan for audiences

In this article:

•      About audiences

•      Plan key audiences

•      Worksheet

You use audiences to group the users in your organization so that you can personalize information to ensure that it is as relevant as possible. From the Manage Audiences page for the Audiences Shared Service in Microsoft Office SharePoint Server 2007, you can create and manage up to 10,000 audiences and use them to target content in all of the site collections that use that shared service.

When planning audiences during initial deployment, you want to identify a small set of key audiences based on your evaluation of content needs, your information architecture planning, the structure of your site collections, and the users associated with each site collection.

About audiences

Before planning audiences, you should understand how audiences are defined. Audiences are defined by Shared Services Provider (SSP) administrators in the Application Management page for the core services of the server farm providing the Audiences Shared Service. There are three types of audiences:

•      SharePoint groups   You define SharePoint groups by associating each group with a set of permission levels for each site collection, and then adding members to groups based on their user accounts. Administrators create new SharePoint groups during initial configuration and deployment. Audiences based on SharePoint groups target content to users that are members of the selected groups. SharePoint groups used for audiences can be specific or general, but should be built from sets of users specific to the needs of the business processes and audiences relevant for each site collection.

•      Global audiences   Global audiences are audiences based on the properties of user profiles, which are managed by SSP administrators. Global audiences target content to users based on properties in their user profiles.

•      Distribution lists and security groups   Distribution lists can be created by different users in an organization, depending on the policies of each organization. Audiences based on distribution lists target content to users who are members of the included distribution lists.

The properties of distribution lists and security groups used for audiences must be imported from Windows security, and mail servers and directory services, such as Microsoft Exchange Server, Active Directory directory service, and Lightweight Directory Access Protocol (LDAP). These properties, including distribution lists, are imported when user profiles are imported. For more information about user profiles, see Plan for people and user profiles.

The properties in user profiles and their underlying sources change frequently. To ensure that audiences remain current, SSP administrators must compile audiences. They schedule compilations regularly to update audiences, and might also compile audiences at other times if necessary. Compilation settings and scheduling for audiences in Office SharePoint Server 2007 use the Microsoft Windows SharePoint Services Extensible Job Service.

Plan key audiences

Because audiences are built on other administration features, good planning for audiences is a multi-stage process that includes planning for all of these features. The basic steps to plan are:

1.   Plan for Windows security.

2.   Plan for user profiles.

3.   Plan for distribution lists and SharePoint groups.

4.   Plan for sites and site collections.

5.   Plan for audiences based on groups, distribution lists, and properties in user profiles.

Complete the first four steps before you begin planning for audiences. When you start planning for audiences in an initial deployment, you will record all distribution lists, SharePoint groups, and the central purpose for each site and site collection. Then, you consider how best to group all of that information to create a relatively small number of audiences that reflect the important groups within your organization based on all of these criteria.

We recommend that you consider creating additional SharePoint groups that are planned with audiences in mind. Each site collection will generally have a focused set of business processes associated with specific groups of users, and custom SharePoint groups can be used to define each audience as precisely as possible in combination with existing SharePoint groups, Windows security, user profile properties, and distribution lists. By the end of the audience planning process, you should have a list of audiences that meet the needs of the groups of users who are using each site collection.

Audience rule

Description

User profile properties

These include a logical operator that is used to evaluate the property.

Reporting structures

These are recorded in the user profile and are visible by default in My Site Web Parts.

Memberships

These are in a source group, such as a distribution list or a Windows security group. Memberships are also displayed by default in My Site.

You can also create audiences directly from distribution lists or SharePoint groups, without including them as audience rules.

You typically will have a natural starting point when you create audiences. For example, your existing working teams, cross-group projects, key business processes, and site structure include groups of users that can be easily translated to audiences by using audience roles based on user profile properties, reporting structure, or membership.

Audience planning can also identify potential improvements in planning for distribution lists, user profile properties, SharePoint groups, and reporting structure. If you want to target some users as a group and there are not existing SharePoint groups, distribution lists, or user profile properties, it is a good idea to plan for adding those groups, lists, or properties.

Worksheet action

Use the People, profiles, and policies worksheet (http://go.microsoft.com/fwlink/?LinkID=73268&clcid=0x409) to record planned audiences as you identify them. Record all planned content targeted to each audience. Record any underlying distribution lists, groups, and properties of user profiles that must be added before you create audiences.

Plan content targeting to audiences

Creating audiences is only half of the story. You make use of audiences to target content, to highlight relevant information for the right users, and to reduce the presentation of irrelevant information to the wrong users.

You target content in the following ways:

•      By list item or Web Part.

•      By using Trusted My Sites host locations.

•      By using the My Site navigation bar to target personalization sites.

•      As part of the discovering servers feature.

•      By filtering Web Parts by audience.

Target by list item or Web Part

Any Web Part can be targeted to a specific set of audiences by adding those audiences to the Target Audiences text box in the Advanced section of the Web Parts tool pane.

Audiences can target content to users in many ways by using different Web Parts. One of the best ways to target content in site collection pages is by using the Content Query Web Part.

The Content Query Web Part is provided by default for certain SharePoint template pages, such as portal site areas and team sites, and can target content in the following ways:

•      Group results by options or audience, and is often used to target both by Web Part and by list item.

•      Display list items from multiple hierarchical levels, and includes better rendition of audience information.

•      Target specific list items to specific audiences by using the Content Query Web Part. Then, even when those list items appear in Web Parts or pages, only the individual list item is targeted and not the entire page or Web Part.

You can also target content in My Sites to audiences by using several different Web Parts. For more information about those Web Parts, see Plan for personalized Web Parts.

Target by using Trusted My Site host locations

In some scenarios, such as a global deployment with geographically distributed shared services, some users can have access to one or more My Site host locations. In these scenarios, SSP administrators for each SSP manage a list of Trusted My Site host locations across all SSPs, and then target each location to the audiences of users who need to view those locations.

Trusted My Site host locations are processed in priority order within the list so that users see the personalized information that is most relevant for the My Site that they are viewing, and personalization information is available even if individual SSPs are unavailable. During the initial deployment, this should be fairly straightforward. In most deployments, there is only one SSP and no need to configure this feature.

Worksheet action

Use the People, profiles, and policies worksheet (http://go.microsoft.com/fwlink/?LinkID=73268&clcid=0x409) to plan for and record Trusted My Site host locations based on the number of SSPs in your deployment and the need for users to see personalized information across SSPs.

For more information, see Plan My Sites.

Target by using the My Site navigation bar

My Site links to personalization sites in the My Site navigation bar can be targeted to specific audiences. Links are added to the My Site navigation bar by SSP administrators. In many cases, a personalization site might be relevant for one group in your organization but not everyone. The SSP administrator can target links so that they appear only for users for whom the personalized content in the site is relevant. For more information, see Plan My Sites.

Target links published to Office client applications

Just as personalization sites can appear on the My Site navigation bar based on targeting of the personalization sites on the personalization links list, it is possible to target the links on the Links Published to Office Applications page. This list, available from the User Profiles and My Sites section of the Shared Services Administration page, is used to include links to Office Server sites from Office client applications. Examples of links that show up in client applications include:

•      Sites, including team sites, portal sites, and project workspaces.

•      Data connection libraries.

•      Document libraries or document repositories.

For example, if a personal site directory is added to this list, that location is provided as a choice whenever someone shares a document from an Office client application. This enables users to use the same personal site from multiple client computers. Similarly, data collection libraries added to the list show up in the Microsoft Excel client, and document libraries show up whenever saving documents from any Office client application. By default, links to Office client applications appear for all users in the SSP. Those links become much more powerful when they are targeted to users who most need them, so that users only see the personal sites, data connection libraries, and document libraries relevant to their own work.

When planning the initial deployment of Office SharePoint Server 2007, consider each of these kinds of links. Plan to add links to cover sites, data connection libraries, and document libraries for all the site collections by using the SSP.

Worksheet action

Use the People, profiles, and policies worksheet (http://go.microsoft.com/fwlink/?LinkID=73268&clcid=0x409) to record each of the links and the relevant audience for each link.

Filter by audience

A group of Web Parts known as filters can be connected to other Web Parts so that they only display results based on certain properties. The exact properties available vary from filter to filter, but one of the available options is to filter by audience. Filters are usually connected to business data Web Parts, so this allows you to target business data based on audience. Unlike simple Web Part personalization, the audience property passed by the filter to the business data Web Part can be used in relatively complex business analysis or calculations when displaying results.

Filters are commonly used in dashboards and report-enabled sites, such as the Report Center site, but they can be used on many kinds of sites, including personalization sites. For more information about filters, see Plan dashboards and filters.

Worksheet

Use the following worksheet to plan for audiences:

•      People, profiles, and policies worksheet (http://go.microsoft.com/fwlink/?LinkID=73268&clcid=0x409)

Plan for personalized Web Parts

In this article:

•      About personalized Web Parts

•      Plan for public profile Web Parts

•      Plan for personal site Web Parts

•      Plan for personalization site Web Parts

•      Plan additional Web Parts for My Sites

•      Plan for personalized Web Parts on other sites

•      Worksheet

When planning personalization and site structure across the Shared Services Provider (SSP) and within each site collection, it is helpful to understand how Web Parts are used to personalize sites.

The three templates used by My Sites each have a set of default Web Parts and a gallery of additional Web Parts that can be added to each site. It is also possible to use many of these same personalized Web Parts on other pages. You can also develop custom Web Parts that extend the personalization features that are available in Microsoft Office SharePoint Server 2007.

About personalized Web Parts

SharePoint sites are composed of Web Parts. Personalized Web Parts are those Web Parts that filter or display information based on the user profile and related properties of the user viewing the site, or a particular user in the organization. The typical template for site collections contains a My Site link that can be used by every user who uses the site collection to view, share, and collaborate by using personalized information.

Web Parts can be added by administrators and site designers, or anyone else who has the correct permissions. When these users select Edit Page on the Site Actions menu, the current page opens in design mode. Designers can add Web Parts by clicking Add a Web Part tool in the zone where they want to add the Web Part, and then selecting a Web Part from the gallery that appears.

Although it is not necessary to plan a personalized Web Part for every site in the organization, it is a good idea to plan for the Web Parts that you want to include in the My Site templates, and for any personalized Web Parts that you want to add to key sites in each site collection, such as the Report Center site.

Worksheet action

Use the Site creation worksheet (http://go.microsoft.com/fwlink/?LinkId=73138&clcid=0x409) to record the personalized Web Parts for each site. If there are settings that need to be detailed for any Web Part, record that information as well, so that it can be used as a reference during initial deployment.

Plan for public profile Web Parts

Although many of the administration settings for public profiles are managed by SSP administrators, the Web Parts for public profiles are managed by the administrator of the site collection that hosts My Sites.

Default Web Parts for public profiles

The default Web Parts for the public profile page template are:

•      In the top zone: A Web control that includes the user's name, title, and department.

•      In the left zone:

•      User Properties Web control   This custom Web control is used only in the public profile. It provides information about each user, including a description if one has been provided. Details based on user-provided profile properties that link to related searches on the People tab of the Search Center site include contact information, availability based on meetings scheduled in Microsoft Outlook, and organization hierarchy.

•      Documents Web Part   This Web Part is available only in the public profile, but is similar to the SharePoint Sites Web Part in personal sites. All of the shared documents for the user are grouped in tabs by site, including My Site and every site or subsite in any site collection where that user is a member. Within the My Site tab, there is a link that opens a page of search results that contains every document authored by the user. Within each tab is a list with a link to every document and document location for that particular site, and a link to the site's home page.

•      Links Web Part   This Web Part is a list of links shared by the user. Two actions that are visible to site administrators and users viewing their own public profiles are shown in the following table.

Action

Description

Add Link

Add a link to the list in this Web Part and the drop-down list on the top menu bar, organized into groups.

Manage Links

Edit settings for this link.

•      In the right zone:

•      In Common with [user] Web Part   This Web Part is used only in the public profile. It contains the nearest manager, colleagues, and memberships held in common between one user and other users viewing the public profile, based on the visibility policy. If a user is viewing his or her own public profile, it explains what other users see.

•      Memberships Web Part   Memberships are displayed to users based on the visibility policy. Memberships include sites, SharePoint groups, audiences, and distribution lists. Administrators and users viewing their own public profile (depending on policy) have a Manage Memberships action in this Web Part.

•      Colleagues Web Part   Colleagues are displayed to users based on the visibility policy. Administrators and users viewing their own public profile (depending on policy) have the following actions: Manage Colleagues, Add Colleagues.

All of these Web Parts are customized for My Site. These Web Parts are not available in galleries unless they are exported from galleries available in other pages. A different version of the Colleagues Web Part is available for other pages in galleries as the Colleague Tracker Web Part.

Additional Web Parts for public profiles

Site collection administrators can add or remove Web Parts from the public profile. The design mode of the public profile page includes Add a Web Part Web Parts in each zone on the page. These parts do not appear in the site, but are used to add other parts to each zone. For more information about adding Web Parts to public profiles, see Plan additional Web Parts for My Sites later in this article.

Plan for personal site Web Parts

Personal sites are managed by each user, but site collection administrators can make changes to the personal site template to add or remove Web Parts and promote different personalization, business intelligence, and collaboration features of Office SharePoint Server 2007.

Default Web Parts for personal sites

The default Web Parts for the personal site template are:

•      In the top zone: A Web Part that includes the user's name, title, and department.

•      In the left zone:

•      Getting Started with My Site Web Part   This part, based on the Content Editor Web Part, contains links to important tasks to get users started using My Site, and can be removed by the user when it is no longer needed. Actions linked here include editing the public profile and adding colleagues.

•      SharePoint Sites Web Part   This Web Part is only available in the personal site, but is similar to the Documents Web Part in public profiles. All of the documents and tasks for the user are grouped in tabs by site, including My Site and every site or subsite in any site collection where that user is a member. Within the My Site tab is a link that opens a page of search results containing every document authored by the user. Within each tab is a list with a link to every document and task, its location, as well as a link to the site's home page.

•      In the right zone:

•      My Calendar Web Part   This contains tasks and meetings for the user.

•      Colleagues Web Part   Colleagues are displayed, along with the following actions: Show all colleagues, Modify alert settings.

•      Memberships Web Part   Memberships are displayed, along with a Manage Memberships action.

All of these Web Parts except the My Calendar Web Parts are customized for My Site, and do not appear in any Web Part galleries. The Memberships Web Part is only available for other sites if it is exported. A version of the Colleagues Web Part is available for other pages in galleries as the Colleague Tracker Web Part, and a different version of the SharePoint Sites Web Part is also available. The My Calendar Web Part is also available in galleries for other sites.

Additional Web Parts for personal sites

Each user can add or remove Web Parts from the home page of the personal site. The personal sites Web Part galleries include all of the Web Parts available in the gallery for public profiles except for the Document Library Web Part, and several additional Web Parts for personalizing e-mail, lists, and business data presentation. For more information about adding Web Parts to the personal site, see Plan additional Web Parts for My Sites later in this article.

Plan for personalization site Web Parts

A personalization site is a site created by using a template that filters and targets the information displayed on the page based on the identity of the current user viewing the site. Personalization sites can use many of the Web Parts provided in Office SharePoint Server 2007, along with any other Web Parts you might create or import from galleries of Web Parts created by others. Some Web Parts are used more often, or provide functionality that is specific to the personalization experience.

Default Web Parts for personalization sites

The default Web Parts for the personalization site template are:

•      In the top zone:

•      Current User Filter Web Part   This Web Part enables the author to pass the current user's login name to connected Web Parts.

•      Profile Property Filter Web Part   This Web Part enables the author to pass the current user's preferred name to connected Web Parts.

Both Web Parts are provided by default and are visible to personalization site authors.

No other Web Parts are provided by default. Each personalization page uses different Web Parts that are connected to the existing filters so that the information on the page is personalized.

Additional Web Parts for personalization sites

The owner and administrator of each personalization site can add Web Parts to the page. Personalization sites can use all of the Web Parts available in the gallery for personal sites except for the Shared Documents, Shared Pictures, and My Pictures Web Parts.

Personalization pages are built upon the Current User Filter Web Part and the Profile Property Filter Web Part. The main Web Parts added to personalization sites will be parts that are connected to the filters so that whatever content they display is filtered based on either the user name or the preferred name of the current user.

Connected Web Parts are often business data Web Parts, key performance indicator (KPI) Web Parts, and lists and libraries Web Parts. The decision about which parts to include depends on the business needs of your organization, the purpose of the site collection containing the personalization site, and the information most needed by the members of the personalization site.

Personalization sites for initial deployment will be more effective if they are focused narrowly towards a single purpose. When you plan for each site collection, some will contain personalization sites. Each personalization site should be focused around a shared set of business processes and information that reflects a central purpose of the site collection.

For example, a human resources site that exists to provide information about employee benefits, time reporting, and company policies will have a personalization site that provides Web Parts that personalize that information. A call center personalization site might present Web Parts linked to the customer service database, personalized so that users can see their own open issues, customer service statistics, and so on. A site collection used for authoring Web site content might contain lists and libraries of content for each of a writer's current projects, along with core personalization parts, such as e-mail and calendar Web Parts.

You can categorize personalized content in the following three ways, and most personalization sites will focus on one type.

•      Content personalization   Content is managed by users on another team and published to a site that has a personalized view for each member.

•      Data personalization   There is an underlying business application associated with a key business process, allowing each user to see a personalized view of the data at any time.

•      Personalized views of group project content   Users within the same group or team work together to produce content, and they have a common personalization site to display the work and relevant content for each user.

For complex site collections, personalization might include all of these categories, but it is a good idea to start with a simplified set of personalization sites and extend the sites over time as needs evolve.

Beyond the initial filter Web Parts on personalization pages, you might want to add additional filter Web Parts to further filter data and content on personalization sites. For more information about these filters, see Plan additional Web Parts for My Sites later in this article. The same parts are available as are available in public profiles and dashboard sites.

The administrator of each site collection that has a personalization site should make a note of the content they want to personalize for that site based on the purpose of the site collection, and then identify the Web Parts and filters they will need to deploy each site.

Plan additional Web Parts for My Sites

The additional Web Parts available to add to the pages and templates for My Sites fall into several groups:

•      Suggested Web Parts

•      List and libraries Web Parts

•      Business data Web Parts

•      KPI Web Parts

•      Filter Web Parts

Each of these groups of Web Parts raises different questions during public profile planning.

Because personal sites are designed and administered by each user, there are not as many considerations for planning them as there are for personalization sites and public profiles. However, there are some factors you should consider to plan for added functionality in personal sites according to the needs of your organization.

Plan for suggested Web Parts on My Sites

Some Web Parts are specifically suggested for specific zones in the personal site and personalization sites when users add Web Parts to a page in design mode. Personalization is built into most of these Web Parts, which are intended to be used in pages to provide personalized information that users need to accomplish their tasks. They involve e-mail, workspaces, and commonly used lists, libraries, and pages. Other Web Parts can be personalized by using filters or audiences, but suggested Web Parts are inherently personalized.

Note that the public profile does not include any of these suggested Web Parts, because it is not intended to be a place where users learn information about themselves and their work, but a place for other people to learn information about them.

The suggested Web Parts for personal sites are:

•      Colleague Tracker Web Part (This is the same as the default Colleagues Web Part.)

•      Content Editor Web Part (For example, the Getting Started with My Site Web Part.)

•      Page Viewer Web Part

•      Image Web Part

•      My Pictures Web Part

•      My Links Web Part

•      My Workspace Sites Web Part

•      Outlook Web Access Web Parts, including:

•      My Calendar (This is one of the default Web Parts for personal sites.)

•      My Inbox

•      My Mail Folder

•      My Tasks

The suggested Web Parts for personalization sites include all of these Web Parts except the Content Editor Web Part, the Page Viewer Web Part, the Image Web Part, and the My Pictures Web Part. Each of these Web Parts (except for My Pictures) is available in the gallery but not suggested.

To encourage the use of Outlook Web Access Web Parts in personal sites, you can add more of those parts or add mail server information before deployment so the parts will be fully functional from the start without any additional steps required for each user. These Web Parts can also be useful in personalization sites based around collaboration or business data. The distinction is that in personal sites, these parts are central to its purpose as the personalized page for each user, while personalization sites use these parts in a more secondary role to supplement other parts.

You can add the Content Editor Web Part to the personal site template to provide text and links that suggest ways for users to develop their personal sites by adding new Web Parts or by using the existing Web Parts. This is already done by default in the Getting Started Web Part, but you can customize this and even add Content Editor Web Parts focused on different ways to improve personal sites. You can link to personalization sites, business-critical lists, and other resources that can be used in personal sites that users might otherwise not find as easily. If information is particularly critical, you can use the Page Viewer Web Part to display the page within a Web Part of each personal site.

Personalization sites are less likely to use Content Editor Web Parts or Page Viewer Web Parts because they are designed as single pages that provide personalized views for every member, and content in those parts cannot be filtered by the current user. However, it can still be useful for some personalization sites to use Content Editor Web Parts to provide important information for users. Similarly, if the purpose of the site is collaboration, a Page Viewer Web Part for a page central to that collaboration can be helpful.

The My Workspace Sites Web Part displays a list of all workspaces and sites within the personal site or personalization site. In the case of personalization sites, if the purpose of the personalization site involves collaboration or viewing other sites related to the personalized view, you can create those sites and include links here so that users can quickly and easily move from personalization information to related content and tasks. The My Links Web Part can be used to provide links to other relevant content other than subsites of the personalization site. Although users can add their own links to this Web Part, administrators might decide to add and target important links during initial deployment.

As with any Web Part, the core personalization parts can be targeted to audiences, so you can use one personalization site that has some parts targeted to different groups of users. This is useful when the personalization site has the same broad purpose, but different groups of users have different related links, or only some of them need to see workspace sites.

Plan for lists and libraries Web Parts on My Sites

Lists and libraries Web Parts are used by all three My Site templates to include links for relevant lists and libraries. Each template has a different set of available list and libraries Web Parts.

The one Web Part of this kind for the public profile is the Document Library Web Part. This Web Part can be used to associate a library with the public profile. That document library appears on every public profile for every user, and is visible to all users who view the page. The documents in this library are typically documents of general interest for users who view public profiles, such as a frequently asked questions list.

The lists and libraries Web Parts for personal sites are:

•      Cache Profiles Web Part

•      Reports List Web Part

•      Reusable Content Web Part

•      Shared Documents Web Part

•      Shared Pictures Web Part

•      Site Collection Documents Web Part

•      Site Collection Images Web Part

•      Style Library Web Part

Users can also add Web Parts to their personal sites based on lists created in the personal site. Those are the only lists and libraries Web Parts available by default in the galleries for personalization sites. You can add additional lists and libraries Web Parts to the personalization site galleries by exporting them from sites and galleries where they are available. Some Web Parts are associated with certain features of Office SharePoint Server 2007 and are only available when the related feature is enabled. For example, the business data Web Parts appear when the Office Server Enterprise feature is activated.

You can add parts for important lists to the default template of the personal site. For example, you can add key documents and pictures to Shared Documents and Shared Pictures Web Parts, which encourages users to add more documents and pictures to those shared lists over time. You can also add Web Parts for KPI lists that are already linked to real business processes that provide meaningful status indicators as part of the initial personal site experience, and add some lists as default personal site content so they can be added by users as Web Parts later on.

These parts are even more useful in personalization sites to add lists for important content that is relevant to the purpose of the site. A list Web Part can be added that is linked to the Current User Filter Web Part so that it displays performance information that is personalized for each user who uses the site.

Plan for business data Web Parts on My Sites

The business data Web Parts available in the gallery for all three templates of My Site are:

•      Business Data Actions Web Part

•      Business Data Related List Web Part

•      Business Data Item Web Part

•      Business Data List Web Part

•      Business Data Item Filter Web Part

•      IView Web Part

•      WSRP Consumer Web Part

The first four business data Web Parts are used to display information based on the properties of applications registered in the Business Data Catalog. The Business Data Item Filter Web Part filters the other Web Parts within the page based on values found in the Business Data Catalog. The IView and WSRP Web Parts support the presentation of data from SAP and WSRP subsites, respectively.

Additional business data Web Parts available for the personal site and personalization sites, but not public profiles, include:

•      Excel Web Access Web Part (listed in the Default gallery category)

•      SQL Server 2005 Analysis Services Web Part

The Excel Web Access Web Part is used to provide information from a specific worksheet directly within the Web Part by using Excel Calculation Services. The SQL Server 2005 Analysis Services Web Part is available for personal sites and personalization sites for rendering data directly from SQL Server 2005 Analysis Services.

Business data Web Parts provide a way to present information from data sources, such as business applications registered in the Business Data Catalog, to provide key information about users in sites. In the context of public profiles, you might want to provide business data relevant to the user profile that is being viewed, and the person who is viewing the user profile. Depending on the part used, this can include lists of business data, key properties of business data, and important business actions. For personalization sites, you can add business data Web Parts for business applications that are central to the purpose of the site, and connect those parts to the Current User Filter Web Part so they provide information personalized for each user. The Business Data Associations Web Part, Business Data Details Web Part, and Business Data List Web Parts each provide distinct views of business data.

You use the Business Data Actions Web Part to include links to perform custom business actions that the administrator of the Business Data Catalog has planned and created based on the common tasks associated with core business applications. Business actions provide a particularly useful possibility for public profiles. For example, you can create a custom action that returns business data for the user profile that is being viewed. Employees viewing public profiles in a call center site collection might be able to click View Customer Service Records for this Person. Anyone could click someone's name anywhere in the site collection, and then click this action, and be provided with a page linked to the customer service database that would display a list of customer service records for that user.

This is also useful for personalization sites. In the same call center site collection example, a personalization site could use Business Data Actions Web Parts to provide actions to resolve customer service records, open existing records, or transfer cases to other service departments, all without having to start a separate application or find another page.

You can also add business data Web Parts to the personal site template to encourage individual users to use those Web Parts. By providing links to personalization sites that also use that Web Part, you can demonstrate the possibilities for viewing business data Web Parts so that users are more likely to add the Web Parts in their personal sites.

When planning My Sites, you can easily go overboard by adding too many actions and other business data. As always during initial planning, only include the most important business data for each site.

For more information about business data Web Parts, see Plan business data Web Parts.

For more information about business data actions, see Plan business data actions.

Plan for dashboard Web Parts on My Sites

Because KPI Web Parts are commonly used in dashboards, they are also called dashboard Web Parts in My Site Web Part galleries. Dashboards, also known as multi-report summary pages, contain one or more business intelligence Web Parts, such as business data Web Parts, Excel Web Access Web Parts, or KPIs that can be filtered at the page level by various properties to get a unified view of data and content from several sources.

The dashboard Web Parts are:

•      KPI Details Web Part

•      KPI List Web Part

These Web Parts are available in the Web Part galleries for all three My Site templates.

KPI Web Parts can be useful for presenting personalized performance information for key business goals. For public profiles and personalization sites, these might be status indicators that apply to individuals and not entire groups or organizations. For example, you could create a KPI (by using either a KPI List Web Part along with other KPIs, or as a KPI Details Web Part) that is based on an Excel workbook of sales reports for all employees. When you add that Web Part to a personalization site, the current user filter will only calculate the KPI for the current user. The same KPI on another page without the same filter would calculate the KPI for all users whose sales are documented in the source Excel workbook.

If the KPI is of interest only to some users, such as users within the same workgroup, you can target the Web Part to an audience defined to include only the users in the workgroup. For example, if the sales KPI is based on a spreadsheet from the New York sales office, you can target the KPI Web Part to only show results for users working in that office, and use another targeted KPI Web Part for users in another office.

You can use the KPI List Web Part to display several status indicators within one Web Part, such as number of sales, the dollar value of sales, improvement over the last quarter, and customer satisfaction. The KPI Details Web Part only shows a single KPI, such as number of sales.

You can also add a KPI, possibly targeted by team, that shows results at the team level and is not connected to the current user filter. This information might still be useful in a personalization site because it provides information that relates to other Web Parts that are personalized. This is a common scenario for KPI Web Parts on personalized sites because KPIs tend to indicate performance information calculated across groups rather than for individuals.

As with any site planning, before you add a KPI Web Part you should consider the purpose of the site collection that contains the public profile or personalization site. If the site collection is a team site for a sales team, sales data KPIs make sense. If it is a site collection intended for collaboration across a larger organization, the KPI will have to match the breadth of that collaboration or be targeted if it is included at all. If it is a site for human resources information, which is not used by any group in the organization to meet its goals but instead simply provides policies and business applications, you probably will not use a KPI Web Part.

After deciding whether to use KPIs, make decisions about who should see what data, and use audiences and Current User Filter Web Parts to tailor KPIs to your organization.

Consider whether particular KPIs are more appropriate in public profiles or within personalization sites. Users are more likely to look for information about a particular business process in the Report Center site or a personalization site designed for that purpose, rather than in their own or someone else's public profile page. Only include KPIs in public profiles to reinforce the most important indicators for your organization, or when the information is something that is central to the role of each user who views the public profile.

Remember to plan for the data sources that provide information for KPIs. For more information, see Plan key performance indicators.

Plan for filter Web Parts on My Sites

Filter Web Parts are available for all three My Site templates. The default filter Web Parts available are:

•      Authored List Filter Web Part

•      Business Data Catalog Filter Web Part

•      Current User Filter Web Part

•      Filter Actions Web Part

•      Page Field Filter Web Part

•      Query String (URL) Filter Web Part

•      SharePoint List Filter Web Part

•      SQL Server 2005 Analysis Services Filter Web Part

•      Text Filter Web Part

Plan for miscellaneous and custom Web Parts on My Sites

Personal sites can select the following miscellaneous Web Parts:

•      Contact Details Web Part

•      Form Web Part

•      XML Web Part

Personalization sites can use those Web Parts, and can also use the following additional Web Parts:

•      From the Default group in the Web Part gallery:

•      Advanced Search Box Web Part

•      Category Results Web Part

•      Category Web Part

•      People Search Core Results Web Part

•      Search Box Web Part

•      Search Paging Web Part

•      Search Statistics Web Part

•      Search Summary Web Part

•      Search Core Results Web Part

•      Search High Confidence Web Part

•      Site and Documents Web Part

•      Tasks and Tools Web Part

•      This Week in Pictures Web Part

•      Top Sites Web Part Web Part

•      From the Miscellaneous group in the Web Part gallery:

•      Content Query Web Part

•      Summary Link Web Part

•      Table of Contents Web Part

The Form Web Part is used to connect a simple form to other Web Parts on the page. Along with the XML Web Part form, you can add significant interactivity to a personalization page.

Most of the other miscellaneous Web Parts enable you to add search functionality right into the personalization site. When you plan for search, consider how you want personalization sites to work with the content sources and search scopes you have created for the site collection and SSP as a whole.

In addition to the Web Parts that are available in galleries for the My Site templates, you can create custom Web Parts. For more information about designing custom Web Parts, see the Microsoft Office SharePoint Server 2007 Software Development Kit (SDK) (http://go.microsoft.com/fwlink/?LinkID=71218&clcid=0x409).

Plan for personalized Web Parts on other sites

You can personalize Web Parts on other pages in several ways, including:

•      Using the Current User Filter Web Part on a dashboard or any other site to filter data from other Web Parts based on the identity of the current user.

•      Using the Business Data Catalog Filter Web Part to filter business data Web Parts based on properties of business data types in applications registered in the Business Data Catalog, such as people in SAP.

•      Using the IView Web Part specifically with SAP to present personalized data from IView in SAP.

•      Adding one or more audiences to the Target Audiences text box in the Advanced section of the Web Part tool pane.

Worksheet

Use the following worksheet to plan for personalized Web Parts:

•      Site creation worksheet (http://go.microsoft.com/fwlink/?LinkId=73138&clcid=0x409)

Plan My Sites

In this article:

•      About My Sites

•      Plan for personalized sites

•      Worksheet

To effectively plan My Sites, you must decide the following:

•      Whether or not to activate the My Site feature.

•      Which users you want to have My Sites.

•      Where to store and manage personal sites within and across Shared Services Providers (SSPs).

•      Which templates will be used in My Sites and which Web Parts will be used to extend their functionality.

•      Which policies will be applied for viewing user profile information in the public profile.

•      Which personalization sites to create on other site collections.

About My Sites

In Microsoft Office SharePoint Server 2007, My Sites are special SharePoint sites that are personalized for each user. My Sites are enabled by default, and every user in an organization has a unique My Site.

A My Site is composed of three types of My Site pages, each with its own template:

•      Public profile page   Anyone in the organization can see a public profile page, which is hosted in the My Site template.

•      Personal site   This is for storage of each user's content and for easy collaboration with colleagues. Each personal site has a private home page that only that user can see.

•      Personalization site   This is owned by site collection administrators or users designated as site administrators by the site collection administrator, and contains information personalized and targeted to the user. Each My Site provides a personalized navigation bar that connects personalization sites with other parts of the My Site.

My Sites also include personalized views of links, documents, and other Office SharePoint Server 2007 features.

Each user can view the My Site by clicking on the My Site link in the portal site. The My Links menu includes links to all sites of which someone is a member, and links to pages where users can add to and manage the links.

Users can navigate between their personal site home pages, the public profile, and personalization sites by clicking the tabs in the My Site top link bar.

The common features of all personalization sites include:

•      Branding   This is inherited from the main site, and replaces the site banner logo with the My Site logo.

•      Top and left navigation sections   The left pane contains a picture of the user and the Quick Launch, and the top link bar is specialized for My Sites.

•      Four Web Part zones   The four zones include top, bottom, middle left and middle right.

The administrator of each part of My Site has a Site Actions menu that has the following actions available:

•      Create   The administrator can add a library, list, or Web page on the site collection that contains My Sites. This library typically contains content, such as pictures for users, lists for business data Web Parts, and other documents and files needed for public profiles and My Site.

•      Edit Page   The administrator can edit the Web Parts for the page.

•      Site Settings   The administrator can change the settings for the page.

When planning My Sites, ensure that there is a common look that sets them aside from other pages in the site, while still being consistent with the overall appearance of your site. The templates used for My Sites can be customized just as any other template or site. Before you modify the templates for My Sites, it is a good idea to understand the default appearance and functionality of the templates, and the individual Web Parts used by default or available for each site.

For more information about templates and Web Parts in My Sites, see Plan for personalized Web Parts.

About the public profile page

The public profile page, also known as the My Site Public Page, is the public view of each user's user profile and My Site. The public profile is accessed by clicking any link to a user within a portal site or site collection, including links in search results. Users can link to edit their own public profiles on the My Profile link in their My Sites.

The layout of public profiles is designed by the site collection administrator for the site that hosts My Sites, and possibly a designer. Though the same user profile is used in every site collection in a single SSP, the look of the public profile can vary from SSP to SSP. Some consistency of the public profile is a good idea, but different sites created for different purposes have good reasons to vary some of their content and appearance. The default layout includes:

•      Quick Launch   Links to shared lists, such as Shared Documents and Shared Pictures, and My Site subsites, such as workspaces. These links enable users who visit someone's public profile to quickly view shared content.

•      As seen by drop-down list   Seen by users who view their own profile, and has options to see how the public profile looks for different groups of users. The drop-down list is a good way to check that selected policies are working properly.

•      Web Parts   These are in each of the four zones.

For details about the Web Parts available for the public profile, see Plan for personalized Web Parts.

From their own public profile pages, users can return to the personal site by clicking My Home on the My Site top link bar. Users who view public profiles for other users will not see a My Site top link bar because they are not viewing pages in their own My Sites.

About personal sites

The personal site is each user's My Site home page. The personal site is private by default, so the home page of each personal site can only be viewed by the site owner. The personal site is the page that appears when users click the My Site link for the site, and can also be accessed by clicking My Home on the My Site top link bar by users who want to view their own public profiles. It is also the page that appears when users click links to their own name.

Because the home page of each personal site is private, there are no policy considerations during planning. Each user that has a personal site is administrator of the site and can create and edit other pages, change the default layout or customize the page to personal taste, and change site settings. The default layout for personal sites includes:

•      Quick Launch links to:

•      View All Site Content page.

•      Public profile page and sections within the public profile.

•      Shared documents and pictures visible to other users on the public page.

•      Lists, discussions, surveys, and sites added by the user and visible to other users on the public page.

•      Web Parts in each of the four zones of the home page, and contain private content viewed only by the user of the personal site.

•      Recycle Bin for the personal site, which is visible only by the user of the personal site.

All of the Quick Launch links except the Recycle Bin are visible to other users on the public page.

Because each user selects the Web Parts to use for the home page of the personal site, there are fewer planning considerations for Web Parts.

For more information about Web Part planning for personal sites, see Plan for personalized Web Parts.

The other pages, lists, libraries, and workspaces created in the personal site can be shared and viewed by other users, so in that sense the personal site is not entirely private. The planning considerations for subsites and other shared content are no different from those of any other site, except that decisions are up to each user during normal operations and not an organized planning process before initial deployment.

Users can use the links on the My Site top link bar to switch between the personal site, the public profile, and relevant personalization sites that have been linked by the SSP administrator or that they have personally pinned to the top link bar.

About personalization sites

Personalization sites target information personalized for every member of the site by using personalized Web Parts and user filter Web Parts. Each personalization site is created by a site collection administrator or another user that has site creation permissions.

Links to personalization sites can be added to the My Site top link bar by SSP administrators, and appear for every member of each site, or targeted to specific audiences. Links to personalization sites can also appear in the top navigation pane and the left pane of the All Site Content page of the main site. Personalization sites are registered by the SSP, so that personalization sites from all site collections that use the same shared service all appear in My Site, depending on the targeted audience of the personalization site link.

Individual users can add links to other personalization sites that have not been registered by an administrator, but those sites only appear on that user's My Site top link bar.

Personalization sites can be branded by using either the main site logo or the My Site logo. The default layout for personalization sites includes:

•      Picture of the user above the Quick Launch.

•      Quick Launch links, including links to the View All Site Content page and the Recycle Bin for the personalization site.

•      Filter Web Parts in the top zone.

•      A Content Editor Web Part in the middle left zone that explains the purpose and use of personalization sites.

•      A Site Actions menu. The top link bar for Site Settings contains an option to pin the personalization site to the My Site top link bar.

Each site uses filter Web Parts that connect the Web Parts on the site to each user who view the page, but there are no default Web Parts and each personalization site uses a different mix of Web Parts.

For more information about personalization site Web Parts, see Plan for personalized Web Parts.

Each personalization site can also include subsites, such as workspaces, lists, and libraries that are relevant to the personalization site.

Users can use the links on the My Site top link bar of personalization sites to go to the personal site or the public profile of My Site, and to go to any other linked personalization sites. They can also use the breadcrumb navigation to view other parts of the main site.

Plan for personalized sites

Different organizations have different personalization needs. When planning My Sites, you can consider several factors:

•      My Site feature   Enabled by default in Office SharePoint Server 2007, but some organizations might want to disable it.

•      Personal sites in the SSP   Where are personal sites stored and managed, and how My Sites will work across multiple SSPs.

•      Policies   Which policies will you apply to information shown on each user's public profile.

•      Personalization sites   Which personalization sites are needed, and who will create and own each site.

Worksheet action

Use the Site creation worksheet (http://go.microsoft.com/fwlink/?LinkId=73138&clcid=0x409) to record decisions regarding the sites and site collections for your organization. Also, remember to note who is likely to own managing the public profiles for each site collection. The personalization sites that you plan should be included on a per-site basis by site collection administrators, who will probably have more detailed worksheets planning the organization of the site collections they own. The site collection administrator will want to note plans for ownership of personalization sites that are created during initial deployment.

Activate the My Site feature

The My Site feature is activated by default at the Web application level. Some organizations might decide to deactivate the feature for the farm or for individual sites. When deciding whether to use My Site, the following factors are important:

•      Site purpose

•      Web application performance

The most important factor to consider when deciding whether to use the My Site feature is the purpose of your sites. Sites that are designed to enable users to work and share information easily will almost certainly benefit from My Sites. Each user in the organization will be able to easily find users and information related to them.

On the other hand, sites that are not built upon collaboration might not benefit from personal sites. An example is a large document repository that does not contain team sites or workspaces, does not target content by audience, and is not a place where users go to find or share organizational information about themselves or their colleagues.

Because My Site is activated at the Web application level, it is usually a good idea to retain the feature if any of the sites on the Web application will benefit from using it. One exception to this is a Web application that is optimizing for other functionality of Office SharePoint Server 2007. Although the My Site feature is not particularly resource-intensive, Web applications that have a large number of users, a high volume of content, and relatively little need for personalization or collaboration might benefit from deactivating the My Site feature. Administrators planning for personalization should talk to IT administrators in the organization about performance and capacity considerations if this is a concern.

As soon as the My Site feature is activated, any user profiles from an existing installation of Windows SharePoint Services 3.0 are replaced by the public profiles that are part of My Site. A My Site link is added to the top menu bar for all sites in the site collection, along with the My Links menu.

You activate or deactivate the My Site feature from the Manage Web application features link in the SharePoint Web Application Management section of the Application Management tab in Central Administration. You can also limit the ability to create My Sites by removing the right from the authenticated users group for the SSP, or deleting that group from the Personalization Services Permissions page.

You can turn off My Sites at the site collection or site level by deactivating the Office SharePoint Server Standard feature in Site Settings, but you will also lose the search functionality for the site. This can be a good option for sites, such as large document repositories. In that case, the documents on the site can still be crawled so that they appear in searches from other sites in the server farm, without having to support My Sites features that are not relevant for the site but are available on other sites in the farm that have kept the features active.

Plan for My Sites in the SSP

SSP administrators for personalization consider the interaction between personalization sites across all site collections in all farms that use the SSP, and how personalization sites are made available within My Sites. They also make decisions about the presentation of the My Site as a whole. Their considerations include:

•      Personalization links

•      Trusted My Site host locations

•      Personal sites settings

These settings are managed from the User Profiles, Audiences, and Personal Sites section of the SSP.

Personalization links

Any user who has permission to create sites within a site collection can select the personalization site template, but not all of these sites will be relevant for all users in the site collection, much less all users within the same SSP. Personalization sites that are relevant for users across the SSP can be added as links to the My Site top link bar. Every user who uses My Site will see links to all personalization sites that were linked by the SSP administrator, regardless of site collection, except for personalization site links that are targeted to specific audiences.

Personalization sites planned for initial deployment are important enough to add to the My Site link for the users who use the corresponding site collection, but not all users in the SSP will consider the same personalization sites to be relevant. My Site links to personalization sites can be targeted to specific audiences so they are only seen by relevant users.

For information that applies to everyone in an organization, such as human resources information, a My Site link to the personalization site might make sense for everyone. For a personalization site that shows personalized content to the sales team, it makes sense to target the My Site link so that it appears only for members of that team, or for members of the sales site collection.

Worksheet action

Use the Site creation worksheet (http://go.microsoft.com/fwlink/?LinkId=73138&clcid=0x409) to record decisions regarding which personalization sites will be linked in My Site navigation. Also record decisions about targeting to audiences.

For more information about audience planning, see Plan for audiences.

Trusted My Site host locations

From the Shared Services Administration page, you can add additional trusted personal sites locations. This enables SSP administrators to select My Site locations from multiple site locations. This is needed in any scenario that has more than one SSP, such as a global deployment that has geographically distributed sets of shared services, where each SSP contains a distinct set of users. By listing the trusted personal site locations for all other SSPs, you can ensure that My Sites are created in the correct location for each user. This also enables you to replicate user profiles across SSPs.

Personal sites settings

By default, My Sites are stored on the server that contains shared services. Public profiles are created and stored on the Web application that contains the Shared Services Administration pages for the SSP, and personal sites are stored on the default Web application for the server. However, you can change the Web application so that My Sites can be stored on the default Web application, the Web application for the SSP, or any other Web application.

Personalization sites are created on individual site collections that can be on any farm that uses the same SSP. The settings for those sites are controlled by the administrators of those respective sites, by using the same Site Settings pages that are available for any site.

Settings for personal sites are managed by the SSP administrator, who can manage settings that are unique for those sites. Personal sites settings appear on the Manage Personal Sites page, which is available from the My Site settings link on the Shared Services Administration page. Manageable settings include the following:

•      Personal site services   By default, personal sites are stored on the (same as My Site host) Web application for the server that runs the shared services, typically that uses port 80. The public profiles are also stored on the Web application for the SSP by using a different port. You can decide to set a different provider for personal site services so that personal sites are stored on a different Web application. This can be a different application on the same server or another server.
The Web application must already exist. Existing sites are not migrated and must be moved manually. For large organizations, it might make sense to store personal sites on a separate server. When planning personal sites, SSP administrators should talk to IT administrators about the number of users and expected use of personal sites so that the appropriate choice can be implemented during initial deployment.
If your deployment process involves using a test server before deploying to a production server, realize that restoring a backup image of the first server to the second server will not update the location of personal site services. You will have to update this property to use the personal site services on the second server.

•      Personal site location   This is the Web directory where personal sites are stored and accessed. It is a good idea for this to be memorable, and it should not duplicate directories already used for other purposes. Otherwise, you do not have to plan for this setting.

•      Site naming format   There are three options for the format, used to resolve possible conflicts between user names in multiple domains. If your users are in a single domain, you can format by using a simple user name. If your users are in multiple domains, it makes sense to use both domain and user name in the format. The option to resolve conflicts by formatting the second instance of the same user name by including the different domain name should be reserved for after initial deployment, such as when you are adding users from additional domains to a deployment that previously used accounts from a single domain.

•      Language options   In a multilingual deployment, you can allow users to choose the language of their personal site.

•      Default reader site group   You can select which users are members of the SharePoint Reader group for personal sites. By default, this Reader group is the same as the site collection that contains personal sites, but you can limit access based on specific policies of your organization.

Plan My Site policies

When considering how to implement My Sites, you must consider how much control you want to give individual users over the visibility and presentation of their personal information, and which policies you want to set for them based on the needs and policy decisions of your organization.

For more information about policy planning, such as what information to provide for all public profiles, and what information to change based on per-site needs, see Plan for people and user profiles.

Plan for personalization sites

When planning for personalization sites, consider the following factors:

•      How personalization sites will fit into the broader information architecture and site structure of your organization.

•      Which site collections will benefit from personalization sites.

•      Who will own each personalization site.

•      Which Web Parts you will use to target content to users of the personalization site.

Incorporate personalization sites into site collections

Site collection administrators, SSP administrators, and business planners should consider the information architecture planning to eliminate duplication and identify the most important personalization sites to implement during initial deployment.

It is not necessary to plan for all possible personalization sites. Most sites will be created as needed during ongoing operations. The sites identified during planning for initial deployment should be those that identify content needs or are relevant to key business processes, and can also benefit from personalization.

Good candidates for high-priority personalization sites are those that present a personalized view of key business applications. For example, a human resources site might have a personalization site with Web Parts that link to time reporting, benefits, and other similar business applications. A call center site might present information specific to each customer service representative on its personalization site. A sales reporting site tracking activity in Microsoft Office Excel 2007 might have a personalization site that filters columns based on each user's role on the sales team.

For each of those sites, any number of personalization sites is possible, but only a small number will be central to the purpose of each site. In many cases, one personalization site can capture the key personalized information for the central purposes of the site. If a potential personalization site does not correspond to the central purpose of the site, it can wait until after initial deployment.

Site collection administrators are responsible for planning personalization sites in their site collections and incorporating them into the overall structure of their sites. They identify the personalization sites to plan and implement during initial deployment, based on the central purposes of the site collection.

By default, personalization sites are added to the top bar navigation links for the site collection. Site collection administrators decide whether to keep those navigation links. If a personalization site is important enough to include during initial deployment, it is probably important enough to include at the top level of navigation. However, each organization will organize site navigation differently, and in some cases personalization sites might not be appropriate for the top level.

Worksheet action

Use the Site creation worksheet (http://go.microsoft.com/fwlink/?LinkId=73138&clcid=0x409) to record decisions regarding the organization of personalization sites.

Plan owners of personalization sites

Personalization sites are managed by their owners at the site collection level, and not within the SSP.

Plan Web Parts for personalization sites

Personalization sites can use any of the Web Parts provided by Office SharePoint Server 2007, along with any other Web Parts you might create or import from galleries of Web Parts created by others. Some Web Parts are used more often, or provide functionality that is specific to the personalization experience.

For more information about planning personalization Web parts, see Plan for personalized Web Parts.

Worksheet

Use the following worksheet to plan My Sites:

•      Site creation worksheet (http://go.microsoft.com/fwlink/?LinkId=73138&clcid=0x409)

V.  Plan workflows

The articles in this chapter include:

•      Plan workflows

•      What are workflows?

•      Plan workflows: Next steps

Plan workflows

A workflow is a feature of Microsoft Office SharePoint Server 2007 that moves documents or list items through a specific sequence of actions or tasks related to a business process. Workflows can be used to manage common business processes such as document review or approval.

In this section:

•      What are workflows?   This article introduces the types of business processes that workflows can facilitate and describes the workflows included in Office SharePoint Server 2007.

•      Understanding workflow   This article provides an overview of workflow in Windows SharePoint Services 3.0 and the 2007 Office system.

•      Plan workflows: Next steps   This article contains links to topics that will help you in your workflow planning.

•      Workflow Security in Windows SharePoint Services 3.0 and Microsoft Office SharePoint Server 2007 (white paper) (http://technet.microsoft.com/en-us/library/dd239178.aspx) This white paper provides an overview of security considerations when implementing workflows using either Windows SharePoint Services 3.0 or Office SharePoint Server 2007.

What are workflows?

In this article:

•      About business processes

•      Workflows in Office SharePoint Server 2007

About business processes

Much of the work in any enterprise is done by using business processes that depend on the flow of information or documents. These business processes require the active participation of information workers to complete tasks that contribute to their workgroup's decisions or deliverables. In Microsoft Office SharePoint Server 2007, these types of business processes are implemented and managed by using workflows.

Examples of business processes that could be facilitated by workflows include:

•      Contract approval   Guiding a proposed contract among members of an organization who must approve or reject it.

•      Expense reporting   Managing the submission of an expense report and associated receipts, reviewing the report, approving it, and reimbursing the submitter.

•      Technical support   Guiding the progress of a technical support incident as it is opened by a customer, investigated by a support engineer, routed to technical experts, resolved, and added to a knowledge base.

•      Interviewing   Managing the process of interviewing a job candidate. This includes scheduling and tracking interview appointments, collecting interview feedback as it accumulates, making that feedback available to subsequent interviewers, and facilitating the hire/no-hire decision.

•      Content publishing   Managing the approval of the publication of content on an enterprise's Internet presence site.

One of the problems faced by many IT departments when implementing business processes requiring information workers' participation is that those processes do not integrate with the way people actually work. For a business process to be effective, it must be integrated with the familiar, everyday tools and applications used in the workplace so that it becomes part of the daily routine of information workers. In the electronic workplace, this includes integration with e-mail, calendars, task lists, collaboration Web sites, and client applications such as Microsoft Office Outlook 2007 and Word 2007. This is the approach implemented in workflows based on Office SharePoint Server 2007.

Workflows in Office SharePoint Server 2007

Office SharePoint Server 2007 includes the following standard workflows that address primary business needs:

•      Collect Feedback   Sends a document for review. The author chooses the reviewers, sends instructions, and checks on the workflow's progress. Reviewers receive e-mail notification and are assigned a task with a link to the document to review. Participants can optionally delegate their tasks or decline altogether.

•      Approval   Sends a document for approval. Approval is often a prerequisite to another document management task, such as publishing a document to a Web site or submitting a business proposal to a client. As with the Collect Feedback workflow, authors choose approvers, send instructions, and track workflow status. By default, Approval is a serial workflow — the order in which approvers view the document is specified by the author. (By contrast, Collect Feedback is a parallel workflow — reviewers can provide feedback in any order.)

•      Disposition Approval   Allows participants to approve the disposition of expired documents.

•      Collect Signatures   Routes a document to a set of participants who must sign that document.

•      Translation   Manages the translation of a document into one or more languages. This workflow creates placeholder documents and tracks translation tasks for each language version of the source document. If the source document changes, the workflow assigns tasks to update the translated versions.

•      Issue Tracking   Routes an issue to team members for resolution.

•      East Asian Document Approval   Routes a document for approval by using digital signature stamps and a group-oriented consensus process. This workflow is available only in East Asian product versions and language packs.

In Office SharePoint Server 2007, site designers can associate workflows with libraries, lists, or content types to make them available to run on documents or list items. A workflow's progress is recorded in a workflow history list, and workflow tasks are assigned to participants by using a tasks list.

So that they become part of the daily routine of information workers, workflows are tightly integrated into Office SharePoint Server 2007 and 2007 Microsoft Office system, enabling information workers to easily participate in them. The following tasks can be performed from the Web-based Office SharePoint Server 2007 interface or from 2007 Office system client programs:

•      Viewing the workflows available to run on a document or list item.

•      Initiating a workflow.

•      Viewing and starting a workflow task.

•      Completing a workflow task and filling out the task completion form.

Workflows in Office SharePoint Server 2007 are built on the Windows Workflow Foundation component of Microsoft Windows, and software developers can create custom workflows by using the Windows Workflow Foundation Designer in Microsoft Visual Studio 2005. After a workflow built on the Windows Workflow Foundation component of Microsoft Windows is installed and enabled by an administrator, users can associate it with one or more libraries, lists, or content types.

Users can also create custom workflows by using Microsoft Office SharePoint Designer 2007. Each workflow created by using Office SharePoint Designer 2007 can be associated with a single library or list. Using Microsoft Visual Studio 2005, you can create custom workflow actions that can be made available in Office SharePoint Designer 2007. Office SharePoint Designer 2007 includes a visual workflow design environment and a set of workflow actions that users can add to workflows without having to write source code, including:

•      Setting list metadata

•      Creating, copying, deleting, or changing list items (including documents)

•      Checking items in or out

•      Pausing, starting, or stopping the workflow

•      Sending e-mail messages

•      Setting the moderation status of an item

•      Setting an item's metadata

•      Assigning tasks

See Also

Plan workflows: Next steps

Understanding workflow

In this section:

•      Technology Basics of Workflow and SharePoint Products and Technologies

•      Workflow and Windows SharePoint Services 3.0

•      Workflow in Windows SharePoint Services: A Scenario

•      Authoring Windows SharePoint Services Workflows

•      Workflow and Office SharePoint Server 2007

•      Workflow in Office SharePoint Server: A Scenario

•      Authoring Office SharePoint Server Workflows

•      Making a technology choice

•      Conclusion for Understanding Workflow in the SharePoint Products and Technologies

Businesses depend on business processes. While those processes often involve software, the most important processes in many organizations depend on people. Automating interactions among the people who participate in a process can improve how that process functions, increasing its efficiency and lowering its error rate. Using software that supports this kind of human workflow can make organizations more effective.

Many kinds of processes in many different kinds of organizations can benefit from automated support for human workflow. Examples include:

•      Approval: A common aspect of human-oriented business processes is the need to get approval from multiple participants. What’s being approved can vary widely, ranging from a Word document containing next year’s marketing plan to an expense report from a trip to a conference. In every case, some number of people must review the information, perhaps appending comments, then indicate approval or rejection.

•      Coordinating group efforts: Whether it’s preparing a response to an RFP, managing the translation of a document into one or more languages, or something else, many processes require people to work together in an organized way. By defining the steps of the process in an automated workflow, the group’s work can be made more efficient and the process itself more predictable.

•      Issue tracking: Many business processes generate a list of outstanding issues. An automated workflow can be used to maintain that list, assign issues to the people capable of resolving them, and track the status of that resolution.

To support these kinds of automated business processes, Windows SharePoint Services 3.0 can run human workflow applications. Based on Windows Workflow Foundation, these applications interact with people through a Web browser and, if necessary, with other software as well. To create workflow applications, developers use WF’s Workflow Designer and Microsoft Visual Studio 2005, while information workers use the new Microsoft Office SharePoint Designer 2007.

Microsoft Office SharePoint Server 2007, part of the 2007 Microsoft Office system, adds more capability to workflow applications built on Windows SharePoint Services. Using this product, workflows can use custom forms created with Microsoft Office InfoPath 2007 to interact with users through Office applications such as Microsoft Office Word 2007 and Microsoft Office Outlook 2007. Office SharePoint Server also includes several predefined workflows, letting information workers create automated business processes for approval and other common situations.

Both Windows Workflow Foundation and Windows SharePoint Services 3.0 will be standard parts of Windows, while Office SharePoint Server is a separately licensed product. All of these technologies, together with the tools for creating workflows, are introduced in this section. The goal is to provide a big-picture view of how Microsoft supports human workflow in Windows SharePoint Services and the 2007 Office system.

Technology Basics of Workflow and SharePoint Products and Technologies

Understanding Microsoft’s support for human workflow requires a basic grasp of the two fundamental technologies that underlie this support: Windows Workflow Foundation and Windows SharePoint Services. This section briefly describes each one.

Windows Workflow Foundation

It’s common for software to implement some kind of process, with multiple steps performed one after another in a defined order. Given how often this approach is used, why not provide explicit support for creating this kind of application? The goal of Windows Workflow Foundation is to do exactly this. An application built with Workflow Foundation consists of one or more workflows, each of which contains some number of activities. A workflow’s activities are executed one at a time by Workflow Foundation’s runtime engine, with the execution order determined by the workflow itself. By providing direct support for process-oriented applications, Workflow Foundation can make those applications easier to create and maintain.

The following figure shows Workflow Foundation’s main components. A workflow, built from activities, executes using the runtime engine. This execution depends on a set of runtime services, provided by Workflow Foundation, that allow persisting a workflow’s state, tracking its execution, and more. All of this runs inside some host, which can be any Windows process ranging from a simple desktop application to a scalable server. And to accommodate different requirements imposed by different hosts and different kinds of applications, the Workflow Foundation runtime services can be replaced if necessary.

As the figure indicates, workflows can be created using Workflow Foundation Workflow Designer. This tool runs inside Visual Studio 2005, and it provides a graphical environment for organizing activities into workflows. An activity is just a class, so it’s also possible to create workflows purely in code—using a graphical tool isn’t required. Although a workflow can use any activities a developer chooses, Workflow Foundation provides a Base Activity Library (BAL). The BAL includes a number of fundamental activities, including the following:

•      IfElse: executes the activities contained in two or more possible paths based on whether a condition is met.

•      While: repeatedly executes one or more activities as long as a condition is true.

•      Sequence: executes a group of activities one at a time in a defined order.

•      Parallel: executes two or more groups of activities in parallel.

•      Code: executes a defined chunk of code.

•      Listen: waits for one of a set of events, then executes one or more activities when that event is received.

•      InvokeWebService: calls a Web service.

•      Policy: allows defining and executing business rules using a Workflow Foundation-supplied rules engine.

Workflow Foundation provides two types of built-in workflows:

•      Sequential workflows, which execute activities in a defined order. A sequential workflow can contain IfElse, While, and any other activities.

•      State machine workflows, which implement a traditional finite state machine. This type of workflow can also contain IfElse, While, and other activities, but it depends on other activities such as State to represent states and transitions.

It’s important to understand that Workflow Foundation isn’t itself a complete workflow application. Instead, it provides a foundation for developers to create workflow-based software. And because it can be hosted in any Windows process, Workflow Foundation can be combined with other technologies to provide workflow services. Windows SharePoint Services 3.0 does exactly this, and so the next step in understanding Microsoft’s support for human workflow is to understand the basics of this technology.

Windows SharePoint Services

Sharing information is a fundamental part of modern life. Whether in our jobs, as part of a volunteer organization, or in some other way, we frequently need to share documents and other information with a group of people. Windows SharePoint Services, a standard part of Windows Server 2003, can make this sharing easier.

As the figure below illustrates, users of Windows SharePoint Services can create sites, each of which contains document libraries and lists. The information in each site, including documents and list items, is stored in SQL Server. Using Internet Information Services (IIS), people can interact with sites from Microsoft Office applications or a Web browser such as Internet Explorer. Users can also customize the browser interface using Web Parts, allowing each user to create an interface that works well for her.

Version 3.0 of Windows SharePoint Services also adds support for content types. A content type provides a schema that defines a document or list item. By default, every document in a given library has the same schema, as does every item in a particular list. Attaching a content type to a document or list item allows specifying the schema of that document or item independently from the other elements of the library or list it belongs to. Policies can also be attached to content types, specifying things such as how long a document should be retained. These polices will then be applied to any document or item to which that policy is attached.

It’s possible for multiple machines running Windows SharePoint Services to access a single SQL Server database or a group of databases with sites partitioned across them. This improves scalability, allowing access to the same sites by a large number of users. It’s also worth pointing out that although they’re logically separate and appear to users differently, documents and items are actually quite similar under the covers: both are just entries in SQL Server tables. There are some differences—documents can be checked in and out, for example, while items cannot—but the distinction between the two has more to do with how a user sees them than with how they’re implemented.

Windows SharePoint Services also relies on other standard Windows technologies. It can use Active Directory to identify users, for example, and its user interface, including Web Parts, is built on ASP.NET. Both because it’s a standard part of Windows and because it addresses a common set of problems, Windows SharePoint Services has become a very popular technology. It’s used by many organizations for sharing many different kinds of information. Until Windows SharePoint Services 3.0, however, there was no built-in support for creating workflows. How Version 3.0 makes this possible is described next.

Workflow and Windows SharePoint Services 3.0

Both WF and Windows SharePoint Services are useful on their own. The ability to create human workflow applications built on the document-oriented features of Windows SharePoint Services would be even more useful, however. Windows SharePoint Services 3.0 makes this possible. Built using WF, this new release will be included with the forthcoming version of Windows Server 2008, and will also be freely available as an optional update for Windows Server 2003 via Windows Update.

Combining Windows Workflow Foundation and Windows SharePoint Services

As described earlier, the WF runtime engine can be hosted in any Windows process. Windows SharePoint Services 3.0 takes advantage of this, acting as a host for this engine. One or more workflow templates, each containing the code that defines a particular workflow, can be installed on a server. Once this is done, an association can be created between a specific template and a document library, list, or content type. This template can then be loaded and executed by the Windows SharePoint Services-hosted WF runtime engine, creating a workflow instance. The figure below shows how this looks.

Like all WF workflows, those based on Windows SharePoint Services 3.0 rely on WF’s runtime services. To better support workflows hosted in Windows SharePoint Services, however, Version 3.0 replaces some of those built-in services. WF’s standard persistence service has been modified, for example, to allow the state of a persisted workflow to be linked with the document or item with which that workflow is associated.

Having an architectural view of how the parts fit together is useful, and it’s an essential aspect of understanding workflows in Windows SharePoint Services 3.0. The best way to understand what’s really going on, however, is to look at a typical scenario using this technology. The next section walks through a simple example of using a Windows SharePoint Services workflow.

Workflow in Windows SharePoint Services: A Scenario

The most common example of human workflow in most organizations is some variation of approval: a group of people must approve or reject some document, perhaps adding comments to explain their decisions. Reflecting this popularity, the example here shows how an approval workflow implemented using Windows SharePoint Services might look. Before walking through this example, it’s useful to define the roles played by different people. Those roles include:

•      Workflow author: the developer or information worker who creates a workflow template.

•      Windows SharePoint Services administrator: the person who installs a workflow template and associates it with a document library or list.

•      Workflow initiator: the person who starts a running workflow, causing a workflow instance to be created from a particular workflow template.

•      Workflow participants: the people who interact with a workflow instance to carry out the business process it supports.

As described next, individuals in each of these roles have their own parts to play in creating, installing, instantiating, and using a workflow.

Authoring a Workflow

Microsoft provides two options for creating workflows that target Windows SharePoint Services. Developers use Visual Studio 2005 and WF Workflow Designer, while information workers use the simpler rules-based approach provided by Office SharePoint Designer. In both cases, the result is a workflow template that must be deployed to a server running Windows SharePoint Services. Workflow authoring is described in more detail later in this paper, so for now, this scenario assumes that a template has already been created.

Associating a Workflow with a Document Library or List

Before it can be used, a workflow template must be installed on a Windows SharePoint Services system, then associated with a particular document library, list, or content type. After this is done, the workflow can be started from any document or item in that library or list. Workflows operate in the same way on items and documents, and so a workflow template can typically be attached to either (although it’s possible to create a template that can be associated only with an item or only with a document). And while workflows can’t be explicitly started from content types, a workflow associated with a content type can be started from a document or list item to which that content type has been attached.

Both installation and association are done automatically for workflows created using Office SharePoint Designer. For those created using WF Workflow Designer and Visual Studio, however, a Windows SharePoint Services server administrator must explicitly install the workflow template. Once this is done, the template must be associated with a library, list, or content type, something that can be performed by someone with lesser permissions than a server administrator. Whoever creates this association also assigns it a unique name, allowing it to be referenced by users. Optionally, the workflow’s author can let the person who creates the association set options for the workflow’s behavior, such as specifying a default list of people who should always participate in the process. The same template can be associated with multiple libraries, lists, or content types, with each association customized as required. After the association has been created and any options set, a workflow initiator can create a workflow instance from this association, as described next.

Starting a Workflow

Windows SharePoint Services provides three options for creating a workflow instance. All three run the workflow from the beginning every time. (In fact, if a workflow instance created from a particular association is currently running, it’s not possible to create another instance from that same association.) The choices are:

•      The workflow can be started manually by a Windows SharePoint Services user.

•      The workflow can be configured to run automatically when a document or item is changed.

•      The workflow can be configured to run automatically when a document or item is created. For example, a Microsoft Word user might save a new document into a site’s document library, thereby causing an instance of a workflow associated with that library to be executed. A workflow initiator can use Microsoft Word 2007 or older versions to do this. It’s even possible to start workflows in this way from non-Microsoft applications.

This scenario uses the first of these three options: starting a workflow manually. The screen below shows how a document in a document library can appear to a Windows SharePoint Services user. To start a workflow instance from this document, the user clicks on the document and chooses Workflows from the menu.

Making this selection brings up the following screen:

Under the heading Start a New Workflow appear the names of all workflows that can be started from this document. In this example, there are two choices—Approval and Collect Feedback—but if an administrator has associated other workflow templates with this document library, their names would also appear. In this example, the initiator selects Approval, and this screen appears:

Unlike all of the screens shown so far, the contents of this one are defined by the workflow itself. When a workflow is started (i.e., when a workflow instance is created), it can optionally display a screen that allows its user to specify relevant information. For the Approval workflow shown here, this information includes the name of each person who should approve this document, an indication of when each approval is due, and a list of people who should be notified. Once this information has been supplied, the user clicks the Start button in the lower-right corner of this screen. The workflow will now begin executing, requesting that each participant review this document in the order in which their names were entered on this screen.

When a workflow is started, it can also optionally send an email message to the person who started it. Similarly, a workflow can inform its creator by email when it has completed. In this example, for instance, the Approval workflow might send mail to its creator informing her when the approval process is complete. It’s also possible for the participants in the workflow—in this example, the people who are approving the document—to be notified via email that the workflow has something for them to do.

Interacting with a Workflow

Interaction between a person and a running workflow is modeled using the notion of tasks. A task is a unit of work that’s assigned to some individual. In this example, each person on this workflow’s approval list will be assigned a task requesting approval of the document. Windows SharePoint Services maintains a task list for every site, and a running workflow can add tasks to this list, specifying who each task is for. Each user of that site can see what work is waiting for him either by accessing his task list via a Web browser or by synchronizing this site’s task list with his Outlook 2007 task list  The screen below shows how browser access to the task list looks for one of the people assigned to approve the document used in this example.

To a Windows SharePoint Services user, his list of waiting tasks is just another list. In the screen shown above, the user has selected the Tasks list from the options visible on the left side of the screen. The only task that’s currently in the list is a request to approve the document. (The document itself is accessible through the Link that appears on the right side of the screen.) To work on the task, the user in this example clicks on the task name, bringing up this screen:

How a workflow interacts with participants can vary, and so this screen is defined by the workflow itself. In this example, the participant is provided with a field for comments along with buttons to approve or reject the document. Other options are also available, letting him reassign the task to another person or request a change. Here, the user might enter a comment, then click the Approve button. The workflow will then create a task in the task list of the next person in its list of approvers. Once every participant has responded, the workflow ends.

Windows SharePoint Services workflows also provide other options, including the following:

•      A workflow’s initiator can check its status. In the scenario described here, for instance, she might check to see how far the approval process has gotten.

•      A workflow can be modified while it’s executing. What modifications are allowed, if any, is determined by the workflow’s author. An approval workflow, for instance, might allow adding a new approver while the workflow is in progress. The ability to modify in-flight workflows is important, as it’s a reflection of how people actually work. Spontaneous change to business processes is an inescapable reality, and so Windows SharePoint Services workflows provide a way to handle this.

Summarizing the Process

There are plenty of moving parts in a Windows SharePoint Services workflow. The figure below gives an overall view of how the process works.

To summarize: Once a workflow template has been installed and associated with a document library, list, or content type, a step not shown here, a user of that site can create an instance of this workflow. The process begins with the workflow initiator selecting a document and an associated workflow template (step 1). The initiator creates a workflow instance from this association (step 2), then customizes this new instance and starts it (step 3).

Next, the running workflow instance adds a task to the task list of a participant (step 4). (The approval workflow used in this scenario assigns these tasks sequentially, but it’s also possible for a workflow to assign tasks to many participants at once, letting them all be carried out in parallel.) Participants in the workflow can learn about tasks the workflow assigns to them by checking their task list (step 5). Each participant then interacts with the running workflow instance to complete this task (step 6). In the example described here, this required approving a document, but it could be anything the workflow author chooses.

It’s worth noting that the document a workflow is running on is not itself sent from person to person. Instead, the document remains on the site, and each workflow participant is given a link to it. In fact, there’s no requirement that the workflow make any use of the document or item with which it’s associated. Another point worth emphasizing is that what a workflow’s initiator and participants see in steps 1, 2, and 5 is defined by Windows SharePoint Services itself. The forms used in step 3 and step 6, however, are defined by the workflow author. This allows the author to control how users customize and interact with the workflow.

Along with providing a platform for creating human workflow applications, Version 3.0 of Windows SharePoint Services also provides a pre-defined Issue Tracking workflow that can be used as-is by end users. This workflow allows assigning active issues to participants and tracking those issues. Once created, an issue can be moved first to a Resolved state, indicating that it’s been handled by the responsible workflow participant, then to a Closed state, indicating that the workflow initiator has accepted the resolution and closed the issue.

Understanding the basics of how people use workflows in Windows SharePoint Services is an essential part of grasping this technology. Yet it’s also useful to know something about how a workflow author creates those workflows. The next section looks at the two approaches available for doing this.

Authoring Windows SharePoint Services Workflows

What is a Windows SharePoint Services workflow? Fundamentally, it consists of two things: the forms a workflow uses to interact with its users and the logic that defines the workflow’s behavior. Understanding how Windows SharePoint Services workflows are created requires knowing something about both.

Because it communicates with users through a Web browser, a Windows SharePoint Services workflow relies on Microsoft ASP.NET to display its forms. Accordingly, those forms are defined as ASPX pages. A Windows SharePoint Services workflow can potentially display its own forms at four points in its lifecycle:

•      Association: When a Windows SharePoint Services administrator associates a workflow template with a particular document library or list, he might be able to set options that will apply to every workflow instance created from this association. If a workflow author chooses to allow this, she must provide a form that lets the administrator specify this information.

•      Initiation: The initiator of a workflow might be allowed to specify options when he starts a running instance. In the approval scenario just described, for instance, the options included specifying the list of workflow participants and defining how long each one had to complete his or her task. If a workflow allows this, its author must provide a form to allow the initiator to set these options, as shown in step 3 of the previous diagram.

•      Task Completion: The running workflow instance must display a form to the participants in the workflow to let them complete their task. Shown in step 6 in the previous diagram, this form is what allowed the approvers in the earlier scenario to make comments on the document and indicate their approval or rejection.

•      Modification: Although it wasn’t shown in the scenario above, the creator of a workflow can allow it to be modified while it’s running. For example, a workflow might allow adding new participants after it has begun executing or extending the due date for completing tasks. If this option is used, the workflow must display a form at this point to let a participant specify what changes should be made.

Workflows built solely on Windows SharePoint Services define their forms as .aspx pages, while those using Office SharePoint Server can also use forms created with InfoPath, as described later. In either case, a workflow’s logic is always defined as a group of activities, just as with any WF-based workflow. To specify the logic and forms for a workflow, Microsoft provides two different tools, each targeting a different audience. Software developers can use WF Workflow Designer hosted in Visual Studio 2005. Information workers, a less technical group, can use Office SharePoint Designer to create workflows without writing code. The next two sections examine how Windows SharePoint Services workflows can be created using each of these tools.

Authoring Workflows with Visual Studio 2005 and WF Workflow Designer

In many ways, a workflow is like a flowchart. Given this, it makes sense to provide a graphical tool that lets developers specify a workflow’s actions. For WF, this tool is Workflow Designer, part of Windows Workflow Foundation Extensions for Visual Studio 2005. Developers can use WF Workflow Designer to define graphically a workflow’s activities and the order in which those activities should be executed. The screen below shows a simple example of how this looks.

The activities available for use appear in the Toolbox on the left side of the screen. A developer can drag these activities onto the design surface to define the steps in a workflow. The properties of each activity can then be set in the Properties window that appears in the lower right corner.

WF’s Base Activity Library provides a group of fundamental activities, as described earlier. Windows SharePoint Services also provides a set of activities designed expressly for creating Windows SharePoint Services workflows. Among the most important of these are the following:

•      OnWorkflowActivated: provides a standard starting point for a Windows SharePoint Services workflow. Among other things, this activity can accept information supplied by a Windows SharePoint Services administrator via the Association form when the workflow is associated with a document library or list. It can also accept information supplied via the Initiation form when the workflow is started. Every Windows SharePoint Services workflow must begin with this activity.

•      CreateTask: creates a task assigned to a particular user in a task list. For example, the approval workflow in the scenario described earlier used this activity to add a task to the task list used by each of the participants. This activity also has a SendEmailNotification property that, when set to true, automatically sends an email message to the person for whom this task was created.

•      OnTaskChanged: accepts information from the Task Completion form. The approval workflow in the earlier scenario used this activity to accept the input of each participant when the document was approved.

•      CompleteTask: marks a task as completed.

•      DeleteTask: removes a task from a task list.

•      OnWorkflowModified: accepts information from the Modification form, which can then be used to change how this instance of the workflow behaves. If the workflow’s creator chooses not to include any instances of this activity in the workflow, that workflow cannot be modified while it’s running.

•      SendEmail: sends email to a specified person or group of people.

•      LogToHistoryList: writes information about the workflow’s execution to a history list. The information in this list is used to let users see where a workflow is in its execution, look at the workflow’s history after it’s completed, and more. To allow this kind of monitoring, the workflow’s author must write information to a History list at appropriate points in the workflow’s execution. Because it provides its own mechanism for tracking workflows, Windows SharePoint Services doesn’t support WF’s standard tracking service.

A typical pattern for a simple Windows SharePoint Services workflow begins with an OnWorkflowActivated activity, then uses a CreateTask activity to assign a task to a participant in the workflow. The BAL’s standard While activity might then be used to wait until the user completes the task. To learn when this has happened (perhaps the user makes multiple changes to the task, then checks a box on the Task Completion form when she’s done), an OnTaskChanged activity executes within the While, extracting whatever information the user has entered on that form. When the user has completed the task, a CompleteTask activity might execute, followed by a DeleteTask. The workflow can then go on to the next participant, using CreateTask to assign a task to him, and so on. And of course, other things can occur, such as sending email, logging information to the history list, or even including the BAL’s Code activity, which allows running arbitrary code.

All of the activities provided by Windows SharePoint Services are concerned with letting workflows operate within the Windows SharePoint Services environment. The business logic a workflow implements is entirely up to the creator of that workflow. In fact, a developer authoring a Windows SharePoint Services workflow is free to create and use her own custom activities—she’s not required to use only those provided by Windows SharePoint Services and WF.

As described earlier, Windows Workflow Foundation supports both sequential and state machine workflows. A Windows SharePoint Services workflow created with the WF Workflow Designer can also use either option. To allow this, Windows SharePoint Services adds two project types to Visual Studio 2005, one for each of these workflow styles.

Whatever style is chosen, the developer must define more than just the workflow’s logic; he must also specify the ASPX forms it should use. To do this, the developer relies on a file named workflow.xml. This file provides a template that the developer fills in to specify what form, if any, should be displayed at each of the four points at which a Windows SharePoint Services workflow is allowed to do this.

A developer must do some work to pass information between a Windows SharePoint Services workflow and the ASPX forms it uses. Windows SharePoint Services provides a namespace, Microsoft.Windows.SharePoint.Workflow, that exposes an object model for developers. Using the types in this namespace, the creator of a Windows SharePoint Services workflow can pass information from an ASPX form to the workflow and vice-versa.

Once a Windows SharePoint Services workflow and its forms have been created, the developer must package them into what Windows SharePoint Services 3.0 refers to as a feature. A Windows SharePoint Services administrator must then install this feature, which includes installing the workflow’s assemblies to the target system’s global assembly cache. The new workflow will now be visible to the administrator as a workflow template that can be associated with a document library or list.

For a software developer, creating a Windows SharePoint Services workflow using Visual Studio and the WF Workflow Designer isn’t especially hard. The developer needs to understand the specifics of working in this environment, but much of what he’s doing will be familiar. Yet software developers aren’t the only people who’d like to author Windows SharePoint Services workflows. As described next, people who aren’t professional developers can also create workflows using Office SharePoint Designer.

Authoring Workflows with Office SharePoint Designer 2007

Office SharePoint Designer 2007, a separately licensed component of the 2007 Office system, allows information workers and others to add application logic (implemented as a workflow) to Windows SharePoint Services sites. This is certainly a useful goal, but Office SharePoint Designer also addresses another important problem. If a developer creates a Windows SharePoint Services workflow using Visual Studio, that workflow must be installed on a Windows SharePoint Services server like any other application. Yet many Windows SharePoint Services administrators won’t allow arbitrary code to be deployed on their servers, believing that the risk of destabilizing the system is too great. Being able to create straightforward business logic tied to documents and list items is very useful, however, and it’s something that many Windows SharePoint Services users need. Along with allowing less technical people to create workflows, Office SharePoint Designer also addresses this problem by providing a safer way to define and deploy business logic on Windows SharePoint Services servers.

The workflow scenarios that Office SharePoint Designer is intended to address are different in some ways from those addressed by Visual Studio and WF Workflow Designer. While it’s certainly possible to create complex applications, the intent of Office SharePoint Designer is to let users add business logic to Windows SharePoint Services sites. For example, suppose that a site contains a list that allows its users to submit change requests. Office SharePoint Designer could be used to create a workflow that automatically informs the submitter when her change request is accepted or rejected. Similarly, a custom workflow might inform a particular group of users whenever a new document is added to a particular document library. Performing this kind of custom notification isn’t complicated—creating the workflows is easy—but it’s challenging with earlier versions of Windows SharePoint Services because of administrators’ reluctance to install user-written code.

There’s an obvious question here: why should logic created with Office SharePoint Designer be treated any differently? What makes Windows SharePoint Services administrators willing to allow workflows built with this tool to be deployed on the systems for which they’re responsible? The answer is that workflows built with Office SharePoint Designer can only use activities from an administrator-controlled list. While a site’s administrator can choose to include custom activities created by a developer on this list, he’s not required to. By defining exactly what workflows are allowed to do, a Windows SharePoint Services administrator can have more confidence that deploying logic created using Office SharePoint Designer won’t destabilize his system.

Both because it’s intended for information workers rather than developers and because it emphasizes simpler scenarios, Office SharePoint Designer uses a different model for creating workflows than the Visual Studio-hosted WF Workflow Designer. Instead of a graphical approach, Office SharePoint Designer uses a rule-based approach. It’s somewhat similar to the Rules Wizard in Outlook, a tool that’s familiar to many people. The screen below illustrates how a user of Office SharePoint Designer defines a step in a workflow.

Each step can have a condition and an action. The condition determines whether this step’s action should be executed, as in the If statements shown above. The choices for actions include things such as assigning a To-do item to a workflow participant, sending email, and many more. Each of these actions is actually carried out by some Windows SharePoint Services activity, and the activities used here are the same as with Visual Studio and WF Workflow Designer. For example, the Send an Email option shown above corresponds to the SendEmail activity, while Assign a To-do Item corresponds to a slightly specialized version of the CreateTask activity. The list of actions can also include any other activities allowed by the Windows SharePoint Services administrator for this site, including custom activities created by developers.

Even though its user interface looks quite different from the graphical approach used with Visual Studio and WF Workflow Designer, Office SharePoint Designer creates a standard WF workflow. What’s actually produced is a sequential workflow with conditions expressed using the WF rules engine. Workflows created with this tool do have some limitations, however. For example, they can’t be modified while they’re running, unlike those built using Visual Studio and WF Workflow Designer, and only sequential workflows can be created—state machines aren’t supported. Also, workflows built with this tool must be authored against a specific document library or list when they’re designed. Creating a general workflow template that can later be associated with any library or list or with a content type isn’t possible. While this does place limits on how a workflow can be used, it also makes deploying the workflow much simpler. In fact, when a user finishes authoring a workflow with Office SharePoint Designer, the tool automatically deploys the workflow to the target site. This is significantly less complicated than the multi-step deployment process required for workflows created using Visual Studio and WF Workflow Designer.

Workflows created using Office SharePoint Designer can also display customized forms. Rather than require workflow authors to create ASPX pages directly, however, the tool instead generates those pages. The author specifies details about how the generated pages should look, such as what fields they should contain, and Office SharePoint Designer takes care of the rest. Of the four points in a Windows SharePoint Services workflow’s lifecycle where forms can be used, however, only two are used with workflows created using Office SharePoint Designer: Initiation and Task Completion. Because every workflow created with this tool must be associated with a particular document library or list, there’s no need for an association step and hence no Association form. And since these workflows can’t be modified while they’re running, there’s no need for a Modification form.

Office SharePoint Designer can be used for things other than creating Windows SharePoint Services workflows. The tool can be used to create a Windows SharePoint Services site, for example, or to customize the look and feel of a site’s pages by editing the site’s master page. It can also be used to connect to external data, something that relies on the data binding support in ASP.NET. For information workers who need to create logic that executes on a Windows SharePoint Services site, however, the most important aspect of Office SharePoint Designer is surely its support for authoring workflows.

Windows SharePoint Services provides a great deal of functionality for creating document-oriented workflows. Yet ultimately, it’s a platform for development and execution. On its own, it provides no workflow functionality that’s directly usable by end users. If what’s required is out-of-the-box workflow applications—and it often will be—Windows SharePoint Services isn’t enough. Workflows created using just Windows SharePoint Services also have other restrictions, such as the inability to interact with participants via Office client applications. As described next, Office SharePoint Server offers a way to overcome all of these limitations.

Workflow and Office SharePoint Server 2007

The 2007 Office system includes new versions of the Office desktop applications, including Word, Excel, Outlook, and PowerPoint. It also includes a separately licensed suite of servers that address various areas. The member of this suite that’s most relevant to workflow is Office SharePoint Server 2007.

Office SharePoint Server supersedes earlier Microsoft products, including SharePoint Portal Server and Content Management Server, to provide a range of enterprise content management functions. These include several useful additions to the workflow capabilities built into Windows SharePoint Services. As in Windows SharePoint Services, all of these rely on Windows Workflow Foundation.

Combining Windows Workflow Foundation, Windows SharePoint Services, and Office SharePoint Server

The workflow-related additions that Office SharePoint Server provides to Windows SharePoint Services can be grouped into three areas: support for Office 2007 clients, the ability for workflows to use forms created with InfoPath, and pre-defined workflows. This section looks at each of these three areas.

Workflows created using Windows SharePoint Services alone must use ASPX forms. Accordingly, the only way for people to interact with these workflows is via a Web browser. Yet the Office desktop applications are widely used, and many Windows SharePoint Services workflows will reference documents created with these applications. Why not allow users to interact with these workflows directly from Word, Excel, Outlook, and other Office applications?

Office SharePoint Server provides this ability. Rather than relying on a browser to communicate with users, a Windows SharePoint Services workflow running with Office SharePoint Server installed can display its forms directly in Office 2007 applications. For many workflows, this will allow a more natural interaction with users. A Windows SharePoint Services task list, for example, can be synchronized with the task list maintained by Outlook 2007, giving the user a single To Do list. Tasks can also be represented in Word 2007 documents, Outlook 2007 emails, and other ways, letting users input information to a running workflow directly from Office applications.

Displaying forms directly in Office applications requires some way to define those forms. The ASPX pages used by standard Windows SharePoint Services workflows will no longer suffice. To address this, Office SharePoint Server allows workflow authors to define forms using InfoPath 2007. For most people, these forms are easier to create than ASPX pages, and they can also provide capabilities such as built-in validation. It’s important to note, however, that the InfoPath-based forms used with a workflow, referred to in this paper as InfoPath workflow forms, provide only a subset of the capabilities offered by standard InfoPath forms. Much of the InfoPath object model isn’t available, for instance, as the focus is entirely on creating and using forms as part of workflows.

Letting workflow authors interact directly with Office applications through InfoPath workflow forms is certainly useful. Yet so far, everything described in this paper targets developers—there’s nothing that’s immediately usable by information workers. Office SharePoint Server changes this by including a group of pre-defined workflows. All of these workflows are meant to be used directly by information workers, and all can be customized to meet various requirements. The pre-defined workflows that Office SharePoint Server provides include the following:

•      Approval: routes a document for approval. The workflow initiator specifies a list of approvers, each of whom can approve or reject the document, reassign the approval task, or request changes to the document. The example workflow scenario described earlier for Windows SharePoint Services was actually this pre-defined Approval workflow. (It’s worth noting that while the earlier scenario illustrated only aspects of Windows SharePoint Services, executing this pre-defined Approval workflow actually requires Office SharePoint Server. A developer could create a workflow that behaved exactly like the earlier scenario using only Windows SharePoint Services, however.)

•      Collect Feedback: routes a document for review, much like the Approval workflow. Participants can provide feedback, which is compiled and sent to the document owner when the workflow has completed. Unlike Approval, which by default assigns tasks to participants sequentially, this pre-defined workflow defaults to parallel task assignment, allowing feedback to be returned in any order.

•      Collect Signatures: routes an Office document for required signatures. This workflow can be started only from within an Office client.

•      Disposition Approval: helps manage document retention by allowing participants to decide whether to retain or delete expired documents.

•      Translation Management Workflow: helps manage the process of document translation. This workflow can be used to assign specific translation tasks to the participating translators, then track the progress of those tasks. It can also assign new translation tasks when a source document changes.

•      Group Approval: implements a group-oriented approval process. This workflow is available only in East Asian versions of Office SharePoint Server.

All of these pre-defined workflows use InfoPath workflow forms, and so all allow access directly from Office 2007 applications.

Office SharePoint Server also provides other workflow-related services, including the ability to create reports on workflow history directly in Excel and support for bulk task completion, allowing a user to approve many outstanding tasks at once. The product provides a range of other functions as well, such as enhanced search, the ability to load, calculate, and render Excel spreadsheets on the server, and more. This large set of functionality is provided in two versions: a base edition and an enterprise edition. The product’s base edition includes the pre-defined workflows just described, but it doesn’t provide support for InfoPath workflow forms—users must interact with these workflows via a Web browser. The enterprise edition supports all of the capabilities described in this section, including using InfoPath workflow forms.

Workflow in Office SharePoint Server: A Scenario

As before, the best way to get a sense of how a workflow works in an Office SharePoint Server environment is to walk through a scenario. This section shows the same workflow used as an example in the Windows SharePoint Services section of this paper. As mentioned earlier, this is actually the pre-defined Approval workflow provided with Office SharePoint Server. In the Windows SharePoint Services example, the workflow interacted with its users via ASPX forms displayed in a Web browser. Because this scenario uses Office SharePoint Server as well, however, all interaction with the workflow now happens via InfoPath workflow forms displayed in Office 2007 applications.

Once again, the process begins the workflow’s installation and association with some document library or list, and once again, those details are omitted here. What’s most interesting begins with the workflow initiator creating a running workflow instance. As the screen below shows, this can now be done directly from a Word 2007 document. If Office SharePoint Server is deployed, a Start Workflow option appears when the Microsoft Office button is clicked.

Choosing this option brings up the Start New Workflow window, as shown below.

As in the earlier scenario, all workflow associations that are available for this document are shown. Clicking the Start link for the workflow named Approval causes that workflow to begin, bringing up the window shown below (which is actually an InfoPath workflow form). As illustrated in the earlier scenario, the pre-defined Approval workflow allows its initiator to customize its behavior by specifying a list of approvers, setting how long each one has to perform his task, and more. The fields in the form below—the workflow’s Initiation form—allow setting these things.

The people listed as approvers in this workflow will now each be sent an email message in the order their names were entered. Assuming those approvers are using Outlook 2007, that message might look like this:

The approver can examine the document by clicking on the document name link in the body of the mail. Clicking on the Edit this task… button at the top of the message (here marked with a red square) brings up the form shown below.

This is the workflow’s Task Completion form. Its contents are identical to those shown in the Windows SharePoint Services example earlier. This time, however, the form was defined as an InfoPath workflow form, and it’s displayed directly in Outlook 2007. As before, the approver can add comments, then approve or reject the document.

The operation of this workflow is identical to the Windows SharePoint Services example. Yet there are important differences. With Office SharePoint Server, the workflow initiator creates a workflow instance directly from Word rather than using a browser to access a Windows SharePoint Services site. Similarly, the workflow’s participants interact with this running instance entirely through Office 2007 applications. As with the initiator, there’s no longer any need to access the site itself. This ability to create and use workflows in a purely Office-based environment is likely to be important for a significant number of workflow applications.

Authoring Office SharePoint Server Workflows

Like those built solely on Windows SharePoint Services, workflows that use Office SharePoint Server can be created using either Visual Studio 2005 and WF Workflow Designer or Office SharePoint Designer. This section describes both approaches.

Authoring Workflows with Visual Studio 2005 and WF Workflow Designer

Using Visual Studio 2005 and WF Workflow Designer to author an Office SharePoint Server workflow is much like using this tool to author a workflow based solely on Windows SharePoint Services. As shown earlier, a developer can drag and drop activities onto a design surface, then write code as needed. Office SharePoint Server doesn’t provide any extra activities beyond those supplied by Windows SharePoint Services, so developers have the same building blocks for workflow logic.

The big difference, however, is that workflows using Office SharePoint Server can use InfoPath workflow forms rather than just ASPX forms. To create these forms, a workflow author uses InfoPath 2007. This tool provides a graphical editor that lets the author define the form’s content. Developers who prefer to work entirely within the Visual Studio environment can use Visual Studio Tools for Office, which allows hosting InfoPath inside Visual Studio.

Once they’re created, InfoPath workflow forms are attached to a workflow via a workflow.xml file, just as with ASPX forms. Unlike ASPX forms, however, developers don’t need to write custom code to move information between InfoPath workflow forms and a workflow. Instead, Office SharePoint Server and InfoPath provide this link, making life simpler for the people who create workflows.

Authoring Workflows with Office SharePoint Designer 2007

Just as with Windows SharePoint Services, information workers can use Office SharePoint Designer to author workflows that run in an Office SharePoint Server environment. Unlike workflows created using Visual Studio and WF Workflow Designer, however, those created using Office SharePoint Designer can’t use InfoPath workflow forms. This also means that they can’t be accessed directly from Office 2007 applications. Instead, these workflows must be accessed via a Web browser.

This constraint stems from the way that Office SharePoint Designer handles forms. As described earlier, information workers don’t directly create forms using this tool. Instead, a workflow author sets options provided by the tool, then lets the tool generate the required forms. This makes life easy for the author, but the usual tradeoff between ease of use and power also applies: only ASPX forms are supported.

Making a technology choice

Windows SharePoint Services 3.0 offers a general foundation for human workflow applications. Office SharePoint Server 2007 provides extra capabilities built on this foundation. When is the workflow support in Windows SharePoint Services sufficient, and when is Office SharePoint Server also required? Here’s a short summary of the major factors in making this decision.

Windows SharePoint Services alone is appropriate for:

•      Adding application logic to Windows SharePoint Services sites that works with documents and list items.

•      Building workflow applications where user interaction via ASPX forms in a Web browser is sufficient.

Office SharePoint Server is required for:

•      Using most of the pre-defined workflows that Microsoft provides. (The exception is Issue Tracking, which ships with Windows SharePoint Services and uses only ASPX forms.)

•      Building workflow applications where user interaction via Office 2007 client applications is required. This option also allows using InfoPath workflow forms, which are simpler to create and provide more functionality than ASPX forms.

It’s worth pointing out that either technology can provide a foundation for independent software vendors (ISVs). A tool-focused ISV might build specialized tools for creating workflows, targeting either developers or information workers. An application-oriented ISV might provide pre-defined workflows addressing specific problems, such as a help desk application or a process for digital asset management. Depending on the requirements, the ISV might choose to base its application solely on Windows SharePoint Services or to require Office SharePoint Server as well.

Conclusion for Understanding Workflow in the SharePoint Products and Technologies

Human workflow applications can improve the efficiency and accuracy of many business processes. By creating Windows Workflow Foundation and making it a standard part of the operating system, Microsoft has provided the basis for a broad set of workflow applications. By hosting WF workflows, Windows SharePoint Services 3.0 offers developers and information workers the ability to construct document-oriented human workflow applications. Adding Office SharePoint Server lets these applications interact with their users through InfoPath forms presented in Office 2007 desktop applications. It also provides a group of pre-defined workflows that address common business scenarios.

Adding support for workflow to Windows SharePoint Services and Office SharePoint Server is a significant step. Windows SharePoint Services and Microsoft Office are popular technologies, and so it’s fair to expect that these new workflow features will be quite widely used. Going forward, look for workflow applications to become more common in the lives of both information workers and developers.

Resources

•      Windows Workflow Foundation (http://go.microsoft.com/fwlink/?LinkId=76851&clcid=0x409)

•      Windows Workflow Foundation discussion forum (http://go.microsoft.com/fwlink/?LinkId=76853&clcid=0x409)

•      Windows SharePoint Services 3.0 (http://go.microsoft.com/fwlink/?LinkId=76855&clcid=0x409)

•      Office SharePoint Server 2007 (http://go.microsoft.com/fwlink/?LinkId=76856&clcid=0x409)

•      Office SharePoint Designer 2007 (http://go.microsoft.com/fwlink/?LinkId=76857&clcid=0x409)

•      Office SharePoint Server discussion forum (http://go.microsoft.com/fwlink/?LinkId=76858&clcid=0x409)

•      Enterprise Content Management Starter Kit (http://go.microsoft.com/fwlink/?LinkId=76859&clcid=0x409)

About the Author

David Chappell is Principal of Chappell & Associates (http://go.microsoft.com/fwlink/?LinkId=76860&clcid=0x409) in San Francisco, California. Through his speaking, writing, and consulting, he helps technology professionals around the world understand, use, and make better decisions about enterprise software.

Plan workflows: Next steps

This article contains links to topics that will help you in your workflow planning.

Planning workflows: Next steps

To continue planning workflows in the context of document management, forms, or publishing, see one of the following topics:

•      Plan workflows for document management

•      Plan workflow for form templates

•      Plan content approval and scheduling

See Also

What are workflows?

VI.  Plan InfoPath Forms Services

The articles in this chapter include:

•      Plan InfoPath Forms Services

•      Plan what form templates are needed (Office SharePoint Server)

•      Plan custom form templates (Office SharePoint Server)

•      Plan form template design infrastructure requirements (Office SharePoint Server)

•      Plan server-side data connections needed for form templates (Office SharePoint Server)

•      Plan deployment of form templates (Office SharePoint Server)

•      Plan deployment of administrator-approved form templates (Office SharePoint Server)

•      Determine the impact of anonymously accessible form templates (Office SharePoint Server)

•      Plan for naming form templates (Office SharePoint Server)

•      Plan for upgrading form templates (Office SharePoint Server)

•      Plan for retiring form templates (Office SharePoint Server)

•      Plan version control for form templates (Office SharePoint Server)

•      Plan for mobile device access to form templates (Office SharePoint Server)

•      Plan workflow for form templates

Plan InfoPath Forms Services

The articles in this chapter include:

•      Plan what form templates are needed (Office SharePoint Server)

•      Plan custom form templates (Office SharePoint Server)

•      Plan form template design infrastructure requirements (Office SharePoint Server)

•      Plan server-side data connections needed for form templates (Office SharePoint Server)

•      Plan deployment of form templates (Office SharePoint Server)

•      Plan deployment of administrator-approved form templates (Office SharePoint Server)

•      Determine the impact of anonymously accessible form templates (Office SharePoint Server)

•      Plan for naming form templates (Office SharePoint Server)

•      Plan for upgrading form templates (Office SharePoint Server)

•      Plan for retiring form templates (Office SharePoint Server)

•      Plan version control for form templates (Office SharePoint Server)

•      Plan for mobile device access to form templates (Office SharePoint Server)

•      Plan workflow for form templates

In this article:

•      InfoPath Forms Services planning articles

•      Scenario planning

Using InfoPath Forms Services, you can publish form templates that can be opened either in Microsoft Office InfoPath 2007 or rendered in a Web browser.

Note:

InfoPath Forms Services is a component of Microsoft Office SharePoint Server 2007 and should not be confused with Microsoft Office Forms Server 2007, a separate product.

This technology requires specific server configuration, server resource and network bandwidth allocation, consideration of security and user management, and careful planning related to the deployment, accessibility, and management of form templates. You do not have to install InfoPath Forms Services separately, as it is installed with Windows SharePoint Services. In order to make the most effective use of InfoPath Forms Services, you need to do some planning. The planning tasks have been organized into articles to make it easier for you to find the planning information you need for each step.

Note:

"Forms" and "form templates" are separate entities. A form is an instance of a form template, invoked when the form is opened from a document library or when a Web page containing a form is opened. A form template is an .xsn file that resides on a server and contains the code that generates a form.

For example business scenarios for InfoPath Forms Services, see Scenario planning in this article.

InfoPath Forms Services planning articles

Before you begin designing form templates

Plan what form templates are neededThis article helps you to plan what form templates you need to create. It also helps you understand which of your current forms can be imported and which must be recreated manually, and the factors that should be taken into account.

Plan for naming form templates This article helps you to establish a naming convention for form templates.

Planning form template design

Plan form template design infrastructure requirementsBefore you begin deploying form templates in an InfoPath Forms Services production environment, read this article to help you consider the server, security, and network requirements to support your deployment.

Plan custom form templates Read this article to help you develop custom form templates to address specific forms needs.

Plan server-side data connections needed for form templates This article describes how server-side data connections function when a form template is deployed, and it assists you with planning for the data connections you need.

Planning form template deployment

Plan deployment of form templates   This article helps you to understand the deployment process for the two categories of browser-compatible form templates: user form templates and administrator-approved form templates.

Plan deployment of administrator-approved form templates Read this article to help you plan for the deployment of form templates that contain business logic such as a compiled, managed code DLL (form code); require full trust; or use a data connection that is managed by an administrator.

Planning server supportability and maintenance

Plan for upgrading form templates Read this article to help you plan for upgrading administrator-deployed form templates.

Plan for retiring form templates Read this article to help you plan for retiring form templates when they become obsolete.

Plan version control for form templates Read this article to help you plan for enabling version control, which causes document libraries to create a new version of the form template every time the template is edited and saved, preserving previous versions as defined by the administrator.

Plan for mobile device access to form templates Read this article to help you plan for providing access to browser-enabled forms from mobile devices such as handheld PDAs that support HTML, CHTML, or XHTML.

InfoPath Forms Services Best Practices   Read this article for best practices for InfoPath Forms Services.

Scenario planning

You need to carefully plan before you implement InfoPath Forms Services in your organization. You need to consider that InfoPath Forms Services can:

•      Integrate with other applications in Office SharePoint Server 2007.

•      Integrate with other systems such as e-mail.

•      Retrieve data from or push data to databases.

Several factors can make this process complex and challenging. Your organization should decide what purpose forms will serve in the enterprise. Forms can be critical business artifacts in many organizations.

Many organizations use scenario planning to make strategic decisions about how forms are used. The basic method is for a team to generate a scenario that incorporates known facts about the future. For example, the scenario can include the following:

•      System capacity

•      Network topology

•      Number of users

•      Location of users

•      Server configuration

•      Legacy system integration

•      Form complexity

•      Session length

This section contains some sample scenarios for the use of InfoPath Forms Services.

Scenario 1: Expense-Report Submission

A. Datum Corporation, a national computer equipment and IT services provider, sells computers, networking hardware, and IT service contracts. A. Datum Corporation has 10,000 employees in North America. Many A. Datum Corporation teams — including marketing, sales, and support consultants — incur and report work-related expenses. These teams represent about one third of the A. Datum workforce.

Situation

A. Datum Corporation has adopted mySAP ERP for its business data and operations. It wants to add InfoPath Forms Services to its environment to take advantage of data connections to its back-end systems. By deploying InfoPath Forms Services, A. Datum intends to benefit in the following ways:

•      Streamline the process of expense-report submission, review, approval, and reimbursement.

•      Increase data accuracy through data validation and business logic built into the form.

•      Enable expense reports to be completed online or offline.

•      Enforce corporate expense policy rules at the time of expense-report submission.

•      Provide immediate access to expense-report status and expense data.

In addition, A. Datum wants to leverage the advantages realized through Office SharePoint Server 2007 such as document management, team collaboration, and workflow features available with SharePoint sites. The corporation plans to connect the SharePoint sites to its SAP portal so that it can search and index the content along with its other business information.

Solution: Forms for internal use

The IT department in A. Datum Corporation is responsible for deploying and maintaining InfoPath Forms Services and connecting it to SAP. It is concerned with keeping its business-critical information available and secure. It is responsible for ensuring that the end-user experience is smooth and that response times are within acceptable limits. Time studies indicate that users take about 30 minutes to complete an expense report. To accommodate the new expense-reporting forms, the IT department is preparing to do the following:

•      Provide intranet access for employees accessing the forms within the corporate network.

•      Provide dial-up access to a remote access server for employees outside the corporate firewall.

•      Provide the Microsoft Office InfoPath 2007 client for those employees who require offline capability.

•      Deploy this solution on a medium server farm.

Scenario 2: Insurance claims processing

A large organization introduces Office SharePoint Server 2007 into its environment to enable customers, insurance agents, and related businesses to use online forms for processing insurance claims. The organization has been using InfoPath 2003 internally but wants to make its forms browser-enabled.

Situation

Humongous Insurance is a large multinational company that sells insurance products for boat, automobile, and home owners. These products are sold to both consumers and corporate clients. Humongous Insurance has a large, mobile workforce of over 10,000 people that includes salespeople, claims adjusters, attorneys, IT staff, HR staff, and finance staff. Humongous Insurance is based in the United States, but has offices in Canada and several Latin American countries.

Solution 1: Forms for internal use

The insured customer contacts his Humongous Insurance agent by telephone to file a claim. The agent connects to the corporate claims Web site and completes the claim form for the customer. The agent forwards the claim by e-mail to the adjuster, who conducts an inspection. The adjuster approves repairs and costs. The adjuster completes the form that was sent in e-mail and returns it to the agent. The agent reviews the form for accuracy and then forwards it to the accounting department for payment processing. A representative from the accounting department approves a check and archives the claim form. The form is stored as an XML document in the Humongous Insurance claims database. The repairs are done and the customer is refunded the covered amount. Relevant account information is updated accordingly.

Solution 2: Customer-facing forms

Alternatively, a Humongous Insurance customer can file a claim over the Internet. The customer need not wait for regular business hours to file a claim. The customer can go to the Humongous Insurance Web site, establish her account, log on, and file the claim. In this case, the customer completes the form that is typically completed by the agent. After the customer submits the form, it is sent to the adjuster by e-mail and a copy of the e-mail is sent to the agent. The adjuster returns the form to the agent if additional information is needed. From this point, the claim form is handled in the same way as a claim initiated by a telephone call.

Scenario 3: Online government permits

A local government agency uses Office SharePoint Server 2007 and InfoPath Forms Services to provide permit application and approval to contractors over the Internet.

Situation

An electrical contractor successfully bids a job for electrical service updates to a home, and seeks a permit issued by the local government agency to complete this work. The electrical contractor goes to the Web site for the City Power and Light Department of Building Inspections to apply for a permit by using an online service. The contractor has previously registered to use this service. His company information, as well as a prior permit request, is already stored.

Solution 1: Customer-facing forms

Data entered into the permit application Web form is submitted to an XML database located on the network of the Department of Building Inspections. After the application data is submitted, a new permit request is automatically populated to a SharePoint workspace as a link to a multi-part InfoPath form. When the form is opened, the requesting contractor’s company data and permit application data are populated into fields in the first view of the form. This view is identical to the form that the contractor completed.

Solution 2: Forms processing workflow

As part of the process, City Power and Light Department of Building Inspections must formally acknowledge receipt of the application. The receiving agent checks the information for completeness and digitally signs the application form to confirm receipt. A precise image of the application form acknowledging receipt by the department is sent by e-mail to the contractor. InfoPath uses data adapters to access data relevant to qualifying a decision. InfoPath pulls this information from other internal agency data sources into the form in other views. The agency employee reviews this other data, adjudicates the request based upon this merged information, and approves or denies the permit request. If the request is approved, an electrical permit, populated with the requestor’s contact data and relevant information, is rendered in HTML. The permit is posted to the contractor’s home page on the Department of Building Inspections Permit SharePoint site, where the contractor can view and print the permit for posting on the job site.

Plan what form templates are needed

In this article:

•      Create an inventory of current forms

•      Survey the advantages of online forms

•      Assess the need for new form templates

•      Determine form template complexity

•      Worksheet

It is important that you follow some planning steps when you are considering what form templates you will need. Most organizations already have forms in use, and while some of these forms can be imported, you will almost certainly want to create new form templates. This article helps you plan what form templates you need to create. It also helps you understand which of your current forms can be imported and which must be recreated manually, and the factors that should be taken into account.

At the end of this article, you should use the Inventory of existing forms worksheet (http://go.microsoft.com/fwlink/?LinkId=73266) to list your current form inventory. In the article named Plan what form templates are needed, you will use the "Plan deployment of administrator-approved form templates" worksheet to record the form templates you will initially create, and the existing forms you will import.

Create an inventory of current forms

Before you deploy InfoPath Forms Services, it is important to identify what forms are currently used in your organization. Forms exist in many different formats, including:

•      Microsoft Word

•      Paper

•      Fax

•      E-mail

•      Web

•      Microsoft Office InfoPath 2003

•      Other software

Determine whether your existing forms are useful and effective. Some parts of forms or entire forms might not fulfill the purpose for which they were originally designed. Some forms might duplicate other forms. Identify the forms that you want to keep. Of the forms that you want to keep, determine which ones can be developed and deployed to InfoPath Forms Services. Determine if forms should be combined. Identify which forms can be eliminated, either by retiring them or by combining them with another form.

Survey the advantages of online forms

There are a number of reasons that an organization would decide to move forms from their legacy format to an online version. The key advantages for doing this with InfoPath Forms Services are:

1.   Microsoft Office InfoPath 2007 provides a design-once model for both form templates that are viewed and edited in the Office InfoPath 2007 program, and browser-compatible form templates that are viewed and edited in a browser. All declarative rules in the form work identically when a form is filled out by using Office InfoPath 2007 or a Web browser. Similarly, all business logic written in a .NET Framework language to the new managed object model will run identically in both environments. This allows developers to design rich, complex forms once without having to worry about creating different versions.

2.   The Office InfoPath 2007 design mode allows form template designers to define simple validation rules, calculations, and conditional formatting declaratively, without having to write any code. All of these declarative rules run as is on InfoPath Forms Services without making any server-specific or browser-specific changes.

3.   A simple deployment model and features for form template management are available. InfoPath Forms Services provides a one-step deployment model through the InfoPath Designer and also integrates with the Windows SharePoint Services 3.0 and Microsoft Office SharePoint Server 2007 infrastructure to provide administration and manageability tools.

4.   No download or custom installation is required on the client in order to fill out a form.

5.   InfoPath Forms Services can understand XML schemas inherently and can provide a rich, flexible, dynamic, and familiar user model for working with nested, repeating, and optional sections. InfoPath Forms Services also has advanced capabilities for defining validation rules and applying them at run time to catch data integrity problems at the source. All of these capabilities are available when filling out InfoPath forms, whether in a Web browser or in Office InfoPath 2007.

6.   Forms are commonly used as a front end for a more complex business process where the collected data needs to flow through predefined workflow and server processes. Form fields might be mapped to rows and fields in a database. InfoPath Forms Services provides excellent connectivity to Web services with built-in functionality that can let you consume data from or submit data to a Web service without writing a single line of code.

7.   Office InfoPath 2007 is built on the XML standard. InfoPath form templates are based on an underlying XML schema that defines the shape of the data captured by the form. The form is an XML file complying with this schema. Data can easily be retrieved from and submitted to external data sources. This is also true for forms running in a Web browser. Because of this standard data format, form template designers can directly manipulate the data captured through Office InfoPath 2007.

8.   InfoPath Forms Services supports a complete managed object model for forms that can take a dependency on the Microsoft .NET Framework. Business logic written in C# or Visual Basic that takes advantage of this object model runs directly without recompilation on InfoPath Forms Services.

9.   Windows SharePoint Services 3.0 architecture allows administrators to take advantage of CPU and memory upgrades to both scale up and scale out the performance of InfoPath Forms Services to meet demands.

10.  InfoPath Forms Services is natively compatible with the dominant browsers on all platforms.

Assess the need for new form templates

While creating the planning scenario and forms inventory, you might identify gaps where a new form template can fill a need. You might find that InfoPath Forms Services technology offers new opportunities that were not previously practical or possible with current forms. For example, paper forms do not integrate with e-mail. A new form template that integrates with e-mail, if it is appropriate to your scenario, might be valuable. The worksheet in this article includes a section for assessing your need for new form templates.

Determine form template complexity

You have a wide range of options when designing a form template in Office InfoPath 2007. A form template can be simple and short-lived. For example, a workgroup might create a form to determine who will attend a meeting next week. A form template can also be very complex. For example, the form template might:

•      Use form code.

•      Contain multiple data connections.

•      Require deployment by the administrator of the server farm. Understanding the complexity of your form template can help you determine the impact on system resources.

Questions you need to answer when you plan for InfoPath Forms Services include the following:

•      Will the form template be exposed to anonymous users?

•      Will this be an administrator-approved form template? That is, is this a form template that can only by deployed by an administrator because it requires full trust, contains form code, or uses an administrator-managed data connection?

•      Will this form template use data connections to submit or retrieve data from external sources? For more information about data connections, see Plan server-side data connections needed for form templates.

•      How many people are expected to use this form template over its life span?

•      What will the average number of concurrent users be for the form template?

•      What is the expected number of concurrent users during peak usage?

•      What is the expected session length for the form template?

•      Will users access the form template offline?

•      Will the form template require a digital signature?

•      Will workflow be applied to this form template, or is the form template intended to be used in a workflow?

Worksheet

Use the Inventory of existing forms (http://go.microsoft.com/fwlink/?LinkId=73266) to list your current form inventory.

See Also

Plan deployment of administrator-approved form templates

Plan custom form templates

You can develop custom form templates to address specific forms needs. Microsoft Office InfoPath 2007 provides several form templates that can be customized for your organization's needs and systems, but most organizations find that they need to design custom form templates to suit their specific needs.

For example, an insurance company may need to design a form template to gather accident claims information, with certain form fields being populated by existing database entries related to the customer. Because such a form template would contain specialized logic and data connections, it would need to be designed from the ground up.

InfoPath form templates can also be created by importing forms from Microsoft Office Word 2007 and Microsoft Office Excel 2007 documents. For more information, see Convert a Word document to an InfoPath form template (http://go.microsoft.com/fwlink/?LinkId=74648) and Convert an Excel workbook to an InfoPath form template (http://go.microsoft.com/fwlink/?LinkId=74649) on Office Online.

Custom form templates that contain form code, require full trust, or use a data connection managed by a server administrator must be approved and deployed by an administrator. Such form templates are called "administrator-approved form templates." For more information, see Plan deployment of administrator-approved form templates. If a form template does not contain form code, require full trust, or use a data connection managed by an administrator, you can configure InfoPath Forms Services to permit users to deploy such form templates, called "user form templates," without administrator approval.

See Also

Plan what form templates are needed

Plan deployment of form templates

Plan deployment of administrator-approved form templates

Plan form template design infrastructure requirements

In this article:

•      Server requirements

•      Network requirements

•      Security requirements

Before you begin deploying form templates in an InfoPath Forms Services production environment, it is important that you carefully consider the server, security, and network requirements to support your deployment. InfoPath Forms Services can support many thousands of form templates of varying degrees of complexity, and it provides support for user-deployed form templates. As with any enterprise system, it is crucial to design your infrastructure to support the intended level of usage and to establish a clear strategy for scaling the system to meet increased capacity requirements.

Note:

Once you have established the expected usage and size of your deployment, you should always deploy to a staging system before you deploy to a production environment. This allows you to establish performance and capacity baselines and to ensure that your design functions as expected.

The factors you need to consider include:

•      Expected number of users

•      Expected number of form templates

•      Expected life cycle of form templates (the length of time that a form template will be used before being retired or upgraded)

•      Complexity of form templates (for example, how many form templates will use data connections or complex code, or instantiate a workflow)

•      Security considerations

You should read the following Microsoft Office SharePoint Server 2007 planning articles before you begin planning your InfoPath Forms Services infrastructure:

•      Chapter overview: Plan for capacity

•      Chapter overview: Design server farms and topologies

•      Design logical architecture

•      Chapter overview: Plan for performance and capacity (Office SharePoint Server)

•      Chapter overview: Plan for and design security

Server requirements

Because InfoPath Forms Services is only one component of Office SharePoint Server 2007, you need to ensure that your overall Office SharePoint Server 2007 planning process takes into account the particular requirements of InfoPath Forms Services. You may need to increase server capacity to accommodate InfoPath Forms Services users and form templates, particularly if you plan to deploy anonymous form templates to the Internet or plan to deploy complex form templates that require considerable memory and processor time.

For more information on infrastructure and capacity planning for Office SharePoint Server 2007, see the Office SharePoint Server 2007 planning articles Chapter overview: Design server farms and topologies and Chapter overview: Plan for capacity.

Network requirements

In general, you should follow common networking best practices for enterprise systems, such as:

•      Use a firewall between tiers, and between front-end Web servers and the Internet.

•      Use a high-speed network backbone for intra-server communications.

•      Monitor the network environment for peak bandwidth usage and denial-of-service attacks.

•      Perform regular network security audits.

For more information on network requirements, see the Office SharePoint Server 2007 planning article Chapter overview: Design server farms and topologies.

Security requirements

InfoPath Forms Services security takes advantage of the Office SharePoint Server 2007 security framework, but InfoPath Forms Services has its own security considerations apart from Office SharePoint Server 2007 security, which include the following:

•      Administrator-approved form templates may have privileges on corporate systems, including cross-domain access rights, and may contain code that runs under an administrator account. For this reason, it is important that all administrator-approved form templates be carefully reviewed prior to deployment by an administrator who is familiar with InfoPath Forms Services security.

•      An administrator may grant certain farm-level privileges, such as allowing user form templates to use data connections that access data across domains. These settings should be carefully considered before changing the defaults, as they may have a broad impact on security across the entire farm.

•      If you have enabled the Web service proxy, it should run under a unique application pool account. You should disable the Web service proxy if it is not used.

For more information on security requirements, see the Office SharePoint Server 2007 planning article Chapter overview: Plan for and design security.

See Also

Determine the impact of anonymously accessible form templates

Plan server-side data connections needed for form templates

In this article:

•      Scenarios for the use of data connections

•      Database data connection

•      HTTP post data connection

•      SharePoint library submit data connection

•      SharePoint list data connection

•      Web service data connection

•      XML file data connection

A data connection is a dynamic link between a form template and a data source that stores or provides data for the form template. A form template must have one primary data connection, called the main data connection, and it can optionally have one or more secondary data connections. The main data connection defines the main data source of the form template, which is the XML schema that determines how data is stored. The one main data connection allowed on a form template is created automatically when you create the template. You can create as many secondary data connections as you like when you design a form template.

The Microsoft Office InfoPath 2007 designer supports a number of different data connections, which can be used both in the Office InfoPath 2007 program and in InfoPath Forms Services. Office InfoPath 2007 form template designers can develop a form template once and publish it both for the rich client and for the browser using InfoPath Forms Services. If data connections are used within a browser-enabled form template, the form template calls data connections that are resident in InfoPath Forms Services. This topic describes how server-side data connections function when a form template is deployed.

To plan what data connections you will need, gather the following information:

•      What forms currently exist in your organization

•      What application or systems you want to send the data to

Scenarios for the use of data connections

The following are scenarios that show how data connections can be used in conjunction with InfoPath Forms Services.

Scenario 1: Intranet: Authenticated user submitting data through e-mail

April logs onto her computer on the corporate intranet. She browses to her group's SharePoint site and opens an expense report form template from a document library. Because she does not have Office InfoPath 2007 installed, the form is instantiated in her browser. She fills out the form and clicks "Submit." The form is submitted by e-mail to her Accounts Payable department. The mail is delivered to A/P's e-mail box and the "Sender" field shows that the form was sent by "Office Forms Server." Because April is authenticated on the LAN by NTLM, the message's Subject line begins with "Submitted by April Meyer:" Meanwhile, April simply receives confirmation that her form has been submitted.

Scenario 2: Extranet: Basic authentication submitting data through e-mail

The next time April has an expense report to submit, she is traveling to a conference. Using the free wireless Internet at her hotel, she logs into her company's extranet. She is prompted to enter her user name and password. Once she is authenticated, she accesses her expense report form in her browser. When she submits the form, she receives confirmation that the form was submitted. Behind the scenes, mail is sent to A/P as described in the first scenario. Because April is authenticated on the LAN using Basic authentication, the message once again has her name on the Subject line.

Scenario 3: Intranet: HTTP post to application server

Tim works for the IT department at Linfield College. He sets up a BizTalk orchestration to handle admissions applications. He chooses to have the application forms, which are in XML format, submitted using BizTalk's ISAPI adapter. Melissa, who works at the Admissions desk at Linfield, enters the data from the applications that have been submitted by means of postal mail into the application form using InfoPath. When she submits the form, an HTTP post occurs, sending the data to the BizTalk queue.

InfoPath Forms Services uses the E-mail data connection to submit e-mail messages in MIME format on behalf of the user, using mail functionality provided with Windows SharePoint Services 3.0. An e-mail message is sent using the credentials of the account under which the forms server is running. All configuration of this mail service is done by the server administrator. For information about configuring e-mail on Windows SharePoint Services 3.0, see the Windows SharePoint Services Administrator's Guide.

Database data connection

The Database data connection looks up information in a database to populate form fields. You can use this connection to look up data in Microsoft SQL Server, or in any ODBC-compliant database. The Database data connection is query-only and cannot be used to submit data to a database. If you want to use a form to submit data, you should use the Web service data connection.

The Database data connection can authenticate requests to the database in different ways, depending on the security level of the form template that is being used to render the form. Administrator-approved form templates can be designed to have full trust, which means that any business logic or code that runs in the form is authenticated as the InfoPath Forms Services service account unless another authentication method is specified in the form template. Forms that are not running in full trust can only access a database that exists in the same domain as the server running InfoPath Forms Services, and database queries are authenticated either as the user or the account specified in the configuration database. In this case, if authentication fails, a prompt appears in which the user can specify a user name and password to connect to the database.

HTTP post data connection

The HTTP post data connection enables an InfoPath form to post data to an application server using an HTTP post function. The HTTP post originates from the InfoPath Forms Services server.

If the HTTP post data connection is used in a form template running in full trust, then cross-domain HTTP posts can be made. If the form template does not have full trust, HTTP posts can only be made to servers in the same domain as the InfoPath Forms Services server. Before performing an HTTP post, InfoPath Forms Services calls an API method, passing the host name of the computer specified in the connection file to determine whether a connection can be made to that server within the current security context.

SharePoint library submit data connection

The SharePoint library submit data connection enables forms to be published directly to a SharePoint document library. The connection uses the current user identity to access the SharePoint site.

Before submitting a form to a document library, InfoPath Forms Services calls an API method, passing the host name of the computer on which the data source resides to determine whether the form can connect to that server within the current security context.

SharePoint list data connection

The SharePoint list data connection is a query-only connection used to populate InfoPath form fields from an existing SharePoint list.

When this data connection is used, the server calls an API method, passing the host name of the server to determine whether the form can connect to that server within the current security context.

Web service data connection

The Web service data connection can submit data to a Web service and use the return data to update fields in the originating form. This connection collects form data as query parameters, wraps the data in a SOAP envelope, and submits it to a Web service. The connection then obtains the returned SOAP message containing return data or, in the case of failure, error-message data. A Web service connection can be created as a query connection or as a submit connection.

XML file data connection

The XML file data connection connects to an XML file specified when the form template is designed, and it uses the data from the XML file to populate form fields. Form template designers can also choose to include the XML file in the form template itself, which reduces resource-management issues associated with connecting to an external resource.

Plan deployment of form templates

In this article:

•      Browser-compatible form templates

•      Scenario: Insurance claims processing

Microsoft Office SharePoint Server 2007 enables you to deploy rich forms on a server running InfoPath Forms Services that can be opened in Microsoft Office InfoPath 2007, Microsoft Office Outlook 2007, or in a Web browser. Browser-compatible form templates (.xsn files) created in the design mode of the InfoPath client can be published to a document library as browser-enabled form templates that run on InfoPath Forms Services.

You can also upload form templates to a document library that are not browser-compatible. These form templates can only be opened in Office InfoPath 2007.

Worksheet action

Use the Inventory of existing forms worksheet (http://go.microsoft.com/fwlink/?LinkId=73266) to list your current form inventory.

Browser-compatible form templates

There are two categories of browser-compatible form templates: user form templates and administrator-approved form templates. Form templates that do not contain managed code, require full trust, or use a data connection managed by an administrator may be deployed by any user with the Add and customize pages permission. This permission is granted by default to the Design permission level and above on the site collection, but may be granted to any group or user by a site collection administrator.

Note:

For more information on customizing permissions for groups and users, see the Office SharePoint Server 2007 article, Define custom permission levels. Form templates that contain managed code (business logic that incorporates extended functionality such as database queries or integration with third-party application servers), require full trust, or use a data connection managed by an administrator can only be deployed by an administrator.

Important:

In addition to planning for the deployment of form templates, you should also plan a review and testing strategy for deployment of administrator-approved form templates. Because administrator-approved form templates contain code that could run under an administrative user account, it is important that they be subjected to thorough review and testing before they are deployed to a production environment. For more information, see Plan deployment of administrator-approved form templates.

Scenario: Insurance claims processing

This section describes a scenario for the deployment of browser-compatible form templates.

Humongous Insurance, a large insurance organization, introduces Office SharePoint Server 2007 into their environment to enable customers, insurance agents, and related businesses to use online forms for processing insurance claims. The organization has been using InfoPath 2003 internally but is now using InfoPath Forms Services to make forms available to their customers online.

Ted, the lead form template designer for Humongous Insurance, has just completed the design of a form template that allows customers to manage their policy online. Since the form contains business logic and data connections that are managed by the Office SharePoint Server 2007 administration group, he cannot publish the form directly to InfoPath Forms Services. Ted publishes the form template to a network location specified by the administrator, where it can be checked for compliance with design standards for form templates. He then notifies the administrator that the form template is ready for review.

Jorje, the InfoPath Forms Services administrator in charge of validation of form templates, sees the new form template in the network folder. The policy for new form templates at Humongous Insurance is to first validate the template by reviewing the code for compliance with security regulations and design standards, and then to upload the form template to a staging environment for further testing. Jorje reviews the code by opening the form template in the InfoPath program. Then he checks to make sure that the form template code calls the correct data connection, the form template is signed with a digital certificate, and trust settings are configured correctly. When he is satisfied that the form template is compliant with design standards, Jorje uploads the template to the staging environment, which closely matches the production Office SharePoint Server 2007 architecture.

Once the form template has been uploaded to the staging environment, Jorje logs in as a test user and opens the Web page where the form resides. Following his template review checklist, he fills out the form by using every available field and submits it, following this process several times and changing specific data, check box selections, and menu command selections each time. He also verifies that form data is being correctly submitted to the database and that business logic is functioning properly. Once the testing process is complete, Jorje signs off on the review checklist and uploads the form template to the production environment.

See Also

Plan what form templates are needed

Plan deployment of administrator-approved form templates

Plan deployment of administrator-approved form templates

InfoPath Forms Services provides functionality that enables both administrators and users to deploy browser-compatible form templates. Browser-compatible form templates (.xsn files) created in the design mode of Microsoft Office InfoPath 2007 can be opened in a Web browser from servers running InfoPath Forms Services. InfoPath form templates (.xsn files) created in Office InfoPath 2007 design mode can be converted into browser-enabled form templates that run on Microsoft Office SharePoint Server 2007. An administrator must deploy form templates that contain business logic such as a compiled, managed code DLL (form code); require full trust; or use a data connection that is managed by an administrator.

If your organization will deploy form templates that require administrator approval, you must consider several factors in your planning:

•      Map out a review and testing strategy for the deployment of administrator-approved form templates. It is important that form templates that could potentially have a performance impact on the server or that contain business logic are thoroughly reviewed and tested prior to deployment to production systems. We recommend that as part of your planning process, you develop a design standard for form templates that defines best practices, guidelines, and mandatory requirements to be followed by designers of form templates. We recommend that you develop a review checklist for form templates that makes it easy for administrators to verify that new form templates comply with the standards you have established. Also note that any good testing process includes testing in a staging environment to verify that the form template works as expected and to measure the performance impact under load.

•      You should make sure that administrators are available to approve forms in a timely fashion. This will help to reduce bottlenecks in the publishing cycle. Administrators who review and approve form templates should be familiar with the form template design process and have a good understanding of the networking environments to which the form template will be available once it has been deployed.

•      You should carefully consider the approval workflow. If your organization will use form templates that perform sensitive operations, such as submitting data to databases or Web services, then you should ensure that your approval process allows for adequate technical review.

•      You should have an accurate understanding of the difference between administrator-approved form templates and user form templates, and which form templates require deployment by an administrator.

•      You should make sure your server configuration strategy enables the features you need to support the deployment of administrator-approved form templates.

•      You should ensure that you understand how network and application security affect your organization's forms. For example, if a form will access databases in a different domain than the Office SharePoint Server 2007 server on which the form template resides, such a form template requires full domain trust. Therefore, it must be carefully reviewed by an administrator prior to deployment to confirm that the form template's code does not compromise your organization's security policies. Likewise, you should confirm that form template authentication and authorization have been properly configured.

•      Determine whether new form templates that require administrator approval need to be created on a regular basis, and if so, ensure that the necessary procedures, personnel, and applications are in place to support the approval process.

Worksheet action

Use the Plan deployment of administrator-approved form templates (http://go.microsoft.com/fwlink/?LinkId=73267) worksheet to record the administrator-approved form templates you plan to deploy.

See Also

Plan what form templates are needed

Plan deployment of form templates

Determine the impact of anonymously accessible form templates

In this article:

•      Identify the need for anonymously accessible form templates

•      Security and usage considerations for anonymously accessible form templates

•      Bandwidth and capacity considerations for anonymously accessible form templates

If your organization plans to deploy form templates that can be accessed by unauthenticated users, you need to consider a variety of factors in your planning. Without adequate planning, form templates that can be submitted without user authentication can present problems with security, improper usage, bandwidth, and database capacity. Before making form templates anonymously accessible either on a private network or on the Internet, carefully read this article and make sure that your strategy takes these considerations into account.

Identify the need for anonymously accessible form templates

Anonymously accessible form templates provide your end users simple and unobstructed access. Two likely scenarios for anonymously accessible form templates are over the Internet and within the corporate network.

Internet scenario

Anonymously accessible form templates are a reasonable choice on the Internet when there are no security concerns about the functionality or data associated with the form template. Providing anonymously accessible form templates on the Internet can reduce administrative effort because user authentication does not need to be managed or maintained.

Corporate scenario

The reasons for using anonymously accessible form templates within a corporation are similar to those for the Internet. The difference is that users are within a closed network, an Intranet, or are authenticating through a Virtual Private Network, a Remote Access Server, an extranet, Terminal Services or a password-protected Web site. Unlike the Internet scenario, users would typically be known on the network. Providing anonymously accessible form templates can enhance user experience in situations where unfettered and anonymous access is desirable. For example, a corporate survey of employees might produce more candid and useful responses if they are anonymous.

Another advantage to using anonymously accessible form templates is that performance can be improved when you implement anonymous scenarios. Performance advantages are realized because postbacks to request access control list (ACL) verifications are eliminated.

Security and usage considerations for anonymously accessible form templates

Before making a form template anonymously accessible, you must consider the possible consequences to security and the implications of attempts to improperly use the form template.

•      You should ensure that form templates cannot be accessed by scripts or other automated or non-human processes. One way to achieve this is to force users submitting a form template to enter an identification code such as a short alphanumeric string displayed in an image, which cannot be "read" by a script or automated process.

•      Form templates that contain sensitive information such as authentication information, server or database names, or proprietary code should not be exposed to anonymous users.

•      Form templates that contain code or functionality that can invoke processes on a server should be carefully evaluated and tested to ensure that security cannot be compromised by making the form template accessible to anonymous users.

•      In order to prevent users from submitting multiple copies of a form, you might consider including code that tracks the IP address of each user who submits a form and prevents duplicate submissions from the same IP address.

Bandwidth and capacity considerations for anonymously accessible form templates

Once you make a form template anonymously accessible to the Internet, you no longer have control over how many times that form is submitted. Therefore, before publishing an anonymously accessible form template to the Internet, carefully consider your expectations regarding the following factors:

•      How many users will submit the form within a given time period

•      How much data must be transferred and stored

•      How much server processor time, memory and throughput will be utilized each time the form is submitted

You can then estimate how much bandwidth, server processor time and database capacity is required in order to support the form template. Using the IIS administration tool, you can throttle bandwidth and the number of concurrent connections for a Web site if you want to control usage.

See Also

Plan what form templates are needed

Plan for naming form templates

You should establish a naming convention for form templates that avoids confusion about their origin and usage. Of course, you can name form templates any way you like, but it's useful in the long run to follow a logical naming convention. General best practices include:

•      Make sure that form template designers are aware of the naming conventions you establish, and that they understand how to check for duplicate template names before saving a new template. Conversely, as the administrator, you can change template names to conform to naming conventions before uploading them to the system.

•      Establish a naming convention that reflects relevant information about the templates.

•      Avoid using dates in form template names, as date information may be confusing if a form template is upgraded at a later time.

•      Make sure that you distribute form template naming conventions to InfoPath designers and administrators.

•      Keep in mind that form templates may be reused throughout your enterprise, and that developers may use file names to organize form templates.

See Also

Plan version control for form templates

Plan custom form templates

Plan for upgrading form templates

You can upgrade administrator-deployed form templates in InfoPath Forms Services when you upload a new version of an existing form template. The upgrade process allows you to configure how the transition between the existing version and the upgraded version will take place.

There are three ways to upgrade a form template. Before you upgrade a form template, evaluate the circumstances and choose the most appropriate type of upgrade.

•      Hard upgrade   If you want to remove the existing form template when the upgrade takes place, you can use a hard upgrade. Existing form-filling sessions are terminated and all user data is lost. The user must begin a new form-filling session with the upgraded form template to continue. This upgrade method should only be used when a serious problem with the form template has been identified and you need to remove it from the system immediately.

•      Quiesce and upgrade   If you need to ensure that a form template will no longer be available for use after a given time and you want to allow existing form-filling sessions to complete, you can quiesce the existing form template and then upgrade to the new version. This upgrade method is useful when a form template contains content or code that will become obsolete or outdated at a given time.

•      Gradual upgrade   If you want to allow the existing form template to remain available for an indefinite period, you can upload the new version as a new form template and remove the old version when it is no longer in use. This is the method that should be employed for most normal upgrades.

Note:

Before you upgrade a form template, make sure that you have adequately reviewed the new template and checked for problems that may affect security and proper operation of the form.

Plan for retiring form templates (Office SharePoint Server)

InfoPath Forms Services administrators can retire form templates when they become obsolete. For example, you may want to retire a survey form template when the survey has been completed.

When a form template is no longer in use, you should generally retire the form template rather than deleting it. This preserves a record of form templates that have been used in your enterprise, and enables them to be reused later.

In the interest of keeping document libraries current and uncluttered, make sure that form templates that are no longer used are retired, and that you have a policy in place for auditing and upgrading existing form templates.

When you deploy a form template, consider the following:

•      Will this form template eventually need to be retired, or will it need to be upgraded?

•      How will you track the life cycle of form templates to be retired?

If you plan to retire a form template that is still in use, you should plan to use one of the following methods:

•      Perform a gradual upgrade. In a gradual upgrade, you deploy the latest version of a form template alongside the current version and redirect users to the latest version. Once the older version of the form template is no longer being accessed, you can retire it safely.

•      Quiesce the form template before upgrading. This prevents current sessions from being terminated, which can result in the loss of data and an abrupt interruption of user form-filling experiences.

For more information on how to quiesce form templates, see the "Quiesce form templates" section in Manage form templates.

See Also

Plan for upgrading form templates

Plan version control for form templates

In this article:

•      Document Retention

•      Capacity Planning

You can configure InfoPath Forms Services to enable version control for form templates at the document-library level. Enabling version control causes the library to create a new version of the form template every time the template is edited and saved, preserving previous versions as defined by the administrator. If form templates will be regularly edited in a given document library, you should configure the library for version control. This prevents existing form templates from being overwritten when edits are made, and it provides a mechanism for rolling back to a prior version.

Note that version control does not apply to form template upgrades. When you upgrade a form template by uploading a new version of an existing form template, the prior version of the form template is no longer available, and there is no mechanism provided for rolling back from an upgrade.

Note:

You can only configure version control for a given document library. You cannot configure "global" version control for sites, site collections, or farms.

Document Retention

If version control is enabled for a document library, the library owner has the option of allowing unlimited previous versions to be retained. The library owner can also elect to only allow a certain number of versions to be retained, but there is no provision for automated deletion of documents past a certain age, also known as tombstoning. This means that documents could potentially be retained for years unless they are manually deleted. You may want to consider the following factors:

•      Your organization's policy may require that documents past a certain age be destroyed. You should plan how to conform to such policies, and how to monitor the age of documents on the farm.

•      If new versions of documents are uploaded without version control, there is a risk that obsolete documents may be accessed by users. You should ensure that document libraries are configured to prevent obsolete documents from remaining available on the system.

Capacity Planning

The farm administrator does not have any direct control over whether document library owners enable version control for their libraries. Therefore, you should consider the following when planning farm capacity:

•      You should plan to use reporting to run regular reports on the size of document libraries in the farm.

•      You should ensure that sufficient database capacity exists to provide overhead for a potentially large number of documents.

See Also

Plan deployment of form templates

Plan for mobile device access to form templates

InfoPath Forms Services provides access to browser-enabled forms from mobile devices such as handheld PDAs that support HTML, CHTML, or XHTML. Because each mobile device renders Web pages differently, the behavior of forms will vary depending on the device used.

Note:

InfoPath Forms Services does not support Wireless Access Protocol (WAP) browsers.

Because of the lack of standardization across mobile devices, the user experience may be significantly different depending on what type of device is being used. Different mobile devices will automatically break up the user interface into different views, in a device-specific way. Possible examples may include:

•      Automatic pagination

•      Automatic switching between list and detail views for lists

•      Automatic switching to a separate edit view for each editable field

Furthermore, because mobile devices may or may not support script execution, and due to low memory and bandwidth capabilities for many of those devices, InfoPath Forms Services cannot use a client-side architecture (CSA) for mobile devices as it does for standard Web browsers. Instead, InfoPath Forms Services uses ASP.NET mobile controls. This means that a mobile device browser will not:

•      Provide client-side actions using script. All such actions will post back to the server.

•      Use out-of-band postback as is used by a standard Web browser. Instead, the mobile device browser will always perform a full-page postback.

Mobile device browsers will therefore need to post back much more frequently than a desktop browser accessing InfoPath Forms Services. You should carefully plan how to support your mobile infrastructure in order to maximize performance.

When an HTTP request is received by InfoPath Forms Services, the server detects whether the request is coming from a mobile device and redirects the request to the appropriate page. ASP.NET mobile controls also can detect the device making a connection and auto-change the protocol used for the connection. For more information about ASP.NET mobile controls, see Mobile Controls (http://go.microsoft.com/fwlink/?LinkID=72731) on the Microsoft Web site.

When planning for mobile device access, you need to consider the following:

•      How many mobile devices do you expect to be accessing your documents and form templates?

•      How will these devices be connected to the network (Wireless access points throughout the organization, across the Internet)?

•      Will there be a standard for the type of mobile device accessing the server? If so, it would be easier for form template designers to exercise control over the way mobile forms will be displayed.

See Also

Plan deployment of form templates

Plan workflow for form templates

Workflows implement business processes on documents, Web pages, forms, and list items in Microsoft Office SharePoint Server 2007. They can be associated with libraries, lists, or content types. For more information on workflows, see Plan workflows.

There are three contexts for workflow planning in relation to forms:

•      Custom workflow form templates — The form template is included in a custom workflow package to gather information as a part of the workflow.

•      Workflows for form template approval — The workflow is used to approve a form template, as it would be to approve any other type of page or document in a library.

•      Workflows launched from a form — The workflow is bound to the Submit or Save button on the form template. When the user clicks the button in a form-filling session, the workflow is launched.

Custom workflow form templates

You can upload a custom workflow package to Office SharePoint Server 2007 that includes workflows and form templates. When a workflow uses a form template as an interface to gather data during the workflow process, these form templates are integrated into the application experience by means of an InfoPath Forms Services Web Part.

These server-side workflow form templates are specific to the workflow and cannot be activated to a site collection or added to a document library. These form templates are stored in the farm forms library and must be uploaded by an administrator. Office SharePoint Server 2007 includes several form templates that are specifically for use in default workflows. These form templates cannot be used outside of these workflows.

Workflows for form template approval

You can use a workflow to review or approve a form template in the same way you can use workflows to route any document or page for review. For more information, see Plan workflows for document management.

Workflows launched from a form

InfoPath Forms Services can be used to launch workflows using the submit button in a form. For example, you can use browser-enabled form templates in a workflow that routes documents from person to person to complete document management tasks, such as reviewing documents, approving their publication, or managing their disposition.

Additionally, administrator-approved form templates can be designed to initiate a workflow. For example, when a form template used for collecting customer information is submitted, it could start a workflow to notify the appropriate personnel and require action within a given time frame.

If you will deploy form templates that trigger workflows, keep the following things in mind:

•      Workflows need to be enabled for the site collections to which the form template will be deployed. If workflows are not enabled for a site collection, a workflow-enabled form template will generate errors on the server when it is submitted.

•      You should ensure that the workflow exists and is enabled in the production environment. A form template designer will typically be designing a form template against a development environment that may have workflows and other custom features that have not been deployed to the production system.

•      Ensure that the workflow is configured to work the same way in the production environment as it does in the development environment.

See Also

Plan workflows

VII.  Plan for business intelligence

The articles in this chapter include:

•      Plan for business intelligence

•      Determine business data and business intelligence needs

•      Determine scope of business intelligence analysis

•      Plan data connection management

•      Plan key performance indicators

•      Plan reports

•      Plan dashboards and filters

•      Plan Excel Services security

•      Determine resource requirements to support Excel Services

•      Plan rendering Excel KPI data

•      Plan Excel reports against OLAP cubes

•      Plan access to Excel spreadsheets

•      Plan for business data connections with the Business Data Catalog

•      Plan for business data profiles

•      Plan business data lists

•      Plan business data Web Parts

•      Plan business data actions

•      Plan for business data search

Plan for business intelligence

Business intelligence enables you to store data that represents your organization's key business processes, to organize that data in a useful manner, and to present that data as meaningful information. Knowledge workers can then act on that information to increase productivity and to provide feedback that improves underlying business processes.

Business intelligence planning is a key part of any deployment of Microsoft Office SharePoint Server. You start by identifying the business needs of your organization. Then, you identify the features of Office SharePoint Server that can help you collect, present, and act on data in your organization.

Plan for business intelligence and business data by using the following steps:

1.   Plan for business intelligence needs   Consider the business processes and business data applications commonly used by your organization, plan the scenarios in which you work with business data, and determine the scope of the business intelligence analysis that your organization is considering. Use the following articles to help plan for business intelligence needs:

•      Determine business data and business intelligence needs provides a discussion of using business intelligence and business data presentation to increase the effectiveness of data analysis and business processes for the common business scenarios of your organization.

•      Determine scope of business intelligence analysis provides a discussion of the appropriate depth of planning for analysis and use of business data.

2.   Plan for business intelligence   Plan data sources for the core business intelligence functionality of Microsoft Office SharePoint Server 2007, and then plan the analysis tools used in SharePoint sites based on those data sources. Use the following articles to help plan for business intelligence:

•      Plan data connection management provides a discussion of connecting to data in Microsoft SQL Server 2005 Analysis Services cubes and other databases.

•      Plan key performance indicators provides a discussion of calculating easy-to-use scorecards from ranges of data in data connection libraries, Excel Services in Microsoft Office SharePoint Server 2007 worksheets, business data lists, and SharePoint lists.

•      Plan reports provides a discussion of presenting key performance indicators (KPIs) and business data Web Parts in Report Center pages and other sites to improve analysis of business data and key business processes.

•      Plan dashboards and filters provides a discussion of displaying multiple related reports and KPIs, and connecting the Web Parts for business data so that you can filter data based on key business properties for all reports on the dashboard page.

3.   Plan for Excel Services   Plan to use Excel Services to analyze business data and increase business intelligence. Use the following articles to plan for Excel Services:

•      Plan Excel Services security provides a discussion of security considerations to use with Excel Services.

•      Determine resource requirements to support Excel Services provides a discussion of the factors that can affect the performance and availability of Excel Services.

•      Plan rendering Excel KPI data provides a discussion of how data in spreadsheets can be rendered in KPI List Web Parts or aggregated into a dashboard.

•      Plan Excel reports against OLAP cubes provides a discussion of online analytical processing (OLAP) functions and formulas that can be used to create customizable reports.

•      Plan access to Excel spreadsheets provides a discussion of spreadsheet management and controlling access to workbooks.

•      Plan external data connections for Excel Services provides guidance for configuring Office SharePoint Server 2007 to enable workbooks loaded on Excel Services to successfully refresh external data.

4.   Plan for business data presentation   Plan to use data from line-of-business applications to analyze and act on data in your SharePoint sites. Use the following articles to plan for business data presentation:

•      Plan for business data connections with the Business Data Catalog provides a discussion of registering applications in the Business Data Catalog.

•      Plan for business data profiles provides a discussion of which business data types and properties to include when registering applications in the Business Data Catalog.

•      Plan business data lists provides a discussion of adding columns to SharePoint lists that contain data from applications registered in the Business Data Catalog.

•      Plan business data Web Parts provides a discussion of creating Web Parts based on the data in business data lists, the many types of business data Web Parts, and the sites that can benefit from using these Web Parts.

•      Plan business data actions provides a discussion of creating actions based on properties of business data, and displaying those actions in Web Parts that can be connected to other business data Web Parts and filter Web Parts.

5.   Plan for business data search   Plan to include data from business applications in search queries from your SharePoint sites. Use the following article to plan for business data search:

•      Plan for business data search provides a discussion of adding business data content sources, mapping crawled business data properties to managed properties used by search queries, and modifying the search experience so that business data is easier to find and business data search results are more relevant.

For a demo about enabling Excel Services, see Demo: Enable Excel Services and data connections for a SharePoint team site. For more information about Excel Services functionality and understanding the relationships among various components of Microsoft Office SharePoint Server 2007, see White papers: Excel Services step-by-step guides.

Determine business data and business intelligence needs

In this article:

•      About business intelligence

•      Plan Office SharePoint Server 2007 features for business intelligence

•      Plan business data scenarios

•      Determine business intelligence needs for your organization

•      Worksheets

Microsoft Office SharePoint Server 2007 includes business intelligence capabilities that can help you preserve data integrity throughout your organization while enabling powerful search, data integration, data analysis, data rendering, and data sharing scenarios.

The business intelligence functionality in Office SharePoint Server 2007 enables centralized management and control of shared resources that can include reports, forms, documents, spreadsheets, and data connections.

As part of planning for your initial deployment of Office SharePoint Server 2007, you should understand business intelligence and how it relates to the processes and conditions of your organization. This will enable you to identify specific business intelligence needs in your organization, and to use those needs to identify which features of Office SharePoint Server 2007 to implement to improve your business processes over time.

About business intelligence

Business intelligence, sometimes known as business performance management, is a set of technologies used to increase the understanding of business processes and their associated data. Good use of business intelligence helps you organize data about your organization so that it is useful, actionable, and capable of transforming your underlining business processes. These goals are achieved through the following processes:

•      Gather data   The first step in building business intelligence is to create and store data that accurately represents what is happening in your organization. Databases are only useful when the data they are tracking is representative of business processes and business conditions. It can be difficult to determine what is missing from data sources, so that additional data can be gathered to improve business processes.

•      Turn data into useful information   Data is typically represented as sets of fields that have corresponding values. By itself, data is neutral and not inherently useful. When you use tools and business processes to make data useful, you create information. One key way to create information is to create a view into data that contains a subset of data that is useful for one or more groups of users in your organization.

•      Use information to impart knowledge   Knowledge is created when you provide actionable information to the people who can use that information. Having a list of data that might be interesting to a particular group of people is better than having raw data, but it does not actually enable you to do anything. By personalizing information, targeting audiences and groups, and providing a way for people to analyze and interact with data, you create actionable information that is the basis for knowledge in your organization.

•      Turn knowledge into action   As you build a base of knowledge in your organization, knowledge workers act more efficiently in pursuing key business goals and managers can identify opportunities for improvement and make decisions based on that knowledge to improve business processes.

Business intelligence provides an effective set of solutions that correspond to each of these steps in an integrated process that enables you to continually improve business processes. Starting with data, you create information that can help you achieve an understanding of the processes. Then, you act on that information to build a base of knowledge and update information, while also changing business processes. These changes produce new data and information that you can use to deepen your knowledge and continue to change your business processes in the future.

Business intelligence includes several strategies and techniques that are designed to improve business processes:

•      Data integration   This includes data storage and warehousing, data mining, and data consolidation. Data integration involves collecting information from various structured and unstructured sources, and consolidating it into a single data source that can be used to create meaningful information by using the business intelligence tools of an organization. Information presentation enables users to query data sources and find usable information that can be analyzed against business goals, while ensuring security and data integrity in a collaborative workspace.

•      Information presentation   This includes information discovery, visibility, analysis, and collaboration.

•      Reporting   This includes the use of scorecards and other tools used to compare information across multiple business processes. Reporting tools, such as scorecards, enable knowledge workers to evaluate information and act on it, thereby creating a base of knowledge for your organization.

Each of these strategies corresponds to an essential step of business performance. Using all of these techniques together creates positive feedback loops of increasing knowledge that can be used to improve your organization and its business processes and associated data over time.

Plan Office SharePoint Server 2007 features for business intelligence

Office SharePoint Server 2007 provides many tools that enable you to display information and build knowledge in your organization. You can use the personalization and targeting features of Office SharePoint Server 2007 to increase the usability of your data and enable knowledge workers in your organization to act on the information built on that data. You can aggregate content across many sources and find it more easily by using search features. Office SharePoint Server 2007 supplements these features with an important set of features for business intelligence.

These features include:

•      Data integration features, such as data connection libraries, the Business Data Catalog, business data profiles, and business data lists.

•      Information presentation and reporting features, such as reports, key performance indicators (KPIs), and dashboards.

Plan data integration features of Office SharePoint Server 2007

Data warehousing and data mining are techniques for gathering useful information from your existing data sources. Business intelligence solutions frequently use online analytical processing (OLAP) tools to provide meaningful data and expose underlying patterns that might not be otherwise apparent. Office SharePoint Server 2007 uses Microsoft SQL Server 2005 Analysis Services. OLAP and SQL Server 2005 Analysis Services are preferred for large data sources that have relatively stable and unchanged data. That data is then used to create information in processes that change more quickly.

Office SharePoint Server 2007 can also use data from other business applications, known as line-of-business applications. Although not part of the core business intelligence functionality, the data from these applications can be displayed and analyzed in similar ways as the data in data connection libraries, providing an integrated view of all business data in the organization. Line-of-business applications manage data about people and business operations and are widely used within large organizations and enterprises. Examples of line-of-business applications include:

•      SAP Business Information Warehouse or mySAP ERP

•      Siebel eBusiness Applications

•      Attunity Legacy Data Access Solutions

•      Microsoft BizTalk Server

These applications are registered in the Business Data Catalog. Data from the Business Data Catalog is used by Office SharePoint Server 2007 to create additional kinds of information for the knowledge workers in your organization. That information can be easily integrated with the other features of Office SharePoint Server 2007 site collections.

Data consolidation is the process of grouping data in meaningful ways so that it is useful. The key data consolidation features of Office SharePoint Server 2007 are data connection libraries, business data profiles, and business data lists.

A data connection library is a library of connections to data sources that can be analyzed by using SQL Server 2005 Analysis Services. This allows the data to be analyzed and displayed by using the business intelligence features of Office SharePoint Server 2007. Data connection libraries include links to data sources, such as SQL Server 2005 Analysis Services cubes, that are relevant for a particular site or site collection.

Business data profiles are lists of properties associated with business data types from line-of-business applications registered in the Business Data Catalog. Each business data profile is a meaningful consolidation of relevant data for key business processes to create usable information for users in your organization. For example, you can have a business data profile for customers that tracks telephone numbers, addresses, e-mail addresses, and locations for each customer.

Business data lists are SharePoint lists that gather one or more columns directly from the data of one or more business applications. Each list has a collection of items with several columns that represent properties for each item. Lists can contain information similar to the information in business data profiles. You can also create lists for KPIs, another important business intelligence feature.

Plan information presentation and reporting features of Office SharePoint Server 2007

After data is consolidated in a meaningful form, additional business intelligence tools enable knowledge workers to query and analyze the resulting information and act on it as quickly and effectively as possible.

You can query business data by using the business data features of Office SharePoint Server 2007 search. You register applications in the Business Data Catalog, and then you crawl content sources for those applications. The subset of data selected by administrators for the Business Data Catalog is then available for administrators for search to map to managed properties that affect the results of search queries.

Users in your organization can search for business data and find meaningful and useful results. For example, the administrator of the Business Data Catalog registers a sales application and selects business data types for customers, product lines, and sales associates, and also selects the properties for the business data profiles associated with those business data types. The Shared Services Provider (SSP) administrator who is responsible for search then creates a content source for the application. After crawling the content source, the SSP administrator for search maps selected crawled properties to managed properties used by the system during search queries. Users who search for a customer based on the customer name, location, or address are more likely to find the customer if the customer name, location, and address are managed properties. These managed properties can also be used to create search scopes.

You can analyze business data by presenting it within sites in your site collection. Business data stored as information in lists or business data profiles in the Business Data Catalog can be used in several technologies designed to enable analysis of information so that knowledge workers can act on information and create knowledge.

For example, you can create KPIs, which calculate a value from a range of data, and compare that data against a target to indicate the performance of key business processes. By analyzing a list of related KPIs, you can see how different business processes interact.

You can also create reports that take KPIs or business data lists by using properties in the Business Data Catalog and display that information with related SharePoint information, such as documents or workspaces.

Dashboards display several business data Web Parts for different data sources and business processes in one place. The Web Parts on dashboards are connected to filters so that the dashboard owner can limit the scope of the data presented across all Web Parts. Users can apply one or more filters to analyze the data in a way that is more relevant to each person. Within dashboards, users in your organization can also use Excel Calculation Services and Excel Web Access Web Parts to look at data sources and filter them based on one or more columns in each workbook.

Each of these analysis tools creates more actionable information. To complete the business intelligence cycle, there are several methods provided by Office SharePoint Server 2007 for acting on information immediately after analyzing data. If you are using Microsoft Office Excel 2007 and have the appropriate permissions, you can start an Office Excel 2007 client to directly edit the underlying workbook. You can add business data actions that appear in search results, the business data profile, reports, and dashboards that directly relate to the information in each of these presentation options. You can edit business data profiles as new information about your business is collected. Knowledge workers in your organization can act on information as they see it, immediately providing feedback that improves productivity. They can also detect underlying patterns to business processes, which can be used to improve your processes, data collection, and information presentation.

Plan business data scenarios

Business intelligence features are deployed as part of larger business data scenarios. These scenarios can be defined in several ways, including:

•      By the purpose of the organization and site collection that is using business data.

•      By specific business processes within a larger scenario for your organization.

•      By information technology infrastructure, deployment, and security concerns.

Plan purpose-based scenarios

Examples of scenarios based on the purpose of an organization and site collection include:

•      Call center   Find open customer service requests (CSRs) in the CSR database from the Search Center site, update CSRs by using InfoPath Forms Services forms tied to business actions, and view performance of front-line technicians by using KPIs.

•      Employee records and personalization   Target data to employees in portal sites based on their Siebel or SAP properties, and allow employees to update their information by using Web-enabled forms.

•      Customer facing   Use Web-enabled InfoPath Forms Services forms to provide a way for customers to personalize account information, update insurance claims information, or submit government forms.

These types of scenarios are useful to consider when you are planning the business intelligence needs of your site structure.

Business intelligence needs can be much more diverse than these few examples, and every organization is unique. For your organization, it is a good idea to state the broad scenario that is relevant before you begin specific planning to deploy a solution for that scenario. For each site collection in your organization, identify those that are using business applications, and identify which applications are central to the purpose of each site collection. Think of the features you will use in broad terms.

Plan process-based scenarios

Examples of scenarios based on more focused business processes within a larger business data and business intelligence framework include:

•      Prediction analysis   Show additional items that might be of interest to people buying a displayed item. For example, display additional products created by the same person or organization.

•      Cross selling   Offer discounted services and products in conjunction with a purchase. For example, offer an item for free with the purchase of two similar items.

•      Data mining   Find and use hidden data. Build behavioral models based on tracking. For example, find card-key access by time of day, by date, by building, or by event to determine traffic patterns.

•      Sales forecasting   Review current account status or customer characteristics and make adjustments based on live data.

•      Purchase order approval   Check current budget status and other data before approving a workflow-generated purchase order.

You can identify similar scenarios to represent different sets of business processes within your organization. Then, you can plan for the specific features you need to address each set of business processes.

You should also consider the planning for infrastructure, security, and other information technology considerations. The business scenarios and business process planning within each scenario that you identify are affected by the environment in which you deploy, and similar overall scenarios that have different deployment scenarios will be planned differently.

These types of scenarios are useful to consider when you are focusing on business intelligence planning and want to determine the appropriate scope of your business intelligence solution.

Plan IT-based scenarios

Examples of scenarios based on deployment and security considerations include:

•      Human resources site collection   One source, one consumer. The application administrator uses business data features to construct a site collection that displays human resources data from a data warehouse. The data on the site collection is sensitive, and is displayed only on that site collection.

•      Expense reports across sites and site collections   One source, many consumers. Team site owners want to display a list of pending expense reports for their teams. Individuals want a My Expense Reports Web Part on their personal site home pages. Expense data changes frequently, so the data is collected from SAP by registering the application in the Business Data Catalog and then by using that data in multiple sites.

•      Product issues databases   Many sources, many consumers. Team site owners want to include live data from a product issues database application on their team sites. There are many databases for different products and teams.

•      Product issues data is provided to an external partner   A business partner uses an extranet that has access to a subset of relevant product issues.

These types of scenarios are useful to consider when you are planning the architecture and deployment of your business intelligence solution.

Whatever your deployment considerations, the people on your planning teams should consider each business scenario and feature in the context of the supporting infrastructure of your organization.

Determine business intelligence needs for your organization

One or more of the scenarios described above, or similar scenarios, can exist within any organization that is deploying Office SharePoint Server 2007. When you plan for business data and business intelligence, consider the scenarios that apply to your organization, and then select the features of Office SharePoint Server 2007 to use that correspond to those scenarios.

Scenarios will revolve around distinct business processes, each of which is built on one or more data sources. These sources are used by features that present that data as information to knowledge workers, who then act on that information. Your business intelligence needs for each business process will correspond to the essential steps of business intelligence: The essential steps of business intelligence are:

1.   Connect to business data sources and collect data.

2.   Present business data as information.

3.   Query and analyze data.

4.   Act on data.

The corresponding feature planning steps are:

1.   Plan line-of-business applications and the Business Data Catalog and SQL Server databases.

2.   Plan business data profiles and business data lists.

3.   Plan business data search, KPIs, and reports.

4.   Plan dashboards, the Report Center site, and business data actions.

If you consider these points when planning the initial deployment of business intelligence features of Office SharePoint Server 2007, you are much more likely to create a business intelligence solution that accomplishes your goals.

Worksheet action

Use the Business data worksheet (http://go.microsoft.com/fwlink/?LinkID=73271&clcid=0x409) to record your decisions. For more information, see the worksheet actions described in the planning topics for particular business data and business intelligence features.

Worksheets

Use the following worksheets to determine business data and business intelligence needs:

•      Business data worksheet (http://go.microsoft.com/fwlink/?LinkID=73271&clcid=0x409)

•      Site creation worksheet (http://go.microsoft.com/fwlink/?LinkId=73138&clcid=0x409)

Determine scope of business intelligence analysis

In this article:

•      About business intelligence scope planning

•      Business intelligence principles

•      Business intelligence examples

About business intelligence scope planning

Business intelligence is the process of gathering, storing, analyzing, and accessing business data across an organization. Microsoft SQL Server 2005 provides a storage and management foundation for business data, and a set of reporting and analysis tools. Microsoft Office SharePoint Server 2007 provides controlled access to — and analysis of — business data, and the ability to leverage data to make better business decisions. Office SharePoint Server 2007 supports workflow, document management, search, data integration, data analysis, and data rendering. It enables you to maintain data integrity and centrally manage shared resources that can include reports, forms, documents, spreadsheets, and data connections.

The Microsoft BI stack is an end-to-end solution built on Microsoft SQL Server 2005, Office SharePoint Server 2007, 2007 Microsoft Office system client applications, and performance management products provided by the Office Business Applications group.

SQL Server 2005 is the data storage and analysis foundation of the Microsoft BI stack. SQL Server 2005 provides relational database management system (RDBMS) data storage, and a set of management tools including:

•      SQL Server 2005 Analysis Services

•      SQL Server 2005 Integration Services

•      SQL Server 2005 Reporting Services

•      SQL Server 2005 Business Intelligence Development Studio

Business intelligence principles

The principles of business intelligence in Office SharePoint Server 2007 include:

•      Data gathering   Integrating data from various structured and unstructured sources.

•      Data storage   Providing a secure, centrally managed data repository.

•      Data analysis   Creating hierarchical views to enhance data discovery and rendering data that can be understood in business terms.

•      Data access   Improving data quality and ensuring data integrity by providing secure access to shared data resources in a collaborative workspace.

•      Data cleansing   Ensuring that data from the source makes sense, is not duplicated, and does not contain null values.

•      Extract, Transform, and Load (ETL)   Extracting data from source databases, transforming data into the structures used in targeted databases, and loading data into targeted databases.

Business intelligence examples

Some examples of business intelligence solutions include:

•      Predictive analysis   Determining the probable outcome of an event or the likelihood of a database state using information that is extrapolated from a known data set.

•      Data mining   Sorting through data to identify patterns and establish cause-and-effect relationships.

•      Sales forecasting   Reviewing current account status or customer characteristics and making adjustments based on live data.

•      Purchase order approval   Checking current budget status and other data before approving a workflow-generated purchase order.

•      Closed-loop analysis   Continuously tracking and improving the quality and performance of products and processes based on feedback. Closed-loop analysis enables you to align the day-to-day operations of an organization with a long-term business strategy. You can use closed-loop analysis to make data more discoverable and actionable.

Plan data connection management

In this article:

•      About data connection management in Office SharePoint Server 2007

•      Plan access to external data

•      Plan access to data connection libraries

About data connection management in Office SharePoint Server 2007

Because connections to data sources are volatile, IT managers need an efficient way to maintain and update connections from Microsoft Office Excel 2007 spreadsheets to data sources. The physical stores that contain data sources can be moved and the names of physical stores can be changed. When a spreadsheet contains direct links to data sources, link integrity is dependent on the validity of the logical address of the linked source. If the logical address of a data source changes, or if the address of the data store that contains the data source changes, the link to the data source is broken.

Excel spreadsheets can contain data from multiple external data sources. Tracking and maintaining connections to multiple data sources within a single spreadsheet can be difficult and time consuming. IT managers often have to track and maintain multiple data sources in hundreds or thousands of spreadsheets. With Microsoft Office SharePoint Server 2007, you can prevent broken links to data sources by defining data connections and storing them in data connection libraries that can be centrally managed, updated, maintained, and listed in a SharePoint site.

Plan access to external data

To plan a strategy for data connection management, you need to determine what kind of external data Excel spreadsheets will be accessing in your deployment scenario. Excel spreadsheets can access Microsoft SQL Server data and online analytical processing (OLAP) data. You can determine how data connections in workbooks that are opened in Excel Calculation Services are handled by the server. You can configure Excel Calculation Services to:

•      Block all data connections.

•      Allow data connections from trusted data connection libraries only.

•      Allow embedded data connections and data connections from trusted data connection libraries.

Data connections can be saved as Office data connection (.odc) files, which are stored separately from spreadsheet files. Workbook authors who have write permissions to Office SharePoint Server 2007 can create data connection files from Office Excel 2007 by using the Data Connection Wizard. The wizard enables workbook authors to create .odc files and save them to a data connection library. Workbook authors who have access permissions to the data connection library can then use the .odc files to create data connection links in their workbooks.

Plan access to data connection libraries

Excel Services in Microsoft Office SharePoint Server 2007 provides an efficient way to manage the connections from Excel spreadsheets to external data sources by preventing the use of embedded data connections in spreadsheets. Instead of using an embedded link to connect directly to an external data source, the spreadsheet gets the latest connection definition from a data connection library and uses that definition to connect to the data source.

Data connection libraries contain .odc files and metadata about the connections. Data connection libraries enable spreadsheets to locate external data sources and maintain connections to data sources that have been renamed or moved to different servers. If an external data source is moved to a new server, the .odc file in the data connection library can be updated by using the location of the new server, and the connection from the spreadsheet is automatically updated.

You can restrict save access to data connection libraries and allow only trusted authors to save connection files. Restricted data connection libraries enable you to ensure that all connection files in a data connection library are authorized. By configuring Excel Calculation Services to use only data connection library connections, instead of direct connections to external data sources, you can ensure that spreadsheets connect only to authorized databases. By default, data connection libraries are created as part of the Report Center template. However, data connection libraries can be created anywhere in Office SharePoint Server 2007 and accessed from a centrally managed Office SharePoint Server 2007 portal site.

Plan key performance indicators

In this article:

•      About KPIs

•      Plan data sources for KPIs

•      Plan KPIs in reports

•      Plan KPIs in dashboards

•      Plan KPIs in My Site

•      Worksheets

Key performance indicators (KPIs) are simple graphical scorecards that can be used to evaluate business data against business goals.

As part of planning your initial deployment of Microsoft Office SharePoint Server 2007, you should understand the data sources used in KPIs, how to configure those data sources and evaluate the status of indicators, and how to display KPIs in sites used by your organization. You can use these plans during initial deployment.

About KPIs

KPIs are a central way of presenting business intelligence for an organization. Also known as status indicators or scorecards, KPIs evaluate business data against business goals and display current status by using easy-to-understand graphical indicators.

For example, a KPI can use traffic light icons to indicate that customer satisfaction is exceeding, meeting, or failing to meet goals. If customer satisfaction exceeds a preset goal, calculated by counting the percentage of positive satisfaction ratings across your organization, the customer satisfaction KPI is displayed with a green traffic light icon. If customer satisfaction is failing to meet minimum goals, the customer satisfaction KPI is displayed with a red traffic light icon. Otherwise, it is displayed with a yellow traffic light icon.

KPIs increase the speed and efficiency of evaluating progress against key business goals. Without KPIs, employees and business managers would have to painstakingly extract performance data and evaluate that data against goals, and then spend the time to present that data in a separate report for business decision makers. It is difficult to get timely status without a way to quickly and automatically evaluate live data. With KPIs, users who want to find out current performance can look quickly at a report in their business site, or even see relevant indicators in their personal sites.

KPIs connect to business data from various sources, and then use Web Parts that display that information in a list of KPIs or in a detailed view for a single KPI. Those Web Parts can be added to reports in the Report Center site, or displayed in other lists and sites.

Each KPI gets a single value from a data source, either from a single property or by calculating averages across the selected data, and then compares that value against a preselected value. Because values are calculated across a range of data rather than displaying data in list form, KPIs tend to be more useful when measuring performance across groups or projects. However, by calculating a range of data for a specific person, such as a list of sales for a single employee, a KPI can evaluate individual performance.

To use KPIs, you must first create a KPI list. KPI lists are created from a template that enables you to add KPIs based on any of the data sources described in the following table.

Data source

Description

SharePoint lists

The data comes from a SharePoint list that might include business data from the Business Data Catalog or Microsoft SQL Server 2005.

Microsoft Office Excel 2007 workbooks

The data comes from an Excel workbook.

SQL Server 2005 Analysis Services

The data comes from database stores known as cubes, for connections in a data connection library.

Manually entered information

The data comes from a static list, rather than based on underlying data sources. This is used less frequently, for test purposes prior to deployment or on occasions when regular data sources are unavailable but you still want to provide performance indicators.

After creating a KPI list, you create a Web Part that is bound to that KPI list. The KPI data is displayed in one of the following Web Parts:

•      KPI List Web Part

•      KPI Details Web Part

The KPI List Web Part shows a list of KPIs that correspond to the bound KPI list. The KPI Details Web Part shows detailed properties for a single KPI.

After you create a KPI Web Part, you can deploy that Web Part in several ways:

•      In a KPI list page report in the Report Center site or a secondary Report Center site, or in a reports library on another site.

•      In a multi-report summary page, or dashboard.

•      In a personalization site.

The KPI list page is a type of report built around a KPI List Web Part, and related summary, and possibly other Web Parts depending on the purpose of the report. When you create a KPI list page report, a KPI List Web Part is included by default. Each KPI in the list must still be added. You can also highlight a single KPI in a report by using a KPI Details Web Part.

KPIs are often used as part of a multi-report summary page, or dashboard. Dashboards use filter Web Parts to filter the data displayed in Web Parts based on certain values. Filter KPIs can be applied dynamically, which enables a business decision maker to quickly compare performance over different periods of time. Dashboards can also filter by other properties.

KPIs in dashboards are more than a single view into data. KPIs are calculated across broad categories, such as total or average sales for employees in an organization. When you plan for KPIs and the lists and Web Parts used to display them, ensure that you know how each KPI will be evaluated during initial deployment and that you identify the data source and calculation method for each KPI.

Plan data sources for KPIs

Each KPI in a KPI list is based on a data source. When you plan for KPIs in your sites, you also plan for data sources.

If a KPI is based on a SharePoint list, you must plan for the list, including its properties. Often, KPI lists are based on business data lists that use columns that are linked to business data applications. The values for those columns are updated as the underlying data is updated. You must plan to register these applications in the Business Data Catalog and import the properties that will be used for KPIs.

SharePoint lists used by KPIs must also be created before you can create the corresponding KPIs. Include every list necessary for KPI deployment in your planning for each site in each site collection.

If a KPI is based on an Office Excel 2007 workbook, ensure that the correct workbooks exist to display meaningful information. Sometimes workbooks are poorly organized or missing information that could be used by KPIs, and this is an opportunity to improve them. Those improvements will help when viewing that same data in an Excel Web Access Web Part, or working directly within the Office Excel 2007 application window.

For data in a SQL Server 2005 Analysis Services cube, plan to include that data in a data connection library.

For SharePoint lists, Excel workbooks, and SQL Server 2005 Analysis Services cubes used as KPI sources, you should consider where the lists, workbooks, and data connection libraries reside. It is usually a good idea to store this content in the site where it is being used. If you are putting a KPI on the home page of the portal site, it makes sense to create a KPI list on the home page. If you are putting a KPI in a report in the Report Center site, it is a good idea to put the lists, workbooks, and data connection libraries for the KPIs in the KPI list, and the KPI list itself in the reports library. If you are putting a KPI in a personalization site, it helps to put the related data sources there. The following figure shows a KPI in relation to other data sources.

It is possible to use data sources stored in document libraries and data connection libraries of other sites, which encourages collaboration and the reuse of valuable KPI lists. However, during initial deployment, it is good to keep your information organized simply and logically. This also simplifies security planning, because you can assume that a site and its content are stored in the same place and not scattered throughout the site collection.

Manually entered values are typically used for testing or temporary purposes, so you will probably only use them in planning and initial deployment to test KPI functionality before you begin a full-scale deployment.

Regardless of the data source for each KPI, you must decide on an appropriate set of values to use when indicating performance. Think about how you will calculate a comparative value from the data source. Which columns of data will you use? Will you calculate a value from a total, an average, a maximum, a minimum, or by some other means?

By planning ahead, you can avoid delays when you realize that an Excel workbook, for example, does not contain the actual set of data that you want to display performance for in the KPI. Plan ahead, select different data sources if you realize the sources you initially select will not provide the information you need for useful KPIs, and then record the plan so that you can finish deployment as quickly and effectively as possible.

Worksheet action

Use the Business data worksheet (http://go.microsoft.com/fwlink/?LinkID=73271&clcid=0x409) to record your KPI planning decisions.

Plan KPIs in reports

KPIs are common features of reports in the Report Center site and other sites that contain report libraries. One of the three main types of reports is a KPI list page report. This report includes a KPI List Web Part to which you can add KPIs for a particular business process, along with a summary of the related processes and any related content and Web Parts.

When planning KPI list pages, focus on the key business processes for each site collection, and combine as many KPIs on each list as you can for related processes. Continue until you have KPIs planned for each business process related to the central purpose of the site collection. This produces a manageable number of KPI list pages, for which you can plan KPI lists and KPIs, in addition to the SharePoint lists, Excel workbooks, and SQL Server 2005 Analysis Services cubes used by each KPI.

You will also want to decide which KPI list pages are important enough to include in the home page of the Report Center site and which should be linked from the page.

You will also want to consider which KPIs work together in dashboards. For large site collections that serve a large number of business applications and business processes, you will want to consider whether to plan more than one Report Center page. For more information about reports, see Plan reports.

Plan KPIs in dashboards

Dashboards, also known as multi-report summary pages, allow you to filter Web Parts at the page level so that every Web Part shows only filtered results. This can be useful for creating pages for monthly or weekly results, results for a team, or results filtered by several other criteria.

KPIs are often a key part of dashboards. KPIs cannot be connected to every kind of filter, but they can be connected to many of them. When deciding whether to include a KPI in a dashboard, consider how closely it relates to the other parts on the page. For more information about dashboards, see Plan dashboards and filters.

Worksheet action

Use the Site creation worksheet (http://go.microsoft.com/fwlink/?LinkId=73138&clcid=0x409) to record the KPIs, KPI lists, and data sources used for dashboard pages and other key sites that use KPIs.

Plan KPIs in My Site

KPIs tend to be more useful in reports and dashboards than in the personalization sites, personal sites, and the public profile page that make up each My Site. However, you might still want to add KPI Web Parts to these sites.

For personalization sites, which are built by using a current user filter Web Part that can be connected to Web Parts on the page, KPIs are not connected but show information across the group of people that uses the personalization site to supplement the Web Parts that are connected and filtered. On a personalization site for a call center team, a KPI List Web Part that shows customer satisfaction, average call time, and number of resolved issues for the entire team supplements an Excel Web Access Web Part personalized to display data for the specific customer service representative who is viewing the page.

You cannot filter a KPI Web Part directly by using the current user filter on a personalization site. The reason for this is that the data in a KPI is often not meaningful when it is calculated across a filtered subset of its original data. A Web Part that tracks the number of sales for the group and the number of sales for one person will produce widely different values, and the KPI can only evaluate against one of the sets of values. Therefore, filtering the KPI that way is not possible.

You can target KPIs so that they appear only in personalization sites when the current viewer is a member of the correct audience. This allows you to target the whole list of KPIs or each individual KPI in the list depending on the scope of the KPI, just as you target the items in any list. If the KPI is of interest only to some users, such as those in the same work group, you can target it to an audience defined to include only the users in the work group. Using the example of a sales team, you might only show the results in the New York sales office to associates in the New York office.

You can use the KPI List Web Part to display several status indicators within one Web Part, such as sales records across the last few quarters. You can also use a KPI that shows sales volume, total value of sales, and improvement compared to the previous quarter in one Web Part.

You might decide during planning to modify the personal site template to include one or more KPI Web Parts, perhaps connected to prepopulated lists. This might be worthwhile for KPIs that you want to display more prominently, even though users might remove the KPI from their personal sites later on.

KPIs are less useful on public profile pages, which show information about a person rather than business processes. Planning for initial deployment is probably not a good time to consider adding KPIs to the public profile.

Consider the KPIs for each personalization site to ensure that they reflect the purpose of the site and the overall site collection. If the site collection is a team site for a sales team, sales data KPIs in a personalization site are appropriate. If it is a site collection intended for collaboration across a larger organization, the KPI will have to be targeted if it is included at all. If it is a site for human resources information, which is not used by any group in the organization to meet its goals but instead simply provides policies and business applications, it is inappropriate to use a KPI.

Worksheet action

Use the Site creation worksheet (http://go.microsoft.com/fwlink/?LinkId=73138&clcid=0x409) to record the KPIs, KPI lists, and data sources used in personalization sites and other personalized sites that use KPIs.

Worksheets

Use the following worksheets to plan KPIs:

•      Business data worksheet (http://go.microsoft.com/fwlink/?LinkID=73271&clcid=0x409)

•      Site creation worksheet (http://go.microsoft.com/fwlink/?LinkId=73138&clcid=0x409)

Plan reports

In this article:

•      About reports

•      Plan Web Parts for reports

•      Plan reports for the Report Center site

•      Plan the reports library

•      Plan other features of the Report Center site

•      Worksheets

Reports are Web-based views of business data that is from various sources. In Microsoft Office SharePoint Server 2007, reports are displayed in pages by using business data and key performance indicator (KPI) Web Parts. These reports can be used alone or in multi-report dashboards to analyze and act on business data and business intelligence.

As part of planning for your initial deployment of Office SharePoint Server 2007, you should understand which Web Parts to use in reports and how to configure those Web Parts to use business data. You should also understand how to combine reports in report pages such as the Report Center site, how to configure management of report libraries, and what other information and features to enable for the Report Center site and other reports-enabled pages.

About reports

You create reports by using business data Web Parts and KPI Web Parts to summarize data and Excel Web Access Web Parts for business intelligence analytics. Reports are displayed in the Web browser interface.

Each report is built around one or more Web Parts. The sources of data in the Web Parts in a report can be Microsoft SQL Server 2005, from either SQL Server 2005 Analysis Services or SQL Server 2005 Reporting Services, or line-of-business applications such as SAP and Siebel. Data in report Web Parts is often available in business data lists, which might be the direct source of the data.

Reports can appear in the following SharePoint sites in your site collections:

•      Report Center site   Created when the site collection is created, the Report Center site contains a reports library, dashboards, and supporting content, and a home page that links to reports and supporting content.

•      Other Report Center sites   Additional Report Center sites can be created for site collections that contain a large number of reports associated with distinct business processes.

•      Report libraries in other sites   Anyone who can create document libraries on a site collection can choose to create report libraries. These libraries create reports that use one of three content types: a report, a Microsoft Office Excel 2007 report, or a dashboard page.

Reports also appear as items in lists and search results.

The business data Web Parts used in reports can appear in additional sites, including personalization sites, workspaces, and team collaboration sites, but those sites are not reports.

Plan Web Parts for reports

Reports are pages built around one or more business data Web Parts, including:

•      Business Data List Web Part

•      KPI List Web Part and KPI Details Web Part

•      Excel Web Access Web Part

•      Reporting Services Report Web Part

When you create a report, you must provide the location of a business data Web Part or KPI Web Part.

The Web Part gallery suggests these same Web Parts, along with the Content Editor Web Part, but you can add any business data Web Part including other Web Parts with different views of business data lists, the Business Data Actions Web Part, or other specialized Web Parts. For more information about these Web Parts, see Plan business data Web Parts.

Reports also include the following Web Parts:

•      Summary Web Part   This is a Content Editor Web Part in the left zone intended to convey the purpose of the report and the business data it contains.

•      Contact Details Web Part   This contains a picture and key properties for a person associated with the report page, usually the page owner.

Dashboard pages contain additional Web Parts. For more details about dashboard pages, see Plan dashboards and filters.

Each report is based around a set of business data in a business data Web Part. Each report is supplemented by a summary that explains the purpose of the report and provides details about the owner of the report. The Web Parts to use for each report should be narrowly focused on a single task or related set of tasks. Many reports contain only a single Business Data List Web Part or KPI Web Part.

Use the following steps to plan Web Parts for reports:

1.   Identify a business process.

2.   Plan to include a report for that business process.

3.   Identify the Web Parts that will convey the information users need to act within that business process.

For example, a common business process in a sales organization is to identify which teams are meeting their sales goals. You decide to create a team sales KPI report that highlights the information. You decide to use a KPI List Web Part to list the relevant teams, and the KPI for each team will be evaluated by calculating the total sales for everyone on each team. You implement a business data list that connects to your sales database, and you include columns that will list the team name, employee names, and sales for each team. You will also need an explanation of the team goals that you can put in the Summary Web Part. In your planning, you record the report, Web Part, list, and list columns, and update the corresponding planning worksheets. In the case of reports based on Business Data List Web Parts, you might have several properties to record, each associated with a different business data type in the Business Data Catalog.

Worksheet action

Use the Business data worksheet (http://go.microsoft.com/fwlink/?LinkID=73271&clcid=0x409) to record business data and business intelligence Web Parts. Record connected Web Parts, data sources, and SharePoint lists used by the Web Part in the same table.

Use the Site creation worksheet (http://go.microsoft.com/fwlink/?LinkId=73138&clcid=0x409) to record the key dashboard sites identified during site planning, and to record the Web Parts used by those sites. Also record the features enabled for the Report Center site, such as document libraries, documents, and images for each site.

Plan reports for the Report Center site

The Report Center site is a page that is created automatically for site collections in Office SharePoint Server 2007. It is a single location that has links to all of the reports and dashboards in the site collection. Users view the Report Center site by clicking Reports in the Quick Launch.

The default layout of the Report Center site includes the following Web Parts:

•      In the left zone:

•      Using the Report Center site   This is a Content Editor Web Part that contains introductory information about the Report Center site. The text here can be modified by site administrators depending on the content and business needs of the site collection and the Report Center site.

•      Announcements   This is a List View Web Part that is used for posting announcements relevant to the Report Center site. By default, it has a welcome announcement. Report Center site contributors can add announcements.

•      Highlights   This is a summary link Web Part tool that can be used to highlight reports, KPIs, and dashboards. By default, it includes a link to a quick reference guide. From the design mode, users who have the appropriate permissions can add links or group headings or configure the style and layout of this Web Part.

•      In the right zone:

•      Contact Details Web Part   Contributors can add one or more contacts here that are relevant to the Report Center site.

•      Upcoming events   This is a List View Web Part used for adding events relevant to the business processes for the Report Center site. Contributors can add events.

The other zones are empty to start, but are often used to present important KPI or business data lists without having to open a separate report.

The Quick Launch in the Report Center site contains links to reports, dashboards, and resources. The Reports link opens up the reports library, which contains a list of all reports for the Report Center site.

There are three kinds of report pages:

•      Report   This page highlights a business data Web Part, such as a Business Data List Web Part or a KPI List Web Part.

•      Excel report   This page highlights data from a particular Excel worksheet.

•      Dashboard page   This page highlights more than one business data Web Part, commonly filtered at the page level by particular properties. By default, each dashboard page contains a KPI List Web Part and an Excel Web Access Web Part.

Each type of report page includes a summary page and contact details for the owner of the report.

You can create additional Report Center sites focused around particular sets of business data and business intelligence by selecting the Report Center Site template when creating a site. The number of Report Center sites you have, and which reports are included in each Report Center site, depends on the purpose of each site collection. For most deployments, starting off with one Report Center site is sufficient. If planning the Report Center site becomes complex, you can consider additional folders for the reports library, or even additional report libraries to organize a large number of reports.

The number of potential reports for a Report Center can be fairly large even for a simple business process that uses a single business application. Consider the example of a sales reporting application. You might want to create reports that track employee performance, customer satisfaction, sales for a particular product, sales by location, and total quarterly revenues, among others. Some of the reports will be composed of KPI List Web Parts that show performance in scorecard format, some will be composed of KPI Details Web Parts that focus on a single item in a KPI list, and some might be business data lists that track several properties.

Many business processes use more than one application. You can use Excel Web Access Web Parts to perform analytics or update information in spreadsheets. You can use SQL Server 2005 Analysis Services to view information in a related data warehouse.

There are several actions you can perform to simplify Report Center planning:

•      Focus the purpose of each site collection and related Report Center site as much as possible.

•      Select only the most important cross-group KPIs and business data lists to implement during initial deployment, and defer the rest for ongoing operations.

•      Present related Web Parts in dashboard pages, and use filters and Web Part targeting to improve relevancy and flexibility. For more information about dashboard pages and filters, see Plan dashboards and filters. For more information about targeting Web Parts, see Plan for personalized Web Parts.

•      Plan business data lists and Web Parts for reusability, so that you can use the same underlying lists for reports, dashboards, personalization sites, and Web Part galleries for other sites.

•      Record the lists that you will need to implement the high-priority reports, include that information in business data list planning, and record the relevant business data types and properties of business applications in planning for business data profiles.

•      Plan to observe usage patterns so that you can effectively update the Report Center site during ongoing operations.

Plan the reports library

The reports library contains links to all reports for the Report Center site. It includes a version history for each report, and archives previous versions so you can view them. This enables you to create new versions of reports for special events or milestones, and later revert back to a previous report.

You can also change the view of the reports library list. The views available by default are:

•      Current reports   This view shows the current versions of all reports.

•      All reports and dashboards   This view shows all versions of reports, with the most recent versions listed first.

•      Dashboards   This view shows only dashboard pages.

You can edit these views to add columns or filter content, or create new views.

Reports based on Excel Web Access Web Parts have a report profile page that includes additional information about the Excel spreadsheet.

When you plan for the reports library, consider who is likely to manage reports in the site collection, and whether reports need to be organized into folders by business application, work team, or business process. These decisions will be influenced by your information architecture planning and the purpose of each site collection as identified during site planning.

Plan other features of the Report Center site

If you click Manage Content and Structure on the Site Actions menu of the Report Center site, you will see a list that contains links to every report and the following information:

•      Announcements

•      Data connections

•      Documents

•      Handbook

•      Images

•      Pages

•      Reference library

•      Reports library

•      Report calendar

•      Sample KPIs

•      Workflow tasks

Each of these items is used to store content that can be used in the reports in the Report Center site. When you plan for Report Center sites in your site collection, make note of this content so you can include it for reports you make available during the initial deployment.

Examples of useful content for initial deployment includes documents that describe business processes related to key reports, data connections that are used by SQL Server 2005 Analysis Services and SQL Server 2005 Reporting Services reports, and images for report owners. Most supplementary content will be added during ongoing operations after the initial deployment.

You can also add additional report libraries to the Report Center site, or to other sites. You might want to plan for multiple report libraries if a Report Center is particularly complex. For example, a departmental portal site might include reports for several different applications or work teams. Each of these can be deployed by using a separate reports library, and you can use the targeting feature of Web Parts in the Report Center site so that users can view only the reports relevant to their job. Permissions can be set separately for each library if different users are managing different sets of reports.

Worksheets

Use the following worksheets to plan reports:

•      Business data worksheet (http://go.microsoft.com/fwlink/?LinkID=73271&clcid=0x409)

•      Site creation worksheet (http://go.microsoft.com/fwlink/?LinkId=73138&clcid=0x409)

Plan dashboards and filters

In this article:

•      About dashboards and filters

•      Plan Web Parts for dashboards

•      Plan filters

•      Worksheets

Dashboards display reports and key performance indicators (KPIs) about the business data and business processes in your organization. The view of these reports can be filtered automatically or filtered by properties selected by users, enabling comparative data analysis across an organization.

As part of planning for your initial deployment of Microsoft Office SharePoint Server 2007, you should understand which Web Parts are common to dashboards, how filters are used on dashboards and other SharePoint sites, how to connect filters and business data Web Parts, and how to display those filters for people who use dashboards and other filter-enabled SharePoint sites.

About dashboards and filters

Dashboards, also known as multi-report summary pages, contain one or more Web Parts, such as business data Web Parts, Excel Web Access Web Parts, or KPIs that can be filtered to provide a unified but flexible view of data and content from several sources. The data displayed on dashboards can be filtered at the page level or by Web Part by using the functionality of Microsoft SQL Server 2005 Reporting Services. For example, you can create a Customer Report dashboard that displays all KPIs and business data Web Parts for your organization's key business processes that relate to a particular customer.

Dashboards are one of the three content types that can be added to a reports library. The Report Center site that is created automatically for portal sites and other site collections contains a reports library, but users can add report libraries to other sites.

Dashboards are composed of a collection of business data Web Parts and a collection of filter Web Parts that connect Web Parts and change the data displayed based on data shared among the connected Web Parts. You can also create sites that filter data such as dashboards by adding connected filter and business data Web Parts to other site templates.

Some filter Web Parts filter data automatically. Some filter Web Parts enable users who view a dashboard to enter values or to select values from a list and then apply those values by clicking the Apply Filter button on the page. The Apply Filter button is implemented as another Web Part that is invisible on the dashboard until one or more filters that have user-specified values are added to the page.

The Apply Filter button and user-specified filters appear in a special filter zone in the dashboard template.

By default, a dashboard contains the layout and Web Parts listed and described in the following table.

Zone

Web Part

Description

Top left

Summary Web Part

This is a Content Editor Web Part that can be modified to add explanatory text for the information provided on the dashboard.

Top right

Contact Details Web Part

This contains contact information for the owner of the dashboard.

Filter

Apply Filter Web Part

Other filters added to the dashboard appear in this zone.

Bottom left

Excel Web Access Web Part

This Web Part can be configured to display data from Microsoft Office Excel 2007 worksheets. Depending on the purpose of the dashboard, administrators can remove this Web Part or supplement it with similar additional Web Parts.

Bottom middle

No default Web Part

This zone is empty, but it is a good place to add additional business data Web Parts, such as KPI List Web Parts and Business Data List Web Parts.

Bottom right

Related Information Web Part

This Web Part is used to add links to related reports, documents, sites, and other content.

The usefulness of dashboards depends on the underlying Web Parts and filters and the connections you make between those components. Therefore, carefully planning which Web Parts and filters you use and how they interact can make a big difference in how effectively people can use business data in your organization.

Plan Web Parts for dashboards

Dashboards are created to present a view of important business data used in common business processes. The first factor to consider when creating a dashboard or a site based on the same types of Web Parts is what the purpose of the site is. This will ensure that the common business processes associated with that purpose can be displayed in the dashboard.

When you plan site collections, you should consider the purpose of each site, which is usually based around groups of users in an organization and the different projects they work on. Some large site collections, such as centralized corporate portal sites, have a fairly broad set of purposes and organize diverse groups of users that work on a wide variety of business processes. Often you will have smaller site collections for more focused groups, projects, and business processes.

Whatever the structure of your site collections, you will want to create dashboards that organize the information in each discrete set of business processes. Some groups of users might have a single set of processes that they use regularly, while others might work across different processes. The number of dashboards and the content on each of them should reflect the work done by users and groups in your organization.

For each site, you should group business processes, identify Web Parts that can be used to display the data necessary to understand the status of key projects, and provide a single point of entry into more detailed information about those projects. These Web Parts contain important business data that can be filtered by other Web Parts.

The business data Web Parts that are commonly added to dashboards include:

•      Additional Excel Web Access Web Parts

•      Business Data List Web Parts

•      KPI List Web Parts and KPI Details Web Parts

•      Reporting Services Report Web Part

When you plan each of the business data Web Parts in a dashboard, consider the implications of the underlying connections to data sources and filter Web Parts. For data connections, you will want to add document libraries for Excel workbooks, register line-of-business applications in the Business Data Catalog, and import the proper set of properties into business data profiles. You will also want to create SharePoint lists for KPIs and add connections to the data connection library for SQL Server 2005 Analysis Services and SQL Server 2005 Reporting Services.

Plan Excel Web Access Web Parts for dashboards

Excel Web Access Web Parts provide information from Excel workbooks directly within the dashboard page. The default view is a subset of cells selected by the site owner when adding the Web Part. Any automatic filters are applied before anyone views the page. Filters that have user-specified values are displayed as list menus or text boxes. These filters enable anyone to select values and filter the view on those values. Users who have the appropriate permissions on a spreadsheet can open it for editing by clicking the appropriate link in the Web Part. For example, you might want to use data from an Excel workbook to show sales data for all employees in a division.

Plan business data Web Parts for dashboards

Business Data List Web Parts contain data from lists that are generated from applications registered in the Business Data Catalog. The most common type of this Web Part is a simple list, but you can also add Web Parts that detail individual items in a data source, or display lists of data related to associated properties in the data source. For example, you can add a Web Part that displays a list of customers, a detailed set of information about one customer, or a list of customers in a particular region. You can also add a Business Data Action Web Part that performs a previously defined action related to data that is contained in one of your business data applications.

All of these business data Web Parts can be connected to each other so that they can share data. The amount of data that can be shared and how it is shared depends on the Web Part, as described in the following table.

Web Part

Maximum data rows shared with other Web Parts

Web Parts that can send data to this Web Part

Type of data this Web Part can receive

Business Data List Web Part

Up to two rows of data, each connected to a single other business data Web Part

Other business data Web Parts, Current User Filter Web Part, Property Profile Filter Web Part

Filter, parameter, filter values, or query values

Business Data Related List Web Part

Up to two rows of data, each connected to a single other business data Web Part

Other business data Web Parts, Current User Filter Web Part, Property Profile Filter Web Part

Filter, parameter, filter values, query values, or related items

Business Data Item Web Part

One row of data to one other business data Web Part

Other business data Web Parts, Current User Filter Web Part, Property Profile Filter Web Part

Filter, parameter, or new item

Business Data Action Web Part

Cannot send data to other Web Parts

Other business data Web Parts, Current User Filter Web Part, Property Profile Filter Web Part

Any

These connections allow you to use multiple Web Parts to create or supplement data in another Web Part dynamically. You can:

•      Use data in Business Data List Web Parts to create Business Data Item Web Parts or Business Data Related List Web Parts.

•      Send a row in a business data Web Part to a Business Data Action Web Part as a new action.

•      Filter data for a Web Part based on values passed from other business data Web Parts or the Current User Filter Web Part or Property Profile Filter Web Part.

For more information about Current User Filter Web Parts, Property Profile Filter Web Parts, and the other filter Web Parts that can be used to filter all Web Parts in a single dashboard page, see Plan filters later in this article.

Plan KPI Web Parts for dashboards

KPI Web Parts show the status of business processes by comparing a value, which is calculated from an underlying data source that has a value representing a goal for that process, and indicating the status by using a simple graphic. For example, a KPI can use traffic light icons to indicate that customer satisfaction is exceeding, meeting, or failing to meet goals. If customer satisfaction exceeds a preset goal, calculated by counting the percentage of positive satisfaction ratings across your organization, the customer satisfaction KPI is displayed with a green traffic light icon. If customer satisfaction is failing to meet minimum goals, the customer satisfaction KPI is displayed with a red traffic light icon. Otherwise, it is displayed with a yellow traffic light icon.

KPIs can be based on data from SharePoint lists, Excel workbooks, or SQL Server 2005 Analysis Services. Reporting Services Report Web Parts present data directly from SQL Server 2005 Reporting Services.

Plan filters

Filters are Web Parts that connect to other filter Web Parts and business data Web Parts to enable dynamic views of business data in dashboards and other sites that use filters and business data Web Parts. There are several supported data types for filters, each associated with a different filter Web Part.

Some of the filters are applied to Web Parts on a page automatically without any input from users who view the page. These filters are added by dashboard owners to limit the scope of data on any dashboard site. Depending on the properties of each filter Web Part, most, but not all, of these filters are applied to all Web Parts on a page.

The other filters are applied to all data in all Web Parts on the page, according to values selected by users of the page. Three of those filter Web Parts use user-specified values for data, while the rest enable users to select values from a list that is created from values selected from various data sources by the site owner.

Not every Web Part can be connected to a filter. Each filter shows which Web Parts on the page it can connect to when you select the Web Part menu in design mode, point to Connections, and then point to Send Filter Values To. Every Web Part that can accept values from filters also shows that information in its Connections menu.

The supported data types and Web Parts are listed in the following table.

Data type

Selection format

Web Part

Text

User

Text Filter Web Part

Number

User

Number Filter Web Part

SharePoint list

List

SharePoint List Filter Web Part

Business Data Catalog

List

Business Data Catalog Filter Web Part

SQL Server 2005 Analysis Services

List

Analysis Services Filter Web Part

Manually entered list

List

Any filter Web Part that uses a manually entered list in Web Part properties

Values based on targeted Web Parts

List

Any targeted Web Part

Current user

Automatic

Current User Filter Web Part

Query string parameter

Automatic

Query String (URL) Filter Web Part

Fixed value

Automatic

Choice Filter Web Part

Page field value

Automatic

Page Field Filter Web Part

Plan automatic filter Web Parts

Several filters are applied automatically when the dashboard is displayed in a Web browser. These filters are configured by the owner of the site to limit the scope of displayed data. These filters are visible only in design mode. Because all other filters are applied after these filters by the option of users, these filters should be planned and implemented first.

The filter Web Parts that apply filters automatically are:

•      Current User Filter Web Part

•      Query String (URL) Filter Web Part

•      Authored List Filter Web Part

•      Page Field Filter Web Part

•      Organization Filter (Direct Reports) Web Part

The Current User Filter Web Part and the related Property Profile Filter Web Part are included in the personalization site template and can also be added to dashboard sites. They filter respectively by the account name and preferred name properties of the user profile of the current user. They can pass these properties to other filters as default values and to business data Web Parts. For certain personalization Web Parts, this results in a personalized view that has information relevant to the user currently viewing the site.

The Property Profile Filter Web Part is used only on personalization pages. It is not available in Web Part galleries for other pages. For more information about personalization Web Parts, see Plan for personalized Web Parts.

The Authored List Filter Web Part enables you to filter the page based on a list of properties that is authored by the site owner.

The Query String (URL) Filter Web Part automatically filters one or more Web Parts according to a query string provided by the dashboard owner. A default URL can be provided for the filter if the query string does not produce a valid URL.

The Page Field Filter Web Part enables you to filter content on the page based on the columns in the page list for the dashboard or any other Web Part page. You can filter one or more connected Web Parts based on the values in the selected column. You can also add columns to the list to expand your ability to filter Web Parts on the page.

Plan filters that use user-specified values

The filters that use user-specified values are based on the following filter Web Parts:

•      Text Filter Web Part

•      Number Filter Web Part

Each of these filters enables individual users to enter values that are used to filter every Web Part on the dashboard. Filtering begins when the user clicks the Apply Filter button on the dashboard page. The default values for the Text Filter Web Part can be taken from the Current User Filter Web Part or the Property Profile Filter Web Part.

Planning for these filters is straightforward. If you want users to have the ability to quickly filter by values that are not in a list, you can enable these filters. It is usually a good idea to enable these filters first, so that some filtering is available with minimal effort by the site owner, with filters based on lists from data sources implemented later. However, after you have created more complex filters that are more relevant for the purpose of the site, these might no longer be necessary. Plan for more complex filters, but you can enable these filters early in deployment without any additional planning.

Plan filters that use values selected from a list

Some of the filters that use user-specified values provide those values in a list created from other data sources. The filters are:

•      Manually entered list (used by any filter Web Part)

•      SharePoint List Filter Web Part

•      Business Data Catalog Filter Web Part

•      Analysis Services Filter Web Part

If you want to enable filtering by a simple list of values and do not want to create a SharePoint list or find other data sources that have those values, you can use a manually created list created from the Advanced Filter Properties page of filter Web Parts. Creating a list such as this is quick and easy, and it is a good early step along with enabling simple date and text filters to provide dashboard functionality until more complex filters are deployed.

More often, and particularly later in your deployment, you will want to use properties from more sophisticated data sources. It is worth taking the time to plan these kinds of filters, because they require that you also plan for the underlying data sources. You will want to create SharePoint lists, register business applications in the Business Data Catalog, and add connections to SQL Server 2005 Analysis Services cubes in data connection libraries before you create filters based on these sources.

The Business Data Catalog Filter Web Part filters other Web Parts on a page based on values of properties found in SQL Server 2005 Reporting Services or in applications that are registered in the Business Data Catalog. It is often used in combination with business data Web Parts to filter the view, and any recognized property can be used by this filter.

Analysis Services Filter Web Parts are selected from a hierarchical tree view. They enable you to filter Web Parts on a page based on values from SQL Server 2005 Analysis Services cubes and status indicators. This is often used to filter KPIs that are based on SQL Server 2005 Analysis Services data.

This view also enables you to show data from complex data stores so that anyone who uses a dashboard can quickly select any node in the tree and filter on that node. This provides analytics on complex data that are difficult to build any other way. This is a good option for large data warehouses that have read-only or infrequently updated data, but can be used for all kinds of data.

Access to some data sources, such as applications in the Business Data Catalog and SQL Server 2005 Analysis Services cubes, might require configuration of single sign-on to properly connect to data. Incorporate single sign-on planning into your plans for these data sources to ensure that filters and related Web Parts work properly. For more information, see Plan for single sign-on.

Worksheet action

Use the Business data worksheet (http://go.microsoft.com/fwlink/?LinkID=73271&clcid=0x409) to record business data and business intelligence Web Parts used by dashboards. Record connected filter Web Parts and the properties used by each filter, data sources, and SharePoint lists used by the Web Part in the same table.

Use the Site creation worksheet (http://go.microsoft.com/fwlink/?LinkId=73138&clcid=0x409) to record the key dashboard sites identified during site planning, and to record the Web Parts used by those sites.

Worksheets

Use the following worksheets to plan dashboards and filters:

•      Business data worksheet (http://go.microsoft.com/fwlink/?LinkID=73271&clcid=0x409)

•      Site creation worksheet (http://go.microsoft.com/fwlink/?LinkId=73138&clcid=0x409)

Plan Excel Services security

In this article:

•      About Excel Services security

•      Plan user authentication

•      Plan communication among servers

•      Plan external data authentication

•      Worksheets

About Excel Services security

In addition to the security requirements for deploying Microsoft Office SharePoint Server 2007, you need to review security considerations for a deployment that includes Excel Services in Microsoft Office SharePoint Server 2007. Windows SharePoint Services 3.0 provides the platform on which Office SharePoint Server 2007 is built.

Excel Services in Microsoft Office SharePoint Server 2007 functionality, coupled with Office SharePoint Server 2007, is the primary way to control, secure, and manage access to Excel workbooks in the enterprise. Excel Services is an enterprise-class application server that is designed for performance, scalability, and security. An Excel Services deployment provides thin rendering of — and interactivity with — workbooks, and it enables you to easily reuse workbook components, such as charts and PivotTable reports, that can be rendered in business intelligence dashboards.

Excel Services enables you to leverage server-side Excel spreadsheet calculations for custom applications, and it provides users with the ability to lock workbooks and to secure private data and intellectual property. This ensures that data within your workbooks is protected while users interacting with workbooks on a server can take full advantage of the data refresh and recalculation functionality provided by Excel Services.

Security is an important component for enabling these data rendering scenarios. You need to consider many factors when planning for an environment that helps to ensure the security of workbooks that are rendered on a server. You need to plan for managing the security of workbooks and managing the security of the server itself. Excel Services provides you with a significant level of granular control for the processing and displaying of Excel workbooks. You can control how workbooks are opened on the server and the specific capabilities that are enabled for each workbook.

This article is an overview of the security settings for Excel Services and related components that you must consider when planning a deployment. In addition, this article provides prescriptive guidance for using Excel Services to help secure and manage access to workbooks on the server.

The security model for Excel Services is based on the concept that to ensure data integrity and quality, an administrator must be able to centrally manage shared resources and user access to corporate intellectual property contained in workbooks. To accomplish this, Excel Services enables you to specify:

•      Trusted file locations   These are SharePoint document libraries, UNC paths, or HTTP Web sites that have to be explicitly trusted before Excel Calculation Services is allowed to access them. Excel Calculation Services opens workbooks that are stored in trusted file locations only.

•      Trusted data providers   These are external databases that Excel Calculation Services is explicitly configured to trust when processing data connections in workbooks. Excel Calculation Services attempts to process a data connection only if the connection is to a trusted data provider.

•      Trusted data connection libraries   These are SharePoint document libraries that contain Office data connection (.odc) files. The .odc files are used to centrally manage connections to external data sources. Instead of allowing embedded connections to external data sources, Excel Calculation Services can be configured to require the use of .odc files for all data connections. The .odc files are stored in data connection libraries, and the data connection libraries have to be explicitly trusted before Excel Calculation Services will allow workbooks to access them.

By default, cross-domain workbook and data connection access is not allowed. To allow workbooks in trusted file locations (and data connections in trusted data connection libraries) to be accessed across domains by web parts, pages, or Web services, run the Stsadm.exe command-line utility, as shown in the following example, where SSP name is the name of your Excel Services Shared Services Provider:

stsadm.exe -o Set-EcsSecurity -Ssp <SSP name> -AllowCrossDomainAccess true|false

The requesting Web pages and the workbooks or data connections must reside in the same farm.

Note:

When you open a workbook in Excel Calculation Services, a temporary file is stored in the %TEMP% folder of the application server that is running Excel Calculation Services.

Plan user authentication

Excel workbooks that are opened by Excel Calculation Services should be stored in the Office SharePoint Server 2007 content database, because Windows SharePoint Services 3.0 maintains an access control list (ACL) for these files. Excel Calculation Services can also open workbooks from UNC paths and HTTP Web sites, but we recommend using the Office SharePoint Server 2007 content database for workbook storage.

Authentication for user access to a SharePoint portal site is performed by Windows SharePoint Services 3.0. By default, Windows SharePoint Services 3.0 uses Integrated Windows authentication.

In addition to the listed authentication methods, Excel Services also supports generic forms-based authentication. However, configuring Windows SharePoint Services 3.0 to use generic forms-based authentication is beyond the scope of this article.

Plan communication among servers

You can determine how front-end Web servers communicate with Excel Calculation Services application servers, and how application servers communicate with back-end data sources, by configuring Excel Services to use either trusted subsystem data access or delegation. Trusted subsystem is the default setting for a Windows server farm, because it does not have the extra configuration requirements of the delegation model. In the trusted subsystem model, front-end Web servers and Excel Calculation Services application servers trust the accounts of the associated Office SharePoint Server 2007 applications by using the Shared Services Provider (SSP).

In a trusted subsystem environment, when opening files from Office SharePoint Server 2007, permission checks on the files can be performed against end-user identities even if Kerberos is not configured. If Excel Calculation Services application servers open workbooks from UNC shares or HTTP Web sites, the user account cannot be impersonated, and the process account must be used.

Note:

To impersonate the user account and implement workbook authorization, you must set up constrained Kerberos delegation between Excel Calculation Services application servers and UNC or HTTP resources.

Constrained Kerberos delegation is the most secure configuration for communication between front-end Web servers and Excel Calculation Services application servers. Constrained Kerberos delegation is also the most secure configuration for accessing back-end data sources from application servers. Constrained Kerberos delegation is the preferred configuration for deploying Excel Services. For external data connections, Integrated Windows authentication will only work if the delegation model is implemented.

Plan external data authentication

Workbooks can contain embedded direct data connections and links to data connection files that are stored in data connection libraries. On refresh, depending on the configuration of Excel Services, the embedded direct data connection can be used to query the data source, or the data connection library link can be used to query the .odc file. The .odc file contains data connection information and must be stored in a data connection library.

To configure Excel Services to process connections to external data sources, select a setting in the External Data section of the Excel Services Add Trusted File Location page of the SharePoint Central Administration Web application.

To configure administrative settings for Excel Services, open the SharePoint Central Administration Web application from Office SharePoint Server 2007 and perform the following procedure.

Configure administrative settings for Excel Services

1.   On the Central Administration home page, click Application Management.

2.   On the Application Management page, in the Office SharePoint Server 2007 Shared Services section, click Create or Configure this Farm's Shared Services.

3.   On the Manage this Farm's Shared Services page, click SharedServices1 (Default). This is the SSP that you will configure.

4.   On the Shared Services home page, in the Excel Services Settings section, click Trusted file locations.

5.   On the Excel Services Trusted File Locations page, click Add Trusted File Location.

6.   In the Address section, type the location and name of the SharePoint document library that you want to add as a trusted file location in Excel Services. If the document library is stored in the Windows SharePoint Services 3.0 content database, make sure Windows SharePoint Services 3.0 is selected as the Location Type.

Delegation is required for most farm deployments that have integrated connections. When Excel Calculation Services retrieves connection information, credentials are designated as Stored (to be retrieved from the SSO database), Integrated, or None. For data connections with integrated credentials, delegation is required for deployments that are scaled out to multiple servers. In a stand-alone deployment, delegation is not required.

Imagine a data connection in a workbook opened in an Excel Calculation Services application server that uses the Stored credentials method. Excel Calculation Services has to retrieve valid credentials from a single sign-on (SSO) authentication database. Then, it uses the credentials to authenticate against a data source, before the data connection can be established.

Excel Services supports three data authentication methods: Integrated Windows authentication, SSO authentication, and None.

Integrated Windows authentication

Integrated Windows authentication usually requires constrained Kerberos delegation, which is the most secure authentication method. We recommend that you enable constrained Kerberos delegation for authentication from front-end Web servers to application servers running Excel Calculation Services, and from Excel Calculation Services to external data sources. For Excel Services scenarios, we recommend using Integrated Windows authentication.

SSO authentication

SSO authentication enables users to access multiple system resources without having to provide authentication credentials more than once. Office SharePoint Server 2007 implements SSO authentication by including a Windows service and a secure credentials database. Using the pluggable SSO functionality supported by Excel Services, you can implement your own SSO provider. Office SharePoint Server 2007 includes a Windows SSO provider that works with Excel Services.

Any SSO provider that you implement with Excel Services should maintain a flag for each SSO entry that specifies whether the SSO entry is using Windows-based credentials or credentials from another environment. The Windows SSO provider in Office SharePoint Server 2007 maintains a flag for this purpose. Excel Services uses the SSO database to retrieve credentials for connection authentication.

SSO authentication in Office SharePoint Server 2007 supports individual mappings and group mappings. SSO maintains a set of credentials for the application identities (App IDs) of resources that are stored in the Office SharePoint Server 2007 SSO database. For individual mappings, a security layer checks user credentials against multiple individual listings for an App ID that is stored in the SSO database. Individual mappings are useful if you need logging information about individual user access to shared resources.

For group mappings, a security layer checks group credentials for multiple domain users against a single set of credentials for a resource identified by an App ID that is stored in the SSO database. Group mappings are easier to maintain than individual mappings, and performance is better.

To enable SSO functionality for Office SharePoint Server 2007, start the Microsoft Single Sign-On service and then configure SSO settings in the SharePoint Central Administration Web application. Use the following procedures to set up and configure an SSO database to authenticate data connections.

Start the Single Sign-On service

1.   From Administrative Tools, click Services.

2.   Double-click Microsoft Single Sign-On Service.

3.   On the Log On tab of the Single Sign-On Service Properties page, click This account, and then type the domain, user name, and password that you have used to install and manage your server.

4.   Click Apply.

5.   On the General tab of the Single Sign-On Service Properties page, change the startup type to Automatic, click Start, and then click OK.

Note:

Start the Single Sign-On service on all front-end Web servers and all application servers in your farm that run Excel Calculation Services.

Manage SSO settings

1.   From Administrative Tools, open the SharePoint Central Administration Web application.

2.   On the Central Administration home page, click Operations.

3.   In the Security Configuration section, click Manage settings for single sign-on.

4.   On the Manage Settings for Single Sign-On page, click Manage server settings.

5.   In the Account Name box for the SSO Administrator account, type the same domain and user name that you used to configure the Single Sign-On service. If the user name that you used to configure the Single Sign-On service is a member of a Windows security group, you can type the name of the Windows security group instead of a user name.

6.   In the Enterprise Application Definition Administrator Account box, type the same domain and user name that you used to configure the Single Sign-On service.

None

When you specify None as the authentication method for your Excel Services deployment, Excel Services tries to use inbound connection strings to connect to the database specified in the string. Depending on the specific database provider, the database might be able to use the connection string to authenticate the user.

Excel Services does not parse connection strings to determine an authentication method. The connection strings are simply passed to the database provider. Connection strings can specify that Integrated Windows authentication is required. Connection strings can also contain a specific user name and password. In either case, when you specify None as the authentication method, Excel Services requires the impersonation of an unattended service account.

If the database provider determines that the connection string specifies Integrated Windows authentication, and if the database authorizes access, the connection is established by using the security context of the unattended account. If the connection string contains a user name and password, and if the database authorizes access, the connection is established by using the security context of the authorized user account.

Unattended service account

The unattended service account is a low-permissions account that Excel Calculation Services can impersonate when establishing a data connection that uses SSO credentials from an environment that is not Windows-based, or None, as the authentication method. If an unattended service account is not configured, data connections will fail if SSO from an environment other than Windows, or None, is used as the authentication method.

Impersonating the unattended account protects Office SharePoint Server 2007 databases, and any other data sources that Excel Services can directly access, from unauthorized connections by client computers that are using Excel Calculation Services to open external data connections. When an unattended service account is impersonated, the credentials associated with an Excel Calculation Services application thread cannot be used to access any other databases. Also, when an unattended service account is impersonated, external data queries are run under the security context of a low-permissions account, instead of running under the security context of an Excel Calculation Services application thread that has greater permissions.

You can configure the unattended service account either as a domain account or as a local computer account. If the unattended service account is configured as a local computer account, ensure that the configuration is identical on every application server running Excel Calculation Services. Restrict the permissions of the unattended service account to enable only logging on to the network. Verify that the unattended service account does not have access to any data sources or Office SharePoint Server 2007 databases. Use the following procedure to enable the unattended service account.

Enable the unattended service account

1.   In the Name and Password boxes in the External Data section of the Excel Services Settings page, type the name and password that you want to use.

2.   Click OK.

Security settings

To configure administrative settings for Excel Services, including security settings, open the SharePoint Central Administration Web application from Administrative Tools in Microsoft Windows Server 2003, and perform the following procedure.

Configure security settings for Excel Services

1.   On the Central Administration home page, click Application Management.

2.   On the Application Management page, in the Office SharePoint Server 2007 Shared Services section, click Create or Configure this Farm's Shared Services.

3.   On the Manage this Farm's Shared Services page, click SharedServices1 (Default). This is the SSP that you will configure.

4.   On the Shared Services home page, in the Excel Services Settings section, click Edit Excel Services settings.

You can also use the Excel Services Settings page to configure the options for file access method and data encryption, which have a direct impact on secure deployment.

File access method

On the Excel Services Settings page, in the Security section, under File Access Method, select either Impersonation or Process account.

•      Impersonation   This enables a thread to run in a security context other than the context of the process that owns the thread. Select Impersonation to require Excel Calculation Services to authorize users when they try to access workbooks that are stored in UNC and HTTP locations. Selecting this has no affect on workbooks that are stored in Office SharePoint Server 2007 databases. In most server farm deployments in which front-end Web servers and Excel Calculation Services application servers run on different computers, impersonation will require constrained Kerberos delegation.

•      Process account   If Excel Calculation Services application servers are opening workbooks from UNC shares or HTTP Web sites, the user account cannot be impersonated, and the process account must be used.

Data encryption

You can use Internet Protocol Security (IPsec) or Secure Sockets Layer (SSL) to encrypt data transmission among Excel Calculation Services application servers, data sources, client computers, and front-end Web servers. To require encrypted data transmission between client computers and front-end Web servers, change the Connection Encryption setting from None to All connections. None is the default setting. If you change the Connection Encryption setting to All connections, the Excel Calculation Services application server will only allow data transmission between client computers and front-end Web servers over SSL connections.

If you decide to require encrypted data transmission, you will have to manually configure IPsec or SSL. You can require encrypted connections between client computers and front-end Web servers while allowing unencrypted connections between front-end Web servers and Excel Calculation Services application servers.

Trusted file locations

Trusted file locations are SharePoint sites, UNC paths, or HTTP Web sites from which a server running Excel Calculation Services is permitted to access workbooks.

In the Location section of the Excel Services Add Trusted File Location page, you can configure the address, the location type, and whether child libraries of trusted file locations are also trusted. By selecting Trust Children you can improve manageability, but you can also create a potential security issue by enabling subsites and subdirectories of trusted locations to be automatically trusted as soon as they are created.

Worksheet action

Use the Trusted file locations worksheet (http://go.microsoft.com/fwlink/?LinkId=73327&clcid=0x409) to record the names of trusted SharePoint sites, UNC paths, and HTTP Web sites.

In the Session Management section, you can configure settings to help conserve resource availability and improve Excel Calculation Services performance and security. Performance can suffer when a large number of users have multiple Excel Calculation Services sessions open concurrently. You can control resource consumption and limit the duration of open Excel Calculation Services sessions by configuring two different time-out settings for open sessions.

The Session Time-out setting determines the amount of time an Excel Calculation Services session can remain open and inactive after each user interaction. The Short Session Time-out setting determines the amount of time an Excel Calculation Services session can remain open and inactive after the initial session request. You can also control the number of seconds allowed for any single session request by configuring a Maximum Request Duration value. By limiting the amount of time that sessions remain open, you can help reduce the risk of denial-of-service attacks.

In the Workbook Properties section, you can configure a maximum size of any workbook that is permitted to be opened in an Excel Calculation Services session. Performance and resource availability can be compromised when users open extremely large workbooks. Unless you control the allowable size of workbooks running in open Excel Calculation Services sessions, you risk users exceeding your resource capacity and causing the server to fail.

Note:

If an application server running Excel Calculation Services fails or is shut down, all open sessions on the server are lost. In a stand-alone installation, Excel Services will no longer be available. This means that workbooks cannot be loaded, recalculated, refreshed, or retrieved by Excel Calculation Services. In a server farm deployment that includes multiple application servers running Excel Calculation Services, shutting down one server does not affect open sessions that are running on other servers. Users with sessions running on a server that is shut down are prompted to reopen their workbooks. When users start a new session, they are automatically routed to active application servers running Excel Calculation Services.

In the External Data section, you can determine whether workbooks stored in trusted file locations and opened in Excel Calculation Services sessions can access an external data source. You can designate whether Allow External Data is set to None, Trusted data connection libraries only, or Trusted data connection libraries and embedded. If you select either Trusted data connection libraries only or Trusted data connection libraries and embedded, the workbooks stored in the trusted file locations are allowed to access external data sources.

External data connections can be accessed only when they are embedded in or linked from a workbook. Excel Calculation Services checks the list of trusted file locations before opening a workbook. If you select None, Excel Calculation Services will block any attempt to access an external data source. If you manage data connections for a large number of workbook authors, consider specifying Trusted data connection libraries only. This ensures that all data connections in all of the workbooks generated by authenticated workbook authors have to use a trusted data connection library to access any external data sources.

If you manage data connections for a small number of workbook authors, consider specifying Trusted data connection libraries and embedded. This enables workbook authors to embed direct connections to external data sources in their workbooks, but still have access to trusted data connection libraries if the embedded links fail.

In the Warn on Refresh area of the External Data section, you can specify whether a warning is displayed before a workbook refreshes from an external data source. By selecting Refresh warning enabled, you ensure that external data is not automatically refreshed without user interaction.

In the Stop When Refresh on Open Fails area, you can specify if Excel Calculation Services stops opening a workbook if the workbook contains a Refresh on Open data connection that fails. By selecting Stopping open enabled, you ensure that cached values are not displayed if a refresh operation fails when the workbook is opened. When Refresh on Open is successful, cached values are purged. By clearing the Stopping open enabled check box, you risk displaying cached values if Refresh on Open fails.

In the External Data Cache Lifetime area of the External Data section, you can specify the maximum amount of time cached values can be used before they expire.

To ensure that only trusted users have access to workbooks stored in trusted locations, it is important to enforce ACLs on all trusted file locations.

There are three core scenarios for deploying Excel Services with Office SharePoint Server 2007: enterprise, small department, and custom.

In an enterprise deployment, consider the following guidelines:

•      Do not configure support for user-defined functions.

•      Do not allow workbooks to use embedded data connections to directly access external data sources.

•      Limit the use of data connection libraries for external data source access from workbooks.

•      Restrict the size of workbooks that can be opened in Excel Calculation Services.

•      Selectively trust specific file locations and do not enable Trust Children for trusted sites and directories.

In a small department deployment, consider the following guidelines:

•      Enable trust for all file locations that are used by department members to store workbooks.

•      Enable Trust Children for all trusted sites and directories.

•      Selectively restrict access to specific file locations if problems arise.

In a custom deployment, consider the following guidelines:

•      Enable Excel Calculation Services to open large workbooks.

•      Configure long session time-out settings.

•      Configure large data caches.

•      Create a single trusted location for this deployment.

•      Do not enable Trust Children for this trusted location.

Trusted data providers

You can control access to external data by explicitly defining the data providers that are trusted and recording them in the list of trusted data providers. The list of trusted data providers designates specific external data providers to which workbooks opened in Excel Calculation Services are permitted to connect.

Before instantiating a data provider to enable a workbook to connect to an external data source, Excel Calculation Services checks the connection information to determine whether the provider appears on the list of trusted data providers. If the provider is on the list, a connection is attempted; otherwise, the connection request is ignored.

Worksheet action

Use the Trusted data providers worksheet (http://go.microsoft.com/fwlink/?LinkId=73325&clcid=0x409) to record the names of trusted data providers.

Trusted data connection libraries

A trusted data connection library is a document library from which you have determined that it is safe to access .odc files. Data connection libraries are used to secure and manage data connections for workbooks that are accessed by a server running Excel Calculation Services. A list of trusted data connection libraries designates specific data connection libraries from which workbooks opened in Excel Calculation Services are permitted to access .odc files.

If a data connection is linked from a workbook that is accessed by a server running Excel Calculation Services, the server checks the connection information and the list of trusted data connection libraries. If the data connection library is on the list, a connection is attempted by using the .odc file from the data connection library; otherwise, the connection request is ignored.

Worksheet action

Use the Trusted data connection libraries worksheet (http://go.microsoft.com/fwlink/?LinkId=73324&clcid=0x409) to record the names of trusted data connection libraries.

View Only permissions

You can specify users who are only permitted to view workbooks by adding them to the Office SharePoint Server 2007 Viewers group or by creating a new group configured with View Only permissions. The Viewers group is configured with View Only permissions by default. Users added to a group configured with View Only permissions can view, open, interact with, refresh, and recalculate workbooks, but they are prevented from accessing the file source in any way, other than by using Excel Services. This helps you protect your proprietary information. The source data is never displayed to the designated users.

Workbooks and workbook data objects configured with View Only permissions cannot be opened in Office Excel 2007; however, a snapshot of the workbook, displaying only values and formatting of the server-viewable ranges, can be rendered in Office Excel 2007.

You can configure site settings in Office SharePoint Server 2007 to control access to workbook data by setting View Only permissions on centrally managed workbooks that are rendered in a Web browser. You can also configure site settings in Office SharePoint Server 2007 to enable workbooks to refresh external data on the server, and to secure and manage external data connections. Use the following procedure to save specified data objects as View Only items.

Save specified data objects as View Only items

1.   Open a workbook that contains data objects, such as charts and tables, in Office Excel 2007.

2.   Publish the workbook to a SharePoint document library that is listed as a trusted location for Excel Services.

3.   In the File Name box on the Save As dialog box, type the URL for the SharePoint document library where you want to save the file. Ensure the Open this workbook in my browser after I save check box is selected.

4.   Click Excel Services Options.

5.   On the Excel Services Options dialog box, select Items in the Workbook from the drop-down menu.

6.   Select the items you want to render, and then click OK.

7.   On the Save As dialog box, click Save.

External data connections

The Excel Calculation Services component of Excel Services is used to connect to external data sources. Excel Calculation Services processes external data connection information that contains everything the server needs to connect to a data source, including how to authenticate, which connection string to use, which query string to use, and where and how to gather credentials to use for the connection. These connections can be defined in two places: embedded within workbooks and in .odc files. The connection information is identical in both places. The .odc files are small files that persist connection information in plain text and in a format that is reusable.

You can use the Office Excel 2007 client to author and edit .odc files and connections embedded in workbooks. In the Office Excel 2007 client, you can run the Data Connection Wizard or configure the settings in the Connections properties page. You can also export an .odc file based on these settings. The Connections properties page shows connection information, including Excel Services authentication properties.

Worksheet action

Use the External data connections worksheet (http://go.microsoft.com/fwlink/?LinkId=73323&clcid=0x409) to record the names of .odc files and the locations of corresponding external data sources.

.odc files

Workbooks can contain links to .odc files and embedded connection information. This enables workbooks to retrieve the .odc file, read the contents, and attempt to connect to an external data source if the embedded connection information fails. The .odc files must be managed and maintained to ensure that they contain accurate data connection information.

You can also configure Excel Calculation Services to use connection information from the .odc file exclusively instead of first trying to connect by using the embedded information. This approach enables administrators to deploy a small set of managed .odc files that provide updated connection information to many workbooks.

Workbook authors can specify, on a per-connection basis, which connection information the workbook can use. To do this, open Office Excel 2007 client and click Workbook Connections on the Data tab. Add a connection to a workbook, open Workbook Connections, and then view the properties of the connection you just added. On the Definition tab, select Always use connection file. This setting enables the workbook to retrieve a connection file from a data connection library and use the connection information within the file to connect to an external data source. You can also configure this setting by selecting Always use connection file on the final page of the Data Connection Wizard.

Managing .odc files

Data connection libraries provide a repository for collections of .odc files. Administrators can manage data connections on the server by creating a data connection library and .odc files that require workbooks to always use a connection file. Workbooks that consume connections directly from a data connection library will always get updated connection information before connecting to a data source.

If data source information changes (for example, the server name), you only need to update one .odc file in the data connection library and all of the workbooks that consume the .odc file will be automatically updated the next time they refresh. You can also use View Only permissions to restrict access to .odc files.

User-defined functions

If your deployment scenarios include workbooks that contain user-defined functions to extend the capabilities of Excel Calculation Services, you need to configure Excel Services to support user-defined functions.

To configure this support, you must enable user-defined functions on trusted file locations containing workbooks that require access to user-defined functions. In addition, you must register user-defined function assemblies on the Excel Services user-defined function assembly list. Use the following procedures to enable user-defined functions.

Enable user-defined functions

1.   In the Excel Services section of the Shared Services home page, click User-defined functions.

2.   On the Excel Services User-Defined Functions page, click Add User-Defined Function Assembly.

3.   In the Assembly box, type the assembly strong name or the file path of the user-defined function assembly that you want to register.

4.   In Assembly Location, perform the following actions:

a.   Select the global assembly cache (GAC) if you are deploying a user-defined function assembly to the GAC on each Excel Calculation Services application server in your farm.

b.   Select Local file if you want to save a user-defined function to a directory on an Excel Calculation Services application server (a local path), or to a network share (a UNC path).

c.   Ensure the Enable Assembly check box is selected, and then click OK.

Enable user-defined functions for workbooks in a trusted file location

1.   In the Excel Services section of the Shared Services home page, click Trusted file locations.

2.   On the Excel Services Trusted File Locations page, click the URL of the trusted file location whose properties you want to edit.

3.   In the User-Defined Functions section of the Excel Services Edit Trusted File Location page, select User-defined functions allowed, and then click OK.

Worksheets

Use the following worksheets to plan Excel Services security:

•      External data connections worksheet (http://go.microsoft.com/fwlink/?LinkId=73323&clcid=0x409)

•      Trusted data connection libraries worksheet (http://go.microsoft.com/fwlink/?LinkId=73324&clcid=0x409)

•      Trusted data providers worksheet (http://go.microsoft.com/fwlink/?LinkId=73325&clcid=0x409)

•      Trusted file locations worksheet (http://go.microsoft.com/fwlink/?LinkId=73327&clcid=0x409)

See Also

Demo: Enable Excel Services and data connections for a SharePoint team site (http://office.microsoft.com/en-us/sharepointserver/HA102078901033.aspx)

Determine resource requirements to support Excel Services

In this article:

•      About Excel Services topologies

•      Plan for simultaneous client connections

•      Plan for concurrent Excel Calculation Services session requests

•      Excel Services performance testing

•      Limit the number and duration of open sessions

Many factors can affect the performance and availability of your Microsoft Office SharePoint Server 2007 deployment, including network bandwidth and resource consumption. Excel Services in Microsoft Office SharePoint Server 2007 in Office SharePoint Server 2007 can affect system performance, depending on the volume of client connections and the number of simultaneous Excel Calculation Services session requests. Calculation size and complexity can also affect Excel Calculation Services resource consumption.

The scope and complexity of Excel calculations can affect the performance and availability of Excel Services in an Office SharePoint Server 2007 deployment. As calculation volume, complexity, and frequency increase, more system resources are consumed. Define baseline hardware requirements for system memory, CPU speed, and storage for each application server that runs Excel Calculation Services.

About Excel Services topologies

Office SharePoint Server 2007 is logically divided into three tiers: the front-end Web server tier, the application server tier, and the database tier. During installation, Excel Services installs two components (Excel Web Access and Excel Web Services) on the front-end Web server tier, and one component (Excel Calculation Services) on the application server tier, as shown in the following diagram.

A network load balancer enables Office SharePoint Server 2007 to scale out front-end Web servers. The network load balancer is available to all Office SharePoint Server 2007 applications. You can scale out application servers by adding computers within the shared services framework in Office SharePoint Server 2007.

There are three schemes for load balancing Excel Calculation Services requests: Workbook URL, Round-Robin, and Local. You can configure separate load balancing schemes for each Shared Services Provider (SSP).

For information about how to install the Office SharePoint Server 2007 Excel Services components, see the following articles:

•      Deploy Office SharePoint Server 2007 on a stand-alone computer

•      Deploy Office SharePoint Server 2007 in a server farm environment

Data access models

There are two data access models you can use for any of the Excel Services server farm topologies: trusted subsystem and constrained Kerberos delegation.

•      Trusted subsystem   This is the default setting for a Windows server farm, because it does not have the extra configuration requirements of the delegation model. In the trusted subsystem model, front-end Web servers and application servers running Excel Calculation Services trust the accounts of the associated Office SharePoint Server 2007 applications by using the SSP. In a trusted subsystem environment, when opening files from Microsoft Office SharePoint Server 2007, permission checks on the files can be performed against end-user identities even if Kerberos is not configured. If Excel Calculation Services application servers are opening workbooks from UNC shares or HTTP Web sites, the user account cannot be impersonated, and the process account must be used.

•      Constrained Kerberos delegation   This is the most secure configuration for communication between front-end Web servers and Excel Calculation Services application servers. Constrained Kerberos delegation is also the most secure configuration for accessing back-end data sources from application servers. Constrained Kerberos delegation is the preferred configuration for deploying Excel Services. For external data connections, Integrated Windows authentication will only work if the delegation model is implemented.

Excel Services topologies

The following Excel Services topologies are described in this section:

•      Excel Services single-server topology

•      Excel Services small farm trusted subsystem topology

•      Excel Services small farm Kerberos topology

•      Excel Services medium farm trusted subsystem topology

•      Excel Services medium farm Kerberos topology

•      Excel Services large farm trusted subsystem topology

•      Excel Services large farm Kerberos topology

•      Excel Services extranet topology

•      Excel Services corporate intranet topology

•      Excel Services high-performance computing topology

Excel Services single-server topology

The following topology diagram shows the logical architecture for a stand-alone Excel Services deployment on a single server.

In this example, all Office SharePoint Server 2007 components are installed on a single computer. This includes the Excel Services front-end Web server components and Excel Calculation Services, the application server component of Excel Services. This also includes the configuration and content databases, which are installed by using Microsoft SQL Server Express Edition. This topology is useful for testing the core functionality of Excel Services, but it is not recommended as a scalable solution.

This configuration supports multiple Windows SharePoint Services 3.0 Web applications by using Integrated Windows authentication. In this configuration, external data access can be provided by using data connection libraries, the Microsoft Single Sign-On service (SSO), or data connections embedded in workbooks. Load balancing is provided by the Excel Services load–balancing component. This topology uses the trusted subsystem data access method. The file access method is an Excel Calculation Services process account configured as an SSO administrator.

Excel Services small farm trusted subsystem topology

The following topology diagram shows the logical architecture for a small farm Excel Services deployment that uses the trusted subsystem data access model.

In this example, the Excel Services front-end Web server components and the application server component are installed on one server, and the SQL Server 2005 configuration and content databases are installed on a separate server. This configuration also shows the Single Sign-On service running on the Office SharePoint Server 2007 server. The configuration also shows the Excel Calculation Services process account configured as an SSO administrator.

Excel Services small farm Kerberos topology

The following topology diagram shows the logical architecture for a small farm Excel Services deployment that uses the constrained Kerberos delegation data access model.

In this example, the Excel Services front-end Web server components and the application server component are installed on one server, and the SQL Server 2005 configuration and content databases are installed on a separate server. This configuration also shows the Single Sign-On service running on the Office SharePoint Server 2007 server. The configuration also shows the Excel Calculation Services process account configured as an SSO administrator.

Excel Services medium farm trusted subsystem topology

The following topology diagram shows the logical architecture for a medium farm Excel Services deployment that uses the trusted subsystem data access model.

In this example, the Excel Services front-end Web server components, the application server component, and the SQL Server 2005 configuration and content databases are installed on three separate servers. This configuration also shows the Single Sign-On service running on the Office SharePoint Server 2007 front-end Web server and on the Excel Services application server. The configuration also shows the Excel Calculation Services process account configured as an SSO administrator.

Excel Services medium farm Kerberos topology

The following topology diagram shows the logical architecture for a medium farm Excel Services deployment that uses the constrained Kerberos delegation data access model.

In this example, the Excel Services front-end Web server components, the application server component, and the SQL Server 2005 configuration and content databases are installed on three separate servers. This configuration also shows the Single Sign-On service running on the Office SharePoint Server 2007 front-end Web server and on the Excel Services application server. The configuration also shows the Excel Calculation Services process account configured as an SSO administrator.

Excel Services large farm trusted subsystem topology

The following topology diagram shows the logical architecture for a large farm Excel Services deployment that uses the trusted subsystem data access model.

In this example, multiple Excel Services front-end Web server components, multiple application server components, and multiple SQL Server 2005 configuration and content databases are each installed on separate servers. This configuration also shows the Single Sign-On service running on the Office SharePoint Server 2007 front-end Web server and on the Excel Services application server. The configuration also shows the Excel Calculation Services process account configured as an SSO administrator.

Important:

For large farm deployments, it is recommended to run Office SharePoint Server 2007 in a homogeneous environment. All of the servers in a large farm should run either a 32-bit version of Windows Server 2003 or a 64-bit version of Windows Server 2003. It is not recommended to run Office SharePoint Server 2007 in a mixed environment.

Excel Services large farm Kerberos topology

The following topology diagram shows the logical architecture for a large farm Excel Services deployment that uses the constrained Kerberos delegation data access model.

In this example, multiple Excel Services front-end Web server components, multiple application server components, and multiple SQL Server 2005 configuration and content databases are each installed on separate servers. This configuration also shows the Single Sign-On service running on the Office SharePoint Server 2007 front-end Web server and on the Excel Services application server. The configuration also shows the Excel Calculation Services process account configured as an SSO administrator.

Excel Services extranet topology

The following topology diagram shows the logical architecture for Excel Services front-end Web server components, application server components, and SQL Server 2005 configuration and content databases deployed in a perimeter network.

In this example, Excel Services components are isolated from external data sources and client computers in a secure perimeter network behind firewalls. This configuration provides enhanced security for data sources and helps prevent data corruption and unauthorized access to data.

Note:

If you have a Windows firewall enabled on the application servers, you must open the specific port on which the shared services Web site that hosts Excel Calculation Services is running.

Excel Services corporate intranet topology

The following topology diagram shows the logical architecture for an Excel Services deployment that isolates front-end Web server components and SQL Server 2005 configuration and content databases in a perimeter network that is separated from the corporate intranet. Excel Services application servers are deployed within the corporate intranet and all Excel Services components are isolated from remote client computers and from external data sources.

In this example, Excel Services application servers are deployed within the corporate network and are protected from direct external access. This configuration enables you to tightly control who can access your application servers and data. By isolating front-end Web servers in a perimeter network, you limit the attack surface of your environment to public-facing Web servers.

Note:

If you have a Windows firewall enabled on the application servers, you must open the specific port on which the shared services Web site that hosts Excel Calculation Services is running.

Excel Services high-performance computing topology

The following topology diagram shows the logical architecture for a deployment that includes Microsoft Windows Compute Cluster Server 2003 and Excel Services.

In this example, the Excel Services front-end Web server components and the application server component are installed on individual compute cluster nodes that comprise a compute cluster. These nodes share a SQL Server 2005 configuration and content database that runs on a server that is external to the compute cluster. A head node runs the compute cluster scheduler that schedules and load balances jobs among the nodes in the cluster.

Plan for simultaneous client connections

The number of simultaneous client connections can impact the performance and availability of front-end Web servers. For a deployment designed to support a large number of client connections, you need to plan for the deployment of enough front-end Web servers to support an adequate level of system performance and availability. Determine the number of front-end Web servers that are required for your deployment scenario. Define baseline hardware requirements for system memory, CPU speed, and storage for each front-end Web server.

Plan for concurrent Excel Calculation Services session requests

To determine the appropriate scale of a deployment to support Excel Calculation Services in Office SharePoint Server 2007, you need to know how many concurrent Excel Calculation Services session requests the scenario needs to support. For a deployment designed to support a large volume of Excel Calculation Services sessions, you need to plan for enough Excel Calculation Services servers to support an adequate level of performance and availability. Add Excel Calculation Services servers to improve performance and availability. Excel Calculation Services Proxy is a front-end Web server component used to load-balance session requests among the available application servers that run Excel Calculation Services.

You can configure a per-user session limit for application servers that run Excel Calculation Services. This value is the maximum number of concurrent sessions allowed for each user. Windows SharePoint Services 3.0 Web sites can be configured to allow anonymous user access. In this case, the Excel Calculation Services session limit for a single user will still apply. All anonymous users share the same session limit value that is configured for a single user.

The following configuration changes are recommended for an Excel Services environment that supports a large volume of Excel Calculation Services session requests and workbook calculations.

•      IIS time-out   If calculations in Excel Services are expected to take longer than 110 seconds, increase the IIS time-out value. A ThreadAbort exception will occur when calculations exceed the IIS time-out setting. The default IIS time-out setting is 110 seconds.

•      ASP.NET MaxConnection   When the number of client connection requests requires front-end Web servers to open multiple concurrent connections to application servers running Excel Calculation Services, you need to increase the maximum number of ASP.NET connections. In ASP.NET, configure the MaxConnection setting to a maximum connection limit of 10, as shown in the following example:

<configuration>    <system.net>       <connectionManagement>          <add address="*" maxconnection="10" />       </connectionManagement>    </system.net> <system.web>

Consider configuring the following Windows Server 2003 registry settings to improve Excel Calculation Services performance.

Caution:

Incorrectly editing the registry might severely damage your system. Before making changes to the registry, you should back up any valued data on the computer.

•      HeapDeCommitFreeBlockThreshold   During a period when Excel Calculation Services application servers are experiencing a high volume of requests, the application servers might encounter performance issues caused by memory allocation failures. Because of memory fragmentation, this can occur even if application servers have adequate amounts of RAM installed to handle the volume of requests. To alleviate this problem, use the Registry Editor to change the HeapDeCommitFreeBlockThreshold setting to REG_DWORD 0x00040000. To change the setting, use the following registry path:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager

•      MaxUserPort   You might need to increase the range of available ports by changing the value of the MaxUserPort registry setting. The MaxUserPort setting specifies the highest port number that TCP can assign when an application requests an available user port from the system. To change this registry setting, run the Registry Editor and use the following registry path:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters

•      TcpNumConnections   You might need to increase the maximum number of connections that TCP can have open simultaneously by changing the value of the TcpNumConnections registry setting. If the TcpNumConnections registry key does not exist, run the Registry Editor to create and configure the key. To change this registry setting, run the Registry Editor and use the following registry path:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters

•      TcpTimedWaitDelay   During a period when Excel Calculation Services application servers are experiencing a high volume of requests, there is a possibility that some requests will be denied. If this occurs, you might be encountering a problem with the default setting of the TcpTimedWaitDelay registry key. By default, the TcpTimedWaitDelay setting is set to 240 seconds, or four minutes. This is the amount of time that must elapse before a closed TCP session can be released and the resources can be reassigned. To alleviate this problem, use the Registry Editor to change the TcpTimedWaitDelay setting from 240 seconds to 30 seconds. If the TcpTimedWaitDelay registry key does not exist, run the Registry Editor to create and configure the key by using the following registry path:

HKEY_LOCAL_MACHINE\SYSTEM\ControlSet\Services\Tcpip\Parameters

Excel Services performance testing

The following performance test results provide guidance based on comparisons of throughput, response times, and resource utilization of Excel Services by using different topologies and data sets. These recommendations are also based on comparisons of performance factors by using different external data authentication schemes for online analytical processing (OLAP) and relational external data connections. Resource requirements and response times in Excel Services depend on workbook size, workbook complexity, the number of concurrent users, and external data latency. Tests are run by using a defined data set, and results vary depending on data set design.

The baseline configuration for each tested data set includes Office SharePoint Server 2007 dashboards, with each dashboard rendering two Excel Web Access Web Parts and two key performance indicator (KPI) Web Parts. The result is four Excel Calculation Services sessions for each page hit.

Twenty percent of the sessions are assumed to have some interactivity, such as paging or data refresh. The tests are based on the assumption that 5,000 users are actively accessing dashboards and portal KPIs linked to cells in Microsoft Office Excel 2007 workbooks.

Hardware configuration

Performance testing was run on Office SharePoint Server 2007 front-end Web servers, Excel Calculation Services application servers, and Office SharePoint Server 2007 SQL Configuration and Content Database servers with the following hardware configurations:

Servers

Hardware configuration

The Office SharePoint Server 2007 front-end Web servers

Two Dual-Core AMD Opteron 275 CPUs running at 2.2 GHz, with 9.83 GB RAM

The Excel Calculation Services application servers

Two Dual-Core AMD Opteron 275 CPUs running at 2.2 GHz, with 9.83 GB RAM

The Office SharePoint Server 2007 SQL Configuration and Content Database servers

Four Dual-Core AMD Opteron 880 CPUs running at 2.4 GHz, with 8 GB RAM

Data set attribute tables

This section provides information about the attributes of the data set and scenarios used for performance testing. Exceptions to these attributes are noted in individual configurations, as applicable. Excel Services performance depends on the attributes of the data set, including memory usage, CPU usage, throughput, and response time. It is important to consider the characteristics of your data set before using the performance test results provided here. The results you get will vary based on the data used in your environment, and other variables.

Performance test scenarios

The performance tests were run using the following test scenarios. The scenarios are based on an assumption of a total of 5000 users actively accessing dashboard pages and Excel workbooks, with Office Excel Web Access. The scenarios are also based on the assumption that a variety of dashboards are accessed with varying degrees of frequency. The tests include:

•      A small number of dashboards that are accessed frequently by a large number of users.

•      A large number of dashboards that are accessed infrequently by a small number of users.

This range of dashboard usage corresponds to an enterprise environment in which a small number of dashboards are used across the entire organization, and a large number of dashboards are used by groups within the organization.

Number of users

Frequency of views

Number of dashboards

Number of workbooks

3,750

Twice a day

5

10

1,500

Three times a week

25

24

1,000

Once a week

50

50

250

Once a month

150

40

150

30% of 1,000 files are viewed by users accessing Excel Web Access Web Parts

300

25

Workbooks without external data connections

The workbooks in this scenario are not connected to an external data source. Resource consumption is determined by the size, complexity, the amount of formatting, and the number of calculations used in each workbook. Workbook size is determined by the number of rows and columns each workbook contains. All of these factors affect resource consumption and throughput in Excel Services. The workbooks include a range of features, such as formatting, conditional formatting, and charting. The dataset used includes a range of workbooks with the following attributes:

Percentage of workbooks

Rows

Columns

Percentage of calculations

Percentage of formatting

Volatile functions

2%

<5,000

10 – 45

50%

50%

Yes

38%

<5,000

10 – 45

20%

50%

No

5%

<5,000

60 – 365

5%

50%

No

20%

5,000 – 7,000

10 – 40

10%

50%

No

15%

7,001 – 10,000

10 – 50

10%

50%

No

15%

10,001 – 15,000

10 – 50

10%

50%

No

5%

15,001 – 20,000

10 – 50

10%

50%

No

Workbooks with OLAP data connections

The workbooks in this scenario contain data connections to Analysis Services cubes. These workbooks include a range of features, such as formatting and conditional formatting. In addition to the variables that affect resource consumption and throughput in every scenario, the amount of Analysis Services data that is consumed by the workbooks in this scenario, and whether or not the workbooks are refreshed on open, can affect Excel Services performance. This scenario is based on the assumption that 15% of the workbooks have data connections that refresh on open. Caching has a major impact on the performance of external data connections. Typically, Excel Services uses cached data if there is a connection to an external data source, using the same credentials multiple times. Caching performance is also affected by the Excel Services External Data Cache Lifetime setting.

Percentage

Rows

Row size

Other

10%

<1,000

512 – 2,048

DCL SSO (or Kerberos)

20%

<1,000

512 – 2,048

DCL SSO (or Kerberos), refresh on open

40%

<1,000

100 – 512

One to four PivotTable reports and one to four PivotChart reports embedded in workbooks

20%

<1,000

<100

Four to six PivotTable reports and four to six PivotChart reports embedded in workbooks

10%

1,000 – 5,000

<100

Two PivotTable reports and two PivotChart reports embedded in workbooks

Workbooks with relational data connections

The workbooks in this scenario contain data connections to SQL Server relational databases. These workbooks include a range of features, such as formatting and conditional formatting. In addition to the variables that affect resource consumption and throughput in every scenario, whether or not the workbooks are refreshed on open can affect Excel Services performance in this scenario. This scenario is based on the assumption that 15% of the workbooks have data connections that refresh on open. Caching has a major impact on the performance of external data connections. Typically, Excel Services uses cached data if there is a connection to an external data source, using the same credentials multiple times. Caching performance is also affected by the Excel Services External Data Cache Lifetime setting.

Percentage

Rows

Row size

Other

2%

<1,000

<512

DCL SSO (or Kerberos), periodic refresh

20%

<500

<512

DCL SSO (or Kerberos), refresh on open

40%

1,001 – 5,000

1024 – 2,048

One or two PivotTable reports and one or two PivotChart reports embedded in workbooks

20%

5,000 – 10,000

1024 – 2,048

DCL SSO; one or two PivotTable reports and one or two PivotChart reports embedded in workbooks

10%

10,000 – 20,000

512 – 1,024

DCL SSO; two to four PivotTable reports and two to four PivotChart reports embedded in workbooks

8%

20,000 – 65,000

<512

DCL SSO; one or two PivotTable reports embedded in workbooks

Distribution of workbooks by data sources

Performance tests were run using the following distribution of workbooks. Exceptions to this distribution are noted for some of the configurations. In each configuration, workbooks were distributed based on the percentages shown in the data set attribute tables. For Example, 30% of the workbooks contained no external data. Of these, 20% had between 5000 and 7000 rows, as shown in the Workbooks without external data connections table. This resulted in 6% of the total workbook distribution (20% of 30%), consisting of workbooks with no external data and containing between 5000 and 7000 rows. Some of the configurations isolate workbooks of a specific type. For example, workbooks containing OLAP data connections configured to refresh on open.

Workbook type

Percentage

Workbooks with no external data

30%

Workbooks with OLAP data connections

35%

Workbooks with relational data connections

35%

Request mix used in performance tests

Performance tests were run using the following request mix. There are exceptions to this request mix. For example, in tests using workbooks with no external data, there are no interactive operations with external data queries. Exceptions are noted for some of the configurations.

Request type

Percentage of total requests

OpenWorkbook (includes one GetRrange)

65%

Interactive requests with external data queries

15%

GetRange (paging)

10%

Find, Sort, and Filter interactive requests within workbooks

10%

Performance test results

The tables in this section show test results for each tested configuration.

Excel Services small farm trusted subsystem configuration

The following table shows the data set for this configuration.

Workbook type

Percentage

Workbooks with no external data

30%

Workbooks with OLAP data connections

35%

Workbooks with relational data connections

35%

The following table shows front-end Web server test results for this configuration:

Performance counter

Result

Requests per second

14.32

Average response time in seconds

5.52

ASP.NET queue

1.91

CPU

41.97

W3wp process private bytes

822

The following table shows Excel Calculation Services application server test results for this configuration:

Performance counter

Result

Requests per second

15.52

Average response time in seconds

2.05

Sessions per second

2.94

ASP.NET queue

1.91

CPU

41.97

W3wp process private bytes

3844

Excel Services large farm trusted subsystem configuration

The following table shows the data set for this configuration.

Workbook type

Percentage

Workbooks with no external data

30%

Workbooks with OLAP data connections

35%

Workbooks with relational data connections

35%

The following table shows front-end Web server test results for this configuration.

Performance counter

Front-end Web server 1

Front-end Web server 2

Front-end Web server3

Requests per second

4.62

4.54

4.63

Average response time in seconds

10

9.69

10.01

ASP.NET queue

0.12

0.2

0.25

CPU

1.13

1.21

1.21

W3wp process private bytes

738

713

742

The following table shows Excel Calculation Services application server test results for this configuration.

Performance counter

Result

Requests per second

14.8

Average response time in seconds

4.74

Sessions per second

2.58

ASP.NET queue

33.29

CPU

37.84

W3wp process private bytes

3867

Excel Services large farm Kerberos configuration

The following table shows the data set for this configuration.

Workbook type

Percentage

Workbooks with no external data

30%

Workbooks with OLAP data connections

35%

Workbooks with relational data connections

35%

The following table shows front-end Web server test results for this configuration.

Performance counter

Front-end Web server 1

Front-end Web server 2

Front-end Web server3

Requests per second

15.39

15.36

15.58

Average response time in seconds

4.48

4.3

4.35

ASP.NET queue

0.46

0.5

0.45

CPU

4.43

4.33

4.36

W3wp process private bytes

906

909

899

The following table shows Excel Calculation Services application server test results for this configuration.

Performance counter

Result

Requests per second

46.36

Average response time in seconds

1.36

Sessions per second

9.43

ASP.NET queue

63.55

CPU

54.82

W3wp process private bytes

6387

Excel Services large farm trusted subsystem configuration using OLAP data with refresh on open and SSO

The following table shows the data set for this configuration.

Workbook type

Percentage

Workbooks with OLAP data connections; refresh on open; uses SSO for external data authentication

100%

The following table shows front-end Web server test results for this configuration:

Performance counter

Front-end Web server 1

Front-end Web server 2

Front-end Web server3

Requests per second

1.84

1.83

1.85

Average response time in seconds

7.6

7.5

8.07

ASP.NET queue

0.001

0.001

0

CPU

0.59

0.61

0.62

W3wp process private bytes

379

375

384

The following table shows Excel Calculation Services application server test results for this configuration:

Performance counter

Result

Requests per second

6.52

Average response time in seconds

3.82

Sessions per second

1.08

ASP.NET queue

1.22

CPU

45.29

W3wp process private bytes

4995

Excel Services large farm Kerberos configuration using OLAP data with refresh on open

The following table shows the data set for this configuration.

Workbook type

Percentage

Workbooks with OLAP data connections; refresh on open; uses Kerberos for external data authentication; user credentials are delegated for authentication with OLAP data sources

100%

The following table shows front-end Web server test results for this configuration.

Performance counter

Front-end Web server 1

Front-end Web server 2

Front-end Web server3

Requests per second

0.99

1

0.99

Average response time in seconds

19.29

18.32

19.36

ASP.NET queue

0.001

0

0.001

CPU

0.41

0.41

0.38

W3wp process private bytes

417

431

425

The following table shows Excel Calculation Services application server test results for this configuration.

Performance counter

Result

Requests per second

2.95

Average response time in seconds

17.39

Sessions per second

0.59

ASP.NET queue

11.63

CPU

54.8

W3wp process private bytes

10419

Excel Services large farm Kerberos configuration using SQL Server 2005 Analysis Services groups

The following table shows the data set for this configuration.

Workbook type

Percentage

Workbooks with OLAP data connections; refresh on open, using Kerberos for external data authentication; user credentials are delegated for authentication with OLAP data sources; users map to SQL Server 2005 Analysis Services groups

100%

The following table shows front-end Web server test results for this configuration.

Performance counter

Front-end Web server 1

Front-end Web server 2

Front-end Web server3

Requests per second

8.7

8.38

8.62

Average response time in seconds

3.63

3.69

3.7

ASP.NET queue

0.004

0.004

0.006

CPU

2.31

2.31

2.3

W3wp process private bytes

435

431

452

The following table shows Excel Calculation Services application server test results for this configuration.

Performance counter

Result

Requests per second

25.67

Average response time in seconds

1.69

Sessions per second

5.22

ASP.NET queue

2.73

CPU

63.07

W3wp process private bytes

7850

Excel Services large farm trusted subsystem configuration using relational data

The following table shows the data set for this configuration.

Workbook type

Percentage

Workbooks with relational data connections; refresh on open, using SSO for external data authentication

100%

The following table shows front-end Web server test results for this configuration.

Performance counter

Front-end Web server 1

Front-end Web server 2

Front-end Web server3

Requests per second

24.07

24.2

24.6

Average response time in seconds

3.17

3.16

3.15

ASP.NET queue

9.15

10.41

13.77

CPU

6.49

6.65

6.78

W3wp process private bytes

959

965

1062

The following table shows Excel Calculation Services application server test results for this configuration.

Performance counter

Result

Requests per second

76.16

Average response time in seconds

0.43

Sessions per second

14.84

ASP.NET queue

17.79

CPU

46.62

W3wp process private bytes

35.88

Excel Services large farm Kerberos configuration using relational data

The following table shows the data set for this configuration.

Workbook type

Percentage

Workbooks with relational data connections; refresh on open, using constrained Kerberos delegation for external data authentication

100%

The following table shows front-end Web server test results for this configuration.

Performance counter

Front-end Web server 1

Front-end Web server 2

Front-end Web server3

Requests per second

22.78

22.6

23.1

Average response time in seconds

3.03

2.97

2.98

ASP.NET queue

0.59

0.5

0.39

CPU

6.18

6.15

6.16

W3wp process private bytes

836

838

843

The following table shows Excel Calculation Services application server test results for this configuration.

Performance counter

Result

Requests per second

68.41

Average response time in seconds

0.74

Sessions per second

13.87

ASP.NET queue

21.46

CPU

55.87

W3wp process private bytes

6328

Limit the number and duration of open sessions

In addition to adding resources, limiting the number of open Excel Calculation Services sessions can help mitigate performance and availability issues. One way to limit the number of open Excel Calculation Services sessions is to decrease session time-out settings. Indiscriminately limiting session duration can cause active sessions to close, which can result in data loss.

The preferred solution is to use Office Excel Web Access Short Session Mode to configure shorter initial time-out settings for sessions that have no client-side interactivity when the sessions are opened. You can configure a second time-out setting for sessions that are active as soon as they are opened. In this example, sessions that remain inactive for the duration of the initial time-out setting are closed by the Excel Calculation Services server. Sessions that are active before the initial time-out setting expires will remain open until the second time-out setting expires.

See Also

Microsoft Windows Compute Cluster Server 2003 (http://www.microsoft.com/hpc/en/us/default.aspx)

Plan rendering Excel KPI data

In this article:

•      About rendering Excel KPI data

•      KPI List Web Parts for Office SharePoint Server 2007

•      Excel KPI and SQL Server 2005 Analysis Services

About rendering Excel KPI data

In Microsoft Office SharePoint Server 2007, data in Microsoft Office Excel 2007 spreadsheets can be rendered in individual key performance indicator (KPI) List Web Parts or aggregated into a dashboard on a SharePoint site. A dashboard is a page that contains a set of Web Parts. A dashboard might be a KPI list made up of multiple KPI List Web Parts. Each Web Part can render data derived from several different Excel spreadsheets, or from multiple data objects within the same spreadsheet.

KPI List Web Parts for Office SharePoint Server 2007

Office SharePoint Server 2007 includes a new KPI List Web Part. This new Web Part is designed to render the current status of volatile data in a way that can be easily understood in business terms. By using KPIs, users can monitor the status and trends of important business measurements as they occur. KPIs can be used to abstract large amounts of data and render the data as easily understood icons.

Excel KPI and SQL Server 2005 Analysis Services

Microsoft SQL Server 2005 Analysis Services is a source for data that Excel Services in Microsoft Office SharePoint Server 2007 renders as KPIs. When a server that runs SQL Server 2005 Analysis Services is deployed and populated with business data, the server functions as a Unified Dimensional Model (UDM) to which Excel Services can connect. The UDM is a logical layer between reporting applications and back-end data sources. The UDM layer can be designed to render data in business terms and make it easier for users to create reports.

The data that Excel Services consumes from a SQL Server 2005 Analysis Services server can be formatted on the server by a UDM designer. The UDM designer can set server-based conditional formatting rules that can be implemented to draw attention to values that compromise the integrity of a database, such as a negative balance or any other values that violate business rules. The UDM designer can also set up visual status and trend indicators that help users quickly understand rendered KPI data in business terms.

Plan Excel reports against OLAP cubes

In this article:

•      About building Excel reports against OLAP cubes

•      OLAP functions

•      OLAP formulas

About building Excel reports against OLAP cubes

You can use the new Microsoft Office Excel 2007 online analytical processing (OLAP) functions and formulas to create highly customizable reports and analytic models that can be automatically updated to include the most current business data from external data sources.

OLAP functions

By using the new Office Excel 2007 OLAP functions, you can use an Office Excel 2007 spreadsheet as a reporting surface for data from OLAP cubes. You can use the following OLAP functions to import Microsoft SQL Server 2005 Analysis Services data directly into Office Excel 2007 spreadsheet cells for unstructured data analysis:

•      CUBEMEMBER   Sends a Multidimensional Expression (MDX) to an OLAP cube and fetches a member or tuple.

•      CUBEVALUE   Sends one or more MDX to an OLAP cube and fetches an aggregated value.

•      CUBESET   Sends an MDX to an OLAP cube that defines a set in the cube and places the set in a spreadsheet cell.

•      CUBESETCOUNT   Returns the number of elements in a set.

•      CUBERANKEDMEMBER   Fetches the Nth item in a set.

•      CUBEMEMBERPROPERTY   Returns a member property value from an OLAP cube.

•      CUBEKPIMEMBER   Returns a key performance indicator (KPI) goal, value, status, or trend from an OLAP cube.

OLAP formulas

Excel OLAP formulas provide an additional way to display SQL Server 2005 Analysis Services data in Office Excel 2007 spreadsheets. By using Excel OLAP formulas, you can build reports with greater control of data placement than is possible by using PivotTable reports. In addition, you can use Excel OLAP formulas to write custom MDXs into a report.

Plan access to Excel spreadsheets

In this article:

•      About spreadsheet management

•      Plan a strategy to control access to workbooks and ensure data integrity

•      Plan a strategy to restrict access to individual data objects within workbooks

About spreadsheet management

By using Excel Services in Microsoft Office SharePoint Server 2007, you can control access to workbook data while ensuring data integrity. You can use Excel Calculation Services to enforce centralized management of proprietary information, maintain one version of the truth for Microsoft Office Excel 2007 workbooks, and control how and to whom workbook data is made available based on user permissions.

Depending on the type of access permitted, you can restrict users to View Only permissions, allowing them to view snapshots of workbooks without being able to alter any data in Office Excel 2007. Workbooks that have View Only restrictions still allow users to open, interact with, refresh, and recalculate workbooks in a Web browser. You can also grant open permission to users, which allows them to access and update workbooks.

Plan a strategy to control access to workbooks and ensure data integrity

By configuring View Only permissions, you can ensure that Excel workbooks are only rendered in a Web browser. Users who have View Only permissions can be restricted to opening a snapshot of the workbook in Office Excel 2007.

In Microsoft Office SharePoint Server 2007, you can configure View Only permissions and access restrictions to document libraries in a SharePoint site. This enables you to restrict the availability of workbook data to users who have authenticated access to the site.

Plan a strategy to restrict access to individual data objects within workbooks

Access to selected data objects within a workbook, such as PivotTable components and charts, can be controlled independently from the rest of the workbook when the workbook is published to an application server that runs Excel Calculation Services. The view of the workbook in Excel Services, when rendered in a Web browser, is always the published view, which might be limited to the server-viewable items in the workbook.

Users who have View Only permissions will be able to open only a snapshot of the published items. Users who have full permissions will be able to open the full workbook, including items that have not been designated server viewable.

Plan external data connections for Excel Services

In this article:

•      About Excel Services connections to external data

•      Connections and Excel workbooks

•      Data providers

•      Authentication to external data

•      Data connection libraries and managed connections

•      Excel Services security and external data

•      Step-by-step server configuration for external data

•      Step-by-step workbook configuration for external data

•      Frequently asked questions

To configure Microsoft Office SharePoint Server 2007 to enable workbooks loaded on Excel Services in Microsoft Office SharePoint Server 2007 to successfully refresh external data, you need to understand the relationships and dependencies between Office SharePoint Server 2007 and Excel Services.

The guidance provided in this article helps you resolve the following Data Refresh Failed error message.

About Excel Services connections to external data

This article provides guidance to help you configure the following Office SharePoint Server 2007 application server components:

•      Excel Services

•      Single sign-on (SSO)

•      Office SharePoint Server 2007

This article also includes background information that provides an overview of application server and external data concepts, some of which are specific to Office Excel 2007. This background information contains important information that will help you successfully set up Excel Services to enable workbooks to consume external data.

This article also shows you how to configure Office Excel 2007 workbooks and provides answers to frequently asked questions, including questions about:

•      Server security and external data

•      Managed data connections

Connections and Excel workbooks

Every Excel workbook that uses external data contains a connection to a data source. Connections consist of everything that is required to establish communications with, and retrieve data from, an external data source. This includes:

•      A connection string (a string that specifies which server to connect to and how to connect to it).

•      A query (a string that specifies what data to retrieve).

•      Any other specifics required to get the data.

Embedded and linked connections

Excel workbooks can contain embedded connections and linked connections. Embedded connections are stored internally as part of the workbook. Linked connections are stored externally as separate files that can be referenced by a workbook.

Functionally, there is no difference between embedded and linked connections. Both will correctly specify all the required parameters to connect to data successfully. Linked connection files can be centrally stored, secured, managed, and reused. They are often a good choice when planning an overall approach to getting a large group of users connected to external data. For more information, see Data connection libraries and managed connections.

For a single connection, a workbook can have both an embedded copy of the connection information and a link to an external connection file. The connection can be configured to always use an external connection file to refresh data from an external data source. In this example, if the external connection file cannot be retrieved, or if it fails to establish a connection to the data source, the workbook cannot retrieve data. If the connection is not configured to use only an external connection file, Excel attempts to use the embedded copy of a connection. If that fails, Excel attempts to use the connection file to connect to the external data source. The ability to specify that only connection files can be used to establish a communications link to an external data source is a new feature of 2007 Microsoft Office system and provides support for the managed connection scenarios described in Data connection libraries and managed connections.

Excel Services can use connections coming from an external connection file and connections that are embedded in the workbooks. There are some restrictions for external connection files. For more information, see Excel Services security and external data. If both types of connections are allowed on the server, the behavior is the same as the Excel behavior described in the previous paragraph.

For security purposes, Excel Services can be configured to only allow connections from connection files. In this configuration, all embedded connections are ignored for workbooks loaded on the server, and connections are only attempted when there is a link to a valid connection file that is trusted by the server administrator. For more information, see Trusted data connection libraries.

Note:

There are many types of connection files, and Excel Services only works with Office data connection files (.odc).

Data providers

Data providers are drivers that client applications (such as Excel and Excel Services) use to connect to specific data sources. For example, a special MSOLAP data provider is used to connect to Microsoft SQL Server 2005 Analysis Services. The data provider will be specified as part of the connection in the connection string. You do not need to know a lot about data providers in the context of this article, but you need to understand that:

•      Data providers are typically well-tested, stable sets of libraries that can be used to connect to external data.

•      Any data provider used by Excel Services must be explicitly trusted by the server administrator. For information about adding a new data provider to the trusted providers list, see Adding a trusted data provider for Excel Services.

Note:

By default, Excel Services trusts many well-known and stable data providers. In most cases, it is not necessary to add a new data provider. Data providers are typically added for custom solutions.

•      Data providers handle queries, parsing connection strings, and other connection-specific logic. This functionality is not part of Excel Services. Excel Services cannot control how data providers behave.

Authentication to external data

Data servers require that a user be authenticated. Authentication is essentially the act of telling the server who you are. The next step is authorization. Authorization is essentially the act of telling the server what you can do. Authentication is required to enable the data server to perform authorization, or to enforce security restrictions that prevent data from being exposed to anyone other than authorized users.

Excel Services needs to tell the data source who is requesting the data. In most scenarios, this is going to be the user who is viewing an Excel report in a browser. Essentially, the purpose of this article is to explain authentication between Excel Services and an external data source. Authentication at this level is shown in the following diagram. The arrow on the right depicts the authentication link from an application server running Excel Calculation Services to an external data source.

There are many ways to implement authentication, but this article is going to focus on the three methods that apply to Excel Services:

•      Windows authentication

•      SSO

•      None

Excel Services determines the type of authentication based on a property of the connection. This property must be explicitly set, and can be set by using Office Excel 2007 client. If the authentication type is missing, the default of Windows authentication is attempted. For more information, see Specifying the server authentication for an existing connection.

Windows authentication

This method uses your Windows user identity to authenticate against a data source. For the scope of this article it is not important to know the specific mechanism that the operating system uses to do this (such as NTLM or constrained delegation). What is important to understand is that Windows authentication is considered to be the most secure way to access external data, and is typically the default method for external data access when using an Excel client to connect to data sources, such as SQL Server 2005 Analysis Services.

In most enterprise environments, Excel Services will be set up as part of a farm with the front-end Web server, back-end Excel Calculation Services server, and data source, all running on different computers, as depicted in the diagram in Authentication to external data. This means that delegation, or Kerberos, (constrained delegation is recommended) will be required to allow data connections that use Windows authentication. This is because delegation is required to ensure that user identities can be communicated from computer to computer in a trusted and secure way. In a farm deployment, these kinds of connections will not work on Excel Services unless Kerberos is correctly configured.

SSO

Single sign-on (SSO) is a centralized database that is commonly used to store credentials (a user ID and password pair) that can be used by applications to authenticate to other applications. In this case, Excel Services relies on SSO to store and retrieve credentials for use in authenticating to external data sources.

Each SSO entry contains an application ID that serves as a lookup that is used to retrieve the appropriate set of credentials. Each application ID can have permissions applied so that only specific users or groups can access the credentials that are stored for that application ID.

Given an application ID, Excel Services will retrieve the credentials from the SSO database on behalf of the user who is accessing the workbook (either through the browser or Excel Web Services). Excel Services will then use those credentials to authenticate to the data source and retrieve data.

Note:

The application ID must be explicitly set for the connection. For information on how to specify an application ID, see Specifying the server authentication for an existing connection.

None

This authentication method simply means that no credential retrieval should take place or that no special action is taken for authentication for the connection. For example, Excel Services should not try to delegate credentials, and should not try to retrieve credentials from the SSO database. In these cases, Excel Services should simply hand the connection string to the data provider and allow the provider to worry about how to authenticate.

In more practical terms, this means that typically a connection string will specify a user name and password that should be used to connect to the data source. However, sometimes the connection string might specify that the integrated security be used. That is, the Windows identity of the user or computer that is issuing the request should be used to connect to the data source. In these cases, the data source will not be connected to as Excel Services, but will instead be connected to as the unattended account. For more information, see Unattended account.

Data connection libraries and managed connections

A data connection library is a new type of list added to Office SharePoint Server 2007. This is a SharePoint list that is designed to store connection files, which can then be referenced by 2007 Office system applications, such as Office Excel 2007.

Data connection libraries give customers the ability to centrally manage, secure, store, and reuse data connections.

Reusing connections

Because the data connection library is in a well-known place in Office SharePoint Server 2007 and displays friendly business names and descriptions, people can reuse connections that other people create or configure. A knowledgeable information worker or data expert can create connections, and other people can reuse them without having to understand the details about data providers, server names, or authentication. The location of the data connection library even can be published to Office clients so the data connections will be displayed right in Excel or in any other client application that makes use of the data connection library. For more information, see Creating a data connection library.

Managing connections

Because workbooks contain a link to the file in a data connection library, if something about the connection changes (such as a server name or an SSO application ID), only a single connection file needs to be updated as opposed to hundreds of workbooks. The workbooks will pick up the connection changes automatically the next time they use that connection file to refresh from Excel or on Excel Services.

Securing connections

The data connection library is a SharePoint list and supports all the permissions that Office SharePoint Server 2007 does, including per-folder and per-item permissions. The advantage that this provides on the server is that a data connection library can become a locked-down data connection store that is highly controlled. Many users might have read-only access to it so that they can use the data connections, but they can be prevented from adding new connections. By using access control lists (ACLs) with the data connection library, and allowing only trusted authors to upload connections, the data connection library becomes a store of trusted connections. Trusted connections are connections that are known not to contain malicious queries.

Excel Services can be configured to load connection files only from data connection libraries that are explicitly trusted by the server administrator, and to block loading of any embedded connections. In this configuration, Excel Services uses the data connection library to apply another layer of security around data connections.

Data connection libraries can even be used in conjunction with the new Viewer role in Office SharePoint Server 2007 that will allow those connections to be used to refresh workbooks loaded on Excel Services. If the Viewer role is applied, users cannot access the connection file contents from a client application, such as Excel. Therefore, the connection file contents are protected but can still be used for workbooks refreshed on the server.

Excel Services security and external data

Excel Services has many layers of security. The following subsections address only the concepts that are directly relevant to external data access.

Trusted file locations

Excel Services will only load workbooks from trusted file locations. A trusted file location is essentially a directory (that might include all subdirectories) that the administrator has explicitly allowed workbooks to be loaded from. These directories are added to a list that is internal to Excel Services. This list is known as the trusted file locations list.

Trusted locations might specify a set of restrictions for workbooks loaded from them. All workbooks loaded from a trusted location will adhere to the settings for that trusted location. Here is a short list of the trusted location settings that affect external data:

•      How external data can be accessed. The options for this include:

•      No data access allowed (default).

•      Only connection files in a Office SharePoint Server 2007 data connection library can be used.

•      Connections embedded in workbooks are allowed in addition to connection files from a data connection library.

•      Whether to show the query refresh warnings or not.

•      Whether to fail the workbook load if external data fails to refresh when the workbook opens. This is used in scenarios where the workbook has cached data results that will change depending on the identity of the user viewing the workbook. The goal is to hide these cached results, and ensure that any user who views the workbook can see only the data that is specific to them. In this case, the workbook will attempt to refresh on open. You can set refresh on open for each connection. If the refresh fails, the workbook is not displayed to users who cannot open it in Excel client.

Note:

This only works if the workbook is locked down by Viewer role permissions in Office SharePoint Server 2007, because a user who can open the workbook directly in Excel can always see the cached data results.

•      External data cache expiration times. Data is shared among many users on the server to improve scale and performance, and these cache life times are adjustable. This accommodates scenarios where query execution should be kept to a minimum because the query might take a long time to execute. In these scenarios, the data often changes only daily, weekly, or monthly as opposed to by the minute or every hour.

Trusted data connection libraries

As with workbook files, Excel Services will only load connection files from Office SharePoint Server 2007 trusted data connection libraries. A trusted data connection library is a library that the server administrator has explicitly added to an internal trusted list. For information about how data connection libraries allow an administrator to secure and manage connection files, see Data connection libraries and managed connections. For information about how to trust a data connection library for use with Excel Services, see Trusting a data connection library on Excel Services.

Trusted data providers

Excel Services will only use external data providers that are added to an internal trusted providers list. This is a security mechanism that prevents the server from using providers that the administrator does not trust. For information about how to trust a data provider, see Adding a trusted data provider for Excel Services.

Unattended account

The unattended account is a special account that Excel Services impersonates any time it is attempting to authenticate to a data source that is not using Integrated Windows authentication. Because Excel Services has no control over the data provider, and does not directly parse provider-specific connection strings, it needs to mitigate security threats whereby the identity of Excel Services itself can be used to connect to a data source. The unattended account is used to mitigate such threats.

Excel Services will often run with a highly privileged account, and this level of privilege is not appropriate for end users who are trying to only view data. When external data authentication is set to either None or SSO, where the SSO application ID is not storing Windows credentials, the unattended account is impersonated before attempting to connect to data. Because the unattended account is not expected to have privileges to the data source, this will prevent accidental or malicious connections to data sources in the context of a privileged account.

If the unattended account has access to the data source (when authentication type is set to None), a connection will be successfully established by using the credentials of the unattended service account. Use caution when designing solutions that purposely use this account to connect to data. This is a single account that can potentially be used by every workbook on the server. Any user loading a workbook on Excel Services and setting the authentication type to None might be able to view that data by using the server. In some scenarios, this might be needed. However, SSO is the preferred solution for managing passwords on a per-user or per-group basis.

Trusted subsystem and delegation

When Excel Services is deployed, the method that is used to communicate among the different server farm components is specified. It is configured in either trusted subsystem mode or delegation mode. This mode can be changed only by using the Stsadm.exe command-line tool.

Trusted subsystem (default in a farm deployment) is a mode in which the front-end and back-end server components have a two-way trust. This allows files to be retrieved from Office SharePoint Server 2007 by using the Excel Services account. However, even though Excel Services retrieves the files, it performs a security check to verify that the user requesting the file has the appropriate permissions. In this mode, the back-end Excel Calculation Services server does know the user's identity, but does not have a full user security token and so cannot delegate it to other computers.

Delegation (default in single computer or evaluator deployment) is a mode in which the front-end servers of the farm always delegate the user's identity to the back-end servers. In this case, files are retrieved as the end user who is requesting the workbook instead of the Excel Services account. The back-end Excel Calculation Services server has the user's full identity (security token) and so can delegate it to other servers.

Note:

In delegation mode, the back-end Excel Calculation Services server can delegate to any computers that are on the same server, but delegation to other computers that reside on a different server requires Kerberos to be configured.

Connections that use Windows authentication will only work when Excel Services is deployed in delegation mode. This is because when the server is in trusted subsystem mode, the back-end calculation component of the application server does not have the end user's (the person viewing the workbooks) full security token and so it cannot delegate the identity to the data source.

Step-by-step server configuration for external data

This section gives step by step instructions for performing basic configuration on the server side to enable external data connectivity. This includes configuration of all the Office Server components that are required for Excel Services to refresh external data, and therefore covers more than just Excel Services administration.

This section references the SharePoint Central Administration Web site and Shared Services Provider (SSP) administration. This section also contains the instructions for launching those consoles. To complete these steps, you will need access to Central Administration and SSP administration, respectively.

Access the Central Administration console

1.   On the taskbar, click Start, point to All Programs, point to Microsoft Office Server, and then click SharePoint 3.0 Central Administration.

Access the SSP administration console

1.   From the Central Administration console, perform either of the following procedures:

2.   Select the name of the SSP from the left-hand navigation bar. For example, SharedServices1 as shown in the following figure.

3.   In the top navigation bar, click the Application Management tab.

a.   On the Application Management page, click Create or configure this farm's shared services.

b.   On the Create or Configure this Farm's Shared Services page, select the name of the SSP.

Adding a trusted data provider for Excel Services

Excel Services will only attempt to process connections that use trusted data providers. For most common types of data connections (such as ODBC, OLEDB, SQL Server, and OLAP), it is not necessary to add a provider because by default Excel Services trusts many standard providers. Providers are typically only added for very custom solutions. For more information, see Data providers.

Add a new provider for use with Excel Services

1.   Ensure that the data provider is installed on each server in the farm. This is specific to the data provider being used and is beyond the scope of this article.

2.   Launch the SSP administration console. For more information, see Step-by-step server configuration for external data.

3.   In the Excel Services Settings section, click Trusted data providers, as shown in the following figure.

4.   On the Excel Services Trusted Data Providers page, click Add Trusted Data Provider.

5.   Fill in the values for the Provider ID, Provider Type, and description, as shown in the following figure.

6.   Click OK.

Note:

The ID that is in the Provider ID should be used in the connection strings that this provider generates.

Allowing external data for Excel services

External data must be explicitly enabled per trusted file location.

Enable external data access for a trusted file location

1.   Launch the SSP administration console. For more information, see Step-by-step server configuration for external data.

2.   In the Excel Services Settings section, click Trusted file locations, as shown in the following figure.

3.   On the Excel Services Trusted File Locations page, select the name of the trusted file location that you are attempting to load workbooks from, or click the Add Trusted File Location to create a new one, as shown in the following figure.

4.   On the details page for the trusted file location, scroll down to the External Data section, as shown in the following figure.

5.   Select the Trusted data connection libraries only option button to allow access to connection files in a data connection library. Or, select the Trusted data connection libraries and embedded option button to enable connections embedded in a workbook and connections from a data connection library. This is also the location where you can toggle other external data settings that affect the server, such as refresh warnings, data cache time-outs, and so on.

Setting the unattended account

The unattended account is required to enable connections that have their authentication set to either None or SSO where the SSO application ID is not using Windows credentials. For more information on the unattended account, see Unattended account. If these types of connections will not be used, the unattended account does not need to be configured.

Configure the unattended account settings

1.   Launch the SSP administration console. For more information, see Step-by-step server configuration for external data.

2.   On the Shared Services home page, in the Excel Services Settings section, click Edit Excel Services settings, as shown in the following figure.

3.   On the Edit Excel Services Settings page, scroll down to the Unattended Service Account section. Enter the domain user name and password of the account you want to use, as shown in the following figure.

4.   Click OK.

Configuring Office Server single sign-on

SSO enables middle-tier application servers to store and retrieve user credentials. The key to credential retrieval is the application ID.

Application IDs are used to map users to credential sets. This mapping is available for groups and individuals. A group mapping means that every user that is a member of a specific domain group is mapped to the same set of credentials. Group mappings are best for scale and performance on Excel Services because they allow external data cache sharing. Individual mappings map each individual user to that user's own set of credentials.

Office SharePoint Server 2007 can support any SSO provider that implements the pluggable Office SharePoint Server 2007 SSO interface. Office Server ships with its own version of SSO, referred to Office SharePoint SSO. This section only deals with the configuration of Office SharePoint SSO, and does not cover any third-party SSO provider configuration in any detail.

If the user needs more SSO functionality beyond what Office SharePoint SSO provides, another SSO provider can be used.

Note:

Microsoft also ships a new version of Enterprise Single Sign-On (EntSSO) with Microsoft Host Integration Server and Microsoft BizTalk Server. EntSSO is not supported by Excel Services. EntSSO provides more functionality, such as application IDs that support multiple group mappings, administration of application IDs on a per-application ID basis, and functionality that helps populate and update passwords that are stored in the SSO database.

This section is not intended to be a comprehensive guide on everything a user can do by using SSO. It is only intended to give the basic steps, under common configurations, to get Office SharePoint SSO successfully configured on the server so that it is ready to be used for refreshing data on Excel Services.

Start the Microsoft Single Sign-On service on the server

The Microsoft Single Sign-On service should be started on each server in the farm.

Start the Single Sign-On service

1.   From Administrative Tools, click Services.

2.   Double-click Microsoft Single Sign-On Service to launch the Single Sign-On Service Properties page, as shown in the following figure.

3.   On the General tab of the Single Sign-On Service Properties page, set the startup type to Automatic.

4.   On the Log On tab of the Single Sign-On Service Properties page, click This account, and then type the domain account that you want to run the service as, as shown in the following figure.

Note:

For most evaluator or demonstration deployments, such as a single-click installation, it is easiest to use the same credentials as the account that was used to install Office Server. For more information about account requirements for installing SSO, see More on Office Server SSO accounts and privileges.

5.   Click Apply.

6.   On the General tab of the Single Sign-On Service Properties page, click Start to start the service, and then click OK.

Configuring SSO on Office Server

SSO must be configured so that application IDs and passwords can be added. For information on how to configure application IDs, see Creating a new application ID in SSO.

Configure SSO on Office Server

1.   Launch the Central Administration console. For more information, see Step-by-step server configuration for external data.

2.   On the Operations tab, in the Security Configuration section, select Manage settings for single sign-on, as shown in the following figure.

3.   From the Manage Settings for Single Sign-On page, select Manage server settings, as shown in the following figure.

4.   From the Manage Server Settings for Single Sign-On page, enter the credentials of the SSO administrator account and the Enterprise Application Definition administrator account.

Note:

The Enterprise Application Definition administrator account is used for management of application IDs and passwords in SSO. For most configurations, the account that was used to install the server can be used for both of the SSO administrator account, and the Enterprise Application Definition administrator account. For more information on accounts used to set up SSO, see More on Office Server SSO accounts and privileges.

5.   Accept the default database and time-out settings. Click OK to save and close the page.

More on Office Server SSO accounts and privileges

This section provides more detail about the specific memberships, rights, and privileges of the different accounts that are used to configure Office Server SSO. This does not necessarily apply to any third-party pluggable SSO providers.

For evaluation or demonstration purposes, the account that was used to install Office Server can be used to configure SSO. This is the simplest configuration. However, in a production or enterprise deployment, it is considered more secure to ensure the SSO administrator and service account is different from the account that was used to install the server.

•      SSO service account   The user that the SSO service account is running as must be a member of the WSS_Admin_WPG group on the local machine, and it must be a domain account.

•      SSO administrator account   This can be any domain group or user account. The user who is setting the SSO administrator account must be a member of the domain group that the SSO administrator account is getting set to. Or, if an individual account is being used as the SSO administrator account, it must be the account of the current user.

When Excel Services is configured in a trusted subsystem mode, the SSP application pool account must be a member of the SSO administrator group. (For more information, see Trusted subsystem and delegation.) This enables SSO ticketing, which Excel Services uses in such configurations, to work. The SSP application pool account is the security account that is used to run the shared services application pool in IIS.

•      SSO Application Manager account   This can be any domain group or individual user account. Accounts that are added as SSO Application Managers must have at least Read access to the Central Administrator site, as this is the site where the SSO accounts are managed from.

•      SSO configuration account   This section addresses the requirements of the account that is being used to configure SSO. The account being used to setup and configure SSO must:

•      Be a local administrator of the server that stores the master key used for password encryption/decryption. This server is also referred to as the "secret server."

•      Be a member of the following SQL Server roles on the SQL Server computer that stores the SSO passwords: Security Admin, Server Admin, and Db Creator.

•      Be an Office Server farm administrator. This allows the user to write to the Office SharePoint Server 2007 configuration database during SSO configuration.

•      Be a member of the SSO administrator group that is set during SSO configuration.

•      Have the ability to log on to the console of the server where SSO is going to be configured.

Example of SSO accounts and privileges

An administrator named Bob uses the domain account, CORPDOMAIN\ServerAdmin, to install Office SharePoint Server 2007. This account is an administrator account on every server in the farm, and also has Office Server farm administrative rights. Bob logs on to the computer by using the CORPDOMAIN\ServerAdmin account. Bob adds the account, CORPDOMAIN\ServerService, to the WSS_Admin_WPG group on each computer. Bob starts the Single Sign-On service on each computer, running the service as CORPDOMAIN\ServerService.

Bob then launches the Central Administration console to configure SSO. Bob sets the domain group CORPDOMAIN\OfficeServerAdmins to be both the SSO administrator account and the SSO application manager account. The CORPDOMIAN\ServerAdmin account, which Bob is using for this configuration, is a member of the domain group CORPDOMAIN\OfficeServerAdmins. Bob goes to the SSP administration pages to double-check the account that the SSP is running as. He sees that the SSP is running as CORPDOMAIN\SharedServiceAdmin. Bob knows that for Excel Services to work, CORPDOMAIN\SharedServiceAdmin must have rights as an SSO administrator. CORPDOMAIN\SharedServiceAdmin is a member of the domain group CORPDOMAIN\OfficeServerAdmins, which was the group used as the SSO administrator. After configuring the rest of the server and Excel Services, Bob sees that Excel Services can use SSO for external data refresh.

Creating a new application ID in SSO

Create a new application ID in SSO

1.   Launch the Central Administration console. For more information, see Step-by-step server configuration for external data.

2.   On the Operations tab, in the Security Configuration section, select Manage settings for single sign-on.

3.   From the Manage Settings for Single Sign-On page, select Manage settings for enterprise application definitions, as shown in the following figure.

4.   From the Manage Enterprise Application Definitions page, click New Item from the toolbar to create a new application ID.

5.   Enter the values for the new application. The application name is what users must enter as the SSO application ID into their data connections in Excel client when configuring the connection to work on the server. Typically, the Display name and the Application name should be the same.

6.   Enter the e-mail address of the user or group that will be managing this application definition.

7.   Select the Account type.

a.   Select Group if all users of a specific group should be mapped to a single set of credentials. You will get a chance to define the domain group to map from later.

b.   Select Individual if every user should be mapped to a unique set of credentials.

Note:

Do not choose Group using restricted account. This is not supported by Excel Services.

8.   In the Authentication type section, select the Windows authentication check box if the credentials you plan to store for this application ID will be Windows domain credentials.

Note:

For Excel Services scenarios, because this SSO entry will store user name and passwords, the Field values under the Logon Account Information at the bottom of the page do not need to be altered.

9.   If appropriate, configure the settings for an application that uses a group mapping and stores Windows credentials, as shown in the following figure. This will be a common configuration when retrieving from an OLAP source, such as SQL Server 2005 Analysis Services.

10.  Click OK at the bottom of the page to save the application definition.

11.  In the Manage Settings for Single Sign-On page, click Manage account information for enterprise applications, as shown in the following figure.

12.  From the Manage Account Information for Enterprise Applications page, you can control which accounts can access the credentials stored for an application ID, and manage the actual credentials that are stored for an application ID.

13.  From the Enterprise application definition drop-down list, select the application ID that you entered in the last step, as shown in the following figure.

14.  In the Group account name text box, enter the group that should be granted access to the credentials stored for this application ID. This is not the account that is used to access the data source, this is simply the domain group or user account that should map to the credentials that are actually used to authenticate to the data source.

Note:

If every user in the domain should be allowed to access these credentials, enter DOMAIN\domain users in this text box.

15.  Ensure the Update account information option button is selected, and click the Set button.

16.  The account information page will launch. Enter the user name and password of the account that should be stored in SSO, as shown in the following figure. This is the account that is used by Excel Services to access the data source. After you have typed the credentials, click OK.

Note:

If the password is left blank when the SSO credentials are Windows credentials, Excel Services will attempt to use Protocol Transitioning on behalf of the end user to connect to the data source. Protocol Transitioning is beyond the scope of this article.

17.  You will be returned to the page for managing account information. You can close the browser or click Done to return to the SSO administration home page.

Creating a data connection library

The data connection library is a list template in Office SharePoint Server 2007. It can be created almost anywhere a list can be created in Office SharePoint Server 2007.

Note:

The Report Center site already has a data connection library created by default, and serves as a convenient place to manage all the data connections that are used by reports in that site.

Add a data connection library to an existing SharePoint site

1.   From a SharePoint site, click View All Site Content from the left navigation bar for the site, as shown in the following figure.

2.   Click the Create button near the top of the page, as shown in the following figure.

3.   On the next page, in the Libraries section, select Data Connection Library, as shown in the following figure.

4.   On the next page, enter a name for the data connection library and optional description, as shown in the following figure.

5.   Click Create.

Trusting a data connection library on Excel Services

Before connection files can be used by Excel Services, the data connection library must be explicitly added to the internal trusted data connection libraries list.

Add a data connection library to trusted list

1.   Launch the SSP administration console. For more information, see Step-by-step server configuration for external data.

2.   In the Excel Services Settings section, select Trusted data connection libraries.

3.   On the Excel Services Trusted Data Connection Libraries page, enter the URL of the data connection library and enter an optional description, as shown in the following figure.

Note:

The URL must connect directly to the data connection library, as shown in the previous figure. The URL cannot connect to the forms directory or to the default aspx page. If you copy a link to a data connection library directly from your browser, you must delete any /forms or /default.aspx strings from the URL.

1.   Click OK.

Exposing the data connection library in the Office client

To make discovery and reuse of connections easier, the data connection libraries can be surfaced in the data connections UI in the Office client (currently displays in Office Excel 2007 and Microsoft Office Visio 2007). This allows users to choose a connection from the data connection library, based on friendly name and description, inline as part of the document authoring experience.

To enable data connection libraries to display directly in the client application, the data connection library must be published from the server to the client computer. The client computer must be associated with that server, or a registry key must be set directly.

Publishing the data connection library to the Office client

Publish the data connection library to the Office client

1.   Launch the SSP administration console. For more information, see Step-by-step server configuration for external data.

2.   In the User Profiles and My Sites section, click Published links to Office client applications, as shown in the following figure.

3.   On the Published Links to Office Client Applications page, click New.

4.   Enter the URL to the data connection library.

Note:

The URL must be directly to the data connection library, as shown in the image and not to the forms directory or the default aspx page. If you copy a link to a data connection library directly from your browser, you must delete any /forms or /default.aspx strings from the URL.

5.   Choose Data Connection Library from the Type drop-down list, as shown in the following figure.

6.   Click OK.

Note:

If Audience Targeting is used, only the users that are members of the specified SharePoint audience will receive the link to the data connection library. By default, if Audience Targeting is not used, all users will receive the link to the data connection library if they have permissions to view the data connection library.

Associating the client computer with the server

To enable the client computer to receive the published list of data connection libraries, it must first be associated with the portal server. This can be done by having My Site enabled, and by having a default My Site set.

Note:

In most real-world deployments, this is already done and in those cases, no action needs to be taken here.

Enable My Site

1.   Launch the Central Administration console. For more information, see Step-by-step server configuration for external data.

2.   In the top navigation bar, click the Application Management tab.

3.   On the Application Management page, in the Application Security section, click Self-service site management, as shown in the following figure.

4.   From the Self-Service Site Management page, select a Web application (the default is acceptable in most deployments), and click On, as shown in the following figure.

5.   Click OK.

Setting My Site as the default should be done by the end user who will be reusing connections from a data connection library.

Set My Site as the default

1.   Navigate to the portal, and click My Site on the top right part of the toolbar, as shown in the following figure.

2.   From the My Site page, select Set as default My Site from the top right of the page, as shown in the following figure.

3.   Click OK to the dialog box that launches.

Note:

The default My Site setting can be propagated to other servers for that user via Active Directory.

Setting a registry key to surface a data connection library in the client

This section contains steps that detail how to create a registry key that will cause a data connection library, or any other HTTP or UNC location, to surface in the connection UI.

Create a registry key to surface a data connection library

1.   On the taskbar, click Start, and then click Run. Type regedit, and then press ENTER, as shown in the following figure.

2.   Navigate to the folder at HKEY_CURRENT_USER\Software\Microsoft\Office\12.0\Common\Server Links\Published.

3.   If the Published folder does not exist, you will need to create it. In this case, right-click the Server Links folder and select New Key, as shown I the following figure. Name the Key Published.

4.   Create a new string value for the Published folder by right-clicking inside the folder and selecting New String value, as shown in the following figure.

5.   Name the string the friendly name of the data connection library.

6.   Right-click the string value, and select Modify, as shown in the following figure.

7.   Enter the HTTP path to the data connection library in the Edit String dialog box, as shown in the following figure.

8.   Click OK.

Step-by-step workbook configuration for external data

This section covers the common options that need to be configured from the Excel client to allow a workbook to refresh external data when loaded on Excel Services. This section also covers reusing connections from a data connection library, as well as exporting connections to a data connection library.

Creating a new connection

The simplest way to create a new data connection in an Excel workbook is to use the Data Connection Wizard. This wizard also allows you to configure the authentication options for Excel Services. The Data Connection Wizard produces .odc files, which are linked from the workbook, as described in Embedded and linked connections.

Create a new connection

1.   In Excel, on the Data tab, in the Get External Data section, select From Other Sources, select From Data Connection Wizard from the drop-down list, as shown in the following figure.

2.   Walk through each screen of the wizard, making appropriate choices for your data source. On the last screen of the wizard, click the Authentication Settings button, as shown in the following figure.

3.   On the Authentication dialog box, select the option button that corresponds to your authentication choice. The types of authentication are described in Authentication to external data, and are shown in the following figure.

4.   Click OK to close the Authentication dialog box, and then click Finish to end the wizard.

Note:

This wizard produces an .odc file, and can save this file directly to a data connection library. To do this, choose the browse button on the last screen of the wizard, and type the HTTP path to the data connection library in the corresponding file dialog. When the file is in the data connection library, others can reuse it.

Reusing an existing connection from a data connection library

If a data connection library is populated with connection files and is exposed to the Office client, connections from it can be reused directly from within Excel. For more information, see Exposing the data connection library in the Office client.

Reuse an existing connection

1.   From the Excel Data ribbon, select Existing Connections, as shown in the following figure.

The DCL folder is shown under the Connection Files on the Network section of the Existing Connections dialog box, as shown in the following exhibit.

2.   Each data connection library will have a separate folder. Double-click the folder for a data connection library to see the connections that are stored there, as shown in the following figure.

3.   Select the connection that you want to use, and then click Open.

4.   In the Import Data dialog box, select how you want to view your data in Excel, as shown in the following figure.

Note:

The Table option is not supported in Excel Services. If it is chosen, that workbook will not load in Excel Services.

Specifying the server authentication for an existing connection

This section illustrates how to set the server authentication for connections that were previously created in an Excel workbook. For information about creating a new connection, see Creating a new connection.

Specify the server authentication

1.   From the Excel Data ribbon, in the Connections section, click Connections, as shown in the following figure.

2.   In the Workbook Connections dialog box, which shows all the external data connections that are currently being used by the workbook, select the connection that needs to be changed, and then click Properties, as shown in the following figure.

3.   In the Connection Properties dialog box, which allows many properties of the connection to be changed, including the refresh on open setting, choose the Definition tab, as shown in the following figure.

4.   Click the Authentication Settings button.

5.   From the Excel Services Authentication dialog box, select the option button that corresponds to the preferred authentication type, as shown in the following figure. For more information about authentication types, see Authentication to external data.

6.   Click OK to close the Excel Services Authentication dialog box, and click OK out of the workbook connections and properties dialogs.

Saving an existing connection to a data connection library

Save an existing connection

1.   In the Connection Properties dialog box, on the Definition tab, click Export Connection File, as shown in the following figure.

2.   In the File dialog box, enter the HTTP path to the data connection library, and then click Save. When an .odc file is exported in this manner, the workbook connection becomes linked to that .odc file, as described in Connections and Excel workbooks.

More about the properties on the Definition tab

The Definition tab on the Connection Properties dialog box has other properties that can affect how connections are used and behave on both the client computer and the server. All of these properties are persisted in the .odc file, which is generated by clicking Export Connection File, and will be inherited by any workbook that later uses that .odc file.

These settings are respected in both Excel client and Excel Services. This section contains notes on how two of the most important properties affect connections across client computer and server. For more information about the high-level behavior of both of these settings, see Connections and Excel workbooks.

•      Connection file   This is the path to the connection file that this workbook connection maintains a link to. To change to a different connection file, choose the browse button and enter a path to a new connection file.

Note:

Changing any settings on the Definition tab of the Connection Properties dialog box will break the link to the connection file because the copy of the connection in the workbook will no longer be an exact replica of the connection file.

•      Always use connection file   This specifies whether to use the embedded copy of the connection first, or whether to always use the contents of the linked connection file to refresh data. If this check box is selected, the embedded copy of the connection information is always ignored, regardless of whether the connection file connection is successful.

Frequently asked questions

How do I get Microsoft Access data into my workbooks on Excel Services?

Workbooks that refresh data from an Access database are not supported with the features that come with Excel Services. This is because these types of solutions have problems scaling and performing in an enterprise server environment. Although it might be possible to make this work by adding the right provider to the trusted providers list and installing any required Data Source Name (DSN) files on the server, it is not supported.

How do I use other workbooks as data sources on Excel Services?

This is not supported in this version of Excel Services. Linked workbooks are an unsupported feature, and those workbooks will fail to load on the server. You might consider moving the data from the linked workbooks into a single workbook. An alternate approach is to use a user-defined function (UDF) to fetch data from a different workbook.

Why don't my Windows authentication connections work even when I have correctly configured Kerberos in my farm?

This is happening either because the user who is viewing the workbook does not have correct permissions on the data source, or because the server's Access Model was configured as a trusted subsystem. In the trusted subsystem mode, Windows authentication style connections fail automatically as the back-end calculation server does not have the full identity (security token) of the user and therefore cannot delegate to the data source.

If the credentials are not delegated, how can Excel Services make per-user permission checks on files?

Even if the Access Model is a trusted subsystem, Excel Services can still do per-user permissions checks on files stored in Office SharePoint Server 2007. Excel Services is part of Office SharePoint Server 2007, and so it is trusted to do per-user permission checks even when it cannot delegate an end user's identity; however, it does not affect how Excel Services connects to external data.

In these topologies, as described in the previous paragraph, Windows authentication–type connections do not work because the back-end application server cannot delegate the workbook viewer's identity.

What is the guidance around using local cubes on the server?

Local cubes for SQL Server 2005 Analysis Services are not supported by Excel Services. These local cubes do not scale well in an enterprise production environment because they were not designed to meet the demands of many users refreshing data immediately. It is not recommended to use these with Excel Services.

How can I have more control over how external data is accessed from the server?

Trusted file locations allow a granular level of control over how workbooks behave on the server, including how they refresh external data. When a user loads a workbook on Excel Services, the workbook trusted location is resolved to the deepest level. For example, if a workbook is loaded from http://server/site/doc%20lib/, and a set of trusted location rules exists for http://server, and a different set exists for http://server/site/doc%20lib, the rules from the latter will be applied. This makes it possible to enable scenarios where a particular set of security restrictions are applied at a very wide, or very granular, level.

For example, the entire portal can be added as a trusted location (http://server or http://).

Note:

You must select the Include Children check box to allow workbook loading from all subdirectories. You might choose to configure the trusted location settings at this level to always show data warnings, and only allow refresh by using data connection libraries. Workbooks stored in a more secure document library might be enabled to load any data connections (data connection library or embedded). The external data cache time-out values might be extremely high because workbooks in this document library take a long time to refresh data and data is not updated very often.

Administrators are encouraged to add trusted file locations, and change what is allowed for each, in a way that fits their particular security requirements.

What factors should I consider regarding performance and external data?

There are a number of considerations to take into account when designing external data access from Excel Services.

•      Excel Services shares data caches in the middle tier. The cache is shared when the connections are identical, and the credentials used to connect to the data source are the same. This ensures that users have rights to the same data. This means that Excel Services scales better when the same credentials are used by many users to connect to data. SSO group mappings, None where a user name/password are saved in a connection string, or None where the unattended account is used are all good authentication types for these cases. (Although it should be noted that SSO is the best option here from a security point of view.)

•      For SQL Server 2005 Analysis Services and later, data caches can be shared even if individual SSO or Windows credentials are used. This is an optimization that only applies to SQL Server 2005 Analysis Services or later, and it only applies if the users are members of the same groups on Analysis Services, and if there are not any cube calculations or security that relies on an individual user's identity.

•      Increase external data cache lifetimes where it makes sense. If a workbook takes a particularly long time to refresh data due to the size of a query, consider increasing the data cache timeout for that trusted location.

•      Disable interactivity in the dashboard for OLAP PivotTable reports. When users interact with OLAP-based PivotTable reports, new queries are issued against the back-end data source for that user's session. In this case, that user will stop sharing the data cache. Consider publishing the workbook so that the view of the data is appropriate for most users, and disabling interactivity where it makes sense to do so.

How can I secure my data so that it is viewable only from a workbook published to Excel Services?

Excel Services takes advantage of the View Only permission set in Office SharePoint Server 2007. All users who are added to the Viewers group in Office SharePoint Server 2007 get this level of permissions by default. This only applies to files loaded from Office SharePoint Server 2007 when the trusted file location is set to be of type SharePoint.

Users who have View Only permissions have the right to load, render, interact, refresh, recalculate, and take snapshots of workbooks that are loaded on Excel Services. These users cannot access the actual file source, or contents, of the workbook directly. This means that they cannot download or save the workbook, open it directly in Excel, or access the file contents through any method other than Excel Services. This is the prescribed way to secure, "one version of the truth" workbooks.

In this case, users can see only the parts of the workbook that are marked as "Viewable on the Server," by the workbook author who uses the Publish to Excel Services feature in Excel client. By publishing the correct parts of the workbook and securing the workbook with View Only permissions, the workbook author can ensure that no data or proprietary information from the workbook is exposed when it should not be.

In cases where users are allowed to download the source of the workbook, and that user does not have direct access to the data source, if the data connection uses SSO or the unattended account to refresh on the server, the user cannot refresh that connection from Excel client. This is because Excel client cannot use the server's unattended account or SSO to refresh connections directly. The workbook author should take care in these cases to remove any cached data from the workbook, or ensure that any cached data in the workbook is allowed to be viewed by all users who might open the workbook in Excel client.

I followed the instructions in this article, but when I load my workbook on the server I see some unsupported features error talking about Query Tables. How can I fix it?

When authoring a workbook, and bringing the external data into a workbook for the first time, you are presented with an Import Data dialog box, as shown in the following figure, with choices on how to visualize the data.

When you select Table from this dialog box, a Query Table is created. These structures are not supported in Excel Services, and the workbook will not load on the server. To correct this, delete the table from the workbook. Reconnect to data, and select PivotTable Report next time.

A PivotTable report can be made to look a lot like a Query Table by using the PivotTable Tools, Design tab, from the ribbon. Try turning off Subtotals, Grand totals, and drill indicators. Then choose Tabular form for the report layout.

Another option, which requires custom code, is to use a UDF to retrieve the data, and return it to the workbook as a table. This can be rendered, loaded, and refreshed on Excel Services. This is beyond the scope of this article.

I have an ODBC connection, and therefore I do not have an .odc file. How can I use my connection with a data connection library so that it will work on Excel Services?

Excel Services works only with .odc files. If you have a connection in a workbook that you want to save to a data connection library and have work with Excel Services, you will need to export that connection as an .odc file. The Export Connection File command from the Connection Properties dialog box described in Specifying the server authentication for an existing connection can be used to do this as it always exports .odc files.

How do View Only permissions and .odc files in a data connection library work?

View Only permissions grant users the right to use an Excel file on Excel Services, but not from any other client application — not even Excel. The .odc files work the same way. If a workbook uses an .odc file to refresh data, the server copy of that workbook will correctly refresh for a user with View Only permissions to the .odc file. However, even if the user has permissions to open the workbook in Excel client, the connection will cannot use the .odc file to refresh from Excel client. The user can only make use of the .odc file by refreshing workbooks running on the server that uses the .odc file.

Typically, the user will have the same View Only permission restrictions on the workbook and the .odc file. If users are intended to open the workbook in Excel client but not the .odc file, the embedded connection in the workbook should not expose the content s of the .odc file. In this case, the embedded connection should not be a copy of the .odc file. Ensure the cached data in the workbook is not exposing data from the data source to which the .odc file points.

See Also

Excel Services (http://go.microsoft.com/fwlink/?LinkId=78464&clcid=0x409)

Excel Services Architecture (http://go.microsoft.com/fwlink/?LinkId=78465&clcid=0x409)

Plan Excel Services security (http://technet.microsoft.com/en-us/library/cc263086.aspx)

Office SharePoint Server 2007 (http://technet.microsoft.com/en-us/library/cc303422.aspx)

Determine resource requirements to support Excel Services  (http://technet.microsoft.com/en-us/library/cc263500.aspx)

Single Sign-on Overview (http://go.microsoft.com/fwlink/?LinkId=78476&clcid=0x409)

Implementing a Pluggable SSO Provider (http://go.microsoft.com/fwlink/?LinkId=78479&clcid=0x409)

Creating Custom Solutions with Excel Services (http://go.microsoft.com/fwlink/?LinkId=78480&clcid=0x409)

Kerberos Authentication in Windows Server 2003 (http://go.microsoft.com/fwlink/?LinkId=78481&clcid=0x409)

Demo: Enable Excel Services and data connections for a SharePoint team site (http://office.microsoft.com/en-us/sharepointserver/HA102078901033.aspx)

Plan for business data connections with the Business Data Catalog

In this article:

•      About the Business Data Catalog

•      Plan connections to the Business Data Catalog

•      Plan business data presentation

•      Worksheets

The Business Data Catalog is used to connect data from line-of-business applications that have managed properties used by enterprise search in Microsoft Office SharePoint Server 2007. After applications are registered in the Business Data Catalog, the business data types and properties selected by administrators can be used in SharePoint sites, SharePoint lists, and relevant business data Web Parts. These sites, lists, and Web Parts can then be used to analyze and act on business data.

The line-of-business data used by the Business Data Catalog can combine with the core business intelligence functionality of Microsoft SQL Server 2005 Analysis Services and SQL Server 2005 Reporting Services, Excel Services in Microsoft Office SharePoint Server 2007, and key performance indicators (KPIs) based on data sources in data connection libraries. The result is an integrated view of business data and business processes across your organization.

As part of planning for your initial deployment Office SharePoint Server 2007, you should understand how to connect applications to the Business Data Catalog and how to present that data in sites, lists, and Web Parts. Then, you can plan for more specific features that use business data, such as business data profiles, business data actions, reports, and dashboards. Together these plans form a comprehensive deployment plan that you can use along with planning worksheets during the initial deployment of Office SharePoint Server 2007.

About the Business Data Catalog

The Business Data Catalog is a service for registering line-of-business applications and certain business data types and properties of those applications. The Business Data Catalog is managed from the Shared Services Administration page for each Shared Services Provider (SSP). For each line-of-business application used by the Web applications and site collections of an SSP, you must first register the line-of-business application and the business data types and properties that you want to expose to users.

After registering applications in the Business Data Catalog, you can decide how to present and use the data of those applications in sites, lists, and Web Parts. Properties in the Business Data Catalog appear in business data profiles and can be used in business data lists and Web Parts, or in filter Web Parts that filter the view of business data Web Parts. These Web Parts can then be used in building SharePoint sites, including reports and dashboards, that display business data. You can find data by crawling properties of business data as part of business data content sources. As with any other crawled properties, the crawled properties of business data are mapped to managed properties for search, and those properties are used during queries to prioritize relevant search results. Properties about users can be associated with properties in user profiles imported by profile services from directory services, such as the Active Directory directory service or Lightweight Directory Access Protocol (LDAP) directory services, or added as additional properties of user profiles.

By using line-of-business data in your SharePoint sites, you can integrate data analysis from these sites with data analysis based on data connection libraries. This allows you to build knowledge about your key business processes, make decisions, and act on those decisions.

For example, a sales department for a large organization uses a line-of-business application that tracks products, sales associates, customers, sales offices, and individual sales. The SSP administrator registers the applications, along with relevant business data types for products, customers, and sales offices. For each of these business data types, the SSP administrator includes relevant properties. For example, for customers, the properties for location, address, description, and purchasing manager are included.

You can create a business data list from sales data in a data connection library, and you can add columns for properties registered in the Business Data Catalog. This list of customers and sales can then be used in business data Web Parts used by reports, so you can compare sales across customers in the Report Center site. By mapping the relevant properties to managed properties in search, someone searching for a specific location where a customer is located will find that customer near the top of search results.

Plan connections to the Business Data Catalog

Start the plan for the Business Data Catalog by considering the line-of-business applications used by your organization. Large databases and data warehouses will typically be accessed by using data connection libraries, and not the Business Data Catalog. The Business Data Catalog is the place to register line-of-business applications.

For each application, it is important to consider the following factors:

•      Properties that will be helpful in analyzing business processes and making business decisions.

•      Properties that are less relevant or contain data that you do not want to display widely in your organization.

•      Sites that will use business data, such as reports, dashboards, and personalization sites.

•      Web Parts that are used by SharePoint sites that have business data, including Business Data List Web Parts and KPI Web Parts.

•      Lists you need to build business data Web Parts.

•      Business data actions you want to create and the properties those actions are based on.

•      Properties you expect users to use when searching for business data.

The details of planning properties of business data profiles, business data lists and Web Parts, business data actions, and the properties for searching for business data are described in greater detail in other articles. When you plan for the connections to the Business Data Catalog, it is important to first focus on which applications to connect and how to make those connections.

You should consider that most users in your organization will not have direct access to the line-of-business applications. This is a good idea for several reasons. Some data might be sensitive and not all data in the application will be displayed in sites, lists, and Web Parts. You also want to limit the performance impact on the servers that host line-of-business applications. For these reasons, a common practice is to copy data in a line-of-business application to another server, and then use that location in the Business Data Catalog and business data content sources.

To further limit access to the data, it is a good idea to use a single account or a group that contains a small number of accounts both for accessing the business data in the application and for crawling the data for search. In the case of search, it is a good idea to create a crawl rule for business data applications that uses the administration account for each line-of-business application as the crawling account for each business data start address.

After applications are connected, all included business data types and properties can be used in sites, lists, and Web Parts by any users who have the appropriate permissions. Typically, site collection administrators will create a SharePoint group for viewing business data and include users who have responsibilities to analyze and act on business data. Often, users will act on business data by making business decisions that are not directly involved with the application itself. If acting on data requires changing the data in the underlying database, each user can make changes based on their permissions to the relevant database.

For business data actions that use forms hosted by InfoPath Forms Services, the proper security settings must be configured according to plans for InfoPath Forms Services, so that users who use the forms can expect the data to be updated in the underlying application and not just a duplicated location used by the Business Data Catalog.

If a duplicated location is used, it is a good idea to plan for how often the data in that location is synchronized with the line-of-business data on the application server.

After you decide who has access to data and which applications you want to register, you should consider which business data types and properties to include. The simple rule to use is that if you want users in your organization to analyze data based on a set of business data types, those business data types should be included in the Business Data Catalog.

As you plan for the initial deployment, start with the business data types that you know are most likely to be analyzed by users in your organization, based on the purpose and key business processes of your sites. Include those business data types and plan for the properties that are most likely to produce useful results. For example, for a customer service site, it makes sense to include business data types for customers and for sales associates, enabling users that have the appropriate business data permissions to view and compare sales across customers or sales associates and make business decisions based on the results.

Worksheet action

Use the Business data worksheet (http://go.microsoft.com/fwlink/?LinkID=73271&clcid=0x409) to record each connected application and the relevant business data types and properties, along with the accounts that have permission to the application server, any server that contains a copy of data that is used by the Business Data Catalog, and the accounts that are members of SharePoint groups that have access to the data in the Business Data Catalog.

For data sources based on SQL Server databases and other relational databases that will be stored in data connection libraries, record the planned data source and the relevant business data types and properties used by SQL Server 2005 Analysis Services and SQL Server 2005 Reporting Services when analyzing and displaying the data.

For more information about the business data types and properties used in the Business Data Catalog, see Plan for business data profiles.

Plan business data presentation

After you have connected line-of-business applications and the data for relevant business data types and properties to the Business Data Catalog, you can consider how you will present that data in the organization so that it can be used in data analysis, collaboration, and business decision-making.

You should consider the business data that you want for each site in your planned site structure. Based on the purpose of each planned site, you can identify the applications, business data types, and properties to use in building the business data lists and Web Parts used in each site. After you ensure that the relevant data is available in the Business Data Catalog, you can plan the relevant Web Parts and SharePoint lists used by each site.

Worksheet action

Use the Business data worksheet (http://go.microsoft.com/fwlink/?LinkID=73271&clcid=0x409) to record the KPIs, reports, and business data lists and Web Parts based on each data source, and add the properties used by each list or Web Part. For KPIs, record the planned calculation method and the targets for each indicator level of the KPI.

Use the Site creation worksheet (http://go.microsoft.com/fwlink/?LinkId=73138&clcid=0x409) to record the sites that use business data applications for your site collection hierarchy and for each site collection. Also record the business data Web Parts and SharePoint lists that are used for each site.

For more information about planning business data in personalization sites or sites that use targeted Web Parts, see Plan My Sites.

For more information about planning business data in SharePoint lists, see Plan business data lists.

For more information about planning business data Web Parts, see Plan business data Web Parts.

For more information about planning business data actions, see Plan business data actions.

For more information about planning business data search, see Plan for business data search.

Worksheets

Use the following worksheets to plan for business data connections with the Business Data Catalog:

•      Business data worksheet (http://go.microsoft.com/fwlink/?LinkID=73271&clcid=0x409)

•      Site creation worksheet (http://go.microsoft.com/fwlink/?LinkId=73138&clcid=0x409)

Plan for business data profiles

In this article:

•      About business data profiles

•      Plan connections to the Business Data Catalog

•      Plan to include business data content sources

•      Plan properties of business data profiles

•      Worksheets

Good planning for business data profiles can transform a site collection from a place where users collaborate on documents and link to content and sites that support that content to a place where users can easily interact dynamically with key business data that is synchronized between the Web browser and underlying data sources.

As part of planning your initial deployment of Microsoft Office SharePoint Server 2007, you should understand which business data applications you want to connect to the Business Data Catalog, and which business data types and properties of those applications you want to make available in Office SharePoint Server 2007. Then, you can use these plans during your initial deployment of Office SharePoint Server.

About business data profiles

Business data profiles describe the properties of every important person, organization, product, business location, or any other type of data tracked by your business applications. You can create profiles for all types of data, depending on the needs of your organization and the purpose of each site collection you plan. The properties of business data profiles are also used by other features of Office SharePoint Server 2007.

Plan connections to the Business Data Catalog

The Business Data Catalog is a service that exposes data from enterprise applications to Windows SharePoint Services 3.0 and Office SharePoint Server 2007. The Business Data Catalog can be used by multiple site collections in one or more server farms. Each line-of-business application is represented by a Web application instance that contains its data in the Shared Services Provider (SSP), consolidated into a single Business Data Catalog for all business data.

The Business Data Catalog enables line-of-business applications to make data available as Office SharePoint Server 2007 properties. These properties can be used in lists, Web Parts (including reports and multi-report summaries, such as dashboards), and key performance indicators (KPIs) created from business data lists. These properties can also be used as metadata for search, user and business data profiles, and custom Web applications. Examples of line-of-business applications include:

•      SAP Business Information Warehouse or mySAP ERP

•      Siebel eBusiness Applications

•      Attunity Legacy Data Access Solutions

•      Microsoft BizTalk Server

The Business Data Catalog can also recognize properties from database servers, such as Microsoft SQL Server and Oracle, and properties from Excel Calculation Services. Application data can be managed interactively by using business data actions, often by using Microsoft Office InfoPath 2007 forms.

Before you can use data from line-of-business applications in business data profiles and other features of Office SharePoint Server 2007, you must perform the following steps:

1.   Register the application in the Business Data Catalog.

2.   Map the application properties to properties in the site collection and SSP schema.

3.   Create and crawl the content source for the business data application.

Plan to include business data content sources

You can create content sources to crawl business data. The properties of business data profiles are updated whenever a content source that contains the location of the business application is crawled. For more information about crawling business data, see Plan for business data connections with the Business Data Catalog.

Plan properties of business data profiles

Business data profiles are created when an application is registered in the Business Data Catalog. Business data profiles are created for every business data type in a business application that the SSP administrator chooses to display. Copies of these profiles exist for every site collection that uses the same SSP.

Business data profiles are similar to user profiles in that they contain a set of properties and associated values. The properties of each profile are crawled by the SSP and are then available for use in search queries and business data features of Office SharePoint Server 2007.

In addition to the properties of business data types, business data profiles include links for all business data actions that have been created for the application. For more information, see Plan business data actions.

The properties of business applications in the Business Data Catalog should be considered as part of your overall information architecture planning. Based on the purpose of each site collection, decide whether it will need to use each business application.

After you identify site collections that will use data from business applications, think about which features used by each site collection will use that data, and how data will be used across the SSP. Examples of types of data that might be used by your organization within each site collection include:

•      Users, such as customers, employees, and business partners.

•      Organizations that might also be customers, partners, internal groups or divisions, and other groups associated with the data in one of your organization's core business applications.

•      Places, such as different sales regions.

•      Products or services provided by your organization.

Many business applications track these types of data. Importing that data into the Business Data Catalog as business data types with business data profiles is relatively simple. The important planning considerations include:

•      Which properties to include during import.

•      How those properties are displayed in the business data profile.

•      How those properties are displayed in other features that depend on the properties of business data.

Only SSP administrators can view the properties in the business data profiles in the Business Data Catalog. However, anyone else can view the business data profile for each business data type by clicking a link to that business data type in a business data list or Web Part. For example, in a list of recent customer transactions, clicking the name of the customer displays the profile for that customer, including the customer's name, address, telephone number, and e-mail address. Similarly, clicking the product name within the same list displays a profile for the product that contains its name, description, and price.

The properties of business data profiles can be displayed in the following additional ways:

•      Business data search

•      Business data lists

•      Business data Web Parts

•      Filter Web Parts that filter by properties in the Business Data Catalog (such as the filters in personalization sites and dashboards)

•      KPIs based on business data sources

•      Reports built around one or more KPIs or business data Web Parts

•      Business data actions

•      InfoPath Forms Services browser-enabled forms

Business properties that refer to user profile data or discussion list properties redirect to the profile stores for those types of profile data, which are not stored within the Business Data Catalog. For example, personnel records stored in SAP, which are imported by the People and Audiences Shared Service, appear as user profiles that can be managed from the relevant SSP.

Each of the features in the previous list that is built on business data has its own detailed planning considerations. When planning business data profiles, it is important to focus on including the relevant properties that will make the profiles useful in themselves, while also being useful for these other features. In this case, it might be useful to work backwards, starting with planning sites, then highlighting the business data features for each site and planning for each of them, and then listing all of the relevant properties to include in the business data profile for each business data type used in that site. By the time you evaluate all of your sites, you will have a list of applications, business data types, and properties for each business data type. Then, you can simply ensure to include those properties when registering applications in the Business Data Catalog.

For example, when you plan your site collections, you might decide to track business sales on a single site collection. You plan to use the portal site template to host a central site that has news and information relevant to all sales associates and managers, personalization sites that track sales for each employee, and a dashboard that presents sales across the organization that can be filtered by date, sales associate, product line, or location. You also want employees to be able to search for customers, particularly when managing key business accounts.

The administrators and planners for the site collection plan the Web Parts and lists needed to meet these business needs. The dashboard will have a set of business data Web Parts such as KPIs, Excel Web Access Web Parts, and Web Parts that display data from applications that are registered in the Business Data Catalog. Each of those business data Web Parts will gather its data from a different business data type in the central business application that is tracking sales. The relevant data — and associated properties — will depend on what is being tracked. Each filter Web Part used will filter based on a different property of business data. Search is built on a subset of managed properties that is used in queries and search scopes when users search for customers, products, or sales offices. Finally, the business actions you implement often use business data properties.

For each of the pages and sites you plan for the site collection, you plan the business data types and relevant properties you will need. By the time you are done, you will have a list of business data types for the application, the properties you want to track for each one, and the properties that are used most often across the site collection. Every site collection will be planned similarly, and the SSP administrator for the Business Data Catalog will end up with a complete list of business data profiles to implement during initial deployment.

Business data property and profile planning is an iterative process in which you first plan information architecture, then consider the sites planned based on that information architecture, then identify features for each site, and then use information about the properties needed by those features to plan and create business data profiles in the Business Data Catalog. In that process, you might also identify gaps in the information architecture planning or find that some business data properties are lower priority and can wait until later deployment. It can be just as important to decide what not to include in the initial deployment.

Worksheet action

Use the Site creation worksheet (http://go.microsoft.com/fwlink/?LinkId=73138&clcid=0x409) to record the sites that use business data applications for your site collection hierarchy and for each site collection. Also record the business data Web Parts and SharePoint lists that are used for each site.

Use the Business data worksheet (http://go.microsoft.com/fwlink/?LinkID=73271&clcid=0x409) to record the applications registered in the Business Data Catalog, along with the included business data types and properties for each business data profile.

For data sources based on SQL Server databases and other relational databases that will be stored in data connection libraries, record the planned data source and the relevant business data types and properties used by SQL Server 2005 Analysis Services and SQL Server 2005 Reporting Services when analyzing and displaying the data.

For each data source on the worksheet, record the KPIs, reports, and business data lists and Web Parts based on that data source, and add the properties used by each list or Web Part. For KPIs, record the planned calculation method and the targets for each indicator level of the KPI.

Worksheets

Use the following worksheets to plan for business data profiles:

•      Business data worksheet (http://go.microsoft.com/fwlink/?LinkID=73271&clcid=0x409)

•      Site creation worksheet (http://go.microsoft.com/fwlink/?LinkId=73138&clcid=0x409)

Plan business data lists

In this article:

•      About business data lists

•      Plan business data columns

•      Plan dependent columns

•      Plan business actions in business data lists

•      Plan Web Parts for business data lists

•      Worksheets

In Microsoft Office SharePoint Server 2007, business data lists are lists that contain columns that have data from other data sources, such as data connection libraries, Excel Calculation Services, other SharePoint lists, or the Business Data Catalog. In Office SharePoint Server 2007, you use business data lists to display the business data types and properties of business data applications within SharePoint lists and to create Business Data List Web Parts. These lists and Web Parts can then be used in sites throughout the Web applications and site collections used by your organization.

As part of planning for your initial deployment of Office SharePoint Server 2007, you should understand how to add business data columns to SharePoint lists, how to add business data actions to business data lists, and how to create business data Web Parts based on business data lists. Then, you can plan for lists in your initial deployment of Office SharePoint Server 2007.

About business data lists

Business data lists enable you to display data from business applications in SharePoint lists. You create business data lists by adding business data columns to any existing SharePoint list. You can also create business data lists by creating and configuring a Business Data List Web Part, which automatically creates the corresponding list that has selected business data fields.

Business data lists are used as a source of data when you create the Web Parts for pages, such as the Report Center site, other SharePoint sites that have reports or business intelligence Web Parts, multi-report summary pages known as dashboards, and personalization sites.

The data in business data lists can be taken from the applications registered in the Business Data Catalog and from underlying line-of-business applications. Additionally, data from Microsoft SQL Server and Excel Calculation Services can be displayed in SharePoint lists and list Web Parts.

Plan business data columns

From any SharePoint list, users who have permissions to add and remove columns to the list have the option to include one or more business data columns. These columns enable you to connect to data sources to bring business data into any existing list.

Business data columns are associated with business data types in the Business Data Catalog. The heading for the column is the business data type, and each row in the column contains a different item of that type. For example, a business data column for the "customer" business data type appears as a "customer" column that includes different customers for each item in the list.

The data in business data columns is taken directly from business applications. Every item of business data has a corresponding business data profile. This enables you to create lists that link directly to valuable business data. For example, in a customer service scenario, clicking the name of the customer in the customer column opens a profile of that customer. The profile contains a list of relevant properties for the customer, such as the customer's location, number of purchases, address, e-mail address, and telephone number.

When planning the sites in your site collection, it is important to consider which business data lists to include in the initial deployment. Most business data lists will be created during ongoing operations by individual users, but some lists are so central to the business data in your organization that you might want to create and deploy them from the beginning. Some lists are used by Business Data List Web Parts.

For every Business Data List Web Part you create that relies on a SharePoint list, plan to create the list and include the columns that will be needed in each Web Part. Each column you identify during planning is a business data type that you can import when you register a business application in the Business Data Catalog.

Worksheet action

Use the Business data worksheet (http://go.microsoft.com/fwlink/?LinkID=73271&clcid=0x409) to record the needed columns for the planned lists and Web Parts.

Plan dependent columns

Business data columns might be associated with dependent columns that appear automatically next to the main column. These dependent columns cannot be edited, because their values are taken from the connected data source. The values update automatically every time the view of the list is refreshed, after a set amount of time, or when someone who has the appropriate permissions clicks the Update Business Data button at the top of the list.

Users can filter and sort on dependent columns just as any other columns. The person who adds business data columns decides which dependent columns to include.

Dependent columns represent properties related to a particular business data type in the Business Data Catalog, which might or might not be business data types themselves. When you plan for the business data lists in your initial deployment of Office SharePoint Server 2007, make a note of the properties you will need to create for these dependent columns.

Worksheet action

Use the Business data worksheet (http://go.microsoft.com/fwlink/?LinkID=73271&clcid=0x409) to record the properties you will need to create for the dependent columns. Use that information when you register each business application in the Business Data Catalog.

Plan business actions in business data lists

When you add a business data column to a list, you also add a set of actions associated with the business data type for that business column. These actions appear when users hold their pointer over the item they want to act on. In the customer database example, users who use the list can perform an action for any customer simply by pointing at the customer's name in the list and then selecting an action from the menu that appears. For example, a common action is "Edit Customer Profile," which opens a Microsoft Office InfoPath 2007 page that has properties for the selected customer.

Plan Web Parts for business data lists

Business data lists are used when creating Business Data List Web Parts. The following Web Parts are based on business data lists:

•      Business Data List Web Part

•      Business Data Details Web Part

•      Business Data Association Web Part

•      Key performance indicator (KPI) List Web Part

The first three Web Parts use data from applications in the Business Data Catalog in business data lists to display business intelligence in reports, dashboards, personalization sites, and other business intelligence sites. For more information, see Plan business data Web Parts.

The KPI List Web Part can be based on information in business data lists, by selecting a SharePoint list as the source for a particular KPI. KPIs can also be created from SQL Server 2005 Analysis Services databases that are accessed by data connection libraries. For more information, see Plan key performance indicators.

Worksheet action

Use the Site creation worksheet (http://go.microsoft.com/fwlink/?LinkId=73138&clcid=0x409) to record the SharePoint lists and related Web Parts used for dashboard pages and other key sites that use business data lists.

Worksheets

Use the following worksheets to plan business data lists:

•      Business data worksheet (http://go.microsoft.com/fwlink/?LinkID=73271&clcid=0x409)

•      Site creation worksheet (http://go.microsoft.com/fwlink/?LinkId=73138&clcid=0x409)

Plan business data Web Parts

In this article:

•      About business data Web Parts

•      Plan core business data Web Parts

•      Plan specialized business data Web Parts

•      Plan KPI Web Parts

•      Plan Excel Web Access Web Parts

•      Plan SQL Server 2005 Analysis Services Web Parts

•      Plan filter Web Parts connected to business data Web Parts

•      Plan deployment of Web Parts

•      Worksheets

In Microsoft Office SharePoint Server 2007, business data Web Parts are used in reports, reports-enabled pages such as the Report Center site, and other SharePoint sites including personalization sites to display a Web-based view of business data that promotes analyzing, reporting, and acting on that data in a way that builds knowledge within your organization.

As part of planning for your initial deployment of Office SharePoint Server 2007, you should understand the different varieties of business data Web Parts, understand how they are used to display business data and promote business intelligence, and plan the specific Web Parts to deploy for each site.

About business data Web Parts

Business data can be displayed in SharePoint lists and Web Parts for the pages and sites in each site collection used by your organization. The sources of this data include Microsoft SQL Server 2005 and its related applications, such as SQL Server 2005 Reporting Services, and line-of-business applications registered in the Business Data Catalog.

Business data can be exposed directly in lists by using the Business Data List Web Part. It also can be exposed through Web Parts designed specifically for personalization features. Depending on where the Web Parts are used, the experience is completely different. If it is just a simple list, the experience is much like using any SharePoint list, except that the data is connected to the data source and updates automatically. If it is a single Web Part within a report, the owner of the page controls the interactivity and it might simply be a display of that data. If it is on a multi-report summary page, it can be filtered along with other business data Web Parts on the page. If it is on a personalization site or personal site, the information in the Web Part is targeted by audience, and only information relevant to the viewer is presented. There are also specific Web Parts for common line-of-business applications, such as SAP.

Types of Web Parts that are used to display business data on SharePoint sites include:

•      Core business data Web Parts

•      Specialized business data Web Parts

•      Key performance indicator (KPI) Web Parts

•      Excel Web Access Web Parts

•      SQL Server 2005 Analysis Services Web Parts

•      Filter Web Parts that are connected to business data Web Parts (for example, the Current User Filter Web Part and the Property Profile Filter Web Part used on personalization sites, and the Business Data Catalog Filter Web Part)

These Web Parts are used to create pieces of business intelligence that can be displayed in reports linked from the Report Center site, other SharePoint sites that have reports or business data, in multi-report summary pages also known as dashboards, and on personalization sites.

Data connection libraries expose Office data connection (.odc) files and universal data connection (.udcx) files.

Plan core business data Web Parts

The core business data Web Parts include:

•      Business Data List Web Parts

•      Business Data Details Web Parts

•      Business Data Association Web Parts

•      Business Data Actions Web Parts

•      Business Data Catalog Filter Web Parts

The first four business data Web Parts are used to display information based on the data stored by SQL Server and reported by SQL Server 2005 Reporting Services, and the properties of line-of-business applications registered in the Business Data Catalog. The first three of these Web Parts then can be added to reports in the Report Center site or other pages that display reports or business data.

The Business Data List Web Part presents business data in a simple list form, including several items from one type of business data in the Business Data Catalog. An example is a list of customers from a customer service database. That list can be connected to a filter Web Part to show information that is based only on the current user or a specific value for a property of the relevant business application. You also can edit the view properties of a Business Data List Web Part, just as you can edit the view of any list, to filter by property or limit the number of items shown in the Web Part. The Web Part also can be targeted to audiences so that only some users see the Web Part.

The Business Data Details Web Part displays the details of a single item, such as a single customer in a customer database.

The Business Data Association Web Part presents a related list that shows a list of items related to an item of another business data type. An example is a list of customers who work in a particular sales region. Related lists can be associated with more than one source business data type to narrow the focus of the list. An example is a list of sales orders by a customer in a particular sales division. The source business data types are the customer and the sales division, and the items in the list are sales orders. As with the view for the Business Data List Web Part, the view for the Business Data Association Web Part can be filtered or limited to a specified number of list items, and can be connected to filter Web Parts or targeted to audiences.

The Business Data Actions Web Part adds a simple URL to a page associated with the action named in the link. It is used to enable users to perform common actions from business applications directly from the Web browser. Often, a Business Data Actions Web Part is found on the same page with a related business data Web Part, so users can see information and act on it immediately. For example, a Business Data Actions Web Part for the "View Customer Profile" action could be found on a dashboard that has an Excel Web Access Web Part that displays sales for a customer and a KPI Web Part that shows customer satisfaction. An analyst seeing a low customer satisfaction KPI could correlate that information with recent sales reports and then click the business data action link to find out more about the customer and contact them to improve customer service.

The Business Data Catalog Filter Web Part filters other Web Parts on a page based on values found in SQL Server 2005 Reporting Services or the Business Data Catalog. It is often used in combination with business data Web Parts to filter the view, and any recognized property can be used by this filter. For more information about filtering data, see Plan dashboards and filters.

Plan specialized business data Web Parts

Specialized business data Web Parts include:

•      IView Web Part (SAP)

•      WSRP (Web Services for Remote Portlets) Consumer Web Part

The IView and WSRP Consumer Web Parts support the presentation of data from SAP and WSRP portlets, respectively. If your organization uses SAP or remote portlets, these Web Parts enable you to integrate these Web Parts into your Web Part pages so that you can have a single view of all business data instead of different sites for different Web-based views of business data.

To use the IView Web Part, you must perform the following steps:

1.   Configure SAP for the site.

2.   Select an SAP server and IView for the Web Part.

3.   Ensure that both the SAP server and IView are trusted on the site.

To use the WSRP Consumer Web Part, you must perform the following steps:

1.   Configure WSRP producers for the site.

2.   Select a portlet server and portlet for the Web Part.

3.   Ensure that both the portlet server and portlet are trusted on the site.

Plan KPI Web Parts

KPI Web Parts present business data with graphical indicators of the current status of a key business process. For example, a KPI can use traffic light icons to indicate that customer satisfaction is exceeding, meeting, or failing to meet goals. If customer satisfaction exceeds a preset goal, calculated by counting the percentage of positive satisfaction ratings across your organization, the customer satisfaction KPI is displayed with a green traffic light icon. If customer satisfaction is failing to meet minimum goals, the customer satisfaction KPI is displayed with a red traffic light icon. Otherwise, it is displayed with a yellow traffic light icon.

Each KPI in a KPI List Web Part and the single KPI in each KPI Details Web Part is evaluated based on a single value from a data source, either from a single property or by calculating an average or total across the selected data. Because they are calculated across a range of data rather than displaying data in list form, they can be more useful when measuring performance across groups or projects. However, by calculating a range of data for a specific person, such as a list of sales for a single employee, a KPI can evaluate individual performance.

The two KPI Web Parts display a list of KPIs calculated independently, or details for a single KPI. You can connect KPI Web Parts to filter Web Parts to filter each KPI by specific properties or users. Data sources for KPI lists include:

•      SharePoint lists   The data comes from a SharePoint list that might include business data from the Business Data Catalog or SQL Server 2005.

•      Excel workbooks   The data comes from an Excel workbook.

•      SQL Server 2005 Analysis Services   The data comes from database stores known as cubes, for connections in a data connection library.

•      Manually entered information   The data comes from a static list, rather than based on underlying data sources. This is used less frequently, for test purposes prior to deployment or on occasions when regular data sources are unavailable but you still want to provide performance indicators.

If the KPI List Web Part is added to a page, you must provide a link to a KPI list that contains KPIs. KPI List Web Parts can include links to the details of each KPI. When you click the link for the KPI, a customizable details Web page appears that contains additional information. The view of KPI List Web Parts based on SharePoint lists can be limited or filtered just as the view of any list.

The KPI Details Web Part displays performance indicators for a single item in a KPI list.

For more information about planning KPI Web Parts, see Plan key performance indicators.

Plan Excel Web Access Web Parts

Excel Web Access Web Parts are available for personal sites and personalization sites. The Excel Web Access Web Part is used to provide information from a specific worksheet directly within the Web Part by using Excel Calculation Services. It also enables the ability to perform analytics in the Web browser without affecting the underlying worksheets or data sources. Users who have the appropriate permissions can start an Microsoft Office Excel 2007 window directly from this Web Part to edit the worksheet. The Excel Web Access Web Part also can be used to perform analytics on data from SQL Server 2005 Analysis Services.

Plan SQL Server 2005 Analysis Services Web Parts

SQL Server 2005 Analysis Services Web Parts are available for personal sites and personalization sites. The SQL Server 2005 Analysis Services Web Part presents data directly from SQL Server 2005 Analysis Services. This part can be used in reports or multi-report summary pages, or in other sites that use business data such as personalization sites.

Plan filter Web Parts connected to business data Web Parts

One feature of business data Web Parts is the ability to filter the data displayed on each Web Part by using one or more filter Web Parts. Filters can be connected to a single Web Part or to all the Web Parts on a page. When several business data Web Parts are connected to a single filter, the data in all of the business data Web Parts can be filtered by the same property and value. For example, a page can filter data from all of its business data Web Parts over the last month or for a certain user. Such multi-report summary pages, known as dashboards, can be very useful in presenting a uniform view of business data in your organization.

Plan deployment of Web Parts

Each of these Web Parts must be added to a site and then connected to the underlying data source. After that connection is made and the Web Part displays business data, it can be used to create a page around the Web Part called a report. It can also be used in a multi-report summary page that displays multiple business data Web Parts. Reports can appear in the Report Center site or any other reports site, and business data Web Parts can be used in other sites such as personalization sites.

Site planning enables you to identify the Web Parts you plan to create that use business data. Each Web Part requires certain properties. You will want to decide which properties are most relevant for the viewers of each Web Part on a site.

The sites and pages that commonly use business data Web Parts include:

•      The Report Center site

•      Other sites that use reports

•      The default dashboard for the site collection

•      Personalization sites

For an initial deployment, consider the Web Parts that you will use for each of these sites. Although you can use business data Web Parts on any site, it is not necessary to plan for the Web Parts of those sites, which are created during ongoing operations. For each Web Part:

•      List the applications and business data types you need to implement the Web Part.

•      List the properties you need to implement the Web Part, so that you can include those properties in the business data profile for the appropriate business applications and business data types.

•      Ensure that the information for each property and business data type of each application is complete enough to be useful when it is imported.

•      Plan to create lists that business data Web Parts are based on.

•      Consider the security implications of each list, and note the SharePoint groups that will have access to each list and corresponding Web Part.

•      Decide whether the Web Part's view should be limited or filtered. For more information, see Plan business data lists.

•      Decide whether the Web Part is connected to filter Web Parts. For more information, see Plan dashboards and filters.

•      Decide whether the Web Part should be targeted to specific audiences, for each site that uses the Web Part. For more information, see Plan for personalized Web Parts.

•      Consider whether the purpose of this Web Part is already fulfilled by another Web Part or site to minimize unnecessary duplication of functionality. For more information, see Determine sites and subsites.

Although planning Web Parts will take time, it allows you to understand the scope of your Web Part deployment before you begin, so that you can prioritize what is most important for initial deployment, and schedule lower priority sites and Web Parts for later deployment. It also reduces deployment time by identifying data sources and lists on which business data Web Parts are dependent.

Worksheet action

Use the Business data worksheet (http://go.microsoft.com/fwlink/?LinkID=73271&clcid=0x409) to record business data and business intelligence Web Parts. Record connected Web Parts, data sources, and SharePoint lists used by the Web Part in the same table.

Use the Site creation worksheet (http://go.microsoft.com/fwlink/?LinkId=73138&clcid=0x409) to record Web Parts used by each site planned in your site collection hierarchy.

Worksheets

Use the following worksheets to plan business data Web Parts:

•      Business data worksheet (http://go.microsoft.com/fwlink/?LinkID=73271&clcid=0x409)

•      Site creation worksheet (http://go.microsoft.com/fwlink/?LinkId=73138&clcid=0x409)

Plan business data actions

In this article:

•      About business data actions

•      Plan the scope of business actions

•      Plan properties for business actions

•      Plan Business Data Action Web Parts

•      Plan custom business actions

•      Worksheet

Business data actions provide a way to enable users who view business data in reports, dashboards, or other reports-enabled pages to act immediately on the data that they are viewing. By using InfoPath Forms Services and configuring permissions to the relevant databases, users who have the correct permissions can make direct changes to the underlying business data.

As part of planning for your initial deployment of Microsoft Office SharePoint Server 2007, you should understand how to create business actions, how to plan for the pages that perform the action, how to plan the properties used in business data actions, how to determine who has access to an action, and how the action is displayed in search results, SharePoint lists, and sites containing the Business Data Action Web Part. Then, you can use these plans during your initial deployment of Office SharePoint Server 2007.

About business data actions

Business data actions are actions configured by administrators. The actions open a Web page that provides meaningful information about business data so that users can meaningfully collaborate based on the data displayed in your organization. Business data actions enable you to provide ways for users in your organization to directly interact with business data from within the sites in your site collections.

For every application registered in the Business Data Catalog, each business data type has a business data profile. You create actions for common tasks by using business data from within the profile.

The business action has two simple properties: an action name and a URL for a Web page that is used to process the action and to provide results of some kind. The Web page is typically one of the following:

•      A static Web page that has a fixed result.

•      A SharePoint list.

•      A Microsoft Office InfoPath 2007 forms-enabled page that can interact with business data on the database or business application server.

•      A customized page for more complex data interaction or presentation, such as a dynamic .aspx page.

After actions are created, they appear within a specialized Business Data Action Web Part for items in:

•      Search results

•      SharePoint lists

•      Reports and dashboards

Examples of search results that might include actions are employees, customers, sales reports, and regional offices. Any business data type in the Business Data Catalog can be associated with one or more actions in a Business Data Action Web Part, and those actions appear as part of those items when they appear in search results. Similarly, any business data type in a list includes the associated actions that have been created for that business data type. Actions also show up in the business data profiles in the Business Data Catalog for the relevant applications and business data types. The Business Data Action Web Part can be used in other pages, such as the Report Center site and personalization sites.

For example, you can implement a Resolve action for a customer database application. After searching for a particular incident in the database, a customer service representative sees the Resolve action next to the customer's incident report in the search results. The representative clicks the link for the action, which opens a page that has form fields for type of resolution, date of resolution, and the name of the representative who is resolving the issue. The customer service representative might also see this action in his or her personal site, in a personalization site designed for tracking and resolving customer issues, or in a personalized Web Part displayed on another page, such as the Report Center site.

Plan the scope of business actions

When planning for business actions, consider the common actions that people use for each business application. Every action that you make available from Office SharePoint Server 2007 is likely to increase the number of users who perform that action, which can affect planning in several areas:

•      Security   Security is handled by the destination page associated with each action. That page can be a simple Web page, a Office InfoPath 2007 form, or a more customized page. Whatever the destination page, only users who have access to that page can perform the action. If the destination is not a SharePoint site, users who use the page must log in separately. When you plan for business actions, be sure that the users who perform the action have the appropriate permissions for the destination site. You can do this by comparing the membership and permissions plan for each site and noting the differences. Then, for each action, note where the differences affect the actions you are planning to create during initial deployment. If there are discrepancies, you can either change permissions so that the right users have access to a site, or you can change the planned destination location.

•      Performance   When you enable users in your organization to easily access business applications from business actions in your site collection, you will likely increase the use of those applications. This produces an additional load on the databases and application servers for business applications. In most organizations, this will be a manageable increase. However, in large organizations, server performance might be affected.

•      Site design   Consider the costs in time and resources for site planning when designing more complex actions. You might have limited time to design and develop more complex pages for handling interaction between your SharePoint sites and your business applications. Prioritize the most important actions first. Additional actions can be added as needed as part of normal operations after initial deployment and configuration.

Site administrators should make a note of the business actions they want to develop and the schedule for implementing those actions, and then provide those details to the IT administrators on the planning team. This helps IT administrators plan for any potential impact in capacity planning for both initial deployment and long-term operations.

Plan properties for business actions

Business actions often require users to provide values in forms for certain business properties. Business actions can also open Web pages that use certain properties in performing calculations. You can make the correct properties available by noting the properties you need and including them in a comprehensive list of business data properties to include in business data profiles. The important information to plan for includes:

•      The business applications that have important actions that you want to make available in each site collection.

•      The business data types in the Business Data Catalog associated with each action.

•      The properties associated with the each business data type.

For example, you might want a business action that resolves customer service records to be associated with the business data type for customer service records, and to appear when anyone views a customer service record. During planning, record the customer service database, the customer service record business data type, and the properties tracked for each customer service record, such as service date, issue type, customer name, and location of service. Provide this information to the users who plan shared services, so Shared Services Provider (SSP) administrators can import the properties when registering properties in the Business Data Catalog.

Worksheet action

Use the Business data worksheet (http://go.microsoft.com/fwlink/?LinkId=73271&clcid=0x409) to record your business data action plans. List data sources and related business data types and properties, both for databases in data connection libraries and for line-of-business applications registered in the Business Data Catalog. Business data actions that use those properties should also be recorded.

Plan Business Data Action Web Parts

The Business Data Action Web Part adds a link to a page associated with the action. When you create business actions for any business data type in the Business Data Catalog, this Web Part is included in search results and list items for any example of that business data type. If you create a resolve customer service report issue for the customer service report business data type, a Web Part that contains the Resolve action appears in any search results or lists containing any customer service reports.

You can use that same Web Part in additional sites, such as the Report Center site or personalization sites. When the Business Data Action Web Part is added, you can add one or more actions associated with a single business data type. You can use multiple action links on the same site to provide actions that are associated with more than one business data type, bringing business data interactivity wherever it is appropriate. Often, a Business Data Action Web Part is found on the same page as a related Web Part, such as a key performance indicator (KPI) Web Part, Business Data List Web Part, or Excel Web Access Web Part, so users can view information and immediately act on it.

You can choose Web Parts for each page based on the best way of fulfilling the purpose of each page as determined during information architecture and site structure planning. As you plan the key sites in site collections, update your site planning to incorporate opportunities for business data actions.

Plan custom business actions

You can use the developer tools for Office SharePoint Server 2007 to customize business actions so that they do more than forward to a particular URL. Creating a custom action might be worth the development time and resources if the action relates directly to a key business process. For more information about creating custom actions, see the Office SharePoint Server 2007: Software Development Kit (http://go.microsoft.com/fwlink/?LinkId=72208).

Worksheet

Use the following worksheet to plan business data actions:

•      Business data worksheet (http://go.microsoft.com/fwlink/?LinkId=73271&clcid=0x409)

Plan for business data search

In this article:

•      About business data search

•      Plan business data search

•      Worksheets

The integration of business data with other features of Microsoft Office SharePoint Server 2007 provides an opportunity to use the full power of enterprise search to find, view, and act on relevant business data. This integration is available only in the enterprise version of Office SharePoint Server 2007. Deployments of the standard version of Office SharePoint Server 2007 cannot register business data applications or search for business data by using enterprise search.

When planning for business data search, it is important to understand the search functionality. It is also important to consider the following:

•      Plan for inclusion of business data in content sources.

•      Select the appropriate properties of business data to map to managed properties in the search schema.

•      Create access control lists (ACLs) for business data types.

•      Use search scopes and search filters to change how search queries are grouped and which search results are found.

•      Plan to integrate business data search capability into the sites in your site collection.

About business data search

Business data results are excluded from general search results. Business data search results can be displayed in four distinct ways:

•      When a search scope that includes business data is used to search, the search results include business data results. A business data search scope is not provided by default, but administrators can create search scopes that include business data.

•      Users can refine initial search results by selecting the option to search business data sources.

•      Users can select a business data tab provided in the Search Center site, and the search will include all business data for the tab. A tab for all business data is not included by default, but administrators can add tabs for searching all business data or for searching data from specific business applications.

•      If the search term in a standard search query matches a keyword phrase selected by an administrator, the business data result appears in recommended results.

Administrators of the search service and individual site collections must configure several options before business data is available in search results. Use the following procedure to make business data available for search.

Make business data available for search

1.   For line-of-business applications, register the application in the Business Data Catalog and set the number of connections.

2.   Create a content source for the business application data.

3.   Crawl the content source for the application data to add its properties as new crawled properties in the portal site schema.

4.   Select the relevant properties in the Configure Search section of the Business Data Catalog and map them to managed properties for search.

5.   Create ACLs for business data types in the Business Data Catalog.

6.   Crawl the content source for the business data source again to update managed properties and ACLs.

7.   Create search scopes for business data.

8.   Configure keywords for business data.

Most of these tasks are performed by the administrator of the search shared service or by the administrator of the Business Data Catalog. Some tasks are performed by site collection administrators. Both shared services administrators and site collection administrators will help plan search for business data.

Plan business data search

When planning for business data search, it is important to consider your business needs and how you can use search features to improve the visibility of business data and the usability of business intelligence features.

The first thing to consider is which business processes are relevant to each site collection, and which business applications are used in evaluating and working within those processes. When you identify those applications, think about how users will search for that business data, and what the scope of the business data is. Often, users will look for business data from a particular application from several sites and site collections, but not every site will use the same business data. Based on the scope of business processes and the associated business applications and business data, several decisions will be affected.

Plan Shared Services Providers for business data

You can often rely on the security for business applications to limit access to business data, but for particularly sensitive data that is used frequently by one group of users in your organization but not by the entire organization, you might want to consider separate Shared Services Providers (SSPs). Content and data are not shared across SSPs, so users who search by using the search shared service of one SSP will not see results for another SSP. This option is usually a good idea only when the content sets, including documents and sites other than business data, are fully distinct. Otherwise, you can use application security, SharePoint groups, and search scopes and search filters to limit availability of data.

Within the Business Data Catalog for each SSP, you will register every line-of-business application that has data you want to make available through search and other Office SharePoint Server features, such as business data Web Parts, InfoPath forms templates, workflows, and so on. SSP administrators should talk with farm administrators about capacity and performance implications for business applications. For more information, see Plan for business data connections with the Business Data Catalog.

Worksheet action

Use the Information architecture worksheet (http://go.microsoft.com/fwlink/?LinkId=73273&clcid=0x409) to record the number of SSPs and the data sources for each SSP's Business Data Catalog.

Use the Site hierarchy planning tool (http://go.microsoft.com/fwlink/?LinkId=73143&clcid=0x409) to plan the number of SSPs and the data sources for each SSP's Business Data Catalog.

Use the Estimate data capacity requirements worksheet (http://go.microsoft.com/fwlink/?LinkId=73274&clcid=0x409) to record the number of connections for each business data source.

Plan business data content sources

To use business data in search results, you must create business data content sources. Business data content sources are added just like other content sources, but have some additional configuration steps that you should consider during planning.

Business data start addresses include locations of databases for Microsoft SQL Server 2005 or other databases, and various line-of-business applications. These locations are often on separate servers that exist prior to the deployment of Office SharePoint Server 2007, although the applications can be hosted on the same server. For load-balancing purposes, you might want to host databases on separate servers. When you plan the server farms for your deployment, consider how they will connect to application servers. For more information about deploying application servers, see Design server farms and topologies (Office SharePoint Server).

To help preserve security and limit the performance impact on your business data applications, you do not want to use the actual location where business data is stored when crawling business data content sources. Typically, you will create a data warehouse that has a copy of the data, including all of the relevant business data types, properties, and values. That location will be used in the content source for the business application.

You might want to create additional content sources to support the following scenarios:

•      You want to crawl business data in one application more frequently than business data in other applications.

•      You want to create search scopes that are limited to a specific set of data from one or more applications, by using content sources. You can create search scopes based on properties instead of on content sources, so content sources are not necessary if properties enable you to accomplish the same result.

•      You want to create a Search Center tab that points to a specific set of business data that is defined by content source. As with search scopes, this is not the only way to define how business data is displayed in the Search Center site.

The frequency with which you crawl business data content sources depends on the impact to business data application servers. Work with the administrators of each business data application to implement a reasonable schedule.

Worksheet action

Use the Content Sources section of the Plan to crawl content worksheet (http://go.microsoft.com/fwlink/?LinkId=73748&clcid=0x409) to record the decisions you make about business data content sources, along with the expected crawling schedule for each content source.

For more information about content sources, see Plan to crawl content.

Plan search properties for business data

To use business data, you must select the properties of business data that will be available to search as managed properties. Properties from SQL Server can be mapped directly after they have been crawled, but line-of-business applications must first be registered in the Business Data Catalog. Managed properties will be the subset of properties that you want to use when you search for business data.

The key business processes identified during information architecture planning will suggest the most likely managed properties. You can map multiple crawled properties to a single managed property, and select whether one takes precedence or whether the managed property is multi-valued and includes all values found for crawled properties.

When you decide which properties and which business data types for a business data application you want to make available for search, you must think about what you want users to be able to find, how that information will be presented, and what the crawling impact is on the data warehouse that contains the data. Frequently, you will not want to display all data, but only data about certain properties. For example, an organization that has several offices in several regions might only want to display results for specific offices in a few key regions, depending on business needs. You decide which business data types to include and which properties to include for each business data type. Factors to consider when deciding which properties to make available include:

•      Confidentiality policies   You might have good business reasons to keep certain records confidential. For example, records that might be relevant only to key business planners and not to most users who work with data in the application. You can decide to display the properties for business data types that are not confidential, but not to display those that are.

•      Performance impact   Some properties might not be confidential, but the impact of crawling those properties and potentially enabling users to access and change those properties by using business actions might outweigh the business gains of that decision. Carefully consider the performance of each group of business data types that you enable.

Worksheet action

Use the Plan managed properties section of the Plan the end-user search experience worksheet (http://go.microsoft.com/fwlink/?LinkId=74967&clcid=0x409) to record the managed properties.

For more information about crawled and managed properties for search, see Plan the end-user search experience (Office SharePoint Server).

Plan access and security for business data search results

You can use the security for each business application to limit access to business data search results. You can also limit access to business data search by using SharePoint groups.

Any user who has access to a business data application, whether it is a database application, such as SQL Server 2005 or a line-of-business application, can also access the business data in that application. Business data search results use that security to ensure that only users who have the correct permissions can see the search results.

However, you can also apply permissions to business data and business data search results from within Office SharePoint Server 2007. A user without permissions to the database can still see search results if they have the correct SharePoint permissions.

It is a good practice to limit the number of users who have direct access to a business application. In many organizations, this might be a single account or a group that contains a small number of users. You can create SharePoint groups that have the correct permissions to view business data and related search results for each application, and then assign users in your organization to those groups. When granting permissions, consider your larger security needs and the users to whom the data in each business application is relevant. Match each application with the users who will need to find business data to do their jobs.

Worksheet action

Use the Custom permission levels and groups worksheet (http://go.microsoft.com/fwlink/?LinkId=73134&clcid=0x409) to record access to applications.

Use the Site and content security worksheet (http://go.microsoft.com/fwlink/?LinkId=73135&clcid=0x409) to record access to applications.

Plan search scopes for business data

Search scopes can be used to enable users to search for certain subsets of business data. When you plan your information architecture, you identify key business processes or groups of processes. Some of these processes will be closely linked to specific business data applications. To create a search scope for specific applications and content related to those applications, you can either apply scope rules based on properties of business data to narrow the scope of search results, or create a content source that includes only start addresses for that business process and base the search scope on that content source.

For more information about planning search scopes, see Plan the end-user search experience.

Plan keywords for business data

For each business application, you will also want to consider the most relevant search results, and consider the search terms that users are likely to use when they perform search queries. For example, if you have a key performance indicator (KPI) list that tracks a key business process, you might decide that it should appear at the top of search results when users search business data by using common terms for that business process. You can use special terms, also known as keywords and Best Bets, to highlight key business data. You can highlight lists, databases, specific business data types for an application in the Business Data Catalog. For example, you can highlight a customer business data profile as a Best Bet for a keyword relating to that customer, and the profile will be promoted to the top of search results.

You can prioritize the important special terms to configure during initial deployment by considering key phrases for each business process and associated application. Then, you can consider the most important content for those terms. Record those terms to create a reference you can use during deployment to test search terms and see if the key content appears high enough in the search results. If it does not, you can create special terms to promote those results.

Worksheet action

Use the Keywords section of the Plan the end-user search experience worksheet (http://go.microsoft.com/fwlink/?LinkId=74967&clcid=0x409) to record keywords.

For more information about keywords and special terms, see Plan the end-user search experience.

Plan business data tabs in the Search Center site

The Search Center site provides a business data tab that can be used to search across all business data sources. You might want to identify additional business data tabs for specific applications, databases, or records within an application or database. Look at your information hierarchy and consider adding business data tabs for each of the key business processes for your organization. If it is likely that users will want to search a specific set of data, it is probably worth creating a tab for that purpose. Using business data tabs in the Search Center site also provides a way to expand search without creating long lists of search scopes in the Search Scopes menu.

You might also want to customize the appearance and functionality of each tab. For more information about customizing the Search Center site, see Searching in Office SharePoint Server 2007 (http://msdn2.microsoft.com/en-us/library/ms497338.aspx) in the Microsoft Office SharePoint Server 2007 Software Development Kit (http://msdn2.microsoft.com/en-us/library/ms550992.aspx).

Example

Contoso, Ltd., is a technology company that has a customer call center to handle support calls. The call center is set up on a single site collection. Support representatives keep track of customers and customer issues by using a line-of-business application, and they have an archive of past customer issues stored on SQL Server 2005 databases that they can analyze by using SQL Server 2005 Analysis Services. Each of these applications and the related customers and product lines are recorded in the Information architecture worksheet (http://go.microsoft.com/fwlink/?LinkId=73273&clcid=0x409).

The Business Data Catalog administrator plans to register the customer issues application in the Business Data Catalog, map business application data properties to managed properties used by search, and create business data profiles for key business data types, such as customer, region, business unit, and product line. The planned properties are recorded in the Business data worksheet (http://go.microsoft.com/fwlink/?LinkID=73271&clcid=0x409). The managed properties used by search are recorded in the Plan managed properties section of the Plan the end-user search experience worksheet (http://go.microsoft.com/fwlink/?LinkId=74967&clcid=0x409).

Because the content on the site collection concerns an integrated set of business processes and users who share information across teams and processes, there is no need for additional SSPs to isolate content. Only one SSP is needed. This should be recorded on the Site hierarchy planning tool (http://go.microsoft.com/fwlink/?LinkId=73143&clcid=0x409).

The search service administrator plans to create a content source for the customer service application, so customer and customer issue data can be updated more frequently than the rest of the content on the site collection. This content source is recorded in the content sources section of the Plan to crawl content worksheet (http://go.microsoft.com/fwlink/?LinkId=73748&clcid=0x409).

The Business Data Catalog administrator decides to use a single account that has access to the customer service application to crawl the data in the application. Additional users will be granted permissions not directly to the application, but by being added to SharePoint groups that have access to business data in the site collection. Permissions to data in the SQL Server 2005 database will be limited by cube so that each person can view only the data relevant to his or her areas of responsibility. Most users in your organization will be granted read-only access for the data directly relevant to their jobs. This information is recorded in the Site and content security worksheet (http://go.microsoft.com/fwlink/?LinkId=73135&clcid=0x409).

The planning team plans scopes for customers and customer issues, along with other search scopes not related to business data. The planning team records this information in the Plan scopes section of the Plan the end-user search experience worksheet (http://go.microsoft.com/fwlink/?LinkId=74967&clcid=0x409).

When considering special terms for business data, the search service administrator for Contoso, Ltd., identifies support experts for each major product line and creates Best Bets for each expert based on keywords related to their area of expertise.

The team plans a dedicated Search Center site for the team that contains information about customers and customer service reports, and important documents and sites relevant to customer service representatives. The team starts with the Search Center site provided by the portal site template and plans features based on business needs. The team plans a customer tab so that customer service representatives can search for specific customers in the database, and a separate tab for customer service reports.

Worksheets

Use the following worksheets to plan for business data search:

•      Authentication methods worksheet (http://go.microsoft.com/fwlink/?LinkID=73278&clcid=0x409)

•      Business data worksheet (http://go.microsoft.com/fwlink/?LinkID=73271&clcid=0x409)

•      Plan to crawl content worksheet (http://go.microsoft.com/fwlink/?LinkId=73748&clcid=0x409)

•      Custom permission levels and groups worksheet (http://go.microsoft.com/fwlink/?LinkId=73134&clcid=0x409)

•      Estimate data capacity requirements worksheet (http://go.microsoft.com/fwlink/?LinkId=73274&clcid=0x409)

•      Information architecture worksheet (http://go.microsoft.com/fwlink/?LinkId=73273&clcid=0x409)

•      Plan the end-user search experience worksheet (http://go.microsoft.com/fwlink/?LinkId=74967&clcid=0x409)

•      Site and content security worksheet (http://go.microsoft.com/fwlink/?LinkId=73135&clcid=0x409)

•      Site hierarchy planning tool (http://go.microsoft.com/fwlink/?LinkId=73143&clcid=0x409)

VIII.  Plan search

The articles in this chapter include:

•      Identify your search team

•      Plan to crawl content

•      Plan the end-user search experience

•      Security considerations for search

Plan search

In this article:

•      Why two search services?

•      Plan the search team

•      Plan to crawl content

•      Plan the end-user search experience

Planning search is an important part of planning any deployment of Microsoft Office SharePoint Server 2007. If you devote time to plan how search is implemented, you can save time in the future and can reinforce the effectiveness of other business processes.

Planning carefully for search can prepare you for an initial limited deployment. You can continue to refine your search implementation, such as adding additional crawled content to the content index. Using an effective planning process can help make your search solution more effective, even if you implement the solution in stages or your needs continue to evolve after initial deployment.

You should also plan the following practical aspects of using search features:

•      What roles will be performed by the people who will manage the search features.

•      Whether you want to customize search Web Parts or the Search Center site (Enterprise edition only).

•      Whether you want to use custom search applications.

•      Whether you need to include data from external sources.

Why two search services?

Office SharePoint Server 2007 provides two search services: Office SharePoint Server Search and Windows SharePoint Services Help Search. Each of these services can be used to crawl, index, and query content, and each service uses a separate index.

The Office SharePoint Server Search service is based on the search service that is provided with earlier versions of SharePoint Products & Technologies, but with many improvements. You should use the Office SharePoint Server Search service to crawl and index all content that you want to be searchable (other than the Help system).

Note:

For the purposes of this planning guide, the Office SharePoint Server Search service is referred to as the Search service.

The Windows SharePoint Services Help Search service is the same service provided by Windows SharePoint Services 3.0, although in Windows SharePoint Services 3.0 it is called the Windows SharePoint Services Search service. Windows SharePoint Services 3.0 uses this service to index site content, index Help content, and serve queries.

As its name implies, in Office SharePoint Server 2007 the purpose of the Windows SharePoint Services Help Search service is to enable searching of the Help system that is built into Office SharePoint Server 2007.

Because the Windows SharePoint Services Help Search service uses an index that is separate from the other search service, users' queries in the Search box for the Help system return hits for only Help content. If you do not want users to be able to search the Help system, you do not need to start this service.

Plan the search team

You need to identify the search team and assign administration roles to the people on the team. Depending on the size of your organization, some members of the search team might be assigned more than one role. For more information, see Identify your search team .

Plan to crawl content

Before users can search for content, you must make that content available to search queries by crawling the content to build the content index. You plan for crawling by determining where the content is that you want to crawl, what type of content it is, and security credentials for accessing the content, among other things. This section of the guide can help you make the decisions necessary to effectively plan for crawling. It provides a worksheet that you can use to record the choices you make during this part of the planning phase. You can then use your completed worksheet when you deploy search.

For more information, see Plan to crawl content .

Plan the end-user search experience

After you plan how to crawl content, you can then plan the end-user search experience. This includes determining what users see when performing queries and what they see in the search results pages. For more information, see Plan the end-user search experience.

Identify your search team

In this article:

•      About the search planning team

•      About the search planning process

•      Plan the search deployment and operations teams

•      Worksheet

About the search planning team

Before you begin planning the features and deployment of the Office SharePoint Server Search service for Microsoft Office SharePoint Server 2007, you should understand the role of the search planning team. Involve the following administrators in planning for search:

•      Shared Services Provider (SSP) administrators, who manage large content sets within a server farm or across multiple farms. SSP administrators understand the high-level content needs of the organization and what information is important for users across their content set.

•      Site collection administrators, who manage the specific content needs of a single site collection, often scoped to a division or specific organizational purpose or product line.

•      Application administrators, who manage the end-user experience, which includes defining keywords, Best Bets, and scopes. Administrators must plan the end-user search experience at the site collection level, but they can also plan it for individual sites.

•      IT administrators, who plan architecture and topology details for one or more server farms in the organization based on the content needs identified by others. Typically, IT administrators are not concerned with content except as it affects IT operations such as availability, reliability, and capacity planning.

About the search planning process

The search planning process encompasses the following major steps:

1.   You identify the content managed by SSP administrators and site collection administrators during content planning, and content needs are reflected in the taxonomy developed for the organization. For more information, see Determine the information architecture of your site.

2.   Site collection administrators and SSP administrators consider the search capabilities they want to implement to meet the content needs, and communicate the required capabilities to IT administrators and application administrators.

3.   The high-priority content needs are addressed in IT planning and deployed in a pilot deployment, and then other content needs are met in successive waves of planning.

4.   When there is sufficient content, and the search capabilities for that content are available, the initial deployment is made available to the entire organization.

5.   Depending on the amount of content and level of planning detail, planning and implementation continue after initial deployment.

Plan the search deployment and operations teams

To deploy the Office SharePoint Server Search service, each of the types of administrators listed in the previous section is required. To perform regularly scheduled operations, you will need an SSP administrator and a site collection administrator, at a minimum. The same people who are on the search planning team might also be involved in the deployment and operations phases, but this can vary between organizations.

Worksheet

Use the following worksheet to record information about your search planning team and to record information about other team members who will not be involved in the planning phase but might be involved in the deployment or operations phases:

•      Search team worksheet (http://go.microsoft.com/fwlink/?LinkId=73621&clcid=0x409)

Plan to crawl content

In this article:

•      About crawling and indexing content

•      Identify the sources of content that you want to crawl

•      Plan content sources

•      Plan for authentication

•      Plan protocol handlers

•      Plan to manage the impact of crawling

•      Plan crawl rules

•      Plan search settings that are managed at the farm level

•      Indexing content in different languages

•      Worksheet

The purpose of this article is to help search services administrators understand how Microsoft Office SharePoint Server 2007 crawls and indexes content and to help them plan to crawl content.

Before end users can use the enterprise search functionality in Office SharePoint Server 2007 to search for content, you must first crawl the content that you want to make available for users to query.

For the purpose of this article, content is any item that can be crawled, such as a Web page, a Microsoft Office Word document, business data, or an e-mail message file.

When planning to crawl content, you should consider the following questions:

•      Where is the content that you want to crawl physically located?

•      Is some of the content that you want to crawl stored in different types of sources, such as file shares, SharePoint sites, Web sites, or other places?

•      Do you want to crawl all the content at specific sources or just some of it?

•      What types of files make up the content that you want to crawl?

•      When and how often should you crawl content?

•      How is this content secured?

Use the information in this article to help you answer these questions and make the necessary planning decisions about the content you want to crawl and how and when you want to crawl that content.

At key points in this article, we prompt you to fill out a section of a worksheet that pertains to the information you have read. You can either record your decisions on the worksheet as you work through this article or all at once at the end of this article. Either way, a completed worksheet is a valuable asset to have when you deploy your search solution.

Note:

This article describes the process of planning for crawling and indexing content to one index. If, as you plan to crawl your content, you discover that you want to use an additional content index, record your planning decisions for each Shared Services Provider (SSP) on a separate worksheet.

Office SharePoint Server 2007 includes the Office SharePoint Server Search service, which is used to crawl and index content. This service is part of an SSP and all content crawled using a particular SSP is indexed in a single index. For information about choosing the number of SSPs to use to index content, see Plan Shared Services Providers.

About crawling and indexing content

Crawling and indexing content is the process by which the system accesses and parses content and its properties, sometimes called metadata, to build a content index from which search queries can be served.

The result of successfully crawling content is that the individual files or pieces of content that you want to make available to search queries are accessed and read by the crawler. The keywords and metadata for those files are stored in the content index, sometimes called the index. The index consists of the keywords that are stored in the file system of the index server and the metadata that is stored in the search database. The system maintains a mapping between the keywords, the metadata associated with the individual pieces of content from which the keywords were crawled, and the URL of the source from which the content was crawled.

Note:

The crawler does not change the files on the host servers in any way. Instead, the files on the host servers are simply accessed, read, and the text and metadata for those files are sent to the index server to be indexed. However, because the crawler reads the content on the host server, some servers that host certain sources of content might update the last accessed date on files that have been crawled.

Identify the sources of content that you want to crawl

In many cases, the needs of your organization might only require that you crawl all the content contained by the SharePoint sites in your organization's server farm. In this case, you might not need to identify the sources of content you want to crawl because all site collections in a server farm can be crawled using the default content source. For more information about the default content source, see Plan content sources later in this article.

Many organizations also need to crawl content that is external from the server farm, such as file shares or Web sites on the Internet. Office SharePoint Server 2007 can crawl and index content that is hosted on other Windows SharePoint Services or Office SharePoint Server farms, Web sites, file shares, Microsoft Exchange public folders, IBM Lotus Notes servers, and business data that is stored in databases. This greatly increases the amount of content that can be made available to search queries.

In many cases, however, you might not want to crawl every site collection in your server farm, because content stored in some site collections might not be relevant in search results. In this case, you must do one or both of the following:

•      Note the site collections that you do not want to crawl. If you decide to use the default content source, you must ensure that the start addresses for the site collections you do not want to crawl are not listed in the default content source.

•      Note the individual start addresses of the site collections that you do want to crawl. If you decide to create additional content sources to use to crawl this content, you need to know these start addresses. For information about when to use one or more content sources, see Plan content sources later in this article.

With the Infrastructure Update for Microsoft Office Servers installed, there are two ways to process search queries in order to return search results to users. You can query the Search Server content index, or you can use federated search.

Tip:

Note that the Infrastructure Update for Microsoft Office Servers provides Office SharePoint Server 2007 with the federated search capability that first appeared in Search Server 2008.

There are advantages to each approach. For a comparison of these two approaches to processing search queries, see Federated Search Overview (http://go.microsoft.com/fwlink/?LinkID=122651). For a list and brief description of articles about understanding and using federation, see Working with federation (Office SharePoint Server). For more information about the Infrastructure Update for Microsoft Office Servers, see Install the Infrastructure Update for Microsoft Office Servers (Office SharePoint Server 2007).

Plan content sources

Before you can crawl content, you must first determine where the content is and on what types of servers the content is hosted. After this information is gathered, a shared services administrator can create one or more content sources that are used to crawl that content. These content sources provide the following information to the crawler during a crawl:

•      Type of content you want to crawl — for example, a SharePoint site or a file share.

•      Start address from which to start crawling.

•      Behavior to use when crawling — for example, how deep to crawl from the start address, or how many server hops to allow.

•      Crawling schedule.

Note:

Crawling content by using a particular content source is sometimes called "crawling the content source."

This section helps you plan for the content sources needed by your organization.

The default content source is called Local Office SharePoint Server sites. Shared services administrators can use this content source to crawl and index all content in all Web applications associated with the SSP. By default, Office SharePoint Server 2007 adds the start address (in this case a URL) of the top-level site of each site collection created in the Web application that uses the same SSP to the default content source.

For some organizations, simply using the default content source to crawl all sites in their site collections satisfies their search requirements. However, many organizations need additional content sources.

Reasons for creating additional content sources include the need to:

•      Crawl different types of content.

•      Crawl some content on different schedules than other content.

•      Limit or increase the quantity of content that is crawled.

Shared services administrators can create up to 500 content sources in each SSP and each content source can contain up to 500 start addresses. To keep administration as simple as possible, you should create only as many content sources as you need.

Crawl different types of content

You can only crawl one type of content per content source. That is, you can create a content source that contains URLs for SharePoint sites and another that contains URLs for file shares, but you cannot create a single content source that contains URLs to both SharePoint sites and file shares. The following table lists the types of content sources that can be configured.

This type of content source

Includes this type of content

SharePoint sites

SharePoint sites from the same farm or different Office SharePoint Server 2007, Windows SharePoint Services 3.0, or Office SharePoint Server 2007 for Search farms

SharePoint sites from Microsoft Office SharePoint Portal Server 2003 or Microsoft Windows SharePoint Services 2.0 farms

Note:

Unlike crawling SharePoint sites on Office SharePoint Server 2007, Windows SharePoint Services 3.0, or Office SharePoint Server 2007 for Search, the crawler cannot automatically crawl all subsites in a site collection from previous versions of SharePoint Products and Technologies. Therefore, when crawling SharePoint sites from previous versions, you must specify the URL of each top-level site and each subsite that you want to crawl. Sites listed in the Site Directory of Microsoft Office SharePoint Portal Server 2003 farms are crawled when the portal site is crawled. For more information about the Site Directory, see About the Site Directory (http://go.microsoft.com/fwlink/?LinkId=88227&clcid=0x409).

Web sites

Other Web content in your organization not found on SharePoint sites

Content on Web sites on the Internet

File shares

Content on file shares within your organization

Exchange public folders

Microsoft Exchange Server content

Lotus Notes

E-mail messages stored in Lotus Notes databases

Note:

Unlike all other types of content sources, the Lotus Notes content source option does not appear in the user interface until you have installed and configured the appropriate prerequisite software. For more information, see Configure Office SharePoint Server Search to crawl Lotus Notes (Office SharePoint Server 2007).

Business data

Business data stored in line-of-business applications

Plan content sources for business data

Business data content sources require that the applications hosting the data are first registered in the Business Data Catalog. You must create one or more separate content sources of the Business Data content source types to crawl business data. You can create one content source to crawl all applications registered in the Business Data Catalog, or you can create separate content sources to crawl individual applications that are registered in the Business Data Catalog.

Often, the people who plan for integration of business data into your site collections are not the same people involved in the overall content planning process. Therefore, include business application administrators in your content planning teams so that they can advise you how to integrate their data into your other content and effectively present it in your site collections.

For more information about planning business data search, see Plan for business data search.

Crawl content on different schedules

Shared services administrators often must decide whether some content is crawled more frequently than other content. The larger the volume of content that you crawl, the more likely it is that you are crawling content from different sources. These different sources might or might not be of the same type and might be hosted on servers of varying speeds in relation to one another.

These factors make it more likely that you need additional content sources to crawl those different sources of content at different times.

Primary reasons that content is crawled on different schedules are:

•      To accommodate downtimes and periods of peak usage.

•      To more frequently crawl the content that is updated more frequently.

•      To crawl content hosted on slower host servers separately from content crawled on faster host servers.

In many cases, not all of this information can be known until after Office SharePoint Server 2007 is deployed and running for some time. Instead, some of these decisions are made during the operations phase. However, it is a good idea to consider these factors during planning so that you can plan your crawl schedules based on the information at hand.

The following two sections provide more information about crawling content on different schedules.

Downtimes and periods of peak usage

Consider the downtimes and peak usage times of the servers that host the content you want to crawl. For example, if you are crawling content hosted by many different servers outside your server farm, it is likely that these servers are backed-up on different schedules and have different peak usage times. The administration of servers outside your server farm is typically out of your control. Therefore, we recommend that you coordinate your crawls with the administrators of the servers that host the content you want to want to crawl to ensure you do not attempt to crawl content on their servers during a downtime or peak usage time.

A common scenario involves content outside the control of your organization that relates to the content on your SharePoint sites. You can add the start addresses for this content to an existing content source or create a new content source for external content. Because availability of external sites varies widely, it is helpful to add separate content sources for different external content. In this way, the content sources for external content can be crawled at different times than your other content sources. You can then update external content on a crawl schedule that accounts for the availability of each site.

Content that is updated frequently

When planning crawl schedules, consider that some sources of content are typically updated more frequently than others. For example, if you know that content on some site collections or external sources are updated only on Fridays, it would be a waste of resources to crawl that content more frequently than once each week. However, your server farm might contain other site collections that are continually updated Monday through Friday, but not typically updated on Saturdays and Sundays. In this case, that you might want to crawl several times each week day, but only once or twice on weekends.

The way in which content is stored across the site collections in your environment can guide you to create additional content sources for each of your site collections in each of your Web applications. For example, if a site collection stores only archived information, you may not need to crawl that content as frequently as you crawl a site collection that stores frequently updated content. In this case, you might want to crawl these two site collections using different content sources so that they can be crawled on different schedules without having to crawl the archive sites as frequently as the other content.

Full and incremental crawl schedules

Shared services administrators can configure the crawl schedules independently for each content source. For each content source, they can specify a time to do full crawls and a separate time to do incremental crawls. Note that you must run a full crawl for a particular content source before you can run an incremental crawl. If you choose an incremental crawl for content that has not yet been crawled, the system performs a full crawl.

Note:

Because a full crawl crawls all content that the crawler encounters and has at least read access to, regardless of whether that content has been previously crawled, full crawls can take significantly more time to complete than incremental crawls.

We recommend that you plan crawl schedules based on the availability, performance, and bandwidth considerations of the servers running the search service and the servers hosting the crawled content.

When you plan crawl schedules, consider the following best practices:

•      Group start addresses in content sources based on similar availability and with acceptable overall resource usage for the servers that host the content.

•      Schedule incremental crawls for each content source during times when the servers that host the content are available and when there is low demand on the resources of the server.

•      Stagger crawl schedules so that the load on the servers in your farm is distributed over time.

•      Schedule full crawls only when necessary for the reasons listed in the next section. We recommend that you do full crawls less frequently than incremental crawls.

•      Schedule administration changes that require a full crawl to occur shortly before the planned schedule for full crawls. For example, we recommend that you attempt to schedule the creation of the crawl rule before the next scheduled full crawl so that an additional full crawl is not necessary.

•      Base simultaneous crawls on the capacity of the index server to crawl them. We recommend that you typically stagger your crawl schedules so that the index server does not crawl using multiple content sources at the same time. For best performance, we suggest that you stagger the crawling schedules of content sources. The performance of the index server and the servers hosting the content determines the extent to which crawls can be overlapped. A strategy for crawl scheduling can be developed over time as you can become familiar with the typical crawl durations for each content source.

Reasons to do a full crawl

Reasons for a search services administrator to do a full crawl include:

•      One or more hotfix or service pack was installed on servers in the farm. See the instructions for the hotfix or service pack for more information.

•      An SSP administrator added a new managed property.

•      To re-index ASPX pages on Windows SharePoint Services 3.0 or Office SharePoint Server 2007 sites.

Note:

The crawler cannot discover when ASPX pages on Windows SharePoint Services 3.0 or Office SharePoint Server 2007 sites have changed. Because of this, incremental crawls do not re-index views or home pages when individual list items are deleted. We recommend that you periodically do full crawls of sites that contain ASPX files to ensure that these pages are re-indexed.

•      To detect security changes that were made on a file share after the last full crawl of the file share.

•      To resolve consecutive incremental crawl failures. In rare cases, if an incremental crawl fails one hundred consecutive times at any level in a repository, the index server removes the affected content from the index.

•      Crawl rules have been added, deleted, or modified.

•      To repair a corrupted index.

•      The search services administrator has created one or more server name mappings.

•      The account assigned to the default content access account or crawl rule has changed.

The system does a full crawl even when an incremental crawl is requested under the following circumstances:

•      An SSP administrator stopped the previous crawl.

•      A content database was restored from backup.

Note:

If you are running the Infrastructure Update for Microsoft Office Servers, you can use the restore operation of the stsadm command-line tool to change whether a content database restore causes a full crawl.

•      A farm administrator has detached and reattached a content database.

•      A full crawl of the site has never been done.

•      The change log does not contain entries for the addresses that are being crawled. Without entries in the change log for the items being crawled, incremental crawls cannot occur.

•      The account assigned to the default content access account or crawl rule has changed.

•      To repair a corrupted index.

Depending upon the severity of the corruption, the system might attempt to perform a full crawl if corruption is detected in the index.

You can adjust schedules after the initial deployment based on the performance and capacity of servers in the farm and the servers hosting content.

Worksheet action

Record the decisions you make about content sources for your initial deployment in the tables in the Content sources section of the Plan to crawl content worksheet (http://go.microsoft.com/fwlink/?LinkID=73748&clcid=0x409).

Limit or increase the quantity of content that is crawled

For each content source, you can select how extensively to crawl the start addresses in that content source. You also specify the behavior of the crawl, sometimes called the crawl settings. The options you can choose for a particular content source vary somewhat based on the content source type that you select. However, most options determine how many levels deep in the hierarchy from each start address listed in the content source are crawled. Note that this behavior is applied to all start addresses in a particular content source. If you need to crawl some sites at deeper levels, you can create additional content sources that encompass those sites.

The options available in the properties for each content source vary depending upon the content source type that is selected. The following table describes the crawl settings options for each content source type.

Content source type

Crawl settings options

SharePoint sites

Everything under the host name for each start address

Only the SharePoint site of each start address

Web sites

Only within the server of each start address

Only the first page of each start address

Custom — Specify page depth and number of server hops.

Note:

The default setting for this option is unlimited page depths and server hops.

File shares

The folder and all subfolders of each start address

Only the folder of each start address

Exchange public folders

The folder and all subfolders of each start address

Only the folder of each start address

Business data

Crawl entire Business Data Catalog

Crawl selected applications

As the preceding table shows, shared services administrators can use crawl setting options to limit or increase the quantity of content that is crawled.

The following table describes best practices when configuring crawl setting options.

For this content source type

If this pertains

Use this crawl setting option

SharePoint sites

You want to include the content on the site itself.

-or-

You do not want to include the content available on subsites, or you want to crawl them on a different schedule.

Crawl only the SharePoint site of each start address

SharePoint sites

You want to include the content on the site itself.

-or-

You want to crawl all content under the start address on the same schedule.

Crawl everything under the host name of each start address

Web sites

Content on the site itself is relevant.

-or-

Content available on linked sites is not likely to be relevant.

Crawl only within the server of each start address

Web sites

Relevant content is on only the first page.

Crawl only the first page of each start address

Web sites

You want to limit how deep to crawl the links on the start addresses.

Custom — Specify the number of pages deep and number of server hops to crawl

Note:

We recommend you start with a small number on a highly connected site because specifying more than three pages deep or more than three server hops can crawl the entire Internet.

File shares

Exchange public folders

Content available in the subfolders is not likely to be relevant.

Crawl only the folder of each start address

File shares

Exchange public folders

Content in the subfolders is likely to be relevant.

Crawl the folder and subfolder of each start address

Business data

All applications that are registered in the Business Data Catalog contain relevant content.

Crawl the entire Business Data Catalog

Business data

Not all applications that are registered in the Business Data Catalog contain relevant content.

-or-

You want to crawl some applications on a different schedule.

Crawl selected applications

Plan file-type inclusions and IFilters

Content is only crawled if the relevant file name extension is included in the file-type inclusions list and an IFilter is installed on the index server that supports those file types. Several file types are included automatically during initial installation. When you plan for content sources in your initial deployment, determine whether content you want to crawl uses file types that are not included. If file types are not included, you must add those file types on the Manage File Types page during deployment and ensure that an IFilter is installed and registered to support that file type.

Office SharePoint Server 2007 provides several IFilters, and more are available from Microsoft and third-party vendors. For information about how to install and register additional IFilters that are available from Microsoft, see How to register Microsoft Filter Pack with SharePoint Server 2007 and with Search Server 2008 (http://go.microsoft.com/fwlink/?LinkId=110532). If necessary, software developers can create IFilters for new file types.

On the other hand, if you want to exclude certain file types from being crawled, you can delete the file name extension for that file type from the file type inclusions list. Doing so excludes file names that have that extension from being crawled.

The following table lists which file types are supported by the IFilters that are installed by default and which file types are enabled on the Manage File Types page by default.

File name extension

Default IFilter support

Default file type inclusions

ascx

Yes

Yes

asm

Yes

No

asp

Yes

Yes

aspx

Yes

Yes

bat

Yes

No

c

Yes

No

cmd

Yes

No

cpp

Yes

No

css

Yes

No

cxx

Yes

No

def

Yes

No

dic

Yes

No

doc

Yes

Yes

docm

Yes

Yes

docx

Yes

Yes

dot

Yes

Yes

eml

Yes

Yes

exch

No

Yes

h

Yes

No

hhc

Yes

No

hht

Yes

No

hpp

Yes

No

hta

Yes

No

htm

Yes

Yes

html

Yes

Yes

htw

Yes

No

htx

Yes

No

jhtml

No

Yes

jsp

No

Yes

lnk

Yes

No

mht

Yes

Yes

mhtml

Yes

Yes

mpx

Yes

No

msg

Yes

Yes

mspx

No

Yes

nsf

No

Yes

odc

Yes

Yes

one

No

No

php

No

Yes

pot

Yes

No

pps

Yes

No

ppt

Yes

Yes

pptm

Yes

Yes

pptx

Yes

Yes

pub

Yes

Yes

stm

Yes

No

tif

Yes

Yes

tiff

No

Yes

trf

Yes

No

txt

Yes

Yes

url

No

Yes

vdx

No

Yes

vsd

No

Yes

vss

No

Yes

vst

No

Yes

vsx

No

Yes

vtx

No

Yes

xlb

Yes

No

xlc

Yes

No

xls

Yes

Yes

xlsm

Yes

Yes

xlsx

Yes

Yes

xlt

Yes

No

xml

Yes

Yes

IFilters and Microsoft Office OneNote

An IFilter is not provided for the .one file name extension used by Microsoft Office OneNote. If you want users to be able to search content in Office OneNote files, you must install an IFilter for OneNote. To do this, you must do one of the following.

•      Install the Microsoft Office OneNote 2007 client application on the index server.

The IFilter provided by Office OneNote 2007 can be used to crawl both Office OneNote 2003 and Office OneNote 2007 files. The IFilter installed by Office OneNote 2003 can crawl Office OneNote 2003 files only. For more information, see Install and register the OneNote IFilter (Office SharePoint Server 2007).

•      Install and register the Microsoft Filter Pack.

The OneNote IFilter provided by this filter pack can be used to crawl Office OneNote 2007 files only. For more information, see How to register Microsoft Filter Pack with SharePoint Server 2007 and with Search Server 2008 (http://support.microsoft.com/?id=946336.)

Worksheet action

Record the decisions you make about file-type inclusions and IFilters for your initial deployment in the File-type inclusions and IFilters section of the Plan to crawl content worksheet (http://go.microsoft.com/fwlink/?LinkID=73748&clcid=0x409).

Limit or exclude content by using crawl rules

When you add a start address to a content source and accept the default behavior, all subsites or folders below that start address are crawled unless you exclude them by using one or more crawl rules.

For more information about crawl rules, see Plan crawl rules later in this article.

Other considerations when planning content sources

You cannot crawl the same addresses using multiple content sources. For example, if you use a particular content source to crawl a site collection and all of its subsites, you cannot use a different content source to crawl one of those subsites separately on a different schedule. To accommodate this restriction, you might need to crawl some of these sites separately. Consider the following scenario:

The SSP administrator at Contoso wants to crawl http://contoso, which contains the http://contoso/sites/site1 and http://contoso/sites/site2 subsites. He wants to crawl http://contoso/sites/site2 on a different schedule than the other sites. To achieve this, he adds the addresses http://contoso and http://contoso/sites/site1 to one content source and selects the Crawl only the SharePoint site of each start address setting. He then adds http://contoso/sites/site2 to another content source and specifies a different schedule for that content source.

In addition to crawl schedules, there are other things to consider when planning content sources. For example, whether you group start addresses in a single content source or create additional content sources to crawl those start addresses depends largely upon administration considerations. Administrators often make changes that require a full update of a particular content source. Changes to a content source require a full crawl of that content source. To make administration easier, organize content sources in such a way that updating content sources, crawl rules, and crawling content is convenient for administrators.

Content sources summary

Consider the following when planning your content sources:

•      A particular content source can be used to crawl only one of the following content types: SharePoint sites, Web sites that are not SharePoint sites, file shares, Exchange public folders, Lotus Notes databases, and business data.

•      Shared services administrators can create up to 500 content sources in each SSP, and each content source can contain up to 500 start addresses. To keep administration as simple as possible, you should create only as many content sources as you absolutely need.

•      Each URL in a particular content source must be of the same content source type.

•      For a particular content source, you can choose how deep to crawl from the start addresses. These configuration settings apply to all start addresses in the content source. The available choices on how deep you can crawl the start addresses differ depending upon the content source type that is selected.

•      You can schedule when to perform either a full or incremental crawl for the entire content source. For more information about scheduling crawls, see "Full and incremental crawl schedules" earler in this article.

•      Shared services administrators can modify the default content source, create additional content sources for crawling other content, or both. For example, they can configure the default content source to also crawl content on a different server farm or they can create a new content source to crawl other content.

•      To effectively crawl all the content needed by your organization, use as many content sources as make sense for the types of sources you want to crawl, and for the frequency at which you plan to crawl them.

Plan for authentication

When the crawler accesses the start addresses that are listed in content sources, the crawler must be authenticated by and granted access to the servers that host that content. This means that the domain account used by the crawler must have at least read permission to the content.

The default content access account is the account that is used by default when crawling content sources. This account is specified by the shared services administrator. Alternatively, you can use crawl rules to specify a different content access account to use when crawling particular content. Regardless whether you use the default content access account or a different content access account specified by a crawl rule, the content access account that you use must have read access to all content that is crawled, or the content is not crawled and is not available to queries.

We recommend that you select a default content access account that has the broadest access to most of your crawled content, and only use other content access accounts when security considerations require separate content access accounts. For information about creating a separate content access accounts to crawl content that cannot be read using the default content access account, see Plan crawl rules later in this article.

For each content source you plan, identify the start addresses that cannot be accessed by the default content access account and plan to add crawl rules for URL patterns that encompass those start addresses.

Note:

Ensure that the domain account used for the default content access account or any other content access account is not the same domain account that is used by an application pool associated with any Web application you crawl. Doing so can cause unpublished content in SharePoint sites and minor versions of files (history) in SharePoint sites to be crawled and indexed.

For more information about the planning considerations for content access accounts, see Plan crawl rules later in this article.

Worksheet action

Record the default content access account that the crawler will use when crawling content in the Default content access account section of the Plan to crawl content worksheet (http://go.microsoft.com/fwlink/?LinkID=73748&clcid=0x409).

Another important consideration is that the crawler must use the same authentication method as the host server. By default, the crawler attempts to authenticate using NTLM authentication. You can configure the crawler to use a different authentication method, if necessary. For more information, see "Authentication requirements for crawling content" in Plan authentication methods (Office SharePoint Server).

Plan protocol handlers

All content that is crawled requires the use of a protocol handler to gain access to that content. Office SharePoint Server 2007 provides protocol handlers for all common Internet protocols. However, if you want to crawl content that requires a protocol handler that is not installed with Office SharePoint Server 2007, you must install the third-party or custom protocol handler before you can crawl that content.

The following table shows the protocol handlers that are installed by default.

Protocol handler

Used to crawl

Bdc

Business Data Catalog

Bdc2

Business Data Catalog URLs (internal protocol)

File

File shares

http

Web sites

https

Web sites over Secure Sockets Layer (SSL)

Notes

Lotus Notes databases

Rb

Exchange public folders

Rbs

Exchange public folders over SSL

Sps

People profiles from Windows SharePoint Services 2.0 server farms

Sps3

People profile crawls of Windows SharePoint Services 3.0 server farms only

Sps3s

People profile crawls from Windows SharePoint Services 3.0 server farms only over SSL

Spsimport

People profile import

Spss

People profile import from Windows SharePoint Services 2.0 server farms over SSL

Sts

Windows SharePoint Services 3.0  root URLs (internal protocol)

Sts2

Windows SharePoint Services 2.0 sites

Sts2s

Windows SharePoint Services 2.0 sites over SSL

Sts3

Windows SharePoint Services 3.0 sites

Sts3s

Windows SharePoint Services 3.0 sites over SSL

Worksheet action

Record the decisions you make about protocol handlers for your initial deployment in the Protocol handlers section of the Plan to crawl content worksheet (http://go.microsoft.com/fwlink/?LinkID=73748&clcid=0x409).

Plan to manage the impact of crawling

Crawling content can significantly decrease the performance of the servers that host the content. The impact that this has on a particular server varies depending upon the load that the host server is experiencing and whether the server has sufficient resources (particularly CPU and RAM) to maintain service level agreements under normal or peak usage.

Crawler impact rules enable farm administrators to manage the impact your crawler has on the servers being crawled. For each crawler impact rule, you can specify a single URL or use wildcard characters in the URL path to include a block of URLs to which the rule applies. You can then specify how many simultaneous requests for pages are made to the specified URL or choose to request only one document at a time and wait a number of seconds that you choose between requests.

Crawler impact rules reduce or increase the rate at which the crawler requests content from a particular start address or range of start addresses (sometimes called a site name), regardless of the content source used to crawl those addresses. The following table shows the wildcard characters that you can use in the site name when adding a rule.

Wildcard to use

Result

* as the site name

Applies the rule to all sites.

*.* as the site name

Applies the rule to sites with dots in the name.

*.site_name.com as the site name

Applies the rule to all sites in the site_name.com domain (for example, *.adventure-works.com).

*.top-level_domain_name as the site name

Applies the rule to all sites that end with a specific top-level domain name, for example, *.com or *.net.

?

Replaces a single character in a rule. For example, *.adventure-works?.com applies to all sites in the domains adventure-works1.com, adventure-works2.com, and so on.

You can create a crawler impact rule that applies to all sites within a particular top-level domain. For example, *.com applies to all Internet sites with addresses that end in .com. For example, an administrator of a portal site might add a content source for samples.microsoft.com. The rule for *.com applies to this site unless you add a crawler impact rule specifically for samples.microsoft.com.

For content within your organization that other administrators are crawling, you can coordinate with those administrators to set crawler impact rules based on the performance and capacity of the servers. For most external sites, this coordination is not possible. Requesting too much content on external servers or making requests too frequently can cause administrators of those sites to limit your future access if your crawls are using too many resources or too much bandwidth. Therefore, the best practice is to crawl more slowly. In this way, you can mitigate the risk of losing access to crawl the relevant content.

During initial deployment, set the crawler impact rules to make as small an impact on other servers as possible while still crawling enough content frequently enough to ensure the freshness of the crawled content.

During the operations phase, you can adjust crawler impact rules based on your experiences and data from crawl logs.

Worksheet action

Record the decisions you make about crawler impact rules for your initial deployment in the Crawler impact rules section of the Plan to crawl content worksheet (http://go.microsoft.com/fwlink/?LinkID=73748&clcid=0x409).

Plan crawl rules

Crawl rules apply to a particular URL or set of URLs represented by wildcards (also referred to as the path affected by the rule). You use crawl rules to do the following things:

•      Avoid crawling irrelevant content by excluding one or more URLs. This also helps to reduce the use of server resources and network traffic, and to increase the relevance of search results.

•      Crawl links on the URL without crawling the URL itself. This option is useful for sites with links of relevant content when the page containing the links does not contain relevant information.

•      Enable complex URLs to be crawled. This option crawls URLs that contain a query parameter specified with a question mark. Depending upon the site, these URLs might or might not include relevant content. Because complex URLs can often redirect to irrelevant sites, it is a good idea to enable this option on only sites where the content available from complex URLs is known to be relevant.

•      Enable content on SharePoint sites to be crawled as HTTP pages. This option enables the index server to crawl SharePoint sites that are behind a firewall or in scenarios in which the site being crawled restricts access to the Web service used by the crawler.

•      Specify whether to use the default content access account, a different content access account, or a client certificate for crawling the specified URL.

Note:

Crawl rules apply simultaneously to all content sources in the SSP.

Often, most of the content for a particular site address is relevant, but not a specific subsite or range of sites below that site address. By selecting a focused combination of URLs for which to create crawl rules that exclude unneeded items, shared services administrators can maximize the relevance of the content in the index while minimizing the impact on crawling performance and the size of search databases. Creating crawl rules to exclude URLs is particularly useful when planning start addresses for external content, the impact on resource usage of which is not under the control of people in your organization.

When creating a crawl rule, you can use standard wildcard characters in the path. For example:

•      http://server1/folder* contains all Web resources with a URL that starts with http://server1/folder.

•      *://*.txt includes every document with the .txt file name extension.

Because crawling content consumes resources and bandwidth, it is better to include a smaller amount of content that you know is relevant than a larger amount of content that might be irrelevant. After the initial deployment, you can review the query and crawl logs and adjust content sources and crawl rules to be more relevant and include more content.

Specify a different content access account

For crawl rules that include content, administrators have the option of changing the content access account for the rule. The default content access account is used unless another account is specified in a crawl rule. The main reason to use a different content access account for a crawl rule is that the default content access account does not have access to all start addresses. For those start addresses, you can create a crawl rule and specify an account that does have access.

Note:

Ensure that the domain account used for the default content access account or any other content access account is not the same domain account that is used by an application pool associated with any Web application you crawl. Doing so can cause unpublished content in SharePoint sites and minor versions of files (history) in SharePoint sites to be crawled and indexed.

Worksheet action

Record the decisions you make about crawl rules for your initial deployment in the Crawl rules section of the Plan to crawl content worksheet (http://go.microsoft.com/fwlink/?LinkID=73748&clcid=0x409).

Plan search settings that are managed at the farm level

In addition to the settings that are configured at the SSP level, several settings that are managed at the farm level affect how content is crawled. Consider the following farm-level search settings while planning for crawling:

•      Contact e-mail address: Crawling content affects the resources of the servers that are being crawled. Before you can crawl content, you must provide in the configuration settings the e-mail address of the person in your organization whom administrators can contact in the event that the crawl adversely affects their servers. This e-mail address appears in logs for administrators of the servers being crawled so that those administrators can contact someone if the impact of crawling on their performance and bandwidth is too great, or if other issues occur.

The contact e-mail address should belong to a person who has the necessary expertise and availability to respond quickly to requests. Alternatively, you can use a closely monitored distribution-list alias as the contact e-mail address. Regardless of whether the content crawled is stored internally to the organization or not, quick response time is important.

•      Proxy server settings: You can choose whether to use a proxy server when crawling content. The proxy server to use depends upon the topology of your Office SharePoint Server 2007 deployment and the architecture of other servers in your organization.

•      Time-out settings: The time-out settings are used to limit the time that the search server waits while connecting to other services.

•      SSL setting: The Secure Sockets Layer (SSL) setting determines whether the SSL certificate must exactly match to crawl content.

Worksheet action

Record the decisions you make about farm-level search settings for your initial deployment in the Farm-level search settings section of the Plan to crawl content worksheet (http://go.microsoft.com/fwlink/?LinkID=73748&clcid=0x409).

Indexing content in different languages

When crawling content, the crawler determines each individual word in the content it finds. Languages that have words separated by spaces make it relatively easy for the crawler to distinguish each word. In other languages, finding the boundary between words can be more complex.

Office SharePoint Server 2007 provides word breakers and stemmers by default to help crawl and index content in many languages. Word breakers find word boundaries in full-text indexed data, while stemmers conjugate verbs.

If you are crawling any of the languages in the table listed below, Office SharePoint Server 2007 automatically uses the appropriate word breaker and stemmer for that language. An asterisk (*) indicates that the stemming feature is on by default.

Language supported by default

Language supported by default

Arabic

Lithuanian*

Bengali

Malay

Bulgarian*

Malayalam*

Catalan

Marathi

Croatian

Norwegian_Bokmaal

Czech*

Polish*

Danish

Portuguese

Dutch

Portuguese_Brazilian

English

Punjabi

Finnish*

Romanian*

French*

Russian*

German*

Serbian_Cyrillic*

Greek*

Serbian_Latin*

Gujarati

Slovak*

Hebrew

Slovenian*

Hindi

Spanish*

Hungarian*

Swedish

Icelandic*

Tamil*

Indonesian

Telugu*

Italian

Thai

Japanese

Turkish*

Kannada*

Ukrainian*

Korean

Urdu*

Latvian*

Vietnamese

When the crawler indexes content for a language that is not supported, the neutral breaker is used. If the neutral breaker does not give you the results you expect, you can try third-party solutions that work with Office SharePoint Server 2007.

As a best practice, be sure that you install the appropriate word breaker and stemmer for each of the languages that you need to support. Word breakers and stemmers must be installed on all of the servers that are running the Office SharePoint Server Search service.

For more information about word breakers and stemmers, see Plan for multilingual sites.

Worksheet action

Record the decisions you make about word breakers and stemmers for your initial deployment in the Word breakers and stemmers section of the Plan to crawl content worksheet (http://go.microsoft.com/fwlink/?LinkID=73748&clcid=0x409).

Worksheet

If you have not already done so, record your planning decisions about content sources and other decisions about crawling content in the following worksheet:

•      Plan to crawl content worksheet (http://go.microsoft.com/fwlink/?LinkID=73748&clcid=0x409)

If you decide to create only some of the planned content sources and crawl rules during initial deployment and configuration, you can use this worksheet as part of ongoing operations.

Plan the end-user search

In this article:

•      Plan what users see when performing a query

•      Plan what users see in search results

Search administrators can improve the relevance and presentation of search results by carefully planning the end-user search experience. The goal of such planning is to create a search experience that enables users to quickly find the information they need. This article contains information that can help Shared Services Provider (SSP) administrators and site collection administrators optimize the end-user search experience.

The first section of this article discusses:

•      The search user interface for performing search queries.

•      How to plan for custom scopes. This includes information about the default scopes that users use to filter the content included in each search query. Administrators can use this information to help identify when your organization might need to create custom scopes. This subsection also discusses how to plan any necessary custom scopes.

•      Advanced searches and how properties can be used to filter search results. Administrators can use this information to understand the options they have for managing keywords and properties to optimize users' ability to perform powerful advanced searches.

•      The benefit of using property searches with scopes. This includes how crawled properties relate to managed properties and how to plan for them.

The second section of this article covers search results pages and the features that administrators can control that affect what users see in search results. The section discusses:

•      How to plan for keywords and best bets. This includes how to plan for effective keywords, best bets for a particular organization and how associating synonyms with keywords can enhance the end-user experience.

•      How administrators can control the relevance ranking of particular sites to improve the relevance of search results.

•      Describes the new federated locations feature that can be used to search multiple sources and combine results into a single search results page. This feature requires the Infrastructure Update for Microsoft Office Servers. For more information, see Install the Infrastructure Update for Microsoft Office Servers (Office SharePoint Server 2007).

•      How to control how links appear in search results.

•      How to plan for search-based alerts.

The abilities described in this article enable administrators to have a great deal of control of the end-user search experience. Although we recommend that you constantly evaluate the effectiveness of search queries during regular operations, good planning before the initial deployment can help create effective search queries from the start and reduce future administration costs.

Plan what users see when performing a query

To effectively plan for the configuration choices that help you realize your goal of helping users find the content for which they are searching, it helps to first consider what end users see in the user interface.

Search user interface levels

To understand how to plan the end-user search experience, it is helpful to first become familiar with the user interface that end users use when performing queries. As you might expect, this user interface is straightforward. The focal point of this user interface is a search box where users can enter search queries. A search box is provided on all non-administrative pages in the site collection and also in the Search Center. For example, the search box appears, by default, at the site level and the list level. The following sections describe search user interface at each level of the site collection.

Site-level search user interface

The site-level search box (callout 2) is a text box on the top-right corner of Web site pages in which users can type their search queries. After users type a query, they click the Go Search button (callout 3) to run the query. Advanced users can click the Advanced Search link (callout 4) to use the Advanced Search page to construct queries. Information about the Advanced Search page is provided later in this article.

The first thing you might expect users to ask when looking at a search box in a user interface is, "What body of content will my query be run against?" The Search Scope list to the left of the search box (callout 1) specifies the body of information in the content index that the query will be run against.

Note:

Search scopes, also referred to as scopes, define the items in the index against which a search query is run. The scope determines, in part, what items are displayed on the search page for a particular query.

This enables users to perform queries against subsets of content in the content index, which improves the relevance of their search results.

List-level search user interface

The search user interface at the list and library levels looks and functions the same as the site-level search user interface, except that an additional default scope, called This List, is available. The list-level search box is at the top-right corner of each list and library in all site collections. The Search Scope list is set to the All Sites scope by default, but users can select another scope from the list.

Search Center search user interface

The Search Center provides a centralized and highly customizable user interface in which users can perform search queries. The Search Center consists of a search box for entering search queries, and a link to an Advanced Search page so users can construct advanced search queries. By default, the search box is set to the All Sites scope so users search across all content in the index. However the People scope, used to search for people in your organization, is also available on a separate tab. Administrators can choose to add tabs and associate them with custom scopes that users can use to query over different subsets of content.

Users go to the Search Center by clicking the Search tab on the top link bar (callout 1). Similar to the search box at the site-level, the search box in the Search Center (callout 3) is a text box in which users can type their search queries. Users then click the Go Search button (callout 4) to run their queries. By default, the All Sites scope is selected but a user can select another available tab, such as the People tab, to use a different scope to search.

Advanced users can click the Advanced Search link (callout 5) to use the Advanced Search page to construct queries. The Search Center uses the same Advanced Search page as the site-level search box. Information about the Advanced Search page is provided later in this article.

Unlike the site-level search box, the search box in the Search Center does not have an adjoining Search Scope list to the left of it, by default, for selecting different scopes. Instead, users click the tab (callout 2) that corresponds to the scope with which they want to search. Office SharePoint Server 2007 provides two default scopes in the Search Center: All Sites and People.

Note:

The site owner of the Search Center site can add an adjoining Search Scope list to a search box by editing the Search Box Web part.

The following table shows the default scopes that are available in Office SharePoint Server 2007 and the levels at which they are available.

This scope

Enables users to

At this level

Customizable?

All Sites

Search across all content in the index

Search Center

Top-level site

Subsite

Lists and libraries

Yes

People

Search for people

Search Center

Top-level site

Subsite

Lists and libraries

Yes

This Site: Site name

Search across the current site and all of its subsites

Top-level site

Subsite

Lists and libraries

No

This List: List name

Search across the current list

Lists and libraries

No

Note:

The All Sites scope is the default scope at all levels in each site collection. However, users can select any available scope.

Plan custom scopes

To understand when your organization might need to supplement the default scopes with custom scopes, you must first have knowledge of the default scopes. This section provides information about the default scopes provided with Microsoft Office SharePoint Server 2007. You can use custom scopes with scope rules to group certain content in the index into a set of content on which queries can be run. For example, you can make it possible to search a specific set of Web sites, or all Word documents that were authored by a particular person or were authored during a particular period of time, or any combination of these parameters.

Scopes that you create at the SSP level are called shared scopes because they are shared with all site collections that use that SSP. Site collection administrators decide which shared scopes to use and how to display them.

You can also create custom scopes at the site collection level, which makes the custom scopes available only to the site collection on which they were created. Scopes created at this level are sometimes called site-collection-level scopes.

Scope scenario

During content and site structure planning for a large organization, it is determined that human resources is a large division that delivers content relevant to all employees on several SharePoint sites and line-of-business applications. Therefore, the SSP administrator creates a shared scope for content relating to human resources.

The site collection administrator of the human resources site uses that shared scope and creates additional scopes at the site collection level. The site-collection-level scopes are for company policies and new hire information because those are core concepts that are relevant for the site collection. The site-collection-level scopes do not make sense as shared scopes because people searching in other site collections are unlikely to want scopes that are so specific.

Site collection administrators can either use the shared scopes as defined by the shared services administrator or copy the shared scopes they want to use in their site collection and modify them. They can then select the display groups in which to include each scope, such as the search box drop-down list and the Advanced Search page.

Note:

Site collection administrators cannot modify or delete shared scopes, but they can copy a shared scope and then modify the copy.

To summarize, SSP and site collection administrators first create the scopes that are needed for their organization and then a site collection administrator associates them with display groups to make them available to the search boxes that are associated with those display groups. Site collection administrators can associate one or more scopes with a display group. More information about display groups is presented later in this article.

When planning search scopes, you look at your information architecture to identify broad content sets on which people are likely to want to search. (For more information, see Determine the information architecture of your site.) Some of these content sets will span the information architecture across many sites, and some will span subsets of information within site collections. Site collection administrators decide whether to implement shared scopes or site-collection-level scopes for a particular site collection based on the needs of the users of that site collection. Content that is only relevant within certain site collections should be left for scope planning at the site collection level.

Plan shared scopes

Because certain site collections are tied to a particular SSP, all settings for a particular SSP affect all of its associated sites. The SSP administrator manages shared scopes for all sites that use the same SSP. SSP administrators can perform the following tasks:

•      Create and edit shared scopes.

•      Add scope rules to shared scopes.

•      Delete shared scopes.

•      Refresh changes made to scopes.

Shared scopes are visible and available for use by administrators for all site collections that are using the same set of shared services.

The following shared scopes are automatically created for each SSP and are available on the Search Center, by default:

•      All Sites

•      People

Plan scopes for site collections

During planning, each site collection administrator will want to create scopes based on the information architecture within the site. They can choose to create new scopes, make a copy of shared scopes (a copy of a shared scope becomes a site collection level scope), or both. For example, site collection administrators can add scopes by selecting shared scopes that are useful for people using their site collection, and then supplementing those scopes by creating scopes for the site collection.

The following table shows the actions related to scopes that can be performed by site collection administrators.

Site collection administrators can perform these actions on shared scopes

Site collection administrators can perform these actions on site-collection-level scopes

•      Choose how to display search scopes (search dropdown, advanced search, or both).

•      Copy and modify a shared scope to use as a scope for the site collection.

•      View the status. For example what scope rules they contain and the order in the scopes list in which they appear.

•      Choose how to display search scopes (search dropdown, advanced search, or both).

•      Create site collection level scopes.

•      Edit site collection level scopes (more information provided below).

•      Add scope rules.

•      Delete site collection level scopes.

•      View the status. For example what scope rules they contain and the order in the scopes list in which they appear.

Site collection administrators cannot create or add matching rules to shared scopes directly, though they can copy a shared scope as a site-collection scope and modify the copy.

Note:

After a site collection administrator copies a shared scope, the copy becomes a site-collection-level scope that the site collection administrator can use to perform any of the actions that they can perform on any other site-collection-level scope.

When creating or editing a new site-collection-level scope, you specify the following:

•      Unique title.

•      Description for the scope (optionally).

•      Display group, sometimes called scope group. Site collection administrators can assign scopes to display groups to determine where they appear on the site. By default, Office SharePoint Server 2007 provides display groups for the search box drop-down list and the Advanced Search page. Site collection administrators can assign one or more scopes to any display group.

•      Results page. You can choose to use the default search results page to display search results when this scope is used or specify a different page. Note that if you choose to use a different page, you must first create that search results page.

No site collection level scopes exist, by default, but each site collection has access to all shared scopes.

Plan display groups

Display groups provide a way to assign scopes to a particular search box. Site collection administrators have several options for configuring the existing display groups or they can choose to create one or more new display groups. Typically, a site owner identifies a particular need for a display group. For example, users of a particular team site might frequently need to search for content that is scattered across multiple document libraries. To narrow the body of content they are searching over, they currently must perform separate searches in different search boxes —for example, in the search box of each library — or construct an advanced query to filter the search results. To provide users with an easier way to perform this frequent search, the site collection administrator creates a display group and assigns the appropriate scope to it. Site Owners can then associate this display group with a particular search box — for example, a search box on a custom search page on the site. Users then use that search box to search over the content defined by the scope, in this case, the document libraries. Office SharePoint Server 2007 provides two display groups, by default:

•      Search Dropdown   The All Sites and People scopes are assigned to this display group and it is used by the search box, by default.

•      Advanced Search   The All Sites scope is assigned to this display group and it is used by the search box on the Advanced Search page, by default.

Site collection administrators can perform the following actions:

•      Add scopes to any display group.

•      Remove scopes from any display group.

•      Create new display groups and assign the scopes they want to them.

•      Change the order in which scopes appear in the Search Scopes list.

•      Specify which scope is selected, by default, in the Search Scopes list.

Site owners can perform the following:

•      Assign different display groups to the search box and the Advanced Search page in the Search Center site.

•      Create new search pages using the Search Box and Advanced Search Box Web parts and assign the display group or groups that they want to use.

Plan scope rules

You define a scope by adding scope rules to the scope. Scope rules define what content to associate with the scope and what content to not associate with it. Scope rules added to a particular scope define the extent of the scope.

Each scope rule is based upon a particular scope rule type, which defines the properties, locations, and sources of content. The following table lists the scope rule types that are available to shared search scopes and site-collection-level search scopes.

This scope rule type

Is available to shared search scopes

Is available to site-collection-level search scopes

Tests content by

Web address (http://server/site)

Yes

Yes

Location

Property Query
(Author = John Doe)

Yes

Yes

Single property

Content Source

Yes

No

A particular content source

All Content

Yes

Yes

All content in the content index

The All Content scope rule type is the simplest because it associates all crawled content with the scope. For each of the other three scope rule types, an SSP administrator can specify the behavior of the scope rule which determines the content to associate with the scope. These behaviors are described in the following list:

•      Include   Items matching this rule appear in search results unless another rule removes them. When combining rules, this behavior is similar to the OR logical operator.

•      Require   Items matching other rules must also match this rule to appear in search results. This behavior is equivalent to the AND logical operator.

•      Exclude   Items matching this rule are excluded from search results even if they match other rules. This behavior is equivalent to the AND NOT logical operator.

Scopes will often be based on a single scope rule. However, there are good reasons to use scopes with multiple rules. You can create scopes based around a specific theme or conceptually-related set of content. To do this, you can include and exclude several locations, properties, or a combination of locations and properties that are conceptually related. The logical combination of rules determines the content that is either included or excluded from the scope.

Using scope rules that are based on location

You can create rules based on the location (Web address or UNC path) of content using the Web Address scope rule type. Several usage scenarios require rules of this kind, including searching for content in the following locations:

•      In a group of document libraries.

•      Within a set of folders in a single large document repository, for example, when searching a company archive.

•      On external sites for a particular subject.

•      On other servers in your organization.

Each Web address scope rule contains a single location, defined by a single folder, domain name, or server name. Depending on what set of content you want to make available in a scope, you add matching rules until all relevant locations are included in the scope and all irrelevant locations are excluded. Examine the information architecture and site structure planning to help you decide which locations to include in each scope.

Using scope rules that are based on managed properties

You can base scope rules on a specific value for a single managed property using the Property Query scope rule type. Before you create such a scope rule, verify that:

•      The managed property that you want to use exists, either because it is a default managed property or was created by an SSP administrator.

•      The managed property is configured to be available for use in scopes. Several managed properties are created but only a few are configured to be available for use in scopes, by default. Only managed properties that SSP administrators have specifically made available for scopes can be used in search scopes.

Note:

SSP administrators can enable a property to be available for use in scopes by using the Edit Managed Property page for the particular property.

After the scope rule is created, each item of content that matches the property query is tested against that specific value and included or excluded based on the rule. Rules based on properties can only be queried by using the Is exactly operator and not against other operators such as Contains.

For example, a site collection administrator for a sales portal site can create scopes for each sales office by using the SalesOffice managed property and setting the value for the rule in each scope to the value for the relevant office. Because this managed property is used to define the scope, the search results will include only content for the sales office when using this scope.

When your organization plans the managed properties for your SSP, consider scopes. To create a scope for a certain set of content, you must ensure that there are properties of that content that are mapped to managed properties that can be included in scope rules.

Using scope rules that are based on a content source

There are several reasons an SSP administrator might create additional content sources. They are typically created to crawl content on a different schedule than other content. Often an SSP administrator will create a separate content source to crawl content that is on a different SharePoint farm or on a file share, for example. If a content source exists that already encompasses the content that users what to search over, for example, a file archive, an SSP administrator can create a shared scope with a scope rule (content source type) to enable users to search over that portion of content.

Only shared scopes can contain scope rules that are based on a specific content source. This scope rule type is not available to scopes at the site collection level. Your content source planning can help you identify sets of content that are easier to administer when they are on separate content sources.

For each content source that you plan, consider whether the content that was indexed using that content source is something that would make sense grouped together in a shared scope for people using the site collection. If so, you can add a scope rule for that content source.

Also consider if the content source can be divided up into smaller bodies of content that people might want to search for. If so, you can combine scope rules to specify the content source with other scope rule types to create a narrower scope.

For more information about planning for content sources, see Plan to crawl content.

Using the All Content scope rule type

When you create a scope rule using the All Content scope rule type, all content in the content index is available to the scope. If you want to create a narrower scope, you can add scope rules to a scope that uses the All Content scope rule type to exclude particular content from the scope.

Excluding content using a scope rule with the exclude behavior

The All Sites shared scope can be copied and used as a starting point to include all content in the content index. Then you can add scope rules that exclude content from search results to create scopes that are broad but do not include a certain set of search results. It is sometimes easier to use a copy of the All Sites shared search scope with exclusion rules than to create a complex search scope containing rules that include every subset of content on the site.

Regardless of whether you start with a copy of the All Sites shared scope or another scope, you might want to consider adding scope rules that exclude content as a separate step from adding scope rules that include content because reasons to exclude content from search results can differ substantially from the reasons to include content.

Example of scope planning

Contoso Corporation has an IT services division, a customer service division, and a sales division. Each of these three divisions has its own site collection, and there is also a central portal site collection for company news and human resources information. All crawled content is indexed into one content index.

Because the content for each division is distinct, the SSP administrator creates a separate content source for each of the three divisional site collections so each can be crawled on a different schedule. The SSP administrator also creates a fourth content source used for crawling the central portal site collection that contains the human resources and company news content.

By default, all content that has been indexed from each of the site collections is included in the All Sites shared scope that is available to all site collections. The SSP administrator creates a separate shared scope for each divisional site collection and then creates a scope rule for each shared scope that includes the appropriate content source for each site collection's shared scope.

For example, for the Customer Service division, the SSP administrator creates a scope called Customer Service, and then adds a scope rule to that scope. When adding the scope rule, the SSP administrator selects Content Source as the scope rule type, selects the Customer Service content source from the list of available content sources, and then selects the include behavior to include all items crawled using that content source.

Note:

All existing content sources appear in the Content Source list on the Add Scope Rule page when creating a scope rule based on a content source.

The following table lists the shared scopes that have been created by the SSP administrator at Contoso Corporation.

This shared scope

Contains this content

Services division

All content on the IT Services site collection that was crawled using the Services Division content source.

Customer Service

All content on the Customer Service site collection that was crawled using the Customer Service content source.

Sales

All content on the Sales site collection that was crawled using the Sales content source.

Central Portal

All content on the Central Portal site collection that was crawled using the Customer Service content source.

In addition to the shared scopes created by the SSP administrator, the default All Sites scope includes all of the crawled content in the index. The All Sites shared scope is available, by default, to all site collections.

The site collection administrator for each division decides to use the All Sites shared scope and the shared scope that contains the content for their site collection, but none of them plans to use the Central Portal scope, even though it is a shared scope. That option will only be available from the Search Scope drop-down list in the central portal site collection.

The site collection administrator for each division makes copies of the shared scope that the SSP administrator created for their site collection. (The copies of the shared scope become site collection-level scopes.) Each site collection administrator then adds scope rules to the site collection-level scopes to target only the most important set of content that their users want to query against when using those scopes.

For example, the site collection administrator for the sales site collection creates scopes for content related to each product line, based on the managed properties of marketing documents and other content, and the location of related team sites and document libraries.

Worksheet action

Record your decisions about scopes, scope rules, and display groups in the "Plan scopes" section of the End-user search experience worksheet (http://go.microsoft.com/fwlink/?LinkId=81039).

Advanced Searches

In many cases, users type a keyword phrase in the search box and then click the Go Search button or press Enter to execute their query. If this technique does not produce the result they are looking for on the first few pages of search results, some users will give up. However, advanced users tend try again by using a more advanced query to target the content they are looking for.

Very advanced users can construct advanced search queries in the search box. For example, to find content that contains the word "negotiate" that was authored by Bob Smith, they could type the following query in the search box:

negotiate author:smith

However, most users are not familiar with the syntax required to construct advanced queries in this way. Therefore, most users construct an advanced query by using the Advanced Search page which enables them to target the content they are searching for using syntax. The following table describes the options on the Advanced Search page that are related to keywords.

Find documents with this option

Does this

All of these words

Searches for content that contains all of the keywords the user types, but the words do not have to be in the content in any particular order.

The exact phrase

Searches for content that contains the words the user types in the exact order.

Any of these words

Searches for content that contains any of the words the user types.

None of these words

Searches for content that contains none of the words the user types.

Users can also use the Advanced Search page to narrow their search to a specific language or document type. Finally, users can select property restrictions to filter their search results based on whether the value of the property they select matches the value that they enter. For example, users can select the Author property, select the Contains inclusion operator, type a value, and then click Search.

Several properties, called managed properties, are provided, by default, such as Author and Title. However, most of the default managed properties are not made available to use in scopes. SSP administrators choose which managed properties they want to make available to scopes and can create additional properties to meet their organization's needs. Managed properties that are enabled by the SSP administrator for use in scopes are available to all site collections.

Plan properties for search

One way to organize content in your site collections in a way that can be effectively searched is to group content that has a common theme in the same location. This way, you can take advantage of the default scopes at the site and list level for searching over your content. For example, you can create a site to store all the information for a particular project. Within that site, you can create separate document libraries and lists to store different kinds of information related to that project. Users use the default This Site scope to search over all content in the site or the This List scope to search on content in a particular list or library in the site. SSP and site collection administrators can create custom scopes as needed for users to search over different portions of content.

Although this is a relatively easy way to organize your content for effective searches, this approach by itself does not meet the needs of all organizations, especially when a large amount of content is being searched. Some reasons for this are:

•      It is not always possible to organize all content with a common theme in the same location.

•      Even if all content with a common theme is organized in the same location at deployment, content can become scattered across a site collection over time.

We recommend that you organize your content by location when it makes sense to do so, and then supplement that organization by using properties.

Managed and crawled properties

When content is crawled, the crawler also crawls the metadata properties associated with that content. Crawled properties include the metadata of content that is stored in files, databases, and line-of-business applications used by your organization. Crawled properties can represent different kinds of information, such as author, title, and e-mail address.

In previous versions of Microsoft SharePoint Products and Technologies, you could reduce property duplication by mapping some properties to other common properties, but many properties confused search results because they weren't relevant. Thus, relevant properties were hard to find amid the many irrelevant properties.

Office SharePoint Server 2007 mitigates this confusion by enabling SSP administrators to create managed properties. They can then map crawled properties, which are the properties that the crawler collects and adds to the property store when crawling content, to managed properties that are used by search queries.

The relationship between managed properties and crawled properties is a simple but powerful one. SSP administrators can map one or more crawled properties (the properties discovered by the crawler) with managed properties (properties that can be used in scope rules and queries. This mapping is important because many crawled properties contain the same kind of metadata and crawled properties often have names that are not intuitive. For example, by default, the crawled properties named "Mail:6" and "Office:4" are mapped to a managed property named Author. This is because the values of these two crawled properties contain the name of the author. This mapping of crawled properties to managed properties eases administration and benefits users. Administrators benefit because they have fewer properties to work with when creating scopes. End users that construct advanced queries in the search box benefit because they also have fewer and more intuitive property names to remember.

Managed properties have the following benefits:

•      Users can use managed properties to construct queries in the search box that filter search results.

•      You can use properties on the Advanced Search page to enable end users to easily filter search results.

•      Site owners can customize the Advanced Search page to use different managed properties.

•      SSP and site collection administrators can create custom scopes with rules that filter search results based on queries. End users benefit from advanced property-based queries without the need to learn how to construct an advanced query.

Several managed properties are created and mapped to crawled properties, by default. SSP administrators can map additional crawled properties to existing managed properties and create new managed properties.

Using properties in queries

For the value of crawled properties to affect a search query, the crawled properties must be mapped to a managed property and the user must perform a search against that managed property. Including the values of too many crawled properties can have a negative effect on search relevance and performance.

If you want to use the manage property in a scope, you must make the managed property available to scopes. However, you do not need to do this to use the managed property on the Advanced Search page or as part of a query in a search box.

Administrators planning the initial deployment of Office SharePoint Server 2007 should record the initial set of managed properties planned for the search service for every SSP used in the deployment.

Many of these crawled properties can be found by looking at the properties of business data applications and the properties displayed in applications for content types such as Microsoft Office Word or Office Excel documents.

If you have access to a test server, you can crawl high-priority content and use the crawled properties that appear to help with planning.

You can make the content on your site easier to find by carefully planning your managed properties and how you implement them. When planning your deployment, we recommend that you keep the number of managed properties to a minimum. This means carefully considering what properties are most useful for your organization and deploying those as a starting point. You can always create additional managed properties after deployment, if needed.

Plan managed properties

One practical way to identify potential managed properties is to examine your existing content and its high-priority metadata. If you have access to a test farm prior to active deployment of Office SharePoint Server 2007, you can crawl your content and see what crawled properties appear, and use those properties to identify part of your information architecture. However, most organizations will benefit from planning information architecture on paper before staging a deployment, because it can help to focus your planning and identify content and processes that are not as well-organized as they could be.

The key to creating a useful set of managed properties is to determine the most important concepts and find properties in your content that you can map to managed properties that enable users to find relevant content when searching. Mapping more properties increases the size of the search database, and reduces performance accordingly, so it's a good idea to map properties only when you are confident that the mapping is relevant.

It is difficult to discover properties of content without first crawling content. Therefore, it is best to wait to plan managed properties until you already have a good idea of the content of each site collection. Then, on a test server, you can crawl all that content so that you have a list of crawled properties to compare against your information architecture when creating managed properties. It can be difficult to map properties even after crawling content because it is difficult to identify the content type or application that uses the property. If you are unsure of the nature and content of a particular property, you might want to set up a mapping in a test environment and experiment with searches over this property.

Many of the most useful managed properties are automatically created when Office SharePoint Server 2007 is installed. Use these managed properties as a starting point when planning your other managed properties. The automatically created properties include:

•      Author

•      Description

•      Site Name

•      Type

•      File Size

•      Last Modified Date

•      URL

•      Title

Keep in mind that in order to effectively search by using properties, the crawled properties must first be assigned values. For example, if you have a document that has a property that maps to a managed property called Author, and no value is assigned to that property on that document, the document will not be displayed in search results when users query using the Author property for a particular author.

Avoid duplicating managed properties

Some properties are fairly basic and might appear as different properties in different types of content. Examples include the Author and Title properties for documents.

The most important thing you can do with these basic properties during planning is to reduce duplication by creating one set of managed properties and mapping the crawled properties with the same meaning to properties in the set of managed properties. In the case of the Author property, you can map each unique appearance of a crawled property for authors with a single Author managed property.

You can map one or more crawled properties to one or more managed properties.

Tip:

Adding each Author property as a separate managed property doesn't make sense, because it adds additional managed properties to the database without simplifying the user experience.

You can choose to prioritize multiple crawled properties so that if more than one property is found during crawling, only the value of the highest priority property is used for queries using the managed property or properties. If you don't prioritize crawled properties, values for all crawled properties mapped to the managed property are used for queries, so that the managed property becomes multi-valued. This means the search result returns results for all content that contains values for any of the mapped properties that match the query. A sensible approach for a single-value property is to choose the most common crawled property as the managed property, and then prioritize mapped properties by how often they occur. It is not always easy to determine which property is crawled most often, but one strategy is to prioritize properties that you know are associated with commonly used applications.

Be careful when mapping properties that you do not map poorly matched or irrelevant properties because imprecise mappings can actually reduce the relevance of search results. If possible, test searches for managed properties before initial deployment, and plan to review usage data for search queries during normal operations to fine tune the properties you have mapped.

Add properties to present key concepts in the information architecture

In addition to the crawled properties that are mapped to managed properties, by default, other crawled properties might clearly map to concepts in your information architecture that are not already captured by existing managed properties. For example, a company might identify customer service as a key business process in its information architecture. Key concepts associated with customer service in the information architecture might include customers, customer service representatives, and customer service regions.

For each concept in your information architecture, ask yourself if there's a crawled property that represents this concept that can be mapped to a managed property. If so, make the property a managed property.

Scenario

A line-of-business application tracks customer and employee data, and the properties of that data are likely candidates for managed properties after they are registered in the Business Data Catalog and crawled as part of a business data content source. You might also identify crawled properties for applications that should be mapped to these managed properties, for example, a customer service representative identifier (ID) property in a separate data application, or an Author property for an application type used exclusively by customer service representatives. A search query that uses that property or a term associated with that property will include search results for all items containing any of the crawled properties mapped to the Customer service representative ID managed property.

Each major business process identified in the information architecture will have a set of associated file types or business data applications that can be used to identify likely managed properties.

Note that although many concepts in the information architecture aren't represented by properties, those concepts are useful during site structure planning and the implementation of other search features. The information architecture can identify managed properties that you overlooked, but just because a concept is listed in the information architecture doesn't mean that there is or should be a managed property for that concept.

Plan for business data properties

As part of business data search planning, SSP administrators must map the properties of business applications to managed properties. Those properties must be selected as managed properties for business data for an application to appear in search results. The customer service example described previously illustrates mapping business data properties to managed properties used by search. For more information about business data planning, see Plan for business data search.

Worksheet action

Record your decisions about crawled and managed properties in the tables in the "Plan managed properties" section of the End-user search experience worksheet (http://go.microsoft.com/fwlink/?LinkId=81039).

Use managed properties in search scopes

Each managed property can be exposed as a property for search scope rules. For more information about planning search scopes, see the "Plan search scopes" section earlier in this article.

Plan to integrate properties for new file types

Office SharePoint Server 2007 uses property categories to group crawled properties based on the properties that are discovered when the documents are crawled.

For information about property categories associated with file types, see Managing Metadata (http://go.microsoft.com/fwlink/?LinkID=81062). For more information about crawling content, see Plan to crawl content.

Plan what users see in search results

Office SharePoint Server 2007 provides several settings that enable SSP and site collection administrators to control what users see in search results pages. Although you can control the search results in numerous different ways, before deployment we recommend that you:

•      Plan for keywords, best bets, and synonyms.

•      Plan what sites are most and least relevant to control how close they appear to the top of search results.

•      Plan whether to use federated locations and federation Web Parts. This feature requires the Infrastructure Update for Microsoft Office Servers. For more information, see Install the Infrastructure Update for Microsoft Office Servers (Office SharePoint Server 2007).

•      Plan the appearance of links.

•      Plan whether users can use search-based alerts.

Plan keywords, best bets, and synonyms

Keywords, sometimes called keyword phrases, are the words that users type into a search box when constructing a query. When users perform a simple keyword search, for example entering the word "widget" in the search box and clicking the Go Search button, Office SharePoint Server 2007 displays the search results of all content in the selected scope that contains that keyword.

Office SharePoint Server 2007 enables site collection administrators to create an entity called a keyword that is directly related to keyword phrases of the same name that are in the index. A site collection administrator can create a keyword using one or more words. For example, a keyword can be a single word, such as "OOF", or a group of words that must be typed in a particular order, such as "out of office".

In addition to the name of the keyword, also called the keyword phrase, site collection administrators can create keywords that are composed of one or more of the following options:

•      A definition of the keyword that appears in search results

•      One or more synonyms

•      One or more best bets, which are the URLs that SSP administrators specify as being highly relevant for a particular keyword.

Note:

Although you can create a keyword that does not contain any of the optional information listed above, doing so does not improve the relevance of search results.

Keywords enable site collection administrators to improve the relevance of end user queries. The search results for any site collection can be modified to promote specific content so that it appears more prominently in response to queries that use particular search terms. Although keywords are planned, implemented, and managed at the site collection level, it is a good idea to make your planning and implementation consistent throughout your organization.

Keyword definitions are a good way to provide easy access to information about high-priority concepts in each site collection. For each concept, site collection administrators can create a keyword so that the definition of the keyword appears in the Search Best Bets Web Part next to the search results. For example, a sales portal devoted to selling a particular line of products might provide definitions for the major items in the product line. These definitions can be used to help sales associates understand their products better, or the definitions can be displayed in search results on a public-facing portal site for customers.

Keyword example

A site collection administrator knows that end users are having difficulty finding the calendar that is used to track when team members are out of the office. Users report that when they search for the calendar, their queries produce several pages of irrelevant search results, and that they give up after looking through the first few search results pages.

The site collection administrator decides to create a keyword named "oof" containing the following items:

•      Keyword definition: This is the acronym we use to mean out of office.

•      Synonym: time off

•      Best bet: URL to the calendar and a description for the best bet.

The site collection administrator then asks the end users to use this new keyword "oof" or its synonym "time off" when searching for the calendar.

The following figure shows an example of the default search results page that end users see when searching on the keyword "oof" from the Search Center in this scenario. Note that best bets and keyword descriptions only appear on search results pages for searches that are run using the Search Center, by default.

In the figure above, the query that the end user ran is shown (callout 1). The keyword highlighting feature also shows the keywords in the content as bold text (callout 2). The description that the site collection administrator assigned to this keyword appears in the top-right corner of the search results page, by default (callout 3). Each keyword can be associated with a definition and you can include a URL in definitions. Accordingly, it is a good idea to:

•      Identify definition sources during planning.

•      Include a separate step during planning to design a glossary of all definitions used by keywords in each site collection.

•      Create some keywords for the sole purpose of associating the keywords with a definition.

The Best Bet (callout 4) appears directly below the keyword description, if there is one. A best bet is more than a URL. It also has a title and can optionally have a description. In this example, the site collection administrator named the best bet "Out of Office page". The description that the administrator assigned to the best bet appears directly below its name, and then the URL of the best bet appears below that.

Specific documents, sites, and people with expertise in the concept associated with a search term are common uses of best bets. It is important to consider the title and description of each best bet during content planning to increase the relevance and usability of each best bet. You can associate up to 25 best bets with each keyword in the administration user interface, and many more with the object model, but it is a good idea to not overuse best bets. Effective content planning can help you identify an appropriate number of best bets for each keyword that balances the number of search results with search relevancy.

Note:

Because the URL of a best bet is hard coded by the site collection administrator, it can be any URL. It can even point to content that has not been crawled.

You can use the same best bet for more than one keyword. If the best bet already exists, you can add it to any keyword without having to enter the properties for the best bet again and possibly introduce redundant best bets. You can also simultaneously change the URL and description for that best bet for all keywords that use it. This is particularly useful if you are using a test site during planning and before initial deployment.

Understanding synonyms

Synonyms are one or more words that closely relate to a particular keyword. For example, an effective synonym for the keyword "car" might be "auto", "automobile", or "SUV". These are all effective synonyms for that particular keyword because you would expect that some users that are searching for cars to type one of those words into the search box instead. Site collection administrators can define one or more synonyms for each keyword. The purpose of a synonym is to display the same keyword definition and best bet on the search results page that is displayed when using the keyword. Following the previous example, if end users run a search query using the synonym "out of office" they see the same keyword description and best bets that they see when they run the search query using the keyword "oof." The difference, however, is that they see search results for only content that contains the words "out of office" instead of content that contains the word "oof".

Synonyms are useful when several search terms are used for the same concept and content, so that search results are consolidated and not scattered across several search terms. The list that is updated when a site collection administrator creates keywords and adds synonyms is called a thesaurus. The thesaurus for Office SharePoint Server 2007 is compatible with the thesaurus for Microsoft Office SharePoint Portal Server 2003.

Use information architecture to identify keywords

You can analyze the content in your information architecture to compile a list of terms with which to create keywords that you can associate with specific and highly relevant content.

Relevant content is anything specific that you want people to see first or most prominently when they search using a specific keyword. Examples of relevant content for each major business concept or content area include:

•      Documents

•      Sites

•      People

•      Definitions

•      Approved or official terms that mean the same thing, but were not included in the search query.

Associating keywords with a best bet is helpful to encourage people to view the key documents that are needed to collaborate on key business processes. For example, a business might have a special template for expense reports, and a keyword "expense report" that promotes that template to the top of search results. Without that keyword, each employee might spend several minutes asking their colleagues for the appropriate URL or browsing the company Web site. With the keyword associated with the URL to the expense report template as a best bet, employees can quickly locate the template.

Keywords for sites are helpful for identifying the location of sites for relevant information in a large organization. For example, "holidays" could be a keyword associated with a best bet that contains the URL of the human resources site that contains information about paid time off for employees. Ideally, the best bet could contain the URL of the exact page that provides company holiday information.

Keywords that help people find other people encourage collaboration between people across the organization who have important knowledge to share, or just about important people in the company. For example, you can associate a title such as "CEO" with the chief executive officer for a company, or you can make a person's My Site a best bet for a keyword relating to their organization or area of expertise, such as "chemistry department."

Security considerations for keywords

Unlike previous versions of Office SharePoint Portal Server, keywords and best bets are not affected by security permissions, and all readers on the site collection can see all best bets and keywords for that site collection that appear in search results. Users who do not have permissions to see the page to which a best bet is linked cannot go to the page. However, they can see the description of the best bet on the search results page and the URLs to the content. This could expose information that some users were not intended to see.

Keywords are meant to provide high-priority results for all users.

If you want to target content to certain users based on their permissions, you can use audiences and targeted Web Parts in the appropriate places on the site collection.

Plan keywords across your organization

It is important to plan keywords in advance to help ensure consistency of keywords across your organization. Even though keywords are implemented at the site collection level, you should ensure consistency of keywords across site collections whenever possible.

Example of good keyword planning

Contoso Corporation has two site collections, one for the sales and one for the marketing department. A different site collection administrator is assigned to each. Because users of these site collections are spending too much time finding the corporation's customer list, these two site collection administrators decide that they need to create a keyword for their site collection and associate a best bet with that keyword that links users directly to the customer list.

To ensure that end users have a consistent experience on both site collections, the two site collection administrators collaborate to decide how the keyword and best bet should be defined.

Tip:

Planning for consistency of keywords across your organization requires good collaboration among site collection administrators. Whenever possible, ensure that keywords and best bets are consistent across site collections.

By avoiding the use of different keywords and best bets across site collections that point to the same content, you can avoid end-user confusion. For example, if the site collection administrator of the sales site collection had created a keyword named "super list" and the site collection administrators of the marketing site collection had created a keyword named "master list", end users who use both site collections would become confused when their keyword searches do not consistently display the best bet they expect to see on the search results page. That is, an employee who primarily uses the sales site collection is accustomed to searching using the keyword "super list" and would expect it to work from either site collection.

In small organizations, the content planning team is likely to be small and organized around a single site collection, and planning for keywords might be organized by only one or two people. In large organizations, on the other hand, a larger planning team can be helpful. You should include business planners and administrators at each level to make sure all business needs are addressed.

Best bets appear in search results even if the content hasn't been crawled. This is another reason to plan keywords during initial deployment, so that high-priority content can be available in the early stages of a deployment before all content sources have been crawled. In rare cases where content cannot be crawled because search is missing a relevant IFilter or for any other technical reason, you can use best bets to make the content easier to find even though it hasn't been crawled.

Key people at each level of the organization plan keywords for their site collections. Those people use the same overall content plan, adapted for the content on the site collections that they are planning. When planning keywords, which starts before deployment and continues in waves after deployment, each set of content planners can communicate with each other to keep consistency in the overall plan.

Not all keywords will be planned before deployment. The role of your content planning teams is to identify the high-priority concepts that are most relevant to search queries in your organization, so that search queries are relevant to users from the first day of your deployment. The planning team can identify a contact person for each keyword who may or may not be someone on the planning team. After deployment, site collection administrators can expand the keyword list after identifying common search terms in the query logs.

In the planning phase, keyword list managers should consider how keywords match to queries. Keywords must match the complete string of search terms exactly, and must not use special syntax such as a plus sign (+) and a minus sign (-) when searching for content in lists. This prevents the return of multiple lists of keywords for the same search query, which streamlines search results.

Plan keyword management

The details of keyword management are mostly relevant to the daily operations of your site collections, but there are some aspects of administration that are worth considering when planning your deployment. Specifically the optional contact and publishing properties that site collection administrators can assign to properties.

Tip:

The more planning you do before deployment, the less management will be needed during day to day operations.

In addition to the properties listed in the "Plan keywords, best bets, and synonyms" section earlier in this article, each has the following optional properties:

•      Start, end (expiration), and review dates

•      Contact

Keywords can be required to go through approval before they affect search results, and can also be set to start or expire after a certain amount of time. The high-priority keywords identified during initial planning are unlikely to be temporary, except for content that is relevant to people using a site collection during the initial deployment.

The contact for each keyword is the person who should be contacted when a keyword expires, if it is set to expire. Content planners for each site collection should consider who is going to be managing keywords after the initial deployment, and include at least some of those people in the planning process at the site collection level.

However, part of the planning process is anticipating who will make decisions about keywords in the future. Making those decisions during the planning process can improve the transition to regular operations of the site collection, and promote consistent and efficient use of keywords in the future.

By using the object model, you can also import and export keywords between site collections as an Excel spreadsheet, so if some best bets apply to other site collections, you can plan once and deploy on all relevant site collections. This also allows keyword managers for a site collection at the divisional or project level to suggest best bets for a central site collection in a shared services environment.

For more information about managing keywords, see the Operations Guide for Office SharePoint Server 2007.

Worksheet action

Record your decisions about keywords in the "Keywords" section of the End-user search experience worksheet (http://go.microsoft.com/fwlink/?LinkId=81039).

Plan the relevance of search results

The greater the body of content that is being searched over, the more likely it is that several pages of search results will be displayed for a particular query. This is especially true when basic keyword queries instead of advanced queries are used. To facilitate a positive end-user experience, ensure that links to the most relevant content are displayed as early as possible on the search results pages.

Office SharePoint Server 2007 enables SSP administrators to assign indexed Web pages relevance settings. Each relevance setting, which is associated with a particular Web page, determines how close to the top of the search results page the link to a particular page appears. Pages that are assigned a relevance setting are known as authoritative pages.

Authoritative page settings are one factor in prioritizing search results. For more information about search relevance, see Enterprise Search Relevance Architecture Overview (http://go.microsoft.com/fwlink/?LinkId=93736).

Authoritative page settings are configured at the SSP level and apply to all queries made using that SSP. SSP administrators can assign sites to one of four authoritative page levels:

•      Most authoritative

•      Second-level authoritative

•      Third-level authoritative

•      Sites to demote

Web pages are weighted based on how authoritative they are, with each level receiving proportionate relevance weighting. By default, all top-level pages for Web applications are automatically added as most authoritative. You can move these pages to other authoritative page levels or remove them from authoritative page settings completely.

Sites that are not assigned an authoritative page ranking are weighted based on their click distance from an authoritative site. Click distance refers to the number of links between a content item and an authoritative page linking to the content item. For more information, see the "Click Distance" section Enterprise Search Relevance Architecture Overview (http://go.microsoft.com/fwlink/?LinkId=93736).

Sites that are assigned the Sites to demote setting will typically appear towards the end of the search results after all other relevance weighting factors have been considered.

This means that they often appear on the search results page after pages that are not even specified as an authoritative page. We recommend that you use this setting for sites that contain less relevant information (for example, an archive site).

When planning authoritative page settings, consider the purpose of each site, and review its subsites. Group authoritative sites into the three levels by importance and group the sites that are not likely to be relevant as sites to demote.

Good practices to use when planning authoritative page settings include:

•      SharePoint sites and business applications central to high-priority business processes will typically be most authoritative.

•      Sites that encourage collaboration or action are likely to be more authoritative than sites that are merely informative.

•      Sites that are informative but not central to high-priority business processes or used for collaboration are likely to be in the second or third level of authoritative sites.

•      External sites will typically be less authoritative, because your organization cannot control the content on those sites.

•      You don't need to assign an authoritative page setting to every site. It is a good idea to select relevance for a small number of sites that you know are most authoritative or less relevant, and adjust the authoritative page settings during normal operations based on feedback from users and information in the query logs.

Worksheet action

Record your decisions about authoritative pages in the "Authoritative pages" section of the End-user search experience worksheet (http://go.microsoft.com/fwlink/?LinkId=81039).

Plan whether to use federated locations and federation Web Parts

Note:

The information provided in this section applies to Office SharePoint Server 2007 with the Infrastructure Update for Microsoft Office Servers. For more information, see Install the Infrastructure Update for Microsoft Office Servers (Office SharePoint Server 2007).

Federation, a new feature that was first introduced in Search Server 2008 and is available in Office SharePoint Server 2007 by installing the Infrastructure Update for Microsoft Office Servers, can be planned with the rest of the end-user search experience. Federation enables end users to issue a query that searches multiple sources and combines results into a single search results page. These sources can include:

•      Your company's enterprise content repositories

•      Internet search engines or subscriptions services used by your company

•      Enterprise documents indexed by Office SharePoint Server 2007 in other divisions or world regions

When the end user issues a query, Office SharePoint Server 2007 formats and renders the results alongside your indexed results by using new federation Web Parts.

When you plan the experience you want for your users when they search federated locations, try to target the searching needs and habits of users in your company. Ask yourself these questions: What content do your users need to find most to be productive? What queries are they currently using? Target your federated locations to solve the key information problems in your company.

When using federation it is tempting to add many federated locations to satisfy all the possible needs of your users. Unfortunately, this leads many users to disregard federated results as clutter.

To help ensure that federated results target useful answers to queries, federated locations can match specific query formats with trigger rules. When you create a trigger rule for a federated location, the Web Part that is associated with that location displays results only for queries that match the pattern or prefix that you specify.

For example, let's say that you work at a company called Contoso, where employees manufacture a product called a widget. Employees need to find these widgets many times a day by using a ten-digit widget ID. Widgets are stored in a database that cannot be crawled by Office SharePoint Server 2007. To enable Contoso employees to search for widgets, you build a federation connector that searches the widget database. However, displaying widget information for every query would likely frustrate your users. So, you create a federated location trigger by using a pattern that recognizes ten-digit queries. Now, when users search for widget IDs, they get a top federated result from the widget database.

For more information about using triggers and trigger rules, see Work with triggers and query templates.

You can add and configure federated results on the search results page with either a Federated Results Web Part or a Top Federated Results Web Part. By default, the search results page contains two Federated Search Results Web Parts and one Top Federated Results Web Part. You set the federated location and its properties in the Web Parts on the search results page.

For more information about federation, see Federating search results from other locations.

Plan the appearance of links

SSP administrators can use server name mappings to change how particular URLs or ranges of URLs are displayed in search results. Server name mappings are set at the SSP level for all content that is crawled by that SSP, and are applied whenever a full crawl of the affected content sources is performed. You might want to use server name mappings in the following scenarios:

•      You want to prevent access problems and possible security vulnerabilities caused by links that show the local addresses on the server. For example, depending on how content is crawled, a URL might display a local path on the server.

•      You want to obscure complex URLs in search results, so you replace them with a more concise name on the server.

•      For security reasons, you want to hide the name of the original source of the content such as the server or share name.

Use server name mappings only when you have one of the display problems described in the previous list. In most cases, planning for server name mappings prior to the initial deployment will be minimal.

Worksheet action

Record your decisions about authoritative pages in the "Authoritative pages" section of the End-user search experience worksheet (http://go.microsoft.com/fwlink/?LinkId=81039).

Plan search-based alerts

An SSP administrator can decide whether search-based alerts will be activated for a particular SSP. If search-based alerts are activated and the server is configured to send e-mail, end users can click the Alert Me link at the top of search results pages and specify what kind of changes they want to be alerted to and how frequently they want to receive an alert in e-mail. Note that when you allow search-based alerts, your system uses additional resources on mail servers and increases the load on query servers because queries for each search-based alert run every time a search-based alert is processed. When planning the initial deployment, consider the resources available for alerts and the likelihood that people using your sites will use alerts productively. Search-based alerts are activated, by default.

Tip:

If you deactivate search-based alerts in the Shared Services Provider, we recommend that all site owners remove the Alert Me link at the top of their search results pages.

During operations, search-based alerts are automatically disabled whenever the entire content index is reset in order to avoid sending notifications for all search-based alerts. Administrators then have to re-enable search-based alerts.

Worksheet action

Record your decisions about search-based alerts in the "Search-based alerts" section of the End-user search experience worksheet (http://go.microsoft.com/fwlink/?LinkId=81039).

Security considerations for search

Microsoft Office SharePoint Server 2007 uses a technique, sometimes called security trimming, to ensure that users do not see content or links to content that they do not have permissions to view. However, when using either the Office SharePoint Server Search or Windows SharePoint Services Help Search service to perform search queries, certain conditions can exist in which users might see links to content that they do not have permission to access. While they will not be able to use the link on the search results page to view the content, the links that appear on the search results page might be accompanied by text that discloses information the users should not see. This article describes the conditions in which this can occur and how to avoid them.

Sharing data across Web parts

When sharing data between Web parts, to avoid the risk of disclosing information that users should not see in search results pages, we recommend that you do not use fine-grained permissions. Instead, set permissions only at the site or site collection level and do not share data with a Web part that is contained by a page that has different permissions than any of the data being shared.

Note:

Permissions can be set at the site, list and library, or item levels.

If you must use fine grained permissions, do not share data between Web parts. If this cannot be avoided either, do not crawl this content. See the following section for information about excluding content from being crawled.

If you have already crawled the content, consider removing it from the index.

Exclude content from a crawl

Site owners and designers can exclude content from being crawled that may pose an information disclosure risk in any of the following ways:

•      Designers can add the <META NAME="ROBOTS" CONTENT="NOHTMLINDEX"/> element manually to all pages that they don't want the index server to crawl.

•      At the site level, use the Search Visibility page (accessed through the Site Settings page) to prevent the index server from crawling a particular site. You can optionally use this page to specify one of the following:

•      Do not index ASPX pages if this site contains fine-grained permissions

•      Always index all ASPX pages on this site

•      Never index any ASPX pages on this site

•      At a list or library level, use the following procedure to specify that content in a list or library does not appear in search results.

Exclude content from a list or library from search results

1.   In the list or library that contains content that you do not want to appear in search results, on the Settings menu, click <Library type> Library Settings or List Settings.

2.   In the General Settings section, click Advanced Settings.

3.   In the Search section, select No and then click OK.

IX.  Plan communication

The articles in this chapter include:

•      Plan communication

•      Plan presence integration

•      Plan incoming e-mail

•      Plan outgoing e-mail

Plan communication

Enabling communication is a critical component for creating Web applications in which group members can interact with each other and keep up with changes to information through the use of alerts. The site collection features that are dependent on communications being properly set up include:

•      Online presence to allow real-time messaging between group members.

•      Alerts to notify group members when things have changed.

•      Administrative messages related to requests for site access and other site administration issues.

•      Discussion groups.

To make the most effective use of the communications features, planning should include understanding the software requirements. It should also include the privacy and security implications of enabling communication, particularly outside the corporate firewall.

Communications components

Communications includes three components: online presence, incoming e-mail, and outgoing e-mail. Plan communication by using the following articles:

•      Plan presence integration provides information on how too enable users to see online presence of group members and start instant message conversations from within a site collection.

•      Plan incoming e-mail provides information on how to set up e-mail for discussion groups.

•      Plan outgoing e-mail provides information on how to use alerts and administrative messages.

Plan presence integration

In this article:

•      About online presence

•      Advantages of incorporating online presence

•      Organizational considerations

•      Software requirements

•      E-mail account requirements

Online presence enables individuals who have access to your site to see who is online and to send instant messages to them. Online presence can be a powerful collaboration tool that helps site members to quickly find out who is available to answer questions.

This article explains what online presence is, how it can be used in an organization, and the software that is required to enable it.

About online presence

Online presence gives individuals the ability to identify who is online and available to communicate with them at any given moment. Enabling online presence (and installing the required software) adds an online status indicator next to an individual's name wherever their name appears in a site collection. The online status indicator shows whether the individual is offline or is online and available to respond to queries via an instant messaging client. When an individual is online, you can click the online status indicator to send an instant message. This direct access to knowledgeable sources can help team members work more effectively and efficiently.

Wherever a member name appears in a site, the online status indicator menu is available. The online status indicator is integrated with the Active Directory directory service, Microsoft Exchange Server, and MSN Messenger to provide information, such as office location and free/busy status, so it is a useful tool for scheduling meetings and sending e-mail even when an individual is offline.

Online status is rendered by an ActiveX control that is installed with Microsoft Office. The ActiveX control enables online status to be displayed. This control verifies the e-mail address on record for the user and directs a query to the presence server for that client to see if they are online. The ActiveX control does not store online information or e-mail addresses; it simply directs queries from the site to the e-mail address and renders the appropriate status.

Online presence is enabled by default; however, both the software and e-mail account requirements must be met for the functionality to be available to end users.

Advantages of incorporating online presence

The advantage of enabling presence is in the ability to use it to improve collaboration between group members and increase efficiency in business processes. By integrating instant messaging and presence information in a SharePoint site, group members can see who is online and instantly know whether they are available for a quick question or brief meeting. Individuals can streamline work processes by immediately notifying team members of document or timeline changes or establish group collaborative sessions by using instant messaging.

Organizational considerations

Because online presence is enabled at the Web application level, it is enabled for all sites and subsites of that virtual server. Therefore, it is critical to ensure that all site collections within the virtual server are willing to share this level of transparency.

While enabling online presence is beneficial in many environments where collaboration is critical, it is important to balance the benefits of increased collaboration among group members with the requirements for security and compliance, particularly in regard to the deployment of an instant messaging client. Planning for presence should include assurance that both internal and external communications to and from the instant messaging client are consistent with company-wide policy for security and compliance with regulatory guidelines and business practices.

For example, in some highly regulated industries, instant messaging conversations must be retained in accordance with record-keeping requirements for electronic communications. Companies that are subject to Sarbanes-Oxley regulation must archive instant messaging conversations as a part of their records-retention requirements.

Software requirements

Because online status is rendered by Office, Office 2003 or later is required on all client computers. Additionally, one of the following instant messaging clients must be installed on client computers to enable real-time communications:

•      Microsoft Windows Messenger version 4.6

•      MSN Messenger version 4.6 or later

•      Microsoft Office Communicator 2005 or later

If either MSN Messenger or Windows Messenger is installed on the client computer, by default the end user will see online status for their Messenger contacts only. If Office Communicator is installed, the end user will see the online status for all users who have permissions on the site collection.

E-mail account requirements

To display online status, the presence feature uses a Session Initiation Protocol (SIP) address to communicate with the instant messaging client. If a SIP address is not available, a .NET address (MSN Messenger) or an Exchange Instant Messaging address (Windows Messenger) can be configured on an individual basis. However, only SIP addresses can take advantage of additional presence features, such as the ability to send and receive e-mail and to display free/busy information from the online status indicator.

Plan incoming e-mail (Office SharePoint Server)

In this article:

•      About incoming e-mail

•      Key decisions for planning incoming e-mail

•      Configuration options and settings modes

•      Before configuring incoming e-mail

•      Plan the Microsoft SharePoint Directory Management service

•      Worksheet

About incoming e-mail

Incoming e-mail is a feature of Microsoft Office SharePoint Server 2007 that enables SharePoint sites to receive and store e-mail messages and attachments in lists and libraries. This new feature enables teams to store the e-mail that they send to other team members without opening the SharePoint site and uploading the content that was sent in e-mail. This is possible because most types of lists and libraries can be assigned a unique e-mail address.

This article helps server and farm administrators understand the choices they need to make before they deploy the incoming e-mail feature for their organization.

Key decisions for planning incoming e-mail

There are several key decisions that you can make as you plan for incoming e-mail. These decisions include whether to:

•      Accept e-mail from all e-mail servers or only safe e-mail servers.

•      Use the directory management service to create distribution lists and contacts from SharePoint sites.

•      Specify the folder that you want the system to check for incoming e-mail.

•      Specify the e-mail server address that will be displayed in Web pages when users create an incoming e-mail address for a site, list, or group.

Some scenarios — for example, using the directory management service — require one or more IT professionals to implement. Nonetheless, you can still implement a basic incoming e-mail scenario even if your organization does not have an IT staff.

Basic scenario

If your organization does not have an IT professional staff, you can enable a basic incoming e-mail scenario by installing the Simple Mail Transfer Protocol (SMTP) service on the server running Office SharePoint Server 2007 and enabling incoming e-mail by using the automatic settings mode with all default settings. In this scenario, e-mail is delivered directly to your SMTP server and Office SharePoint Server 2007 periodically checks for e-mail in the default e-mail drop folder that is automatically configured by the SMTP service.

Selecting the automatic settings mode and accepting all the default settings is the easiest way to enable incoming e-mail because all configuration settings are made for you and, therefore, little expertise is required. For most organizations, this configuration is all that is needed.

You enable a basic incoming e-mail scenario in the following steps:

1.   The server administrator uses the Windows Components Wizard to install the E-mail Services component on the server that you want to receive incoming e-mail. This installs and starts the SMTP service on that server.

2.   The farm administrator enables incoming e-mail by using the automatic settings mode and accepting all the default values.

3.   The site collection administrator enables the incoming e-mail feature on the libraries and lists in which they want to store incoming e-mail and assigns each library and list a unique e-mail address in the form address@SMTPserveraddress. For example, sharedfiles@SMTPserver.contoso.com.

When users send e-mail to the address of a list or library, Office SharePoint Server 2007 detects that new e-mail has been delivered and sends it to the appropriate list or library based on the e-mail address.

Note:

If this basic scenario meets your needs, you can skip the remainder of this article. For more information, see "Configure incoming e-mail" in the Help system.

Advanced scenarios

For more advanced administrators, additional choices are available, some of which require more expertise to deploy than choosing the basic scenario with all default options. This section describes the following configuration options:

•      Safe e-mail server

•      E-mail drop folder

•      Microsoft SharePoint Directory Management service

•      Incoming e-mail server display address

Safe e-mail server

You can configure Office SharePoint Server 2007 to accept e-mail from any e-mail server or only e-mail that has been routed through a safe-e-mail server application, such as Microsoft Exchange Server.

This option requires an IT professional to configure the e-mail routing through the safe e-mail server and is available only in automatic mode.

You can derive the following benefits by routing e-mail through a safe e-mail server:

•      User authentication   The SMTP service cannot authenticate users who send e-mail to your site, but Exchange Server can. The server administrator can use the SharePoint Central Administration Web site to specify that the system accept e-mail from authenticated users only if the e-mail is sent through Exchange Server.

•      Spam filtering     Exchange Server provides spam filtering to eliminate unsolicited commercial e-mail before it is forwarded to its destination — in this case, the server running Office SharePoint Server 2007. Another technique that can reduce spam is to allow members of the team site to archive e-mail only in lists on which you have granted write permissions to members.

•      Virus protection   Exchange Server provides virus protection for e-mail routed through it.

Worksheet action

Record your decisions about safe e-mail servers in the Safe e-mail servers section of the Plan incoming e-mail worksheet (http://go.microsoft.com/fwlink/?LinkId=82857&clcid=0x409).

E-mail drop folder

You can specify the location from which Office SharePoint Server 2007 retrieves incoming e-mail. The benefit of using this option is that it enables Office SharePoint Server 2007 to retrieve incoming e-mail from a network share on another server. However, we recommend that you do not do this. This is because Office SharePoint Server 2007 cannot detect configuration changes on the remote e-mail server that is delivering the e-mail to your drop folder. This means that if an administrator configures the e-mail server to no longer deliver e-mail to this folder, Office SharePoint Server 2007 cannot detect that the configuration has changed, and therefore will not be able to retrieve the files from the new location.

You can also use the SMTP service to receive e-mail and specify the folder to which e-mail will be dropped instead of accepting the SMTP service's default setting. This is useful when the default folder location is full or nearly full.

Note:

When incoming e-mail settings are set to advanced mode, you must ensure that the logon account for the Windows SharePoint Services Timer service has modify permissions on the e-mail drop folder.

Worksheet action

Record your decisions about safe e-mail servers in the Safe e-mail servers section of the Plan incoming e-mail worksheet (http://go.microsoft.com/fwlink/?LinkId=82857&clcid=0x409).

Note:

Because this option is only available in advanced mode, you cannot specify an e-mail drop folder and also specify one or more safe e-mail servers.

Microsoft SharePoint Directory Management service

The Microsoft SharePoint Directory Management service connects SharePoint sites to your organization's user directory to provide enhanced e-mail features. The benefit of using this service is that it enables users to create and manage e-mail distribution groups from SharePoint sites. This service also creates contacts in your organization's user directory so people can find e-mail-enabled SharePoint lists in their address books.

A typical directory management scenario proceeds in the following steps:

1.   A site collection administrator creates a new SharePoint group.

2.   The administrator chooses to create a distribution list to associate with that SharePoint group and assigns an e-mail address to that distribution list.

3.   Over time, the administrator adds users to and removes users from this SharePoint group. As users are added to and removed from the group, the SharePoint Directory Management service automatically adds and removes them from the distribution list, which is stored in the Active Directory directory service. Because distribution lists are associated with a particular SharePoint group, this distribution list is available to all members of that SharePoint group.

4.   Because the SharePoint Directory Management service is used, e-mail addresses are automatically generated for the discussion boards and calendars on team sites, by default, and added to the team distribution list. The e-mail addresses for these two lists will be in the following form, by default: GroupAddress.discussions and GroupAddress.calendar.

5.   By including e-mail addresses for discussion boards and calendars in the distribution list, all e-mail and meeting invitations sent to this distribution list will be archived in the team site.

For more information about planning for the SharePoint Directory Management service, see "Planning the Microsoft SharePoint Directory Management service" later in this article.

Incoming e-mail server display address

Administrators can specify the e-mail server address that will be displayed in Web pages when users create an incoming e-mail address for a site, list, or group. This setting is often used in conjunction with the Microsoft SharePoint Directory Management service to provide a more friendly e-mail server address for users to type.

Worksheet action

Record your decisions about safe e-mail servers in the Safe e-mail servers section of the Plan incoming e-mail worksheet (http://go.microsoft.com/fwlink/?LinkId=82857&clcid=0x409).

Configuration options and settings modes

As a farm administrator, you have two settings modes from which to choose when enabling incoming e-mail: automatic and advanced. As described in the "Basic scenario" section above, you can choose the automatic settings mode with default settings. However, the automatic settings mode has additional options that you can choose.

The following table describes the configuration options and whether they are configured on the Configure Incoming E-Mail Settings page in Central Administration by using the automatic settings mode or the advanced settings mode.

Configuration option

Automatic settings mode

Advanced settings mode

Safe e-mail servers

Yes

No

E-mail drop folder

No

Yes

SharePoint Directory management service

Yes

Yes

Incoming e-mail server display address

Yes

Yes

The advanced and automatic settings modes are similar in that they both enable farm administrators to configure the Microsoft SharePoint Directory Management service and the e-mail server address to display in Web pages. These settings modes differ in that the automatic settings mode replaces the ability to choose what e-mail servers to accept e-mail from with the ability to specify the folder to which e-mail is dropped. Office SharePoint Server 2007 uses this e-mail drop folder to detect new e-mail messages.

Note:

The e-mail drop folder setting is not available in automatic mode, because that mode automatically sets the e-mail drop folder to the folder that is specified by the SMTP service.

Before configuring incoming e-mail

Before configuring incoming e-mail, perform the following tasks:

•      Install the SMTP service on each server on which you want to receive and process incoming e-mail. Alternatively, provide another way for e-mail to be delivered to your e-mail drop folder.

•      If you use the SMTP service on the server running Office SharePoint Server 2007, ensure that the server is running the Windows SharePoint Services Web Application service. This enables e-mail that is received on the Web server to be processed by Office SharePoint Server 2007.

For more information about installing the SMTP service, see the Windows Help system.

Plan the Microsoft SharePoint Directory Management service

You can configure the Microsoft SharePoint Directory Management service by using either the automatic settings mode or the advanced settings mode. You can choose to enable the Microsoft SharePoint Directory Management service on your server or server farm running Office SharePoint Server 2007, or use the Microsoft SharePoint Directory Management service of another farm. One advantage of using the service running on another farm is that Active Directory permissions are managed in a centralized place (that is, on the other farm).

To enable this service on your own server or server farm running Office SharePoint Server 2007, the SharePoint Central Administration application pool account used by Office SharePoint Server 2007 must have write access to the container that you specify in Active Directory. This requires an Active Directory administrator to set up the organizational unit (OU) and the permissions on the OU. The advantage of using the Microsoft SharePoint Directory Management service on a remote farm is that you do not need the help of an Active Directory administrator to create and configure the OU if the OU already exists.

Directory management service configuration options

When you configure the Microsoft SharePoint Directory Management service to create distribution groups and contacts in Active Directory, you must provide the following information:

•      Name of the Active Directory container where new distribution groups and contacts will be created. This must be provided in the following format:

OU=ContainerName, DC=DomainName, DC=TopLevelDomainName

•      Name of the SMTP server to use for incoming e-mail (or accept the default SMTP server if one exists). This must be provided in the following format:

Server.subdomain.domain.top-level_domain

For example, SharePointServer.support.contoso.com

•      Whether to accept messages from only authenticated users.

•      Whether to allow users to create distribution groups from SharePoint sites. If you choose yes for this option, you can also choose whether users can do any combination of the following actions:

•      Create a new distribution group.

•      Change a distribution group's e-mail address.

•      Change a distribution group's title and description.

•      Delete a distribution group.

When configuring the Microsoft SharePoint Directory Management service to create distribution groups and contacts using a remote Microsoft SharePoint Directory Management service, you must provide the following information:

•      The URL of the remote directory management service. For example, http://server:adminport/_vti_bin/SharePointEmailWS.asmx.

•      The name of the SMTP server to use for incoming e-mail.

•      Whether to accept messages from only authenticated users.

•      Whether to allow users to create distribution groups from SharePoint sites.

Worksheet action

Record your decisions about safe e-mail servers in the Safe e-mail servers section of the Plan incoming e-mail worksheet (http://go.microsoft.com/fwlink/?LinkId=82857&clcid=0x409).

Worksheet

Use the following worksheet to record your decisions about incoming e-mail:

•      Plan incoming e-mail worksheet (http://go.microsoft.com/fwlink/?LinkId=82857&clcid=0x409)

See Also

Demo: Configure a SharePoint Server 2007 site to receive e-mail (http://office.microsoft.com/en-us/sharepointserver/HA102047921033.aspx)

Plan outgoing e-mail (Office SharePoint Server)

In this article:

•      About outgoing e-mail

•      General requirements

•      Outbound SMTP server

•      From and Reply-to addresses

•      Character set

Outgoing e-mail is the foundation on which site administrators can implement several compelling e-mail notification features. These features help end users track changes and updates to individual site collections and allow site administrators to deliver status messages. These e-mail features include both e-mail alerts and administrative messages.

•      Alerts   In a large and growing site collection, users need an efficient way to keep up with updates to lists, libraries, discussions, and other important parts of the site. Setting up alerts provides an effective means to stay on top of changes. For example, if several different groups are dependent on each other for reviewing documents, individuals in each group can set up alerts to be notified whenever there are changes to the documents they are responsible for. Users can specify which areas of the site collection or which documents they want to track and decide how often they want to receive alerts.

Note:

Users must have at least View permissions to set up alerts.

•      Administrative messages   Site administrators might want to receive notices when users request access to a site or when site owners have exceeded their specified storage space. Setting up outgoing e-mail enables site administrators to receive automatic notifications for site administration issues.

This article will help site administrators understand both the uses for integrating outgoing e-mail and the requirements for integrating it into their site collections.

About outgoing e-mail

Properly configuring outgoing e-mail is a requirement for implementing e-mail alerts and notifications. The outgoing e-mail feature uses an outbound Simple Mail Transfer Protocol (SMTP) service to relay e-mail alerts and notifications.

Outgoing e-mail support can be enabled at both the server farm level (available in the Operations section of Central Administration) and at the Web application level (available in the Application Management section of Central Administration). Therefore, you can specify different settings for a specific Web application. Outgoing e-mail settings at the Web application level override those set up at the server farm level.

General requirements

The outgoing e-mail settings include several components that must be considered when planning for this feature:

•      An SMTP service to relay e-mail alerts and notifications. You will need the DNS name or IP address of the SMTP mail server to use.

•      An address to use in the header of an alert message that identifies who the message is from.

•      A Reply-to address that is displayed in the To field of a message when a user replies to an alert or notification.

•      A character set to use in the body of alert messages.

Outbound SMTP server

The SMTP service is a component of Internet Information Services (IIS); however, it is not enabled by default with IIS. It can be enabled by using the Add or Remove Programs in Control Panel.

After determining which SMTP server to use, the SMTP server must be configured to allow anonymous access and to allow e-mail messages to be relayed. Additionally, the SMTP server must have Internet access if you want the ability to send messages to external e-mail addresses.

For more information about installing, configuring, and managing the SMTP service, see the Help for Internet Information Services (IIS) Manager (http://go.microsoft.com/fwlink/?LinkId=72343).

Note:

Only a member of the Farm Administrators group can configure an SMTP server. The user must also be a member of the local Administrators group on the server.

From and Reply-to addresses

The two e-mail addresses that you can specify when configuring outgoing e-mail settings are the From address and the Reply-to address.

•      From address   Alerts and notifications are sent from an administrative account on the server farm. This account is probably not the one you want to be displayed in the From field of an e-mail message. The address that you use does not need to correspond to an actual e-mail account; it can be a simple friendly address that is recognizable to an end user. For example, "Site administrator" might be an appropriate From address.

•      Reply-to address   This is the address that will be displayed in the To field of a message if a user replies to an alert or notification. The Reply-to address should also be a monitored account to ensure that end users receive prompt feedback for issues they might have. For example, a Help Desk alias might be an appropriate Reply-to address.

Character set

When you configure e-mail settings, you will need to specify the character set to use in the body of e-mail messages. A character set is a mapping of characters to their identifying code values. The default character set for outgoing e-mail is Unicode UTF-8, which allows most combination of characters (including bidirectional text) to co-exist in a single document. In most cases, the default setting of UTF-8 works well, although East Asian languages are best rendered with their own character set.

Be aware that if you select a specific language code, the text is less likely to appear correctly in mail readers configured for other languages.

X.  Plan document management

The articles in this chapter include:

•      Plan document management

•      What is document management?

•      Identify document management participants and stakeholders

•      Analyze document usage

•      Plan document libraries

•      Plan content types

•      Plan workflows for document management

•      Plan versioning, content approval, and check-outs

•      Plan Information Rights Management

•      Plan information management policies

•      Plan enterprise content storage

Plan document management

Microsoft Office SharePoint Server 2007 includes document management features that you can use to control the life cycle of documents in your organization — how they are created, reviewed, published, and consumed, and how they are ultimately disposed of or retained. The articles in this chapter will guide you in planning the document management features of your solution based on Office SharePoint Server 2007.

The articles in this chapter include:

•      What is document management? includes an introduction to document management in the enterprise, along with a description of the document management planning process recommended in this planning guide.

•      Identify document management participants and stakeholders describes the creation of a document management planning team.

•      Analyze document usage provides guidance on determining the types of documents used in your enterprise and analyzing the stages in the documents' life cycles.

•      Plan document libraries describes using document libraries to organize documents in your enterprise.

•      Plan content types describes planning content types, which are the Office SharePoint Server 2007 mechanism for defining and sharing the attributes of documents, list items, and folders.

•      Plan versioning, content approval, and check-outs provides guidance on planning content control in Office SharePoint Server 2007, such as by using versioning, check-in and check-out, and approval for publishing content.

•      Plan Information Rights Management describes how to plan Information Rights Management on documents stored in document libraries so that you can control which actions users can take on documents when they open them from libraries in Office SharePoint Server 2007.

•      Plan workflows for document management describes how to use the Office SharePoint Server 2007 workflow feature to design document-related processes.

•      Plan information management policies describes planning and implementing enterprise policies that will help your organization comply with regulatory and legal obligations, in addition to best practices such as auditing documents and retaining them properly

•      Plan enterprise content storage contains information to help solution planners and designers properly plan and configure a large-scale enterprise content management solution based on Office SharePoint Server 2007 so that it performs well while providing the features needed by site users.

•      White paper: Managing Enterprise Metadata with Content Types discusses how to implement the set of features that define the metadata properties of each type of content and promote the consistent and effective use of metadata across an enterprise's content.

•      Downloadable book: Office SharePoint Server Document Management (http://technet.microsoft.com/en-us/library/cc263233.aspx) provides a link to a Microsoft Office Word document that contains all of technical library articles about document management with Office SharePoint Server.

See Also

Plan records management

What is document management?

In this article:

•      The elements of a document management system

•      The planning process

Document management controls the life cycle of documents in your organization — how they are created, reviewed, published, and consumed, and how they are ultimately disposed of or retained. Although the term "management" implies top-down control of information, an effective document management system should reflect the culture of the organization using it. The tools you use for document management should be flexible, allowing you to tightly control documents' life cycles if that fits your enterprise's culture and goals, but also letting you implement a more loosely structured system if that better suits your enterprise.

A well-designed document management system promotes finding and sharing information easily. It organizes content in a logical way, and makes it easy to standardize content creation and presentation across an enterprise. It promotes knowledge management and information mining. It helps your organization meet its legal responsibilities. It provides features at each stage of a document's life cycle, from template creation to document authoring, reviewing, publishing, auditing, and ultimately destroying or archiving.

The elements of a document management system

An effective document management solution specifies:

•      What types of documents and other content can be created within an organization.

•      What templates to use for each type of document.

•      What metadata to provide for each type of document.

•      Where to store documents at each stage of a document's life cycle.

•      How to control access to a document at each stage of its life cycle.

•      How to move documents within the organization as team members contribute to the documents' creation, review, approval, publication, and disposition.

•      What policies to apply to documents so that document-related actions are audited, documents are retained or disposed of properly, and content important to the organization is protected.

•      How documents are converted as they transition from one stage to another during their life cycles.

•      How documents are treated as corporate records, which must be retained according to legal requirements and corporate guidelines.

Microsoft Office SharePoint Server 2007 includes features that implement all of these aspects of document management. To ensure that information workers can easily take advantage of these capabilities without having to depart from their day-to-day operations and familiar tools, applications in the Microsoft Office 2007 system — such as Microsoft Outlook and Microsoft Word — also include features that support each stage in a document's life cycle.

The planning process

The document management planning process consists of the following major steps:

1.   Identify document management roles   Ensure that your plans incorporate the feedback of your organization's key stakeholders, that you have the right team in place to implement the solution, and that you know who will participate in document management processes. See Identify document management participants and stakeholders for more information about creating a document management planning team.

2.   Analyze document usage   After you identify who works on documents, determine the types of documents they work on and how they will be used. For more information, see Analyze document usage.

3.   Plan the organization of documents   You can organize documents in libraries, team sites, and portal sites. Office SharePoint Server 2007 offers a range of document organizing and storing features, from specialized sites such as the Records Repository to free-form document libraries for ad-hoc document creation and collaboration. Within a library, you can further organize content into folders and subfolders. For more information, see Plan document libraries.

4.   Plan how content moves between locations   It may be necessary to move or copy a document from one site or library to another at different stages of its life cycle. For example, the publishing process may include moving a document from a staging site to a public Internet site. If content needs to be converted from one format to another as it moves from site to site, you will also want to plan content conversions. For more information, see "Plan the flow of content" in the topic Plan document libraries.

5.   Plan content types   Use content types to organize information about types of documents, such as metadata, document templates, policies, and workflow processes. This is an essential step to help you organize your documents and enforce consistency across your organization. For more information, see Plan content types.

6.   Plan content control   You can plan the appropriate degree of control for each content type and storage location. For example, for a document library you can plan to require check-in and check-out and to protect documents from unauthorized distribution by using Information Rights Management. For more information, see Plan versioning, content approval, and check-outs.

7.   Plan workflows   By planning workflows for your organization, you can control and track how documents move from one team member to another as each participant collaborates in a document's life cycle. Office SharePoint Server 2007 includes workflows for common team tasks such as reviewing and approving documents. Office SharePoint Server 2007 also supports creating and installing custom workflows. For more information, see Plan workflows for document management.

8.   Plan policies   For each content type, plan information management policies to ensure that documents are properly audited, retained, labeled, and otherwise handled according to your organization's institutional and legal requirements. Office SharePoint Server 2007 includes policies that implement auditing, document retention, labeling, and barcodes (to ensure that printed content can be correlated with corresponding versions in document libraries). For more information, see Plan information management policies.

Download this book

This topic is included in the following downloadable book for easier reading and printing:

•      Document Management Guide for Office SharePoint Server 2007 (http://go.microsoft.com/fwlink/?LinkID=92638)

See the full list of available books at Downloadable books for Office SharePoint Server 2007 (http://technet.microsoft.com/en-us/library/cc262788(TechNet.10).aspx).

Identify document management participants and stakeholders

The first step in your document management planning is to determine the stakeholders and participants in your document management solution. You can use a survey to collect this information. For example, your survey might contain the following questions:

1.   Who in your organization creates documents?

2.   What types of documents do they create?

3.   Who reviews documents?

4.   Who edits documents?

5.   Who uses documents?

6.   Who approves the publication of documents?

7.   Who designs Web sites used for hosting documents?

8.   Who sets guidelines and policies for managing documents?

9.   Who manages records in your organization?

10.  Who deploys and maintains the servers on which documents are stored?

Worksheet action

Each of these questions can yield multiple answers. Record the information you gather from the survey in the Document management participants worksheet (http://go.microsoft.com/fwlink/?LinkId=73285&clcid=0x409), as in the following example.

Position

Types of documents

Role

Financial analyst

Technical writer

Equity research note

Financial model

Web page

Author

Financial analyst

Manager

Equity research note

Financial model

Reviewer

Technical editor

Equity research note

Web page

Editor

Customer

Equity research note

Financial model

Web page

Reader

Corporate lawyer

Manager

Equity research note

Financial model

Web page

Content approver

Server administrator

All

IT specialist

Database manager

All

Database specialist

Compliance officer

All

Legal specialist

Records manager

All

Records manager

Site manager

All

Content publisher

Site administrator

All

Content auditor

Identifying content stakeholders can help you ensure that your document management solution is comprehensive, and that you design sites and document libraries that suit your enterprise's content needs and processes.

Worksheet

Document management participants worksheet (http://go.microsoft.com/fwlink/?LinkId=73285&clcid=0x409)

Download this book

This topic is included in the following downloadable book for easier reading and printing:

•      Document Management Guide for Office SharePoint Server 2007 (http://go.microsoft.com/fwlink/?LinkID=92638)

See the full list of available books at Downloadable books for Office SharePoint Server 2007 (http://technet.microsoft.com/en-us/library/cc262788(TechNet.10).aspx).

Analyze document usage

After you identify your content stakeholders, collect information from them that will help you analyze how documents are used in your organization. This is an important part of the planning process because the analysis helps you determine:

•      How document libraries are structured.

•      Which site templates to use.

•      How many sites you will need.

•      Which information management policies to apply to the sites.

•      Which physical server topology you will need to implement your solution.

The information to collect includes:

•      Document type, such as equity research note, employee performance review, internal memo, or product specification.

•      Purpose of each document type, such as "provides customers with recommendations about equities along with supporting data."

•      Author of each document type (listed as roles, not individuals, such as "Financial Analyst," "Human Resources Specialist," or "Product Manager").

•      Format of the document. If the document is transformed from one format to another, record that information.

•      Users of each document type, such as "customers" or "team members."

•      Other roles that apply to the document's life cycle, such as "technical reviewer" or "copy editor."

•      Location of the document, such as "client computer," "Web server," or "file server." Note that this question could have multiple answers, such as when a document is authored on a client computer and then published to a Web server.

•      How readers view the document, such as from a Web page or a file share.

Worksheet action

The Analyze document usage worksheet (http://go.microsoft.com/fwlink/?LinkId=73284&clcid=0x409) is provided to record your document usage analysis. The following are examples of information that might be collected and recorded in the worksheet from two different organizations in an enterprise.

Type

Purpose

Author

User

Format

Other Roles

Locations

Equity research note

Gives premium customers of a financial service guidance on whether to buy or sell one or more stocks

Financial analyst

Customer

DOCX (for authoring); PDF (for publishing)

Reviewer (technical); reviewer (legal); approver; copy editor; records manager; site administrator

•      Authoring site

•      Testing site

•      Internet

•      Records repository

Analysis   The separate authoring and publishing formats require a format conversion. The large number of reviewers requires one or more workflows (business processes implemented on the server). The four sites (authoring, testing, Internet, and records repository) require mechanisms for moving the content from one site to another. The need to archive the content in a corporate records repository and the regulatory implications of publishing equities advice require corporate policies and best practices such as content auditing and retention.

Type

Purpose

Author

User

Format

Other Roles

Locations

Employee performance review

Evaluates the performance of an employee — including self-evaluation and manager's evaluation

Information worker; manager

Managers; human resources specialists

.DOC

Reviewer (human resources); reviewer (legal); approver (upper manager); records manager

•      Client computer

•      E-mail server (as attachment)

•      Corporate Web server

•      Corporate records repository

Analysis   Two authors and multiple reviewers require one or more workflows. The document travels from one desktop computer to another as an e-mail attachment, then resides in a corporate Web server (presumably highly locked down) and is archived in a records repository. The sensitive nature of this content requires Information Rights Management (IRM) on the desktops and servers, in addition to corporate policies and best practices (such as auditing) that protect the employee's privacy and the enterprise's legal standing.

Worksheet

Use the following worksheet to record the information discussed in this article:

•      Analyze document usage worksheet (http://go.microsoft.com/fwlink/?LinkId=73284&clcid=0x409)

Download this book

This topic is included in the following downloadable book for easier reading and printing:

•      Document Management Guide for Office SharePoint Server 2007 (http://go.microsoft.com/fwlink/?LinkID=92638)

See the full list of available books at Downloadable books for Office SharePoint Server 2007 (http://technet.microsoft.com/en-us/library/cc262788(TechNet.10).aspx).

Plan document libraries

In this article:

•      Plan document libraries

•      Plan the flow of content

•      Promoting document libraries from Office client programs

Document libraries are collections of files on Microsoft Office SharePoint Server 2007 that you share with other site users. Most Microsoft Office SharePoint Server 2007 document management features are delivered through document libraries. As part of document management planning, you should determine the document libraries that best fit your organization's needs.

When you identify which document libraries best match your organization's needs, you might also determine that you need multiple sites or site collections. For example, if you are authoring content for publication to external customers, you might need one site (and library) in which to author and review content and a separate site, perhaps in a separate Office SharePoint Server 2007 installation, in which to publish your content.

When you plan document libraries over multiple sites, you may also need to plan how content flows from one site to another — by manual processes, workflows, or custom solutions.

Plan document libraries

The following table lists typical uses of document libraries in Office SharePoint Server 2007.

Library

Purpose

Library in a team site

Collaboration; easy sharing of content among peers; content control, such as versioning and moderation; Office SharePoint Server 2007 searching.

Library in a portal area

Content that is intended for a wider audience in the organization; similar to a library in a team site, but typically implemented with a more-stringent review and approval process.

Library in a Document Center site

A large-scale library useful as an enterprise knowledge base or historical archive; includes features to help users navigate, search, and manage a large number of documents in a deep hierarchy by using a set of specialized Web Parts.

Library in a Records Repository

Specialized records management; each library corresponds to a record type, such as contract, that the organization must retain for legal compliance purposes; libraries retain documents, metadata, and associated audits and are meant to be read-only.

Library in an Internet site (HTML)

Contains Web pages to incorporate in an Internet or intranet Web site; Office SharePoint Server 2007 supports editing Web pages directly and manages the underlying document libraries for each page automatically.

Library in an Internet site (hybrid)

Content available for downloading from a Web site; you can present content from document libraries on an Internet site.

Translation management document library

Designed for translating documents, if your enterprise works in multiple languages. It includes a specialized translation workflow and views that show multiple language versions of the same document or all documents in a particular language.

Slide library

Supports sharing, managing, and reusing Microsoft Office PowerPoint 2007 slides.

The following example illustrates how to use the analysis that you completed in Analyze document usage to help you plan document library organization for your enterprise. In this example, Contoso Ltd. delivers content to clients based on market research. The content is created primarily by consultants operating remotely. This is done in a cycle in which:

1.   A partner evaluates engagement ideas and requests for proposals.

2.   After a contract is established, a project manager assembles a team of consultants and creates an engagement-specific working site in which the results of the research are recorded and the project is completed.

3.   When the project is done, the deliverable documents are published to a secured Internet site, where customers have access to them.

4.   The team writes best practices documents and case studies based on the project.

5.   Knowledge managers collect, organize, and archive the best practices and other documents.

6.   Deliverables, contracts, and other records are retained as corporate records.

7.   Using the content maintained by the knowledge managers, partners evaluate opportunities and create new proposals.

The following table illustrates a document usage analysis for this scenario.

Documents

Purpose

Author

Users

Format

Engagement ideas and requests

Develop new customer engagements

Project leader

Sales manager; project leader

.doc

Proposals

Describe a proposed customer engagement

Project leader

Project managers; project team members; customers

.doc

Contracts

Commit to a consulting engagement

Lawyer

Project leader; project manager; sales manager; customers

.doc

Research results and project deliverable drafts

Generate documents related to the customer engagement

Project leader; project contributor; consultant

Editors; technical reviewers

.doc and other types

Deliverable documents

Generate final deliverables, probably converted from .doc format

Project leader

Customers

.pdf

Best practices and case study documents

Capture organizational knowledge

Project contributor; consultant; knowledge manager

All team members

Various types

Corporate records

Retain some content, such as deliverable documents, as corporate records

All

Corporate records managers; corporate lawyers

All

This document usage analysis suggests the following conclusions:

•      Project leaders need libraries in team sites for storing engagement ideas, engagement requests, and proposal drafts.

•      Lawyers need libraries in a portal area for storing contract templates and active contracts.

•      Project leaders and contributors need libraries in team sites for authoring research results, deliverables, and case studies.

•      Customers need libraries in an Internet site for viewing final deliverables.

•      All members of the enterprise need access to a Document Center site for viewing best practices and case study documents.

•      Corporate records managers and lawyers need access to an enterprise Records Repository to maintain corporate records.

The following figure illustrates how these libraries might be distributed. The sites are hosted in three site collections: an Internet site collection for customer access, an extranet site collection for remote authoring by team members, and an intranet site collection for secure maintenance of the records management site.

Worksheet action

The Document libraries worksheet (http://go.microsoft.com/fwlink/?LinkId=77248&clcid=0x409) is provided to record your library planning decisions. Use this worksheet to list the libraries required for your solution, along with the types of documents they contain. Note that libraries can contain more than one type of document.

Plan the flow of content

Content in a document management solution based on Office SharePoint Server 2007 is often dynamic, moving from one site to another as needed to meet document users' needs. When you plan document libraries, therefore, also plan the flow of content from one library or site to another. Office SharePoint Server 2007 includes the following ways to move content, either manually or dynamically:

•      You can create custom workflows that copy or move content from one site or library to another. A workflow guides a document through a business process, assigning tasks to participants as their role in the document's life cycle becomes active. A workflow can be designed to move a document from one site or library to another. For information about planning workflows, see Plan workflows for document management.

•      Authors can copy a document to a library in any site in which they have authoring permissions. The relationship between the source and the destination document is maintained so that the copy can be refreshed as needed.

•      Web pages and entire Web sites can be staged and published from one site to another either manually or automatically based on a schedule.

•      Content can be sent to the records management site by using the Office SharePoint Server 2007 user interface, by using a workflow, or by using a custom solution based on the Windows SharePoint Services 3.0 object model.

•      Using Web Folders or Network Places, an author can manually copy or move the contents of a document library from one library or site to another.

Returning to our example, the following figure illustrates how to apply some of these content flow techniques. Note that the Staged Internet site has been added to the Authoring portal site.

•      Using publishing features, Web pages are published to the Internet site.

•      Using the Copy command, documents are copied to the Document Center site.

•      Using a custom workflow, documents are copied to document libraries on the Internet site.

•      Using the Send to Records Repository command, contracts are sent to the enterprise Records Repository.

Promoting document libraries from Office client programs

You can customize the 2007 Office systemOpen and Save dialog boxes to encourage organization members to use document libraries as storage locations. By adding sites to the My Places bar next to the Open and Save dialog boxes, you can provide one-click access to the locations where users should store their documents. This enables team members to interact with the document libraries as part of the Save experience from 2007 Office system client programs, rather than having to go directly to the server to upload their documents.

To promote using sites in the Open and Save dialog boxes, you can publish them by using a Microsoft Office SharePoint Server 2007 Web service. This service provides a list of sites targeted to specific users based on their roles or the sites that they are members of. A 2007 Office system client program can automatically discover this Web service through the user's My SharePoint Sites. Other server products can also implement this Web service and provide the location of the service to the Office client. After this is configured, 2007 Office system adds an entry to the My Places bar and populates it with the locations defined by the Web service.

Alternatively, administrators can set registry keys to add specific sites to the My Places bar in the Office Open and Save dialog boxes. Registry keys are deployed by using Group Policy and a Microsoft Active Directory directory service template provided in the 2007 Office system Resource Kit.

You can limit the locations that organization members can save to using the Office Save dialog box. For example, you can restrict the ability to save files to desktops and force users to save content in a document library. In 2007 Office system, you can control where users are allowed to browse to save their documents, thereby guiding users to save in approved locations. Note that this does not guarantee that users won't save files to their local computers or other unapproved locations. There are many ways to get files onto a computer, and motivated people can work around most restrictions. However, by limiting access to these locations through the Office Save dialog box, you can dramatically reduce the number of team members who use these unapproved locations.

To restrict the locations available in the Office Save dialog box, use Group Policy to set the appropriate registry keys to enable this setting and define the approved local, network, or server locations. When this setting is enabled, any location not defined in this manner — including standard links to the Desktop and My Network Places — will be removed from the My Places bar.

The list of approved locations can be limited to one or more Office applications. For example, an administrator can restrict save locations in Microsoft Office Access 2007 while allowing other Office applications to save anywhere.

Download this book

This topic is included in the following downloadable book for easier reading and printing:

This topic is included in the following downloadable book for easier reading and printing:

•      Document Management Guide for Office SharePoint Server 2007 (http://go.microsoft.com/fwlink/?LinkID=92638)

See the full list of available books at Downloadable books for Office SharePoint Server 2007 (http://technet.microsoft.com/en-us/library/cc262788(TechNet.10).aspx).

See Also

Plan content types

Plan content types

In this article:

•      What are content types?

•      Properties integration with the 2007 Office release

•      About column templates

•      About folder content types

•      Planning document content types

•      Planning list content types

•      Planning document conversions

•      After planning content types: next steps

•      Worksheets

This topic describes content types and related features, and provides guidance on planning content types for your solution based on Microsoft Office SharePoint Server 2007.

What are content types?

A content type defines the attributes of a list item, a document, or a folder. Each content type can specify:

•      Properties to associate with items of its type.

•      Workflows that can be launched from items of its type.

•      Information management policies to associate with items of its type.

•      Document templates (for document content types).

•      Document conversions to make available (for document content types).

•      Custom features.

You can associate a content type with a list or library. When you do this, you are specifying that the list or library can contain items of that content type and that the New command in that list or library will let users create new items of that type.

Note:

Properties, workflows, policies, and templates can also be associated directly with a list or library. However, doing this limits these associations to the list or library and is not reusable across your solution.

Document libraries and lists can contain multiple content types. For example, a library can contain both the documents and the graphics related to a project. When a list or library contains multiple content types:

•      The New command in that list or library lets users create new items of all the associated content types.

•      The columns associated with all available content types are displayed.

You define custom content types in a site's content type gallery. A custom content type must be derived, directly or indirectly, from a core content type such as Document or Item. After it is defined in a site, a custom content type is available in that site and in all subsites below that site. To make a content type most broadly available, define it in the content type gallery of the top-level site in a site collection.

For example, if your organization uses a particular contract template, in the content type gallery of the top-level site in a site collection you can create a content type that defines the metadata for that contract, the contract's template, workflows required to review and complete the contract, policies that enforce auditing of actions related to the contract, a retention period for retaining the contract, and labels to insert in printed versions of the contract. Then, any document library in your site collection to which you associate the Contract content type will include all of these features and will enable authors to create new contracts based on the template.

In sites based on Office SharePoint Server 2007, each default list item or library item — such as Contact, Task, or Document — has a corresponding core content type in the site's content type gallery. When planning content types, you can use these core content type definitions as starting points, basing new content types on existing ones as needed or modifying the core types.

Content types are organized into a hierarchy that allows one content type to inherit its characteristics from another content type. This allows classes of documents to share characteristics across an organization, while allowing teams to tailor these characteristics for particular sites or lists.

For example, all customer deliverable documents in an enterprise may require a set of metadata such as account number, project number, and project manager. By creating a top-level Customer Deliverable content type from which all other customer deliverable document types inherit, you ensure that required information such as account numbers and project numbers will be associated with all variants of customer deliverable documents in your organization. Note that, if another required column is added to the top-level Customer Deliverable content type, the content type owner can propagate the changes to all content types that inherit from it, which will add the new column to all customer deliverable documents.

Properties integration with the 2007 Office release

In the 2007 Microsoft Office system, when a user is editing a document from a Office SharePoint Server 2007 document management server, a Document Information Panel is shown at the top of the document. The Document Information Panel displays an editable form that reflects the document's properties on the server.

Office SharePoint Server 2007 makes it easy to customize the property form for a content type. When you configure a content type, you can start Microsoft Office InfoPath 2007, which generates a default property form based on the properties of the content type. The default form includes the same controls, layout, and schema that 2007 Office system would use if no custom form were defined. You can then customize and deploy the form as you would any other Office InfoPath 2007 InfoPath form. For example, you can add your company logo, fonts, and color scheme to a form; connect it to a custom data source; add conditional logic; and design form features that are available to users based on their roles.

Along with editing properties in the Document Information Panel, authors using Microsoft Office Word 2007 can insert properties defined on the server into their documents. For example, if the document properties include an attorney name, this name can be inserted into the title page, the footer, or anywhere else the name is used in the document. If a new attorney is assigned to a particular case, the Attorney Name property can be updated on the document management server; this updated attorney name will be reflected in every instance of this property that has been inserted into a document.

About column templates

Each item of metadata associated with a content type is a column, which is a location in a list to store information. Lists or libraries in Office SharePoint Server 2007 are often displayed graphically as columns of information. However, depending on the view associated with the list, the columns can appear in other forms, such as days in a calendar display. In forms associated with a list or library, columns are displayed as fields.

You can define columns for use in multiple content types. To do this, create them in a Column Templates gallery. There is a Column Templates gallery in each site in a site collection. As with content types, columns defined in a site's Column Templates gallery are available in that site and in all of its subsites.

About folder content types

Folder content types define the metadata associated with a folder in a list or library. When you apply a folder content type to a list or library, the New command in that list or library will include the folder content type, letting users create folders of that type.

You can define views in a list or library that are available only in folders of a particular content type. This is useful when you want a folder to contain a particular type of document and you want views in that folder to only display columns relevant to the document type contained in that folder.

Using the Office SharePoint Server 2007 object model, you can customize the New command for a folder content type so that, when a user creates a new folder of that type, the folder is pre-populated with multiple files and documents based on templates stored on the server. This is useful, for example, for implementing a compound document type that requires multiple files to contribute to a single deliverable document.

Planning document content types

Plan document content types for your solution by using the Analyze document usage worksheet, which you filled in using the topic Analyze document usage. Use the Content type worksheet to record your decisions about each new content type.

Each document content type should inherit its settings directly from the core Document content type or from a content type that is descended from the Document content type. This will ensure that the basic columns for your document types, such as Title and Created By, are present and that you can associate a template with the content type.

The first stage in planning document content types is to review each document type listed in your Analyze document usage worksheet to determine if there is an existing content type available for documents of that type. If a core content type (such as Document) is sufficient, enter the content type name in the Content Type column of the Analyze document usage worksheet.

After reviewing your list of document types to determine which ones can use core content types, plan new document content types using the following steps. For each content type you plan, fill in a separate Plan a content type worksheet.

1.   Enter the document type from the Analyze document usage worksheet.

2.   Enter the site URL at which the new content type will be defined. Keep in mind that content types are available in the site in which they are defined and in all subsites below that site.

3.   Determine the parent content type   Enter the parent content type in the "Parent Content Type" field of the Plan a content type worksheet. This will be either a core content type or a custom content type that you have already planned.

4.   Determine the columns   In the "Plan Columns" table of the Plan a content type worksheet, do the following:

a.   Enter each column inherited from the parent content type. In the New? column, type No for each entry.

b.   For each additional column, enter the name of a pre-defined column or of a column that you will create. Keep in mind that the name of a column is important, because it can communicate the column's purpose. Therefore, even if a column of a type that you need is already defined in the Site Collection Column gallery, you might decide to define a similar column with a more relevant name for your application. Along with the names of the additional columns, enter their types and indicate whether or not they are new.

5.   Determine the template   In the Plan Template section of the worksheet, enter the name of the template to associate with this content type along with its type (such as .Docx) and a brief description of the purpose of the template. If the template is not inherited from the parent content type, in the "New?" field, type No.

6.   Determine the workflows   Workflows attach business logic to documents and list items in Microsoft Office SharePoint Server 2007. You can associate any available workflow with a content type; the workflow can then be initiated on any document of that content type. For a full discussion of workflow planning, see Plan workflows for document management. After reviewing workflows and determining which workflows are available, enter each workflow to associate with the content type in the "Plan Workflows" table of the Plan a content type worksheet. If the workflow is not inherited from the parent content type, enter that information in the New? column.

7.   Determine the policy   A policy is a set of rules for a type of content and is made up of policy features that provide the details of each rule, such as whether or not items of the content type can be printed or which actions on the item should be audited. You can apply a policy to any custom content type. Note that you cannot apply a policy to a core content type. For more information about policy planning, see Plan information management policies. After reviewing policies and determining which policy features and policy templates are available, in the Plan a Policy section of the Plan a content type worksheet, do the following:

a.   If the parent content type has policy settings, they will apply unchanged in the new content type. This ensures that policies, once set, are enforced in all relevant content types. If the current content type is inheriting its policy settings from its parent type, in the Plan a Policy section of the Plan a content type worksheet, answer Yes to the question, "Is the policy defined in the parent content type? Yes/No."

b.   If the current content type is inheriting a policy based on the parent content type, in the "Record the Policy Name" field of the Plan a Policy section, type the name of the policy template. Similarly, if the current content type does not inherit a policy and you want to apply a policy template, in the "Record the Policy Name" field of the Plan a Policy section, type the name of the policy template.

c.   If the current content type is inheriting one or more individual policy features from the parent content type, enter each policy feature in the "Feature" table in the Plan a Policy section of the worksheet. Conversely, if the current content type does not inherit a policy and you want to associate policy features with the current content type, enter those policy features in the "Feature" table. Note that you cannot associate both individual policy features and a policy by name to a content type.

8.   Determine document conversionsOffice SharePoint Server 2007 supports installing document conversion components on the server that transform documents from one format to another. For an overview of document conversions, see Planning document conversions, below.

You can associate one or more document converters with a content type. For example, if a content type is associated with a template of type .docx, you can associate the From Word Document to Web Page converter that is included in Office SharePoint Server 2007 with the content type. This lets authors write documents of the content type in Microsoft Office Word 2007 and then convert them to Web pages for publication.

Note:

In the Office SharePoint Server 2007 Central Administration pages, administrators can enable a document converter so that it is available in any document library in a Web application. When a converter is enabled in this way, it is not necessary to associate it with content types in any site in the Web application.

In the Plan Document Conversions section of the Plan a content type worksheet, record each document converter to associate with the content type, specify if the converter is new (and requires installation), and add optional notes.

Planning list content types

The elements of a list content type include the columns of metadata associated with the content type along with workflows that can run on items of that list content type. Use a list content type to define a type of list item unique to your solution. For example, in a customer call center solution, in which support professionals investigate and resolve customers' technical issues, a list content type could be used to standardize the data for each support incident and to support tracking the incident using a workflow.

Worksheet action

Plan new list content types using the following steps. For each list content type that you plan, fill in a separate Plan a content type worksheet. In the "Document Type" field of the worksheet, enter List.

1.   Enter the site URL at which the new content type will be defined. Content types are available in the site in which they are defined and in all subsites below that site.

2.   Determine the parent content type   Enter the parent content type in the "Parent Content Type" field of the Plan a content type worksheet. This will be either a core content type or a custom content type that you have already planned.

3.   Determine the columns   In the "Plan Columns" table of the Plan a content type worksheet, do the following:

a.   Enter each column inherited from the parent content type. In the New? column, type No for each entry.

b.   For each additional column, enter the name of a pre-defined column or of a column that you will create. Along with the names of the additional columns, enter their types and indicate whether or not they are new.

4.   In the Plan Template section of the worksheet, type None.

5.   Determine the workflows   If there is an available workflow that is relevant to the list content type, you can optionally associate it with the content type. The workflow could then be initiated on any list item of that content type. For a full discussion of workflow planning, see Plan workflows for document management. After reviewing workflows and determining which workflows are available, enter each workflow to associate with the content type in the "Plan Workflows" table of the Plan a content type worksheet. If the workflow is not inherited from the parent content type, enter that information in the New? column.

6.   In the Plan a Policy section of the worksheet, type None.

Planning document conversions

Office SharePoint Server 2007 supports installing document conversion components on the server that transform documents from one format to another. Conversions can be run either from the user interface or programmatically, such as from a custom workflow. The relationship between source documents and their transformed counterparts is maintained. Office SharePoint Server 2007 includes converters that create Web pages from Microsoft Office Word 2007 documents and from Microsoft Office InfoPath 2007 forms.

Along with providing the infrastructure on the server to install and run document converters, Microsoft Office SharePoint Server 2007 includes a load balancer service that you can configure to optimize the use of your server resources. Part of planning document conversions is tuning your server farm to optimally balance the load as documents are transformed.

To be available to users, a converter must be installed on the server farm and then enabled by a server administrator. After a converter is enabled for a server, it is available to run on source documents on that server.

You configure document converters using the following steps:

1.   In the document usage analysis that you perform in Analyze document usage, identify candidates for document conversion — that is, documents that are written in one format but that should be published or archived in another.

2.   For each conversion needed, locate converter programs to implement the needed conversions on your servers.

3.   If needed, install the conversion programs on application (middle tier) servers in your farm.

4.   Configure the launcher and load balancer services, either on the Web servers or application (middle tier) servers.

5.   Identify the points in your document flow at which conversions take place.

6.   Identify how conversions will be implemented — either manually or using custom solutions that launch them.

After planning content types: next steps

After planning document and list content types, here are some suggested next steps:

•      If you haven't already done so, in the Content Type column of the Analyze document usage worksheet, record each content type that you planned.

•      Sort your "Plan a content type" worksheets by site URL, and identify the new columns to define for each site.

•      Identify new templates to design.

•      Identify new workflows to plan and install.

•      Identify new policy templates to plan and new policy features to plan and install.

Worksheets

Use the following worksheets to record the information discussed in this article:

•      Analyze document usage worksheet (http://go.microsoft.com/fwlink/?LinkID=73284&clcid=0x409)

•      Content type worksheet (http://go.microsoft.com/fwlink/?LinkId=73288&clcid=0x409)

•      Plan a content type worksheet (http://go.microsoft.com/fwlink/?LinkId=73292&clcid=0x409)

Download this book

This topic is included in the following downloadable book for easier reading and printing:

•      Document Management Guide for Office SharePoint Server 2007 (http://go.microsoft.com/fwlink/?LinkID=92638)

See the full list of available books at Downloadable books for Office SharePoint Server 2007 (http://technet.microsoft.com/en-us/library/cc262788(TechNet.10).aspx).

Plan versioning, content approval, and check-outs

In this article:

•      Plan versioning

•      Plan content approval

•      Plan check-in and check-out

•      Worksheet

Microsoft Office SharePoint Server 2007 includes features that can help you control access to content. You configure settings for the content control features discussed in this article in document libraries. To share these settings across libraries in your solution, you can create document library templates that include your content control settings; this ensures that new libraries will reflect your content control decisions.

Plan versioning

Versioning is the method by which successive iterations of a document are numbered and saved. Office SharePoint Server 2007 has three versioning options:

•      None   Specifies that no previous versions of documents are saved. When no versioning is in use, previous versions of documents are not retrievable, and document history is also lost because comments that accompany each iteration of a document are not saved. Use this option on document libraries containing unimportant content or content that will never change.

•      Major versions only   Specifies that numbered versions of documents are retained using a simple versioning scheme (such as 1, 2, 3). To control the effect on storage space, you can specify how many previous versions to keep, counting back from the current version.

In major versioning, each time a new version of a document is saved, all users with permissions to the document library will be able to view the content. Use this option when you do not want to differentiate between draft versions of documents and published versions. For example, in a document library that is used by a workgroup in an organization, major versioning is a good choice if everyone on the team needs to be able to view all iterations of each document.

•      Major and minor versions   Specifies that numbered versions of documents are retained by using a major and minor versioning scheme (such as 1.0, 1.1, 1.2, 2.0, 2.1). Versions ending with .0 are major versions and versions ending with non-zero extensions are minor versions. Previous major and minor versions of documents are saved along with current versions. To control the effect on storage space, you can specify how many previous major versions to keep, counting back from the current version. You can also specify for how many major versions minor versions should be kept. For example, if you specify that minor versions should be kept for two major versions and the current major version is 4.0, then all minor versions starting at 3.1 will be kept.

In major and minor versioning, any user with read permissions can view major versions of documents. You can specify which users can view minor versions. Typically, grant users who can edit items permissions to view and work with minor versions, and restrict users with read permissions to viewing only major versions.

Use major and minor versioning when you want to differentiate between published content that can be viewed by an audience and draft content that is not yet ready for publication. For example, on a human resources Web site that describes organizational benefits, use major and minor versioning to restrict employees' access to benefits descriptions while the descriptions are being revised.

Worksheet action

In the Document libraries worksheet (http://go.microsoft.com/fwlink/?LinkID=73306&clcid=0x409), for each document library listed, specify the versioning scheme to use: none, major, or major and minor.

Plan content approval

Content approval is the method by which site members with approver permissions control the publication of content. A document draft awaiting content approval is in the Pending state. When an approver reviews the document and approves the content, it becomes available for viewing by site users with read permissions. A document library owner can enable content approval for a document library and can optionally associate a workflow with the library to run the approval process.

Use content approval to formalize and control the process of making content available to an audience. For example, an enterprise that publishes content as one of its products or services might require a legal review and approval before publishing the content.

The way that documents are submitted for approval varies depending on the versioning settings in the document library:

•      None   If no versioning is in use and changes to a document are saved, the document's state becomes Pending. Office SharePoint Server 2007 keeps the previous version of the document so users with read permissions can still view it. After the pending changes have been approved, the new version of the document is made available for viewing by users with read permissions and the previous version is discarded.

If no versioning is in use and a new document is uploaded to the document library, it is added to the library in the Pending state and is not viewable by users with read permissions until it is approved.

•      Major versions only   If major versioning is in use and changes to a document are saved, the document's state becomes Pending and the previous major version of the document is made available for viewing by users with read permissions. After the changes to the document are approved, a new major version of the document is created and made available to site users with read permissions, and the previous version is saved to the document's history list.

If major versioning is in use and a new document is uploaded to the document library, it is added to the library in the Pending state and is not viewable by users with read permissions until it is approved as version 1.

•      Major and minor versions   If major and minor versioning is in use and changes to a document are saved, the author has the choice of saving a new minor version of the document as a draft or creating a new major version, which changes the document's state to Pending. After the changes to the document are approved, a new major version of the document is created and made available to site users with read permissions. In major and minor versioning, both major and minor versions of documents are kept in a document's history list.

If major and minor versioning is in use and a new document is uploaded to the document library, it can be added to the library in the Draft state as version 0.1, or the author can immediately request approval in which case the document's state becomes Pending.

Worksheet action

In the Document libraries worksheet (http://go.microsoft.com/fwlink/?LinkID=73306&clcid=0x409), specify whether or not to require content approval for each document library listed.

Plan check-in and check-out

You can require that users check documents in and out of a document library before editing the documents. It is always recommended to do this. The benefits of requiring checking in and out include:

•      Better control of when document versions are created. When a document is checked out, the author can save the document without checking it in. Other users of the document library will not be able to see these changes and a new version is not created. A new version (visible to other users) is only created when an author checks in a document. This gives the author more flexibility and control.

•      Better capture of metadata. When a document is checked in, the author can write comments that describe the changes made to the document. This promotes creation of an ongoing historical record of the changes made to the document.

If your solution requires that users check documents in and out when editing them, the 2007 Microsoft Office system client programs include features that support these actions. Users can check documents out, undo check-outs, and check documents in from 2007 Office system client programs.

When a document is checked out, it is saved in the user's My Documents folder in a subfolder named "SharePoint Drafts." This folder is displayed in Microsoft Office Outlook 2007. As long as the document is checked out, the user can only save edits to this local folder. When the user is ready to check the document in, the document is saved back to the original server location.

From 2007 Office system client programs, users can optionally choose to leave checked-out documents on the server by changing content editing options.

Worksheet action

In the Document libraries worksheet (http://go.microsoft.com/fwlink/?LinkID=73306&clcid=0x409), specify whether or not to require check-in and check-out for each document library listed.

Worksheet

Use the following worksheet to help you plan versioning, content approval, and check-outs:

•      Document libraries worksheet (http://go.microsoft.com/fwlink/?LinkID=73306&clcid=0x409)

Download this book

This topic is included in the following downloadable book for easier reading and printing:

•      Document Management Guide for Office SharePoint Server 2007 (http://go.microsoft.com/fwlink/?LinkID=92638)

See the full list of available books at Downloadable books for Office SharePoint Server 2007 (http://technet.microsoft.com/en-us/library/cc262788(TechNet.10).aspx).

See Also

Plan document libraries

Plan Information Rights Management

In this article:

•      Information Rights Management in Office SharePoint Server 2007

•      Worksheet

Information Rights Management (IRM) enables content creators to control and protect their documents. The contents of rights-managed documents are encrypted and supplied with an issuance license that imposes restrictions on users. These restrictions vary depending on the level of users' permissions. Typical restrictions include making a document read-only, disabling copying of text, not allowing users to save a copy of the document, or preventing users from printing the document. Client applications that read IRM-supported file types use the issuance license inside an IRM-managed document to enforce the restrictions on users who access the document.

Information Rights Management in Office SharePoint Server 2007

Microsoft Office SharePoint Server 2007 supports using IRM on documents stored in document libraries. Documents that can be rights-managed in Office SharePoint Server 2007 include Microsoft InfoPath forms, Microsoft Word, Microsoft Excel, and Microsoft PowerPoint file formats, in addition to Word, Excel, and PowerPoint Open XML file formats. To add other file types, an administrator must install protectors — programs that control the encryption and decryption of rights-managed documents — for each new type of file.

By using IRM in Office SharePoint Server 2007, you can centrally control which actions users can take on documents when they open them from libraries in Office SharePoint Server 2007. This is in contrast to IRM applied to documents stored on client computers, where the owner of a document can choose which rights to assign to each user of the document. Use IRM on document libraries to control sensitive content that is stored on the server. For example, if you are making a document library available to preview upcoming products to other teams within your enterprise, you could use IRM to prevent the teams from publishing the content to audiences outside your organization.

When IRM is enabled on a document library and a document of a type that can be rights-managed is downloaded from the server to a client application, Office SharePoint Server 2007 encrypts the document and adds an issuance license. When the document is uploaded back to the server, Office SharePoint Server 2007 decrypts the file and stores it in the library in unencrypted form. By only encrypting documents when they are downloaded and decrypting them when they are uploaded, Office SharePoint Server 2007 enables features such as search and indexing to operate as usual on the files in the IRM-protected document library. The IRM permissions that are applied to a document when users upload it from a document library are based upon each user's permissions to the content in the Office SharePoint Server 2007 security settings. The following table describes how Office SharePoint Server 2007 permissions are converted to IRM permissions:

Office SharePoint Server 2007 permissions

IRM permissions

Manage Permissions, Manage Web

Full control, as defined by the client. This generally allows a user to read, edit, copy, save, and modify the permissions of rights-managed content.

Edit List Items, Manage List, Add and Customize Pages

Edit, copy, and save permissions. You can optionally enable users with these permissions to print documents from the document library.

View List Item

Read permissions. A user can read the document, but cannot copy or update its content. You can optionally enable users with view list item permissions to print documents from the document library.

Other

No other permissions map to IRM permissions.

To use IRM in Office SharePoint Server 2007, you must install the Microsoft Windows Rights Management Services Client, version 1, on every front-end Web server in your server farm. In addition, Microsoft Windows Rights Management Services (RMS) for Windows Server 2003, service pack 1.0 or later, must be available on your network. To install the Windows Rights Management Services Client, and for additional information about Microsoft Windows Rights Management Services, visit the Windows Rights Management Services Technology Center (http://go.microsoft.com/fwlink/?LinkId=73121). For a description of the steps needed to configure Microsoft Windows Rights Management Services to allow Office SharePoint Server 2007 to create rights-managed content, see Deployment for Office SharePoint Server 2007.

Worksheet

For each document library, specify whether or not to require IRM and, if protectors for additional document types are required, note that information in the Require Information Rights Management column. Use the following worksheet to record the information:

•      Document libraries worksheet (http://go.microsoft.com/fwlink/?LinkId=73306&clcid=0x409)

Download this book

This topic is included in the following downloadable book for easier reading and printing:

•      Document Management Guide for Office SharePoint Server 2007 (http://go.microsoft.com/fwlink/?LinkID=92638)

See the full list of available books at Downloadable books for Office SharePoint Server 2007 (http://technet.microsoft.com/en-us/library/cc262788(TechNet.10).aspx).

Plan workflows for document management

Workflows implement business processes on documents, Web pages, forms, and list items in Microsoft Office SharePoint Server 2007. They can be associated with libraries, lists, or content types. For an overview of workflows, see the topic Plan workflows.

In document management, use workflows to route documents from person to person so they can each complete their document management tasks, such as reviewing documents, approving their publication, or managing their disposition. Also, use custom workflows to move documents from one site or library to another. For example, you can design a workflow to copy a document from one site to another when the document is scheduled to be archived.

Office SharePoint Server 2007 includes workflows that address the following document management needs:

•      Collect Feedback — Sends a document for review.

•      Approval — Sends a document for approval, often as a prerequisite to publishing it.

•      Disposition — Manages document expiration and disposition.

•      Collect Signatures — Routes a document for signatures.

•      Translation — Manages the translation of a document into one or more languages.

•      East Asian Document Approval — Routes a document for approval using stamp signatures and a group-oriented consensus process.

Associate a workflow with a content type when you want to make that workflow available whenever that content type is in use. For example, a purchase order content type could require approval by a manager before completing the transaction. To ensure that the approval workflow is always available when a purchase order is initiated, create a Purchase Order content type and associate the approval workflow with it. Then add the Purchase Order content type to any document libraries in which purchase orders will be stored.

To plan workflows for your document management solution, analyze each document content type you plan to implement and identify the business processes that need to be available to run on content of that type. Then identify the workflows you will need to make available for that content. For more information about planning content types, see the topic Plan content types.

Worksheet action

In the Plan Workflows section of the Plan a content type worksheet (http://go.microsoft.com/fwlink/?LinkId=73292&clcid=0x409), enter the name of each workflow and its purpose, and indicate if a new (custom) workflow is needed to implement the process.

Here is a sample table analyzing workflows for a contract content type:

Contract Process

Contract Workflow

New?

Review drafts

Collect feedback

No

Get manager's and legal counsel's approval

Approval

No

Resolve open issues

Issue tracking

No

Get signatures

Collect signatures

No

Worksheet

Use the following worksheet to record the information discussed in this article:

•      Plan a content type worksheet (http://go.microsoft.com/fwlink/?LinkId=73292&clcid=0x409)

Download this book

This topic is included in the following downloadable book for easier reading and printing:

•      Document Management Guide for Office SharePoint Server 2007 (http://go.microsoft.com/fwlink/?LinkID=92638)

See the full list of available books at Downloadable books for Office SharePoint Server 2007 (http://technet.microsoft.com/en-us/library/cc262788(TechNet.10).aspx).

Plan information management policies

In this article:

•      About information management policies and policy features

•      About information management policy reporting

•      About information management policy integration with the 2007 Office system applications

•      Policy features available in Office SharePoint Server 2007

•      Plan information management policies

About information management policies and policy features

An information management policy is a set of rules for a type of content. Each rule in a policy is a policy feature. For example, an Information Management policy feature could specify how long a type of content should be retained, or it could provide document auditing. Information management policies enable you to control who can access your organizational information, what they can do with it, and how long the information should be retained.

Note:

In this topic, the term "policy" refers to information management policy unless otherwise specified.

Policies can be implemented to help an organization comply with legally mandated requirements, such as the need to retain records. For example, a Human Resources policy, used in an organization to ensure that employee records are handled in accordance with legally recommended guidelines, could include the following policy features:

•      Auditing, to record the editing and viewing history of each employee-related document.

•      Retention, to ensure that work-in-progress content is not kept for an unnecessarily long period of time.

•      Labels, to ensure that physical copies of each document are properly identifiable.

•      Print Restrictions, to ensure that sensitive employee-related documents are only printed on secure printers. Note that this is an example of a custom policy that must be implemented using the Office SharePoint Server 2007 object model or acquired from a 3rd-party software vendor.

Policy features are implemented as programs that run on the Office SharePoint Server 2007. They can be enabled and configured by a server administrator and, once enabled, they can be used by site administrators to define policies. Office SharePoint Server 2007 includes five policy features to help you manage your content. By using the Office SharePoint Server 2007 object model, you can design and install custom policy features that meet unique enterprise needs.

A policy feature may use one or more policy resources, which are programs that provide some functionality to a policy feature. For example, a policy resource for a Barcode Generation policy feature could provide the unique barcode value. You can develop custom policy resources and install them to support policy features.

When your organization uses 2007 Microsoft Office system client applications along with Office SharePoint Server 2007, policies are enforced both on the server and in the client applications. This is done transparently; policy features that apply to a document are described in a policy statement associated with the document, and policy-aware applications prevent users from doing tasks that violate the document's policy.

To implement a policy, associate it with content types, libraries, or lists in sites.

Note:

In the Site Content Type Gallery, you can apply a policy to any custom content type, but you cannot apply a policy directly to a core content type.

You can associate a policy with a library, list, or content type in the following ways:

•      Associate policy features with a site collection policy, and then associate that policy with a content type or with a list or library.   The top-level site of a site collection includes a Site Collection Policies gallery where administrators of the top-level site can create new policies. After creating a Site Collection policy, you can export it so that administrators of other site collections can import it into their Site Collection Policy galleries. This enables you to standardize policies across your organization.

When a Site Collection policy is associated with a content type and that content type is associated with a list or library, the owner of the list or library will not be able to modify the Site Collection policy in the list or library. This ensures that policies assigned to a content type are enforced at each level of the site hierarchy.

•      Associate a set of policy features directly with a content type, and then add that content type to one or more lists or libraries.   To ensure that a policy created using this method will be used in an entire site collection, associate it with a content type in the top-level site collection's Site Content Type gallery. Then every item in the site collection of that content type, and every item of a content type that inherits from the original content type, will have the policy. When you use this method of associating a policy with a content type, it is harder to reuse the policy in other site collections, because policies created using this method cannot be exported.

Note:

To more tightly control which policies are in use in a site collection, site collection administrators can disable the ability to set policy features directly on a content type. When setting policy features on a content type is restricted, content type designers can only associate policies from the Site Collection Policies gallery with content types.

•      Associate a set of policy features directly with a list or library.   You can only use this method if the list or library does not support multiple content types. This method of creating a policy is only useful for a narrowly defined policy that applies to a single list or library.

Note:

To more tightly control which policies are in use in a site collection, site collection administrators can disable the ability to set policy features directly on a library. When setting policy features on a library is restricted, content type designers can only associate policies from the Site Collection Policies gallery with libraries.

About information management policy reporting

To track how policies are being used in each Web application in your solution, you can configure information management policy usage reporting using Microsoft Office SharePoint Server 2007 Central Administration. Information management policy reports help you monitor how well your organization uses policies. Because policies are often implemented to help an organization comply with particular regulations, frequent monitoring of policy usage can help you ensure that your organization is compliant.

Office SharePoint Server 2007 includes a default policy report template in XML-SS format, and you can create a custom report template based on the XML-SS schema. You can specify a schedule for policy reporting and you can generate reports manually.

A policy report is generated for each site collection in a Web application. For each list and library, a report records:

•      The number of items using each policy.

•      For each policy in use, either based on a Site Collection policy or configured in a content type, a summary of that policy — its description, along with a description of each policy feature.

For more information about creating and deploying a custom Site Collection policy report, see the Deployment for Office SharePoint Server 2007 guide.

About information management policy integration with the 2007 Office system applications

Office SharePoint Server 2007 information management policies are exposed in 2007 Office system clients. When you configure an information management policy on the server, you can write a policy statement that informs information workers about the policies that are enforced on documents. For example, the policy statement might indicate that a document will expire after a certain period of time, or that it is sensitive information that should not be communicated outside the company. The statement might even provide a contact name if the information worker needs more information about the policy.

The policies that are included in Office SharePoint Server 2007 are exposed to information workers through 2007 Office system client features. For example, when a label is defined as part of a policy, users can insert labels into documents from the Insert menu of most 2007 Office system client applications. If a label is required, users are prompted when saving documents in which a label has not been inserted. Similarly, users will be able to insert barcodes from client applications if that policy feature is part of the document's policy.

Custom policy features can also be integrated in 2007 Office system clients. However, you must implement policy-specific behaviors that you want to be available from 2007 Office system client programs, and you must give users a way to install these behaviors on their client computers via mechanisms such as add-ins to make them available from 2007 Office system client programs. For example, if you implement a custom policy feature that restricts the printers that can be used to print a content type, you must provide a custom add-in for Microsoft Office clients to enforce the restriction from Office client applications.

Policy features available in Office SharePoint Server 2007

This section describes the policy features that are included in Office SharePoint Server 2007.

•      Expiration   The Expiration policy feature helps dispose of content in a consistent way that can be tracked and managed. You can set content of a specific type to expire on a particular date, or within a calculated amount of time after some document activity (such as creating the document).

•      Auditing   The Auditing policy feature logs events and operations performed on documents and list items. You can configure Auditing to log events such as:

•      Editing a document or item

•      Viewing a document or item

•      Checking a document in or out

•      Changing the permissions for a document or item

•      Deleting a document or item

•      Labeling   The Labeling policy feature specifies a label to associate with a type of document or list item. Labels are searchable text areas that Office SharePoint Server 2007 generates based on properties and formatting that you specify. For example, in a law firm, a document related to a legal matter could include a label containing the clients' names, the case number, the attorney assigned to the matter, and so forth. Labels are particularly useful in printed versions of documents as a way to display document properties in printed copy. Along with using labels for documents, you can associate a label with a list item and include that label in views of the list.

•      Barcode   The Barcode policy feature enables you to track a document in physical copies by creating a unique identifier value for a document and inserting a barcode image of that value in the document. By default, barcodes are compliant with the common Code 39 standard (ANSI/AIM BC1-1995, Code 39), and you can plug in other barcode providers using the policies object model.

Plan information management policies

When planning your solution's policies, first determine organization-wide policy needs, and then design Site Collection policies to meet those needs and distribute those policies for inclusion in all relevant site collections' Site Collection Policy galleries. This might require planning custom policy features. Note that, if your policy requires custom policy features and resources, those features and resources must be installed and enabled on all server farms on which your solution is used. See the Deployment for Office SharePoint Server 2007 guide for more information about deploying and enabling Office SharePoint Server 2007 features and resources.

A typical example of an organization-wide policy is one designed to promote best practices in auditing and expiring product specifications across the divisions of an organization. A single Site Collection policy is designed to be applied to all product specifications so that they are consistently audited and retained. After defining the Site Collection policy and testing it, it is exported and then imported to Site Collection Policy galleries of other site collections in which product specifications are stored. It is then associated with all product specification content types in the various site collections to impose the policy on all product specification documents.

Worksheet action

To help you plan information management policies, use the Policy worksheet (http://go.microsoft.com/fwlink/?LinkId=73307&clcid=0x409). Create a separate worksheet for each policy you are planning, and in each worksheet record:

•      The purpose of the policy, such as "Policy to apply to all product specifications."

•      The site collection in which the policy is being designed.

•      The scope at which the policy is being defined. If the policy is to be used across multiple site collections, define it in the Policy Template gallery. Define a policy for a content type if the policy is more narrowly targeted to a single content type in a site collection.

•      Each policy feature, such as "Expiration" or "Auditing." Optionally enter configuration notes for a policy feature. For example, for Auditing, you could specify which actions to audit, such as "Editing Items." If the feature is custom, list all resources that must be installed for the feature to work.

•      All content types that the policy will be applied to and list all site collections in which the content types are in use.

Worksheet

Use the following worksheet with this article to help plan your deployment:

•      Policy worksheet (http://go.microsoft.com/fwlink/?LinkId=73307&clcid=0x409)

Download this book

This topic is included in the following downloadable book for easier reading and printing:

•      Document Management Guide for Office SharePoint Server 2007 (http://go.microsoft.com/fwlink/?LinkID=92638)

See the full list of available books at Downloadable books for Office SharePoint Server 2007 (http://technet.microsoft.com/en-us/library/cc262788(TechNet.10).aspx).

Plan enterprise content storage

This article contains information to help solution planners and designers properly plan and configure a large-scale enterprise content management solution based on Microsoft Office SharePoint Server 2007 so that it performs well while providing the features needed by site users. Office SharePoint Server 2007 supports high-capacity document storage; a document library can contain up to 5 million documents. However, depending on how the content is used, the performance of sites containing a very large number of documents can degrade. The prescriptive guidance provided in this article can help you design large-scale content management solutions that scale to the requirements of your enterprise while providing the users of your solution with a well-performing environment in which to create and use documents.

Decisions you make about the capacities of site collections, sites, and libraries in Office SharePoint Server 2007 should take into account not only the physical storage constraints of your Office SharePoint Server 2007 environment but also the content usage and viewing patterns of your users. For example, if users view or query a set of documents in a document library containing thousands of documents, performance can degrade if the site is not configured properly. Or if a service-level agreement requires that content be backed up twice a day, the service might not be satisfactorily performed if the set of content is too large. This article discusses techniques you can use to provide necessary content management functionality while maintaining acceptable performance.

In this topic, four levels of content storage are discussed:

•      Site collection

•      Site

•      Library

•      Folder

For each level of storage, this article describes the benefits of organizing content at that level, discusses how performance can decrease as the number of stored documents increases, and provides recommendations for improving performance when high volumes of content are present.

In this article:

•      Typical large-scale content management scenarios

•      Site collections: content storage benefits and limitations

•      Sites: content storage benefits and limitations

•      Libraries: content storage benefits and limitations

•      Folders: content storage benefits and considerations

•      Summary of recommendations

Note:

Although the examples in this article are primarily relevant for solutions based on Office SharePoint Server 2007, the prescriptive guidance information provided here applies to both Office SharePoint Server 2007 and Windows SharePoint Services 3.0.

Typical large-scale content management scenarios

Typically, large-scale content management scenarios are variants of one of the following scenarios:

•      Large-scale authoring environment

•      Large-scale content archive

•      Extremely large-scale content archive

The scenario descriptions provided here are intended to clarify what we mean by large-scale solutions and to provide examples that hopefully reflect your content management goals.

Large-scale authoring environment

In a large-scale authoring environment, a site can contain a library in which users actively edit 50,000 or more documents across 500 or more folders. Versioning is enabled, and typically 10 or more previous versions of each document exist. Documents are checked in and out frequently and workflows are used to control their life cycles. Twenty or more content types might be in use. A typical database for this type of site contains approximately 150 gigabytes (GB) of data. (Note that each version of a document is stored separately in the database.) Typically, in a large-scale authoring environment, 80% of site users are authors who have access to major and minor versions of documents, while 20% of site users have read-only permissions and can only view major versions of the content.

A large-scale authoring environment site can be based on the Office SharePoint Server 2007 Document Center site template, which includes a single, large document library and which is optimized for large-scale authoring. See The Document Center site.

Large-scale content archive

A large-scale archive is a document repository in which users are either viewing documents or uploading new documents. Little or no authoring takes place in the site. There are two primary large-scale archive scenarios: knowledge base and records management.

In a knowledge base site, there is only a single version of most documents, so the site can scale to easily hold 1,000,000 or more documents. The content is typically stored in a single database as large as 400 GB. In a typical scenario, such as an enterprise's technical support center, 10,000 users might access the content, primarily to read it. A subset of users (3,000–4,000) uploads new content to the site. A knowledge base site can be based on the Document Center site template.

Another type of large-scale archive is a records center, based on the Records Center site template. This site template contains features that you can use to manage the retention and disposition of records (documents that serve as evidence of activities or transactions performed by the organization and that must be retained for some time period). Similar to a knowledge base site, a records center contains a single version of each document and could typically hold 1,000,000 or more documents. Many more users submit content to a records center than view or read it.

Extremely large-scale content archive

If the user interface of a site is customized to remove resource-intensive user interface operations such as complex viewing queries, an extremely large-scale content archive can be used as a reference library or content repository. An extremely large-scale archive might contain up to 10,000,000 documents distributed across 5,000 or more folders. The database can grow larger than three terabytes (TB).

In an extremely large-scale archive, users (50,000 or more) primarily browse content by searching. Content is submitted by using a custom submission form.

Site collections: content storage benefits and limitations

A site collection is a set of Web sites that has the same owner and shares administration settings. Each site collection contains a top-level Web site and can contain one or more subsites. A site collection usually has a shared navigation structure.

Benefits of storing content in the same site collection

The sites in a site collection are usually interrelated by purpose. To maximize your solution's usability, store all related data and content within a single site collection. Benefits of doing this include:

•      Content types and columns managed in a site collection can be shared across all sites in the site collection. Conversely, there is no automatic mechanism for propagating content types and column definitions across multiple site collections.

•      Information management policies managed in the site collection can be made available to content in all sites in the site collection.

•      Office SharePoint Server 2007 automatically updates links to renamed or moved files within a site collection to reflect their new names or locations. Conversely, links to documents in other site collections are not updated.

•      If the site collection is on a server running Windows SharePoint Services 3.0, searching can only be done over the content in that site collection. If the site collection is on a server running Office SharePoint Server 2007, content can be searched across multiple site collections.

•      Some views in Windows SharePoint Services 3.0 and Office SharePoint Server 2007 list documents from multiple sites within a single site collection (for example, a view enumerating all tasks assigned to a user across a site collection). Also, developers can create cross-site database queries within a site collection, but cross-site queries are not supported across multiple site collections.

•      Content quotas and other quotas can only be managed at the site-collection level.

Limits on storing content in the same site collection

Keep the following limits in mind when planning how to allocate your content across one or more site collections:

•      Creating too many subsites of any site in a site collection might affect performance and usability. Limit the number of subsites of any site to 2,000 at most.

•      All sites in a site collection share the same back-end resources. In particular, all content in a site collection must be stored in the same content database. Because of this, the performance of database operations — such as backing up and restoring content — will depend on the amount of content across the entire site collection, the size of the database, the speed of the servers hosting the database, and other factors. Depending on the amount of content and the configuration of the database, you might need to segment a site collection into multiple site collections to meet service-level agreements for backing up and restoring, throughput, or other requirements. It is beyond the scope of this article to provide prescriptive guidance about managing the size and performance of databases. For more information about capacity planning, see Chapter overview: Plan for capacity.

•      Particularly, keep extremely active sites in separate site collections. For example, a knowledge base site on the Internet that allows anonymous browsing could generate a lot of database activity. If other sites use the same database, their performance could be impacted. By putting the knowledge base site in a separate site collection with its own database, you can free up resources for other sites that no longer have to compete with it for database resources.

Note that Windows SharePoint Services 3.0 and Office SharePoint Server 2007 have a number of features that mitigate the need to have your IT department restore content. The Recycle Bin and the Site Collection Recycle Bin provide a double safety mechanism for restoring inadvertently deleted items. Document versioning also provides a safety net for lost documents because their previous versions are available. To further ensure the availability of previous versions, an administrator can remove the delete versions permission from authors' permissions; this can help to guarantee that previous versions of content are available without having to restore them from the database.

Sites: content storage benefits and limitations

A Web site is the primary means of organizing related content in Office SharePoint Server 2007 and Windows SharePoint Services 3.0.

Benefits of storing content in the same site

•      It is easier to create pages that display views of multiple libraries and lists when they are in the same site.

•      The site navigation user interface is optimized to make it easy to find and navigate to libraries within the same site.

•      You define and assign permissions to groups at the site level.

•      You can define a set of content types and site columns for use in a site.

The Document Center site

Office SharePoint Server 2007 includes a Document Center site template. Use this template to create a site that is optimized for creating and using large numbers of documents.

To enable document management best practices, sites based on the Document Center site template have recommended document management features enabled by default, including:

•      Navigation features to help authors find their content.

•      Major/minor versioning enabled.

•      Required check-in and check-out of documents.

•      Multiple content types enabled.

•      A Relevant Documents Web Part that generates a personalized view of documents checked out by, created by, or last modified by the current user. You can configure the Web Part to use more than one criterion.

•      An Upcoming Tasks Web Part that generates a personalized view of document-related tasks assigned to the current user.

Column indexing is a technique that helps ensure that a view or query returns a list of items in the recommended range of 2,000 or fewer items. Use the following table to determine the right columns to index for each query that the Relevant Documents Web Part supports:

If you configure the Relevant Documents Web Part to…

Then, in the Shared Documents library, index the following column:

Include documents last modified by me

Modified By

Include documents created by me

Created By

Include documents checked out by me

Checked Out By

Along with indexing columns to improve the performance of the Relevant Documents Web Part, make sure that the Show items from the entire site collection checkbox is not selected when configuring the Web Part in a large-scale document management environment.

Limits on storing content in the same site

•      More than 2,000 libraries and lists in a single site will degrade performance.

•      Usability tests show that having more than 50 lists and libraries in the site's navigation structure makes it more difficult to navigate the content by using the user interface.

Libraries: content storage benefits and limitations

A document library is a location in a site containing files of one or more content types. Document libraries are designed to manage and store related documents and to let users create new documents of the appropriate types.

Benefits of storing content in the same library

•      It is easier for users to add new documents or find existing documents within a single library.

•      Many document management settings — such as permissions, content versioning, and approval — are applied at the library level.

•      Views created by using the user interface are bound to a particular library.

•      Information management policies, such as content auditing and retention settings, can be applied to a library.

Limits on storing content in the same library

•      The maximum recommended size of a library is 10,000,000 documents.

•      To apply unique document management settings to content, such as required checkouts or versioning, the content must be stored in a separate library.

•      If multiple content types are used in a library and each content type has one or more columns of metadata that only apply to that content type, views can become confusing. To alleviate this, you can associate each content type with a separate library.

•      The performance of views of content degrades when the number of items viewed exceeds 2,000 items. Remedies for this limitation are to organize the content in the library into folders each containing 2,000 or fewer items, or to create views that take advantage of indexed columns to return sets of 2,000 or fewer items (see below for a discussion of using indexed columns in views).

Note:

All Web page content in a site is stored in a single Pages library in that site, which contains all of that site's Web content pages. The recommended limitation of 2,000 or fewer items per view or query applies to Pages libraries in addition to document libraries.

Using indexed columns to improve view performance

As mentioned above, the performance of views degrades if the number of items displayed exceeds 2,000 items. A useful technique for limiting the number of items to display in a view is to index a column used in the view, and then to filter the view based on that column so that 2,000 or fewer items are displayed. (An indexed column is one that Office SharePoint Server 2007 maintains a record of to make view-related queries more efficient.)

For example, if it is unlikely that more than 2,000 items in a library will be modified in any seven-day period, you could index the Modified column in a library and then filter a view so that only items changed in the last seven days are displayed. (To do this, specify that the Modified column is less than Today-7.) As another example, if it is likely that each author will create less than 2,000 items, you could index the Created By column and then filter a view so that authors only see the documents they created. (To do this, specify that the Created By column is equal to Me.)

The following types of column types can be indexed and used to filter views:

•      Single line of text

•      Multiple lines of text

•      Number

•      Currency

•      Choice

•      Date and Time

•      Lookup

•      Yes/No

•      Person or Group

•      Calculated

Here are other considerations in creating views filtered by indexed columns:

•      Only one indexed column can be used in a view.

•      Do not create filters using "Or" to provide multiple criteria when using an indexed column to filter a view.

•      Using the Item Limit feature to modify a view does not improve the view's performance.

Note:

If a user tries to create a view that could benefit from using an indexed column, Office SharePoint Server 2007 will display a warning message recommending that approach.

Folders: content storage benefits and considerations

A folder is a named subdivision of the content in a library similar to folders in a file system. The primary purpose of folders is to organize content to match the expected functionality of the library. For example, if a library is intended to provide product specifications, the set of folders in the library could be named for each feature area in the product or for each team member who writes product specifications.

Folders can be used to enhance library performance. By dividing content across multiple folders, each containing 2,000 or fewer items, views on the folders will perform well. Note that, to take advantage of this, views available within folders must be configured to only show items inside the folders (this feature is available in the default Office SharePoint Server 2007 view-creation interface). Note also that, if folders contain 2,000 or fewer items, views in the folders do not have to be filtered using indexed columns.

Summary of recommendations

Here is a summary of the recommendations for improving performance at each level of storage when high volumes of content are being stored:

Level

Performance limits

Site collection

2,000 subsites of any site is the recommended limit.

The same content database is used for an entire site collection. This may affect performance in operations such as backup and restore.

Site

2,000 libraries and lists is the recommended limit.

Library

10,000,000 documents is the recommended limit.

2,000 items per view is the recommended limit.

Folder

2,000 items per folder is the recommended limit.

Download this book

This topic is included in the following downloadable book for easier reading and printing:

•      Document Management Guide for Office SharePoint Server 2007 (http://go.microsoft.com/fwlink/?LinkID=92638)

See the full list of available books at Downloadable books for Office SharePoint Server 2007 (http://technet.microsoft.com/en-us/library/cc262788(TechNet.10).aspx).

See Also

Plan for capacity (http://technet.microsoft.com/en-us/library/cc262971.aspx).

Plan records management (http://technet.microsoft.com/en-us/library/cc262114.aspx).

XI.  Plan records management

The articles in this chapter include:

•      Plan records management

•      What is records management?

•      Identify records management roles

•      Develop the file plan

•      Design the Records Center

•      Plan how records are collected

•      Plan physical records retention

•      Plan e-mail message records retention

Plan records management

Microsoft Office SharePoint Server 2007 includes records management features you can use to help your organization meet its regulatory and legal requirements and manage its corporate knowledge.

The articles in this chapter include:

•      What is records management? reviews the elements of a records management system and provides an overview of records management planning.

•      Identify records management roles helps you identify members of your organization with the range of records management–related roles and skills to support planning and implementing a records management solution based on Office SharePoint Server 2007.

•      Develop the file plan provides guidance on determining the types of records in your organization and on creating a file plan to specify retention periods, disposition plans, and other information for each record type.

•      Design the Records Center describes how to plan the document libraries, metadata, policies, and other features of a Records Center site, the Office SharePoint Server 2007 site you use to implement your file plan and manage records.

•      Plan how records are collected helps you plan how electronic and hard-copy records in your organization should move to the Records Center site.

•      Plan physical records retention describes planning tasks related to retaining physical records by using Office SharePoint Server 2007.

•      Plan e-mail message records retention describes planning tasks related to retaining e-mail messages by using Office SharePoint Server 2007.

•      Downloadable book: Records Management Guide for Microsoft Office SharePoint Server 2007 (http://technet.microsoft.com/en-us/library/cc262578.aspx) covers general records management planning considerations and guidelines for configuring Office SharePoint Server 2007.

•      Demo: Add a library to a Records Center site (http://technet.microsoft.com/en-us/library/cc263523.aspx) shows the process for adding a library to an existing Record Center, applying policies to the library, and configuring the Records Center site so that submitted documents are routed to the right library.

See Also

Plan document management

What is records management?

In this article:

•      Elements of a records management system

•      Overview of records management planning

Elements of a records management system

A record is a document or other electronic or physical entity in an organization that serves as evidence of an activity or transaction performed by the organization and that requires retention for some time period. Records management is the process by which an organization:

•      Determines what types of information should be considered records.

•      Determines how active documents that will become records should be handled while they are in use, and determines how they should be collected once they are declared to be records.

•      Determines in what manner and for how long each record type should be retained to meet legal, business, or regulatory requirements.

•      Researches and implements technological solutions and business processes to help ensure that the organization complies with its records management obligations in a cost-effective and non-intrusive way.

•      Performs records-related tasks such as disposing of expired records, or locating and protecting records related to external events such as lawsuits.

Determining which documents and other physical or electronic items in your organization are records is the responsibility of corporate compliance officers, records managers, and lawyers. By carefully categorizing all enterprise content in your organization, they can help you ensure that documents are retained for the appropriate period of time. A well-designed records management system helps protect an organization legally, helps the organization demonstrate compliance with regulatory obligations, and increases organizational efficiency by promoting the disposition of out-of-date items that are not records.

A records management system includes the following elements:

•      A content analysis that describes and categorizes content in the enterprise that may become records, provides source locations, and describes how the content will move to the records management application.

•      A file plan describing, for each type of record in the enterprise, where they should be retained as records, the policies that apply to them, how they need to be retained, how they should be disposed of, and who is responsible for managing them.

•      A compliance requirements document defining the rules that the organization's IT systems must adhere to in order to ensure compliance, along with the methods used to ensure the participation of enterprise team members.

•      A method for collecting records that are no longer active from all record sources, such as collaboration servers, file servers, and e-mail systems.

•      A method for auditing records while they are active.

•      A method for capturing records' metadata and audit histories and retaining them.

•      A process for holding records (suspending their disposition) when events such as litigations occur.

•      A system for monitoring and reporting on the handling of records to ensure that employees are filing, accessing, and managing them according to defined policies and processes.

Microsoft Office SharePoint Server 2007 includes features that can help organizations implement integrated records management systems and processes. To ensure that information workers can easily participate in your enterprise's records management system, 2007 Microsoft Office system applications, such as Microsoft Office Outlook 2007 and Microsoft Office Word 2007, also include features that support records management practices.

Overview of records management planning

This topic describes the planning steps you should take to help ensure that the records management system you implement based on Office SharePoint Server 2007 will achieve your organization's records management goals. Here is a preview of the records management planning process:

1.   Identify records management roles   Successful records management requires specialized roles, including:

•      Records managers and compliance officers to categorize the records in the organization and to run the records management process.

•      IT personnel to implement the systems that efficiently support records management.

•      Content managers to identify where organizational information is kept and to commit their teams to following records management practices.

2.   Analyze organizational content   Before creating a file plan, records managers and content managers survey document usage in the organization to determine which documents and other items may become records.

3.   Develop a file plan   After you have analyzed your organizational content and determined retention schedules, fill in the rest of the file plan. File plans differ from organization to organization, but in general they describe the kinds of items the enterprise acknowledges to be records, indicate where they are stored, describe their retention periods, and provide other information such as who is responsible for managing them and what broader category of records they belong to.

4.   Develop retention schedules   For each record type, determine when it is no longer active (in use), how long it should be retained after that, and how it should ultimately be disposed of.

5.   Evaluate and improve document management practices   Make sure that proper policies are being applied in document repositories. For example, ensure that content is being properly audited, so that adequate audits are retained along with records.

6.   Design the records management application   Office SharePoint Server 2007 includes a specialized site template, the Records Repository, which is designed for records management. Based on your file plan, design the site's libraries, content types, policies, and its record series, which defines where in the site record that type should be stored.

7.   Plan how content moves to the Records Center site   If you are using Office SharePoint Server 2007 for both your active document management and your records management application, you can create custom workflows to move documents to the Records Repository at the appropriate times. If you are using either Office SharePoint Server 2007 or external document management systems, you can plan and develop interfaces that move content from those systems to the Records Repository, based on the Records Repository's programmable interface.

8.   Plan Microsoft Exchange integration   Microsoft Exchange Server 2007, along with Office Outlook 2007, includes features designed to facilitate the flow of e-mail into the Records Repository using specialized folders and commands. If you are using Exchange Server 2007 as your e-mail server, you can plan how to classify e-mail and move it to the Records Repository.

9.   Plan compliance reporting and documentation   To verify that your organization is performing its required records management practices and to communicate these practices, you should document your records management plans and processes. If your enterprise becomes engaged in records-related litigation, you may be required to produce these records management guidelines, implementation plans, and metrics on effectiveness.

Download this book

This topic is included in the following downloadable book for easier reading and printing:

•      Records Management Guide for Microsoft Office SharePoint Server 2007 (http://go.microsoft.com/fwlink/?LinkID=92720)

See the full list of available books at Downloadable books for Office SharePoint Server 2007 (http://technet.microsoft.com/en-us/library/cc262788(TechNet.10).aspx).

See Also

Identify records management roles

Develop the file plan

Design the Records Center

Plan how records are collected

Identify records management

Effective records management requires an organization-wide commitment to planning, implementing, overseeing, and participating in the records management program. To achieve this, members of your organization with a range of records management–related roles and skills must support the effort. As you start planning your records management solution, identify who in your organization will fill the following roles:

•      Records managers   Usually members of an organization's legal department. They are skilled in the process of categorizing electronic and physical documents and in deciding which documents should become records. Records managers help determine organizational records management policies and participate in designing the records management solution. They are responsible for researching and writing the file plan and retention schedule, and they participate in writing the compliance requirements document. Records managers also operate the records management system, performing tasks such as putting records on hold during litigation and disposing of records at the end of their retention periods. The participation of records managers is essential to the success of your records management system.

•      Compliance officers   Also members of an organization's legal department. In some organizations, this role is filled by records managers. Compliance officers monitor every aspect of enterprise records management to ensure that the organization is closely following relevant regulations and guidelines. They are primarily responsible for writing the compliance requirements document, which describes the enterprise records management methodology, guidelines, and training plans.

•      IT professionals   Responsible for deploying, operating, and maintaining the computers and applications that implement the records management solution. They ensure that the records management solution is secure, that it is of the proper scale, that it is reliable, and that it communicates with the document management servers and e-mail servers that supply it with records.

•      Site designers   In a records management solution based on Microsoft Office SharePoint Server 2007, they are the experts in creating and configuring Web sites implementing a Records Center site.

•      Content managers   Manage teams that produce documents or that handle physical or electronic files that might be records. Their role is to supply leadership in identifying records, in planning processes for their teams that will ensure good records management practices, and in making sure that the information workers on their teams participate in the organizational records management effort.

•      Information workers   The participants in the records management system. They create or manage the electronic and hard-copy documents, memos, reports, messages, and other content that could be records. The success of your records management solution depends on the quality of participation by the information workers in your organization.

Note:

How you design your records management system can have a big impact on how well information workers comply with it. For example, by creating simple processes for retaining records, you will increase participation because information workers will be less likely to see these tasks as impediments to getting their other work done. Also, effective records management training and documentation will increase information workers' active participation.

Your organization might have already filled all of the roles described in this article. If not, you might want to seek experts in records management and compliance. Professional organizations such as the Association of Records Managers and Administrators can be helpful in locating records management professionals in your area.

The initial tasks of the team designing your records management system include analyzing content usage in your organization, analyzing regulatory and other requirements that will affect records management decisions, evaluating hardware and application resources to use to retain records, and planning the best strategy for ensuring information workers' cooperation in managing records. Because this planning touches on so many disciplines in your organization, form a diverse team to plan your records management solution, including all the roles described above.

Worksheet action

Use the Records management stakeholders and participants worksheet (http://go.microsoft.com/fwlink/?LinkId=73296&clcid=0x409) to record the name, e-mail address, role, and other contact information for each participant you enlist for the records management planning team.

Worksheet

Use the following worksheet to help plan your deployment:

•      Records management stakeholders and participants worksheet (http://go.microsoft.com/fwlink/?LinkId=73296&clcid=0x409)

Download this book

This topic is included in the following downloadable book for easier reading and printing:

•      Records Management Guide for Microsoft Office SharePoint Server 2007 (http://go.microsoft.com/fwlink/?LinkID=92720)

See the full list of available books at Downloadable books for Office SharePoint Server 2007 (http://technet.microsoft.com/en-us/library/cc262788(TechNet.10).aspx).

Develop the file plan

In this article:

•      About records, active documents, and archived documents

•      Determine what is a record

•      Complete the file plan

The file plan is the primary records management planning document. Although file plans can differ across organizations, they typically:

•      Describe the kinds of items the organization acknowledges to be records.

•      Describe what broader category of records the items belong to.

•      Indicate where records are stored.

•      Describe retention periods for records.

•      Delineate who is responsible for managing the various types of records.

About records, active documents, and archived documents

Before you can determine your file plan, you need to understand the differences among records, active documents, and archived documents.

•      Records   These are documents or other physical or electronic entities in an organization that serve as evidence of activities or transactions performed by the organization. They must be retained for some time period so they can be produced if needed, such as for regulatory or legal discovery.

When an active document is declared to be a record, it is moved or copied to a protected place such as a physical vault or an electronic records repository, and it is assigned a retention period that specifies how long the organization will keep it. (Note that the retention period could be permanent, meaning that the record would be retained indefinitely.) When a record's retention period is over, it is either disposed of by a records manager or moved to an archive for safekeeping as a document of historical interest.

•      Active documents   These are documents in use, such as the e-mail messages in an information worker's inbox, the printed product specifications on someone's desk, the documents in a document library, or the pages on a corporate Web site. It is expected that active documents will change over time, be copied and shared, and generally move about the organization.

Active documents may be declared as records if they serve as evidence of an activity or transaction performed by your organization. For example, if your organization provides a service that includes delivering content to a customer, then that content becomes a record of the delivery of the service and a copy of the document should be retained. Some types of active documents will never become records; for example, you might not classify an e-mail sent among coworkers to agree on where to meet for lunch as a record.

At some point in a document's life cycle, it stops being active. For example, when a deliverable document is presented to a customer, it might no longer be necessary to keep managing this content as an active record. But if the document is a record, it should be saved and protected for some retention period.

•      Archived documents   These are documents that are no longer active but are not records (either because they no longer have to be retained or because they were never classified as records). Archived documents are kept by an enterprise for non-legal reasons such as for historical preservation.

Determine what is a record

Determining which active documents in your organization might be declarable as records requires the collaboration of records managers, lawyers, compliance officers, and content managers. Note that, even if your enterprise is not in a highly regulated industry, there are general laws (such as the Sarbanes-Oxley Act of 2002) that your records managers need to be aware of that might obligate your enterprise to retain records. Along with general business laws, you need to evaluate legal requirements specific to your enterprise.

It is beyond the scope of this article to provide more than general information about how to determine what is a record in your organization. Most likely, your enterprise is already doing some form of records management and has filled most of the records management roles you need, and you might already have a taxonomy of records.

Generally, to determine what are records in your organization:

1.   Understand your enterprise's legal obligations and business needs.

2.   In a collaborative effort across the divisions of your organization, analyze active document usage.

3.   Develop a list of active document types that should become records. For example, you may determine that the following should be retained as records:

•      Contracts to rent corporate space.

•      Documents related to employees' benefits.

•      Documents related to product research and development.

4.   Categorize the records.

Worksheet action

This is useful because records in the same category often have the same retention periods and might require equivalent treatment in other ways. You can use the Record categories worksheet (http://go.microsoft.com/fwlink/?LinkID=73300&clcid=0x409) to record the results of your research.

Here is a sample worksheet:

Records

Record category

Description

Sites

Benefit plans, insurance plans, pension plans

Employee Benefit Descriptions

Descriptions of all employee benefit plans.

http://example

Payroll timesheets, supplementary payroll information

Payroll Records

Summaries of hours worked, overtime, and salary paid.

http://example

Vendor invoices

Invoices

Records of goods or services purchased from vendors.

http://example

Product surveys, questionnaires, training manuals, training videos

Training Materials

Provides internal or external training.

http://example

Shipping forms, shipping reports

Shipping Records

Documents the shipment of materials.

http://example

Press releases, newspaper articles

Press Releases

Public relations information about products and services.

http://example

Emergency contact sheets, medical plan enrollment forms, resumes, benefits status reports

Personnel Records

Records of individuals' employment histories and related personnel actions.

http://example

Complete the file plan

After determining which documents should be retained as records and creating a set of record categories, complete your file plan by defining retention periods for each record category, indicating how to dispose of records when their retention periods have expired and supplying other information such as the primary records manager for each record type and the media in which the record is stored.

Here is a completed sample file plan:

Records

Description

Media

Record category

Retention

Disposition

Contact

401k plans

Description of employee benefit plan.

Web pages

Employee Benefit Plans

X years

None

Reshma Patel

Insurance plans

Description of employee insurance plan.

Print

Employee Benefit Plans

X years

None

Reshma Patel

Pension plans

Description of employee pension plan.

Print

Employee Benefit Plans

X years

None

Reshma Patel

Payroll timesheets

Summaries of hours worked, overtime, and salaries paid.

Electronic documents

Payroll Records

X years

Destroy

Reshma Patel

Supplementary payroll information

Summaries of sick time, vacation time, and other non-salary payroll items.

Electronic documents

Payroll Records

X years

Destroy

Reshma Patel

Vendor invoices

Records of goods or services purchased from vendors.

Print

Invoices

X years

Destroy

Eric Lang

Product surveys

Customer satisfaction survey.

Web pages

Survey Materials

X years

Archive

Molly Dempsey

Questionnaires

Questionnaire to determine customer demographics.

Print

Survey Materials

X years

Archive

Molly Dempsey

Training manuals

Hard-copy training content.

Print

Training Materials

X years

Destroy

Molly Dempsey

Training videos

Video training content.

Video

Training Materials

X years

Destroy

Molly Dempsey

Shipping forms

Configure the shipment of materials.

Print

Shipping Materials

X years

Destroy

Eric Lang

Shipping reports

Document the shipment of materials.

Electronic spreadsheets

Shipping Materials

X years

Destroy

Eric Lang

Press releases

Releases about products and services.

Electronic documents

Public Relations Information

X years

Archive

Molly Dempsey

Newspaper articles

News about products and services.

Print

Public Relations Information

X years

Archive

Molly Dempsey

Emergency contact sheets

Employee information.

Electronic documents

Personnel Records

X years

Destroy

Reshma Patel

Medical plan enrollment forms

Employees' sign-up forms for health plans.

Electronic documents

Personnel Records

X years

Destroy

Reshma Patel

Resumes

Resumes received.

Mixed

Personnel Records

X years

Destroy

Reshma Patel

Note:

The above example is a sample and not a recommendation of any particular file plan settings. No retention periods are supplied to reinforce that this is an example and not a recommendation of any records management policy.

Worksheet

You can use the following worksheet with this article to help plan your deployment:

•      Record categories worksheet (http://go.microsoft.com/fwlink/?LinkID=73300&clcid=0x409)

Download this book

This topic is included in the following downloadable book for easier reading and printing:

•      Records Management Guide for Microsoft Office SharePoint Server 2007 (http://go.microsoft.com/fwlink/?LinkID=92720)

See the full list of available books at Downloadable books for Office SharePoint Server 2007 (http://technet.microsoft.com/en-us/library/cc262788(TechNet.10).aspx).

Design the Records Center

In this article:

•      About the Records Center site

•      Planning document libraries for records retention

•      Planning metadata

•      Planning the record routing table

To manage records in Microsoft Office SharePoint Server 2007, site designers and records managers plan and implement a Records Center site. This site, based on the Records Center site template, contains features you can use to implement your file plan and manage the records while they are being retained.

Design the Records Center site in four steps:

1.   Based on your file plan, plan the document libraries you need to store your records.

2.   Plan metadata for each record type, and define columns in the document libraries to contain and display the metadata.

3.   For each type of record, plan policies to define retention periods and auditing specifications that help meet your enterprise's regulatory obligations.

4.   Based on your analysis of active content that will become records, plan the record routing table, which maps each type of record to the appropriate library in the Records Center site. When a record is sent to the Records Center site, either programmatically or via the user interface, this table is used to determine how to classify the document within the file plan.

About the Records Center site

The Office SharePoint Server 2007 Records Center site template is designed to implement records management and retention.

By combining standard Office SharePoint Server 2007 features with specialized records management features, the Records Center site provides the following capabilities:

•      Record routing   When a document is sent to the Records Center site, either by using a default method such as the Send to Records Center command or by using the programmable interface, the record is routed to the correct document library based on its type. The correlation between incoming record types and their related document libraries is managed in the record routing table, as described later in this article in the section Planning the record routing table.

When a record is sent to the Records Center site, other information is sent along with the record itself. This other information includes the record's audit history, which is stored in an XML file, and all of its metadata, which is stored both in an XML file and in columns of metadata in the Records Center site.

•      Policy enforcement   Office SharePoint Server 2007 includes the following policy features that are useful for records management:

•      Auditing   Logs events and operations performed on documents. In the context of records management, this is useful to record who is viewing and accessing information in the Records Center site.

•      Expiration   Specifies how long the record should be retained and provides an action to take when the retention period ends, such as initiating a disposition approval workflow. In the context of records management, the retention period usually starts when the record is stored in the Records Center site.

•      Barcodes   Provides each record with a unique barcode graphic and numeric value. The value of the barcode is stored and indexed along with the electronic version of the record. In the context of records management, barcodes are useful for retaining and tracking physical records. When the records in a library have hard-copy versions, barcodes provide a way to correlate the hard-copy versions with their electronic counterparts. See the topic Plan physical records retention for a discussion of physical records retention planning.

•      Programmable interface   A comprehensive records management solution enables records to flow into the records management system from all sources of records in the organization. The Records Center site's programmable interface provides a method to send a file, its associated metadata, and its audit history to the Records Center site as part of a business process. By using this method, any document management system can be configured to send files to the Records Center site. You can also add modules that extend the classification of incoming records — for example, to classify records based on their metadata values.

In addition to extending the interface for moving records into the Records Center site, you can extend other aspects of the Records Center site. For example, you can design additional policy features that meet your enterprise's unique requirements.

•      Hold   The Office SharePoint Server 2007 Records Center site provides a way to suspend a record's expiration policy. It includes a hold feature that lets records managers create named "holds" that protect specified records from expiring and being destroyed. For example, in the event of an internal audit or a litigation, putting the relevant records on hold ensures that those records, which you may be required to produce, will be available until the audit or litigation is complete.

Planning document libraries for records retention

The easiest approach to planning document libraries for records retention — and the approach recommended in this planning guide — is to create a document library for each type of record in your file plan (see Develop the file plan). For example, each record in the following sample file plan could be stored in a separate library:

Records

Description

Media

Record category

Retention

Disposition

Contact

401K plan

Description of employee benefit plan.

Web pages

Employee Benefit Plans

X years

None

Reshma Patel

Insurance plan

Description of employee insurance plan.

Electronic documents

Employee Benefit Plans

X years

None

Reshma Patel

Press releases

Releases about products and services.

Electronic documents

Public Relations Information

X years

Archive

Molly Dempsey

Newspaper articles

News about products and services.

Print

Public Relations Information

X years

Archive

Molly Dempsey

Worksheet action

To help you plan document libraries for records retention, list each record type and assign it to a document library. To record information about the library, such as what policies to apply and what columns of metadata to add to it, use the Document library for retaining records worksheet (http://go.microsoft.com/fwlink/?LinkId=73298&clcid=0x409) for each library.

Planning metadata

After planning document libraries for records retention, the next step is to determine the metadata to define for each library. There are two categories of metadata to consider:

•      Records metadata

•      Additional metadata

Planning records metadata

Records metadata is the metadata that is submitted along with a record when it is sent to the Records Center site. Determining what the optimal metadata for a type of record is depends on that type of record, and it may require discussions among records managers and the managers of the content on the active servers. Once you have determined that adequate metadata is being generated and stored for a record type, you can configure the destination document library for that type of record to retain the metadata along with the record. When a record is sent to the destination document library:

•      The names and values of each column of metadata associated with it are saved along with the record in an XML file in a hidden _properties folder that is created in the destination library.

•      The metadata values are copied to matching columns in the destination library.

For each column of metadata for a type of record, define a column in the destination document library that matches the incoming column's name and type. To specify that the column must be submitted along with the record and that it must have a data value associated with it, configure the column in the Office SharePoint Server 2007 user interface to require data. (Do this by selecting the Require that this column contains information option.) For example, if the source records include a "Department" column of type "Single Line of Text," define a column with that name and type in the destination document library.

Note:

If a record is submitted for retention and required metadata is missing (either because no value is supplied or because the column is missing entirely), the submitter will be prompted for the missing metadata. If the metadata is not provided, the record will not be accepted for retention. If the document is sent programmatically (rather than from the user interface), the file is placed in a temporary holding area, and information is sent back to the calling program that must be handled programmatically to supply the missing column of information before the record is added to the destination library.

Worksheet action

In the Document library for retaining records worksheet (http://go.microsoft.com/fwlink/?LinkId=73298&clcid=0x409), record the name and type of each column of records metadata that you want to store along with the record, and specify if the column should be required.

Planning additional metadata

Along with displaying columns of metadata associated with retained records, you may want to add other columns of information to display in your records management document libraries. For example, you may want to add a "Records Manager" column to display the name of the person on your team who is responsible for managing the records stored in the document library. Note that, as with columns submitted along with records, if you specify that these additional columns are required, the record submitter will be prompted for the missing metadata and the record will not be accepted unless that metadata is supplied. If you do not want the submitter to be prompted for the values of additional metadata, do not configure the columns to require data.

Note:

You can define columns for use in multiple document libraries. To do this, you can create them in the Column Templates gallery associated with the Records Center site.

Worksheet action

In the Document library for retaining records worksheet (http://go.microsoft.com/fwlink/?LinkId=73298&clcid=0x409), record the name and type of each column of additional metadata that you want to store along with the record, and specify if the column should be required.

Planning policies

An information management policy is a set of rules for a type of content. Each rule in a policy is a "policy feature." For example, an information management policy feature could specify how long a type of content should be retained or which actions on the content should be audited. Information management policies enable you to control who can access your organizational information, what they can do with it, and how long to retain it. Policies in a records management system should be configured by records managers to reflect the enterprise's regulatory obligations.

Microsoft Office SharePoint Server 2007 includes the following policy features that are useful for managing records in the Records Center site:

•      Auditing, to demonstrate that records are being managed properly.

•      Expiration, to control how long records are retained in the Records Center site.

•      Barcodes, to track physical records.

Depending on your records management needs, you can also acquire or develop your own records management–related policy features that are not included in Office SharePoint Server 2007, such as policies that digitally sign records or convert them to a fixed format.

There are two recommended options for planning policies for records management:

•      If the same policies will apply to multiple record types — for example, because they are in the same record category — create a separate site collection policy for each set of record types. Associate each site collection policy with the relevant document libraries.

Worksheet action

•      In the topic Develop the file plan, you determined record categories using the Record Categories worksheet (http://go.microsoft.com/fwlink/?LinkId=73300&clcid=0x409). For each record category that requires a policy, create and configure the policy in the Site Collection Policy gallery by adding policy features and configuring them. (For more general information about policies and policy planning, including links to policy planning worksheets, see the topic Plan information management policies.

•      If a record type requires a unique set of policy settings, associate the relevant policy features directly in the document library for that record type and configure the policy features appropriately for that library.

Worksheet action

In the Document library for retaining records worksheet (http://go.microsoft.com/fwlink/?LinkId=73298&clcid=0x409) for a library, record your decisions about policy configuration:

•      To associate a site collection policy with the document library based on the record category of the content stored in the document library, in the Policy section of the worksheet, record the name of the policy template for that record category.

•      To associate unique policy features directly with the document library, in the Policy section of the worksheet, enter each policy feature along with configuration notes for that feature.

Planning the record routing table

The record routing table is a list in the Records Center site that lists each type of record that might be submitted to the Records Center site and specifies the library in which to store it. When files are submitted to the Records Center site by using the Send to Records Center command or the programmable interface, this list is used to route the incoming file to its proper location.

Each entry in the record routing table is a record series list item specifying:

•      The title and description of the record series. The name of a record series indicates a type of item that can be submitted to the Records Center site for the current record series. If files are submitted to the Records Center site from a server based on Office SharePoint Server 2007 or Windows SharePoint Services 3.0, the name should match a content type name in the library containing the active record. If the files are submitted from another source, the name should match the type of document that can be submitted from that file source using the programmable interface.

•      The location (a document library) in which to save the records for the current record series.

•      A list of record types, called aliases. These are other names for the records that can be submitted to the Records Center site for this record series. For example, if your organization has multiple departments that use different names for the same underlying record type (such as "contracts" and "agreements"), you could define aliases for each name used for the same record type.

If the records are submitted to the Records Center site from a server based on Office SharePoint Server 2007 or Windows SharePoint Services 3.0, the aliases will be content types. If the records are coming from another file source, the aliases should match the types that can be specified for that record source in the programmable interface.

One record series in the record routing table should specify the default document library. When a Records Center site receives a file that does not match an alias in the record routing list, the file is moved to the specified default location where it can be manually filed by a records manager. The Records Center site template includes an Unclassified Records document library and record series as the initial default location; it is recommended that you keep this record series as the default.

A good approach to planning your record routing table is:

1.   For each document library that you created in your Records Center site, plan to create an entry in the record routing table.

2.   Give a record series the same title as the primary type of record to be retained using that record series.

3.   Based on your analysis of active documents in your enterprise, obtain a list of all the content types or other record types that could be submitted for the current record series; these should be listed in your file plan, and they will be the aliases for the record series. For example, if, in a human resources Records Center site, you decide to retain all pension plans, insurance plans, and 401k plans in an Employee Benefits Plans document library, you would specify all these record types as aliases in the record series entry for the Employee Benefits Plans document library.

4.   Determine which record series should be the default.

Worksheet action

Use the Records routing table worksheet (http://go.microsoft.com/fwlink/?LinkId=73303&clcid=0x409) to record your decisions about each record series you plan to create in the record routing table. Note that there should be a record series for each document library in your Records Center site.

Worksheets

Use the following worksheets with this article to help plan your deployment:

•      Document library for retaining records worksheet (http://go.microsoft.com/fwlink/?LinkId=73298&clcid=0x409)

•      Record categories worksheet (http://go.microsoft.com/fwlink/?LinkId=73300&clcid=0x409)

•      Records routing table worksheet (http://go.microsoft.com/fwlink/?LinkId=73303&clcid=0x409)

Download this book

This topic is included in the following downloadable book for easier reading and printing:

•      Records Management Guide for Microsoft Office SharePoint Server 2007 (http://go.microsoft.com/fwlink/?LinkID=92720)

See the full list of available books at Downloadable books for Office SharePoint Server 2007 (http://technet.microsoft.com/en-us/library/cc262788(TechNet.10).aspx).

See Also

Design Records Center architecture (http://technet.microsoft.com/en-us/library/cc263486.aspx)

Plan how records are collected

In this article:

•      Techniques for moving files into the Records Center site

•      Completing your plan

After you develop a file plan and design the Records Center site, plan how active electronic and hard-copy documents in your organization will move to the Records Center site. This article reviews techniques you can use to move content to the Records Center site and suggests a way to plan how items in your file plan will become records.

Techniques for moving files into the Records Center site

You can use the following techniques for moving files into the Records Center site:

•      Manually sending content from a Web site based on Microsoft Office SharePoint Server 2007.

•      Using managed e-mail folders in Microsoft Exchange Server 2007.

•      Using a custom solution based on the Windows SharePoint Services 3.0 object model, such as a custom workflow.

Manually sending content to the Records Center site

If a file is stored in a document library in a Web site based on Office SharePoint Server 2007, an information worker can declare it a record by sending a copy of it to the Records Center site using the Send to Records Center command. When a site collection administrator configures the connection to the Records Center site, this command becomes available on all active documents in the site collection. Along with sending a copy of the document to the Records Center site, the Send to Records Center command sends the document's metadata, its audit history, and its location on the active document server. If additional metadata is required in the Records Center site, the user is prompted to supply it. Although manually sending records to the Records Center site is not a practical large-scale solution, you can use it to supplement other methods of moving content to the Records Center site.

Note:

When the Send to Records Center command is used to declare a record and send it to the Records Center site, it leaves the active document in its current location. The active document can continue to be used, or it can be deleted if that is appropriate.

Using managed e-mail folders in Microsoft Exchange Server 2007 to send e-mail and files to the Records Center site

Exchange Server 2007 includes policy features similar to those implemented using Office SharePoint Server 2007. In Exchange Server 2007, administrators can configure an Exchange folder so that, when a user moves an e-mail message into the folder, the e-mail message is copied to the Records Center site using Simple Mail Transfer Protocol (SMTP).

When an e-mail message copied from Office SharePoint Server 2007 is received in the Records Center site, it is handled like any other file sent to the Records Center site; it is moved to the appropriate document library based on the matching entry in the record routing table. For more information about the record routing table, see Design the Records Center.

The policy and records retention features described above are managed e-mail folders features introduced in Exchange Server 2007. Using managed e-mail folders, Exchange administrators can define folders that are targeted to specific business purposes, such as Personnel Issues, Product Planning, or Contracts. By assigning policies to these managed folders, administrators can ensure proper expiration of content, configure connections to other servers (such as a Records Center site in Office SharePoint Server 2007), or initiate any custom actions that have been configured in Exchange Server 2007. The use of managed e-mail folders can be enforced by rules (such as moving messages into folders based on their subject lines), or the use of the folders can be voluntary, requiring information workers to manually move e-mail into appropriate folders. For a full description of implementing managed e-mail folders and other Exchange Server 2007 features, see the Exchange Server 2007 Administrator's Guide.

Using a custom solution to send files to the Records Center site

You can programmatically send files and e-mail messages to the Records Center site from file and e-mail servers, whether or not they are based on Office SharePoint Server 2007 or Exchange Server 2007. To do this, develop and install programs that have interfaces to the records management methods implemented in the Windows SharePoint Services 3.0 object model and then integrate those programs into your document or e-mail management processes.

By using the Windows SharePoint Services 3.0 object model, you can determine the list of record types defined in a Records Center site's record routing table, and then submit a file — including its contents, properties, and audit history — to a particular record series. For a full description of programming the Windows SharePoint Services 3.0 object model, see the Office SharePoint Server 2007 Software Development Kit (http://go.microsoft.com/fwlink/?LinkId=71218&clcid=0x409).

You can use the Windows SharePoint Services 3.0 object model to create a custom workflow that copies files to the Records Center site. A workflow that sends files to the Records Center site can be integrated into your document management system as part of a workflow that guides a document through its life cycle. For document types that have a predictable life cycle, such as expense reports, you could implement a workflow that guides the document through its various stages and, as a final step, sends a copy of the document to the Records Center site. The workflow could be triggered by the creation of a new document.

Completing your plan

After you Develop the file plan and review the methods for moving content into the Records Center site, complete your plan by determining how to send each type of record to the Records Center site. The factors to consider include the following:

•      Is compliance enforced or voluntary?

•      Can you count on the cooperation of information workers in your organization to comply with records management processes? In general, avoid manual processes; however, where they are needed, devise adequate training and monitoring to ensure team compliance.

•      Will content be stored on Office SharePoint Server 2007 document management servers?

•      Will e-mail be stored on Exchange Server 2007 e-mail servers? If e-mail is stored on Exchange Server 2007 e-mail servers, you can use built-in mechanisms such as managed e-mail folders to implement the connection to the Records Center site. If e-mail is stored on other e-mail servers, you can use the Windows SharePoint Services 3.0 object model to design and implement custom methods for sending files to the Records Center site.

•      Are you retaining physical content? Managing active physical content, such as hard-copy documents or CD-ROMs, and sending it to a records vault for retention (along with tracking the record in a Records Center site) requires unique planning not described in this topic. For example, if no electronic version of a hard-copy document exists, you might need to track the item by using a list and its associated policies and workflows. For a full discussion of strategies and techniques for tracking a physical record, both while it is active and after it is sent to the Records Center site, see the topic Plan physical records retention.

The following table illustrates how some records in a file plan will move to a records repository site:

Documents

Description

Media

Source location

Becomes a record...

Benefit plan

Description of employee benefit plan.

Web pages

Office SharePoint Server 2007 document library

Using a custom workflow associated with expiration policy

Insurance plan

Description of employee insurance plan.

Print

Physical document associated with list item in Office SharePoint Server 2007

By sending to a physical vault and creating a list item in the Records Center site to track (using a barcode)

Payroll timesheets

Summaries of hours worked, overtime, and salaries paid.

Electronic documents

Payroll records server not based on Office SharePoint Server 2007

Using a custom program

Product development files

Specifications of products and associated documents.

Electronic documents

Office SharePoint Server 2007 document library

Using custom workflow associated with expiration policy and manually using Send To Records Center command

Product development e-mail

E-mail messages related to product development.

E-mail

Exchange Server 2007 managed folders

Manually by moving messages to an Exchange folder connected to the Records Center site

Download this book

This topic is included in the following downloadable book for easier reading and printing:

•      Records Management Guide for Microsoft Office SharePoint Server 2007 (http://go.microsoft.com/fwlink/?LinkID=92720)

See the full list of available books at Downloadable books for Office SharePoint Server 2007 (http://technet.microsoft.com/en-us/library/cc262788(TechNet.10).aspx).

Plan physical records retention

In this article:

•      Using Office SharePoint Server to manage physical records

•      Planning physical records retention

•      Worksheet

This article describes planning tasks related to retaining physical records by using Microsoft Office SharePoint Server 2007. As with digital items, such as electronic documents and e-mail messages, a physical item can be a record and can require management. By using Office SharePoint Server 2007 in conjunction with your physical records storage and retrieval system, you can implement a records management solution that includes both electronic and physical records.

Physical records that you manage by using Office SharePoint Server 2007 can include any non-digital items, such as printed documents, DVDs, videotapes, other media, and even hardware such as product prototypes. You can manage individual physical items or a set of items, such as a box of related documents.

Note:

A well-designed records management system helps protect an organization legally, helps the organization demonstrate compliance with regulatory obligations, and increases organizational efficiency by promoting the disposition of out-of-date electronic and physical items that are not records. Determining which electronic or physical items in your organization are records is the responsibility of corporate records managers, compliance officers, and lawyers. By carefully categorizing all enterprise content in your organization, they can help you ensure that records are retained for the appropriate period of time.

Using Office SharePoint Server to manage physical records

This section describes Office SharePoint Server 2007 features that you will want to consider in planning a records management solution that supports physical records retention and disposition.

Physical records and the Records Center site

The Office SharePoint Server 2007 Records Center is a site template designed to implement records management and retention. It includes records management features, such as policy enforcement, record hold, and record routing, and it has a fully programmable interface. For a full overview of the Records Center site, see Design the Records Center.

The Records Center site is designed for managing electronic and physical records. This facilitates treating both types of records as part of the same file plan, applying the same types of metadata to both electronic and physical records, and associating the same policies with them where appropriate. You can either manage electronic and physical records in the same Records Center site or you can use one Records Center site for electronic records and another for physical records.

When planning physical records management in a Records Center site, here are some unique considerations to keep in mind:

•      Use lists rather than document libraries to track physical records. See  for details.

•      Because the actual storage of a physical item happens separately, users do not "send" a physical item to a Records Center site by using the user interface (or by using a customization based on the programmable interface). Instead, records managers add new physical records to the site by creating new items in the lists used to manage the records, and by creating associated features (see next item) to manage the physical records by using the Office SharePoint Server 2007 lists. Typically new list items are added to lists programmatically, such as by using a custom workflow.

Note:

There is no need to add physical records to the Record Routing table in the Records Center site, which sends electronic records to their appropriate document libraries but does not route physical records.

•      It is recommended that additional functionality, such as custom workflows, be added to lists to provide physical record-specific processes, such as inventory tracking, storage management, ownership transference, and physical records disposition. For a case study including descriptions of Records Center customizations that support physical records management, see .

Lists and physical records

In contrast to electronic records such as documents, which are both stored and managed in Office SharePoint Server 2007 document libraries, physical records are stored in an appropriate physical venue, depending on the type of item. To track physical records' locations, owners, status, and other information, and to guide them through their lifecycles, use Office SharePoint Server 2007 lists rather than document libraries in the Records Center site. After an item representing a physical record is added to a list, you can manage it by using the same records management features that document libraries provide for digital records:

•      Metadata   Metadata in Office SharePoint Server 2007 is implemented as columns of information displayable in lists or document libraries. Records managers use metadata to record information about records, such as their descriptions, the types of media, record category, each item's disposition, barcode value, and record owner. By using the Site Column Gallery in the Records Center site, you can define metadata columns that are useful for both your electronic and physical records. This helps you to maintain the same information about records regardless of their media, and makes it easier to search and retrieve both electronic and physical items by using list and library items' properties. For more information about site columns and metadata, see Plan content types.

•      Workflows   You can associate a workflow with a list. Physical items represented in the list can then be tracked by using the workflow. For example, when a new item is added to a list, a custom workflow can be launched that assigns tasks to ensure the proper physical storage of the item. Other workflows can be added to the list — for example, to retrieve a physical item. For information about creating custom workflows, see the Office SharePoint Server 2007 Software Development Kit (http://go.microsoft.com/fwlink/?LinkId=71218&clcid=0x409).

•      Forms   You can use InfoPath Forms Services integration with Office SharePoint Server 2007 to associate forms with lists, and use them to implement commands associated with physical records management. For example, you can use browser-based forms to provide access to physical records inventories or to facilitate service requests related to physical records. For information about planning forms, see Plan InfoPath Forms Services.

•      Information management policies   An information management policy is a set of rules for a type of content. Each rule in an information management policy is a policy feature. Policies and policy features can be applied to list items and used in the context of physical records management:

•      Expiration   The expiration policy feature helps dispose of items in a consistent way that can be tracked and managed. You can set list items to expire on a particular date or within a calculated amount of time. You can associate a workflow with a list's expiration policy so that, when an item expires, the workflow assigns tasks that ensure the item's destruction or other disposition. For more information about the expiration policy feature, see Plan information management policies.

•      Barcodes   The barcode policy feature enables you to track a physical item by creating a unique identifier value for the item and attaching a barcode image of that value to the item. By default, Office SharePoint Server 2007 barcodes are compliant with the common Code 39 standard (ANSI/AIM BC1-1995, Code 39), and you can plug in other barcode providers by using the policies object model. By associating a barcode value with a list item that represents a physical record, you ensure that the physical item can be located from the list item and vice versa. For more information about the barcode policy feature, see Plan information management policies.

•      Labels   The label policy feature specifies labels that Office SharePoint Server 2007 can generate, based on a set of list or document library metadata. You can customize a label's format, and you can insert labels into electronic documents or print them. In physical records management, attach printed labels to physical items to help identify the physical records and correlate them with their associated list items.  For more information about the label policy feature, see Plan information management policies.

•      Auditing   The auditing policy feature logs events and operations performed on a document or list item, such as changing, viewing, or deleting the item. The actions that are audited are extensible. In the context of records management, auditing is an essential operation that helps ensure a complete record of the activities related to an item. For more information about the auditing policy feature, see Plan information management policies.

•      Content types   A content type defines the information and features available for a list item, document, or folder, including its metadata, workflows, and information management policies. Because content types can be organized hierarchically, a set of content types can have some features in common, such as shared metadata, while having unique features.

Content types are useful in records management because they can group features for records of a particular type in an easily reusable way. You can create content types for your electronic and physical records that share common information, such as metadata to categorize the records, while having unique features based on their media. For example, you can define a general "document record" content type, and then create electronic and physical document content types that inherit their metadata from the general content type. Then you can add unique features to the physical document content type that are not relevant to the electronic document content type, such as a barcode policy feature or a physical records workflow. For more information about content types, see Plan content types.

•      Folders   You can define custom folder content types. In physical records management, you can use folders to represent physical storage locations, such as boxes or shelves in a warehouse. List items in the folders then represent items in the physical storage locations. For example, if a set of printed documents is stored in a box, you can store the records of each document in a folder that represents the box, with metadata that identifies the box's barcode value, physical location, and other custom information. For more information about folders and content types, see Plan content types.

•      Attachments   You can attach electronic items, such as scanned images, to list items. This is useful in a physical records management context to help identify a physical record and correlate it with its associated list item.

Case study: Physical records management at Microsoft

The Microsoft Legal and Corporate Affairs (LCA) Records Management team created an inventory tracking solution by using many of the features described in this topic, including the Records Center site, forms, workflows, and information management polices. It gives Microsoft employees easy access to physical records information and eliminates the need to handle inventory searches manually. Building on Office SharePoint Server 2007 and Microsoft Office InfoPath 2007, the solution uses forms and workflows to automate the collection and management of physical records.

A white paper is available online that describes the goals and benefits of the solution along with its architecture. See Streamlining Records Management Using SharePoint Server 2007 Workflow (http://go.microsoft.com/fwlink/?LinkId=80869&clcid=0x409).

Planning physical records retention

Worksheet action

You can use the Plan physical records worksheet (http://go.microsoft.com/fwlink/?LinkId=81626&clcid=0x409) with this article to help plan your physical records management based on Office SharePoint Server 2007.

For each physical record type in your file plan, use a separate worksheet.

1.   Under Physical Record, enter the type of record, such as "Retirement Plan Description."

2.   Under Record Category, enter the category based on your file plan, such as "Human Resources Benefits Plans."

3.   Under Media, enter the type of media, such as "Print Brochure."

4.   Under Records Center, enter the URL of the Records Center site.

5.   Under List, enter the name of the list for managing this type of physical record.

6.   In the Metadata table, enter metadata columns to display for this record type. For each item of metadata, enter its type, such as Person. In the Source column, specify where the item of metadata is defined, such as "Site Column Gallery" or "Current List."

7.   In the Policies table, record the policy template to associate with this list, or record each policy feature individually and supply configuration notes as needed. For more information about information management policies, see Plan information management policies.

8.   In the Workflows table, record each workflow to make available for this record type, list the content type the workflow will operate on, and add any relevant notes, such as a description of the intended use of the workflow and who is responsible for developing it.

9.   In the Forms table, record any forms development required for this record type and add relevant notes, such as a description of the intended use of the form and who is responsible for developing it.

Worksheet

Plan physical records worksheet (http://go.microsoft.com/fwlink/?LinkId=81626&clcid=0x409)

Download this book

This topic is included in the following downloadable book for easier reading and printing:

•      Records Management Guide for Microsoft Office SharePoint Server 2007 (http://go.microsoft.com/fwlink/?LinkID=92720)

See the full list of available books at Downloadable books for Office SharePoint Server 2007 (http://technet.microsoft.com/en-us/library/cc262788(TechNet.10).aspx).

See Also

Design the Records Center

Plan e-mail message records retention

In this article:

•      Using a Records Center site for e-mail message retention

•      Using Exchange Server 2007 with Office SharePoint Server to manage e-mail message records

•      Managing e-mail message records without Exchange Server 2007

•      Planning e-mail message records retention

•      Worksheets

E-mail messages stored in e-mail servers can be records. Because information workers increasingly use e-mail client applications to communicate business information, corporate compliance officers and records managers should include e-mail messages in their records management planning by:

•      Accounting for e-mail messages in file plans.

•      Providing a way to retain e-mail message records, hold them for legal discovery, and dispose of them.

•      Providing a way for information workers to classify their e-mail messages as records.

•      Providing a way for information workers to transfer e-mail messages to records centers.

This article describes planning tasks related to retaining messages by using Microsoft Office SharePoint Server 2007. In addition to Office SharePoint Server 2007, Microsoft Exchange 2007 includes features that support the goals of records managers and corporate compliance officers. Because the Exchange 2007 features that support records management were designed to easily integrate with Office SharePoint Server 2007 records management features, you can use the two products in a seamless way to manage message classification, retention, and expiration. Therefore, this topic focuses on planning e-mail message records management by using Office SharePoint Server 2007 with Exchange 2007. By using a custom solution based on the Windows SharePoint Services 3.0 and Office SharePoint Server 2007 object models, e-mail message records management solutions that don't require Exchange 2007 can be implemented based on Office SharePoint Server 2007. The section Managing e-mail records without Exchange Server 2007 describes planning e-mail records retention when Exchange 2007 is not in use.

For an overview of Office SharePoint Server 2007 records management capabilities, see Plan records management. For information about planning, deploying, and operating a messaging system based on Exchange 2007, see the Microsoft Exchange Server 2007 technical library (http://go.microsoft.com/fwlink/?LinkId=83249&clcid=0x409).

Using a Records Center site for e-mail message retention

As described in the article Design the Records Center, site designers and records managers plan and implement a Records Center site to manage records in Microsoft Office SharePoint Server 2007. The following features of the Records Center site, which are the primary features used to manage records, work for retaining e-mail messages records in the same way as they work for retaining other types of records:

•      Document libraries   You create document libraries in the Records Center site to store records. You can create new libraries for retaining e-mail records or you can store e-mail records in existing libraries. For example, if your Records Center site has a "Contracts" document library, you can store e-mail messages related to contracts in that library with other types of contract-related documents.

•      Metadata   You define and create e-mail message metadata in the same way that you create other types of metadata in the Records Center site. E-mail message record metadata typically includes common e-mail fields such as To, From, and Subject. These fields are automatically submitted to the Records Center along with e-mail message records sent from Office Outlook 2007 and Exchange 2007. For more information, see Using Exchange Server 2007 with Office SharePoint Server to manage e-mail message records later in this article.

To store the metadata for e-mail message records, you must first (as with any type of record metadata) define the metadata columns in a document library or in the content type assigned to the document library. For detailed information about planning metadata for records management, see the section, "Planning metadata," in the article Design the Records Center.

•      Record routing   When an e-mail message is sent to the Records Center site, the record is routed to the correct document library based on the content type associated with the message. The e-mail content type information is automatically submitted with e-mail message records sent from Office Outlook 2007 and Exchange 2007 using the Exchange 2007 label feature. For more information, see Using Exchange Server 2007 with Office SharePoint Server to manage e-mail message records later in this article. For custom e-mail message record solutions that do not use Exchange 2007, the content type must be determined by the custom solution and sent programmatically to the Records Center site. For more information, see the Office SharePoint Server 2007 Software Development Kit (http://go.microsoft.com/fwlink/?LinkId=71218&clcid=0x409).

•      Policies   As is the case for other types of records, e-mail message records require auditing and expiration policies. After a message record has been sent to a Records Center site and routed to a document library, the set of information management policies configured in that document library are applied to the message records stored in that library. For more information about planning policies for records management, see the section, "Planning policies," in Design the Records Center.

•      Hold   The Office SharePoint Server 2007 Records Center site includes a hold feature. In records management, a hold is an action suspending a document’s disposition so that it remains protected in the Records Center until the hold is lifted. This feature enables records managers to create named holds that protect specified records from expiring and being destroyed. You can put one or more message records on hold in the same way that you put other records on hold.

Using Exchange Server 2007 with Office SharePoint Server to manage e-mail message records

Exchange 2007 includes features that facilitate managing e-mail message records and that can easily be integrated into a records management solution based on Office SharePoint Server 2007. These features help ensure that:

•      Information workers can properly classify their e-mail messages.

•      After e-mail messages are classified, they remain active for a duration set by an Exchange 2007 administrator.

•      E-mail messages that must be retained beyond their active retention periods are sent to a Records Center site for long-term retention.

The Exchange 2007 records management features include:

•      Managed folders   These are folders that are configured by a Exchange 2007 administrator so that information management policies are applied to the messages stored in the folders. A typical type of policy applied to a managed folder is an expiration policy, which specifies how long a message can be kept in a folder before it is deleted or moved to another folder for review. When used in an e-mail client application such as Office Outlook 2007, managed folders have the same features as other folders. When a managed folder is selected in Office Outlook 2007, a statement describing the policies associated with the folder is displayed.

Managed folders are typically named to indicate the business classification of the e-mail messages that they are intended to contain. For example, you can name a managed folder "Research and Development" or "Contracts and Leases." Based on a managed folder's name and policy statement, information workers are expected to understand the purpose of the folder and use familiar means such as dragging and dropping to store appropriate e-mail messages in the folder. Note that when an information worker drags an e-mail message into a managed folder, that action both classifies the message and applies the proper policies to it.

•      Journaling   The Exchange 2007 journaling feature sends a copy of an e-mail message to a target storage location outside of a mailbox. By configuring the journaling target location to be a Records Center site, an Exchange 2007 administrator can implement e-mail message record retention using Exchange 2007 and Office SharePoint Server 2007.

You can configure a managed folder to be journaled by specifying a journaling target location (such as an Office SharePoint Server 2007 Records Center site) and a label that indicates the type of e-mail message that the folder contains (such as "product development" or "business critical"). When an information worker moves an e-mail message into a managed folder that has journaling enabled, a copy of the message, the message's label, metadata, and attachments are sent to the target location.

The label associated with a managed folder is used by the Records Center site to route a journaled e-mail message to its correct document library for long-term retention. The label must match the name of a record series in the Record Routing list. (Alternatively, the label can match an alias for the record series.) This is similar to how content types are used in the Record Routing list to determine the correct document library when a document is submitted to a Records Center. For a full description of record routing and record series, see the section, "Planning the record routing table," in the article Design the Records Center.

•      Metadata   When an e-mail message is sent to a Records Center site by the Exchange 2007 journaling feature, the following metadata values are sent with the message:

•      To

•      From

•      Subject

•      CC

•      BCC

When an e-mail message record is sent to a destination document library, the names and values of each column of metadata associated with it are saved in an XML file in a "_properties" folder that is created in the library, and the metadata values are also copied to matching columns in the destination library. You must ensure that document libraries designed for retaining e-mail messages include the needed columns for storing the metadata values that are sent with the messages.

If a column for storing metadata in a document library is configured to require information and an e-mail message sent to the library is missing a required value, the submitter is not immediately prompted for it. (This behavior differs from what occurs when a document is submitted.) Instead, Office SharePoint Server 2007 saves the submitted message in a holding library. After a specified period of time — configurable by the Exchange 2007 administrator — Office SharePoint Server 2007 sends the submitter an e-mail message with a link to a Web page in which the submitter can specify the missing metadata values for all pending messages.

For information about planning and configuring Exchange 2007 records management features, see Managing Messaging Records Management (http://go.microsoft.com/fwlink/?LinkId=83452&clcid=0x409).

Managing e-mail message records without Exchange Server 2007

By using a custom solution based on the Windows SharePoint Services 3.0 and Office SharePoint Server 2007 object models, you can create a solution for records management for e-mail messages that is based on Office SharePoint Server 2007 that does not require Exchange 2007. When you implement message records retention in this way, you must develop programs that have interfaces to the records management methods implemented in the Windows SharePoint Services 3.0 object model, and then integrate those programs into your e-mail management processes. For a full description of programming the Office SharePoint Server 2007 object model, see the Office SharePoint Server 2007 Software Development Kit (http://go.microsoft.com/fwlink/?LinkId=71218&clcid=0x409).

Planning e-mail message records retention without Exchange 2007 is identical to planning retention of other types of records. For general guidance on planning e-mail records management solutions in this way, see Plan records management.

Planning e-mail message records retention

This section describes recommended steps for planning e-mail message records retention if you are using both Office SharePoint Server 2007 and Exchange 2007. If you are not using Exchange 2007, the steps for planning message records retention are similar to the steps for planning other types of records retention. For information, see the following resources:

•      Develop the file plan

•      Design the Records Center

•      Plan how records are collected

The following steps describe planning e-mail message records retention using both Office SharePoint Server 2007 and Exchange 2007. These steps guide you in planning a separate document library for storing the contents of each managed folder, which is the easiest way to plan document libraries for e-mail message records retention.

1.   In the Managed folders worksheet (http://go.microsoft.com/fwlink/?LinkId=84737&clcid=0x409), record the name of each managed folder on a separate line. Then, for each managed folder, record the following information:

a.   In the Folder name column, type the name of the label to be used in journaling the messages.

b.   In the Label column, specify the label that indicates the type of e-mail message that the folder contains.

c.   In the Metadata fields column, list the names of metadata fields that will be submitted to the Records Center site.

d.   In the Notes column, supply additional notes such as the retention policy and other policies applied to this managed folder.

2.   Ensure that e-mail message records are part of your file plan.

a.   Review the topic Develop the file plan.

b.   In the Record categories worksheet (http://go.microsoft.com/fwlink/?LinkID=73300&clcid=0x409), add each type of message to the Records column, and provide a category and description for the message record. For example, if weekly status reports are sent as e-mail messages, you could add "Status e-mail message" to the Records column and categorize them as Personnel Records.

3.   For each managed folder, fill in a Document library for retaining records worksheet (http://go.microsoft.com/fwlink/?LinkId=73298&clcid=0x409) with the following information:

a.   In the first section, enter the record type (for example, "Weekly status e-mail message"), the record category (for example, "Personnel records"), and the name of the document library that will retain records of this type.

b.   In the Plan metadata section, in the Column name column, enter on separate rows the name of each metadata field that will be submitted for retention with the messages that will be stored in this library. In the Type field, indicate that the metadata is "record metadata." Indicate if the metadata is required. If the metadata field is new, record that in the worksheet. Note that a new metadata field requires that a new column be added to the Site Column gallery. For more information, see Plan content types.

c.   In the Plan policy section, enter the policy features to associate with this document library (for example, auditing and expiration). Typically, policy settings are related to a record category, as specified in the Record categories worksheet (http://go.microsoft.com/fwlink/?LinkID=73300&clcid=0x409).

The details of configuring policies are beyond the scope of this article. For guidance in configuring information management policies and using them in a Records Center site, see Plan information management policies and Design the Records Center.

d.   Enter record routing information for each managed folder. In the Records routing table worksheet (http://go.microsoft.com/fwlink/?LinkId=73303&clcid=0x409), on a new line, enter the title of the record series. This should be the name of the label used to journal e-mail messages to this record series. Enter a description for this record series, such as "E-mail status report messages." Enter the name of the document library that will store the e-mail message records. This should match the name of a document library recorded in a Document library for retaining records worksheet (http://go.microsoft.com/fwlink/?LinkId=73298&clcid=0x409). If other managed folders are being routed to the same document library, enter their labels in the Aliases column.

Worksheets

Use the following worksheets to record your planning decisions about e-mail message records retention.

•      Managed folders worksheet (http://go.microsoft.com/fwlink/?LinkId=84737&clcid=0x409)

•      Record categories worksheet (http://go.microsoft.com/fwlink/?LinkID=73300&clcid=0x409)

•      Document library for retaining records worksheet (http://go.microsoft.com/fwlink/?LinkId=73298&clcid=0x409)

•      Records routing table worksheet (http://go.microsoft.com/fwlink/?LinkId=73303&clcid=0x409)

Download this book

This topic is included in the following downloadable book for easier reading and printing:

•      Records Management Guide for Microsoft Office SharePoint Server 2007 (http://go.microsoft.com/fwlink/?LinkID=92720)

See the full list of available books at Downloadable books for Office SharePoint Server 2007 (http://technet.microsoft.com/en-us/library/cc262788(TechNet.10).aspx).

See Also

Plan records management

Microsoft Exchange Server 2007 technical library (http://technet.microsoft.com/en-us/library/bb124558.aspx)

XII.  Plan site and content security

The articles in this chapter include:

•      Plan site security

•      Determine permission levels and groups to use

•      Define custom permission levels

•      Choose which security groups to use

•      Choose administrators and owners for the administration hierarchy

Plan site and content security

There are several elements that make up security for your environment. One of these elements is the permissions that control access to your sites and the content in your sites. A new security model and new security features (such as SharePoint groups to control membership, and item- and document-level permissions) make it easy to control who has access to what content in your sites. This chapter explains how security for sites and site content works, and it guides you through making choices about site security.

Another element integral to the security of your environment is how you structure security at the Web application level — choosing authentication methods and specifying the encryption methods to use. For more information, see Chapter overview: Plan for and design security [Office SharePoint Server].

In this chapter:

•      Plan site security helps you understand the elements of site security and how permissions are assigned, and it helps you choose which levels of site security to use in your site collection or subsite.

•      Determine permission levels and groups to use reviews the available permission levels and groups, and it helps you determine whether you need additional permission levels or groups.

•      Define custom permission levels helps you create any custom permission levels you might need.

•      Choose which security groups to use helps you determine which Microsoft Windows security groups and user accounts to use to grant access to sites, decide whether to use the All Authenticated Users group, and decide whether to allow anonymous access.

•      Choose administrators and owners for the administration hierarchy defines the levels of administration from the server level to the subsite level, and it helps you choose the administrators you need for each level.

Plan site security

In this article:

•      About site security elements

•      About assigning permissions

•      About fine-grained permissions and permission inheritance

•      Choose which levels of site security to use

•      Plan for permission inheritance

•      Worksheet

This article addresses planning for access control and authorization at the site collection, site, and subsite levels, and does not address planning for the security of your server or server farm. For more information about planning for other aspects of security, such as authentication methods and encryption, see Plan site and content security.

Site security is controlled by assigning permissions to users and groups for a specific securable object (such as site, list, or item). When you plan for site security, you need to decide:

•      To what degree you want to control permissions for individual securable objects. For example, do you want to control access for the entire site, or do you need specific security settings for a particular list, folder, or item?

•      How you want to categorize and manage your users (by using groups). This article covers the essentials of site security and assists you as you determine the securable objects at which to apply specific permissions. For more information about categorizing users into groups, see Choose which security groups to use.

Note:

The way that groups and permissions interact has changed significantly from the previous version. In the previous version, site-level groups were used to contain both users and permissions — that is, when you added a user to a site group, you automatically determined the permissions that the user was granted for a site. In this version, the concepts of groups of users and permissions have been separated: SharePoint groups at the site collection level contain the users, permission levels contain the permissions, and groups have no permissions until they are assigned a permission level for a specific securable object (such as a site, list or library, folder, item, or document).

About site security elements

Regardless of what type of site you are creating, the security for your site includes the following five elements:

•      Individual user permissions   Individual permissions that grant the ability to perform specific actions. For example, the View Items permission grants the user the ability to view items in a list. Farm administrators can control which permissions are available for the server farm by using the User Permissions for Web Application page in Central Administration. (To get to this page, on the Application Management page, under Application Security, click User permissions for Web application.) For information about available permissions, see User permissions and permission levels.

•      Permission level   A pre-defined set of permissions that grants users permission to perform related actions. The default permission levels are: Limited Access, Read, Contribute, Design, and Full Control. For example, the Read permission level includes the View Items, Open Items, View Pages, and View Versions permissions (among others), all of which are needed to read documents, items, and pages of a SharePoint site. Permissions can be included in multiple permission levels. Permission levels can be customized by anyone assigned to a permission level that includes the Manage Permissions permission. For information about default permission levels and which permissions are included in them, see User permissions and permission levels.

•      User   A person with a user account that can be authenticated through the authentication method used for the server. You can add individual users and directly assign a permission level to each user; users do not have to be part of a group. We recommend that you assign permissions to groups rather than users. Because it is inefficient to directly maintain user accounts, you should only assign permissions on a per-user basis as an exception. For more information about user account types, see User permissions and permission levels.

•      Group   A group of users. Can be a Windows security group (such as Department_A) that you add to the site, or a SharePoint group such as Site Owners, Site Members, or Site Visitors. Each SharePoint group is assigned a default permission level, but the permission level for any group can be changed as needed. Anyone assigned a permission level that includes the Create Groups permission (included in the Full Control permission level by default) can create custom SharePoint groups.

•      Securable object   Users or groups are assigned a permission level for a specific securable object: site, list, library, folder, document, or item. By default, permissions for a list, library, folder, document, or item are inherited from the parent site or parent list or library. However, anyone assigned a permission level for a particular securable object that includes the Manage Permissions permission can change the permissions for that securable object. By default, permissions are initially controlled at the site level, with all lists and libraries inheriting the site permissions. Use list-level, folder-level, and item-level permissions to further control which users can view or interact with the site content. You can return to inheriting permissions from a parent list, the site as a whole, or a parent site, at any time.

About assigning permissions

You can assign a user or group a permission level for a specific securable object (site, list, or item). Individual users or groups can have different permission levels for different securable objects.

Note:

Because it is inefficient to directly maintain user accounts, it is recommended that you use group permissions as much as possible. Particularly if you are using fine-grained permissions (see the following section), you should use groups to avoid having to track individual user accounts. People can move in and out of teams and change responsibilities frequently, and you do not want to have to track all of those changes and continually update the permissions for uniquely secured objects.

The following diagram illustrates how users and groups are assigned specific permission levels for a particular securable object.

About fine-grained permissions and permission inheritance

You can use fine-grained permissions (permissions on the list or library, folder, or item or document level) to more precisely control what actions users can take on your site. The following securable objects are available for permission assignments:

•      Site   Controls access to the site as a whole.

•      List or library   Controls access to a specific list or library.

•      Folder   Controls access to a folder's properties (such as the name of the folder).

•      Item or document   Controls access to a specific list item or document.

Permission inheritance and fine-grained permissions

By default, permissions within a site are inherited from the site. However, you can break this inheritance for any securable object at a lower level in the hierarchy by editing the permissions (creating a unique permission assignment) on that securable object. For example, you can edit the permissions for a document library, which breaks the inheritance from the site. However, the inheritance is broken for only the particular securable object for which you assigned permissions; the rest of the site's permissions are unchanged. You can return to inheriting permissions from the parent list or site at any time.

Permission inheritance and subsites

Web sites are themselves a securable object to which permissions can be assigned. You can configure subsites to inherit permissions from a parent site or create unique permissions for a particular site. Inheriting permissions is the easiest way to manage a group of Web sites. However, if a subsite inherits permissions from its parent, that set of permissions is shared. This means that owners of subsites that inherit permissions from the parent site can edit the permissions of the parent. If you want to change permissions for the subsite alone, you must stop inheriting permissions and then make the change.

Subsites can inherit permissions from a parent site. You can stop inheriting permissions for a subsite by creating unique permissions. This copies the groups, users, and permission levels from the parent site to the subsite, and then breaks the inheritance. If you change from unique permissions to inherited, then users, groups, and permission levels start being inherited, and you lose any users, groups or permission levels that you uniquely defined in the subsite. Permission levels can also be inherited (and they are, by default), such that the Read permission level is the same, no matter what object it is applied to. You can break that inheritance by editing the permission level. For example, you might not want the Read permission level on a particular subsite to include the Create Alerts permission).

Choose which levels of site security to use

When you create your permission structure, it is important to find the balance between ease of administration, performance, and the need to control specific permissions for individual items. If you use fine-grained permissions extensively, you will spend more time managing the permissions, and users may experience slower performance when they try to access site content. As with any server or Web site, it is also important to follow the principle of least privilege when it comes to authorizing access to the site: Users should have only the permission levels they need to use. Begin by using the standard groups (such as Members, Visitors, and Owners) and controlling permissions at the site level for the easiest administration experience. Make most users members of the Visitors or Members groups. Limit the number of people in the Owners group to only those users whom you want to allow to change the structure of the site or change site settings and appearance. By default, users in the Members group can contribute to the site, adding or removing items or documents, but cannot change the structure of the site or change site settings or appearance. You can create additional SharePoint groups and permission levels if you need more control over the actions that your users can take.

If there are particular lists, libraries, folders, items, or documents that contain sensitive data and must be even more secure, you can grant permissions to a specific group or individual user. Be aware, however, that there is no way to view all of the permissions specific to lists, libraries, folders, items, or documents within a site. This means that it is difficult to quickly ascertain who has permissions on which securable objects and also difficult to reset any fine-grained permissions in bulk.

Plan for permission inheritance

It is easiest to manage permissions when there is a clear hierarchy of permissions and inherited permissions. It gets more difficult when some lists within a site have fine-grained permissions applied, and when some sites have subsites with unique permissions and some with inherited permissions. As much as possible, arrange sites and subsites, and lists and libraries so they can share most permissions. Separate sensitive data into their own lists, libraries, or subsites.

For example, it's much easier to manage a site that has permission inheritance as illustrated in the following table.

Securable object

Description

Unique or inherited permissions

SiteA

Group home page

Unique

SiteA/SubsiteA

Sensitive group

Unique

SiteA/SubsiteA/ListA

Sensitive data

Unique

SiteA/SubsiteA/LibraryA

Sensitive documents

Unique

SiteA/SubsiteB

Group shared project information

Inherited

SiteA/SubsiteB/ListB

Non-sensitive data

Inherited

SiteA/SubsiteB/LibraryB

Non-sensitive documents

Inherited

Comparatively, it is not so easy to manage a site that has permission inheritance as illustrated in the following table.

Securable object

Description

Unique or inherited permissions

SiteA

Group home page

Unique

SiteA/SubsiteA

Sensitive group

Unique

SiteA/SubsiteA/ListA

Non-sensitive data

Unique, but same permissions as SiteA

SiteA/SubsiteA/LibraryA

Non-sensitive documents, but with one or two sensitive documents

Inherited, with unique permissions at the document level

SiteA/SubsiteB

Group shared project information

Inherited

SiteA/SubsiteB/ListB

Non-sensitive data, but with one or two sensitive items

Inherited, with unique permissions at the item level

SiteA/SubsiteB/LibraryB

Non-sensitive documents, but with a special folder containing sensitive documents

Inherited, with unique permissions at the folder and document level

Worksheet

On the Site and content security worksheet (http://go.microsoft.com/fwlink/?LinkId=73135&clcid=0x409), fill in your site hierarchy, and then list the permissions needed at each level of the hierarchy and any permission inheritance.

Determine permission levels and groups to use

In this article:

•      Review available default groups

•      Review available permission levels

•      Determine whether you need additional permission levels or groups

•      Worksheet2

The most important decision about your site and content security in Microsoft Office SharePoint Server 2007 is to decide how to categorize your users and what permission levels to assign.

There are several default SharePoint groups that are intended to help you categorize your users based on the types of actions they need to perform, but you might have unique requirements or other ways of looking at sets of users. Likewise, there are default permission levels, but they might not always align exactly with the tasks that your groups need to perform.

In this article, you review the default groups and permission levels and decide whether to use them as they are, customize them, or create different groups and permission levels.

Review available default groups

With SharePoint groups, you manage sets of users rather than individual users. SharePoint groups can be composed of many individual users, can hold a single Windows security group, or can be some combination of the two. SharePoint groups confer no specific rights to the site; they are merely a means to contain a set of users. Depending on the size and complexity of your organization or Web site, you can organize your users into several groups, or just a few.

The default SharePoint groups that are created for sites in Office SharePoint Server 2007 are listed in the following table.

Group name

Default permission level

Restricted Readers

Restricted Read to the site (plus Limited Access to specific lists)

Style Resource Readers

Read to the Master Page Gallery and Restricted Read to the Style Library.

Viewers

View Only

Home Visitors

Read

Home Members

Contribute

Quick Deploy Users

Contribute to the Quick Deploy Items library (plus Limited Access to the rest of the site)

Approvers

Approve (plus Limited Access)

Designers

Design

Hierarchy Managers

Manage Hierarchy (plus Limited Access)

Home Owners

Full Control

Note:

The Limited Access permission level is used to give groups access to a specific list, document library, item, or document, without giving them access to the entire site. Do not remove this permission level from the groups listed above. If this permission level is removed, the groups might not be able to navigate through the site to get to specific items with which they need to interact.

In addition, the following special users and groups are available for higher-level administration tasks:

•      Site collection administrators   You can designate one or more users as primary and secondary site collection administrators. These users are recorded in the database as the contacts for the site collection, have full control of all sites within the site collection, can audit all site content, and receive any administrative alerts (such as verifying whether the site is still in use). Generally, you designate site collection administrators when you create the site, but you can change them as needed by using the Central Administration site or Site Settings pages.

•      Farm administrators   Controls which users can manage server and server farm settings. The Farm Administrators group replaces the need for adding users to the Administrators group for the server, or to the SharePoint Administrators group that was used in Windows SharePoint Services version 2.0. Farm administrators have no access to site content by default; they must take ownership of the site to view any content. They do this by adding themselves as site collection administrators, which action is recorded in the audit logs. The Farm Administrators group is used in Central Administration only, and is not available for any sites.

•      Administrators   Members of the Administrators group on the local server can perform all farm administrator actions and more, including:

•      Installing new products or applications.

•      Deploying Web Parts and new features to the global assembly cache.

•      Creating new Web applications and new IIS Web sites.

•      Starting services.

Like the Farm Administrators group, members of the Administrators group on the local server have no access to site content, by default.

After you identify the groups you need, determine the permission levels to assign to each group on your site.

Worksheet action

Use the Custom permission levels and groups worksheet (http://go.microsoft.com/fwlink/?LinkId=73134&clcid=0x409) to record any groups you need to create.

Review available permission levels

The ability to view, change, or manage a particular site is determined by the permission level that you assign to a user or group. This permission level controls all permissions for the site and for any subsites, lists, document libraries, folders, and items or documents that inherit the site's permissions. Without the appropriate permission levels, your users might not be able to perform their tasks, or they might be able to perform tasks that you did not intend them to perform.

By default, the following permission levels are available:

•      Limited Access   Includes permissions that allow users to view specific lists, document libraries, list items, folders, or documents when given permissions.

•      Read   Includes permissions that allow users to view items on the site pages.

•      Contribute   Includes permissions that allow users to add or change items on the site pages or in lists and document libraries.

•      Design   Includes permissions that allow users to change the layout of site pages by using the browser or Microsoft Office SharePoint Designer 2007.

•      Approve   Includes permissions to edit and approve pages, list items, and documents.

•      Manage Hierarchy   Includes permissions to sites and edit pages, list items, and documents.

•      Restricted Read   Includes permissions to view pages and documents, but not historical versions or user rights information.

•      Full Control   Includes all permissions.

For more information about permissions that are included in the default permission levels, see User permissions and permission levels.

Determine whether you need additional permission levels or groups

The default groups and permission levels are designed to provide a general framework for permissions, covering a wide range of organization types and roles within those organizations. However, they might not map exactly to how your users are organized or to the variety of tasks that your users perform on your sites. If the default groups and permission levels do not suit your organization, you can create custom groups, change the permissions included in specific permission levels, or create custom permission levels.

Do you need custom groups?

The decision to create custom groups is fairly straightforward and has little impact on your site's security. Essentially, you should create custom groups instead of using the default groups if any of the following applies:

•      You have more (or fewer) user roles within your organization than are apparent in the default groups. For example, if in addition to Approvers, Designers, and Hierarchy Managers, you have a set of people who are tasked with publishing content to the site, you might want to create a Publishers group.

•      There are well-known names for unique roles within your organization that perform very different tasks in the sites. For example, if you are creating a public site to sell your organization's products, you might want to create a Customers group that replaces Visitors or Viewers.

•      You want to preserve a one-to-one relationship between Windows security groups and the SharePoint groups. (For example, your organization has a security group for Web Site Managers, and you want to use that name as a group name for easy identification when managing the site).

•      You prefer other group names.

Do you need custom permission levels?

The decision to customize permission levels is less straightforward than the decision to customize SharePoint groups. If you customize the permissions assigned to a particular permission level, you must keep track of that change, verify that it works for all groups and sites affected by that change, and ensure that the change does not negatively affect your security or your server capacity or performance.

For example, regarding security, if you customize the Contribute permission level to include the Create Subsites permission that is typically part of the Full Control permission level, members of the Contributors group can create and own subsites, and can potentially invite malicious users to their subsites or post unapproved content. Or, regarding capacity, if you customize the Read permission level to include the Create Alerts permission that is typically part of the Contribute permission level, all members of the Home Visitors group can create alerts, which might overload your servers.

You should customize the default permission levels if either of the following applies:

•      A default permission level includes all permissions except one that your users need to do their jobs, and you want to add that permission.

•      A default permission level includes a permission that your users do not need.

Note:

You should not customize the default permission levels if your organization has security or other concerns about a particular permission and wants to make that permission unavailable for all users assigned to the permission level or levels that include that permission. In this case, you should turn off this permission for all Web applications in your server farm, rather than change all of the permission levels. To manage permissions for a Web application, in Central Administration, on the Application Management page, in the Application Security section, click User permissions for Web application.

If you need to make several changes to a particular permission level, it is better to create a custom permission level that includes all of the permissions you need.

You might want to create additional permission levels if any of the following applies:

•      You want to exclude several permissions from a particular permission level.

•      You want to define a unique set of permissions for a new permission level.

To create a permission level, you can copy an existing permission level and then make changes, or you can create a permission level and then select the permissions that you want to include.

Note:

Some permissions are dependent on other permissions. If you clear a permission that another permission depends on, the other permission is also cleared.

Worksheet action

Use the Custom permission levels and groups worksheet (http://go.microsoft.com/fwlink/?LinkId=73134&clcid=0x409) to record any permission levels you want to customize or create.

Worksheet

Use the following worksheet to determine permission levels and groups to use:

•      Custom permission levels and groups worksheet (http://go.microsoft.com/fwlink/?LinkId=73134&clcid=0x409)

Define custom permission

In this article:

•      Customize an existing permission level

•      Copy an existing permission level

•      Create a permission level

After you have determined that you need custom permission levels and you have decided what permissions to include in the new permission level, you can create a custom permission level. Permission levels can be created for a site or site collection. You can create a custom permission level by using any of the three procedures in this article.

Customize an existing permission level

If the custom permission level that you want is nearly identical to an existing default permission level and you don't need to use the default permission level, you can customize the default permission level to include or exclude permissions that you do or do not need.

1.   On the Site Settings page, under Users and Permissions, click Advanced permissions.

2.   On the toolbar, click Settings, and then click Permission Levels.

3.   In the list of permission levels, click the name of the permission level you want to customize.

4.   In the list of or permissions, select or clear the check boxes to add permissions to or remove permissions from the permission level.

5.   Click Submit.

Copy an existing permission level

If the custom permission level that you want is similar to an existing default permission level, and you need to use both the default permission level and your custom permission level, you can copy the default permission level, and then modify the copy and save it as a new permission level.

1.   On the Site Settings page, under Users and Permissions, click Advanced permissions.

2.   On the toolbar, click Settings, and then click Permission Levels.

3.   In the list of permission levels, click the name of the permission level you want to copy.

4.   At the bottom of the page, click Copy Permission Level.

5.   On the Copy Permission Level page, in the Name box, type a name for the new permission level.

6.   In the Description box, type a description for the new permission level.

7.   In the list of permissions, select or clear the check boxes to add permissions to or remove permissions from the permission level.

8.   Click Create.

Create a permission level

If there is no permission level similar to the one you need, you can create one and include just the permissions that you need.

1.   On the Site Settings page, under Users and Permissions, click Advanced permissions.

2.   On the toolbar, click Settings, and then click Permission Levels.

3.   On the toolbar, click Add a Permission Level.

4.   On the Add a Permission Level page, in the Name box, type a name for the new permission level.

5.   In the Description box, type a description for the new permission level.

6.   In the list of permissions, select the check boxes to add permissions to the permission level.

7.   Click Create.

Choose which security groups to use

In this article:

•      Determine which Windows security groups and accounts to use for granting access to sites

•      Decide whether to use all authenticated users

•      Decide whether to allow access to anonymous users

•      Worksheet

For easier user management, we recommend that you assign site permissions to groups rather than to individual users. In the Microsoft Active Directory directory service, the following two types of groups are commonly used to organize users:

•      Distribution group   A group that is only used for e-mail distribution and that is not security-enabled. Distribution groups cannot be listed in discretionary access control lists (DACLs) used to define permissions on resources and objects.

•      Security group   A group that can be listed in discretionary access control lists (DACLs) used to define permissions on resources and objects. A security group can also be used as an e-mail entity.

You can use security groups to control permissions for your site by directly adding the security group and granting the entire group permissions. You cannot use distribution groups in this way; however, you can expand a distribution list and add the individual users to a SharePoint group. If you use this method, you must manage the process of keeping the SharePoint group synchronized with the distribution group. If you use security groups, you do not need to manage the individual users in the SharePoint application. Because you included the security group itself and not the individual members of the group, Active Directory manages the users for you.

Determine which Windows security groups and accounts to use for granting access to sites

Each organization sets up its Windows security groups differently. For easiest permission management, security groups should be:

•      Large and stable enough that you aren't constantly adding additional groups to your SharePoint sites.

•      Small enough that you can assign appropriate permissions.

For example, a security group called "all users in building 2" is probably not small enough to assign permissions, unless it happens that all users in building 2 have the same job function, such as accounts receivable clerks. This is rarely the case, so you should look for a smaller set of users, such as "accounts receivable" or some other smaller, highly-related group.

Decide whether to use all authenticated users

If you want all users within your domain to be able to view content on your site, consider granting access to all authenticated users (the Domain Users Windows security group). This special group allows all members of your domain to access a Web site (at the permission level you choose), without your having to enable anonymous access.

Decide whether to allow access to anonymous users

You can enable anonymous access to allow users to view pages anonymously. Most Internet Web sites allow anonymous viewing of the site, but might ask for authentication when someone wants to edit the site or buy an item on a shopping site. Anonymous access must be granted at the Web application level at the time that the Web application is created. If anonymous access is allowed for the Web application, then site administrators can decide whether to:

•      Grant anonymous access to a site.

•      Grant anonymous access only to lists and libraries.

•      Block anonymous access to a site altogether.

Anonymous access relies on the anonymous user account on the Web server. This account is created and maintained by Microsoft Internet Information Services (IIS), not your SharePoint site. By default in IIS, the anonymous user account is IUSR_ ComputerName. When you enable anonymous access, you are in effect granting that account access to the SharePoint site. Allowing access to a site, or to lists and libraries, grants the View Items permission to the anonymous user account. Even with the View Items permission, however, there are restrictions to what anonymous users can do. Anonymous users cannot:

•      Use the Microsoft Office SharePoint Designer remote procedure call (RPC); in other words, they cannot open sites for editing in Office SharePoint Designer. They can also not use DAV (the Web Folders protocol in Windows); in other words, they cannot view the site in My Network Places.

•      Upload or edit documents in document libraries, including wiki libraries.

Important:

To create more secure sites, lists, or libraries, do not enable anonymous access. Enabling anonymous access allows users to contribute to lists, discussions, and surveys, possibly using up server disk space and other resources. Further, it allows anonymous users to discover site information, including user e-mail addresses and any content posted to lists, and libraries, and discussions.

You can also set permission policies for the anonymous user for different zones (Internet, Extranet, Intranet, Other), if you have the same Web application serving content in those different zones. The policies are described in the following list:

•      None   No policy. This is the default option. No additional permission restrictions or additions are applied to site anonymous users.

•      Read   Anonymous users can read content, unless the site administrator turns off anonymous access.

•      Deny Write   Anonymous users cannot write content, even if the site administrator specifically attempts to grant the anonymous user account that permission.

•      Deny All   Anonymous users cannot have any access, even if site administrators specifically attempt to grant the anonymous user account access to their sites.

Worksheet

On the Site and content security worksheet (http://go.microsoft.com/fwlink/?LinkId=73135&clcid=0x409), list the security groups that you will use and the permission levels they will need at each level of your site hierarchy.

Choose administrators and owners for the administration hierarchy

In this article:

•      Levels of administration

•      Worksheet

Administration of Microsoft Office SharePoint Server 2007 occurs at many levels, such as on the server farm as a whole, on shared services, and on individual sites. Many people can be involved in managing Office SharePoint Server 2007.

Levels of administration

Most levels of the server and site hierarchy have a corresponding administration group. Although the Web application level does not have a unique administrator group, farm administrators and service administrators have control over the Web applications within their scope. Members of the Farm Administrators group and members of the Administrators group on the local server can define a policy to grant individual users permissions at the Web application level. For more information about policy, see "Policy for Web applications" in the Logical architecture elements article.

The groups of users who have administrative permissions at different levels are described in the following list:

•      Server or server farm level

•      Farm Administrators group   Members of the Farm Administrators group have permissions to and responsibility for all servers in the server farm. Members can perform all administrative tasks in Central Administration for the server or server farm. Members of this group can also perform command-line operations. This group does not have access to individual sites or their content. However, members can take ownership of a specific site collection if need be (for example, if the administrator of a site leaves the organization and a new administrator must be added).

•      Administrators group   Members of the Administrators group on the local server can perform all farm administrator actions and more, including installing new products or applications, deploying Web Parts and new features to the global assembly cache, creating new Web applications and new Internet Information Services (IIS) Web sites, and starting services. Like farm administrators, members of this group on the local server have no access to site content, by default.

Note:

Farm administrators and administrators can also take ownership of specific site collections, if needed. To take ownership, they can add themselves as the site collection administrator by using the Site Collection Administrators page in Central Administration.

•      Shared services level

•      SSP administrators   Can control which services are included in a Shared Services Provider (SSP) and configure settings for those services.

•      Service administrators   Can configure settings for a specific service within an SSP. For example, the service administrator for the Search service on Service1 can configure search settings for Service1.

•      Site level

•      Site collection administrators   Have the Full Control permission level on all Web sites within a site collection. This means that they have access to content in all sites in that site collection, even if they do not have explicit permissions on that site.

•      Site owners   By default, members of the Owners group for a site have the Full Control permission level on that site. They can perform administration tasks for the site, and for any list or library within that site.

Worksheet action

Use the Administrators and owners worksheet (http://go.microsoft.com/fwlink/?LinkId=73126&clcid=0x409) to record which administrators to assign to each level. Refer to your site hierarchy diagram to be sure you assign owners for each site collection, top-level Web site, and subsite that you are planning.

Worksheet

Use the following worksheet to choose administrators and owners for the administration hierarchy:

•      Administrators and owners worksheet (http://go.microsoft.com/fwlink/?LinkId=73126&clcid=0x409)

XIII.  Plan for site creation and maintenance

The articles in this chapter include:

•      Plan for site creation and maintenance

•      Plan process for creating sites

•      Plan for site maintenance and management

Plan for site creation and maintenance

If you plan on having more than a few site collections in your Microsoft Office SharePoint Server 2007 environment, you need to be sure that you have a plan for site creation and maintenance. Without such a plan, it is difficult to control or track when SharePoint sites are created, whether sites are still active, and when you can safely remove inactive sites. Before you deploy and make sites available to users, you need to answer questions such as:

•      Do you want to tightly control site creation or to allow many users to create sites?

•      At which level in the site hierarchy should additional sites be created?

•      How do you find and remove unused sites in your environment?

The articles and worksheets in this chapter help you design and record a plan for site creation and maintenance. This will help you be prepared to manage growth in your environment.

Plan for site creation and maintenance by using the following articles:

•      Plan process for creating sites helps you determine which type of site creation process will fit your organization, and which method to use to implement that process.

•      Plan for site maintenance and management helps you to plan for maintaining your SharePoint sites from the beginning to ensure your sites stay current, useful, and usable.

Plan for site maintenance and management

In this article:

•      Plan for site maintenance

•      Plan for managing site collections

•      Worksheet

All Web sites, particularly sites that have more than one author, get cluttered. Periodic review and cleanup can help keep your site functioning well, whether your site is large or small. If you build a plan for maintaining your site or sites from the beginning, you can ensure that they stay current, useful, and usable.

Plan for site maintenance

Your site maintenance plan will be different than that for any other environment, and it will contain different elements. Site maintenance is different for sites managed by an IT department than it is for user-created sites and managed sites. However, some best practices for a site maintenance plan include:

•      Ask users what they want in IT-managed sites. Perform periodic surveys to determine what your users need from the site.

•      Use usage logs and reports to find out which areas of the site are being used, and then correlate that with user surveys to find out what can be improved.

•      Archive obsolete content or sites. However, if you are going to archive or delete obsolete content or sites, be sure that users understand that plan, and that you perform these actions only at predictable times. For example, publish a schedule of when you are going to archive content or delete unused sites.

•      Periodically review site permissions. For example, review the permissions quarterly to remove permissions for any users who have left the group or project.

•      Select a reasonable time interval for your maintenance activities. For example, if you plan to conduct periodic user surveys, do not conduct them more than twice a year (and preferably, no more than once a year).

•      Create a plan for regular backups of site content. Determine or discover how often backups will be made, and the process for restoring content when necessary. For more information about planning for backup and restore, see Plan for data protection and recovery (Office SharePoint Server).

Start now, during your planning process, to create a plan for site maintenance. Record your plan, including how often to tune up the site and archive content. Get your plan reviewed by members of your team and representatives of your user base. This way, you can identify any concerns that users might have now, determine how best to address these concerns, and have a plan for site maintenance in place by the time your site goes live.

Worksheet action

Use the Site maintenance worksheet (http://go.microsoft.com/fwlink/?LinkID=73146&clcid=0x409) to create a site maintenance plan.

Plan for managing site collections

One part of your site maintenance plan should be a plan for how to manage the size and number of site collections in your environment. This is most important if you are allowing Self-Service Site Management. Most organizations want to be able to predict and control how much growth they can expect from sites because of the impact that they can have on database resources. For example, if a particular content database contains 100 sites, and one of those sites is taking up more than 50 percent of the space, then that site might need to be in its own content database. This will ensure that you preserve some room for additional growth, while maintaining the ability to back up and restore the databases.

Two methods for managing site collections are:

•      Site collection quotas   Use this method to control how large site collections can become.

•      Site use confirmation and deletion   Use this method to monitor and remove unused site collections.

Plan site collection quotas

Use quotas to track and limit site storage. You can send a warning e-mail message to site owners when site storage reaches a particular size (in megabytes), and then lock the site to further content when site storage reaches a maximum size. When you perform your database and server capacity planning, determine what size limits (if any) you want to enforce. To take the best advantage of quotas:

•      Create different quota templates for different site types. For example, you might want different quotas for different divisions, or for different customer types, or for different paths (perhaps sites under the /sites path only get 100 MB per site collection, whereas sites under the /vip path can take up to 300 MB per site collection). Whenever you create a site collection from Central Administration, you can specify on which quota template it is based. Note that sites created by using Self-Service Site Management use the default quota for the Web application.

•      Give enough room for reasonable growth in sites. Depending on what each site is used for, storage space needs can vary dramatically. Sites are designed to grow over time as they are used. A quota limit of 50 MB is unlikely to be enough storage space to start with for most sites, and is unlikely to be anywhere near enough for a site that has a long life.

•      Allow for reasonable notice between the warning e-mail message and locking the site for exceeding its quota. For example, do not set the warning limit to 80 MB and the site storage limit to 85 MB. If users are in the middle of uploading several large files, they will not be happy if blocked from completing that task with very little notice.

Worksheet action

Use the Site maintenance worksheet (http://go.microsoft.com/fwlink/?LinkID=73146&clcid=0x409) to record your decisions about using site collection quotas.

Plan site use confirmation and deletion

You need to plan how to handle sites that become inactive after a project has ended, or sites that users created just to test out some ideas, and then abandoned. Site use confirmation and deletion can help you keep your environment cleaner, by helping you identify when sites are no longer needed. This feature works by automatically sending an e-mail message to site owners to see if they consider their site active. If the owner does not respond to the e-mail message (after a specified number of messages over a specified length of time), the site can be deleted.

To plan for site use confirmation and deletion, decide:

•      How long you want to wait before checking to see if a site is inactive. The default length of time for team or project sites is 90 days after site creation, but you should probably give owners longer than that. For a test or personal site, 90 days is probably too long. Usually a site that was created, was actively used, and is now ready to be deleted or archived, took at least six months and probably a few years to complete that life cycle. Reminders every six months are valuable for those situations.

•      How often you want to send an e-mail message to site owners to see if their sites are inactive. After the first e-mail message, if the site administrator does not respond, you can continue with additional notices at daily, weekly, or monthly intervals.

•      Whether you want to automatically delete unused sites. If the site administrator does not respond to multiple e-mail messages, do you want to go ahead and delete the site automatically? It is recommended that you make a backup first. You can do so by making sure that regular backups are performed and you can use the Office SharePoint Server 2007: Software Development Kit (http://go.microsoft.com/fwlink/?LinkID=72208&clcid=0x409) to customize this functionality so that it automatically makes a backup of the site before deletion, but this is not default behavior.

•      If you are going to automatically delete unused sites, how many e-mail messages will you send to site owners before you do so. By default, four weekly notices are sent before site deletion, but you can increase or decrease this number to suit your needs.

Worksheet action

Use the Site maintenance worksheet (http://go.microsoft.com/fwlink/?LinkID=73146&clcid=0x409) to record your decisions about site use confirmation and deletion.

Worksheet

Use the following worksheet to plan for site maintenance and management:

•      Site maintenance worksheet (http://go.microsoft.com/fwlink/?LinkID=73146&clcid=0x409)

Plan process for creating sites

In this article:

•      Determine who can create sites and a method for site creation

•      Plan for Self-Service Site Management

•      Plan for custom site creation processes

•      Worksheet2

Some organizations need to maintain tight control over who can create sites, or when sites are created. Other organizations can allow users more access and freedom to create sites when needed. This article helps you determine which type of site creation process will fit your organization, and which method to use to implement that process.

Determine who can create sites and a method for site creation

By default, new site collections (and therefore new top-level Web sites) can only be created by using Central Administration, which means that they can only be created by members of the Farm Administrators group. This behavior might suit your organization if you want your environment to be tightly controlled and managed, with only a few people allowed to add top-level sites. However, the default top-level site creation method might not suit your organization if you have any of the following requirements:

•      You want users to be able to easily create informal, perhaps even disposable, top-level sites, such as for short-term projects.

•      You want to create an informal space for team, group, or community interaction.

•      You are hosting top-level sites (either internally or externally) and want the process for requesting and receiving a top-level site to be as quick and low cost as possible.

There are several ways to allow users to create their own sites, while still maintaining some control over your environment. Consider which of the following methods will work best for your organization.

•      Self-Service Site Management   In Central Administration, you can turn on Self-Service Site Management to allow users to create site collections under the /sites path (or other path you specify) within a particular Web application. This method is best used when you want to allow groups or communities to create sites. This method also works well if you are hosting sites and want to allow users to create sites without waiting for a complicated process. The sign-up page for Self-Service Site Management can be customized or replaced with a page that includes all of the information you might need to integrate with a billing system or to track custom metadata about the site at creation time. This method does not work well when large numbers of users need access to multiple sites. Because Self-Service Site Management creates site collections, which have separate permissions, users need to be added uniquely to different site collections. If you use subsites instead, the users can be inherited from the parent site in the site collection.

•      Subsites of existing sites   Limit users to creating subsites of existing sites, rather than new site collections and top-level sites. Any user who has the Full Control or Hierarchy Manager permission level on an existing site can create a subsite. This method is the most limited, because you still control how many site collections there are. Because the sites are always subsites of other sites, they can either be easy to organize (if there are just a few) or very difficult to organize and browse (for example, if everyone in your organization wants a subsite and they create them at different levels in the site collection's hierarchy, the site collection can soon become very difficult to navigate).

Note:

If you do not want users to have this capability, you can remove the Create Subsites right from the Full Control and Hierarchy Manager permission levels, either at the site collection or Web application level.

•      Personal sites   Allow users to create personal sites (also known as My Sites). Personal sites are site collections stored under the /personal path of the Web application. Personal sites are created for individual users, so they are not the appropriate method to use if you are trying to create sites for groups or communities. For more information about personal sites, see Plan My Sites.

Note:

Keep in mind that none of these methods can control how much space each site takes up in your content databases. To control site sizes, you should use quotas and set a size limit for site collections. You cannot set individual size limits for subsites. For more information, see Plan for site maintenance and management (Office SharePoint Server).

Plan for Self-Service Site Management

Self-Service Site Management allows users to create and manage their own top-level Web sites automatically. When you turn on Self-Service Site Management for a Web application, users can create their own top-level Web sites under a specific path (by default, the /sites path). When turned on, this capability advertises itself with an announcement added to the top-level site at the root path of the Web application, so any users who have permission to view that announcement can follow the link.

Note:

If you want to use a path other than /sites for Self-Service Site Management, you must add the path as a wildcard inclusion. For more information, see Plan for collaboration sites.

This capability can obviously affect the security for your Web server. Self-Service Site Management is disabled by default — you must turn on the feature to use it. You enable Self-Service Site Management for a single Web application at a time. If you want to use it on all Web applications in your server farm, you must enable it for every Web application individually.

If you enable Self-Service Site Management, you should consider the following:

•      Generally you should require a secondary site collection administrator. Administrative alerts, such as those for when quotas are exceeded, or checking for unused Web sites, go to the primary and secondary administrators. Having more than one contact reduces administrator involvement with these sites.

•      Define a storage quota and set it as the default quota for the Web application.

•      Review the number of sites allowed per content database. Combined with quotas, this will help you limit the size of the databases in your system.

•      Enable unused Web site notifications, so that sites that are forgotten or no longer of value can be identified.

Because Self-Service Site Management creates new top-level Web sites on an existing Web application, any new sites automatically conform to the Web application's default quota settings, unused Web site notification settings, and other administrative policies.

Worksheet action

Use the Site creation worksheet (http://go.microsoft.com/fwlink/?LinkId=73138&clcid=0x409) to record your decisions about using Self-Service Site Management.

Plan for custom site creation processes

You can, of course, create your own process for site creation by using a custom form to request a site that integrates with a back-end billing system to charge a customer's credit card or a corporate cost center. If you have a complicated system or process that you want to include as part of site creation, you should create a custom application to call the site creation interface and perform any other tasks you require. However, if you simply want to add a few custom fields to the site creation page (for example, to track which department in your company is requesting a particular site), you should consider using Self-Service Site Management and customize the sign-up page to include the information that you need. You can customize the scsignup.aspx page in the site definition to include the metadata that you need without having to develop an entire application.

Worksheet action

Use the Site creation worksheet (http://go.microsoft.com/fwlink/?LinkId=73138&clcid=0x409) to plan your site creation process.

For more information about building custom applications or editing pages in a site definition, see the Office SharePoint Server 2007: Software Development Kit (http://go.microsoft.com/fwlink/?LinkId=72208).

Worksheet

Use the following worksheet to plan the process for creating sites:

•      Site creation worksheet (http://go.microsoft.com/fwlink/?LinkId=73138&clcid=0x409)

Planning worksheets for Office SharePoint Server 2007

In this article:

•      Planning worksheets by task

•      Planning worksheets by title

This article provides links to worksheets that you can use to record information that you gather and decisions that you make as you plan your deployment of Microsoft Office SharePoint Server 2007. Use these worksheets in conjunction with — not as a substitute for — Planning and architecture for Office SharePoint Server 2007.

Planning worksheets by task

For this task

Use this worksheet

To do this

Plan overall design

Determine sites worksheet (http://go.microsoft.com/fwlink/?LinkID=73282&clcid=0x409)

Identify top-level sites needed for the solution and the features to investigate for each site.

Plan Web site structure and publishing

Article pages worksheet (http://go.microsoft.com/fwlink/?LinkId=73316&clcid=0x409)

Plan fields for content pages.

Layout pages worksheet (http://go.microsoft.com/fwlink/?LinkId=73317&clcid=0x409)

Plan layout pages for Web pages.

Master pages worksheet (http://go.microsoft.com/fwlink/?LinkId=73318&clcid=0x409)

Plan master pages for site collections.

Site paths worksheet (http://go.microsoft.com/fwlink/?LinkId=73148&clcid=0x409)

Record managed paths that need to be created for hosting collaboration sites.

Site creation worksheet (http://go.microsoft.com/fwlink/?LinkId=73138&clcid=0x409)

Record a plan for creating sites.

Welcome pages worksheet (http://go.microsoft.com/fwlink/?LinkId=73320&clcid=0x409)

Plan fields for welcome pages.

Plan for personalized content and sites

People, profiles, and policies worksheet (http://go.microsoft.com/fwlink/?LinkID=73268&clcid=0x409)

Plan connections, sources, people features, and audiences.

Search properties worksheet (http://go.microsoft.com/fwlink/?LinkID=73272&clcid=0x409)

Plan properties for search, mapping crawled properties to managed properties.

Site creation worksheet (http://go.microsoft.com/fwlink/?LinkId=73138&clcid=0x409)

Record a plan for creating sites.

Plan InfoPath Forms Services

Data connections for form templates worksheet (http://go.microsoft.com/fwlink/?LinkId=73321&clcid=0x409)

Plan InfoPath Forms Services data connections.

Deploy administrator-approved form templates worksheet (http://go.microsoft.com/fwlink/?LinkId=73322&clcid=0x409)

Record information to plan administrator-approved form templates.

Plan for business intelligence

Authentication methods worksheet (http://go.microsoft.com/fwlink/?LinkID=73278&clcid=0x409)

Plan and record authentication methods to be allowed in your environment.

Business data worksheet (http://go.microsoft.com/fwlink/?LinkID=73271&clcid=0x409)

Plan for information architecture based on the taxonomy of key concepts and business processes.

Crawl and query search features worksheet (http://go.microsoft.com/fwlink/?LinkID=73276&clcid=0x409)

Plan and record crawl and search settings.

Custom permission levels and groups worksheet (http://go.microsoft.com/fwlink/?LinkID=73134&clcid=0x409)

Record custom permission levels and groups that need to be created.

Estimate data capacity requirements worksheet (http://go.microsoft.com/fwlink/?LinkID=73274&clcid=0x409)

Record information to help capacity planning.

External data connections worksheet (http://go.microsoft.com/fwlink/?LinkId=73323&clcid=0x409)

Plan for Excel Services by recording the names of .odc files and the locations of corresponding external data sources.

Information architecture worksheet (http://go.microsoft.com/fwlink/?LinkID=73273&clcid=0x409)

Plan information architecture based on the taxonomy of key concepts and business processes.

Search properties worksheet (http://go.microsoft.com/fwlink/?LinkID=73272&clcid=0x409)

Plan properties for search, mapping crawled properties to managed properties.

Site and content security worksheet (http://go.microsoft.com/fwlink/?LinkId=73135&clcid=0x409)

Record inherited and unique permissions, and record which groups need what level of access.

Site creation worksheet (http://go.microsoft.com/fwlink/?LinkId=73138&clcid=0x409)

Record a plan for creating sites.

Site hierarchy planning tool (http://go.microsoft.com/fwlink/?LinkId=73143&clcid=0x409)

Create a site hierarchy diagram in Microsoft Office Visio.

Trusted data connection libraries worksheet (http://go.microsoft.com/fwlink/?LinkId=73324&clcid=0x409)

Record the names of trusted data connection libraries.

Trusted data providers worksheet (http://go.microsoft.com/fwlink/?LinkId=73325&clcid=0x409)

Record the names of trusted data providers.

Trusted file locations worksheet (http://go.microsoft.com/fwlink/?LinkId=73327&clcid=0x409)

Record the names of trusted SharePoint sites, Universal Naming Convention paths, and Web sites.

Plan search

Search team worksheet (http://go.microsoft.com/fwlink/?LinkID=73621&clcid=0x409)

Determine and record which team members will be involved in planning and implementing your search solution.

Plan to crawl content worksheet (http://go.microsoft.com/fwlink/?LinkId=73748&clcid=0x409)

For each content source, determine what and when to crawl.

Plan communication

Plan document management

Analyze document usage worksheet (http://go.microsoft.com/fwlink/?LinkID=73284&clcid=0x409)

Record information gathered when analyzing document usage.

Content type worksheet (http://go.microsoft.com/fwlink/?LinkID=73288&clcid=0x409)

Plan a content type.

Document libraries worksheet (http://go.microsoft.com/fwlink/?LinkID=73306&clcid=0x409)

Plan libraries based on sites and on document types.

Document management stakeholders and participants worksheet (http://go.microsoft.com/fwlink/?LinkID=73285&clcid=0x409)

Identify document management planning stakeholders and record document management practices.

Policy worksheet (http://go.microsoft.com/fwlink/?LinkID=73307&clcid=0x409)

Plan information management policies for content types.

Plan records management

Document library for retaining records worksheet (http://go.microsoft.com/fwlink/?LinkID=73298&clcid=0x409)

Plan a document library for retaining records.

Record categories worksheet (http://go.microsoft.com/fwlink/?LinkID=73300&clcid=0x409)

Plan record categories.

Records management stakeholders and participants worksheet (http://go.microsoft.com/fwlink/?LinkId=73330&clcid=0x409)

Identify records management planning stakeholders and analyze records management practices.

Records routing table worksheet (http://go.microsoft.com/fwlink/?LinkID=73303&clcid=0x409)

Design the records routing table.

Plan site and content security

Administrators and owners worksheet (http://go.microsoft.com/fwlink/?LinkId=73126&clcid=0x409)

Record owners for each site collection and site.

Custom permission levels and groups worksheet (http://go.microsoft.com/fwlink/?LinkID=73134&clcid=0x409)

Record custom permission levels and groups that need to be created.

Site and content security worksheet (http://go.microsoft.com/fwlink/?LinkId=73135&clcid=0x409)

Record inherited and unique permissions, and record which groups need what level of access.

Plan for site creation and maintenance

Site creation worksheet (http://go.microsoft.com/fwlink/?LinkId=73138&clcid=0x409)

Record a plan for creating sites.

Site maintenance worksheet (http://go.microsoft.com/fwlink/?LinkId=73146&clcid=0x409)

Record the plan for maintaining sites, including quota values and automatic deletion choices.

Design server farms and topologies

Availability plan worksheet (http://go.microsoft.com/fwlink/?LinkId=73333&clcid=0x409)

Identify redundancy requirements and plan availability options for server roles.

Design logical architecture

Authentication methods worksheet (http://go.microsoft.com/fwlink/?LinkID=73278&clcid=0x409)

Plan and record authentication methods to be allowed in your environment.

Web application authentication settings worksheet (http://go.microsoft.com/fwlink/?LinkId=73334&clcid=0x409)

Plan authentication settings for individual Web applications.

Plan for and design security

Single sign-on enterprise application definition worksheet (http://go.microsoft.com/fwlink/?LinkId=73335&clcid=0x409)

Plan settings for individual enterprise application definitions (used with single sign-on).

Single sign-on server farm settings worksheet (http://go.microsoft.com/fwlink/?LinkId=73336&clcid=0x409)

Plan farm-level single sign-on settings.

Plan for capacity

Estimate data capacity requirements worksheet (http://go.microsoft.com/fwlink/?LinkID=73274&clcid=0x409)

Record information to help capacity planning.

Estimate peak throughput worksheet (http://go.microsoft.com/fwlink/?LinkId=73337&clcid=0x409)

Record each type of site access to determine peak throughput required.

Plan for and design database storage and management

Estimate data capacity requirements worksheet (http://go.microsoft.com/fwlink/?LinkID=73274&clcid=0x409)

Record information to help capacity planning.

Planning worksheets by title

Use this worksheet

For this task

To do this

Administrators and owners worksheet (http://go.microsoft.com/fwlink/?LinkId=73126&clcid=0x409)

Plan site and content security

Record owners for each site collection and site.

Analyze document usage worksheet (http://go.microsoft.com/fwlink/?LinkID=73284&clcid=0x409)

Plan document management

Record information gathered when analyzing document usage.

Article pages worksheet (http://go.microsoft.com/fwlink/?LinkId=73316&clcid=0x409)

Plan Web site structure and publishing

Plan fields for content pages.

Authentication methods worksheet (http://go.microsoft.com/fwlink/?LinkID=73278&clcid=0x409)

Plan for business intelligence

Design logical architecture

Plan and record authentication methods to be allowed in your environment.

Availability plan worksheet (http://go.microsoft.com/fwlink/?LinkId=73333&clcid=0x409)

Design server farms and topologies

Identify redundancy requirements and plan availability options for server roles.

Business data worksheet (http://go.microsoft.com/fwlink/?LinkID=73271&clcid=0x409)

Plan for business intelligence

Plan for information architecture based on the taxonomy of key concepts and business processes.

Content type worksheet (http://go.microsoft.com/fwlink/?LinkID=73288&clcid=0x409)

Plan document management

Plan a content type.

Crawl and query search features worksheet (http://go.microsoft.com/fwlink/?LinkID=73276&clcid=0x409)

Plan for business intelligence

Plan search

Plan and record crawl and search settings.

Custom permission levels and groups worksheet (http://go.microsoft.com/fwlink/?LinkID=73134&clcid=0x409)

Plan for business intelligence

Plan site and content security

Record custom permission levels and groups that need to be created.

Data connections for form templates worksheet (http://go.microsoft.com/fwlink/?LinkId=73321&clcid=0x409)

Plan InfoPath Forms Services

Plan InfoPath Forms Services data connections.

Deploy administrator-approved form templates worksheet (http://go.microsoft.com/fwlink/?LinkId=73322&clcid=0x409)

Plan InfoPath Forms Services

Record information to plan administrator-approved form templates.

Determine sites worksheet (http://go.microsoft.com/fwlink/?LinkID=73282&clcid=0x409)

Plan overall design

Identify top-level sites needed for the solution and the features to investigate for each site.

Document libraries worksheet (http://go.microsoft.com/fwlink/?LinkID=73306&clcid=0x409)

Plan document management

Plan libraries based on sites and on document types.

Document library for retaining records worksheet (http://go.microsoft.com/fwlink/?LinkID=73298&clcid=0x409)

Plan records management

Plan a document library for retaining records.

Document management stakeholders and participants worksheet (http://go.microsoft.com/fwlink/?LinkID=73285&clcid=0x409)

Plan document management

Identify document management planning stakeholders and record document management practices.

Estimate data capacity requirements worksheet (http://go.microsoft.com/fwlink/?LinkID=73274&clcid=0x409)

Plan for business intelligence

Plan for capacity

Plan for and design database storage and management

Record information to help capacity planning.

Estimate peak throughput worksheet (http://go.microsoft.com/fwlink/?LinkId=73337&clcid=0x409)

Plan for capacity

Record each type of site access to determine peak throughput required.

External data connections worksheet (http://go.microsoft.com/fwlink/?LinkId=73323&clcid=0x409)

Plan for business intelligence

Plan for Excel Services by recording the names of .odc files and the locations of corresponding external data sources.

Information architecture worksheet (http://go.microsoft.com/fwlink/?LinkID=73273&clcid=0x409)

Plan for business intelligence

Plan information architecture based on the taxonomy of key concepts and business processes.

Layout pages worksheet (http://go.microsoft.com/fwlink/?LinkId=73317&clcid=0x409)

Plan Web site structure and publishing

Plan layout pages for Web pages.

Master pages worksheet (http://go.microsoft.com/fwlink/?LinkId=73318&clcid=0x409)

Plan Web site structure and publishing

Plan master pages for site collections.

People, profiles, and policies worksheet (http://go.microsoft.com/fwlink/?LinkID=73268&clcid=0x409)

Plan for personalized content and sites

Plan connections, sources, people features, and audiences.

Policy worksheet (http://go.microsoft.com/fwlink/?LinkID=73307&clcid=0x409)

Plan document management

Plan information management policies for content types.

Record categories worksheet (http://go.microsoft.com/fwlink/?LinkID=73300&clcid=0x409)

Plan records management

Plan record categories.

Records management stakeholders and participants worksheet (http://go.microsoft.com/fwlink/?LinkId=73330&clcid=0x409)

Plan records management

Identify records management planning stakeholders and analyze records management practices.

Records routing table worksheet (http://go.microsoft.com/fwlink/?LinkID=73303&clcid=0x409)

Plan records management

Design the records routing table.

Search properties worksheet (http://go.microsoft.com/fwlink/?LinkID=73272&clcid=0x409)

Plan for personalized content and sites

Plan for business intelligence

Plan search

Plan properties for search, mapping crawled properties to managed properties.

Single sign-on enterprise application definition worksheet (http://go.microsoft.com/fwlink/?LinkId=73335&clcid=0x409)

Plan for and design security

Plan settings for individual enterprise application definitions (used with single sign-on).

Single sign-on server farm settings worksheet (http://go.microsoft.com/fwlink/?LinkId=73336&clcid=0x409)

Plan for and design security

Plan farm-level single sign-on settings.

Site and content security worksheet (http://go.microsoft.com/fwlink/?LinkId=73135&clcid=0x409)

Plan for business intelligence

Plan site and content security

Record inherited and unique permissions; record which groups need what level of access.

Site creation worksheet (http://go.microsoft.com/fwlink/?LinkId=73138&clcid=0x409)

Plan for personalized content and sites

Plan for business intelligence

Plan for site creation and maintenance

Plan Web site structure and publishing

Record a plan for creating sites.

Site hierarchy planning tool (http://go.microsoft.com/fwlink/?LinkId=73143&clcid=0x409)

Plan for business intelligence

Create a site hierarchy diagram in Microsoft Office Visio.

Site maintenance worksheet (http://go.microsoft.com/fwlink/?LinkId=73146&clcid=0x409)

Plan for site creation and maintenance

Record the plan for maintaining sites, including quota values and automatic deletion choices.

Site paths worksheet (http://go.microsoft.com/fwlink/?LinkId=73148&clcid=0x409)

Plan Web site structure and publishing

Record managed paths that need to be created for hosting collaboration sites.

Trusted data connection libraries worksheet (http://go.microsoft.com/fwlink/?LinkId=73324&clcid=0x409)

Plan for business intelligence

Record the names of trusted data connection libraries.

Trusted data providers worksheet (http://go.microsoft.com/fwlink/?LinkId=73325&clcid=0x409)

Plan for business intelligence

Record the names of trusted data providers.

Trusted file locations worksheet (http://go.microsoft.com/fwlink/?LinkId=73327&clcid=0x409)

Plan for business intelligence

Record the names of trusted SharePoint sites, Universal Naming Convention paths, and Web sites.

Web application authentication settings worksheet (http://go.microsoft.com/fwlink/?LinkId=73334&clcid=0x409)

Design logical architecture

Plan authentication settings for individual Web applications.

Welcome pages worksheet (http://go.microsoft.com/fwlink/?LinkId=73320&clcid=0x409)

Plan Web site structure and publishing

Plan fields for welcome pages.