In the 2007 Microsoft Office System architecture, all applications enjoy compatible storage and retrieval operations because they all use the same storage and retrieval services. The same holds true for all common services throughout the enterprise. Security can be administrated uniformly across the organization because all applications make use of the same security services in the software infrastructure.
The 2007 Microsoft Office release is a strong move toward true Service-Oriented Architecture (SOA). Office 2007 implementations reap the benefits of modularity, extensibility, scalability, and separation of concerns. Although most architecture experts agree that SOA is the next logical step in software evolution, it can present challenges for administrators. How does one monitor, manage, and administrate a whole environment full of independent services? To make SOA practical and to provide consistent support for system administrators, the services that compose the Microsoft Office system have been grouped into applications that serve specific purposes. This organizational strategy makes all the various services understandable and manageable without detracting from the benefits of SOA.
All SharePoint Server 2007-specific services can be accessed only through SharePoint Server 2007. They are still enterprise services, but they are located and accessed within the SharePoint Server 2007 container. All services specific to Internet Information Services (IIS) are similarly grouped and accessible within IIS.
The grouping of services into applications makes deployment, organization, training, and administration far easier and simpler. The 2007 release of Microsoft Office offers the best of both worlds. From the bottom up, its architecture is organized as a series of discrete and independent services. From the top down, it is organized into applications that serve as containers for those services.
SharePoint Server 2007 is the application that is responsible for providing document repository services, document workflow services, intranet sites, search indexing, and collaboration services.
Figure 2-1 represents a logical view of the service architecture for the 2007 Microsoft Office system. At the bottom of the diagram are the more fundamental services. Each succeeding layer then uses the services below it to build more specific services to support business operations. At the top level are specific business services that can be used independently or organized to support business applications and processes. A quick look shows that applications such as SharePoint Server 2007 are composed of discrete services located at various levels of this diagram. (See Figure 2-1.)
Biz Data Catalog
Data in Lists
SQL RS\AS Integ
OM and SOAP
Web Parts | Personalization | Master Pages | Provider Framework (Navigation, Security…)
Operating System Services
You can see in Figure 2-1 that at the lowest level of the architecture is Operating System Services. This layer is responsible for directly managing the physical and logical devices that make up the physical infrastructure for the environment. Here are the drivers and administrative tools that can be used to manage, configure, and optimize the network, peripheral, and platform hardware. The architecture principle of "separation of concerns" means that the 2007 Microsoft Office system is isolated from the operating system to a large extent and is treated as a service. The 2007 Microsoft Office system is therefore able to run on Windows Server 2003 platforms as well as future releases of the operating system.
Microsoft SQL Server provides a common database service, shown in Figure 2-1, that is intended to meet all data storage, retrieval, modification, and destruction requirements across the enterprise for SharePoint Server 2007. By using one database platform, the Microsoft Office system removes the requirements of maintaining separate and often incompatible databases in the same environment. Because the storage services are isolated so that they are independent of the applications, you can modify, extend, or replace the database service without affecting applications and services that depend on it.
How do you know when a document is a final version or a draft? How do you know if a proposal has been accepted and approved? When is information official and when is it unofficial? Workflow services, provided by Windows Workflow Foundation (WF), shown in Figure 2-1, provide a method for formalizing, enforcing, recording, and auditing the progress of a document through formal work processes.
With workflow services, you can tell whether a document has been properly processed, reviewed, approved, updated, published, and destroyed. Each of these business processes can be defined, automated, enforced, recorded, and audited along with the document. With the advent of information control and quality standards such as the Health Insurance Portability and Accountability Act (HIPAA), Sarbanes-Oxley, and the various Department of Defense (DoD) regulations, it is becoming increasingly important to provide a metadata trail showing the execution of processes that led to the creation, modification, approval, publication, and ultimate destruction of a document. By leveraging workflow services in the architecture, it is possible to standardize and accumulate process metadata throughout the enterprise to govern the reliability and use of documents.
The supporting services for SharePoint Server 2007 are pulled from the .NET provider framework and ASP.NET 2.0. Web Parts, Web Part pages, master pages, personalization, and other features of SharePoint Server 2007 are dependent directly on the services and architecture provided at this layer.
ASP.NET 2.0 is a common and well-known developer platform. Building Windows SharePoint Services 3.0 to leverage the ASP.NET development platform ensures that there is a more solid developer platform for third-party integration and extensions, and it makes Windows SharePoint Services 3.0 more accessible to the ASP.NET developer community. Following are some examples of how Windows SharePoint Services 3.0 leverages features and built-in functionality in ASP.NET.
ASP.NET has its own page rendering engine. Windows SharePoint Services 3.0 will get out of the business of rendering pages and trust ASP.NET to render the pages on its behalf. This means that Windows SharePoint Services 3.0 pages will run in ASP.NET direct mode.
ASP.NET has the ability to ensure that pages are not complied into a dynamic-link library (DLL) before Windows SharePoint Services 3.0 can use them. Instead, the page is parsed and the allowed controls in the control tree are rendered on the page. This means that administrators are be able to set at the application scope through the Web.config file which controls can be rendered on the page. In addition, ASP.NET allows you to override the application scope by allowing approved controls to be set on the individual page within the application. This helps you guard against malicious code being compiled into pages in Windows SharePoint Services 3.0. If needed, you can still give trusted developers the ability to author new code directly in pages.
Administrators have the ability to set permissions on ASP.NET controls via the bin directory on the server. Configuring control permissions at this level affects all applications and pages across the entire SharePoint farm. The errors that are given vary depending on where the control resides. For example, an unsafe control in a Web Part zone will mean that an error Web Part is rendered. An unsafe control outside a Web Part zone will cause the entire page to not render correctly. An "unsafe" control is one in which the control does not have sufficient permissions in the Safe Controls List to render properly.
|More Info|| |
For more information on how to configure the Safe Controls List, please see Chapter 31, "Administrating Code Access Security."
The entire Web page that is rendered in the user's browser is actually a combination of two pages: a Master Page and a Content Page (or Page Layout). Master pages are associated with one or more content pages and are used to render the "chrome," such as the left Quick Launch bar and the top navigation bar. Master pages are built by developers whereas content pages are created and managed by end-users.
Master pages usually contain the branding and other features that needs to be consistent across multiple sites and site collections. ASP.NET 2.0 renders these pages for Windows SharePoint Services 3.0.
A Web Part and the Web Part framework are built into the core of the ASP.NET platform. A Web Part is a custom control assembly that uses a Web Part description file in either the Windows SharePoint Services 3.0 format (.dwp) or the ASP.NET 2.0 format (.webpart). The Web Part description file can be stored and referenced on any computer; it contains XML data that describes an instance of the Web Part. The Web Part .NET assembly is a DLL that must be installed and registered on each Windows SharePoint Services computer that uses the Web Part. The Windows SharePoint Services 3.0 architecture allows for backward compatibility with Windows SharePoint Services 2.0 Web Parts.
In SharePoint, data cannot be exposed or hosted outside a Web Part. All data is held ultimately either as a list item or as metadata to the list or a list item. Applications are also exposed using Web Parts, where functionality is broken up into Web Parts and the summation of the Web Parts forms the overall application.
Personalization in SharePoint Server 2007 is rich and multifaceted. Users with appropriate permissions can drag and drop Web Parts onto a Web Part page and even create new pages within a site. They can target information to other users based on their audience group membership, Active Directory group membership, or e-mail group membership. In addition, users can expose information about themselves and then use the privacy controls to decide who gets to see which piece of information they have posted. Moreover, users have the ability to find out what social groups they are members of and then add members of those groups to their own social groups.
Master pages (.master) are a much improved concept over the ghosted pages concept, which in Windows SharePoint Services 2.0 was the way pages were shared between sites. Windows SharePoint Services 3.0 moves to the concept of master pages as the method of sharing pages between sites.
With master pages, a developer can specify all the shared elements in the .aspx pages in the master page, and have content pages that add the elements specific to the content page. In Windows SharePoint Services 3.0, there are regions on each page that are common to all pages, such as the navigation bar or title area. Using master pages to present the Windows SharePoint Services 3.0 sites makes sense because master pages can be used to create regions that are standard across all the instances of the page and create other regions that are uniquely editable in those same instances of the page.
You'll need to differentiate between master pages and page layouts. Master pages contain controls that are shared across multiple page layouts, such as navigation. Page layouts (sometimes referred to as content pages) control the content of a page. Each page layout has at least one associated content type that controls the kind of content that can be stored on the page. By default, there are three content types:
Each content type for page layouts contains columns that define content that can appear on a page along with the metadata that is associated with the layout page.
Content in a layout page is stored as SharePoint list items in the Pages document library. When users view or edit the page, content is pulled from the SharePoint list and displayed to the user.
Together, the master page and the layout page form a page instance, which is the look and feel of the page in the SharePoint site. Page layouts can be used by all page instances that are based on that page layout. Master pages can be used by all page instances in a site. Page instances based on the same page layout in different sites can use different master pages.
The root site for a site collection has a document library called the Master Page and Page Layout Gallery. All page layouts and master pages are stored in this document library. Like other document libraries, this document library supports versioning and workflow, so you can use those features when you need to create new master pages and page layouts.
There is a Master Page Gallery created for every site in SharePoint Server 2007, but you can only create new master pages with the page layouts stored in the Master Page Gallery of the top-level site in the site collection.
The SharePoint Designer 2007 is the preferred tool for creating and customizing master pages.
All this talk about services and standards raises an important question: how in the world does it work? All services in the in the 2007 Microsoft Office system release and SharePoint Server 2007 environment have to communicate and operate within certain rules or guidelines in order to be used. Services are offered by providers that are governed by rules and standards called a framework. As an example, if a storage area network (SAN) manufacturer wants to market a new storage array to Microsoft Office system customers, the manufacturer must make sure that its storage software is designed to be a service that obeys the rules of the provider framework. If so, it will install smoothly into place and the software and services "above it" will have no idea that there has been a change. It will be transparent.
The framework that is used by Microsoft is called the .NET Framework. The .NET Framework is an integral Windows component that supports building and running the next generation of applications and XML Web services. The .NET Framework provides the following benefits:
A consistent object-oriented programming environment regardless of where the object code is stored and executed
A code-execution environment that does the following:
Minimizes software deployment and versioning conflicts
Promotes safe execution of code, including code created by an unknown or semi-trusted third party
Eliminates the performance problems of scripted environments
Homogenizes the developer experience across different types of applications, such as Windows-based applications and Web-based applications
Is compatible with industry standards to ensure that code based on the .NET Framework can integrate with any other code
There are two main components to the .NET Framework. The first is the common language runtime and the second is the class library. You can think of the common language runtime as an agent that does the following:
Manages code at execution time
Provides core services such as memory management, thread management, and remoting
Enforces strict type safety and other forms of code accuracy that promote security and robustness
The concept of code management is a fundamental principle of the common language runtime feature. Code that targets the runtime is known as managed code, while code that does not target the runtime is known as unmanaged code.
The class library, the other main component of the .NET Framework, is an object-oriented collection of reusable types that you can use to develop applications ranging from traditional command-line or graphical user interface (GUI) applications to applications based on the latest innovations provided by ASP.NET, such as Web Forms and XML Web services.
The Microsoft Office system provides standard navigation services that make sure there is one standard user interface for selecting common tasks and changing focus from one Web page to another. This helps provide the end user with a consistent set of choices for common tasks regardless of where they are being selected.
Essential security operations such as encryption and authentication are provided as common low-level services. Using common services across the enterprise makes it easier to keep control over security issues, compliance, versioning, and testing.
Security settings are configurable throughout the entire product-from Central Administration all the way to each individual item. Through the Central Administration interface, you'll be able to create and set policies at the virtual server level that will affect all the sites, lists, and list items that are hosted by the virtual server. The security policies set at the Web application level replace the Security Rights Mask at the virtual server level in Windows SharePoint Services 2.0.
For example, if a particular user's account is granted Contributor access using a policy at the virtual server level, the user will have Contributor access to all the sites, lists, and list items that are hosted within that virtual server. If there is a conflict with a local setting, whether the right is granted or denied, the policy set at the Central Administration level will take precedence and override the local security setting. This architecture allows end-users to manage the day-to-day security of their information while allowing you to ensure that your corporate security policies are enforced correctly.
Each virtual server gets its own set of security policies in Central Administration. In addition, security policies cannot be shared across virtual servers; they must be created manually for each virtual server. Some of the more common uses for security policies include scenarios such as the following:
Setting the default content access account to have read access to all objects within the Web application, even if users try to deny that account access to their information.
The ability to deny access to content is a positive administrative action that helps certain businesses in certain vertical markets comply with legal requirements. In some instances, it is not enough to not include a group of users in accessing content; instead, it is expected that these users will be explicitly denied access to that content.
Setting the Deny Write policy for All Authenticated Users on their extranet virtual server so that any changes made to the content in the read-only extranet must be made on the internal staging servers and then published to the extranet servers.
The core services are those services that must be functioning in order for SharePoint to run properly. What follows is an architecture overview of these services.
The database services stores information accurately, retrieve the strings quickly, and return them intact. Through the use of various data types, database services can even determine what kind of data is represented. A database can't, however, provide a context for interpreting the meaning of the data. If the database services return the currency number 500.00, what does it mean? Does it represent U.S. dollars or euros? Is it a receipt or an estimate? Is it a guess, or is it a firm number? Is it a secret, or is it public information?
The storage services offered as core services provide metadata and context to the raw data stored in the database. This makes the data more easily indexed, managed, interpreted, and published.
Metadata is information about information. For example, information that records who originated the data and when, whether the data has been approved, what the security requirements are for the data, how it is to be represented when it is published, when the data is to be destroyed, and how the data is to be used.
Metadata provides context for data so that it can be interpreted and understood when it comes time to use it. Metadata also supports the ability to intelligently index and quickly search large databases by automating the classification and organization of like-kinds of information.
Versioning services provide the ability to organize, track, and control the evolution of documents. Multiple contributors are vital to collaboration, but multiple contributors can also create confusion. Version control, as the name implies, is a core service that provides standard version control functions for documents and data within the Microsoft Office system.
Windows SharePoint Services 3.0 provides two types of versioning. One type of versioning was first available in SharePoint Portal Server 2001 and is called major/minor versioning. With major/minor versioning, only major versions can be published. Minor versions can be viewed by those who have the right to view the minor versions of the document or list item, but these versions cannot be published, nor can they be viewed by those who have only Reader access to this list.
The other type of versioning that was available in Windows SharePoint Services 2.0 is called simple versioning. With simple versioning, each version is a full copy of the document and the versions are numbered sequentially. Users will determine which type of versioning is used in each list. Simple versioning is also available in Windows SharePoint Services 3.0 along with major/minor versioning.
When used correctly, versioning gives the user a clear picture of the difference between major and minor changes to a document or list item. Both the document and its metadata can be versioned as well. At any given time, the same document might have any of the following three states, which dictate what can be done with the document and who can do it:
Checked Out The user who has this document explicitly checked out is the only user who can make and save changes to this document or list item. This is the version of the document that is the latest version.
Draft (minor version) The user or group of users who have permissions to see the document's minor versions can read and check out the document if the document is not already checked out.
Published (major version) The user or group of users who have permissions only to read the document's major versions can consume the content in the major version, but cannot see or read the minor versions that might exist as the developing document history for the next major version.
Versioning and auditing are not the same concepts. Versioning allows the user to tell the system which changes are minor changes and which changes are major changes to a document. Auditing is the process of tracking which user made a change to a document, regardless of the importance of that change. Versioning is focused on allowing the user to assign a value to the change made to the document. Auditing is merely tracking that a change has taken place, by whom and when.
Personalization of a list item or a document is applied only to the published version.
By providing a common backup service, the 2007 Office system streamlines the administration of backup and recovery operations. If applications are designed to take advantage of common backup and recovery services, there is minimal need for special handling, scripting, and testing of backup operations.
The architecture for backup is improved in SharePoint Server 2007. When you take a step back and look at an overview of this product, you'll realize that SharePoint Server 2007 is actually held in several different locations:
Content and metadata for crawled content is held in SQL content databases.
The binaries for the program are held on the file server-by default, in C:\Program Files\Office SharePoint Server\Bin.
The content indexes are held on the file server-by default, in C:\Program Files\Office SharePoint Server\Data.
The Web application files are held on the file server-by default, in C:\Inetpub\wwwroot\wss\VirtualDirectories.
The configuration information for the Web applications is held in the metabase.
The farm configuration information is held in the SQL Configdb database.
The built-in backup tool that ships with SharePoint Server 2007 will back up all farm SQL databases (including the ConfigDB), provisioned Web applications and the index. This combination is a significant improvement from Spsbackup.exe, which only backed up the SQL databases and the indexes.
Most of you will use a third-party backup solution to back up your SharePoint implementation. Whether or not you use the built-in backup solution, it's important to remember that all backups initially are committed to disk and then can be copied to tape or a SAN. Because of this architecture, you'll find that your disk needs will grow as your SharePoint implementation grows.
At a minimum, you'll need to work with a 4 to 1 ratio of disk space (in your overall disk topology) to data hosted in SharePoint. Here is how the model works assuming 1 GB of data is held in SharePoint (keeping in mind that this is a model, not a formula):
1 GB of data will need 1 GB of disk space.
Another 1 GB of free disk space is needed for SQL maintenance utilities to run properly. You should always have 100 percent free disk space relative to the size of your largest database.
You'll be indexing this data, so assume your index is 20 percent the size of the content being indexed. White papers and experience point to actual figures ranging from as little as 10 percent up to as high as 40 percent. Using 20 percent as our number for this model is a bit conservative and doesn't take into account external content sources that might need to be crawled and that would add to the size of your index. In this example, assume you need one search server and two query servers, which means you'll need 400 MB of disk space because the index will be held twice, once on the search server and once on the query server.
Your farm will need to be backed up. Your backup image, in this example, consumes another 1.2 GB of disk space. The index is backed up only once, even though it is held on multiple servers.
Overall, in this example, you will need 3.8 GB of disk space for every 1 GB of data that is hosted in your environment. This example does not account for external content sources that will need to be crawled, nor does it include a SQL backup (as opposed to using the built-in SharePoint backup tool). Your SQL database administrators (DBAs) will likely want to do their own backup of your SQL databases, which will increase the amount of disk space that you will need.
Farm backup is not the only feature that is improved in Windows SharePoint Services 3.0. Another major improvement is the two-stage Recycle Bin for users, where restores of individual documents and list items are driven by end users. The lack of per-item restore capabilities was one of the significant drawbacks of Windows SharePoint Services 2.0. Not only did several third-party vendors develop tools to address this shortcoming, but Microsoft found consultants building customized applications for individual customers that solved this problem. Clearly, this issue needed to be addressed in the new version of Windows SharePoint Services.
In the first stage of the Recycle Bin, the user deletes a document or list item and the item appears in the end-user and site collection Recycle Bins. The end user can restore or delete the item from this Recycle Bin. Deleted items in this stage count toward the site quota. Items in this Recycle Bin are automatically cleaned out after a preconfigured number of days. Items are sorted in descending order by data deleted.
The second stage is invoked when the end user deletes the item from her Recycle Bin. The item no longer appears in the interface for the end user, and it no longer counts toward the site quota. However, Site Collection administrators can see all second-stage deleted items and can restore deleted items from this stage.
The Windows SharePoint Services Recycle Bin functionality is similar to that of the Windows Recycle Bin. When an item is deleted, it is removed from its list and placed into the user's Recycle Bin. On the Recycle Bin page, the user has the option to restore or permanently delete any item.
Restoring a document moves the item from the Recycle Bin back into its original list-the process includes making sure that the file name doesn't conflict with existing files. In addition to using the basic Recycle Bin functionality, the site collection administrator has the option to set a cleanup service that will automatically permanently delete items that have been deleted for a specified amount of time. Deleted items and nondeleted items can have the same name, and there can be multiple deleted items that have the same name. Multiple nondeleted items that have the same name have the automatic iteration number "(x)" appended to them.
Only users who have permissions to delete and restore items are able to delete and restore items. In addition, Site Collection administrators have the ability to override individual user's decisions and restore items if needed. The life span of deleted items is decided by the farm administrators, and the configurations are set in Central Administration.
The Recycle Bins can be turned off at the virtual server level. If this feature is turned off, all the bins are emptied of any items they contain and any future delete actions will result in the items being permanently deleted. Turning off the Recycle Bin feature has the effect of implementing the delete architecture of Windows SharePoint Services 2.0.
Sites and site collections are not included in this architecture. The two-stage Recycle Bin feature applies only to documents and list items. In addition, items cannot be opened or viewed while deleted. The item must first be restored in order for the item to be viewed. Attachments to list items are treated as part of the list item.
This architecture has the benefit of giving users direct control over when and how to delete and restore individual items, as well as reducing maintenance costs by reducing the need to include IT personnel into the restore process.
Regardless of which security standard is being implemented, security functions can be grouped into a small number of common security services.
The rights and roles services assign the role that the individual has in the organization. Rather than keeping track of unique rights for individuals based on their own lobbying efforts, the individuals are simply assigned one or more roles that dictate their rights and privileges throughout the enterprise.
A role is a collection of rights that is assigned to an object in SharePoint that can then be associated with a user or group. Roles are first defined, which means that the list of rights is enumerated and grouped into a role. Then roles are assigned, which means that the roles are attached to an object in SharePoint.
A right is an action that the user can perform within SharePoint. The action is usually explicit and well defined. For example, the action of deleting a document is a right. User and group accounts are never assigned rights directly. Rights are always grouped into roles, the roles are assigned to a SharePoint object, and then user and group accounts are associated with the role. This is the only architecture that is supported and available to users to gain rights to perform actions in SharePoint.
A user can be either an Active Directory user account or an external user account via pluggable authentication. The user's profile is scoped to the site collection.
Windows SharePoint Services 3.0 works with the access token, which contains the security identifiers (SIDs) of both the user's account and all the groups that the user is a member of. User accounts that are used via pluggable authentication have a much more simple access token because that account is not a member of any Active Directory domain security group.
SharePoint groups are a collection of user accounts. SharePoint supports both domain groups from Active Directory and SharePoint groups that are created within SharePoint itself. SharePoint groups can be used only within the scope of the site collection, whereas domain groups can be used anywhere in the SharePoint farm.
The inheritance model is such that each object within SharePoint can have its own set of permissions or inherit its permissions from its parent container. A modified or combined model is not supported. A combined model is one in which an object can inherit permissions from its parent object and have additional permissions added to the inherited set of permissions. In addition, you cannot configure an object to inherit permissions from any other object other than its parent object.
Pluggable authentication is an authentication service that any application can use to authenticate users and processes. This approach greatly simplifies regulatory compliance, as one set of processes can be configured to the compliance requirements for the entire organization. It also removes the burden on the administrators to manage a large number of security levels for specific applications.
For the end user, pluggable authentication provides for Single Sign-On (SSO) authentication. Once the end user opens a session and is authenticated, the system provides them with the correct access across the enterprise. There is no need to remember a different password for each system or application. In addition, many companies have already implemented an SSO solution other than the Microsoft Single Sign-On service. As an alternative to maintaining and mapping two sets of credentials, SharePoint Server 2007 allows you to specify an alternative SSO provider to the standard SSO provider in SharePoint Server 2007.
Replacing the default SSO provider in SharePoint Server 2007 involves implementing the Microsoft.SharePoint.Portal.SingleSignon.ISsoProvider interface, installing it into the global assembly cache, and registering the new SSO provider with SharePoint Server 2007.
You can register only one SSO provider for SharePoint Server 2007. Registering a new SSO provider replaces the default SpsSsoProvider class in SharePoint Server 2007. Because only one SSO provider can be in use at a time, it is recommended you stop the Microsoft Single Sign-On service when using a custom SSO provider.
Sometimes you need to prevent a single individual from seeing or changing one data field in a record or database. The Microsoft Office system provides per-item security, which enables access privileges to be granted for each individual data element.
SharePoint's security model can work with either users or groups. When you are thinking about individual sites, keep in mind that you can add users individually to SharePoint sites. But if thousands of users are added to the site, performance might degrade because the enumeration of thousands of users' SIDs for SharePoint to reference might consume an inordinate amount of resources. Adding individual users to team sites or Web Parts doesn't scale well, so it is recommended that larger installations that need to add thousands of users to sites or Web Parts use Active Directory security groups.
The end user should not be able to see what she can't have access to or actions she cannot perform. Once an end user is authenticated and her rights are applied, any pages, buttons, functions, data elements, windows, or instructions that she doesn't have access to are automatically removed from her configuration. This helps limit confusion and is a security best practice.
Rights trimming affects several parts of SharePoint Server 2007. The content in lists is trimmed so that users see only the content that they have permissions to see. The page links are rights trimmed so that users see only links for which they have permissions to navigate. This includes links to add and edit content, such that users can access only links to Web Parts that allow them to edit content for which they have permissions. Actions are also trimmed so that the user sees links only for actions that they have rights to perform.
In Windows SharePoint Services 3.0, a link is considered any part of the user interface that takes a user from one Web page to another Web page. To accommodate link trimming for anonymous users, Windows SharePoint Services 3.0 gives the user explicit login and logoff. When a user accesses a Web site anonymously, most of the user interface links will not appear because anonymous users usually have minimal permissions to the site. By providing explicit login and logoff, user's who have first accessed the site anonymously will have the opportunity to explicitly log in and gain greater access to the site's functionality.
Imagine a world where administrative functions and processes are consistent throughout the enterprise. Microsoft did imagine this and built it right into the product architecture. All administrative services that are accessed through the operating system and the applications are presented through a common service that organizes and standardizes the administrator user experience.
Many, but not all, management actions can also be scripted using the stsadm.exe command-line tool. In most cases, any action you can commit using the command line can also be undone using the command line.
Admin UX stands for "Administrator's User Experience." System administrators are the backbone of any IT organization, and Microsoft has focused considerable time and effort in simplifying and unifying the tools and interfaces used by system administrators. This service provides commonality and integration for administrative functions throughout the 2007 Microsoft Office system.
Central Administration is divided into two main areas: operations and application management. If you're configuring the farm or making farm-wide configurations, you'll use the Operations page of Central Administration. If you're working with a Web application or executing configurations for a Web application, you'll use the Application Management page.
One of the strengths of SharePoint Server 2007 is its ability to dynamically and automatically create and provision Web sites based on templates and master pages. SharePoint Server 2007 has unified the provisioning process so that all such pages are created and provisioned in the same manner, rather than through separate creation and provisioning services. This arrangement makes it simpler and safer to create, modify, manage, and remove SharePoint Server 2007 sites and Web pages.
The provisioning services also provide for the workflow management of Web sites and content using workflow services. This ensures that content is properly reviewed, approved, staged, and published according to the organization's policies and procedures.
SharePoint Server 2007 unifies three disparate site provisioning models. If you look at the predecessors to SharePoint Server 2007, you'll find that there were three distinct ways to create a Web site using Microsoft products:
Windows SharePoint Services 2.0
SharePoint Portal Server 2003
Content Management Server 2003
Each product had the ability to create and provision a Web site. SharePoint Server 2007 unifies these approaches and gives the end user the ability to provision new sites, regardless of whether they are content management-oriented sites, collaboration sites, or new portals. As part of the provisioning aspect, administrators can set a farm-wide Sites Directory to capture metadata about newly created sites. Whether or not site metadata is captured to the farm-wide sites directory, it is always captured to the local sites directory for each site inside the site collection.
To help you understand the provisioning process, here are a few items to consider:
New Web applications are created in Central Administration and must be executed by an IT administrator.
A new top-level site (TLS) (also called a root site), which is the first site in a new site collection and is created in a managed path, can be created either in Central Administration or by using the Self-Service Site Creation (SSSC) feature. These new TLSs can be created either by administrators or end users with sufficient permissions.
Sub-Web sites are created inside site collections and are usually created by end users who have sufficient permissions to create new sites.
Simply stated, "That which can't be seen, can't be managed." The only accurate and effective way to monitor systems and applications is to build monitoring services into the environment from the beginning. Monitoring technology is not something that can be successfully retrofitted into the environment. The monitoring services provide integrated system, exception, and performance monitoring that is available to all applications in the Microsoft Office system.
Topology services provide for the physical deployment of the 2007 Microsoft Office system and the SharePoint Server 2007 environment into a variety of platform and networking configurations. This deployment allows the administrator to optimize and revise the physical infrastructure for efficiency and performance without requiring a change to the logical software architecture or its deployment.
The topology services include tools for viewing, analyzing, and administering server farms. Also included are services that define and administer the policies that govern the use of various features and services by applications and end users. The topology model is also extensible, allowing for support of extranet connections and services beyond the organization's boundaries.
The Services on Server page in Central Administration allows you to turn on and off services for each server in the SharePoint farm. Although all the binary code is installed on each server, the Topology Manager ensures that each server has "turned on" or "turned off" those portions of the code that are required or not needed for the server to fulfill its assigned duties in the farm.
Windows SharePoint Services 3.0 provides the base topology services for SharePoint Server 2007. Any code or configurations that are installed on one Web Front End (WFE) server should also be installed on the other WFE servers in the farm. This includes Web Parts and Web services.
The topology for SharePoint Server 2007 is scalable, flexible, maintainable, and reliable. Any tier within the farm topology can be scaled to any need just by adding servers to the farm and making the proper configurations in Central Administration. Servers can also change roles just by starting and stopping services, which makes them flexible in their role assignment. Each server can be maintained either individually for patches and upgrades, or they can be maintained as a group by using Windows Server Update Services. In addition, if you have multiple servers servicing a single role in the farm topology, servers can be brought down individually for maintenance without bringing down the entire farm or causing an interruption of services. Because multiple servers can be installed in a redundant fashion for farm services, you can achieve high availability in your farm, ensuring that users rarely, if ever, experience downtime from your SharePoint implementation.
SharePoint Server 2007 provides common site models to guide the generation and provisioning of SharePoint Server 2007 pages and sites. The Site Model organizes site-rendering services, templates, and navigation services into a coherent and consistent site architecture without requiring code changes.
Standardized services supported by a standardized provider framework require a standardized application programming interface (API).
The Microsoft Office system API provides standard support for data entry through common forms and embedded fields. Forms and embedded fields allow the entry of information embedded in a document, which establishes the context and meaning of the information being entered. The Microsoft Office system services can be used to infer context that can be used to drive metadata, which in turn drives search indexing and metadata. Because these services are standard and centralized, they can be used consistently across the enterprise without programmatic changes.
The services and features have been created using object-oriented software development techniques. This means that the features are encapsulated in self-contained software packages that communicate with each other using messages. Object models and Simple Object Access Protocol (SOAP) services provide the Microsoft Office system with consistent tools to use in managing and using software objects.
Although logical architecture is the heart of the Microsoft Office system architecture plan, software needs a physical place to run. Although the logical architecture is intangible, it becomes tangible when it is actually installed and run in a physical environment. This expression of logical architecture according to a physical architecture plan is known as deployment. The deployment services provide for the location and use of the Microsoft Office system services in a physical computing environment or platform, without disrupting the organization of the logical architecture. The deployment services know how to map the Microsoft Office system to real-world physical architecture configurations when it is installed.
The SharePoint Server 2007 logical architecture can be physically deployed to a single machine serving as all three tiers in the three-tier environment, or on any number of machines serving one or more of the tiers cooperatively. Figure 2-2 is an example of this three-tier environment.
Figure 2-2: Three-tier server farm deployment options with the Office SharePoint Server 2007 physical architecture
The general deployment architecture for SharePoint Server 2007 is made up of the following three tiers:
Tier 1: Web Front End Static Web content and services on the corporate portal, business unit portal, sites directory, and My Sites host
Tier 2: Application Server Dynamic content processing and application services, including search, indexing, audiences, user profiles, Excel Services, and BDC
Tier 3: Shared SQL Database Infrastructure Shared database infrastructure
Keep in mind that the strength of the underlying architecture plan for the Microsoft Office system is that the logical architecture can be deployed to a variety of physical architectures, to one machine or many.