IN THIS CHAPTER
Any enterprise platform needs to be able to adjust, grow, and scale out to fit the needs of a changing organization. SharePoint is no exception to this rule, and the creators focused on the ability to scale certain components within SharePoint to be able to adjust to the unique conditions that exist in various environments. For small organizations in need of simply document management and team sharing, Windows SharePoint Services (WSS) offers a rich set of easily deployed capabilities. For larger or growing organizations, the full Microsoft Office SharePoint Server product allows for the centralization of information and the distribution of knowledge.
This chapter focuses on techniques and information necessary to scale a SharePoint implementation to organizations of varying sizes. Specific components that can be scaled are described and contrasted. High-redundancy options such as clustering and Network Load Balancing for SharePoint and SharePoint’s SQL Databases are outlined. In addition, examples of scalability in organizations of different sizes are presented.
The first step in scaling a SharePoint environment is to understand the level of usage it will receive, both presently and in the future. After the level of usage is determined, understanding which specific components can be extended is vital to structuring the system to match the desired user load. The key is to match SharePoint functionality to the specific identified need.
When deploying SharePoint, the primary concern in regards to scalability is how many users will utilize the system. For departmental collaboration, the numbers may be small. For large, publicly accessible portals, on the other hand, the numbers could scale up quickly. Scaling a SharePoint implementation based on the number of users is simplistic but can be used as a starting point. In addition to total number of users, the following factors should be identified to more fully understand the load placed on a SharePoint server:
Collecting this information and understanding who will be accessing a SharePoint environment is the first step toward properly scaling the environment.
When designing a SharePoint environment, it is always best to start the design simply and then expand on that design as needs arise. With SharePoint, this means that a single server should be planned and other servers added as new constraints are identified. A single server should not exceed several general limits in SharePoint, and those limits should be understood. These limits are as follows:
Understanding these limits is an important part of scaling the environment. If, after designing and implementing a SharePoint environment, any of these limits is reached, SharePoint should be scaled to match.
In addition to the amount of data that initially is loaded into SharePoint, an understanding of how fast that content will grow is critical in properly scaling an environment. Running out of storage space a year into a SharePoint deployment is not an ideal situation. It is important to understand how quickly content can grow and how to control this inevitable growth.
Proper use of site quotas in SharePoint is an effective way to maintain control over the size that a SharePoint database can grow to. Implementing site quotas as they are created is a recommended best-practice approach and should be considered in most situations. It is easy to bloat SharePoint with unnecessary data, and site quotas help local site administrators to make judicious use of their available space.
SharePoint’s SQL database can grow in size dramatically, depending on how heavily it is used and what type of content is included in it. Table 3.1 illustrates the effect that various data sources can have on a SQL database. Of particular note is the search and indexed content, which can grow large in tandem with the existing content.
Table 3.1. Effect of Various Components on SQL Server
After SharePoint is implemented, it is important to monitor the system to ensure that it is not growing too fast for its own good. In addition to some of the default alerts and tools, a Management Pack for Microsoft Operations Manager (MOM) has been specifically designed to collect information about SharePoint, including the ability to monitor growth of specific components.
The key to SharePoint’s success is in its capability to intelligently present information needed for each individual user, allowing them quick and easy access to that information. SharePoint accomplishes this through various logical mechanisms that exist to help organize this content, structuring it in a way that pulls unstructured data together and presents it to the user. For example, a file server simply holds together a jumbling of documents in a simple file structure. Multiple versions of those documents further confuse the issue. SharePoint contains mechanisms to organize those documents into logical document libraries, categorized by metadata, which can be searched for and presented by the latest version.
In addition to the most obvious logical components, SharePoint allows sets of data to be scaled out to support groups of users. For example, by utilizing different site collections with their own unique sets of permissions, SharePoint can be configured to host different groups of users on the same set of machines, increasing flexibility.
Building on the success of SharePoint Team Services and Windows SharePoint Services 2.0, SharePoint sites in Windows SharePoint Services 3.0 allow various teams or groups of users to have access to particular information relevant to them. For example, sites can be set up for each department of a company to allow them access to information pertinent to their groups.
Sites can be scaled out to support various site collections for each group of users. This allows the data to be distributed across a SharePoint environment logically, allowing a much larger population of users to be distributed across a SharePoint server environment. Each site collection can be administered by a unique owner designated within the site structure, as shown in Figure 3.1. This allows for security to be scaled out across a SharePoint site.
Figure 3.1. Setting site permissions for a SharePoint site.
SharePoint stores its data in a SQL Server 2000/2005 database, but serves up access to that data via HTML and ASP.NET web services. Access to this data is served up to the user via the Windows Server 2003 Internet Information Services (IIS) 6.0. IIS is composed of various logical structures known as virtual servers, which are entry points of sorts to web content. Each virtual server can be configured to point to various sets of information located on the web server or extended via SharePoint to be unique SharePoint web applications.
A web application in SharePoint 2007 is the equivalent of a portal in the SharePoint Portal Server 2003 product. Web applications are physically unique instances of SharePoint, with separate sets of site collections and separate settings. For example, an organization could have a web application for external vendors and another separate one for internal employees to keep data physically separate and to provide for different authentication settings.
Utilizing unique virtual servers and/or web applications with SharePoint can help to scale the functionality of an environment further, allowing the flexibility to grant access to SharePoint using Secure Sockets Layer (SSL) encryption or across different ports. In addition, deploying multiple virtual servers allows for the use of multiple host headers for a SharePoint organization, such as sharepoint.companyabc.com, docs.companyabc.com, info.companyabc.com, moss.organizationa.com, and so on.
The operating system for SharePoint—Windows Server 2003—provides two clustering technologies: Network Load Balancing (MSCS). NLB is available on all version of the platform, including the Standard Edition, whereas MSCS is only available on the Enterprise and Datacenter server platforms. Clustering is the grouping of independent server nodes accessed and viewed on the network as a single system. When an application is run from a cluster, the end user can connect to a single cluster node to perform his work, or each request can be handled by multiple nodes in the cluster. In cases where data is read-only, the client may request data and receive the information from all the nodes in the cluster, improving overall performance and response time.
Clustering technologies in Windows Server 2003 can help to scale SharePoint by allowing more resources to assist in the overall environment. For example, multiple network load-balanced SharePoint front-end servers can distribute traffic to a clustered set of SQL database servers, as illustrated in Figure 3.2.
Figure 3.2. NLB-enabled front-end servers and clustered SQL database servers.
The first Windows Server 2003 clustering technology is NLB and is best suited to provide fault tolerance for front-end SharePoint web servers. NLB provides fault tolerance and load balancing by having each server in the cluster individually run the network services or applications, removing any single points of failure.
The second clustering technology Windows Server 2003 provides is Cluster Service, also known as Microsoft Cluster Service or simply MSCS. Cluster Service provides system fault tolerance through a process called failover. When a system fails or is unable to respond to client requests, the clustered services are taken offline and moved from the failed server to another available server, where they are brought online and begin responding to existing and new connections and requests. Cluster Service is best used to provide fault tolerance for file, print, enterprise messaging, and database servers.
Microsoft does not support running both MSCS and NLB on the same computer due to potential hardware sharing conflicts between the two technologies.
Active/passive clustering occurs when one node in the cluster provides clustered services while the other available node or nodes remain online but do not provide services or applications to end users. When the active node fails, the cluster groups previously running on that node fail over to the passive node, causing the node’s participation in the cluster to go from passive to active state to begin servicing client requests.
This configuration is usually implemented with database servers that provide access to data that is stored in only one location and is too large to replicate throughout the day. One advantage of Active/Passive mode is that if each node in the cluster has similar hardware specifications, there is no performance loss when a failover occurs. The only real disadvantage of this mode is that the passive node’s hardware resources cannot be leveraged during regular daily cluster operation.
Active/passive configurations are a great choice for keeping cluster administration and maintenance as low as possible. For example, the passive node can test updates and other patches without directly affecting production. However, it is nonetheless important to test in an isolated lab environment or at a minimum, during after hours or predefined maintenance windows.
Active/active clustering occurs when one instance of an application runs on each node of the cluster. When a failure occurs, two or more instances of the application can run on one cluster node. The advantage of Active/Active mode over Active/Passive mode is that the physical hardware resources on each node are used simultaneously. The major disadvantage of this configuration is that if you are running each node of the cluster at 100% capacity, in the event of a node failure, the remaining active node assumes 100% of the failed node’s load, greatly reducing performance. As a result, it is critical to monitor server resources at all times and ensure that each node has enough resources to take over the other node’s responsibilities if the other should fail over.
For these fault-tolerant clustering technologies to be most effective, administrators must carefully choose which technology and configuration best fits their specific SharePoint needs. NLB is best suited to provide connectivity to stateless SharePoint front-end web servers. This provides scalability, and the amount of redundancy it provides depends on the number of systems in the NLB set. The Windows Server 2003 Cluster Service provides server failover functionality for mission-critical applications such as SharePoint’s SQL database servers.
Although Microsoft does not support using both NLB and MSCS on the same server, multitiered applications can take advantage of both technologies by using NLB to load-balance front-end application servers and using MSCS to provide failover capabilities to back-end SQL databases that contain data too large to replicate during the day.
Microsoft Cluster Service is a clustering technology that provides system-level fault tolerance by using a process called failover. MSCS is used best in SharePoint to provide access to the SQL database server or servers. Applications and network services defined and managed by the cluster, along with cluster hardware including shared disk storage and network cards, are called cluster resources. Cluster Service monitors these resources to ensure proper operation.
When a problem occurs with a cluster resource, Cluster Service attempts to fix the problem before failing the resource completely. The cluster node running the failing resource attempts to restart the resource on the same node first. If the resource cannot be restarted, the cluster fails the resource, takes the cluster group offline, and moves it to another available node, where it can then be restarted.
Several conditions can cause a cluster group to fail over. Failover can occur when an active node in the cluster loses power or network connectivity, or suffers a hardware failure. In addition, when a cluster resource cannot remain available on an active node, the resource’s group is moved to an available node, where it can be started. In most cases, the failover process either is noticed by the clients as a short disruption of service or causes no disruption at all.
To avoid unwanted failover, power management should be disabled on each of the cluster nodes in the motherboard BIOS, on the network interface cards, and in the Power applet in the operating system’s Control Panel. Power settings that allow a monitor to shut off are okay, but the administrator must make sure that the disks are configured to never go into Standby mode.
Cluster nodes can monitor the status of resources running on their local system, and can keep track of other nodes in the cluster through private network communication messages called heartbeats. Heartbeats determine the status of a node and send updates of cluster configuration changes to the cluster quorum resource.
The quorum resource contains the cluster configuration data necessary to restore a cluster to a working state. Each node in the cluster needs to have access to the quorum resource; otherwise, it will not be able to participate in the cluster. Windows Server 2003 provides three types of quorum resources, one for each cluster configuration model.
Clustering using MSCS is most often used in SharePoint configurations to provide for server redundancy on SQL database servers. By implementing MSCS clustering on SharePoint SQL database servers, the server components themselves become more redundant, but not the actual database itself because it is stored on the shared storage component.
The second clustering technology available with Windows Server 2003 is NLB. NLB clusters provide high network performance and availability by balancing client requests across several servers. When client load increases, NLB clusters can easily be scaled out by adding more nodes to the cluster to maintain or provide better response time to client requests.
Two great features of NLB are that no proprietary hardware is needed, and an NLB cluster can be configured and running in minutes. NLB clusters can grow to 32 nodes, but if larger cluster farms are necessary, DNS (domain name server) round robin or a third-party solution should be investigated to meet this larger demand.
One important point to remember is that within NLB clusters, each server’s configuration must be updated independently. The NLB administrator is responsible for making sure that application configuration and data are kept consistent across each node. Applications such as Microsoft’s Application Center can be used to manage content and configuration data among those servers participating in the NLB cluster.
NLB is the mechanism used most commonly in SharePoint to provide for load-balanced access to multiple SharePoint front-end servers. Organizations seeking to scale up SharePoint front-end capabilities should consider use of this technology for an environment.
A high availability solution masks the effects of a hardware or software failure and maintains the availability of applications so that the perceived downtime for users is minimized. If there is a need for uninterrupted operation of an organization’s SharePoint databases, it is recommended that the IT professional implementing SharePoint understands the high availability alternatives offered in SQL Server.
With regard to SharePoint, SQL Server 2005 offers three high availability alternatives: log shipping, failover clustering, and database mirroring. Peer-to-peer replication is another SQL high availability alternative; however, it is not applicable to SharePoint. It enables load-balancing and improved availability through scalability based on established transaction replication technology. The SQL Server 2005 high availability alternatives applicable to SharePoint will be described in the sections that follow.
Log shipping is a recommended solution for creating redundant copies of databases from a source SQL Server to another target SQL Server, as illustrated in Figure 3.3. The normal procedure of log shipping involves the transaction logs being backed up from a source server (primary server), copied across to another target server (secondary server), and finally restored. Previously, log shipping was available only in the Enterprise Edition of SQL Server 2000. However, it is now included with SQL Server 2005 Standard and Enterprise Edition.
Figure 3.3. Understanding log shipping concepts.
To provide high availability for SharePoint mission-critical databases, log shipping is adequate because first, it is inexpensive, and second, it is relatively easy to administer. This is the most cost-effective method available for creating redundant databases compared to significantly higher costs associated with a hardware cluster. Unlike database mirroring, which is limited to a single destination server, when using log shipping, it is possible to configure more than one secondary server for redundancy.
On the other hand, log shipping offers a slower and manual failover process that is not seamless. Therefore, log shipping might not be the best solution for providing an organization with high availability when compared to the Windows clustering and database mirroring approaches. All SharePoint database connections will also have to be manually changed to reflect the name of the new target SQL Server.
Windows Server 2003 and SQL Server 2005 support the shared-nothing cluster model. In a shared-nothing cluster, each node of the cluster owns and manages its local resources and provides nonsharing data services. In case of a node failure, the disks and services running on the failed node will failover to a surviving node in the cluster. However, with high availability clustering, only one node is managing one particular set of disks and services at any given time.
SQL 2005 on Windows 2003 Enterprise or Windows 2003 Datacenter can support up to eight nodes within a single cluster. Failover clustering of SQL Server 2005 can be configured in two ways: a single-instance failover (Active/Passive) configuration or a multiple-instance failover (Active/Active) configuration.
It is possible to create a two-node cluster with SQL Server 2005 Standard Edition, which was not possible in the past.
In a SQL Server single-instance failover configuration, illustrated in Figure 3.4, the cluster runs a single instance of SQL Server on all nodes in the cluster. If the main SharePoint SQL Server instance fails on the primary node, the surviving node or nodes will run the same SQL Server instance. In this configuration, all the servers within a cluster share a master database along with a set of SharePoint databases, such as the configuration and content databases.
Figure 3.4. Understanding a single-instance failover configuration.
In the multiple-instance failover configuration, shown in Figure 3.5, each of the active nodes has its own instance of SQL Server. Each instance of SQL Server includes a separate installation of the full service and can be managed, upgraded, and stopped independently. To apply a multiple-instance failover configuration, at least two instances of SQL Server must be installed on the cluster and each instance should be configured to run on a certain node as its primary server.
Figure 3.5. Multiple-instance failover configuration.
It is then possible to separate SharePoint databases among the instances of SQL Server for scalability purposes. SharePoint databases that regularly refer to each other should be placed on the same SQL Server instance. Before implementing a multiple-instance failover configuration, the expected load on each of the database applications should first be evaluated, followed by a second evaluation to determine whether a single node can handle the combined load in a failover situation. If a single node cannot work, the use of two single-instance failover mode clusters should be considered.
SharePoint databases will not be statically load balanced across multiple instances of SQL Server. This design alternative is best suited for organizations that have independent databases that could benefit from multiple servers being used at the same time, such as multiple site and content databases.
Database mirroring is a new high availability alternative introduced in SQL Server 2005. This solution increases database availability by maintaining an up-to-date copy of the source database on a hot standby server in real-time.
Database mirroring consists of two mandatory roles and a third optional role. The first mandatory role is the Principal Server, which contains the source database and is the source of all transactions. The secondary mandatory role is the Mirror Server, which is another server, one that focuses on receiving transactions from the principal server. The Witness Server is the third and optional role, which detects and enables automatic failover between the principal and mirror servers in the event of a failure.
Figure 3.6. Understanding database mirroring.
Mirroring is implemented on a per-database basis and works only with databases that use the full recovery model. The simple and bulk-logged recovery models do not support database mirroring. Database mirroring is supported in SQL Server 2005 Standard Edition and Enterprise Edition.
Database mirroring offers a substantial improvement in availability over the previous high availability alternatives. Implementation is simplistic and it is straightforward to maintain. It is similar to log shipping; however, when a database mirroring session synchronizes, it provides a hot standby server that supports rapid failover with no loss of data from committed transactions. In addition, unlike log shipping, the failover is nearly seamless and client applications can recovery with minor interruption by reconnecting to the mirror server.
Database mirroring was introduced with the release of SQL Server 2005. However, the feature was not enabled by default and was not supported by Microsoft in production. Database mirroring is now supported with the release of Service Pack 1 for SQL Server 2005.
IT professionals designing the back-end database infrastructure for SharePoint are faced with the dilemma of choosing the right high availability technology for their solution. If the Service level agreement at the organization requires a hot standby server to be available for immediate failover, failover clustering and database mirroring in High Availability Configuration mode are the right choice. The failover is nearly seamless for the administrator and clients. If a warm standby server, wherein a less expensive, but not as immediate solution is required, log shipping and database mirroring in High Protection or High Performance mode should suffice. In this scenario, failovers must be conducted manually and the clients will be initially affected. Finally, other factors that affect these decisions are cost, hardware, and site proximity.
In addition to the logical structure of SharePoint, which can be scaled out, SharePoint includes the ability to physically spread data and content across multiple servers. This is one of the principal design changes implemented since the first versions of SharePoint, which did not scale very well beyond a single server. The concept of the SharePoint farm subsequently allows for a much greater range of flexibility and scalability of an environment because services and databases can be distributed.
SharePoint farms consist of two, three, four, or more servers sharing a common configuration database. A farm provides for the distribution of processing and application power across multiple machines in addition to providing a limited degree of additional redundancy into an environment.
Each SharePoint server installed into a SharePoint farm takes on specific sets of roles in that environment. The roles for SharePoint servers in a farm are as follows:
A single server can perform more than one of the roles listed in a SharePoint farm. It is, in fact, more common for multiple roles to be performed on specific servers than to have dedicated servers for each task.
As an organization’s requirements from SharePoint scale beyond the capabilities of a single server, additional servers added into a farm become a necessity. Understanding how those servers can be designed and scaled properly into an environment is key.
SharePoint scalability does not end at the farm level. On the contrary, SharePoint’s capability to extend its resources to large deployments is supported by the concept of shared services. Shared Services is the capability to share specific functionality across multiple SharePoint farms. For example, search capability can be extended across more than one SharePoint farm utilizing the Shared Services model. Although individual items cannot be shared using this approach, the following items can be shared:
Several limitations exist for deploying SharePoint using the Shared Services approach, however. The following are limitations of using this model:
For the largest SharePoint deployments, Shared Services allows a degree of scalability beyond the server farm itself, allowing for the sharing of resources between multiple SharePoint environments.
Microsoft Office SharePoint Server (MOSS) 2007 requires that a Shared Services instance be created for each farm, not matter what the size. Even single server instances must build a Shared Services Provider (SSP). The SSP is used for administration of specific farmwide content, and is used as a placeholder if the farm is expanded in the future.
As the cost of providing a portal structure goes down, it makes business sense to create portal-based solutions as opposed to purchasing, installing, and maintaining software on individual PCs for accessing information. Maintaining a web browser on each desk and a centralized application structure flexible enough to provide access for any set of users is generally much more cost effective and presents a means for implementing innovative solutions that might have been too costly to deliver using traditional methods. When applications or new features are added to the portal, they are instantly available to users without having to touch every desktop. Delivering information and applications via a web browser also reduces the burden on the IT department while providing them with the necessary control over who has access to the information and applications.
The backbone of the business portal is Microsoft Office SharePoint Server 2007. It provides the platform for creating an enterprise portal for centrally managing, storing, sharing, and accessing information. When appropriately designed, the portal can be used to quickly find relevant information and provide a means for team collaboration. Users can create their own customized view of the portal to meet their needs, and information can be targeted to an individual based on her role.
Team and workgroup collaboration, document management, and list management are accomplished using the Windows SharePoint Services 3.0 engine within MOSS 2007. It is oriented to facilitating information sharing and document collaboration. Its features make it easy for users and teams to work together and enable managers to coordinate content and activities. Microsoft Office 2003/2007, when used in conjunction with Windows SharePoint Services, further enhances user productivity by providing an integrated desktop that accesses server collaboration services using tools that users are familiar with.
Microsoft Office 2007 and the older 2003 version provide interfaces that users are familiar with and are the primary tool for creating and modifying documents. Elements of Microsoft Office 2007/2003 can also be integrated with SharePoint technologies to provide a central web-based accessibility to information.
The tightest integration for a SharePoint 2007 environment can be realized with the 2007 versions of the Office clients; however, 2003 clients are supported against a SharePoint 2007 farm. Although technically supported, using older versions of Office such as Office XP or Office 2000 in a SharePoint 2007 environment is not generally recommended to because there are major functionality limitations.
Microsoft BizTalk Server 2006 and custom-developed web parts provide the means for integrating line-of-business applications into the MOSS 2007 environment. Microsoft BizTalk Server 2006 includes the tools to integrate applications, whereas web parts can be developed for the integration with SharePoint. This provides end users with the ability to perform business transactions and retrieve information from business systems without having to leave the site or learn new applications. In addition, BizTalk itself centralizes access and control to disparate volumes of corporate data, allowing more intelligent business decisions to be made.
An effective SharePoint environment encompasses both collaboration and communication concepts into its design. The ability to alert users of document changes, for example, takes advantage of email routing. MOSS 2007 has the capability to interface with any SMTP (Simple Mail Transfer Protocol) server to relay messages, but is most effective when integrating with the newest 2007 version of Exchange because multiple new integration points have been built between the two applications, both released within a few months of each other.
Using SharePoint 2007 with Exchange Server 2007 or, to a lesser extent, Exchange 2003, allows for tight integration with the various components of Exchange itself, such as shared calendars, direct access to mailbox items, task lists, and public folders. Alerts can be sent to specific mailboxes, for example, to allow them to be viewed by multiple users. A departmental calendar can be set up in Exchange and displayed in SharePoint.
Leveraging an existing Exchange Server 2007 deployment with SharePoint greatly extends the reach of both applications, filling gaps in the functionality of each product. The most functional, collaborative environments can be created by a combination of these technologies.
Lesser versions of Exchange, such as Exchange 2000/2003, are supported directly from within SharePoint as web parts, although the integration features such as those available with the Exchange Server 2007 version of Outlook Web Access are not as rich.
More specific information on Exchange 2007 and configuring Exchange to work with SharePoint 2007 can be found in Chapter 18, “Configuring Email-Enabled Content and Exchange Server Integration.”
MOSS 2007 and Windows SharePoint Services 3.0 were designed to address business needs and issues that commonly arise in organizations. This section pulls together the information about SharePoint features described in other chapters of this book to summarize some common business issues and how features of SharePoint can be used to address them. Scenarios that represent these issues are described along with the specific SharePoint technologies that can be used to address that particular issue.
In many organizations users duplicate effort by creating documents or by gathering information when someone else in the organization has already done so. This happens because either the users didn’t know the information existed or they couldn’t find it, and results in an inefficient use of time.
SharePoint solution: Full-text indexing and search of SharePoint document libraries, workspaces, metadata information, and lists
SQL full-text indexing of Windows SharePoint Services sites enables indexing and searching site content so that users can quickly find the documents or information they need.
Users need information, and often the only way they can get it is to perform multiple different types of searches on multiple content sources and then manually consolidate the results. This results in the possibility of content not being searched (either because it is overlooked or just takes too much time) as well as an inefficient use of time.
SharePoint solution: MOSS 2007 content sources that can be indexed and searched
Adding frequently used sources of information as content sources in a SharePoint 2007 environment provides a means for users to perform one search request and have the results from many different content sources displayed together. For example, a single SharePoint search request could span other SharePoint sites, websites external to the organization, file shares, and Microsoft Exchange Public Folders. This enables users to easily search across many sources to find the information they need.
Only the full MOSS 2007 version of the product supports searching and indexing content from external sources. WSS 3.0 supports only indexing local content in WSS sites.
A team of people need to collaborate on a project and produce a set of documents to be sent to a client. User A works on the first document and saves it as “Doc1.” User A emails User B to let User B know the document is available for review. User B makes changes and additions and saves the document as “Doc1 R1.” User B creates an email with a list of ideas about additional changes that could be made and emails it to User A and User C. User C replies to User A and User B regarding User B’s email about proposed changes, makes her own changes, saves it as “Doc1 R2,” and emails User A and B to let them know changes have been made. User A also replies about the proposed changes, makes “final” changes to the document, saves it as “Doc1 Final,” and emails the document to the client.
Two days later, the client emails back with the list of changes the client wants to see in the document. User A edits the document again and saves it as “Doc1 Final R1.” The process continues until there are suddenly 10 versions of the document and 16 emails floating around about what should be in the document. At this point, the team isn’t sure what changes have been made, the folder where the document is stored is cluttered with various versions of the document (and taking up a lot of space), and nobody knows which version(s) were sent to the client.
SharePoint solution: WSS team site with shared document library, document versioning enabled, document discussions
Rather than having multiple versions of multiple documents floating around with different names, a team site for the project with a shared document library could be used. Each client document would be stored in the library, and by using versions and entering version comments, shown in Figure 3.7, the team would know who made changes, be provided with a brief overview of what or why changes were made, and know which one was sent to the client. By using document discussions in place of emails to have an online discussion of the document, all comments are stored in one place, with the document right there for easy access as opposed to sifting through multiple emails.
Figure 3.7. Using versioning and version comments in a SharePoint document library.
A user emails an attachment to a group, revises the attachment, and then emails it to the group again, and so on. This results in excess email traffic, excess storage, and the potential that recipients won’t see the current version of the attachment if it is modified after the email is sent.
SharePoint solution: Document workspaces/libraries and alerts
Document workspaces and libraries can be used for storing documents in a centralized document library, accessible by all team members. Alerts set up by team members notify them when the document changes. Team members know where the most current version of the document is located and are notified automatically when the document changes.
In a traditional file system environment, a user creates a document. For future reference, should the document be stored in a folder based on the subject of the document, in a folder based on document type, in a folder based on the client the document was created for, or in all three places? Decisions of this type need to be made all the time, weighing the consequences of storing the document in one place versus another versus storing multiple copies of the document.
SharePoint solution: Use of topics, document metadata, search
When using SharePoint, using document metadata and topics prevents the document creator from having to worry about where the document is stored. Metadata, or specific fields of information that can be stored with the document, can be used for information such as subject, client, and document type. Because these fields are searchable, a document can be easily found regardless of what folder it is in. Some organizations go as far as storing all documents in one big document library and then use metadata (shown in Figure 3.8), topic assignments, and search to classify and find information.
Figure 3.8. Adding metadata columns to SharePoint document libraries.
An organization might use a business application such as SAP or Microsoft Great Plains. Some individuals in the organization will need to access information stored in these applications, but it would be costly to install and maintain the application on each desktop and to train all the users.
SharePoint solution: ASP.NET web parts, single sign-on
ASP.NET web parts can be developed and used to access and display information from other applications and data sources. Single sign-on can also be enabled to provide seamless integration with the application. This provides the user with an easy, usable method for accessing information, and the IT department can maintain the code centrally and not have to worry about desktop deployment and specific training for the line-of-business applications. SharePoint 2007 also supports web parts written for SharePoint 2003, which opens it to the capability to view content from multiple third-party software and web part vendors.
An organization needs to collaborate with another organization—for example, a marketing company that is doing research and developing collateral for the organization, or a client that the organization is working with on a specific project. The users from both organizations email documents and other information back and forth. Typically, these emails are sent to all people involved with the project so as to not leave anyone out. This can result in excess email traffic and emails being sent to users that they might not need (or want) to see.
SharePoint solution: Team site with extranet access
The Windows SharePoint Services 3.0 team site template fits the needs of groups of people working collaboratively. The site can be set up for extranet access, enabling outside parties to participate as team members. Using a team site over a traditional email-based method of communication provides all kinds of benefits, including giving people the ability to review only what they want to review, set up alerts to be notified when specific information changes, set up a process for approving final documents, participate in online real-time discussions, and look at prior document versions.
A team collaboration site is used by a group of people working together for a common end result or to complete a project. The success of the team or project depends on the effectiveness of the team and its ability to collaborate efficiently to complete the project. Therefore, the site is designed to facilitate team communications and sharing project information.
Typically, a team collaboration site is an internal, decentralized site that has a relatively small number of members. However, it can be configured to provide access for members external to the organization. When the site is implemented, it replaces the traditional file-share–based storage, use of email, and use of other traditional applications that the organization might have for storing and accessing documents and other information.
The general categories of business needs for this group are communications, project management, and document management. These needs can be mapped to SharePoint features as presented in this section:
A team collaboration site is implemented using a Windows SharePoint Services team site. A shared document library is created in the team site for document management and a Tasks list is created for assigning responsibilities. Content approval is enabled for the document library with the project manager assigned the role of approver. Document workspaces are also used for individual documents to incorporate direct access from Microsoft Office 2007/2003 applications. The team uses document discussions to communicate ideas about document contents and a general discussion for items relating to the project. The team site is part of a SharePoint implementation that has content sources defined for searching relevant information and archived documents.
This section includes some ideas to incorporate into the team site solution in congruence with the elements previously discussed.
The major project milestone tasks can be entered into a Tasks list, assigned to individual team members, and then tracked by the project manager. The Tasks list can also be used for status reporting.
Users can initially create documents using Microsoft Office 2007/2003 applications and then save them to a document workspace. The document workspace can be used by the team members as a conduit for instant messaging on project-related issues. Discussions within the document can be used for providing feedback and recommendations for document content.
When the document is ready for “publishing,” it can be moved to the shared library where it is reviewed by the approver. The approver can set up an alert to be notified when the new documents are added or modified within the library.
The corporate intranet is used for communicating information to employees and providing them with access to corporate line-of-business applications. The primary goals of a corporate intranet are to provide resources to employees that will help improve performance and to provide employees with centralized electronic access to corporate-based information for things such as policies, procedures, and roles and responsibilities. The benefits of a corporate intranet include providing an electronic means of accessing information as opposed to reliance on human intervention, providing an easier way of finding information, automating processes, and eliminating duplication of effort. The end result is a reduction in operational costs.
The general business needs of this group include searching for information, corporate communications, workflow processing, management of web-based content, and application integration. These needs can be mapped to SharePoint features as presented in this section.
The corporate intranet site is implemented using Microsoft Office SharePoint Server 2007 and includes Windows SharePoint Services 3.0 sites. Features used on the site home page include announcements, links (to other major corporate sites and applications), search, events, and discussions. In the Quick Launch area are links to lists, such as the Corporate Directory, and to shared libraries, including policies and procedures, newsletters, training, and benefits. Areas can be configured for operational groups within the organization and/or geographical groups within the organization, depending on the organizational requirements. Content sources that contain information useful to employees for doing their job can be added for indexing and search. Security and content approval can be implemented to enable controlled creation of sites and site content by a wide group of users. Integration can be provided for SharePoint-compatible applications by using preexisting integration web parts and/or developing custom web parts. Single sign-on can also be used to make it easier for users to access applications from within the Site collection.
This section includes some ideas to incorporate into the corporate intranet site solution in congruence with the elements previously discussed.
Disseminate important corporatewide information such as policy and procedure changes by using announcements. Put an expiration date on them. If users see the same announcements day in and day out, they have a tendency to ignore them.
Use a general discussion for obtaining employee feedback on policies, procedures, events, and other items of interest to employees. Moderate the discussion; have the Human Resources department or Legal department responsible for approving all items submitted to the discussion group to ensure that they are appropriate. Maintain a separate discussion forum for non-company-related items such as employees selling candy for their child’s youth group. This type of discussion should not take up valuable home page space, but should provide a link to it from the home page. Surveys can also be used to get specific input on a topic.
Maintain a corporate Events list in a Calendar view to provide visual impact for upcoming events. Depending on the corporate climate, things such as birthdays and vacations can be maintained on the corporate calendar as well as company events and holidays.
Store company policies, procedures, and forms in shared document libraries for ease of maintenance and for accessibility. The department responsible for maintaining the documents should also be responsible for the publishing of documents (approve contents), with read access provided to all other users.
For document libraries that contain company policies, procedures, and forms, include a “Frequently Asked Questions” document to provide answers to the questions asked most often.
Create content source groups for a logical breakdown of content for searching to prevent an inordinate amount of time from being spent performing searches.
Using Active Directory as the basis for the company directory assists in keeping the SharePoint-viewed company directory synchronized with Active Directory. A customized view of the directory can be created that filters and displays only relevant columns of information.
Using an application such as Microsoft Office InfoPath 2007/2003, InfoPath forms can be created, filled out, and stored in document libraries for access and processing. Alerts can be set up in the library for the person(s) that need to process the documents so that when something is submitted, they are notified and can review the items. Approval processing can also be used to approve and/or reject the documents. This concept could be used for things such as expense reports and other workflow documents. For a real end-to-end solution, application code can be developed to feed the data from the form documents into the appropriate external application (for example, the accounting system) for final processing.
Because there is generally a great deal of information on a corporate intranet, users should take advantage of the ability to create and customize their own personal site to include information they find useful. By using web parts that interface with Microsoft Outlook 2003/2007, the personal site can become the primary user interface.
The primary purpose of the customer extranet portal is to service the needs of customers. The customer extranet enables customers to find information about products and services, and place help desk calls. In some customer extranets, client access is provided for things such as invoice payment and viewing account status and payment history. The customer extranet can also be used for document collaboration and managing joint projects with the customer. The content for this type of portal can originate from internal and/or external sources.
The business needs of this group include searching for information, aggregating content from multiple sources, providing a dynamic view of relevant business information, collaborating on documents, sharing documents, managing joint projects, resolving issues, and providing a means for business transactions. The SharePoint features used to meet these needs are outlined as follows:
The customer extranet site is implemented using Microsoft Office SharePoint Server 2007 and includes Windows SharePoint Services sites. Depending on the specific implementation, Microsoft BizTalk can be used to exchange business application information and provide integration with business applications, while customized web parts provide the link to SharePoint. In addition, integration for SharePoint-compatible applications can be provided using preexisting web parts, developing custom web parts, and/or providing links to web-based front ends to business applications. Single sign-on can also be implemented to make it easier for users to access applications.
In addition, SharePoint now supports Forms-based authentication options in addition to standard Windows authentication. This allows administrators to build a custom ASP.NET Authentication provider to authenticate users against a foreign LDAP source or a SQL table, removing the need to have Active Directory accounts for all users.
Features available on the extranet portal home page include a Links list, announcements, discussion board, and search. The Quick Launch area can contain links to lists such as a limited corporate directory (with the listings for the salespeople and other people who customers typically deal with, such as accounting personnel) and frequently accessed shared libraries such as newsletters, training documents, and product information. Areas can be configured for support, product/service information, and billing information. A content source group can be created for the content in each area to make searches more targeted.
Document workspaces can be used to collaborate on documents. Team sites can be used when working with the customer on a joint project. Content sources can be created for product/service documentation and historical accounting information.
Security needs to be tight to ensure the integrity of customer-specific information. Restrictions need to be in place to prevent one customer from obtaining access to another customer’s data.
This section includes some ideas to incorporate into the customer extranet site solution in congruence with the elements previously discussed.
In addition to providing standard content, use audiences to target specific content to an individual or group of users.
Use the Support area for linking to an Issues list as well as a document library containing technical information. Links to supporting websites could also be in this area. Other possibilities would be to include a Top 10 Issues list as well as a download library.
Include a shared library with documents relating to products and services offered and/or links to corporate or other websites that have this information in the Product/Service Information area. There could also be a discussion board on this Area page so that clients could submit product- or service-related questions or requests and provide their ideas and feedback on products and services. When there is a need to get specific client feedback, a survey can be used.
Use applications such as Microsoft BizTalk Server 2006 and/or develop custom web parts for the Billing Information area to enable customers to access their invoice/payment information. Alternatively, provide links in this area to a site where invoice or payment information can be provided. There could also be web parts or links to applications or sites where customers can submit payments and/or orders.
Use team sites when working on projects with the customer. Include a Tasks list to document division of responsibility, a Contacts list for maintaining the contact information for members from both sides of the team, a custom “punch” list to document items yet to be completed, and a general discussion area as an alternative to email for documenting project-related correspondence in a central location. Create a weekly status meeting event or use a multiple meeting workspace for tracking and managing project status.
Microsoft Office SharePoint Server 2007 and Windows SharePoint Services 3.0 both allow for a great deal of collaborative capabilities that enable organizations to extend the capabilities of the environment beyond the borders of SharePoint itself. Through integration with other systems such as Office 2007/2003, BizTalk Server 2006, Exchange Server 2007/2003, and many others, SharePoint allows for centralized access and control over many of the processes that take place in businesses.
In addition to integration and collaboration with other infrastructure components, SharePoint is highly flexible in its capability to mold itself to the needs of an organization. Whether it is deployed as a customer extranet, a corporate intranet, or a team collaboration solution, SharePoint provides the built-in tools necessary to achieve the increased integration and efficiencies required by businesses today.
MOSS 2007 and Windows SharePoint Services 3.0 were specifically designed to be scalable, expandable applications. The ability to expand a SharePoint solution to fit the needs of various organizations is key in the adoption strategy Microsoft has for SharePoint, and features such as SharePoint farms, clustered back-end SQL database servers, NLB on front-end servers, and distributed services provide a great deal of flexibility for SharePoint administrators and designers. This flexibility allows SharePoint to scale to fit the current and future needs of organizations of many sizes.