Purpose of Article

The purpose of the document is to outline EPC Group best practice recommendations from an “In the Trenches” SharePoint Consulting perspective for Enterprise SharePoint 2010 Environments. I have also included supportable limitations outlined by Microsoft as well as best practice information that pertains to SharePoint Server 2010. As I have been working with SharePoint from back in the "Tahoe" days and have spent my entire career working around this product I very much enjoy sharing my thoughts and experiences around this extremely powerful platform. (Note: Always implement it as a Hybrid)

Farms

Farms should be set up with the following server minimum requirements.

Web/Application Servers

The Web Application Servers at each location should be used primarily for SharePoint. The server hosting the SharePoint components must have the following minimum software configuration:

Component	Minimum requirement
Processor	64-bit, four cores
RAM	4 GB for developer or evaluation use 8 GB for single server and multiple server farm installation for production use
Hard disk	80 GB for system drive For production use, you need additional free disk space for day-to-day operations. Maintain twice as much free space as you have RAM for production environments.
Software	·         The 64-bit edition of Windows Server 2008 Standard ·         Microsoft Office SharePoint 2010 You must download an update for Windows Server 2008 before you run Setup. ·         Web Server (IIS) role ·         Application Server role ·         Microsoft .NET Framework version 3.5 SP1 ·         Microsoft Sync Framework Runtime v1.0 (x64) ·         Microsoft Filter Pack 2.0 ·         Microsoft Chart Controls for the Microsoft .NET Framework 3.5 ·         Windows PowerShell 2.0 ·         SQL Server 2008 Native Client ·         Microsoft SQL Server 2008 Analysis Services ADOMD.NET ·         ADO.NET Data Services Update for .NET Framework 3.5 SP1 Windows Identity Foundation (WIF)

Additional Web Server recommendations

·         A Web Application Server should have no more than 10 Web Application Pools.

·         A web site should have no more than 250,000 sites per site collection.

·         The maximum number of zones that can be set up for a Farm Web Site is 5.

·         A SharePoint Farm cannot contain more than 20 managed paths per web application.

·         The cache size set for InfoPath Forms service should not be over 300mb.

·         Application Pools on the web application servers should be recycled at least once during off hours.

·         All sites should utilize Quotas to keep the size of the sites at a manageable size.

Database Servers

SharePoint requires SQL databases and prefers Windows Authentication. SharePoint is unaware of any non-SharePoint databases on the SQL server. However it is recommended that the SharePoint environment Database reside on a Dedicated SQL Server instance.

SharePoint requires SQL databases and prefers Windows Authentication. SharePoint is unaware of any non-SharePoint databases on the SQL server.

Component	Minimum requirement
Processor	64-bit, four cores for small deployments 64-bit, eight cores for medium deployments
RAM	8 GB for small deployments 16 GB for medium deployments These values are higher than those recommended as the minimum values for SQL Server because of the distribution of data required for a SharePoint Products 2010 environment.
Hard disk	80 GB for system drive For Production, it is recommended that there are 4 additional disks available for Data, Logs, System DB and System Use. For production use, you need additional free disk space for day-to-day operations. Maintain twice as much free space as you have RAM for production environments.
Software	·         The 64-bit edition of Windows Server 2008 Enterprise or better. ·         The 64-bit edition of Microsoft SQL Server 2008 or better.

 

Additional Environments

It is highly recommended that each Location maintain at least three additional environments that are not connected to the production environment. These environments are:

·         Test. Integration area to test packaged deployment packages for pre-production.

·         Pilot. Test deployment area to test applications changes.

·         Development. Environment for application development and design for change requests for new features and proof-of-concept.

It is highly recommended that the Test or Pilot environment for each location mimic the permissions, content, infrastructure setup, custom solutions, and configuration of the Production environment.

If the hardware and software are available to mimic the Production environment, these servers can be virtualized using Microsoft Hyper-V or VMware.

Development Environment

Configuring a good development environment and using the right tools are essential factors for a pleasant and productive SharePoint Server 2010 development experience. When you are developing solutions for SharePoint Server 2010, it is best to do the development on a machine that is running SharePoint Server 2010. This will allow you to take full advantage of the development and debugging improvements provided by Visual Studio 2010.

The development environment should be installed on a computer that has an X64-Capable CPU and at least 2GB of RAM available to run SharePoint Server 2010. However, it is recommended that the development machine contain at least 4GB of Ram. It is recommended that the Operating System be Windows Server 2008 SP2 or Windows Server 2008 R2. Since the basic requirements for a SharePoint Server 2010 development environment are not the same as a Production Environment, it is highly recommended that you do take the requirements listed in this Development section for creating any of the other environments.

You can use several different configurations for your SharePoint Server 2010 development environment. If your organizational budget allows, it is recommended that you use more than one machine so that you can have SharePoint Server 2010 on one machine and the SQL Server residing on another.

Additional machines add extra cost to the development process, so in many cases, using virtual machines for the development environment is preferred. You can use virtual machine tools such as Microsoft Hyper-V or VMware to accomplish installing SharePoint on a Virtual Environment.

Once the development environment has been set up with one of the recommended versions of Windows Server 2008 and SharePoint Server 2010, you can then install the Development tools. At a minimum you will need to install Visual Studio 2010, SharePoint Designer 2010 on the development machine to produce the base custom solutions needed for the environment.

Developers who have been trained according to Technology Standards should be granted administrative privileges to the development environments to ensure that all features and configurations are available while developing solutions. This is only for the development environment. 

Server Patches

It is best practice to ensure that all SharePoint Server 2010 farms are always up-to-date with the latest public service packs. It is also recommended that hotfixes are only applied in order to address specific problems which are resolved with the said hotfix.

SharePoint 2010 Security Accounts

Required accounts

The DBA needs to create SQL Server logins for the accounts that are used to access the databases for Office SharePoint Server 2010 and add them to roles.

It is recommended that SharePoint Server 2010 is installed by using least-privilege administration installation approach.

The following table describes the accounts that are used to access the databases for SharePoint Server 2010.

Account	Purpose	Requirements
SQL Server Service Account	This account is used as the service account for the following SQL Server services: MSSQLSERVER SQLSERVERAGENT If you are not using the default instance, these services will be shown as: MSSQL$InstanceName SQLAgent$InstanceName	SQL Server prompts for this account during SQL Server Setup. You have two options: Assign one of the built-in system accounts (Local System, Network Service, or Local Service) to the logon for the configurable SQL Server services. Assign a domain user account to the logon for the service. However, if you use this option you must take the additional steps required to configure Service Principal Names (SPNs) in Active Directory in order to support Kerberos authentication, which SQL Server uses.
Setup user account	The Setup user account is used to run the following: Setup on each server The SharePoint Products and Technologies Configuration Wizard The PSConfig command-line tool The Stsadm command-line tool	Domain user account Member of the Administrators group on each server on which Setup is run SQL Server login on the computer running SQL Server Member of the following SQL Server security roles: Securityadmin fixed server role dbcreator fixed server role If you run Stsadm command-line tool commands that read from or write to a database, this account must be a member of the db_owner fixed database role for the database.
Server farm account/Database access account	The Server farm account is used to: Act as the application pool identity for the SharePoint Central Administration application pool. Run the Windows SharePoint Services Timer service.

SharePoint Logging

The SharePoint Server 2010 environment might require configuration of the diagnostic logging settings after initial deployment or upgrade and possibly throughout the system’s life cycle. The guidelines in the following list can help you form best practices for the specific environment.

·         By default, diagnostic logging is configured to write logs to the same drive and partition that SharePoint Server 2010 was installed on. Because diagnostic logging can use lots of drive space and writing to the logs can affect drive performance, you should configure logging to write a drive that is different from the drive on which SharePoint Server 2010 was installed. You should also consider the connection speed to the drive that logs are written to. If verbose-level logging is configured, lots of log data is recorded. Therefore, a slow connection might result in poor log performance.

·         By default, the amount of disk space that diagnostic logging can use is not limited. Therefore, limit the disk space that logging uses to make sure that the disk does not fill up, especially if you configure logging to write verbose-level events. When the disk restriction is used up, the oldest logs are removed and new logging data information is recorded.

·         SharePoint logging should record medium to high events for normal usage days. However, if there is an issue occurring, you can configure diagnostic logging to record verbose-level events. This means that the system will log every action that SharePoint Server 2010 takes. Verbose-level logging can quickly use drive space and affect drive and server performance. You can use verbose-level logging to record a greater level of detail when you are making critical changes or troubleshooting issues and then re-configure logging to record only higher-level events after you make the change.

·         The diagnostic logs contain important data. Therefore, back them up regularly to make sure that this data is preserved. When you restrict log drive space usage, or if you keep logs for only a few days, log files are automatically deleted, starting with the oldest files first, when the threshold is met.

·         Enabling the event log flooding protection setting configures the system to detect repeating events in the Windows event log. When the same event is logged repeatedly, the repeating events are detected and suppressed until conditions return to a typical state.

SharePoint Management Tools

All Farms should actively monitor and manage the SharePoint Farms.

Several Management tools (some very powerful 3^rd party ISV tools with tremendous ROI) are available to help monitor, analyze and manage SharePoint Farms.

Capabilities and Features
Manage Permissions	·         Perform a complete security analysis across your farm. ·         Set, delete, reassign, or duplicate user permissions. ·         Analyze permissions at any level of the farm down to the document level. ·         Identify permissions levels for users in both SharePoint and Active Directory groups. ·         Clean up users who are no longer in Active Directory but are in SharePoint.
Interactive Analysis and Reporting	·         Interactive analysis, not just predefined or static reports. ·         Drill down or drill across to gain more detailed information. ·         Compare historic patterns and trends to better plan out your future requirements. ·         In-depth analysis of SharePoint Audit and Change logs.
Analyze Usage and Activity	·         Analyze activity down to the site, page, or document level. ·         Identify who is accessing which documents, including details on that activity (i.e. checking in a document, editing a document, or just viewing a document’s properties). ·         Isolate sites that are no longer needed and delete them. ·         Compare activity from the past to help anticipate the future. ·         Find sites with the most or least activity.
Analyze Content and Storage	·         Monitor and track the growth of sites for better planning. ·         Analyze Web Part usage to determine which sites are using Web Parts. ·         Ensure consistent branding and behavior: site themes, quotas, regional settings, etc.
Monitor and track the growth of sites for better planning	·         Analyze Web Part usage to determine which sites are using Web Parts. ·           ·         Ensure consistent branding and behavior: site themes, quotas, regional settings, etc.
Proactive Management	·         Automatic alerts to critical changes in your environment. ·         Know immediately when a site is added or deleted or a site’s permission settings changes. ·         Enforce policies to maintain standards. ·         Schedule any analysis or action.
Move or Copy Sites within Farms or Across Farms	·         Move site collections, sites, lists, and libraries. ·         Quickly go from test environment to production environment. ·         Reorganize your environment as part of an architecture change or a business change.
Infrastructure	·         Efficient SharePoint Management. ·         Manage and control multiple sites, site collections, and web applications from one central location. ·         Advanced search lets managers quickly and easily find sites to act upon. ·         Increase productivity with cross-site navigation and farm-wide administration. ·         Perform discovery/search functions across you farm.

 Root Cause Analysis

The following steps should be observed when performing root cause analysis of issues identified in the SharePoint Environment:

1.     Understand the issue and gather data. 

2.     Reproduce the issue if possible.  

3.     List possible root causes.   

4.     Implement change through the companies RFC process.   

5.     Monitor outcome, verify, and document.   

The Web Team should utilize multiple tools and methods for troubleshooting outages and issues that are encountered in the environments. However, the following items outline the base components to review and tools to use when trying to determine the root cause of issues.

·         Event Viewer   This tool is especially useful for understanding the underlying behavior by evaluating application errors and warnings, or investigating system events that occur before, during, and after a performance incident.

·         Dump file analysis   Analyzing dump files is an advanced troubleshooting and analysis approach that provides low-level information about critical system errors and memory dumps. It enables you to examine the data in memory and analyze the possible causes of such issues as memory leaks and invalid pointers.

·         System Monitor   Tools such as System Monitor in the Windows Server® 2003 operating system (called Performance Monitor in Windows Server 2008) are for establishing a performance baseline, tracking trends, and compiling data on resulting performance after making changes.

·         SQL Server Profiler   This tool is a graphical user interface to SQL Trace for monitoring an instance of SQL Server Database Engine or SQL Server Analysis Services. You can use this tool to evaluate SQL Server performance aspects such as query times, stored procedure run times, and deadlocks. This tool is especially useful for analyzing the underlying calls to SQL Server databases that are housed on the storage area network (SAN). This tool should only be used to troubleshoot issues and not on a daily basis.

·         Log Parser    Log Parser is one of the tools to monitor traffic, determine traffic sources distribution, and establish performance baselines. This free tool parses IIS logs, event logs, and many other kinds of structured data by using syntax similar to Structured Query Language (SQL). This should not be run against a live production system during high usage times due to performance implications.

Browser Troubleshooting Tools:  Tools such as a Fiddler or HttpWatch are helpful for measuring caching, page sizes, authentication, and general performance issues from a user browser perspective.

A SharePoint-specific knowledge base should be created to store known issues and resolution instructions that have been encountered. Once the cause of an issue has been identified, a detailed report should be created with resolution information to be added to the knowledge base. This documentation should be used to provide future training on issue resolution and response processes.

SharePoint Search

When you plan crawl schedules and content sources, 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.

·         Utilize crawler impact rules on content sources when you need to decrease the time that a crawl takes based on what the Index and Query server can handle.

·         Utilize crawler impact rules when running crawls across the wan to minimize bandwidth usage.

·         Place the Web server role on the same servers with the query role to increase performance and reduce the effects that the indexing will have on other servers in the Farm.

·         Full crawls should run at least once a week and incremental for highly visible content sources at least once a day.

·         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. It is recommended 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.

·         A Search index should not contain more than 100 million indexed items per search service application.

·         A Search index should not contain more than 10 million indexed items per index partition.

·         Incremental profile imports should occur on a nightly basis and full profile imports on a weekly basis.

Configure Kerboros Authentication

Kerberos authentication server grants a ticket in response to a client computer authentication request, if the request contains valid user credentials and a valid service principal name (SPN). The client computer then uses the ticket to access network resources. To enable Kerberos authentication, the client and server computers must have a trusted connection to the domain Key Distribution Center (KDC). The KDC distributes shared secret keys to enable encryption. The client and server computers must also be able to access Active Directory Domain Services (AD DS). For AD DS, the forest root domain is the center of Kerberos authentication referrals.

Pros:

·         Most secure Integrated Windows authentication protocol.

·         Allows delegation of client credentials.

·         Support mutual authentication of clients and servers.

·         Provides potentially better performance vs. NTLM.

·         Produces less traffic to domain controllers.

·         Produces less traffic between domain controllers.

·         Open protocol supported by many platforms and vendors.

Cons:

Requires additional configuration of infrastructure and environment to function properly.

Requires clients have connectivity to the KDC (Active Directory domain controller in Windows environments) over TCP/UDP port 88 (Kerberos), and TCP/UDP port 464 (Kerberos Change Password – Windows).

Kerberos configuration changes in SharePoint 2010 Products

Most of the basic concepts of configuring Kerberos authentication in SharePoint 2010 Products have not changed. You still need to configure service principal names and you still need to configure delegation settings on service accounts and potentially on computer accounts. However, there are a number of changes you should be aware of:

·         Constrained Delegation — Required for services which leverage the Claims to Windows Token Service. Constrained delegation is required to allow protocol transition to convert claims to windows tokens. Note that some SharePoint services and related products do not leverage the Claims to Windows Token Service. Therefore, they can use basic delegation.

·         Service Applications — In SharePoint Server 2007, the SSP services required special SPNs and server registry changes to enable delegation. In SharePoint 2010 Products service applications use claims authentication and the Claims to Windows Token service so these changes are no longer needed.

·         Windows Identity Foundation (WIF) — The WIF Claims to Windows Token Service (C2WTS) is a new service used by SharePoint to convert claims to Windows tokens for delegation scenarios.

Considerations when upgrading from SharePoint Server 2007

If you are upgrading a SharePoint 2007 farm to SharePoint 2010, there are a few things you should consider as you complete the upgrade:

·         If web applications are changing URLs, be sure to update the Service Principle Names to reflect the DNS names

·         Delete the SSP service principal names as they are no longer needed in 2010.

·         Start the Claims to Windows Token Service on the servers running service applications which require delegation (e.g. Excel Services, Visio Graphics Service).

·         Configure Kerberos constrained delegation with “use any authentication protocol” to allow Kerberos constrained delegation with the C2WTS. 

·         Ensure Kernel mode authentication is disabled in IIS.

Delegation across Domain and Forest Boundaries

The Kerberos protocol supports two types of delegation, basic (unconstrained) and constrained. Basic Kerberos delegation has the ability to cross domain boundaries in a single forest, but cannot cross a forest boundary regardless of trust relationship. Kerberos constrained delegation cannot cross domain or forest boundaries in any scenario.

Some SharePoint Services can be configured to use basic Kerberos delegation while other will require the use of constrained delegation. Any service which relies on the claims to windows token service (C2WTS) must use Kerberos constrained delegation to allow the C2WTS to use Kerberos protocol transition to translate claims into Windows credentials.

The following service applications and products require the use of the C2WTS and Kerberos constrained delegation:

·         Excel Services

·         PerformancePoint Services

·         InfoPath Forms Services

·         Visio Services

The following service applications and products are not affected by these requirements, therefore can use basic delegation if required:

·         Business Data Connectivity service and Microsoft Business Connectivity Services

·         Access Services

·         Microsoft SQL Server Reporting Services (SSRS)

·         Microsoft Project Server 2010

The following service applications do not allow delegation of client credentials therefore are not affected by these requirements:

·         Microsoft SQL Server PowerPivot for Microsoft SharePoint

Known issues

SharePoint Server 2010 can crawl web applications configured to use Kerberos authentication if those web applications are hosted on IIS virtual servers that are bound to default ports (TCP port 80 and Secure Sockets Layer (SSL) port 443). However, SharePoint Server 2010 Search cannot crawl SharePoint Server 2010 web applications that are configured to use Kerberos authentication if the web applications are hosted on IIS virtual servers that are bound to non-default ports (ports other than TCP port 80 and SSL port 443). Currently, SharePoint Server 2010 Search can only crawl SharePoint Server 2010 web applications hosted on IIS virtual servers bound to non-default ports that are configured to use either NTLM authentication or Basic authentication.

For end-user access using Kerberos authentication, if you need to deploy web applications that can only be hosted on IIS virtual servers that are bound to non-default ports, and if you want end users to get search query results, then:

·         The same web applications must be hosted on other IIS virtual servers on non-default ports.

·         The web applications must be configured to use either NTLM or Basic authentication.

·         Search Indexing must crawl the web applications using NTLM or Basic authentication.

Additional background

It is important to understand that when you use Kerberos authentication, accurate authentication functionality is dependent in part on the behavior of the client that is attempting to authenticate using Kerberos. In a SharePoint Server 2010 farm deployment using Kerberos authentication, SharePoint Server 2010 is not the client. Before you deploy a server farm running SharePoint Server 2010 using Kerberos authentication, you must understand the behavior of the following clients:

·         The browser (in the context of this example, the browser is always Internet Explorer)

·         The Microsoft .NET Framework

The browser is the client used when browsing to a Web page in a SharePoint Server 2010 web application. When SharePoint Server 2010 performs tasks such as crawling the local SharePoint Server 2010 content sources, the .NET Framework is functioning as the client.

For Kerberos authentication to work correctly, you must create SPNs in AD DS. If the services to which these SPNs correspond are listening on non-default ports, the SPNs should include port numbers. This is to ensure that the SPNs are meaningful. It is also required to prevent the creation of duplicate SPNs.

When a client attempts to access a resource using Kerberos authentication, the client must construct an SPN to be used as part of the Kerberos authentication process. If the client does not construct an SPN that matches the SPN that is configured in AD DS, Kerberos authentication will fail, usually with an "Access denied" error.

There are versions of Internet Explorer that do not construct SPNs with port numbers. If you are using SharePoint Server 2010 web applications that are bound to non-default port numbers in IIS, you might have to direct Internet Explorer to include port numbers in the SPNs that it constructs. In a farm running SharePoint Server 2010, the Central Administration web application is hosted, by default, in an IIS virtual server that is bound to a non-default port. Therefore, this section addresses both IIS Web sites that are port-bound and IIS Web sites that are bound to host-headers.

By default, in a farm running SharePoint Server 2010, the .NET Framework does not construct SPNs that contain port numbers. This is the reason why Search cannot crawl web applications using Kerberos authentication if those web applications are hosted on IIS virtual servers that are bound to non-default ports.

Kerboros Authentication Checklist

In order to set up a basic Kerberos Authenticated application in SharePoint, the following items listed in the chart should be accounted for.

Area of Configuration	Description
DNS	Register a DNS A Record for the web applications networked loaded balanced (NLB) virtual IP (VIP).
Active Directory	Create a service accounts for the web applications’ IIS application pool. Register Service Principal Names (SPN) for the web applications on the service account created for the web application’s IIS application pool. Configure Kerberos constrained delegation for service accounts.
SharePoint Web App	Create SharePoint managed accounts. Create the SharePoint Search Service Application. Create the SharePoint web applications.
IIS	Validate that Kerberos authentication is Enabled. Verify Kernel-mode authentication is disabled. Install certificates for SSL authentication.
Client Machine	Ensure web application URLs are in the intranet zone, or a zone configured to automatically authenticate with integrated Windows authentication.
Firewall Configuration	Open firewall ports to allow HTTP traffic in on default and non-default ports. Ensure clients can connect to Kerberos Ports on the Active Directory.
Test Browser Authentication	Verify authentication works correctly in the browser. Verify Logon information on the web server’s security event log. Use tools to confirm Kerberos authentication is configured correctly.
Test SharePoint Server Search Index and Query	Verify browser access from the index server(s). Upload content and perform a crawl. Test search.

 

Client integration

Microsoft Office Integration

Microsoft Office client programs and SharePoint products and technologies are natural partners in a productive, networked computing environment. Microsoft Office versions provide increasing levels of integration with SharePoint products and technologies.

Microsoft Office Integration

Microsoft Office client programs and SharePoint products and technologies are natural partners in a productive, networked computing environment. Microsoft Office versions provide increasing levels of integration with SharePoint products and technologies.

This section describes how the 2010, 2007, and 2003 versions of Office work together with the 2010, 2007, and 2003 versions of SharePoint technologies. Although an overview of Office and SharePoint features working together in past versions is provided, this section focuses on the integration features of the Microsoft Office 2010 experience with Microsoft SharePoint 2010.

The scenarios outlined in this section show examples of how SharePoint 2010 and related servers can be combined with capabilities of one or more Microsoft Office 2010 applications to deliver rich, intuitive, and easy-to-use capabilities directly into the hands of desktop users.

The following table provides an overview of the features designed to work together between a specific version of the Microsoft Office programs and the specific version of SharePoint products and technologies. Levels of the combined value of these two products can be summarized as fair, good, better, and best, and are further explained below.

Combined Value	Description
Fair	Microsoft Office 2000 or Office XP: Microsoft Office 2000 introduced the first interactions with Windows SharePoint Services, which provides simple file operations that allow people to open and save documents on SharePoint sites from their Microsoft Office 2000 applications and receive alerts in Microsoft Office Outlook 2000. Microsoft Office XP builds on this level of data integration to provide interactive access to data stored on SharePoint sites, which allows people to export list data to Microsoft Office Excel XP and view properties and metadata for files stored on SharePoint sites.
Good	Microsoft Office 2003 provides a good level of integration with Windows SharePoint Services, and SharePoint Portal Server 2003 which allows users to create documents, organize team meetings and activities, access and analyze data from SharePoint sites, and use Microsoft FrontPage 2003 to customize lists or Web Parts on SharePoint sites. People can also use data integration between the Office 2003 and Windows SharePoint Services to move data to and from SharePoint sites and create databases linked to data stored on SharePoint sites.
Better	Microsoft Office 2007 provides contextual integration with Windows SharePoint Services and Microsoft Office SharePoint Server, which allows people to interact with SharePoint sites without leaving their Microsoft Office programs, and provides two-way synchronization with collaborative information, documents, and business data stored on SharePoint sites.
Best	Microsoft Office 2010 with SharePoint 2010 gives people the ability to view and edit with PCs, browsers, and mobile devices. This combination also includes greater capabilities for people to use Microsoft Office applications to edit documents and work with information from line-of-business (LOB) applications while offline, and then resynchronize when they’re reconnected to the network. The ability to co-author the same document or share a Microsoft Office OneNote notebook reduces review cycles and enhances teamwork. Microsoft Office Backstage view puts many more SharePoint 2010 capabilities in the context of Office applications, including greater automation of metadata capture and streamlined access to document libraries and SharePoint workspaces.

 

The following tables show the integration features of different versions of Microsoft Office with SharePoint 2010:

Browser Support

For users trying to connect to SharePoint 2010 environments the following browsers should be used:

·         Internet Explorer 9

·         Internet Explorer 8

·         Internet Explorer 7

·         Apple Safari (Several versions and the newly released version)

·         Mozilla Firefox (Several versions and the newly released version)

·         Google Chrome (Several versions and the newly released version)

SharePoint 2010 supports additional browsers but all users should utilize the company standard which is Internet Explorer to minimize support issues.

Internet Explorer 6 is not supported for SharePoint Server 2010.

Mobile Browser Support

SharePoint also supports a wide variety of mobile browsers, which includes:

·         IE Mobile on Windows Mobile 5/6 and newer versions

·         Safari4 and newer versions on the iPhone (3 to newest release)) and iPad (1 through newest release)

·         BlackBerry 4.x and newer versions

·         Nokia S60

·         Openwave 6.2, 7.0 and newer versions

·         NetFront 3.4, 3.5 and newer versions

·         Opera Mobile 8.65 and newer versions

Governing Mobile Devices \ Browser Support

Another little known fact is that you can govern the specific devices that can access your SharePoint experience and actually redirect the user to a specific template based upon SharePoint recognizing the mobile device’s browser and sending them to the specific template for optimal user experience.

I am guessing the detractors of SharePoint 2010’s mobile capabilities have not actually sat down with multiple clients and gathered the requirements, developed, implemented, and successfully rolled out either custom or tailored mobile applications to Fortune 1000 or large government organizations.

Development

Customization Deployment Process (Application Development)

The following process diagram is a high level overview of the customization development and deployment process:

 

 

These are steps illustrated in figure 1.

1. Initial requirements are collected and turned into tasks.

2. Developers use Visual Studio 2010 Team Foundation Server or other tools to track the development progress and store custom source code.

3. Since source code is stored in a centralized location, you can create automated builds for integration and unit testing purposes. You can also automate testing activities to increase the overall quality of the customizations.

4. In larger projects, there could also be an additional build verification or user acceptance testing (UAT) farm, which is used by QA personnel to test and verify the builds in an environment that more closely resembles the production environment. Typically a build verification farm has multiple servers to ensure that custom solutions are deployed properly. Figure 2 illustrates a potential model for relating development integration and testing environments, build verification farms, and production environments. In this particular model, the pre-production or QA farm and the production farm switch places after each release. This model minimizes any downtime related to maintaining the environments.

 

5. After custom solutions have successfully undergone acceptance testing, you can continue to the pre-production or quality assurance environment.

6 and 7. The pre-production environment should resemble the production environment as much as possible. This often means that the pre-production environment has the same patch level and configurations as the production environment. The objective of this environment is to ensure that your custom solutions will work in production. The production database can be copied to this environment occasionally, so that you can imitate the upgrade actions that will be performed in the production environment.

8 and 9. After the customizations are verified in the pre-production environment, they are deployed either directly to production or to a production staging environment and then to production.

10. The production environment is used by end users, who give feedback and ideas concerning the different functionalities. Issues and bugs are reported and tracked through established reporting and tracking processes.

11. Feedback, bugs, and other issues in the production environment are turned into requirements, which are prioritized and turned into developer tasks. Figure 3 illustrates how multiple developer teams can work with and process bug reports and change requests received from end users of the production environment. The model in this figure also illustrates how development teams might also coordinate their solution packages. For example, the framework and the functionality development teams might follow separate versioning models that need to be coordinated as they track bugs and changes.

 

Code Development and Deployment

·         When deploying features package and deploy common components separately.

·         Any dependencies between features and solutions must be document to map dependencies between features.

·         Avoid Referencing the Item Collections directly for files and folders when trying to perform any type of enumeration or looping functionality.

·         Utilize efficient LINQ Queries and SPQuery.

·         When utilizing an SPQuery all queries should utilize a RowLimit of up to 2000 items at a time.

·         Try utilizing indexed fields when trying SPQueries.

·         All SPQueries should include an order by statement to take full advantage of the indexed field functionality.

·         All custom solutions and features should be deployed in the Sandbox for testing features that will be deployed in Production. The sandbox is a partially-trusted environment in SharePoint 2010 designed to bring greater stability to the SharePoint farm by restricting actions that may cause performance, security or other problems.

·         Avoid the use of Site Definitions.

·         Utilize the new feature stapling capabilities instead of Custom Site Definitions.

·         All Features should utilize versioning for modifications that are deployed.

Master Pages

One of the big improvements in SharePoint 2010 was the enhancement to the look and feel of a SharePoint site. This includes features such as the Ribbon, better support for Silverlight, faster browsing, and cross browser support. One of the items that should be considered is the use of custom master pages and layouts that are based on a SharePoint 2007 Environment.

This would include the Fabulous 40 templates that were created for Windows SharePoint Services 3.0 and Office SharePoint Server 2007. SharePoint 2010 provides the ability to display SharePoint 2010 master pages as well as the SharePoint 2007 master pages. These pages can still be rendered utilizing the SharePoint 2010 engine but will not enjoy the benefits of the improved features. This should be considered from a visual aspect as well as a performance aspect. SharePoint 2010 pages contain fewer tables and contain compliant XHTML code which improves the load time of SharePoint 2010 page versus a SharePoint 2007 page.

All master pages that are used in the environments should utilize the SharePoint 2010 master pages to utilize the additional features provided by SharePoint 2010 Master Pages.

Command Line Administration

SharePoint 2010 now provides two methods of updating the SharePoint environment through the command line and custom scripts. This is accomplished through the use of the Stsadm tool and Windows Powershell scripts. With the shift in technology preferences, PowerShell has risen as the top performer when performing command-line operations on windows servers. Stsadm has not totally been removed, but it remains as a part of SharePoint to support compatibility with previous versions of SharePoint. Several Stsadm commands have been added as well as some have been removed. Even though Stsadm still exist, it is recommended that the following command line operations be handled with PowerShell:

·         Backup and recovery

·         Databases

·         Features and solutions

·         Import and export

·         Logging and events

·         Performance

·         Security

·         Service application

·         SharePoint 2010 Search

·         Site management

·         Timer jobs

·         Upgrade and migration

·         Workflow management

 

To get the complete list of SharePoint cmdlets installed on your environment, you can run the following command from your SharePoint 2010 Management shell.

gcm -pssnapin microsoft.sharepoint.powershell | select Name, Definition | fl > .\filename.txt

Creation of PowerShell Scripts

One of the big advantages of utilizing PowerShell scripts for SharePoint 2010 is because it allows for the creation of scripts that interact with lists, sites, site collections, and many other components of a SharePoint environment. PowerShell can be used to create complex or simple automated processes in your environment. However when you design a SharePoint-specific cmdlets, always do the following:

·         Define cmdlet nouns.

·         Define cmdlet noun properties.

·         Define cmdlet verbs and parameters.

·         Define your cmdlet errors, progress, and pipeline.

When you follow this process, the result is a comprehensive definition of the cmdlet set for the component or feature that you are developing.

Define Cmdlet Nouns

To define Cmdlet Nouns, perform the following:

1.       When you define a cmdlet noun, be very clear about what your feature will manage. Think of nouns as items that a system administrator will manage. These could be SharePoint objects like SPSite or SPWeb objects, or they could be installed features, such as SPFeature objects, form templates, or Web Parts.

As a general rule, it is better to have a greater number of nouns that have fewer properties than to have a small number of nouns that have a great many properties. Any noun that has more than 15 properties is overburdened.

2.       Identify the non-persisted, run-time state information that you want to expose to system administrators. Also, identify state information that may not be persisted but must nevertheless be returned to system administrators (for example, the running state of a service).

 

3.       Evaluate whether a newly defined noun should be split into two or more different nouns. Create separate nouns for items that are semantically distinct. Use feature or component specifications to identify whether a noun spans multiple concepts or features.

 

4.       If a noun spans multiple data sources (either physical or logical), split the noun along data-source boundaries. Identify a logically independent subset of properties that is persisted in a single database or SharePoint object only. In most cases this subset should become a separate noun, but only if the resulting nouns are logically independent and only if they can be clearly understood as distinct entities (that is, easily separated) without confusing system administrators.

 

5.       For every persisted data source object that is used by more than one noun, unify these nouns into a single noun. Also, unify nouns whose primary difference is that they have different lifetimes, because their creation and deletion can be managed separately.

Define Cmdlet Noun Properties

To define Cmdlet Nouns Properties, perform the following:

1.       Define an Identity property. All nouns must have an Identity property whose value is unique and immutable, such as a GUID.

2.       Create a pipebind for the noun. The pipebind should combine all properties that can uniquely identify the object.

3.       Define the complete set of public properties for the noun. Treat the noun definition as though it were a public API. All related public properties are exposed in the command line when an instance of the noun is returned.

4.       Define a data type for each property. Properties should be strongly typed, so that format validation code can be attached to the property type rather than to the noun. For example, a property that represents an e-mail address should be of type email address rather than of type String.

5.       Identify atypically large properties. Ensure that unusually large properties (larger than 10 KB) are split into two or more properties.

6.       Identify collections of properties that have a large number of elements (for example, a collection with more than 100 elements). Remove such large property collections and split the elements into separate nouns. Then, define the New, Remove, Get, and Set verbs for the new nouns.

For example, consider a scenario in which Users is a property of an SPWeb object, which can have a large number of elements. To avoid problems, create a separate noun called SPUser that represents one element in the list, and then add the associated New, Remove, Get, and Set verbs.

Define Cmdlet Verbs and Parameters

Determine which of the base verbs (Get, Set, New, and Remove) apply to your noun. At a minimum, system administrators must be able to get settings and to change (or Set) them. Additionally, administrators may also need to create new instances (New) and delete existing ones (Remove).

1.       Define the behavior of your Get cmdlet.

The Get verb must retrieve all instances if no parameters are specified, and it must do so by writing the instances to the Windows PowerShell pipeline. However, any operation that can potentially return a very large result set should include a Limit parameter on which a default limit is specified. Of course, when limiting a result set in this way, you must alert users that additional results may be excluded from the limited result set.

The Get verb must have an Identity parameter. When specified, the corresponding cmdlet must return only the instance associated with that identity. If the identity that is specified is not unique, the cmdlet should return all instances that have the specified identity value.

The Get verb can have additional optional filtering parameters. For example, the cmdlet Get-SPSite might have a Content Database parameter that restricts the result set to the site collections that are located in a specified content database. Furthermore, the Get verb must have a Server parameter if the cmdlet returns local (that is, machine-specific) configuration information.

2.       Define the behavior of the Set cmdlet.

The Set verb must have an Identity parameter to identify the instance that is being changed. The parameter must be able to take either an identity (for example, a GUID) or a name. If a name is specified and this name matches more than one instance, the cmdlet must return an error.

The Identity parameter of the Set cmdlet must accept pipeline input.

The Set verb must expose all writable properties of the noun that are received using the corresponding Get cmdlet, except those that cause negative effects when set.

The Set verb must have an optional Instance parameter that represents an entire instance of this noun type. The Instance parameter must accept pipeline input (by value).

3.       Define the behavior of the new cmdlet.

The New verb must take a limited subset of the writable properties of the noun as parameters. The remaining properties should be set to default values. Furthermore, the new cmdlet must return the newly created instance object to the pipeline so that further cmdlets in the pipeline may act on the new instance.

4.       Define the behavior of the Remove cmdlet.

Your Remove cmdlet must have an Identity parameter that can take either an identity value or a name. If a name is specified and it matches more than one instance, the cmdlet must return an error.

The Identity parameter must accept pipeline input. Furthermore, any destructive operation must support Confirm and WhaIf parameters. This requires little effort, as Windows PowerShell and base classes of SharePoint Server 2010 provide means for supporting these parameters.

5.       Identify and define additional verbs for the noun.

For example, an SPContentDatabase noun might need a Mount verb to support mounting the specified database. Use well-tested administrative scenarios and use cases to support selecting appropriate verbs.

Remember that all additional cmdlets must have an Identity parameter that accepts pipeline input. The Identity parameter must accept the identity (PipeBind) of the object. Furthermore, any destructive operation must support Confirm and WhaIf parameters.

6.       Identify properties that have potential negative side effects.

Properties that have potential negative side effects may require additional operations to mitigate the negative effects. These additional mitigating cmdlets must have an Identity parameter that accepts pipeline input.

7.       For each cmdlet that you define, do the following:

1. Identify the list of prerequisites for the cmdlet. For example, in a case where a cmdlet can be executed only in a certain system state, the cmdlet must verify that all state prerequisites are met before executing.

2. Identify the list of operations. Specify the complete list of operations that the cmdlet is able to perform. The cmdlet must perform and then validate these operations. This operation list comprises the functional breakdown of the cmdlet.

Define Cmdlet Errors, Progress and Pipeline

1.       Identify all error conditions and error-state behaviors. That is, list all conditions in which a cmdlet can error out. Then, for each condition, describe the expected behavior. Your cmdlets must provide basic error management.

Your cmdlets must clean up partial changes when an error occurs, and they must return a meaningful (and localized, if appropriate) error message. Furthermore, cmdlets must determine and reveal how a system administrator can recover from any error condition.

2.       Differentiate between terminating and nonterminating errors.

 

3.       Identify long-running operations. If a cmdlet is expected to take longer than about twenty seconds, on average, to complete an operation, the cmdlet must provide progress information to avoid the appearance of a suspended operation.

 

4.       Ensure that cmdlets write their return objects directly to the pipeline. Avoid buffering retrieved objects to an internal array. Writing to the pipeline allows the downstream cmdlets to act upon preceding objects in the pipeline without delay.

 

5.       Group similar parameters. Limit cmdlets to 16 parameters (not including the Identity and Name parameters). In cases where object methods are rarely called, and where an object model method exists, no cmdlet parameter is needed. In cases where a large number of parameters can be grouped, write a single parameter that accepts the group object.

SharePoint Designer 2010 vs Visual Studio 2010

There are instances where it is beneficial to use one development tool over the other. This section outlines the major differences for when you should use Visual Studio 2010 or SharePoint Designer 2010 when creating customizations in SharePoint.

·         Visual Studio 2010 should be the tool of choice when you want to extend SharePoint functionality by writing your own custom code.

·         Visual Studio should be used more by Developers.

·         SharePoint Designer 2010 should mainly be used for presentation and branding of sites for rebranding the site, customizing the layout, updating CSS, and base designing Master Pages. However, any final master pages and layouts that will be globally deployed to all Locations should be eventually created and deployed using Visual Studio 2010 for total reusability.

·         SharePoint Designer 2010 is best suitable for a Web Designer.

·         If you want to design portable workflows you should use Visual Studio 2010.

·         Reusable workflows can be started in SharePoint Designer 2010 and imported into Visual Studio 2010 for the creation of simple workflows.

·         If you want to create event handlers, custom features, site definitions, custom lists or web parts then you should use Visual Studio 2010.

Packaging and Deployment Technologies

SharePoint Features

Note: The packaging and deployment technologies sections will continue to be updated as the SharePoint Review Board is established in future phases and as documented in the SharePoint Roadmap.

SharePoint Features are containers for one or more customizations packaged into a single unit. Features include a built-in scope attribute that defines where and how wide they can be deployed. Feature definitions can be installed and then activated by the server administrator against the farm, a specific Web application, a specific site collection, or a specific Web site. In some cases a feature can also be exposed to the SharePoint Services Team site collection or site owners so that they can be properly put into thedeployment process. Features can have dependencies to other features and can be “stapled” to specific site definitions to help automate the deployment of features that are related to other features or to a site definition.

SharePoint Solutions

SharePoint solutions are containers for one or more customizations Solutions can contain features, Web Parts, security policy changes, and other files with a detailed guide to allow the automated deployment to the file system by the deployment mechanisms in SharePoint Products and Technologies.

Web Part Packages

Web part packages are a legacy packaging and deployment mechanism for Web parts that is still supported in SharePoint 2010. A Web part package is composed of a .cab file with a manifest describing the contained files. SharePoint Solutions are now the preferred method of deploying Web parts due to the additional capabilities to edit safe controls and security policy information.

Installation Types

The previously described packaging and deployment technologies require installation into SharePoint environment before they can be used. The following installation types are the most commonly used:

Manual Installation

Manual installation refers to documented manual steps required to extract and copy files, perform assembly registration, or edit configuration and security policy settings. It is the least preferred method of installation due to the potential lengthiness of installation activities and the potential for incorrect or incomplete installation.

Scripted Installation

Scripted installation refers to batch file-based installation of customizations to execute the various steps that would be part of a manual installation. It is a slight improvement over manual installation but suffers from the disadvantages of requiring multiple files, and usually lacking any handling of installation failure events.

Automated Installation

Automated installation is a customization installation driven by the Windows installer or a self-contained executable. The automated installation experience can be as rich as the appropriate team member want to build. Automated installation normally offers the capability to have rich user dialogs, which can help tailor the installation and deployment process. One common issue with automated installation is that the contained files and activities performed are not easily visible to the person who performs the installation, and therefore harder to evaluate for dangerous activities.

Customization Packaging, Deployment, and Installation

The following packaging and deployment technologies (SharePoint Features and SharePoint Solutions) are the best practices customization packaging and deployment process.

Packaging and Deployment Technologies

SharePoint Features

Note: The packaging and deployment technologies sections will continue to be updated as the SharePoint Review Board is established in future phases and as documented in the SharePoint Roadmap.

SharePoint Features are containers for one or more customizations packaged into a single unit. Features include a built-in scope attribute that defines where and how wide they can be deployed. Feature definitions can be installed and then activated by the server administrator against the farm, a specific Web application, a specific site collection, or a specific Web site. In some cases a feature can also be exposed to the SharePoint Services Team site collection or site owners so that they can be properly put into thedeployment process. Features can have dependencies to other features and can be “stapled” to specific site definitions to help automate the deployment of features that are related to other features or to a site definition.

SharePoint Solutions

SharePoint solutions are containers for one or more customizations Solutions can contain features, Web Parts, security policy changes, and other files with a detailed guide to allow the automated deployment to the file system by the deployment mechanisms in SharePoint Products and Technologies.

Web Part Packages

Web part packages are a legacy packaging and deployment mechanism for Web parts that is still supported in SharePoint 2010. A Web part package is composed of a .cab file with a manifest describing the contained files. SharePoint Solutions are now the preferred method of deploying Web parts due to the additional capabilities to edit safe controls and security policy information.

Code review Process (SharePoint Services Team)

Code review is the key process of stream lining and standardizing the implementation artifacts and deliverable up to the mark to meet the internal or external SLA.

Pre-Requisites:

·         Code Review Process Established in the project team

·         Code Review panel or Gate Keeper needs to be identified

·         Define the Code Review checklist

·         Define the coding guidelines

·         Define the Naming conventions across the reference architecture layers components

·         Prioritize the Review comments Severity

·         Needs to have the Review comments tracking System (Bug tracking system can be used)

Types of Code Review Activity

Desk Review /Informal Review

1.       As a Senior Developer/ team lead / Project lead can sit with developer in his machine and check the complex component implementation

2.       Review the naming convention, number of lines per method or class and for loop, if else ladder, Map or List or array usage and review the developer business logic understanding and implementation

3.       Provide the on the fly review comments to the developer to focus on the key implementation skeleton

Peer Review

1.       As part of any logical component implementation completion, the developer can call for the Peer Review

2.       Peer will be identified with in his track/team and the code artifacts needs to be submitted to the peer by the developer

3.       Identified peer will review the code artifacts against the coding checklist as well with the help of coding guidelines

4.       Peer will provide the review comments to the appropriate developer and Keep the Team Lead/Project lead in the communication loop

Panel Review

1.       Panel will be identified with in the project

2.       Panel consist of Architect, SME, Lead, Senior Developers (max 5- 8 people)

3.       End of Specific Service or Functionality formal component implementation completion, the code or deliverable will be submitted to the Panel by the respective track or team lead

4.       Panel member will do the offline review on the code/artifacts thoroughly

5.       Panel needs to check the Implementation strategy, design pattern, reusability, QoS and the functional logic implementation

6.       Panel will gather in the Meeting room and the team lead /code owner will present the code to panel and walkthrough the artifacts

7.       Panel will raise the concern or identified gap in the meeting and the panel member will discuss the gaps

8.       Finally the panel will recommend the refactoring or approve the code for baseline

9.       All the review comments will be prioritized under one of the following criteria such as Development change/refactoring, bug, design issue, requirement missing, Change Request etc.

Client Review

1.       After the panel review ,the code will be given to the Client Technical panel (if your project structure has this?) and receive their inputs for further beautification in your client deliverables

2.       Finally your project manager will take the summary of the code review metrics from the tool and use that for code quality metrics/ SLA Base line

Installation Types

The previously described packaging and deployment technologies require installation into SharePoint environment before they can be used. The following installation types are the most commonly used:

Manual Installation

Manual installation refers to documented manual steps required to extract and copy files, perform assembly registration, or edit configuration and security policy settings. It is the least preferred method of installation due to the potential lengthiness of installation activities and the potential for incorrect or incomplete installation.

Scripted Installation

Scripted installation refers to batch file-based installation of customizations to execute the various steps that would be part of a manual installation. It is a slight improvement over manual installation but suffers from the disadvantages of requiring multiple files, and usually lacking any handling of installation failure events.

Automated Installation

Automated installation is a customization installation driven by the Windows installer or a self-contained executable. The automated installation experience can be as rich as the appropriate team member want to build. Automated installation normally offers the capability to have rich user dialogs, which can help tailor the installation and deployment process. One common issue with automated installation is that the contained files and activities performed are not easily visible to the person who performs the installation, and therefore harder to evaluate for dangerous activities.

Upgrade Strategy

The following section outlines a few things to consider during the before, during, and after the upgrade process.

Things to consider

·         Update your servers to Service Pack 2 (SP2) of Microsoft Office SharePoint Server 2007 or later.
Your environment must be updated to Service Pack 2 of Office SharePoint Server 2007 to run the upgrade process, either for an in-place or databases attach upgrade.

·         (Optional)It is recommended that you install the October 2009 Cumulative Update because it includes improvements to the pre-upgrade checker tool.

·         Ensure that the environment is fully functioning before you perform an upgrade.
An upgrade does not solve any problems that might already exist in your environment. Therefore, ensure that the environment is fully functioning before you perform an upgrade. For example, if you have web applications that are no longer being used, unextend them before you upgrade. If you want to delete a web application in Internet Information Services (IIS), unextend the web application before you delete it; otherwise, SharePoint Server 2010 will try to upgrade the web application even though it does not exist, and the upgrade will fail. If you find and solve problems beforehand, you are more likely to meet the upgrade schedule that you have estimated.

·         Before you try an in-place upgrade, migrate to 64-bit servers. Upgrade your operating system to a 64-bit version of Windows Server 2008 R2 or Windows Server 2008 with Service Pack 2 (SP2). If you are using SQL Server, upgrade or migrate to a 64-bit version of Microsoft SQL Server 2008 R2, SQL Server 2008 with Service Pack 1 (SP1) and Cumulative Update 2, or SQL Server 2005 with SP3 and Cumulative Update
Do not try to combine these operations with your upgrade process. You cannot perform an in-place upgrade unless your system already runs on a supported operating system and platform.

·         Run the pre-upgrade checker to look for potential issues. The pre-upgrade checker reports missing customizations and issues with orphaned sites, and more, so that you can address these issues before you perform your upgrade.

·         Run the Test-SPContent against the Database if you plan to do the attach; then, detach method for upgrading. This will produce additional issues that may occur when you try to run the actual upgrade process.

·         Perform a trial upgrade on a test farm first. Back up the live farm, restore to test servers, and then perform the upgrade. Examine the results to set expectations for what the live upgraded sites will look like, to determine how much post-upgrade customization will have to be done, and to estimate how long the upgrade will take. Make sure you try a full search indexing crawl to ensure that the search results are indexed properly.

·         Plan for capacity. Ensure that you have disk, processor, and memory capacity sufficient to handle upgrade requirements.

·         Back up your environment. Perform a full backup of your environment before upgrading. That way, you can recover your environment if you must roll back from an upgrade.

·         Optimize your environment before upgrade. A few key limits have changed in SharePoint Server 2010, such as query throttling on large lists and lower limits on the number of site collections allowed per content database (from 5,000 warni2ng and 15,000 limit to 2,000 warning and 5,000 limit). Be sure to optimize your Office SharePoint Server 2007 environment to meet these limits or restrictions before upgrade to mitigate errors during the upgrade process or broken lists or sites after upgrade.

·         (Optional) If you are using the database attach upgrade method, set the original databases to read-only.
If you expect a long outage window while you perform a database attach upgrade, you can set the databases in the original environment to be read-only so that users can continue to access their data without changing it.

·         Do not add any servers to your server farm after you begin the upgrade process. Running the SharePoint Products Configuration Wizard upgrades the configuration database. The configuration database contains the list of servers in the farm. Servers added to the farm after the configuration wizard has been run are not included in the database. Therefore, servers added after the wizard runs do not appear in the upgraded version topology. If you need to add servers to your farm, do so either before you start the upgrade or after you have completed the upgrade process.

·         After upgrade, review the Upgrade Status page and upgrade logs to determine whether there are issues that must be addressed. Then review the upgraded sites. The Upgrade Status page reports on the upgrade progress, and the upgrade logs list any errors or warnings that occurred during the upgrade process. You should verify all of the sites and test them before you consider the upgrade complete.

Site Usage

The following is a list of high level best practices provided to support an implementation of SharePoint 2010:

Administrative

·         Regularly review the list of site users and their respective permission levels for your site, as well as audit that list for associates who changed jobs or roles.

·         Consider using Active Directory groups for adding members to a site; these are especially applicable for department sites to keep active/inactive site members current. If AD groups are not used, Site Owners can assign rights through the use of SharePoint Groups.

·          Assigning specific rights to specific individuals should be used as a last option when determining how to assign permissions.

·         As access and permission rights are assigned, Site Owners must understand their obligations from an audit perspective for assigning individuals appropriate rights within SharePoint, and must carefully review and manage access and permissions.

·         Site members should ensure that the files they upload are appropriate for viewing by the audience with access to the site.

·         Set up alerts to let you know when content on your SharePoint site has changed.

·         Assign users the lowest level of permission they will need for site access.

·         Make sure your site has clearly defined ownership by designating both a primary and secondary Site Owner.

·         Avoid using special characters in a URL as much as possible when creating a site.

Quotas and Limitations (Examples)

·         SharePoint usage must comply with existing company policies and standards.

·         Site Owners receive alerts when storage is at 90% of quota.

·         Any type of document may be uploaded into the SharePoint system which is not in the exclusion list defined in the Web Application.

·         Documents must be no larger than 100MB. Larger files require approval by Tier 2 Support.

·         Preservation and Disposal of sites to ensure stale sites are removed and data storage is reclaimed is part of the provisioning obsolescence plan which includes:

o   Alert to the business owner and admin for renewal, short term preservation (AKA archival) or deletion when the declared expiration date is reached.

o   If a preserved (AKA archived) site has reached 5 years of existence, alert the site owner and delete if no answer.

o   When a site has been idle for 2 years (no update), alert the site owner and site collection administrator for renewal, short term preservation (AKA archival) or deletion. If there are no owners, preservation the site until an owner can be defined. If no owner can be defined, the site will be archived and then deleted after one year.

·         SharePoint maintains version control and previous versions of documents can be restored by document owners. Items that have been deleted within SharePoint can be recovered from the SharePoint Recycle Bin by site owners and users. Full system backups are done according to current Enterprise Standards as defined in the IT Standards for User.

·         Any item emptied from the Recycle Bin will not be restored without appropriate approvals and cost recovery.

·         An unlimited number of documents and document versions may be stored in SharePoint for as long as necessary within site quota limits. However, site owners and users must actively monitor and maintain their sites and remove unneeded documents and document versions in order to preserve storage space.

Creating Site Pages

·         Maintain the default Standard site template layouts as much as possible to ensure consistency and ease of use across multiple sites.

·         Keep announcements, blogs, and other text concise so users can quickly scan the page to gather relevant information.

·         As you add content to your site, the primary emphasis should be on “what” you want to communicate rather than on “how” content is formatted.

·         Use the web-based tools built in to SharePoint to edit your site pages. However this ability should be limited based on the permission set up in the SharePoint site.

·         SharePoint Designer access to the environments should be minimized based on the roles defined at the Farm

 Working with Documents

·          “Working” documents used during a collaboration effort should be stored in document libraries that have been created for each site.

·         Use different views of your document library to tailor how and what information is displayed. While the content of the document library does not change, creating different views allows you to organize and filter the documents in order to make them easy to browse. Views can be created to show documents in a different layout, within a specific date range, by author, filtered by keywords, etc.

·         Send links to documents that are located in SharePoint sites rather than sending attachments in e-mail messages. This helps avoid having multiple copies of the original in circulation.

·         As much as possible, refrain from renaming or moving a file or its location, as this will cause links to become invalid.

·         Avoid incorporating version numbers in file names. SharePoint has built-in versioning tools that automatically save older copies of your file.

File and Document Limitations

The Following chart outlines the limitations for files and document in SharePoint 2010.

Limit	Maximum value	Limit Type	Notes
File size	2 GB	Boundary	The default maximum file size is 100 MB (Note: This can differ and can change based on external BLOB storage and other factors). This can be increased up to 2 GB; however a large volume of very large files can affect farm performance.
Documents	30,000,000 per library	Supported	You can create very large document libraries by nesting folders, or using standard views and site hierarchy. This value may vary depending on how documents and folders are organized, and by the type and size of documents stored.
Major versions	400,000	Supported	If you exceed this limit, basic file operations—such as file open or save, delete, and viewing the version history— may not succeed.

File Naming Tips

·         Use descriptive and meaningful file names. Avoid using the following characters in file names:! @ # $ % & # : \ ? * < > % / | " ~.

·         Since SharePoint automatically tracks Created by, [Last] Modified by, Created Date, and [Last] Modified Date, try to avoid using these descriptors in the file name. If name or date values are key to the file description, agree to common conventions (yyyy-mm-dd or Last name-First Name) in advance.

·         All users should use the standard approach for naming files based on the company’s standards. File naming rules, examples, and reminders can be posted in the document library’s General Settings Description field.

·         When naming files, use spaces between names, as spaces improve readability.

 

#bestpractices #SharePointConsulting #EPCGroup #EnterpriseDeployment #SharePoint #ElectronicRecordsManagement #InformationGovernance #ScanningandCapture #EnterpriseContentManagement #Collaboration #Life-CycleofSharePoint