| Once they are in place, successfully managing a Microsoft SharePoint Portal Server workspace or multiple workspaces consumes time and resources. Many different people, areas, disciplines, and SharePoint components are involved, not to mention the impact that business requirements and technology constraints play in an evolving portal solution. In the next few pages, we will drill down into managing the workspace from a number of different perspectives, including the following: -
General workspace utilization considerations, such as server configurations, server "sizing," number and characterization of users, number of documents or content sources, methods of organizing this portal data, and so on. -
Managing workspace security, such as how the Administrator, Coordinator, and other roles impact workspace management, and how portal data is otherwise protected or secured. -
Managing and securing content, for example, internal and external workspace content. -
Managing critical workspace components, such as approaches to managing and tuning indexes, building taxonomies, using categories and the Category Assistant, and more. -
Managing workspace capacity planning, such as growing vertically versus growing horizontally, and single versus multiple server configurations. -
Other workspace management considerations, such as how to manage and modify workspace settings, enable subscriptions, manage Web discussions, and more. Managing General Workspace Utilization Managing general workspace utilization starts with planning the initial SharePoint Portal Server deployment, and continues through the life of the portal. For our purposes here, we will examine the following: -
Planning exercises that drive the configuration of the Portal, and therefore the workspace(s) themselves -
Workspace configuration drivers, including the number and types of users, documents, and other content sources, and how all of this determines the role that each workspace may play in the overall portal solution -
Portal data organization, and how this evolves over time -
Portal user characteristics, and how this evolves as well  To read more on planning for SPS, see "Deployment Planning Considerations," p. 151. Before a software package or a server is ever purchased, the business community determines the need for an enterprise portal product to meet some kind of critical or value-added business requirement. Perhaps the need is identified as a simple data sharing or document management system, or perhaps a collaboration solution is identified as paramount to improving productivity. Regardless, the following considerations and questions come into play in terms of the baseline generic portal solution: -
How do we manage content today? -
Where do we maintain that data? -
How much raw data are we actually talking about? -
What kind of data or file types do we maintain? -
Who actually uses the data? -
How is the data organized? -
What are the retention period requirements? Once a general understanding of the data is determined, characterizing the users of that data ”users of the proposed SharePoint Portal Server solution who will actually leverage the data or portal capabilities to perform their jobs effectively ”must be performed. This includes determining who they are, when they need their data, how they currently get to the data they need today, and how they ultimately would like to find and access this data. One popular method of gathering this type of user-based information is through the use of questionnaires. Check with your hardware vendor or systems integrator to determine if they already have developed an SPS sizing questionnaire. To read more about the kinds of questions that are posed in a sizing questionnaire, and other SPS sizing- related tools and approaches, see "Planning Required Server Hardware," p. 131. After these needs are analyzed and documented, specific details may be uncovered that allow us to even better characterize the future SharePoint Portal Server end users, and provide us a baseline for hardware sizing of the development and production solutions, including the number and distribution of workspaces: -
Who can view documents? Edit them? Publish? -
What steps should be taken prior to publishing documents? Then, how should it actually be published? -
How important is tracking the history of a document? -
Are check-in or check-out of documents a concern? -
Are enhanced folders otherwise required, or are standard folders adequate? -
How are index updates scheduled? -
How are search scopes defined and created? For example, this last set of questions may drive creating dedicated index workspaces on one or more SharePoint Portal Servers, and some number of user/data workspaces on another server or servers. Some of these servers may be distributed due to geographical considerations, and some may require high-performance disk subsystems to store frequently accessed or updated company-wide documents. Still other workspaces may need to be configured to crawl external data sources, or be configured to cascade up to a corporate Portal. The variations are nearly endless, and speak to the diverse requirements of businesses and other organizations today. A key point to remember is that the practice of "sizing" and characterizing users does not end with the deployment of the Production SharePoint Portal Server solution. Rather, this practice carries on through the life of the portal in the name of capacity planning, previously addressed in Chapter 6. Managing Workspace Security While security concerns are interwoven throughout a SharePoint Portal Server implementation, from development through testing through the deployment of productive solutions, special attention is given here to managing workspace security for the following reasons: -
Folder layout security risks -
Role-based security risks -
Approval routes security risks -
Document Profiles security risks -
Document publishing and version control security risks Folder Layout Security Risks How documents are actually organized in the workspace is impacted by security ”this determines whether combining folders or separating a folder's documents into different folders is required. Security is a fundamental reason to divide documents into multiple groups. That is, some documents should not be seen by some users. In this case, the design of the folder layout is therefore impacted. By storing content in separate folders, access to each folder and therefore the content under each folder is better controlled. To learn more about folder security and how to hide a folder, see "Using Hidden Subfolders ," p. 288. Role-Based Security Risks Coordinators control security for documents and other content stored within each SharePoint Portal Server workspace by assigning users to the appropriate roles on a folder or a document. Coordinators manage roles by using either the Properties page for the specific folder, or via the Properties page for a workspace document. Note that roles may be assigned both at the individual folder level and at the top level of the workspace. Users may also be denied access to a specific document, for example if restricting an entire folder is too restrictive . This flexible role-based security model thus allows for customized access to content. A set of three security roles is offered by SharePoint Portal Server, providing not only a flexible but also a secure method for managing user access to content. SharePoint Portal Server uses role-based security to control access to portal content regardless of whether the content is being accessed via a Web browser, Web folders, or Microsoft Office. The actual permissions associated with each specific role cannot be changed, though, underscoring the importance of accurately assigning users to roles. SharePoint Portal Server includes the following roles ” Reader, Author, and Coordinator ”each of which has been discussed previously. However, in the context of workspace security and management, the following are important: -
The Author role must be respected in terms of the inherent security risks posed via publishing, not to mention the impact that an Author may have due to the role's ability to create, rename, and delete folders. -
Authors cannot change the roles or the approval policy on folders created by the Author or anyone else. -
The Coordinator creates indexes of updated content when necessary, or schedules this to occur automatically. To learn about SPS roles and overall role security, see "Roles," p. 281. As we covered previously, SharePoint Portal Server automatically assigns the Administrator who creates the workspace to the Coordinator role on the top level of the workspace, and on each folder. What is of importance here, though, is that this role may be assigned at a folder level. Thus, distributed permissions are supported ”if you assign a user to the Coordinator role at the folder level, that user is a Coordinator for that folder only. It should also be noted at this time that SharePoint Portal Server allows for a Deny Access security option, too, though on documents only. This setting supersedes all other access permissions except those associated with the local Administrators group. Specific users or groups may be denied access to view a particular document. In this way, the document is no longer visible to the denied user or group , not even in search results. Security Risks Associated with Approval Routes As a Coordinator, creating approval routes is a wonderful way of ensuring that a document is reviewed before publishing. When an Author chooses to publish a document, a route can be created to automatically push the document to one or more persons for review prior to publishing. Each of these individuals on the approval route has the option of approving or rejecting the document. However, these approval routes should be carefully managed, and they should be protected from unauthorized access as well. Indifferent management of approval routes can result in documents being routed to unauthorized Authors. Another result might include publishing a document without the benefit of adequate Q&A or review, potentially exposing or embarrassing an organization. SharePoint Portal Server offers two routing options for reviewing a document before publishing it: -
Serial approval routing (one approver after another, sequentially) -
Parallel approval routing (all approvers at once) Both types of approval routing consist of a series of steps that ultimately lead to publication. The Serial Approval routing process requires that each person approve the document prior to it moving to the next person. The last person's approval actually results in publishing the document. In Parallel Approval routing, any of the approvers may reject the document at any time. For more information on approval routing, see "Approval Process Types," p. 51, and "Bypassing and Canceling the Approval Process," p. 56. Regardless of the routing method, managing the approval routes ”keeping the names and associated email addresses up-to-date ”will not only reduce security risks, but also increase the overall quality of the documents residing on the SharePoint Portal Server production system. Document Profiles Security Risks While document profiles offer a way to add searchable information, called metadata, to a document, this metadata is not protected from a security perspective. That is, an unwary Coordinator might add a custom property like an Account Number to a document. The Account Number could make it easier to organize and find similar documents throughout the organization. But the Account Number is "wide open " to all eyes, for security settings in SharePoint Portal Server only restrict access to document contents, not metadata. Members of the Windows 2000 Everyone group can view all metadata associated with any document, including these custom properties. So while this extra information might help identify the document or allow for better searchability, if the metadata is sensitive in itself, the risk of abuse exists. Therefore, it is recommended that potential metadata be carefully reviewed prior to including it as a document property. Document Publishing Version Control Security Risks While SharePoint Portal Server supports both private and public versions of any document, either of these presents a security risk. For example, published documents might be made available to users without a need for access to the document. Worse, private or previous versions of documents may "float" and eventually be compromised due to a lazy Coordinator assigning Author roles too liberally. As an Author or Coordinator, a document may be published automatically each time it is saved to the server ”or multiple private document drafts may instead be maintained , with publishing only occurring once the document is complete. So even though SharePoint Portal Server records a document's history to help track changes and eliminate the possibility of people overwriting another user's modifications, the draft versions of each document represent a security risk that must be addressed. Securing Internal Workspace Content Special attention to managing internal content is paramount to maintaining a secure SharePoint Portal Server production environment. Of course, "too much security" works to the detriment of an organization in achieving its goals. Internal content stored in the workspace includes documents in both standard and enhanced folders. A Coordinator can easily add or remove users from either type of folder, or deny access to a particular document. In this way, securing internal content ”content within the local workspace ”is relatively straightforward. To do this, the Coordinator uses any of the following: -
The Security tab of Workspace Settings in the Management folder (for the workspace level) -
The folder Properties page (for the folder level) -
The document Properties page (for the document level) The next few pages detail the special considerations and gotchas that apply to managing workspaces housing content internally. Local Administrators Group Security Considerations SharePoint Portal Server assigns the Windows 2000 local Administrators group to the Coordinator role. What does this mean? All members of this local Administrators group can add themselves or others to the workspace as Coordinators. Then, each has the ability to configure security on any document in any folder. It is this ability to configure security that helps to safeguard data, should the data be accidentally or purposely made unavailable to those who should have access to it. That is, the local Administrators group can be used to restore roles on individual folders. Of course, distributing the ability to configure security can work against the better good of the organization supporting the portal. Pay particular attention to minimizing the number of folks in the local Administrators group to only those who require it. And note that disallowing access to a document does not affect the local Administrators group's access to that document. W2K Domain Controller Considerations Another interesting security consideration regards SharePoint Portal Server when it is installed on a domain controller. Domain controllers have no local Administrators group. Thus, only users explicitly assigned to the Coordinator role can specify security on folders. If the Coordinator inadvertently makes a mistake, therefore, no local Administrator is able to come to the rescue! Best practices for installing and deploying applications, whether SharePoint Portal Server or another departmental or enterprise application, dictate that dedicated infrastructure servers are preferred over combination application/infrastructure servers. That is, the services and function associated with Domain Controllers, DNS servers, WINS servers, or file/print servers, and so on are better left on a server platform dedicated to providing those functions. The increase in managing the number of servers is offset by the decrease in managing the day-to-day operations, not to mention future upgrades, associated with both the applications and the infrastructure services. NTFS and Workspace Security Considerations Internal content must be secured across all information sources ” SharePoint Portal Server exposes all information to the appropriate users according to Windows security settings. Therefore, a lack of a clearly defined NTFS security policy can pose a dramatic security risk. So, identify possible security risks and revise the security policy for each potential hazard to ensure accurate and sufficient permissions for the appropriate groups of people. Considerations in Securing and Managing Folders Securing internal content also requires managing the following set of folders and their subfolders, all of which support workspace management functions: -
Management -
Portal -
System -
Shadow -
Categories Note that only Coordinators on the top level of the workspace can manage these folders. Fortunately, except for the Management folder, these folders are not actually visible to typical workspace users. Also, it should be mentioned that security can not be directly configured on these folders. Workspace management functions, such as creating document profiles, are also available through the Web folders interface only. Other interesting security considerations exist ”some of these are discussed in the following sections ”all within the realm of securing and managing internal content in the workspace. Inheriting Security Settings When a new subfolder is created, it inherits security settings such as role settings from its parent folder by default. This may be overridden if not desired by customizing the role settings on the subfolder. If the parent folder's settings are changed, new subfolders may be specified to use the new settings. Folders inherit only the role settings, however. For enhanced folders, SharePoint Portal Server copies the approvers and the approval route to the subfolder when it is created; however, subsequent changes to this setting on the parent folder are not passed to the subfolders. Using Roles to Hide Folder Hierarchies In addition to general user-based security considerations, roles can be used to hide folder hierarchies as well, such that users may search for and find documents in subfolders but not actually have access to the parent folders. For example, a parent folder may contain subfolders with data that should not be viewed by certain organizations. Users in those organizations may be granted access to the other subfolders, but denied access to the parent folder and sensitive subfolders. In this case, the users can view the subfolders and content they need to see by using the subfolder's URL. Windows Explorer effectively hides the parent folder ”to the point where it is not even visible. Managing Compound Documents A compound document is a document that actually consists of multiple files and perhaps different file types, for example a Web page (which usually consists of HTML and various GIFs, JPEGs, and so on ”refer to Figure 9.8). What is important to note from a management perspective is that SharePoint Portal Server supports compound documents only in standard folders. Further, only Coordinators can configure security on a subfolder of a compound document. Figure 9.8. A sample illustration of a compound document in the form of a typical Web page, complete with JPEGs and GIFs.  IFS and IIS Access Considerations The Installable File System (IFS) and Internet Information Services (IIS) can fully access workspace folders. SharePoint Portal Server workspaces have an associated virtual directory created in IIS under the Default Web Site. Here, security may be managed for the dashboard site. Note that users can access the IFS by using Windows Explorer on the SharePoint Portal Server computer, and this access is read-only. SharePoint Portal Server maps IFS to network drive M:, unless a mapping previously existed. It is not recommended to use IFS (network drive M:) to create SharePoint Portal Server folders or documents, assign security to folders or documents, and so forth, as misuse of M: may result in data loss. Securing External Workspace Content Like content that is housed internally, content housed externally to the local workspace also poses certain risks to an organization. Managing external content, in large part, amounts to addressing those risks associated with actually managing Categories that contain documents and information from external content sources. Remember, "external" does not necessarily mean external to a company's data. The term "external" simply applies to any data housed outside of the local workspace. In a nutshell , managing external content boils down to the following rules of thumb or best practices: -
Separate external content from internal content when this makes sense from a business perspective ”store the content in separate folders to maintain excellent security. -
Do not count on share-level security, as it is not supported by SharePoint Portal Server. Only user-level security policies already associated with file shares and databases are supported. -
Pay particular attention to content sources that reside on other than NTFS file systems. In addition, SharePoint Portal Server security is impacted by the following SharePoint Portal Server limitations and constraints: -
File shares or Web sites employing Secure Socket Layer (SSL) for encryption cannot be crawled. -
Encrypted documents are not crawled. -
SharePoint Portal Server may not recognize local group accounts on servers being crawled if they exist in another domain. If you plan to crawl content located on a server in another domain, do not try to secure content by using local group accounts ”the users will not be able to view the crawled content. Instead, use universal group accounts, global group accounts, or domain local group accounts. -
SharePoint Portal Server does not enforce security on Web sites at query time. It specifies what Microsoft describes as a "per- path logon for crawling," but unfortunately , everyone has access to the results. -
Microsoft Exchange 2000 or 5.5 servers hosting encrypted messages are not crawled. -
While SharePoint Portal Server can access Unix systems or Novell NetWare systems via NFS, the corresponding client for the Unix or NetWare file system on the SharePoint Portal Server computer must be installed. And it must be noted that per-file security on non-NTFS file systems is lost ”SharePoint Portal Server maintains per-share security. -
When crawling non-NTFS file systems without the benefit of security mapping, SharePoint Portal Server logs on as anonymous (or guest), and does not have access to any content that is not accessible to any anonymous user. Thus, all crawled documents are searchable by any user. Administrators should be aware of this to avoid compromising content that is secured in a manner not compatible with NTFS. -
Generally speaking, all documents included in the index from a non-NTFS file system are searchable by all Readers on the SharePoint Portal workspace. SharePoint Portal Server does not have built-in support for any other network file system protocols, so security on the file share is enforced only as well as it is exposed by whatever NTFS emulation software is employed.  |
