In this Chapter
Throughout the preceding chapters, this book has provided useful tips and explanations of the many features and benefits available in the Windows Server 2003 operating system. In this chapter, the focus will take you a step further by introducing Microsoft technologies that will leverage the Windows Server 2003 platform to provide the next level of data administration.
File management and information retrieval have always been core Information Systems services benefiting from their own best practices and procedures. With an awareness of the key role these IS services play in any business enterprise, Microsoft has developed tools and services that greatly enhance the functionality, usability, and development of file management, team collaboration, and data lookup. Windows SharePoint Services and the new Office suite play a role in these new services that will be deployed in conjunction with Windows Server 2003 to help today’s administrators with the daunting task of managing the company’s knowledge and enhancing overall productivity.
This chapter shows how each of the new technologies fit into an organization’s knowledge management solution and provides tips on how and when to deploy them.
Windows SharePoint Services (WSS) is a downloadable Windows Server 2003 component used to create Web sites for information sharing and collaboration. SharePoint products and technologies are not new to the product offerings by Microsoft. What was previously released as SharePoint Team Services has now evolved into WSS. Like SharePoint Team Services, WSS is focused on creating sites for teams of information workers to make it easy for users to work together on documents, tasks, contacts, events, and other information. In addition, team and site managers can coordinate site content and user activity easily. The Windows SharePoint Services environment is designed for easy and flexible deployment, administration, and application development.
WSS is both an update to and a revision of SharePoint Team Services. As such, it offers several new features making it a more compelling alternative to third-party offerings. This section highlights some of these revisions with a concentration on information sharing and collaboration. Some of the new features built in to Windows SharePoint Services include
Document Versioning. Document versioning allows team members to automatically keep backup copies of files whenever updates are saved to a document library hosted on a team site. Additionally, team members can check out a document to lock it while editing, preventing other users from overwriting or editing it inadvertently.
Improved Lists and Views. Picture libraries, issue tracking lists, and calendar views are available components of team sites. Moreover, list owners can approve or reject items that are submitted to a site list and add comments. List owners can also apply permissions to a list, allowing only specific users to make changes. List templates can be saved and used as components on different team sites.
Support for Web Parts. Each list in a site is a Web part that allows easy customization and personalization just by using the browser. Users can customize default Web parts or add new Web parts to a page.
Self-Service Site Creation. After WSS is deployed, users have the ability to create sites on demand without involving the IT department by using Self-Service Site Creation. Site creation and management is still available through SharePoint Central administration.
Improved Storage Options. All documents, metadata, and site data can be stored in a database. You can choose to leverage SQL or MSDE to store all the data related to a site. This improves reliability by ensuring complete transactional integrity of the data, and enables the scale-out architecture.
Improved Searches through Indexing. When using SQL as a back-end database, WSS provides full-text indexing to provide site-wide searching of sites on the server.
Improved Security. WSS works with IIS 6.0 security methods, Windows Authentication, SQL Server authentication, and can be integrated with Active Directory.
By allowing all site data to be stored in a SQL Server database, the extensibility of a Windows SharePoint Services solution is greatly enhanced. Now, WSS covers deployment scenarios from a single server, single Web site solution to a full enterprise-level distributed server farm. The following sections cover the options available to you when leveraging WSS to provide team collaboration and information sharing to any size organization.
For a small organization, WSS can be deployed on a single server and can take advantage of an existing SQL Server to hold the database information or can use the MSDE option that can be included with the installation of WSS. To support a larger number of Web sites, WSS can be configured to leverage an existing SQL Server to host the site database.
To ease administration and enhance the end-user experience in the small organization scenario, you should include the following features in the WSS deployment:
WSS and MSDE
When WSS is installed using the default settings, the Setup program automatically installs MSDE (Microsoft Data Engine) and uses it to create the database for the Web site(s). No additional configuration steps are required to create the database. This installation scenario offers you the ability to host several Web sites without a lot of overhead.
For large organizations with administrators familiar with managing server farm solutions, the WSS deployment can be configured with a distributed solution. These types of solutions will use a SQL Server back-end, which in turn might be hosted on a server cluster. The Web front-end component of WSS can be distributed and sites hosted across several servers as well to provide fault tolerant redundancy and load balancing.
Large WSS deployments can benefit in terms of efficiency and enhanced user experience by taking advantage of the following recommendations:
Use existing Web servers. You can host the Web front-end component of WSS on existing Web servers that are hosting other Web applications. Features in IIS 6.0 allow for greater efficiency in hosting multiple applications on a single Web server.
Install language packs. If the organization is globally distributed, you can take advantage of WSS’s language packs. This allows for site creation in different languages around the world while maintaining a central administration.
Prompt for site use confirmation, and automatically deleted unused Web sites. You can configure WSS to delete sites automatically that are no longer being used. Prompts are sent out to the configured owner (and secondary contact) associated with a site after a certain level of inactivity. This will conserve database space and resources on the SQL Server(s).
Leverage domain groups. To ease administration, it is recommended to set permissions on a group level as opposed to individuals when managing Web sites in a large WSS deployment.
Although WSS is ideal for setting up collaborative team sites on a company’s intranet, this technology solution can be extended to the Internet as well. Especially if the company is an Internet Service Provider (ISP), the scalability and security of WSS can be leveraged to host public and private Web sites on the Internet. As with the large organization deployment, ISPs can use distributed WSS solutions with a SQL server back-end. Features within IIS 6.0 will keep different Web server processes isolated from one another.
Additionally, ISPs can configure their WSS solution to take advantage of these features:
Set Quotas for Sites. WSS allows you to set quotas for the amount of space a particular Web site will take on a database server. ISPs can set different rates for the size of the Web sites.
Use WSS in Active Directory Account Creation Mode. This allows for the automatic creation of user accounts in configured OUs on the ISP’s Active Directory domain. SharePoint site owners will then have the ability to create user accounts or invite users to collaborate on a Web site where existing domain accounts for those users do not already exist.
Provide Automatic Site Backups. This provides the site owners the capability to roll back to previous versions of their site without administrative overhead or technical service calls.
Finally, if a given organization collaborates with a partner organization, WSS can be used to set up team Web sites across an extranet. In this scenario both intranet and extranet users are able to view and interact with the same documents and information.
This solution is accomplished by using two virtual servers. One virtual server is configured with an internal address and uses Windows authentication. The other virtual server is configured with an external address and uses a different authentication method (using SSL for example). Both virtual servers are then configured to point to the same content, so that changes made from one access point are reflected on the data accessed from the other access point.
Because this solution provides access to a Web server from outside the firewall, it is important to secure the integrity of the server. Of course, this is a topic that takes the reader all the way back to Chapter 1, “Securing Windows Server 2003.” At a minimum, you will want to employ an antivirus solution and perhaps block certain file extensions on the server.
Providing a detailed description of installing and configuring WSS is outside the scope of this book, but it might be helpful for administrators considering WSS to be aware of some of the prerequisites and requirements involved with a WSS deployment.
The server that hosts the Web components of WSS depends on the operating system that is used. Enterprise and Datacenter editions of Windows Server 2003 have a greater hardware requirement than the standard server version. Because WSS can only be installed on servers that have the Windows Server 2003 operating system, it is best to follow the requirements for the OS when planning for the Web server.
With this in mind, the Web server hosting WSS installed with the Standard version of Windows Server 2003 should have at least a 550Mhz processor. WSS on an Enterprise Edition OS should have at least a 733Mhz processor. The recommended minimum RAM on either edition should be at least 512MB.
As noted earlier, WSS requires the Windows Server 2003 operating system. This can be either Web, Standard, Enterprise, or Datacenter edition.
WSS requires the NTFS file system. Further, the server must be configured as a Web server, which means it needs to have IIS 6.0 running with ASP.NET in Worker Process Isolation Mode. If the target server has been upgraded to Windows Server 2003 from Windows 2000, the Worker Process Isolation Mode will need to be manually changed.
To set the worker process isolation mode in IIS 6.0, follow these steps:
Open Internet Information Services Manager.
Right-click on Web Sites, and choose Properties.
On the Services tab, uncheck Run WWW service n IIS 5.0 isolation mode, as shown in Figure 26.1.
Internet Explorer 5.5 is the recommended minimum level of browser installed on the Web server although it will function with IE 5.01 and Netscape Navigator 6.2 or later.
WSS requires a database either on the server on which it is running, or in the case of a distributed solution, a separate server. The database requirement for WSS can be either Microsoft SQL Server 2000 with Service Pack 3, or Microsoft Data Engine (MSDE) 2000 with Service Pack 3. In order to have multiple back-end databases, WSS requires SQL Server 2000.
SQL Server and MSDE
If SQL Server is not installed on the server when WSS is installed, MSDE is installed automatically. If the command-line interface is used to install WSS, a separate server can be specified to use as the database.
Because WSS is a Web-based solution, the client side requirements simply involve having a browser. Microsoft Internet Explorer 5.01 is the minimum requirement, although IE 5.5 is recommended. Netscape Navigator 6.2 or later will also work. To save documents to the Web site directly from a Microsoft Office product, Microsoft Office 2003 is required. Microsoft Office 2003, and its relevant features, will be discussed in a later section of this chapter.
Another technology designed to build effective information sharing and collaboration is SharePoint Portal Server 2003. Built on the foundation of SharePoint Portal Server 2001, SPS 2003 provides additional collaborative features, application integration, and personalization to the enterprise knowledge worker. SPS 2003 is an enterprise portal that provides a central place to access, manage, share, and interact with relevant information, documents, applications, and people for quicker and better decisions, effective teaming, and streamlined business process through a familiar integrated user experience and mainstream platform.
From this description, it might appear that SPS 2003 provides the same functionality as WSS. Although in some ways this is true, there are some key differences between the two products. For administrators looking to streamline their knowledge workers’ business environment and productivity through SharePoint products and technologies, it is important to understand what sets SPS 2003 apart from WSS.
As has been described in the previous section, WSS is the engine for creating Web sites that enable information sharing and document collaboration. The primary objective of WSS is to take file storage to a new level, moving away from simply saving files to a network share to collaboratively sharing information with team sites. These sites provide communities for team collaboration, empowering users to collaborate on documents, tasks, contacts, events, and other information. WSS can be seen as proliferating smart places.
SPS 2003 takes advantage of WSS, connecting and aggregating these smart places which in turn facilitate smart organizations. SPS 2003 uses the technology of WSS to create sites that are portal pages, the components of which are Web parts and SharePoint document libraries. Through the use of portal pages, users can publish information and documents stored in their WSS sites to the entire organization.
Fundamentally, SPS 2003 can be seen as a tool to aggregate the disparate information contained in multiple Web sites across different business processes into a single solution with familiar management tools.
File and Data management has evolved considerably as a standard IT service. The ease and supportability of managed data improve drastically when you progress from sharing files from individual workstations to sharing files on network shares, e-mail public folders, and intranet Web sites. Microsoft has supported and improved the various methods by which data can be shared and managed at each progressive level. The following sections highlight these improvements and guide you in the direction of effective practices to increase the productivity of knowledge workers.
File sharing between workstations is a concept as old as the first connected personal computers. Making a file or directory available from one machine so that a group or user can access those files from another machine is perhaps the most common file sharing method available. Because this practice is still common in small office environments, Microsoft continues to make this functionality easier for the end user to accomplish. In Windows XP, Microsoft introduces the concept of Simple File Sharing.
The Simple File Sharing UI is available in a folder’s properties and configures both share and NTFS file system permissions. Access permissions are configured in Simple File Sharing at the folder level and apply to the folder, all the files in that folder, child folders, all the files in child folders, and so on. Files and folders that are created in or copied to a folder inherit the permissions that are defined on their parent folder.
Simple File Sharing
Note that even if Simple File Sharing is enabled on an XP Professional workstation, the interface will not be available after that machine has been added to a domain.
Windows XP Home Edition–based computers always have Simple File Sharing enabled. Windows XP Professional-based computers that are joined to a workgroup have the Simple File Sharing UI enabled by default. Windows XP Professional-based computers that are joined to a domain use only the classic file sharing and security interface. When the Simple File Sharing UI (located in the folder’s properties) is used, both share and file permissions are configured.
To turn Simple File Sharing on or off in Windows XP Professional follow these steps:
Double-click My Computer on the desktop.
On the Tools menu, click Folder Options.
Click the View tab, and then click to select the Use Simple File Sharing (Recommended) check box to enable Simple File Sharing as shown in Figure 26.2. (Click to clear this check box to disable this feature.)
If Simple File Sharing is enabled or disabled, the permissions on files are not changed. The NTFS and share permissions do not change until the permissions are changed in the interface. If permissions are set with Simple File Sharing enabled, only Access Control Entries (ACEs) on files that are used for Simple File Sharing are affected.
As workstations begin to share files in a domain environment, it becomes much more difficult to manage data if files are being shared from individual workstations. For this reason, the role of File Server plays a key role in networked knowledge worker environments. With the introduction of Active Directory, Microsoft has provided the system administrator a more effective means by which to enhance file and data management. Network shares that once were mapped via login scripts can now be published in Active Directory making them easily searchable to the knowledge worker.
Moreover, using the Group Policy features available in Active Directory, you can manage how the workstations in the domain environment access shared network files. Primarily the use of Group Policy settings for the management of Offline Files will enhance the knowledge worker’s access to shared network files.
Simple File Sharing
Note that even if Simple File Sharing is enabled on an XP Professional workstation, the interface will not be available after that machine has been added to a domain.
By using the Offline Files feature, knowledge workers can continue to work with shared network files even when they are not connected to the network. If the connection to the network is lost, the view of shared network resources that have been made available offline remains the same as when connected. The access permissions to those files and folders are the same as if they were connected to the network. When the status of the connection changes, an Offline Files icon appears in the notification area and a reminder balloon appears over the notification area to notify the user of the change.
When the network connection is restored, any changes made while working offline are updated to the network by default. When more than one person on the network has made changes to the same file, each user will have the option of saving the offline version of the file to the network, keeping the other version, or saving both.
Using either Computer or User based Group Policies, you can control how workstations can leverage the Offline Files feature. Offline Files settings are located in the Group Policy Editor under the following two contexts:
Computer Configuration/Administrative Templates/Network/Offline Files
User Configuration/Administrative Templates/Network/Offline Files
These settings can be used to enable/disable the Offline Files feature, set mandatory network paths, set synchronization behavior, and more. How managed the knowledge worker environment is determines the amount of control these policies should incorporate.
Intranet file sharing represents the next level of file and data sharing management because it moves the focus of the knowledge worker from the context of the network share to the Web browser and Web site. Microsoft introduced this concept with SharePoint Team Services (STS), which provided a Web site engine that would index shared data for searching by team members granted access to the site.
As with many new technologies, STS was met with challenges. STS proved to be difficult for administrators to manage, and difficult for knowledge workers to leverage. Early efforts at Intranet file sharing provided a great concept, but many users trying to post their files for collaboration on team sites ran into difficulties. As system administrators had to learn how to manage the new Web site functionality, they also needed to add support to their end users trying to post and access documents. For some environments the technology seemed to require additional IT resources to maintain support which lead to a rather lukewarm reception.
Building on the sound concept of Web-based file sharing and collaboration first presented in STS, Microsoft has developed Windows SharePoint Services (WSS) alleviating much of the confusion and administrative overhead found in the earlier product. Improvements found in WSS that are key to data management are summarized in the following list and will be elaborated on in the proceeding sections of this chapter:
Integration into the Windows Server 2003 File Services. This alleviates the problems associated with posting files to an intranet site.
Uses the same File/Save functionality in Office applications. Users have the capability to save to and access files from WSS Web sites directly by using the office applications with which they are already familiar.
Data indexing is improved for better searching capabilities.
Flexibility in database options. Information can be stored in classic network fileserver data, or can leverage MSDE or Microsoft SQL back-end databases for enhanced scalability and redundancy.
Documents can be revision controlled. This preserves backup copies of data whenever updates are saved to a document library hosted on a team site.
With WSS, knowledge worker team members can create a team intranet site, and then upload files using a browser. With Microsoft’s new Office suite, interaction with WSS can also be conducted directly through the Office programs used to create and modify the shared documents. Microsoft Office Word 2003, Microsoft Office Excel 2003, or Microsoft Office PowerPoint 2003 are each integrated with Microsoft Windows SharePoint Services. Key areas where this integration can simplify file sharing between knowledge workers Document Workspaces, the Shared Workspace task pane, and shared attachments.
A Document Workspace site is a Microsoft Windows SharePoint Services site that is specifically targeted for the collaboration of one or more documents. Team members can easily work together on a shared document either by working directly on the Document Workspace copy or by working on their own copy, which they can update periodically with changes that have been saved to the copy on the Document Workspace site.
The documents can be accessed through a browser by typing in the URL for the workspace, or with Office 2003 applications, directly through the application.
The Shared Workspace task pane, shown in Figure 26.3, opens automatically when a user opens a document that is stored in a document library.
To open the Shared Workspace task pane manually so you can add a document to an existing workspace or create a new one, choose Shared Workspace from the Tools pull-down menu within an Office 2003 application.
In addition to displaying Web site data in the Members, Tasks, Documents, and Links tabs, the Shared Workspace task pane provides information about the active document on the Status and Document Information tabs:
Status—. This tab lists important information about the current document, such as whether the document is up to date, whether it is in conflict with another member’s copy, and whether it is checked out.
Document Information—. This tab displays properties associated with the document, such as when it was last modified. If the document library where the document is stored defines custom properties for documents, those custom properties are also displayed on the Document Information tab.
When a team member sends a file as a shared attachment in Outlook 2003, a Document Workspace site is created for the attachment in the Microsoft Windows SharePoint Services site specified by the sender. The Document Workspace created will take the same name as the attached file.
The sender of the shared attachment becomes the administrator of the particular Document Workspace, and all the recipients become members of the Document Workspace. The recipients are then added to the contributor site group.
Recipients can open the attachment, or they can follow the link that is added automatically to the message. The link goes to the home page of the Document Workspace, where a copy of the e-mail attachment is stored in the Shared Documents Library.
By implementing WSS, you provide knowledge workers the capability to search through the entire Web site content on a particular virtual server. The searching capabilities of WSS have been improved from those offered with FrontPage 2002 and STS v1. In STS, searching was implemented through Internet Information Services (IIS) catalogs. This limited searches to documents on the file system. This limitation prevented users from being able to search the contents of lists or discussion board items. With the introduction of WSS, and its ability to leverage SQL Server 2000 for database information, the searching capabilities have been expanded to include all site content. Because all site content is contained in the database, it can be fully indexed for data lookup.
To make Web site searching available to knowledge workers through WSS, the back-end database implemented must be SQL Server 2000. Using the MSDE back-end does not provide this functionality. WSS uses the SQL Server 2000 full-text searching feature to search for Web site content.
The search engine on a Windows 2003 server can create a search index on a per virtual server basis. This means that search is either turned on or off for all top-level Web sites and subsites on a particular virtual server. Subsites inherit the search settings from parent sites. If search has not been enabled for a virtual server, the search links will not appear in the Web sites that reside on that virtual server.
Searching Features for Web Site
Another way to get searching features for Web site content is to implement SharePoint Portal Services 2003. In fact, SPS adds several search features not available to SQL Server 2000, including survey lists, attachments to list items, and Office 2003 file properties (such as “Author”).
When full-text search is enabled in Windows SharePoint Services, a new empty catalog is created by default. Content is added to this catalog as it is added to the particular Web site. Aside from enabling and disabling full-text search, any search management or monitoring must be done from within SQL Server 2000 with the SQL Server administration tools.
When users search SharePoint sites by using SQL Server full-text searching, the search is performed by using a FREETEXT statement. Using FREETEXT allows searching by intent—all terms are stemmed, so that the query looks for all inflectional forms of each query term. For example, if a user queries for "construct", the query also returns results including “construction”, "constructed", "constructing", and so on.
Although WSS with SQL Server 2000 is an appropriate solution to provide search capabilities to small and medium sized organizations, it is important to understand the limitations that this implementation might pose to large server farm type deployments. Search catalogs in SQL Server 2000 can use up to 40 percent of the hard disk space that data uses. Moreover, there is a hard limit of 256 search catalogs per server. There will be performance issues when a search catalog table reaches one million rows.
Another item to keep in mind with SQL Server 2000 is that although it performs linguistic analysis on full-text search catalogs, it can only support one language per database. As mentioned earlier in the chapter, WSS can support multiple languages. So, if a large-scale WSS deployment is intended to support indexing across multiple languages this will require additional SQL Servers to support.
Before knowledge workers can begin to search the Web site’s contents, the searching function must be enabled. To enable search, you must install the full-text searching feature for SQL Server 2000, and then proceed to enable search in WSS.
Full-text searching is usually installed by default on SQL Server 2000, but if this has not been done initially, it can be added easily through the SQL Server Setup tools. To install full-text indexing on SQL Server 2000, perform the following steps:
Run the SQL Server 2000 Setup program.
On the setup screen, click SQL Server 2000 Components, and then click Install Database Server.
From the Welcome screen, click Next.
On the Computer Name screen, select the computer type, and then click Next.
When the Installation Selection panel is displayed, select Upgrade, Remove, or Add Components to an Existing Instance of SQL Server, and then click Next.
From the Instance Name panel, clear the Default check box, and then in the Instance Name box, select your SQL Server instance for Windows SharePoint Services and click Next.
Select Add Components to Your Existing Installation, and then click Next.
On the Select Components panel, in the Sub-Components list, select Full-Text Search as shown in Figure 26.4, and then click Next.
Click Next again to begin the installation.
After SQL Server 2000 has been configured to support full-text searching, you can enable search for Windows SharePoint Services. To enable searching for WSS, perform the following steps:
On the server computer running Windows SharePoint Services, click Start, point to All Programs, point to Administrative Tools, and then click SharePoint Central Administration.
Under Component Configuration, click Configure Full-Text Search.
In the Search Settings section, select the Enable Full-Text Search and Indexing check box as shown in Figure 26.5.
Using conventional methods for managing documents, particularly in the network file share model, there are no built-in revision controls that protect the integrity of data. In the most primitive cases, there is no revision control and old documents are simply replaced when they are updated. In several other cases, revision control is ad hoc and operational procedures designed to maintain a level of control often fail or are confusing. What you are left with is a file structure that resembles Figure 26.6.
The file structure displayed in Figure 26.6 is an example of how companies try to maintain a level of history over the course of a particular document’s development. This example demonstrates the difficulty in standardizing the process because it appears that there are a couple of different naming conventions being used for the same document. It also demonstrates the challenge to clearly present the exact progression or history of the document, or to even specify which file is the latest revision. This method also invites the possibility for more than one user collaborating on the document to make changes that do not end up in the most current working version.
One of the key benefits of WSS is that it gives knowledge workers a clear and consistent method for maintaining versions of documents. It also protects the integrity of the data in documents through a check-in/check-out functionality so that collaborative users do not step on the efforts of other team members.
Document versioning allows collaborating team members to keep multiple versions of a document. If a change needs to be reversed, a knowledge worker with the appropriate rights can restore the previous version and continue working. A Version History command is included on the drop-down list users see when they click the arrow next to a document name and on the toolbar in the Edit Properties page for the document.
The Version History command is also available in client applications compatible with WSS, such as the programs found in Office 2003. When the user clicks Version History, a list of the previous versions of the document appears. The user can open an old version, restore a version (replacing the current version), or delete an old version.
Saving Files
If the user saves the file again, without closing the file, a new version is not created. If the user closes the application he or she is using to edit the file, and then opens it and saves the file again, another version is created.
Preserving Data Integrity
To preserve the integrity of data, only members of the Administrator and Web Designer site groups for a site can determine whether document versioning is enabled for a particular document library.
Versions are automatically created whenever a user updates a document in a document library on a site in which versioning has been enabled. It is important to understand under what circumstances versions are created. Versions are created
When a user checks out a file, makes changes, and checks the file back in.
When a user opens a file, makes changes, and then saves the file for the first time.
When a user restores and old version of a file (and does not check it out).
When a user uploads a file that already exists, in which case the current file becomes an old version.
Document versioning is enabled through the Settings page for each particular document library. To enable document versioning for a document library, perform the following steps:
Navigate to the list, and on the left link bar, click Modify settings and columns.
On the Customize Document Library page, click Change General Settings.
On the Document Library Settings page, in the Document Versions section, under Create a Version Each Time You Check In a File to This Web Site, click Yes as shown in Figure 26.7.
Checking documents in and out allows users to obtain exclusive write access to a document, eliminating potential data loss and the need to merge changes from collaborative authors. When a user checks a document out, that user is the only user who can save changes to the document. Other users can read the document, but they cannot make changes. The user who has the document checked out can update the document, and see the latest version of the document, but other users will not see the updates until the document has been checked back in.
In the event that a checked-out document becomes lost or corrupt, members of the Administrator and Web Designer site groups for that site can override a document check-out if necessary, and force the document to be checked in with the previous version.
The Cancel Check-out Right
Individual users can also be assigned the Cancel Check-out right without having to be made a member of the administrator or Web designer site groups.
Assuming the user has the appropriate rights, a user can cancel a checked-out document and return it to the previous version by performing the following steps:
WSS can be used to manage data in a hierarchical fashion by creating a top-level Web site with subsites to divide site content into distinct separately manageable sites. The top-level sites can contain several subsites; subsites in turn can also contain several subsites. The entire structure of top-level and subsites, called a Web site collection, can be managed centrally.
This structure allows knowledge workers to have a main working site for the entire team, plus individual working sites or shared sites for side projects. Top-level Web sites and subsites allow different levels of control over the features and settings for sites.
The hierarchy in WSS is similar to the hierarchy in Active Directory, which is structured with a top-level domain, with Organizational Units (OUs) comprising the sub divisions. Like AD, administration of subsites in WSS can be delegated to Team administrators. A subsite administrator would only have access to control settings and features of his particular subsite, without requiring control at the top-level site.
Depending on the level of control that is desired for a particular Web site collection, you can individually create and control the entire hierarchy, or can allow users to create their own top level Web sites.
Web site creation can be performed from SharePoint Central Administration or from the command prompt. To create a top-level Web site from SharePoint Central Administration, perform the following steps:
Under Virtual Server Configuration, click Create a Top-level Web site.
On the Virtual Server List page, click the virtual server under which you want to create the top-level Web site.
To create a site under a predefined URL path for the virtual server, on the Create Top-level Web Site page, select Create Site Under This URL; in the Site name box, type the name for the top-level Web site; and then in the URL path box, select the path to use.
To create a site at a predefined URL path, select Create Site at This URL, and then in the URL path box, select the URL to use for the top-level Web site.
In the Site Collection Owner section, type the account name (in the form DOMAINusername) and e-mail address (in the form [email protected]) for the user who will be the site owner and administrator.
In the Site Language section, select the language to use for the top-level Web site.
Click OK.
Creating the Full URL
The name and URL path are combined with the server name to create the full URL to the site. For example, on http://servername, if you create a top-level Web site at the /sites URL path, and use Site001 as the name, the full path to the new top-level Web site is http://servername/sites/site001.
As a best practice for enterprise environments, at step 5, identify a user as the secondary owner of the new top-level Web site. In the event that the primary owner of the site is unavailable for an extended period of time, the secondary owner receives all the notifications directly related to the site and can respond accordingly.
Depending on the amount of customization and control you want to allow users, you can let them create either top-level Web sites or sub-sites. The Self-Service Site Creation feature gives users the ability to create top-level Web sites on their own. This feature enables the knowledge worker to manage data (they can do it themselves) and reduces administrative overhead.
The user does not need administrator permissions on the server or virtual server, only permissions on the Web site where Self-Service Site Creation is hosted. The user simply enters some basic information and the new top-level Web site is created with the user as the owner and administrator.
Users can also create subsites of any site for which they have the Create Sites and Workspaces right. The Create Sites and Workspaces right is included in the Administrator site group by default, so any member of the Administrator site group for a site can create a subsite of that site.
Self-Service Site Creation is enabled at the Configure Self-Service Site Creation page for the virtual server that will host the sites. When Self-Service Site Creation is enabled, an announcement is added to the home page of the top-level Web site on that virtual server, with a link to the sign-up page. Users can click the link to go to the sign-up page and create their sites.
To enable Self-Service Site Creation for a virtual server, use the Configure Self-Service Site Creation page for that virtual server, and perform the following steps:
On the SharePoint Central Administration page, under Virtual Server Configuration, click Configure Virtual Server Settings.
From the Virtual Server List page, click the virtual server to enable.
With the Virtual Server Settings page displayed, under Automated Web Site Collection Management, click Configure Self-Service Site Creation as shown in Figure 26.8.
In the Enable Self-Service Site Creation section, next to Self-Service Site Creation Is, select On.
To require two contact names for each site, select the Require Secondary Contact check box.
Every IT organization places security as a top priority for the systems and services it provides. Security as it relates to managing the knowledge and data of the company is equally paramount. Just as this book begins with an account of security measures and best practices in Windows Server 2003, it seems fitting to complete the book on the same note.
For traditional data and user management, Windows Server 2003 leverages the NTFS file system, Active Directory, and group Policies as detailed in Chapter 5, “Managing User Rights and Permissions.” As Windows SharePoint Services is installed on Windows Server 2003, the best practices detailed in that chapter also apply here. In addition to security practices that leverage the file system and Active Directory, though, WSS has its own security measures built in to ensure that data managed through the SharePoint is equally secure.
Many of the security measures of WSS have been touched on in various points throughout the chapter. The following is a rundown of features that maximize secure data management through SharePoint technologies:
User Authentication. The process used to validate the user account that is attempting to gain access to a Web site or network resource. The administrator manages security using Windows users and security groups either locally or at the domain level.
SharePoint Administrators Group. A Microsoft Windows user group authorized to perform administrative tasks for WSS. When WSS is installed, this unique administrative group is created.
Site Groups. A means of controlling the rights assigned to particular users or groups in WSS Web sites. Similar to delegation of control in Active Directory, site groups help to distribute the management of data in the WSS framework. There is a predefined list of site groups for each Web site (Administrators, Web Designers, and so on). Granting a user a particular level of access to a Web site is accomplished by assigning that user to a site group.
Administrative Port Security. A means of controlling access to the administrative port for WSS. Help secure the administrative port by using Secure Sockets Layer (SSL) security or by configuring the firewall to not allow external access to the administration port, or both.
Microsoft SQL Server Connection Security. When SQL is an integrated component of the WSS solution, there is an additional layer of security added. Use either Windows Integrated authentication or SQL Server authentication to connect you to your configuration database and content database.
Firewall Protection. A firewall helps protect your data from exposure to other people and organizations on the Internet. WSS can be placed either inside or outside the organization’s firewall depending on the function it will play. If WSS will be used to create an extranet or to provide services on the Internet, it is a best practice to use a DMZ network configuration to protect the WSS server.
By default, Windows Server 2003 provides a set of security settings called Internet Explorer Enhanced Security Configuration. These settings limit the types of content that a user at the server can view using Internet Explorer, except for sites listed in the Local intranet and Trusted sites zones. For example, by default, scripting on Internet pages will not run when the site is accessed from the server.
The goal of these settings is to help ensure that a local user on the server will not download a virus or other harmful files from the Internet and infect the server. This is especially pertinent to Web servers. The security features of Internet Explorer Enhanced Security Configuration do not affect remote users viewing content on the server, only users running Internet Explorer on the server computer itself.
Using Internet Explorer Enhanced Security Configuration on a Web Server running WSS prevents some code necessary for viewing site pages or HTML administration pages from running. Again, remote users with proper access rights can still view the pages correctly, but a user running Internet Explorer on the server computer will be unable to view or administer the site. Note also that the user at the server computer will be unable to view and administer a remote SharePoint site because of the security settings.
Adding All the URLs for Virtual Servers
If you choose to add all the URLs for virtual servers and domain named sites to the Local Intranet zone of IE in a Web farm implementation, this must be done on each front-end server that is participating in the WSS Web farm. Depending on the size of the implementation, this could be a time-consuming process.
There are ways to get around this security issue so that a local user can run the necessary scripts from the WSS server and still maintain a level of security:
For simple SharePoint installations, the local administrator can run WSS by using the default localhost name. By default, the SharePoint Central Administration link uses the localhost naming method. This method is not a good option for more complex SharePoint installations that use host-header based site or Web farms.
The recommended workaround that preserves the highest level of security involves adding the URLs for all of the hosted virtual servers to the Internet Explorer Local intranet zone. In a Web farm, the administrator must also add the URLs of all domain named sites to the list of local intranet sites.
Internet Explorer Enhanced Security can also be uninstalled. This is perhaps the least secure alternative. If you are not concerned about users working locally at the Web server, this will resolve any problems with scripts running as expected. This alternative requires the least amount of time to configure as the Internet Explorer Enhanced Security can be uninstalled quickly using Add or Remove Windows Components.
Windows SharePoint Services elevates knowledge management to a new level. Rather than simply storing files in network shares, knowledge workers can now leverage file versioning, check-in check-out protection, and flexible customizable Web views to share company data. Despite the fact that WSS was engineered to scale to large Web farm style deployments that can accommodate worldwide collaboration, WSS runs just as well and is quickly deployed in small business and departmental environments. Finally, even though the knowledge worker gains the flexibility and customizing features of a Web-based application, WSS preserves a high level of security through a variety of built-in security measures while leveraging the improved security of Windows Server 2003.