MCTS Self-Paced Training Kit (Exam 70-667): Configuring Microsoft® SharePoint® 2010: Managing Web Applications

Lesson 1: Configure Web Applications

Web applications are at the top of the logical hierarchy of a SharePoint farm. A SharePoint farm will typically have at least two web applications: Central Administration and a web application that contains content accessed by users, such as http://intranet.contoso.com.

A web application is composed of a collection of settings stored in the farm’s configuration database, one or more content databases, one or more site collections containing content, and one to five zones—each supported by Internet Information Services (IIS) Web sites running with a single application pool. All of these are accessible using URLs called access mappings that enable a request to reach the correct SharePoint web application and enable content to be rendered properly to a user.

A diagram of the components related to a SharePoint web application is shown in Figure 3-1.

In this lesson, you will learn to create a web application and to configure many web application settings. In Lesson 2, you will learn to configure authentication. And, in Lesson 3, you will learn to manage access mappings and zones.

Understand Web Applications and IIS Web Sites

When you create a web application, you create a site in Internet Information Services (IIS). An IIS Web site has bindings, which can include a unique IP address, a host header, or a port. Bindings enable IIS to determine which site is being requested by an inbound HTTP request.

When a user requests a page with a unique resource indicator (URI), such as http://intranet.contoso.com/SitePages/Home.aspx, the client creates an HTTP request packet. The client determines the IP address by querying DNS to resolve the host name—in this example, intranet.contoso.com. The client adds the host name to the host header field of the packet. The client then sends the packet to the server’s IP address over the default HTTP port (80) unless otherwise specified. If the request is an HTTPS request, the destination port is 443 unless otherwise specified. IIS receives and parses the request and identifies that the request is for the Contoso Intranet IIS Web site, which is bound to port 80 with the host header intranet.contoso.com.

After IIS has determined the Web site from which content is being requested, it begins a series of processes that return the requested content to the client. IIS first looks into the web application’s physical path, also called the root directory. When you create a SharePoint web application, you specify the physical path. For example, the intranet web application is stored at C:\inetpub\wwwroot\wss\VirtualDirectories\clients.contoso.com80. In traditional ASP.NET websites, actual content is stored in the root directory. However, as you learned in previous chapters, SharePoint stores content in content databases on a SQL server. IIS has no idea how to locate and access this content. However, the configuration file, Web.config, in the root directory of the IIS Web site defines the site as a SharePoint application and instructs IIS to pass the request to SharePoint.

SharePoint then parses the URI to determine which site collection and thereby which content database is being requested. SharePoint can then access the content from SQL and return the content to IIS, which then delivers the content to the user.

The request is handled by IIS and SharePoint within the context of the application pool of the IIS Web site. The application pool is an isolated memory space that is routed to one or more worker processes (w3wp.exe) that handle requests sent to a server for the sites associated with the application pool. The application pool identity is a domain user account that is registered as a managed account in SharePoint.

When you create a web application, SharePoint creates a content database and assigns the application pool identity the permissions it requires to access content. SharePoint also creates the physical path, the Web.config file, the IIS Web site, and several virtual directories.

As you will learn later in this lesson, SharePoint does not manage the configuration of a security certificate. Although SharePoint specifies that a web application uses SSL, you must install a certificate and bind the certificate to the site in IIS Manager on each server in the farm. Additionally, SharePoint does not give you the option of binding a web application to a specific IP address. If you want to bind a web application to one or more specific IP addresses, you must do so manually in IIS Manager on each server in the farm.

Design Considerations: One or More Web Applications

More web applications are necessary if your governance requirements must be implemented using configuration that is scoped to web applications. For example, if your governance plan requires isolation of internal and external content from cross-site scripting attacks, you can divide content into separate web applications, each of which will have a distinct IIS Web site with a unique domain name, such as http://intranet.contoso.com and http://clients.contoso.com. Doing so will also physically isolate content in separate content databases that can optionally be hosted on separate SQL servers with distinct SQL authentication configuration.

Later in this chapter, you will explore the numerous settings that are scoped to a web application. Although the importance of each setting will vary between enterprises, among the most important settings scoped to a web application are the following:

• Service application connections Each web application is connected to the services it requires, such as Search. Not all scenarios require all services. For example, a small team site might not require the PerformancePoint Service Application. For performance and governance reasons, you should connect web applications only to the service applications they require.

• Recycle Bin settings You can configure whether deleted items are moved to SharePoint’s two-stage Recycle Bins, how long items are retained before being permanently deleted, and what storage limits will be.

• Self-service site collection creation You can allow users to create site collections, which reduces administrative overhead.

• Blocked file types You can configure the file types that are allowed to be uploaded within a web application.

If every scenario that you will support with SharePoint can be implemented with a single set of configuration—for example, if every scenario requires the same services, the same Recycle Bin settings, and the same settings for self-service site collection creation and blocked file types—you need only one web application. However, it is likely that some scenarios will require different sets of configuration. For example, all scenarios might require the same Recycle Bin settings as dictated by your governance plan, but you might want to block audio and video file types on the intranet web application while allowing them within a team site. To support two different collections of settings that are scoped to web applications, you must create two web applications.

In this chapter, and throughout this Training Kit, you will learn about settings that apply to a web application, to a site collection, to a content database, to zones (which you will learn about in Lesson 3), or to other components of the SharePoint logical structure. Pay attention to the scope of settings, because you must consider them when you translate your information management requirements into a SharePoint logical architecture for your enterprise.

Design Considerations: One or More Application Pools and Identities

Because the application pool is a process (w3wp.exe) and an isolated memory space, two web applications running in two separate application pools are isolated from each other. If one web application contains poorly written code that causes the site to crash or consume too many resources, the other application pool and web application will continue to function. And if security is compromised in one application pool, other application pools are not exposed.

You might think that you should create a new application pool for each new web application. In fact, the default settings on the Create New Web Application page encourage you to do just that. However, application pools are a limited resource—each running application pool requires a memory footprint and places performance overhead on the server. Microsoft supports up to 10 application pools per web server; however, the limit depends largely upon the amount of RAM allocated to front-end servers and the workload that the farm is serving: the user base and its usage characteristics. It is therefore recommended that you create web applications in a shared application pool unless there is a significant requirement for process isolation.

Each application pool has an identity—a domain user account that is used by the application pool process. When you create a new application pool, you can use an identity that is shared with other application pools, or you can assign an identity unique to the application pool. The decision of whether to use a shared or unique application pool identity depends on the level of security your governance plan requires. The two primary considerations are access and auditing.

If an application pool identity is breached, it is possible that other application pools running with the same identity might also be exposed. Therefore, if the content accessed by web applications in two application pools shares similar security profiles, you might choose to use a single identity for both application pools. If the security profiles are different, you might choose to use a separate identity for each. For example, Central Administration should run in a separate application pool because the identity used by Central Administration is the SharePoint farm service account—for example, SP_Farm—which is highly privileged. That level of privilege is not appropriate for user-facing web applications. The application pool that is used for user-facing web applications should be a different identity.

If you use unique identities for each application pool, it can be easier to review event log or audit entries and, by examining the identity reported in an event, to distinguish the specific application pool that generated an event.

As you learned in Chapter 1 “Creating a SharePoint 2010 Intranet,” SharePoint 2010’s managed accounts feature makes it much easier to manage password changes for accounts used by services and application pools. Therefore, it is suggested that when you create a new application pool, you consider using a unique identity; however, this is not required. In the Practice for this lesson, you will create an extranet web application for Contoso, Ltd. Because the extranet website is exposed to the Internet, you will create the web application in a separate application pool. Because the security profile of the extranet application is similar to other user-facing web applications, but is quite different than Central Administration, you will assign the new application pool the same identity as other user-facing application pools: CONTOSO\SP_WebApps. In Chapter 9 “Deploying and Upgrading to SharePoint 2010,”, you will learn how to configure managed accounts and how to assign and change application pool identities.

By default, service applications such as Search and Managed Metadata share a single application pool. Although this application pool is separate from the application pool shared by user-facing applications, it is recommended that all service applications share an application pool unless, again, there is a significant driver for process isolation.

Configure a New Web Application

In Chapter 1, you learned to create a web application by using Central Administration. In Chapter 2, you learned to use the New-SPWebApplication cmdlet to create a web application. In Chapter 9, you will learn to use the New-SPManagedAccount cmdlet to create a managed account, which you can then use as the application pool identity for the –ApplicationPoolAccount parameter of the New-SPWebApplication cmdlet.

You have learned that a web application is a combination of an IIS Web site and a content database. The configuration for each is stored in the configuration database of the farm. In this section, you will explore the most important settings that can be configured when you create a web application using the Create New Web Application page in Central Administration, shown in Figure 3-2.

Authentication

The first setting that appears on the Create New Web Application page is Authentication. SharePoint Server 2010 offers two types of authentication:

• Classic Mode Authentication Classic Mode Authentication is the same type of authentication that was used in Microsoft Office SharePoint Server 2007. Classic Mode Authentication relies on Active Directory to authenticate users.

• Claims Based Authentication Claims Based Authentication is a new feature in SharePoint 2010. With Claims Based Authentication you can use Windows authentication (Active Directory); Forms Based Authentication (FBA) against an authentication provider such as Active Directory Lightweight Directory Services (AD LDS), a SQL database of users, or an ASP.NET membership provider; or Security Assertion Markup Language (SAML) tokens generated by trusted authorities such as Windows Live ID or Active Directory Federated Services 2.0 (ADFS 2.0).

If you are new to SharePoint, you should select Claims Based Authentication only if you need to implement Forms Based Authentication or SAML token-based authentication, or if the web application will use code that uses claims. Otherwise, you should select Classic Mode Authentication. Some SharePoint features, including audiences, become more difficult to implement in a web application that uses Claims Based Authentication.

You will learn about each provider and method in Lesson 2. When you understand the various authentication providers, and the nuances of configuring and managing authentication, you can make a more informed decision about whether to select Classic Mode Authentication or Claims Based Authentication when you require only Windows authentication. As you will learn in Lesson 2, you can change the authentication mode from Classic Mode Authentication to Claims Based Authentication by using Windows PowerShell.

IIS Web Site

As you’ve learned, when you create a SharePoint web application, you also create a corresponding site in IIS. In the Name box, type a name for the web application. This name will appear in Central Administration as the name of the web application and in IIS as the site name. Follow your organization’s naming standards, which should be designed to ensure that an administrator can easily identify the purpose of a SharePoint web application or IIS Web site.

Next, in the Port box, configure the port number to which the site will be bound. By default, the Create New Web Application page specifies a random port number, but the port is usually 80 for HTTP or 443 for HTTPS.

When more than one web application is bound to a single IP address and port, a host header is required to allow IIS to route an inbound request to the correct site. Earlier in this lesson you learned that a client embeds the host name portion of the URL in the host header field of the HTTP request packet.

In the Host Header box, type the host header for the web application, which should be the fully qualified domain name (FQDN) of the web application.

Finally, you can configure the root directory by changing the default value in the Path box. The content stored in the root directory of a SharePoint site is minimal, because most content is stored in the content database(s) of the web application. Therefore, you have little reason to change the root directory, unless your governance policies require you to do so. If you do change the path, ensure that the drive letter exists on every SharePoint server in the farm. Also, verify that NTFS permissions allow the root directory to be created successfully on each server in the farm.

The settings discussed in this section are required when you create a new IIS Web site. However, you can also select the Use An Existing IIS Web Site option, and the web application will read the site configuration from IIS on the server running Central Administration. This option is rarely used. Its primary purpose is to fix a broken web application by re-creating the web application and connecting it to the previously created IIS Web site.

Note the following guidelines related to the creation of the IIS Web site for a SharePoint web application:

• It is not recommended to use flat host names without a domain name component as the host header. In other words, do not configure a host header of http://intranet. Instead, use http://intranet.contoso.com.

• When you create a new SharePoint web application, you cannot specify a unique IP address for the new IIS Web site within SharePoint. After creating the IIS Web site, you must use IIS Manager to modify the bindings of the IIS Web site so that the site is bound to an IP address. You must repeat this process on each server in the farm. This configuration is not recorded by SharePoint, and therefore it is not backed up by SharePoint. If you restore a web application by using SharePoint, you must manually reconfigure the IP address binding. Bindings are backed up when you back up IIS configuration.

• Enter the host header correctly entered when you create a web application. The host header is recorded in the configuration database and cannot be changed after the web application is created. You can change host header bindings directly in IIS, but you must remember to do so each time you add a new server to the farm, and to update existing servers if you restart the Microsoft SharePoint Foundation Web Application service. If you need to change the host header of the web application, it is recommended that you delete and re-create the web application.

• Only one host header can be defined during the creation of a web application creation. If users will access the web application with more than one host name, such as http://intranet.contoso.com and http://portal.contoso.com, you must extend the web application to create additional zones. You will learn more about zones in Lesson 3.

Security Configuration

The options that appear in the Security Configuration section depend on whether you selected Claims Based Authentication or Classic Mode Authentication in the Authentication section at the top of the Create New Web Application page. The settings that appear if you selected Classic Mode Authentication are shown in Figure 3-3.

If you selected Classic Mode Authentication, you must designate the authentication provider for the web application. You can select NTLM or Negotiate (Kerberos) as the authentication provider. Classic Mode Authentication essentially uses IIS to authenticate users with built-in Windows authentication providers, including NTLM, Kerberos, and Basic authentication. However, you cannot select Basic authentication when you create a web application—you must configure Basic authentication after the web application has been created. You will learn more about Windows authentication providers later in this lesson.

If you selected Claims Based Authentication, the authentication provider is configured in the Claims Authentication Types section of the Create New Web Application page.

For both authentication types, you must specify whether anonymous authentication is allowed and whether SSL is enabled in the Security Configuration section. By default, anonymous access and SSL are disabled. Later in this lesson, you will learn about the additional steps required to implement anonymous access and SSL.

Claims Authentication Types and Sign In Page URL

The Claims Authentication Types and Sign In Page URL sections are visible only if you selected Claims Based Authentication. One or more authentication providers, and a sign-in page are required for Claims Based Authentication. You will learn more about these settings later in this chapter.

After you have configured security and authentication settings, you must configure additional settings for a web application, shown in Figure 3-4.

Public URL

The Public URL represents the user-accessible URL of the web application. In the URL box, type the protocol, the fully qualified domain name (FQDN) of the web application, and the port that will be used in URIs of requests to the site, such as http://intranet.contoso.com:80.

You will notice that the Public URL is associated with the zone named Default, and you cannot change the zone when creating a new web application. A zone is a path through which content in a web application is actually accessed. When SharePoint receives a URI—for example, http://intranet.contoso.com/SitePages/Home.aspx—SharePoint examines the protocol, FQDN, and port of the URI and uses those three elements to identify both the SharePoint web application that is being requested and the zone through which the request is received—in this example, the default zone of the Contoso Intranet Web application.

Application Pool

Use the controls in the Application Pool section to specify whether the web application will be hosted within an existing application pool, running in the context of the identity that has been already assigned to the application pool, or within a new application pool running in the context of a managed account that you select in the Configurable list. Earlier in this lesson, you learned that it is a best practice to use a shared application pool for web applications unless there is a significant driver for process isolation, because application pools incur memory and performance overhead and are therefore a limited resource of IIS.

Database Name and Authentication

The Database Server box is prepopulated with the name of the server that hosts the farm’s configuration database. If you want to host the web application’s content database on another server, replace the value using the <SERVERNAME\instance> format, where SERVERNAME is the FQDN of the database server and instance is the Microsoft SQL Server instance you want to use, if more than one instance is running on the server.

The Database Name box is prepopulated with a sample name that includes a globally unique identifier (GUID). Most database administrators (DBAs) prefer to follow a naming standard that uniquely identifies the database with a descriptive name that does not include a GUID. Replace the default name with a name that follows your naming standards. A guideline is to use a name that follows this example: SharePoint_Content_Intranet, where the first two elements of the name identify the database as a SharePoint content database, and the remaining elements of the name correlate to the web application and site collections contained in the database.

In the Database Authentication section, select the method used to connect to the content database. The default and recommended method is Windows authentication, which uses the credentials of the application pool identity to connect to SQL Server. Windows authentication automatically encrypts the password.

If you have configured the SQL Server for mixed mode authentication, you can select SQL authentication. You must specify the credentials that the web application will use to connect to the database. Type the user name in the Account box and the password in the Password box. The user account with which you are logged on to Central Administration must have permission to create and secure databases on the server.

Failover Server

SharePoint 2010 supports failover to a second instance of the database. If you have configured database mirroring in SQL Server, SharePoint can failover to another server in the event that the current database server becomes unresponsive. In the Failover Database Server box, type the name of a specific failover database server for the content database. This setting does not configure SQL database mirroring—it only instructs SharePoint to failover to an already-configured backup instance of the database. You will learn about failover in Chapter 11.

Search Server

The Search Server setting is automatically configured, and cannot be changed, if SharePoint Server 2010 is installed. On a SharePoint Foundation 2010 farm, you associate a search server running SharePoint Foundation 2010 Search service with the content database for the new web application.

Service Application Connections

A web application connects to service applications for shared services such as search. Service application connections are grouped into application connection groups, also called proxy groups. In the Service Application Connections section, select either an existing application connection group, or select Custom from the drop-down list and then select the specific service applications you want the web application to use. You will learn more about service application management in Chapter 5.

Customer Experience Improvement Program

Click Yes or No to opt in or out, respectively, of the Customer Experience Improvement Program. If you choose Yes, certain information will be sent to Microsoft that will help Microsoft understand performance and usage patterns of SharePoint implementations in the real world.

Delete a Web Application

You can delete a web application by using Central Administration. As with other changes that involve components of both SharePoint and IIS, you should not use IIS Manager to delete an IIS Web site that services a SharePoint web application. Exercise care when deleting a web application. Before doing so, verify that you have a backup of the web application and of the farm’s configuration.

DELETE A WEB APPLICATION USING CENTRAL ADMINISTRATION

1. In the Central Administration Quick Launch, click Application Management.

2. In the Web Applications section, click Manage Web Applications.

3. Click the Web application you want to delete.

4. On the ribbon, click Delete.

   The Delete Web Application page opens.

5. If you want to delete the content databases, click Yes in the Delete Content Databases section.

6. If you want to delete the IIS Web sites associated with the web application, click Yes in the Delete IIS Web Sites section.

   NOTE

   UNDERSTAND YOUR OPTIONS

   It is possible to delete the definition of the web application in the farm configuration database while leaving both the content databases and the IIS Web sites in place. Although rarely used, this option can be helpful if the configuration of a web application has been corrupted.

7. Click Delete.

DELETE A WEB APPLICATION USING WINDOWS POWERSHELL

The following example shows the use of the Remove-SPWebApplication cmdlet to delete a site:

Remove-SPWebApplication <URL> -DeleteIISSite -RemoveContentDatabase -Confirm:$false

Where:

• <URL> is the URL to the web application that you want to delete.

• The -DeleteIISSite switch parameter, if present, instructs SharePoint to delete the IIS Web site associated with the web application.

• The -RemoveContentDatabase switch parameter, if present, instructs SharePoint to delete the content databases associated with the web application.

• The -Confirm:$false parameter suppresses confirmation prompts.

Secure Communication with a Web Application Using SSL

Transport Layer Security (TLS) and its predecessor, Secure Sockets Layer (SSL), are cryptographic protocols used to encrypt the contents of communications over a network, at the application layer. In the case of SharePoint, the communication is between a client and an IIS Web site, or communications between SharePoint web applications and service applications.

SSL is particularly important if sensitive information will be transmitted to or from a website—without SSL, the information is transmitted in clear text and could be intercepted by a packet sniffer. SSL becomes more important when transmission of information is over untrusted networks, such as the Internet.

Secure communication is made possible with certificates and keys. When a client initiates contact with a secured website, the website provides the client a certificate. Through the series of ensuing processes, the two endpoints agree on a secret—a key—that is used to encrypt and decrypt communications.

The client can also use the server’s certificate to verify the identity of the server, by validating the digital signature of the certificate against a trusted certificate authority. In this way, SSL can be used to authenticate a server prior to sending sensitive information to the server. For example, if Internet Explorer cannot verify that a server’s certificate is valid, it warns the user and the user can then decide whether to accept the inherent risks and to continue communicating with the server.

To secure communications with a SharePoint web application, you must perform the following steps:

1. Configure the SharePoint web application to use SSL.

2. Create a certificate.

3. Bind the certificate to the IIS Web site of the SharePoint web application.

When you enable SSL for the SharePoint web application, you change the web application scheme to SSL in the configuration database, and you enable SharePoint to recognize the HTTPS protocol in the URL. But SharePoint Server 2010 does not itself provide SSL services and does not store the certificate used to authenticate the web application. These roles are performed by IIS.

Configure a SharePoint Web Application to Use SSL

When you create a new web application, you can enable SSL by clicking Yes for the Use Secure Sockets Layer (SSL) setting of the Create New Web Application page. The procedure to create a web application was introduced in Chapter 1, and the settings for a new web application were detailed earlier in this lesson.

To change an existing HTTP web application to use HTTPS, you must modify access mappings and zones. These procedures will be detailed in Lesson 3.

After the SharePoint web application has been configured to use SSL, you must manage certificates and bindings on each web server in the farm.

Create a Certificate

SSL relies on a certificate provided by the web server to the client. If you want the client to be able to verify the server’s identity, you must create a certificate request and send that request to a known certificate authority (CA), such as VeriSign or GeoTrust, or obtain a certificate from an online CA in your domain—for example, from Active Directory Certificate Services.

In a test environment, you can create a self-signed certificate on the web server. The certificate can be used to test SSL configuration and communication with an IIS Web site, but clients will be unable to verify the identity of the server.

CREATE A SELF-SIGNED CERTIFICATE

1. In IIS Manager, in the console tree, click the node representing the server, for example SP2010-WFE1.

   TIP

   SELECT THE SERVER

   Be sure that you select the server node in the IIS console tree, not an IIS Web site. Certificates are stored in the Windows Server certificate store, not in IIS itself.

2. In the IIS section, double-click Server Certificates.

3. In the Actions panel, click Create Self-Signed Certificate.

   The Create Self-Signed Certificate dialog box opens.

4. In the Name box, type a friendly name for the certificate, such as Test Certificate.

5. Click OK.

Bind an SSL Certificate to an IIS Web Site

After you have added a certificate to IIS, you can bind the certificate to an IIS site.

CREATE AN SSL BINDING FOR AN IIS WEB SITE

1. In IIS Manager, in the console tree, click the node representing the IIS Web site for which you want to create an SSL binding.

2. In the Actions panel, click Bindings.

   The Site Bindings dialog box opens.

3. Click Add.

   The Add Site Binding dialog box opens.

4. In the Type list, select HTTPS.

5. Optionally, in the IP Address list, select a specific IP address. Otherwise, accept the default value, All Unassigned.

   If you are hosting more than one SSL-enabled web application on a server, you might want to bind each to a specific IP address to avoid using a wildcard SSL certificate. IP address bindings also make it easier to configure network load balancing for high availability and performance.

   Wildcard SSL certificates allow you to secure multiple subdomains under a single parent domain. For example, you could obtain a wildcard SSL Certificate for *.contoso.com. Wildcard certificates do not allow clients to verify the identity of a specific web application, and can make it more difficult to trace network traffic.

6. Optionally, in the Port box, type a port number or accept the default value, 443.

   The default port for the HTTPS protocol is 443.

7. In the SSL Certificate list, select the certificate—for example, Test Certificate. The resulting configuration is shown in Figure 3-5.

   

   Figure 3-5. An SSL binding for an IIS Web site

8. Click OK and then click Close.

After you have added a new binding for SSL, you can remove any other bindings that are no longer needed.

Configure Web Applications

After creating a web application, you can specify additional configuration for the web application. In Lesson 2, you will learn to configure authentication. In Lesson 3, you will learn to configure authentication zones and alternate access mappings. You must also create one or more site collections and, if needed, additional content databases. You will learn about site collections and content databases in Chapter 4, “Administering and Securing SharePoint Content.”

On the Web Applications Management page of Central Administration, you can select a web application and then configure settings for the web application by clicking buttons on the ribbon, shown in Figure 3-6. The remainder of this lesson will cover a variety of web application settings, and will point you to other locations in this Training Kit that provide additional detail.

Master Page Setting For Application _Layouts Pages

Administrative pages for SharePoint sites are common across all sites in the farm. For example, a site’s Site Settings page, Settings.aspx, is the same ASPX page used by all sites in the farm. This is possible because each SharePoint site is created with a virtual directory called _layouts that points to a common location. Of course, the content that is displayed by the page might be different for each site, based on the site’s features and configuration, but the page itself is common. Because administrative pages are located in the _layouts virtual directory, administrative pages are often called _layouts pages.

Like other ASPX pages, an administrative page refers to a master page, which determines the look and feel and functionality of all pages that refer to it.

CONFIGURE APPLICATION _LAYOUTS MASTER PAGES

1. On the Web Applications Management page of Central Administration, select the web application that you want to configure.

2. On the ribbon, click the General Settings drop-down arrow, and then click General Settings.

   The Web Application General Settings page opens.

3. In the Master Page Setting For Application _Layouts Pages section, for the Application _Layouts Pages Reference Site Master Pages setting, click Yes or No.

4. Click OK.

If the Application _Layouts Pages Reference Site Master Pages setting is disabled (set to No) the administrative pages will use the application.master page in the SharePoint Root directory as their master page. This master page presents the default look and feel of SharePoint Server 2010.

If you have customized the master pages of a site to incorporate custom functionality or branding, you probably want those changes to be visible both on standard content pages and administrative pages. It would not be acceptable for administrative pages to lose the customizations you have made to the site. Therefore, by default, this setting is enabled (set to Yes). This instructs SharePoint to use the site’s master pages—rather than the standard, shared application.master page—when you access an administrative page in a site.

However, this presents a risk that if a site’s master pages become corrupt or inaccessible, an administrative page will not be able to load, and you could be locked out of the ability to manage a site. Therefore, even if this setting is enabled, if SharePoint cannot render a vital page, such as the Settings.aspx page, because of problems with the site’s master pages, the page will be rendered with the default SharePoint master pages, so that the page can be returned to the user successfully.

Recycle Bin Configuration

SharePoint sites support a two-stage Recycle Bin by default. When a user deletes content, the content is moved to the first-stage Recycle Bin, from which the user can restore the content or empty the Recycle Bin. When the Recycle Bin is emptied, content is moved to the second-stage Recycle Bin. Once the content is in the second-stage Recycle Bin, only a site collection administrator can restore it. When the second-stage Recycle Bin is emptied by a site collection administrator, or after another configurable time frame, the content is permanently deleted from the content database. By default, the Recycle Bin is enabled for a new web application, and default configuration is applied.

You should modify Recycle Bin settings in accordance with your specifications.

CONFIGURE RECYCLE BIN SETTINGS FOR A WEB APPLICATION

1. On the Web Applications Management page of Central Administration, select the web application that you want to configure.

2. On the ribbon, click the General Settings drop-down arrow, and then click General Settings.

   The Web Application General Settings page opens.

3. In the Recycle Bin section, in the Recycle Bin Status section, click On to enable the Recycle Bin or click Off to disable the Recycle Bin.

   If you disable the Recycle Bin, all content will be expunged from both first and second stages on Recycle Bins of all sites and site collections in the web application.

4. If you enable the Recycle Bin, you can configure the Delete Items In The Recycle Bin setting and the Second Stage Recycle Bin setting, as discussed later in this section.

5. Click OK.

If the Recycle Bin is enabled, as it is by default, you can configure the time-based expiration of content. Content in a Recycle Bin will be permanently deleted after the number of days that you specify. This time limit does not apply to the first- or second-stage Recycle Bins individually, nor is the time reset when an item is moved to the second-stage Recycle Bin. Instead, the time limit is measured from the time at which the content was deleted.

You can disable the second-stage Recycle Bin by clicking Off in the Second Stage Recycle Bin Setting group. By default, the second-stage Recycle Bin is on, and SharePoint limits the second-stage Recycle Bin size to 50 percent of the storage limit quota for the site collection. However, by default, new site collections have no quota applied, which effectively means that the second-stage Recycle Bin size is also unlimited.

As you can see, you should carefully plan and configure Recycle Bin settings.

General Settings

The Web Application General Settings page exposes many common web application settings, including the Recycle Bin and Master Page Setting For Application _Layouts Pages configuration discussed earlier.

MODIFY WEB APPLICATION GENERAL SETTINGS

1. On the Web Applications Management page of Central Administration, select the web application that you want to configure.

2. On the ribbon, click the General Settings drop-down arrow, and then click General Settings.

   The Web Application General Settings page opens.

3. Modify the settings, as described below, and then click OK.

The following additional settings can be configured on the Web Application General Settings page.

• Default Time Zone By default, each web application uses the time zone of the host operating system, and each site uses the time zone of the parent web application. It is recommended that you manually configure the time zone to prevent potential inconsistencies, particularly across servers of a multi-server farm.

• Default Quota Template When you create a site collection, you can configure the quota for the site collection, which establishes storage limits and warning levels at which administrators can be notified by email that the size of a site collection is approaching its storage limit. This setting, at the web application level, determines the default quota template for new site collections. You must have previously created a quota template before you can configure the Default Quota Template for a web application. See Chapter 4 for more information about quotas.

  NOTE

  CHANGES AFFECT ONLY NEW SITE COLLECTIONS

  If you change the Default Quota Template setting, no change is made to existing site collections. The setting only affects the default quota template assigned to new site collections.

• Person Name Actions And Presence Settings This setting determines whether online status of users will be displayed within the web application. Online status can be queried from Microsoft Office Communicator Server (OCS), and can be displayed next to a user’s name wherever the user’s display name appears. Additionally, if you right-click a user name, additional commands will appear that allow you to communicate directly with the user. By default, this setting is enabled for a new web application.

  NOTE

  NO NEED TO DISABLE SETTINGS IF YOU DO NOT HAVE OCS

  If you do not have OCS in your environment, there is no reason to disable Person Name Actions And Presence Settings. The setting will simply be ignored by SharePoint.

• Alerts Alerts are email notifications regarding changes to content in a list, library, folder, page, item, or document. By default, users are allowed to create alerts—up to 500 alerts across all sites in the web application. It is recommended that you do not configure the limit too high, or choose Unlimited, because it opens the possibility that a user might create sufficient alerts to degrade the performance of SharePoint or Exchange Server.

• RSS Settings Really Simple Syndication (RSS) feeds allow users and applications to monitor content in lists and libraries. For example, a user can subscribe to alerts in a list or library using an RSS reader such as Internet Explorer or Microsoft Outlook 2010. By default, RSS feeds are enabled for a web application, and the RSS feed of each list and library is enabled. You can disable RSS at the web application level.

  If RSS is enabled for the web application, you can enable, disable, and customize the RSS feed of a specific list or library. Open the Settings page for the list or library, and then click RSS Settings. The Modify RSS Settings page opens, with which you can configure RSS settings.

• Blog API Settings The MetaWeblog API is a standard API used by many blog applications to accept blog posts published directly from blogging applications, including Microsoft Office Word 2010. By default, the blog API is enabled. You can also configure whether the web application’s authentication will be used to authenticate the user, or whether the API should accept the user’s user name and password.

• Browser File Handling By default, SharePoint protects users by preventing certain types of files, such as HTML files, from being executed locally when a user clicks the file on the SharePoint site. SharePoint adds headers to these sensitive file types that cause the browser to prompt the user to download the file, rather than allowing the browser to open the file immediately. This default setting, called Strict, should not be changed unless you have specific reasons to do so and you are in a controlled environment. The Strict setting also prevents attacks such as cross-site scripting from compromising the integrity of your server farm by forcing code in such files to be executed on the client browser, instead of on the SharePoint server.

• Web Page Security Validation When enabled, as it is by default, this setting prevents a client session from being used indefinitely. By default, 30 minutes after authentication of a request for a page, the client’s security validation expires. Therefore, after 30 minutes of inactivity, the user must refresh the page or otherwise reestablish the connection, at which point authentication will be performed.

  The setting does not produce a visible effect for web applications that use Classic Mode authentication, which uses Windows authentication mechanisms. Internet Explorer will transparently re-authenticate the user, as long as the web application’s URL is in Internet Explorer’s Trusted Sites or Local Intranet security zone. If the web application uses other authentication providers, a sign-in page will be presented and the effect of re-authentication will be more noticeable.

• Send User Name And Password In E-mail SharePoint 2010 can be installed in Active Directory account creation mode. This mode is included for Internet Service Providers and is being deprecated. The mode is not enabled by default, is being deprecated from SharePoint, and is included primarily to support upgrades of legacy environments for SharePoint hosting services. It is not recommended that you configure an organizational SharePoint farm in Active Directory account creation mode. SharePoint also ignores this setting when it is not installed in Active Directory account creation mode. Therefore, you can ignore this setting.

• Maximum Upload Size By default, a user cannot upload a single file, group of files, or other piece of content greater than 50 MB in size. You can modify this limit, but you must be cognizant of timeouts when transferring large files using HTTP, which is the transfer mechanism used by SharePoint, particularly over slow or high-latency networks such as the Internet or a WAN link.

  NOTE

  2 GB MAXIMUM FILE SIZE

  There is a fixed limit of 2 GB for any file stored in SharePoint. It is not possible to store files larger than 2 GB in a SQL record. Some third-party solutions might address scenarios that require SharePoint-based interaction with files larger than 2 GB.

  IMPORTANT

  MAXIMUM UPLOAD SIZE AFFECTS UPLOAD MULTIPLE FILES

  The Maximum Upload Size setting limits the aggregate size of a single upload action, which includes uploads using the Upload Multiple Files command. For example, by default, you cannot upload 10 files of 10 MB each with the Upload Multiple Files command because the total size of 100 MB exceeds the default limit of 50 MB.

• Customer Experience Improvement Program See the description of this setting in the “Configure a New Web Application” section.

Workflow Settings

From the General Settings menu, you can configure workflow settings for a web application. The Workflow Settings page exposes the following configuration:

• Enable User-Defined Workflows By default, this option is set to Yes and workflows are enabled for a new web application. Users can create declarative workflows—workflows that are based on building blocks that are available by default, such as SharePoint Designer workflow activities, or code that has been deployed to the server by an administrator. Users cannot add new compiled code workflows to the server. Users must have at least the Design permission level for a site to create a workflow in that site.

• Alert Internal Users Who Do Not Have Access Enabled—set to Yes—by default, this option will send an email notification to a user who has been assigned a task in a workflow. The email will include a hyperlink that will generate an access request for the site, at which point an administrator can grant the user the permissions necessary to perform the workflow task. If this option is disabled—set to No—a user who does not have access to the target item of the workflow task will not be notified of the task.

• Allow External Users To Participate In Workflow When this option is enabled, SharePoint will email a copy of a document to a user who has been assigned a workflow task related to the document. For security reasons, and to reduce the proliferation of independent copies of documents, this option is disabled by default.

Outgoing Email Settings

Outgoing email settings are required for alerts to function. You learned in Chapter 1 that after creating a SharePoint farm you should configure the outgoing email settings for the farm. By default, a web application will use those farm-level outgoing email settings. However, you can override the outgoing email settings for a specific web application. You must define the SMTP Relay Server, From Address, and Reply To Address.

CONFIGURE OUTGOING E-MAIL SETTINGS FOR A WEB APPLICATION

1. On the Web Applications Management page of Central Administration, select the web application that you want to configure.

2. On the ribbon, click the General Settings drop-down arrow, and then click Outgoing E-mail.

   The Web Application Outgoing E-Mail Settings page opens.

3. In the Outbound SMTP Server box, type the FQDN of an SMTP-compliant server to which SharePoint can connect to using TCP port 25.

   IMPORTANT

   The SMTP server must be accessible over TCP port 25, and must permit relay from servers based on IP address. SharePoint products do not support SMTP authentication mechanisms.

4. In the From Address box, type the email address that will be used as the sender’s address of outgoing email messages.

5. In the Reply-To Address box, type the email address to which replies should be sent.

6. In the Character Set list, select the character set for email messages. The default is 65001 (Unicode UTF-8), which is the character set most commonly used for email, and supports characters in all languages supported by Unicode.

7. Click OK.

Text Message Service Settings

If users do not have smart phones with which to monitor SharePoint email alerts, you can send alerts via text message, which allows alerts to be sent to almost any cellular telephone.

You must first subscribe to a third-party SMS service provider. The SMS provider relays alerts, based on the email address of the user in the alert, to the user’s mobile phone.

Your costs will vary based on factors including your geographic location, volume of SMS alerts, and fees imposed by your cellular telephone provider.

CONFIGURE SMS-BASED ALERTS

1. On the Web Applications Management page of Central Administration, select the web application that you want to configure.

2. On the ribbon, click the General Settings drop-down arrow, and then click Mobile Account.

   The Web Application Text Message (SMS) Service Settings page opens.

3. In The URL Of Text Message (SMS) Service box, type the URL provided by your SMS provider.

4. In the User Name box, type the user name provided by your SMS provider.

5. In the Password box, type the password provided by your SMS provider.

6. Click Test Service to test the configuration of the service.

7. Click OK.

Self-Service Site Creation

By default, you must be a member of the Farm Administrators group to create a site collection in a web application. However, in certain scenarios—a team or project collaboration web application, for example—you might want users to be able to create site collections without administrator intervention. To support these scenarios you can enable self-service site collection creation, which is disabled by default, by using one of two interfaces in Central Administration.

ENABLE SELF-SERVICE SITE CREATION FROM THE WEB APPLICATIONS MANAGEMENT PAGE

1. Select the web application for which you want to enable self-service site creation.

2. In the Web Applications ribbon, click Self-Service Site Creation.

   The Self-Service Site Collection Management page opens.

3. In the Enable Self-Service Site Creation section, click On.

   Optionally, select the Require Secondary Contact check box. If this check box is selected, a user will be required to provide a secondary contact when the user creates a site collection. The secondary contact becomes the secondary site collection administrator. A primary site collection administrator is always required.

4. Click OK.

ENABLE SELF-SERVICE SITE CREATION FROM THE APPLICATION MANAGEMENT PAGE

1. In the Central Administration Quick Launch, click Application Management.

2. In the Site Collections section, click Configure Self-Service Site Creation.

   The Self-Service Site Collection Management page opens.

3. Click the Web Application picker, and then click Change Web Application.

   The Select Web Application page opens.

4. Click the name of the web application for which you want to enable self-service site creation.

5. In the Enable Self-Service Site Creation section, click On.

6. Optionally, select the Require Secondary Contact check box.

7. Click OK.

In Chapter 4, you will learn how to create a site collection when self-service site creation is enabled for the web application.

Blocked File Types

SharePoint Server 2010 allows you to prevent certain types of files from being uploaded to a web application, based on file extension.

CONFIGURE BLOCKED FILE TYPES

1. On the Web Applications Management page of Central Administration, select the web application that you want to configure.

2. On the ribbon, click Blocked File Types to open the Blocked File Types page.

   You can open the Blocked File Types page with an alternate method. In the Central Administration Quick Launch, click Security. Then, in the General Security section, click Define Blocked File Types. The Blocked File Types page opens. Click the Web Application picker, and then click Change Web Application. The Select Web Application page opens. Click the name of the web application for which you want to define blocked file types.

3. Add or remove extensions, each on a separate line of the list, and then click OK.

The extension-based protection provided by the Blocked File Types list is rudimentary. Users can change the extension of a file and then upload it for storage. For example, you can rename a blocked .exe file with a .txt extension, and then upload the file to a document library. SharePoint looks only at the extension. However, you cannot upload a file and then change the extension.

Other Settings in the Web Applications Ribbon

The Web Applications ribbon also exposes a number of additional settings that are scoped to a web application. The following settings are discussed in Chapter 10, “Administering SharePoint Customization”:

• SharePoint Designer governance From the General Settings menu, you can manage what users are able to do with SharePoint Designer within the web application.

• Manage Features Features are bundles of functionality that can be enabled or disabled for scopes of the SharePoint logical architecture, including web applications, site collections, and sites.

• Web Part Security You can define the availability, behavior, and security of web parts in the web application.

Chapter 4 details the following settings:

• User Permissions You can configure the granular permissions available to be used in permission levels defined for sites in the web application.

• User Policy You can define access policies at the web application that override any permissions, or lack thereof, for content within the web application. For example, the SharePoint search crawling account is assigned a Full Read permission policy for each new web application. This enables the search crawling account to index all SharePoint content, without the need to explicitly assign permissions to content in the web application. User policy is actually scoped to zones, not to web applications. You will learn more about zones in Lesson 5.

• Permissions Policy Permission policies are collections of permissions that can be assigned to a user or group as a user policy, as described earlier. SharePoint 2007 had a fixed number of permission policies: Full Control, Full Read, Deny Write, and Deny All. In SharePoint 2010, you can define custom permission policies.

The remaining settings are discussed later in this Training Kit:

• Resource Throttling SharePoint 2010 introduces resource throttling, which is designed to protect a server and the users of a server from the negative impact of large queries and other performance-degrading activities. Resource throttling allows you to control resource utilization and optimize server performance. Resource Throttling settings are exposed by the General Settings menu. You will learn about resource throttling in Chapter 12, “Monitoring and Optimizing SharePoint Performance.”

• Managed Paths Managed paths specify the URLs in a web application at which site collections can be created. While managed paths are a property of a web application, they are conceptually more related to site collections, and are therefore detailed in Chapter 4.

• Service Connections You can specify the application connection group with which a web application is associated, or you can specify individual service applications to which a web application connects. Service applications, application connection groups, and web application associations are discussed in Chapter 5.

• Authentication Providers Lesson 2 of this chapter details the configuration of web application authentication. Authentication providers are scoped to the zone, not to the entire web application. You will learn more about zones in Lesson 3 of this chapter.

• Anonymous Policy Anonymous access restrictions are described in Lesson 2.

PRACTICE: Configure Web Applications

Practices are designed to guide you through important procedures. The instructions in the Training Kit are high-level instructions that will challenge you to think carefully and to apply the procedures that are covered in this lesson and elsewhere in the Training Kit. If you need assistance, consult the detailed, step-by-step instructions in the Practice Answers on the companion media.

In this practice, you will create a web application to support collaboration with Contoso partners. The web application will be accessible from the Internet, so you want to ensure that communication between clients and the web application is secure. Therefore, you will configure the web application to use SSL. Finally, you will make configuration changes to support both the business and governance requirements of the partner collaboration website.

Prepare for the Practice

Before you perform this practice, you must ensure that your lab environment has been built according to the instructions found in the Introduction to this Training Kit.

1. Apply the snapshot CHAPTER01 to CONTOSO-DC.

2. Apply the snapshot CHAPTER01 to SP2010-WFE1.

3. Start CONTOSO-DC.

   Wait for the virtual machine to complete startup, at which time the Press Ctrl+Alt+Del prompt appears.

4. Start SP2010-WFE1.

EXERCISE 1 Add DNS Host Records for New Web Applications

In this exercise, you add DNS host records for web applications you will create in subsequent exercises.

1. Log on to SP2010-WFE1 as CONTOSO\SP_Admin with the password Pa$$w0rd.

2. Start Command Prompt.

3. Use Dnscmd.exe to create a new host (A) records on the DNS server (contoso-dc.contoso.com) for partners.contoso.com that resolve to the IP address 10.0.0.21.

4. Use Dnscmd.exe to create a new host (A) records on the DNS server (contoso-dc.contoso.com) for extranet.contoso.com that resolve to the IP address, 10.0.0.21. Then close Command Prompt.

EXERCISE 2 Create a Web Application Using Central Administration

In this exercise, you create a web application for collaboration with partners of Contoso.

1. Use Central Administration to create a web application collaboration with partners. Use the following specifications and guidance:

   • Authentication: Classic Mode Authentication

   • Name: Contoso Partner Portal

   • Port: 443

   • Host header: partners.contoso.com

   • Authentication provider: NTLM

   • Anonymous authentication: No

   • Secure Sockets Layer (SSL): Yes

   • URL: https://partnerss.contoso.com:443

   • Application pool: SharePoint Extranet Applications

   • Application identity: CONTOSO\SP_WebApps

   • Content database name: SharePoint_Content_Partners

EXERCISE 3 Create a Site Collection Using Central Administration

In this exercise, you use Central Administration to create a site collection at the root of the new web application.

1. Use Central Administration to create a site collection. Use the following specifications and guidance:

   • Web application: https://partners.contoso.com

   • Title: Contoso Partner Portal

   • Description: Sites for collaboration with partners

   • URL: https://partners.contoso.com/

   • Template: Team Site

   • Primary site collection administrator: CONTOSO\SP_Admin

2. Open a new tab in Internet Explorer and browse to https://partners.contoso.com.

   An Internet Explorer Cannot Display The Webpage error page opens. The site cannot be accessed using HTTPS because SSL has not been configured for the IIS Web site associated with the application.

EXERCISE 4 Create a Self-Signed Certificate

In this exercise, you create a self-signed certificate that, in the next exercise, you will bind to the site to enable SSL.

• In IIS Manager, create a self-signed certificate named Test Certificate in the certificate store of SP2010-WFE1.

EXERCISE 5 Create an SSL Binding for an IIS Web Site

In this exercise, you bind the certificate you created in the previous exercise to the Contoso Partner Portal IIS Web site.

1. Bind the certificate named Test Certificate to the Contoso Partner Portal IIS Web site by modifying the site’s existing incomplete binding.

2. In Internet Explorer, browse to https://partners.contoso.com.

   An error page opens: There is a problem with this website’s security certificate.

   Question: Why does this error appear?

3. Click Continue To This Website (Not Recommended).

   The site is loaded, compiled, and cached for first-time access, and then authentication proceeds. The Windows Security dialog box opens.

   Question: Why does this dialog box appear?

4. Authenticate as CONTOSO\SP_Admin with the password Pa$$w0rd.

   The site is loaded, compiled, and cached for first-time access, and then the site opens.

   If an error appears, refresh the page. It is possible that the client timed out while the site was being loaded by IIS.

EXERCISE 6 Configure Web Application Settings

In this exercise, you enable self-service site creation, configure the Recycle Bin to retain items for 60 days, and prevent users from uploading MP3 files.

1. Switch to the Internet Explorer tab that displays Central Administration. Navigate to the Web Applications Management page, and then make the following changes to the configuration of the Contoso Partner Portal Web Application:

   • Enable Self-Service Site Creation. Require that users add a secondary site collection administrator.

   • Configure the Recycle Bin to retain items for 60 days.

   • Block the upload of MP3 files. For additional manageability and elegance, add the MP3 file extension to the list of blocked file types in alphabetical order.

2. Use Notepad to create a file named TEST.MP3.

   Ensure that the file extension is MP3, and that a TXT extension is not added.

3. Attempt to upload the MP3 file to the Contoso Partner Portal’s Shared Documents document library.

   An error message appears. It indicates that the file has been blocked by an administrator.

Lesson Summary

• When you create a SharePoint web application, you create an IIS site including a folder, a Web.config file, bindings, and a virtual directory. You should manage all configuration by using Central Administration or Windows PowerShell, except for binding a security certificate to a site, which must be performed in IIS Manager on each server in the farm.

• It is recommended that you create all web applications within a single application pool, unless you have a significant requirement for process-level isolation. If you create more than one application pool, your requirements for auditing and access are likely to drive you to create a unique managed account as the identity for each application pool.

• You can encrypt communication between clients and a SharePoint web application by configuring the web application to use the HTTPS protocol, which relies on SSL. You must also add the certificate to the server, and add an SSL binding to the IIS Web site.

• Numerous settings are scoped to a web application, including self-service site collection creation, service application connections, and Recycle Bin settings. If your requirements call for more than one collection of these settings, you will need more than one web application to support those requirements.

Lesson Review

You can use the following questions to test your knowledge of the information in Lesson 1, “Configure Web Applications.” The questions are also available on the companion media in a practice test if you prefer to review them in electronic form.

1. You want to enable SSL encryption for a new SharePoint web application. The server farm currently has no IIS Web sites that use SSL. What do you need to do? (Choose all that apply. Each correct answer is a part of the complete solution.)

   1. Add a binding to the IIS site.

   2. Configure the new SharePoint web application to use SSL.

   3. Add a certificate to the SharePoint configuration database.

   4. Add a certificate to the server.

2. You want to distribute email alerts to different SMTP servers based on the site from which the alert originates. Where can you do this?

   1. Site Collection Administration settings on the Site Settings page of each site.

   2. The Configure Outgoing E-Mail Server command on the General Settings page of Central Administration.

   3. The SMTP Relay settings of the SMTP server.

   4. The Outgoing E-Mail Server setting on the Web Application General Settings page.

3. Your information security and compliance requirements state that if a user accidentally deletes an item, the user must be able retrieve the item for 75 days. How can you configure SharePoint to support this requirement?

   1. Configure Recycle Bin Settings for the web application.

   2. Configure permissions so that the user cannot delete items.

   3. Configure information management policy.

   4. Configure a User Policy for the web application.