Please find the below link to create custom list in Sharepoint..........
http://office.microsoft.com/en-us/sharepointdesigner/HA101191111033.aspx
Thursday, November 15, 2007
Wednesday, November 7, 2007
MOSS 2007 Req Gathering Phase
This content Copied from the Microsoft Site.... to download this document please refer this site
http://www.microsoft.com/downloads/details.aspx?familyid=3d1fa469-0064-4054-9c1a-a6d8c8afce2b&displaylang=en
Deployment and Customization Best Practices for Windows SharePoint Services
Microsoft Corporation
Published: September 2005
Abstract
This document provides answers to some of the most frequently asked questions (FAQs) that IT professionals have about deploying and customizing Windows® SharePoint™ Services. The questions and answers will be of specific interest to system architects, implementers, and operations staff who are evaluating or deploying Windows SharePoint Services in a medium- or large-size organization.
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 White Paper 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, email address, logo, person, place, or event is intended or should be inferred.
© 2005 Microsoft Corporation. All rights reserved.
Microsoft, Active Directory, SharePoint, Windows, the Windows logo, Windows Server, and Windows Server System 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
Introduction 1
Planning 2
Establish Department Representatives and Internal user Groups Early 2
Capacity Planning 2
SharePoint Site Hierarchy Planning 2
Migrating from SharePoint Team Services 1.0 3
Content Migration 3
Extranet Deployment of Windows SharePoint Services 4
Deployment 5
Branding and Customization 5
Active Directory Considerations 5
Training 6
Support 7
Deliver Support Based on a Multi-Level Help Desk Infrastructure 7
Operations 8
Backup and Restore Strategies 8
SharePoint Site Use Confirmation and Automatic Site Deletion 8
Conclusions 10
Related Links 11
Technical Resources 11
Product Information 11
Analyst and Research Reports 12
Introduction
This document provides answers to some of the most frequently asked questions (FAQs) that IT professionals have about deploying and customizing Windows® SharePoint™ Services. The questions and answers will be of specific interest to system architects, implementers, and operations staff who are evaluating or deploying Windows SharePoint Services in a medium- or large-size organization.
Built on the Windows Server 2003 platform, Microsoft Windows SharePoint Services makes it easy for IT professionals to implement a dependable, scaleable infrastructure that enables teams to create Web sites for information sharing and document collaboration, using straightforward administrative tools and services. In addition, Windows SharePoint Services provides the following benefits to IT departments and administrators:
Reliable and scalable platform. Whether deployed on a single server supporting a small organization or in a large enterprise with tens of thousands of sites and thousands of users, Windows SharePoint Services provides a cost-effective, scaleable collaboration and information sharing solution, without compromising system reliability, security, or performance.
Powerful administrative control and security. Windows SharePoint Services enables IT Professionals to establish a foundation that can help to reduce administration effort and total cost of ownership while providing exceptional support for present and future team and project collaboration needs.
Better management and consolidation of corporate file shares. Storing files in Windows SharePoint Services document libraries provides many advantages over storing documents in network file servers. Windows SharePoint Services supplies Web sites with document storage and retrieval with check-in and check-out functionality, version history, custom metadata, and flexible, customizable views. Users can find and share data, with the added assurance that data will not be lost. Overall administration and associated operating costs are lowered.
Easy to Extend and Integrate. Windows SharePoint Services provides IT professionals with a collaboration environment that is easy to extend and that can connect disparate applications, solutions, and systems into an integrated platform with less administrative time and effort.
Rich Partner Ecosystem. Broad adoption of Windows SharePoint Services and the resulting demand for related applications and services has led to the development of an active and growing SharePoint partner ecosystem including ISVs, system integrators, educators, and publications.
Rapid user adoption. Rich out-of-the-box functionality combined with Windows SharePoint Services integration with everyday tools such as web browsers, Microsoft Office applications, e-mail, and instant messaging enable users to begin using Windows SharePoint Services quickly and easily, reducing training needs as well as helpdesk and IT support requests.
Note: The following experiences, lessons learned, and best practices are not intended to serve as a comprehensive or step-by-step guide for deploying and customizing Windows SharePoint Services. Microsoft is sharing this information with IT professionals to assist them in deploying Windows SharePoint Services in their own environments. Additional information is available at http://www.microsoft.com/office/sharepoint. For security reasons, the names of forests, domains, and other internal resources used in this white paper do not represent real names used and are intended for illustration purposes only.
Planning
Establish Department Representatives and Internal User Groups Early
Several Windows SharePoint Services customers stressed the need to create internal user groups early in the planning phase and continue to reinforce their roles during the deployment and operations phases. The most successful approaches involved gathering input and feedback from the user group during the planning phase but also included training the department representatives so they were able to communicate the project’s goals, objectives, and plans to their peers in their departments. These organizations found that the overall project was better understood and accepted when a member of each department was able to "bring the messages back" from the core project team to their own department (rather than having only the core project team broadcast updates to the whole organization).
Capacity Planning
Based on the experiences of organizations who have deployed Windows SharePoint Services and enabled SharePoint self-service site creation, plan for "as much storage as you can afford" is the advice of one customer given their high SharePoint site growth rate.
More pragmatically, the key factors are: 1) SharePoint site creation growth rates, 2) typical SharePoint site storage usage, and 3) SharePoint database "white space".
Customers found that site creation growth rates were affected by the following factors:
Number of SharePoint users
Number of people authorized to create SharePoint sites, either as site or site-collection administrators, and (in cases where self-service site creation is enabled) the number of individual SharePoint users with a need to create new sites
A collaboration culture of the organization that encourages employees to use SharePoint sites rather than e-mail or file servers.
The other key factor – storage usage per SharePoint site – varies greatly depending on the purpose of the site. Based on experience, an average of 50 MB per site can be used for capacity planning purposes.
Database "white space" is unused database storage (database records) that exists after a SharePoint site is deleted. In a large, dynamic environment where sites are being created on a regular basis (perhaps supported by SharePoint self-service site creation and site confirmation and automatic deletion features), white space may account for 25 to 50 percent of the total SharePoint database usage.
SharePoint Site Hierarchy Planning
A large financial customer’s recommendation is to use a relatively flat SharePoint site hierarchy consisting primarily of top-level sites, and to use the Links Web Part to implement a virtual hierarchy or network of links that connect one site to another. The advantage of this approach is the URLs in the Links list are easier to change when the intended hierarchical or network relationships between two sites need to change. Alternatively, changing the location of a site in the site hierarchy in Windows SharePoint Services requires a backup and restore operation to be performed using the Smigrate.exe administration tool. One disadvantage of this approach is access controls based on SharePoint site groups can be easier to manage when the security model enables a subsite to inherit access controls from a parent site.
Migrating from SharePoint Team Services 1.0
For many customers, their deployment of SharePoint Products and Technologies began in 2001 with the implementation of SharePoint Team Services 1.0, the predecessor product to Windows SharePoint Services.
To migrate SharePoint Team Services "subwebs" to Windows SharePoint sites, most customers used the recommended Smigrate.exe tool to migrate subwebs to top-level Windows SharePoint Services sites. Smigrate.exe is used twice: first to first back up each subweb to be migrated and then to restore the subweb structure, content, and access rights to a Windows SharePoint Services site collection.
Some customers with hundreds or thousands of subwebs to be migrated also used scripts to automate the backup and subsequently restore a list of subwebs read from a text file or Microsoft Office Excel® spreadsheet.
Specific customer best practices for using Smigrate.exe include:
If all subwebs are migrated to become top-level sites in Windows SharePoint Services, ensure that there are not "URL collisions"; that is, that no two subwebs from the SharePoint Team Services subwebs hierarchy will have the same URL when they are migrated to become top-level sites in Windows SharePoint Services.
Increase the Windows page file size to 1 GB.
Increase the Internet Information Server (IIS) timeout value to its maximum.
Ensure the quota limits for the target SharePoint site collection are large enough to accommodate the content in the largest subwebs.
Similarly, make sure the Windows SharePoint Services maximum file size is large enough to accommodate the largest individual files.
Review the blocked file type list for the site collection to ensure that there are no blocked file types that need to be removed or added to the list based on your organization’s needs.
Set the maximum number of Windows SharePoint Services alerts to the maximum.
After the migration of a subweb to a SharePoint site, set the subweb access rights to read-only so that users are no longer allowed to update the old subweb.
Content Migration
Windows SharePoint Services sites and document libraries provide a document storage solution that is more secure and manageable, and provides richer document management functionality than traditional file servers.
One of the most common decisions a SharePoint Windows Services customer faces is whether to adopt a centralized content migration, or a decentralized, department-level strategy.
Intuitively, a more centrally managed approach would seem to be the best way to manage very large content migration projects. In reality, the larger the amount of source content to be migrated to Windows SharePoint Services, the greater the need for a division- or department-level content migration strategy. This is because the knowledge to decide what should be migrated and just as importantly, what does not need to be migrated is frequently only known by the original creators and users of the content. This reasoning also applies to how the content should be organized as a hierarchy of sites, document libraries and document library folders in the target SharePoint environment.
Technically, some of the most basic issues that a content migration project needs to plan for include:
SharePoint URL naming conventions and restrictions on the characters that can appear in a site
Document library and folder name
Maximum length of a name as well as the overall maximum length of the URL.
Extranet Deployment of Windows SharePoint Services
The key lesson learned for customers deploying Windows SharePoint Services as an extranet solution using HTTPS (secure hypertext transfer protocol) is the need to deploy a separate IIS virtual server for each unique HTTPS domain name space. Aside from this requirement, deploying Windows SharePoint Services as an extranet solution is virtually the same as deploying a conventional ASP.NET application.
Deployment
Branding and Customization
When deploying Windows SharePoint Services, customers find themselves answering questions similar to those when they deployed their first intranets. For example,
Should all SharePoint sites have the same "look and feel" within a department, the division, or across the entire company?
How much and what types of customization should be allowed?
At what level in the organization should these decisions be made?
Windows SharePoint Services provides a series of site and list templates for the most common list and layout configurations. As part of the overall planning and deployment process, many customers have chosen to create a model SharePoint site using an existing site template, customize it to meet their organizational standards, and then save the site as a standard template to be used for the creation of all new SharePoint sites.
Depending on the culture and business needs of the organization, some companies have also chosen to allow site administrators to use all available customization options including custom style sheets, page layouts (Web Part zones), and Web Parts as well as deeper HTML-level customizations using Microsoft Office FrontPage 2003. Others have chosen more controlled policies that disable these customizations.
Some SharePoint sites use high levels of customization including custom in-house or third-party Web Parts while others may require more stringent security policies. These sites are often deployed using their own independent IIS virtual servers or their own physical or virtual Windows Server 2003 servers.
In general, Microsoft has found that customers have often chosen to use more controlled levels of branding and customization that are compatible with their second- or third-generation intranet strategies and the advice of their internal user groups.
Active Directory Considerations
As expected, enterprise customers deploy Windows SharePoint Services in Active Directory domain mode versus Active Directory account creation mode; the latter being more commonly used for extranet or hosted Windows SharePoint Services deployments.
Customers who have deployed large numbers of domains within their organization have found they need to plan more carefully to insure there are no issues related to user name "collisions".
More pragmatic considerations include:
Making sure each Active Directory user has a valid and current e-mail address (a surprisingly common situation for a small percentage of an organization’s Active Directory accounts) and that all e-mail accounts use the same standards for e-mail domains (for example, top-level domain only or top-level domain plus one or more sub-level domains).
Being aware that some users have more than one Active Directory account; either a current account and one or more dormant accounts.
Training
Microsoft customers that deploy Windows SharePoint Services for the first time typically provide training for four key groups of people:
IT architects and implementers responsible for planning and undertaking the technical deployment of Windows SharePoint Services
IT operations staff
IT help desk staff
End users
Separate training programs are required for each group of people. Many organizations have found it effective to use local department representatives to deliver end-user training, given the familiar browser-based user interface of Windows SharePoint Services and its compatibility with the Microsoft Office System desktop productivity applications such as Microsoft Word and Microsoft Excel.
Support
Deliver Support Based on a Multi-Level Help Desk Infrastructure
The most important recommendation, based on customer experiences in deploying Windows SharePoint Services, is to get an early start in building a multi-level help desk infrastructure; whether for Windows SharePoint Services specifically or for the organization’s entire IT infrastructure. End users tend to adopt Windows SharePoint Services very quickly. The earlier an organization’s help deck support team can begin being training and gain experience with Windows SharePoint Services, the smoother the overall deployment will be.
A typical multi-level help desk infrastructure includes:
Level 1 direct end-user support for basic Windows SharePoint Services features, as well as answers to the most common "Top 20" questions.
Level 2 application support to address more sophisticated "how to use …" questions well as topics such as how best to migrate content into Windows SharePoint Services.
Level 3 operations support to address issues related to operational issues such as uptime, service outages, backups, and restore requests.
Level 4 platform support is resolved using Microsoft Customer Support Services or a partner support service.
Be prepared for the success of Windows SharePoint Services in your organization. If you have a large number of employees, the rapid adoption rates experienced by other large customers indicate that it is important to have an efficient help desk infrastructure in place early.
Operations
Backup and Restore Strategies
The backup and restore strategies for one large financial services company was designed to support an environment with approximately 1,600 SharePoint sites, a maximum site size (site quota) of 500 MB, and a SQL Server 2000 cluster with approximately 15 GB of dedicated storage area network (SAN) resources.
In addition, this customer also uses SharePoint Site User Confirmation and Automatic Deletion features to help control the number of SharePoint sites that are no longer used. This affects the strategy used for backup and restore because when sites are automatically deleted: it can result in a higher frequency of site restore requests. Best practices involving site-user confirmation and automatic deletion are described in the next section.
One recommendation from the field is to perform nightly backups using a 90-day retention period for the backup media and then restore a site collection on an as-required basis to recover a particular SharePoint site.
SharePoint Site User Confirmation and Automatic Site Deletion
In Windows SharePoint Services, new administrative options allow you to automatically send notices to site owners requiring them to confirm that their sites are in use. Windows SharePoint Services can also be configured to delete unconfirmed sites automatically. These features provide a way to control the number of unused Web sites on a server.
Web sites based on Microsoft Windows SharePoint Services may become inactive for many reasons. Perhaps a site was created for documents relating to a project that is finished, or perhaps a user was evaluating Windows SharePoint Services and created a site that he or she no longer needs. Because inactive sites take up space on the servers, it's important to check with site owners to see if their sites are still needed or have become inactive.
Site-use confirmation works like alerts for your users' sites. When sites are created, they are added to the database and are logged as active sites. After a specified time as defined by the administrator, the site owners are sent an e-mail notification asking the owners to either reactivate or delete their unused Web sites. The notification e-mail text contains links to confirm that a site is active or to delete a site. After the notification is sent, there are three possible outcomes:
If a site is in use, the site owner will click a link to confirm that the site is active and preserve the site. That will restart the timer and the owner will be notified again after the same time period.
If a site is not in use, the site owner can either delete the site by following instructions in the notification e-mail, or do nothing. The site owner continues to receive periodic e-mail notifications (over a period defined by the administrator) until use is confirmed or the site is deleted.
If a site is not in use, and you have turned on the automatic deletion feature, the site owner is queried a specific number of times (as determined by the administrator), and if use is not confirmed, the site is automatically deleted.
Automatic deletion is an advanced administrative feature that can delete unneeded sites without any administrative intervention and without any backup mechanism. To prevent a site from being deleted without any notification, you must turn on site-use confirmation before you can turn on automatic deletion. Also, the site owner must always be sent at least two confirmation notices before a site can be deleted. In addition to these default safeguards, you should also consider the following best practices:
Require a secondary contact when sites are created.
Set reasonable intervals between confirmations and before automatic deletion.
Back up Web sites regularly, so you can restore a recent copy if a site is unintentionally deleted.
Conclusions
Windows SharePoint Services enables organizations to deploy and customize a rich environment for effective information sharing and collaboration that is integrated with Microsoft Office, enables teams to stay connected and productive, and increases the efficiency of team processes.
IT professionals can improve the planning and deployment of Windows SharePoint Services in their organizations by following the lessons learned and best practices documented in this white paper. These are based on the experiences of Microsoft customers who have deployed Windows SharePoint Services.
Related Links
For more information on Microsoft SharePoint Products and Technologies, please visit the following Web sites.
Technical Resources
Coexistence and Interoperability Guide for SharePoint Products and Technologieshttp://office.microsoft.com/en-us/assistance/HA011607771033.aspx
Microsoft Developers Network (MSDN) Developer Center for Microsoft SharePoint Products and Technologieshttp://msdn.microsoft.com/sharepoint
Microsoft TechNet SharePoint Portal Server 2003 Technical Resourceshttp://www.microsoft.com/technet/prodtechnol/office/sps2003/default.mspx
Microsoft TechNet Windows SharePoint Services Technical Resourceshttp://www.microsoft.com/technet/prodtechnol/windowsserver2003/technologies/sharepoint/default.mspx
Microsoft TechNet Downloadable Resources for Microsoft SharePoint Products and Technologieshttp://www.microsoft.com/technet/downloads/sharepnt.mspx
Microsoft IT Showcase Deployment White Papershttp://www.microsoft.com/itshowcase
WSS FAQ Web Sitehttp://wss.collutions.com/default.aspx
Product Information
SharePoint Products and Technologies product Web sitehttp://www.microsoft.com/sharepoint
Windows SharePoint Services and SharePoint Portal Server 2003: Product Informationhttp://www.microsoft.com/office/sharepoint/prodinfo/relationship.mspx
Benefits of Microsoft Office SharePoint Portal Server 2003http://www.microsoft.com/office/sharepoint/prodinfo/benefits.mspx
SharePoint Portal Server 2003 Customer Evaluation Guidehttp://www.microsoft.com/office/sharepoint/prodinfo/guide.mspx
Implementing Rich Collaboration Infrastructure Using Windows SharePoint Services and SharePoint Portal Server 2003http://www.microsoft.com/sharepoint/evaluationoverview.asp
Microsoft Web Enterprise Portalhttp://www.microsoft.com/downloads/details.aspx?FamilyID=ac26898b-6893-48b9-8ec0-667f1ba22d6b&DisplayLang=en
Analyst and Research Reports
Process Goldmine: Microsoft Office System Integrated Solutions Deliver Business Value, Navigant Consulting Inc., September 2003.http://www.microsoft.com/office/business/value.mspx
http://www.microsoft.com/downloads/details.aspx?familyid=3d1fa469-0064-4054-9c1a-a6d8c8afce2b&displaylang=en
Deployment and Customization Best Practices for Windows SharePoint Services
Microsoft Corporation
Published: September 2005
Abstract
This document provides answers to some of the most frequently asked questions (FAQs) that IT professionals have about deploying and customizing Windows® SharePoint™ Services. The questions and answers will be of specific interest to system architects, implementers, and operations staff who are evaluating or deploying Windows SharePoint Services in a medium- or large-size organization.
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 White Paper 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, email address, logo, person, place, or event is intended or should be inferred.
© 2005 Microsoft Corporation. All rights reserved.
Microsoft, Active Directory, SharePoint, Windows, the Windows logo, Windows Server, and Windows Server System 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
Introduction 1
Planning 2
Establish Department Representatives and Internal user Groups Early 2
Capacity Planning 2
SharePoint Site Hierarchy Planning 2
Migrating from SharePoint Team Services 1.0 3
Content Migration 3
Extranet Deployment of Windows SharePoint Services 4
Deployment 5
Branding and Customization 5
Active Directory Considerations 5
Training 6
Support 7
Deliver Support Based on a Multi-Level Help Desk Infrastructure 7
Operations 8
Backup and Restore Strategies 8
SharePoint Site Use Confirmation and Automatic Site Deletion 8
Conclusions 10
Related Links 11
Technical Resources 11
Product Information 11
Analyst and Research Reports 12
Introduction
This document provides answers to some of the most frequently asked questions (FAQs) that IT professionals have about deploying and customizing Windows® SharePoint™ Services. The questions and answers will be of specific interest to system architects, implementers, and operations staff who are evaluating or deploying Windows SharePoint Services in a medium- or large-size organization.
Built on the Windows Server 2003 platform, Microsoft Windows SharePoint Services makes it easy for IT professionals to implement a dependable, scaleable infrastructure that enables teams to create Web sites for information sharing and document collaboration, using straightforward administrative tools and services. In addition, Windows SharePoint Services provides the following benefits to IT departments and administrators:
Reliable and scalable platform. Whether deployed on a single server supporting a small organization or in a large enterprise with tens of thousands of sites and thousands of users, Windows SharePoint Services provides a cost-effective, scaleable collaboration and information sharing solution, without compromising system reliability, security, or performance.
Powerful administrative control and security. Windows SharePoint Services enables IT Professionals to establish a foundation that can help to reduce administration effort and total cost of ownership while providing exceptional support for present and future team and project collaboration needs.
Better management and consolidation of corporate file shares. Storing files in Windows SharePoint Services document libraries provides many advantages over storing documents in network file servers. Windows SharePoint Services supplies Web sites with document storage and retrieval with check-in and check-out functionality, version history, custom metadata, and flexible, customizable views. Users can find and share data, with the added assurance that data will not be lost. Overall administration and associated operating costs are lowered.
Easy to Extend and Integrate. Windows SharePoint Services provides IT professionals with a collaboration environment that is easy to extend and that can connect disparate applications, solutions, and systems into an integrated platform with less administrative time and effort.
Rich Partner Ecosystem. Broad adoption of Windows SharePoint Services and the resulting demand for related applications and services has led to the development of an active and growing SharePoint partner ecosystem including ISVs, system integrators, educators, and publications.
Rapid user adoption. Rich out-of-the-box functionality combined with Windows SharePoint Services integration with everyday tools such as web browsers, Microsoft Office applications, e-mail, and instant messaging enable users to begin using Windows SharePoint Services quickly and easily, reducing training needs as well as helpdesk and IT support requests.
Note: The following experiences, lessons learned, and best practices are not intended to serve as a comprehensive or step-by-step guide for deploying and customizing Windows SharePoint Services. Microsoft is sharing this information with IT professionals to assist them in deploying Windows SharePoint Services in their own environments. Additional information is available at http://www.microsoft.com/office/sharepoint. For security reasons, the names of forests, domains, and other internal resources used in this white paper do not represent real names used and are intended for illustration purposes only.
Planning
Establish Department Representatives and Internal User Groups Early
Several Windows SharePoint Services customers stressed the need to create internal user groups early in the planning phase and continue to reinforce their roles during the deployment and operations phases. The most successful approaches involved gathering input and feedback from the user group during the planning phase but also included training the department representatives so they were able to communicate the project’s goals, objectives, and plans to their peers in their departments. These organizations found that the overall project was better understood and accepted when a member of each department was able to "bring the messages back" from the core project team to their own department (rather than having only the core project team broadcast updates to the whole organization).
Capacity Planning
Based on the experiences of organizations who have deployed Windows SharePoint Services and enabled SharePoint self-service site creation, plan for "as much storage as you can afford" is the advice of one customer given their high SharePoint site growth rate.
More pragmatically, the key factors are: 1) SharePoint site creation growth rates, 2) typical SharePoint site storage usage, and 3) SharePoint database "white space".
Customers found that site creation growth rates were affected by the following factors:
Number of SharePoint users
Number of people authorized to create SharePoint sites, either as site or site-collection administrators, and (in cases where self-service site creation is enabled) the number of individual SharePoint users with a need to create new sites
A collaboration culture of the organization that encourages employees to use SharePoint sites rather than e-mail or file servers.
The other key factor – storage usage per SharePoint site – varies greatly depending on the purpose of the site. Based on experience, an average of 50 MB per site can be used for capacity planning purposes.
Database "white space" is unused database storage (database records) that exists after a SharePoint site is deleted. In a large, dynamic environment where sites are being created on a regular basis (perhaps supported by SharePoint self-service site creation and site confirmation and automatic deletion features), white space may account for 25 to 50 percent of the total SharePoint database usage.
SharePoint Site Hierarchy Planning
A large financial customer’s recommendation is to use a relatively flat SharePoint site hierarchy consisting primarily of top-level sites, and to use the Links Web Part to implement a virtual hierarchy or network of links that connect one site to another. The advantage of this approach is the URLs in the Links list are easier to change when the intended hierarchical or network relationships between two sites need to change. Alternatively, changing the location of a site in the site hierarchy in Windows SharePoint Services requires a backup and restore operation to be performed using the Smigrate.exe administration tool. One disadvantage of this approach is access controls based on SharePoint site groups can be easier to manage when the security model enables a subsite to inherit access controls from a parent site.
Migrating from SharePoint Team Services 1.0
For many customers, their deployment of SharePoint Products and Technologies began in 2001 with the implementation of SharePoint Team Services 1.0, the predecessor product to Windows SharePoint Services.
To migrate SharePoint Team Services "subwebs" to Windows SharePoint sites, most customers used the recommended Smigrate.exe tool to migrate subwebs to top-level Windows SharePoint Services sites. Smigrate.exe is used twice: first to first back up each subweb to be migrated and then to restore the subweb structure, content, and access rights to a Windows SharePoint Services site collection.
Some customers with hundreds or thousands of subwebs to be migrated also used scripts to automate the backup and subsequently restore a list of subwebs read from a text file or Microsoft Office Excel® spreadsheet.
Specific customer best practices for using Smigrate.exe include:
If all subwebs are migrated to become top-level sites in Windows SharePoint Services, ensure that there are not "URL collisions"; that is, that no two subwebs from the SharePoint Team Services subwebs hierarchy will have the same URL when they are migrated to become top-level sites in Windows SharePoint Services.
Increase the Windows page file size to 1 GB.
Increase the Internet Information Server (IIS) timeout value to its maximum.
Ensure the quota limits for the target SharePoint site collection are large enough to accommodate the content in the largest subwebs.
Similarly, make sure the Windows SharePoint Services maximum file size is large enough to accommodate the largest individual files.
Review the blocked file type list for the site collection to ensure that there are no blocked file types that need to be removed or added to the list based on your organization’s needs.
Set the maximum number of Windows SharePoint Services alerts to the maximum.
After the migration of a subweb to a SharePoint site, set the subweb access rights to read-only so that users are no longer allowed to update the old subweb.
Content Migration
Windows SharePoint Services sites and document libraries provide a document storage solution that is more secure and manageable, and provides richer document management functionality than traditional file servers.
One of the most common decisions a SharePoint Windows Services customer faces is whether to adopt a centralized content migration, or a decentralized, department-level strategy.
Intuitively, a more centrally managed approach would seem to be the best way to manage very large content migration projects. In reality, the larger the amount of source content to be migrated to Windows SharePoint Services, the greater the need for a division- or department-level content migration strategy. This is because the knowledge to decide what should be migrated and just as importantly, what does not need to be migrated is frequently only known by the original creators and users of the content. This reasoning also applies to how the content should be organized as a hierarchy of sites, document libraries and document library folders in the target SharePoint environment.
Technically, some of the most basic issues that a content migration project needs to plan for include:
SharePoint URL naming conventions and restrictions on the characters that can appear in a site
Document library and folder name
Maximum length of a name as well as the overall maximum length of the URL.
Extranet Deployment of Windows SharePoint Services
The key lesson learned for customers deploying Windows SharePoint Services as an extranet solution using HTTPS (secure hypertext transfer protocol) is the need to deploy a separate IIS virtual server for each unique HTTPS domain name space. Aside from this requirement, deploying Windows SharePoint Services as an extranet solution is virtually the same as deploying a conventional ASP.NET application.
Deployment
Branding and Customization
When deploying Windows SharePoint Services, customers find themselves answering questions similar to those when they deployed their first intranets. For example,
Should all SharePoint sites have the same "look and feel" within a department, the division, or across the entire company?
How much and what types of customization should be allowed?
At what level in the organization should these decisions be made?
Windows SharePoint Services provides a series of site and list templates for the most common list and layout configurations. As part of the overall planning and deployment process, many customers have chosen to create a model SharePoint site using an existing site template, customize it to meet their organizational standards, and then save the site as a standard template to be used for the creation of all new SharePoint sites.
Depending on the culture and business needs of the organization, some companies have also chosen to allow site administrators to use all available customization options including custom style sheets, page layouts (Web Part zones), and Web Parts as well as deeper HTML-level customizations using Microsoft Office FrontPage 2003. Others have chosen more controlled policies that disable these customizations.
Some SharePoint sites use high levels of customization including custom in-house or third-party Web Parts while others may require more stringent security policies. These sites are often deployed using their own independent IIS virtual servers or their own physical or virtual Windows Server 2003 servers.
In general, Microsoft has found that customers have often chosen to use more controlled levels of branding and customization that are compatible with their second- or third-generation intranet strategies and the advice of their internal user groups.
Active Directory Considerations
As expected, enterprise customers deploy Windows SharePoint Services in Active Directory domain mode versus Active Directory account creation mode; the latter being more commonly used for extranet or hosted Windows SharePoint Services deployments.
Customers who have deployed large numbers of domains within their organization have found they need to plan more carefully to insure there are no issues related to user name "collisions".
More pragmatic considerations include:
Making sure each Active Directory user has a valid and current e-mail address (a surprisingly common situation for a small percentage of an organization’s Active Directory accounts) and that all e-mail accounts use the same standards for e-mail domains (for example, top-level domain only or top-level domain plus one or more sub-level domains).
Being aware that some users have more than one Active Directory account; either a current account and one or more dormant accounts.
Training
Microsoft customers that deploy Windows SharePoint Services for the first time typically provide training for four key groups of people:
IT architects and implementers responsible for planning and undertaking the technical deployment of Windows SharePoint Services
IT operations staff
IT help desk staff
End users
Separate training programs are required for each group of people. Many organizations have found it effective to use local department representatives to deliver end-user training, given the familiar browser-based user interface of Windows SharePoint Services and its compatibility with the Microsoft Office System desktop productivity applications such as Microsoft Word and Microsoft Excel.
Support
Deliver Support Based on a Multi-Level Help Desk Infrastructure
The most important recommendation, based on customer experiences in deploying Windows SharePoint Services, is to get an early start in building a multi-level help desk infrastructure; whether for Windows SharePoint Services specifically or for the organization’s entire IT infrastructure. End users tend to adopt Windows SharePoint Services very quickly. The earlier an organization’s help deck support team can begin being training and gain experience with Windows SharePoint Services, the smoother the overall deployment will be.
A typical multi-level help desk infrastructure includes:
Level 1 direct end-user support for basic Windows SharePoint Services features, as well as answers to the most common "Top 20" questions.
Level 2 application support to address more sophisticated "how to use …" questions well as topics such as how best to migrate content into Windows SharePoint Services.
Level 3 operations support to address issues related to operational issues such as uptime, service outages, backups, and restore requests.
Level 4 platform support is resolved using Microsoft Customer Support Services or a partner support service.
Be prepared for the success of Windows SharePoint Services in your organization. If you have a large number of employees, the rapid adoption rates experienced by other large customers indicate that it is important to have an efficient help desk infrastructure in place early.
Operations
Backup and Restore Strategies
The backup and restore strategies for one large financial services company was designed to support an environment with approximately 1,600 SharePoint sites, a maximum site size (site quota) of 500 MB, and a SQL Server 2000 cluster with approximately 15 GB of dedicated storage area network (SAN) resources.
In addition, this customer also uses SharePoint Site User Confirmation and Automatic Deletion features to help control the number of SharePoint sites that are no longer used. This affects the strategy used for backup and restore because when sites are automatically deleted: it can result in a higher frequency of site restore requests. Best practices involving site-user confirmation and automatic deletion are described in the next section.
One recommendation from the field is to perform nightly backups using a 90-day retention period for the backup media and then restore a site collection on an as-required basis to recover a particular SharePoint site.
SharePoint Site User Confirmation and Automatic Site Deletion
In Windows SharePoint Services, new administrative options allow you to automatically send notices to site owners requiring them to confirm that their sites are in use. Windows SharePoint Services can also be configured to delete unconfirmed sites automatically. These features provide a way to control the number of unused Web sites on a server.
Web sites based on Microsoft Windows SharePoint Services may become inactive for many reasons. Perhaps a site was created for documents relating to a project that is finished, or perhaps a user was evaluating Windows SharePoint Services and created a site that he or she no longer needs. Because inactive sites take up space on the servers, it's important to check with site owners to see if their sites are still needed or have become inactive.
Site-use confirmation works like alerts for your users' sites. When sites are created, they are added to the database and are logged as active sites. After a specified time as defined by the administrator, the site owners are sent an e-mail notification asking the owners to either reactivate or delete their unused Web sites. The notification e-mail text contains links to confirm that a site is active or to delete a site. After the notification is sent, there are three possible outcomes:
If a site is in use, the site owner will click a link to confirm that the site is active and preserve the site. That will restart the timer and the owner will be notified again after the same time period.
If a site is not in use, the site owner can either delete the site by following instructions in the notification e-mail, or do nothing. The site owner continues to receive periodic e-mail notifications (over a period defined by the administrator) until use is confirmed or the site is deleted.
If a site is not in use, and you have turned on the automatic deletion feature, the site owner is queried a specific number of times (as determined by the administrator), and if use is not confirmed, the site is automatically deleted.
Automatic deletion is an advanced administrative feature that can delete unneeded sites without any administrative intervention and without any backup mechanism. To prevent a site from being deleted without any notification, you must turn on site-use confirmation before you can turn on automatic deletion. Also, the site owner must always be sent at least two confirmation notices before a site can be deleted. In addition to these default safeguards, you should also consider the following best practices:
Require a secondary contact when sites are created.
Set reasonable intervals between confirmations and before automatic deletion.
Back up Web sites regularly, so you can restore a recent copy if a site is unintentionally deleted.
Conclusions
Windows SharePoint Services enables organizations to deploy and customize a rich environment for effective information sharing and collaboration that is integrated with Microsoft Office, enables teams to stay connected and productive, and increases the efficiency of team processes.
IT professionals can improve the planning and deployment of Windows SharePoint Services in their organizations by following the lessons learned and best practices documented in this white paper. These are based on the experiences of Microsoft customers who have deployed Windows SharePoint Services.
Related Links
For more information on Microsoft SharePoint Products and Technologies, please visit the following Web sites.
Technical Resources
Coexistence and Interoperability Guide for SharePoint Products and Technologieshttp://office.microsoft.com/en-us/assistance/HA011607771033.aspx
Microsoft Developers Network (MSDN) Developer Center for Microsoft SharePoint Products and Technologieshttp://msdn.microsoft.com/sharepoint
Microsoft TechNet SharePoint Portal Server 2003 Technical Resourceshttp://www.microsoft.com/technet/prodtechnol/office/sps2003/default.mspx
Microsoft TechNet Windows SharePoint Services Technical Resourceshttp://www.microsoft.com/technet/prodtechnol/windowsserver2003/technologies/sharepoint/default.mspx
Microsoft TechNet Downloadable Resources for Microsoft SharePoint Products and Technologieshttp://www.microsoft.com/technet/downloads/sharepnt.mspx
Microsoft IT Showcase Deployment White Papershttp://www.microsoft.com/itshowcase
WSS FAQ Web Sitehttp://wss.collutions.com/default.aspx
Product Information
SharePoint Products and Technologies product Web sitehttp://www.microsoft.com/sharepoint
Windows SharePoint Services and SharePoint Portal Server 2003: Product Informationhttp://www.microsoft.com/office/sharepoint/prodinfo/relationship.mspx
Benefits of Microsoft Office SharePoint Portal Server 2003http://www.microsoft.com/office/sharepoint/prodinfo/benefits.mspx
SharePoint Portal Server 2003 Customer Evaluation Guidehttp://www.microsoft.com/office/sharepoint/prodinfo/guide.mspx
Implementing Rich Collaboration Infrastructure Using Windows SharePoint Services and SharePoint Portal Server 2003http://www.microsoft.com/sharepoint/evaluationoverview.asp
Microsoft Web Enterprise Portalhttp://www.microsoft.com/downloads/details.aspx?FamilyID=ac26898b-6893-48b9-8ec0-667f1ba22d6b&DisplayLang=en
Analyst and Research Reports
Process Goldmine: Microsoft Office System Integrated Solutions Deliver Business Value, Navigant Consulting Inc., September 2003.http://www.microsoft.com/office/business/value.mspx
Subscribe to:
Posts (Atom)