Chapter 8: Site Collections and Web Applications (Part 2 of 2)
This article is an excerpt from Mastering Windows SharePoint Services 3.0 by C.A. Callahan from Wiley Publishing (ISBN 978-0-470-12728-5, copyright 2008 by Wiley Publishing, Inc., all rights reserved). No part of these chapters may be reproduced, stored in a retrieval system, or transmitted in any form or by any means—electronic, electrostatic, mechanical, photocopying, recording, or otherwise—without the prior written permission of the publisher, except in the case of brief quotations embodied in critical articles or reviews.
Creating a New Web Application
Web Application Settings
Alternate Access Mapping
The Bottom Line
Let’s move another layer up the chain and look at web applications. Say you do want to enable Self-Service Site Creation, with Automatic Deletion enabled, but you don’t want auto-deletion enabled on all your other sites. In this case, you’ll need a new web application.
Web applications are what Windows SharePoint Services uses to hold site collections. Every site collection has to reside in a web application, although a web application can contain many site collections. When Windows SharePoint Services was installed, two web applications were created: your first site (in my example that’s http://sp2/) and Central Administration (in this case, http://sp2:9876/). A web application is essentially comprised of two items that reside in IIS: an IIS Web Site and an Application Pool. The default web applications and their corresponding names in IIS are shown in Table 8.1.
Table 8.1. Default Web Applications
SharePoint Web Application
IIS Website and Application Pool
SharePoint Central Administration v3
Any settings you conﬁgure in IIS on these web sites affect every site collection in the comparable web application. IIS Web Sites host security settings like SSL, authentication, and anonymous access. Making web applications security boundaries in the sense that their security settings effect all the site collections they contain, while not affecting the security of other web applications. In addition to IIS settings, Windows SharePoint Services offers a lot of additional conﬁguration that can be made at the web-application level.
Almost all of the web application administration and customization is done in Central Administration under Application Management, as shown in Figure 8.13.
Figure 8.13 The Application Management Page
Creating a New Web Application
The ﬁrst link on the Application Management page under, conveniently enough, the SharePoint Web Application Management category, is to create or extend a web application. Extending a web application to a new server will be covered later in the chapter in the “Alternate Access Mapping’’ section, but let’s see what you need to do to create a new one.
Let’s create a new web application for user blogs—one with a main site collection for the Administration blogs and other information (like an announcement to allow site members to make their own site collections), with Self-Service Site Creation turned on so that the users can create blogs of their own from there (yes, they’ll likely only use the top-level site of the collection and not be aware that they can do more, but still, it’s easy to do and easy to clean up after).
When you enable Self-Service Site Creation, there needs to be an existing site collection. It’s that ﬁrst site collection’s users that are given the Self-Service permission, and have access to the link to the Self-Service Site Creation page on the top-level site’s Announcements list. So you add the users you want to give the right to create their own site collections to that ﬁrst site collection. Then they can use that site collection as the staging area for their own collections.
HOME SITE HOME To make that first site collection a place to come back to for those users, consider configuring the Portal Connection setting on their site collections to point back to that staging site collection’s URL. It will give all pages on their sites a link back to that original site collection’s home page. This way they always have a convenient link back to that location. However, if you do that, be sure to create a link back to their site collection(s) so you don’t, navigationally speaking, strand them there.
To create a new web application, make sure you are on the Application Management page and click the Create or Extend Web Application link. It will take you to a new page with two options: Create a new Web application and Extend an Existing Web application.
Click on the Create a new Web application link, which will take you to the Create New Web Application page shown in Figure 8.14.
Figure 8.14 The Create New Web Application page
We need to work with a lot of settings to create a new web application, so let’s go through them all with the new blogging web application in mind.
IIS Web Site We need to specify which IIS Web Site the new web application will use. On the off chance you already created a Web Site in IIS for this web application, you could choose it from the list. In this case we have not, so we need to create a new one.
To create a new web application, you need to enter the following information:
Description A descriptive name for the IIS Web Site, usually something such as SharePoint-portnumber.
This ﬁeld will change to reﬂect your port or host header selections later in the settings. You can choose to manually enter a description as well. My example uses SharePoint-8080 for this web application (I didn’t type that in, if you change the port or host header it changes for you).
Port The port on which the new web application will listen. IIS Web Sites must be unique in some way in order to receive trafﬁc. Web Sites can be unique either by port number or by host header (you can’t mess with unique IPs in this interface). Using a port number to make a Web Site is adequate for demonstration purposes, but does require that users type in a port number next to the server name in their browser to access the top-level site.
The port suggested by default is certain not to be already in use by the server. However, you can specify a port if you know it is available. Because port 80 is taken by the ﬁrst web application, SharePoint-80, my example is specifying port 8080.
Host Header A host header is a way to change the expected URL of the web application. Normally, because port 80 is already taken by the SharePoint-80 Web Site (which is our ﬁrst web application for this SharePoint Server), you would not be able to have any more Web Sites on that port. But Host Headers allow you to specify a unique URL for the Web Site that listens on port 80. As long as the host header is unique in IIS, IIS can capture user requests on port 80 for it and redirect the correct trafﬁc to that Site. This will be covered later in the chapter.
For this web application, my example leaves this blank because we are using a unique port instead.
Path Where the SharePoint conﬁguration ﬁles are to be kept. My example uses the default settings. By default, IIS places the ﬁles in a folder which is named, by default, whatever the port or host header is for the web application. For example: C:\Inetpub\wwwroot\wss\Virtual Directories\8080.
Although you can specify a different path for your web application’s data, for this example, keep the default.
There are several ways you can conﬁgure security on the new web application, as shown in Figure 8.15.
Figure 8.15 The Security Configuration settings
Authentication Provider It is here that you can select what kind of authentication the web application should use when authenticating users. This was covered in Chapter 2 during the installation of Windows SharePoint Services (you had to choose it for that ﬁrst, SharePoint-80, web application). You have two options: Kerberos and NTLM. In most cases, the default choice of NTLM. Microsoft suggests this option as a best practice because using Kerberos for authentication requires you to conﬁgure server principal names for the server. Kerberos is also very time sensitive and all servers and clients must have the same time in order for the tickets that Kerberos uses to be time-stamped correctly. This means that external users will likely have a problem with this authentication model.
Because we don’t require Kerberos for authentication, let’s keep NTLM selected.
WINDOWS SHAREPOINT SERVICES DOESN’T AUTHENTICATE Remember that Windows SharePoint Services does not do authentication; only authorization. Windows SharePoint Services uses outside processes, like Active Directory, to store user accounts and authenticate those accounts. Then Windows SharePoint Services authorizes those authenticated users to access its resources.
Allow Anonymous This setting turns Anonymous Access on or off in the IIS Web Site for the web application. Enabling Anonymous Access adjusts IIS settings to allow the web application to offer anonymous access as an option to the site collections, or just the subsites, or even individual lists and libraries. If there is a site collection or subsite (if it doesn’t inherit permissions) in the web application that wants to take advantage of this, the administrator has to choose to enable anonymous access at that level. Lists and Libraries can be explicitly given anonymous access, but that option (to give particular lists or libraries unique anonymous access) must be enabled at the site collection or subsite where the list or library is located as well as at the web application level.
In this example, allow anonymous by selecting Yes (the default is No) so the user blogs have the option to be read by everyone on the network without logging in.
Use Secure Sockets Layer (SSL) If you want to use SSL to encrypt all the sites in the web application, you can turn on SSL (changing the path from http://sp2:8080 to https://sp2:8080). More details on SSL are discussed in Chapter 15, “Advanced Installation and Conﬁguration.’’
For this example SSL is unnecessary, so keep No selected for this setting.
Load Balanced URL If you have load balancing enabled, and the web application needs to be spread over multiple servers, it will allow you to ensure the paths displayed are consistent. By default, this is set to the URL of the web application.
CURIOUS ABOUT THE LOAD BALANCED URL? For more on load balancing SharePoint, check out Chapter 15, “Advanced Installation and Configuration.”
Using the default URL is ﬁne for this example, so leave this setting at its default.
Application Pool You need to establish which Application Pool in IIS is going to be used by the IIS Web Site. Application Pools in IIS access resources on behalf of the Web Site using an account identity that you specify. This Application Pool will be used by the web application to access its content database. Generally, you’ll want to create a new one to keep it separate from the existing Application Pools. If you do create a new Application Pool, you will also have to provide the security account it will use to access its content database. On a single-server install, this can be the Network Service account. However, on a server farm, you’ll probably want to create a new domain user just for this web application, or you could use the account you created for the original web application after installing Windows SharePoint Services.
For this demonstration I am going to keep the suggested Application pool name (it usually matches the description of the web application) and use the domain account dem0tek\blogcontent. See Figure 8.16.
Figure 8.16 The Application Pool section
Reset Internet Information Services This section is active only if you have a server farm. In order for a new web application to be created, IIS needs to be restarted on every web server in the farm. The local server (the one you’re currently on) needs to be restarted manually, but it’s possible to have the server restart IIS on the rest of the farm automatically.
The current setting for this section is to restart manually, which is ﬁne in this case because you should always reset the local server anyway, so keep the default.
Database Name and Authentication The web application needs a content database to store everything in—just as the SharePoint-80 web application did during the initial installation of Windows SharePoint Services (as discussed in Chapter 2). You need to choose which SQL server you want the database to be stored on; of course, with a Basic or Stand-alone server install, you’ll need to use the default provided as it points to the Windows Internal Database on the server. You can leave the database name as the default or rename it to something more intuitive if you wish (the default creates a unique GUID for the database, which is hard to remember). You’ll also need to decide how the web application will authenticate to the database. Again, you’ll most likely want to use the default Windows Authentication, but if your SQL server does not use Windows Authentication, you’ll need to supply a username and password.
Make certain the correct database server is speciﬁed, that the database name is acceptable, and that your web application can authenticate to access the database. My example uses WSSBlog_Content for the database name, otherwise the default database server and authentication method are ﬁne, as shown in Figure 8.17.
Figure 8.17 The Database Name and Authentication section
Search Server In order for the search service to index the content database for this new web application a search server must be assigned. The dropdown list shows only those servers running the Windows SharePoint Services search service.
Select a search server for the content database. For this example, there is only one choice (SP2), but it is possible to move search to another server (or have search on more than one server for that matter), as discussed in Chapter 15, “Advanced Installation and Conﬁguration.’’
Once you’ve set everything to your satisfaction, click OK and wait while the new web application is built. Once the operation completes, you’ll need to take some more steps to ﬁnish the creation.
To complete the web application creation process you need to manually restart IIS on the server so it ﬁnishes building the new IIS Web Site. Open a command prompt and enter iisreset /noforce
Because we chose to restart IIS manually, if there are other SharePoint servers in the farm, you will need to run the IISRESET command for each of them as well. If you don’t their IIS won’t realize that they should also have a copy of the new web application.
When IIS restarts, go ahead and open Internet Information Services (IIS) Manager, which is found in Administrative Tools on the Start Menu. You’ll see your new IIS website and application pool, as shown in Figure 8.18.
Figure 8.18 IIS shows the new website
Your new web application is up and running in IIS and available to Windows SharePoint Services. Of course, it’s completely empty. Going to the URL won’t show anything—after all, you have no actual site there. The next step is to create a new site collection for the web application and ﬁll it with the top-level site.
To create the ﬁrst site collection for the new web application, go back to Central Administration, Application Management, and under the SharePoint Site Management category, click Create Site Collection.
On the Create Site Collection page, you need to change the web application to your new one (SharePoint-8080), so the new site collection will go in this new web application. So in the ﬁrst section of the page, click on the web application’s name and choose Change Web Application. This will take you to the Select Web Application page shown in Figure 8.19.
Figure 8.19 Select Web Application page
Choose your new web application and click OK. You will be taken back to the familiar Create Site Collection page, but now the page shows the new web application. See Figure 8.20.
Figure 8.20 Create Site Collection page
For the title, my example uses Personal Blogs and gives a brief description (see Figure 8.20 for my example). You’ll notice the Web Site Address is showing the new URL for the web application. We’re going to make this site collection the root of the web application, so the complete URL is http://sp2:8080/.
Go ahead and create a new top-level site using the Team Site template (it makes a good portal for the user blog site collections that will be created from there), use your account (mine is shareadmin) as the Primary administrator, and apply a Quota template. (My example uses the Blog Quota we created earlier.), then click OK. When you’re done, browse to your new site collection, as shown in Figure 8.21.
Figure 8.21 The New site on http://sp2:8080
Now, to ﬁll out the site collection (after all, is it really a collection if there is only a top-level site?) let’s create a subsite of the top-level site. This subsite will actually be a blog for the administrators of the site collection for this example. It is intended to teach users what a blog is and how to use one before they create their own.
Use the Site Actions menu to get to the Create page. Once there select Sites and Workspaces, and on the New SharePoint Site page, name the site (I’m using Admin Blog), and use the Blog template. For the URL, add adminblog to the path. In my example that would look like http://sp2:8080/adminblog. Be sure to place it on the Quick Launch and Top Link bar of the parent site. When you are ﬁnished, click OK. When it’s done, you should have a nice blog site to display to users in addition to the main Personal Blogs top-level site, as shown in Figure 8.22. For more details on how to create a subsite, see Chapter 7, “Sites, Subsites, and Workspaces’’.
Figure 8.22 The Admin Blog site
Web Application Settings
Now you have a new web application, holding a new site collection with a basic top-level site and one subsite. As we did with site collections, let’s take a look at the unique things you can do with a web application. All of these settings are found in Central Administration on the Application Management page (to access Central Administration open Internet Explorer and type in the server address and unique port for the site, such as http://sp2:9876).
Self-Service Site Creation
The web application in this case was created so users could have their own blogs. There are basically two ways of going about allowing users to create their own blog site: Allow them to create subsites in one site collection; or enable Self-Service Site Creation. They both have their pros and cons.
If you allow users to create subsites in a site collection then they can create as many as they want there. Because when you enable the permission there is no inherent limit to how many they can create. But they at least can only overload one site collection.
On the plus side, that one site collection with all the subsites is pretty easy to back up and restore. Also, the users don’t need to know how to manage their own securities if they simply inherit them from the parent site. They also can use any custom templates you may have added to the site collection. On the other hand, if you have users abusing the permission to create subsites, you will have to track down the subsites they create and delete them manually. Also the site collection quota will affect all of the subsites in the collection, meaning that one person’s overloaded subsite can lock the site collection for everyone.
If you enable Self-Service Site Creation, yes, the users can create their own site collections (with their own users and security). As a matter of fact they can create as many as they want (once enabled, there is no way to limit how many site collections the users can create), and that’s pretty powerful. But you can also set up Usage Notiﬁcation and Automatic Deletion, which will automate the deletion process, freeing you from having to hunt down and delete unused site collections yourself. Not to mention that each site collection will have its own storage quota, so no one will be locking anyone else’s sites with their data overload (they will be limited by the quota as well). Also keep in mind that they will have to set up their own users and security for these site collections as well (which gets tiresome after a while).
Because the users are permitted to have considerable independence concerning what they add to their blogs in this scenario, we are going to enable Self-Service Site Creation for this web application. But in addition, we will make the users responsible for regularly indicating their site is being used. If they don’t respond quickly enough, the site collection triggering the conﬁrmation notice will be deleted.
Site collections need to reside in a web application, therefore, the Self-Service Site Creation setting needs to be applied at the web application level. It is enabled in Central Administration, under the Application Security category, by clicking the Self-Service Site Management link.
In this example we’ll turn it on for the selected web application by selecting On and clicking OK, so individual users can create their own blog site collections. See Figure 8.23.
Figure 8.23 The Enable Self-Service Site Creation section
When Self-Service Site Creation is on, an entry will be added to the announcements list on the top-level site of the ﬁrst site collection with a link to the site creation page (scsignup.aspx, as you can see in Figure 8.24).
Figure 8.24 Self-Service Sign up link
When the user accesses that page to create their site collection, it will look like they are creating a subsite, but it will say at the top of the page that they are creating a top-level site (as a matter of fact, if you look closely in Figure 8.25, you’ll notice that is says the user can specify an owner, which is not true, the creator is the owner by default). They will be able to specify their site collection’s path (based on managed paths), top-level site’s template, but not the storage quota because the default quota is already applied at the web application level.
Figure 8.25 Self-Service site collection creation
After the user creates the site collection, they will be prompted to add users to the three default groups, Visitors, Owners, and Members. The accounts are pulled from Active Directory by default and there is, unfortunately, no way no limit the number of users they can add. When they are done and click OK on that Set Up Groups for this Site page, their site collection will open in the browser and they will be able to begin. Keep in mind that the user will be the owner of the site collection, where there are a lot of conﬁguration settings available. Some training might be in order.
MISSING SECONDARY ADMINISTRATOR FIELD Self-Service site collections are based on the defaults set in Central Administration for their web application. If the web application setting is not enabled to require a secondary administrator (and this one didn’t), then there will be no option for it during creation from the user’s perspective. This is one of those subtle signs of how Windows SharePoint Services changes interfaces several layers away from the settings that caused it at the server level.
Web Application Outgoing E-mail Settings
By default, a web application uses the same email settings you created at the Operations level during the installation, but it is possible to give a web application unique email settings. Do this under SharePoint Web Application Management. Click on the Web application outgoing email settings, which will take you to the page in Figure 8.26. You’ll probably want to keep the same mail server, but you might ﬁnd it useful to change the sender address to be unique for this web application. My example uses email@example.com. (Make certain, of course, that that email address exists on your email server.)
Figure 8.26 The Web Application E-mail settings
Web Application General Settings
The Web Application General Settings link takes you to the page in Figure 8.27.
Figure 8.27 The Web Application General Settings page
This page contains a large number of sections for conﬁguration. Everything you see here will apply to all the site collections and sites within the web application. Some of these settings are defaults for the sites, which means they apply to site creation but can be changed on individual site collections post creation. Most of these settings, however, are applied to the web application and cannot be changed later for individual site collections.
Web Application Choose the web application you want to modify. In my example, the http://sp2:8080 web application is edited. Select the correct web application to which to apply these settings.
Default Time Zone Set the default time zone for newly created sites. This is only a default setting; individual sites can be edited to change the time zone from the default to reﬂect local time. Select the default time zone for all sites in the web application. My example uses the main office’s time zone: EST.
Default Quota Template Set the default Quota template for newly created site collections. This setting is also a default. You can still change the Quota template assigned to a site collection manually, as discussed in the “Site Collections’’ section of this chapter. My example uses the Blog Quota template, so self-service sites that are created on this web application automatically get this quota.
Person Name Smart Tag and Presence Settings This option requires MSN Messenger or Windows Messenger. Person Name Smart Tags are small popups that appear when a user hovers their cursor over a name on the SharePoint server. The tags indicate whether the person is online currently, and if they’re available for chat. This option is on by default, which is ﬁne in this case.
Maximum Upload Size This is the maximum amount that can be uploaded in a single process to the web application. This limit applies to any single ﬁle upload, or any group of ﬁles being uploaded together. For example, if you’re using the Explorer view to copy and paste 50 documents to a document library in one go, you’ll need to make sure the combined size of the ﬁles is less than this limit. If you’re planning to transfer a large amount of data to a SharePoint site, you should ﬁrst increase this limit and then decrease it when you’re done. My example leaves the default of 50MB in place. Apply the maximum upload size that is appropriate for your environment.
Alerts User alerts are discussed in Chapter 5. They can be very useful, but you really don’t want to let a user set thousands of alerts (your email server might complain). Here is where you can limit the number of alerts a user can set, or you can disable User Alerts altogether. My example, changes the default of 500 to a mere 50, so the users can’t go crazy with alerts. Feel free to set the limit to ﬁt your environment.
RSS Settings Disabling RSS feeds means that there will be no RSS for any of the site collections on that web application. In fact, when RSS is disabled at the web-application level, the RSS link on the Site Settings page for enclosed site collections won’t even appear. For this example, leave RSS turned on.
Blog API Settings With the rise of blogging, a large amount of third-party blog-writing software has been developed. In an effort to allow blog-writing software to connect seamlessly with actual blog servers, an RFC has been written for two application programming interfaces (APIs): Blogger API and MetaWeblog API. Blogger API, an older standard, dealt only with accessing the text on a blog. The newer standard, MetaWeblog API, also handles extra data such as common RSS-built metadata such as Author, Title, Comment, etc.
Windows SharePoint Services supports MetaWeblog API; when it’s enabled on the web application, users can update, edit, or create blog posts via third-party software. If you accept usernames and passwords via the MetaWeblog API, these programs can also log in to perform the updates. Otherwise, the default authentication for the site is used. If you do enable the API and allow the username and password to be accepted, note that these credentials are sent in clear text. Enabling SSL on the web application can reduce this security risk, as will be discussed later in the chapter. Leave the Blog API enabled, and turn on username and password acceptance.
Web Page Security Validation This is a legacy setting left over fromWSS2.0, where the security validation timeout determined how long a user could remain idle before having to login again. At the time of this writing, this setting no longer applies under WSS 3.0 (see Microsoft Help and Support Article 888828). This may change in a future update or service pack for Windows SharePoint Services. As the setting seems to have no effect on SharePoint, leave the default setting.
Send User Name and Password in E-mail This setting is relevant only if Active Directory Account Creation mode (ADAC) is enabled. When this setting is enabled, and when an account is created for a user, they will receive a notification email detailing their username and password. Without this setting enabled, the user will require an administrator to reset the password in Active Directory. For my example, leave the default in place.
Backward-Compatible Event Handlers Event handlers are custom code written and triggered by events in document libraries. Under Windows SharePoint Services 2.0, these handlers could be applied only to document libraries. With Windows SharePoint Services 3.0, they can be applied to other components, such as lists, files, and even sites. There are other significant changes in how the code works and needs to be written. To assist in the transition to version 3.0, this setting lets you retain your older 2.0 event handlers until you can redo them for 3.0. My example leaves the default in place; as we’ve got no custom event handlers at this point.
Change Log The change log is a new feature in Windows SharePoint Services 3.0 and is a part of the new Search features. The server keeps a log of any recent changes to the site in the change log. This allows Search services to quickly provide up-to-date search results without having to re-index the entire site. You can specify how long entries should be kept in the log, or you can disable the log completely. My example leaves the default of 15 days in place.
Recycle Bin You can customize the Recycle Bin for the entire web application. These changes apply to every site collection and site in the web application. You can adjust how long items sit in the End User Recycle Bin and the second-stage Recycle Bin before deletion, set the Recycle Bins to never delete anything automatically, or disable the Recycle Bins completely. My example leaves the defaults in place. Items are left in the Recycle Bin for 30 days before they are deleted, and the second-stage Recycle Bin is set at 50 percent of the site quota. This means the second stage recycle bin adds 50% of the site collection’s quota to the space taken in the content database.
When you’re done conﬁguring the general settings, click OK. You will be taken back to the Application Management page of Central Administration.
Using Windows Live Writer with SharePoint Blogs
Windows Live Writer from Microsoft is an excellent example of a MetaWeblog API–compatible program (and is still in beta at the writing of this book). You can download it from Microsoft’s get.live.com website.
In order to set up Live Writer for use with a SharePoint blog, you’ll need to configure a new blogging profile as follows:
When you open Live Writer for the first time it will prompt you to create a Windows Live Spaces blog. And if you click Next (because you already have a blog, thank you) it will ask you for the blog type you are writing to. If the account you use to log into the local machine is the one you use to access your SharePoint blog, then choose SharePoint Blog. At that point Live Writer will ask for you blog address, then access your blog, and will be ready to begin.
However, if you want to be able to specify an account, select Another weblog service (which is what I prefer), and click Next.
If you choose Another weblog service, it will take you to a screen to enter the URL for your blog (for example, http://server/myblog) and provide your username and password (assuming authentication via the API is enabled on the SharePoint server), and click Next.
It will check to see if there is a web page at that address and when you are prompted for a service provider, choose MetaWeblog API.
For the remote posting URL, you’ll need to tack /_layouts/metaweblog.aspx to the end of your blog’s URL (for example, http://server/myblog/ layouts/metaweblog.aspx).
Confirm the settings, name the profile, and click Finish.
From that point on it is easy to create blog entries using this (or many other) MetaWeblog API compatible program, the configuration should be the hardest part.
Remember that MetaWeblog API is a web-application setting; therefore, enabling it will provide this kind of integration for all blogs on all sites in all site collections residing in that web application.
Delete Web Application
If you need to delete a web application, go to Central Administration’s Application Management page. Under the SharePoint Web Application Management section, click Delete Web application. This will take you to the page shown in Figure 8.28.
Figure 8.28 Delete Web Application Page
Make sure you’re set to delete the right web application. If not, change it before you change any settings on the page. If you do accidentally delete the wrong application, check Chapter 12, “Maintenance and Monitoring,’’ for how to restore from backup (that is assuming you made a backup).
When deleting the web application, you can choose to delete the associated Web Site in IIS and/or delete the content database. Deleting the IIS Web Site will remove both the Web Site and the corresponding Application Pool from IIS—even if they are being used by another website. Deleting the content database will destroy everything in that database, including all your sites and documents. If you choose to not delete the database, you can create a new web application and reattach it later. Content databases will be covered in more detail later in this chapter.
Manage Web Application Features
Just as with sites and site collections, web applications have Features that apply to the entire web application (and the site collections therein). These can be provided by third-party companies to integrate their products into Windows SharePoint Services, or as part of an overall solution to customize SharePoint functionality. These features are displayed by clicking Manage Web application features, which will take you to the page shown in Figure 8.29. If there are features installed that were scoped to apply to a web application, they would be manageable here.
Figure 8.29 Manage Web Application Features page
Blocked File Types
By default, Windows SharePoint Services blocks the upload of several ﬁle types based on the ﬁle extension. The list of blocked ﬁle types is set at the web-application level. You can block all *.exe ﬁles for all site collections in the web application. Then create a different, private “IT tech team’’ web application, where having a library of common executable tools would be handy. You can also restrict a web application so that it doesn’t permit media ﬁles (such as .mpg, .mov, or.wmv ﬁles) to be uploaded. The sky’s the limit as far as restricting ﬁle types. Another reason web applications are security boundaries.
Blocked ﬁle types are set in Central Administration on the Operations page under Security Conﬁguration. Clicking the Blocked File Types link will take you to the page shown in Figure 8.30.
Figure 8.30 Blocked File Types page
On the Blocked File Types page, you can edit the list of ﬁle extensions to block. First make sure you’re editing the correct web application. If you need to make changes to all the web applications, you’ll need to edit the list for each one. You can permit previously blocked ﬁle extensions by simply removing them from the list, and you can block new ﬁle extensions by adding them to the list (note that you only add the characters for the extension, not the period).
Windows SharePoint Services doesn’t check a ﬁle beyond the extension; therefore, if a user changes a blocked extension to a permitted extension, they’ll be able to upload the ﬁle. For example, someone could take evilhack.exe, rename it evilhack.doc, and successfully upload it to a document library.
During the install process in Chapter 2, you worked with content databases, and you even created a new one while creating a new web application. Now let’s take a closer look at what you can do with content databases in regard to web applications. Web applications need at least one content database to put everything in, but they can support additional content databases. As mentioned in Chapter 2, content databases on a simple install reside in
With a server farm install, they are located on the SQL server you specified during installation.
Editing Content Database Settings
To manage content databases, go to Central Administration’s Application Management page and click Content databases. This will take you to the Manage Content Databases page, shown in Figure 8.31.
Figure 8.31 The Manage Content Database page
On this page, you can see the content databases for a particular web application. As always, clicking on the web application’s name will let you change to a different one. Clicking on a content database’s name will let you edit its settings (see Figure 8.32).
Figure 8.32 The Manage Content Database settings
Database Information A content database can be in two states: Ready and Ofﬂine.
The default setting is Ready, which allows new sites to be created in the content database. Obviously, you’ll want this if you plan to add site collections to the web application and this is the only content database for that web application.
The other setting is Ofﬂine. This setting prevents any new site collections from being created in the content database. Existing site collections can still be used, including creating new subsites within that collection, but the limit has been reached and no more new ones can be added.
When a database is placed Ofﬂine and someone attempts to create a new site collection (either via Central Administration or through Self-Service Site Creation), the error message in Figure 8.33 will appear.
Figure 8.33 Database offline error
Database Capacity Settings To prevent a database from growing too much and getting out of hand, you can limit the number of site collections that are created in a single content database. The default number is 15,000, but it can be set to whatever you like. There is also an option to send out a notiﬁcation if a certain number of site collections are reached. You obviously want this to be lower than the actual limit, and the default is 9,000.
Note that on this page, the word “site’’ is used when describing the limit and warning level. This is a misnomer; the settings apply to site collections, not to individual sites. When a database reaches the warning level, an event is generated in the log ﬁle, as shown in Figure 8.34.
Figure 8.34 Site capacity warning event
When the database hits its capacity, it will behave in the same manner as an Ofﬂine database—no new site collections are permitted. The error message generated is different and clearly shows the issue is capacity (see Figure 8.35).
Figure 8.35 Site capacity error generated during creation
Search Server When you created the web application, you were prompted to choose a Search server for the content database. This setting is where you can change that choice if you want to transfer the search process to another Search server.
Remove Content Database Removing a content database from a web application does not delete that database; it just disassociates it from the web application. The database still exists, just as when you delete a web application and elect to not delete the content database.
A removed content database can be added to a web application later or used when you create a new web application.
Adding a New Content Database
When the content database gets too large, or hits its capacity limit, you may want to add a second content database to the web application. In this case, additional site collections can be added to the new database while still being part of the web application. A web application can have numerous databases to accommodate increases in data storage.
To add a new content database, go to Central Administration’s Application Management page and click Content databases. Click the Add a Content Database button on the Action bar. This will take you to the Add Content Database page, as shown in Figure 8.36.
Figure 8.36 The Add Content Database page
This page asks you to ﬁll out the same information the content database required during the creation of a new web application; in addition, it lets you specify the capacity site limit and warning event level. Once you provide the needed information, click OK. You’ll see the new content database listed on the Manage Content Databases pages. See Figure 8.37.
Figure 8.37 Content databases
At this point, any new site collection created inside the web application will go to whichever database has the most available space for site collections. The available space isn’t calculated by storage capacity, but by subtracting the existing number of sites in the database from the database’s site limit.
Using an Existing Content Database
It’s possible to use an existing content database. It could be one that was previously removed from a web application, or it could simply have not been deleted when its web application was deleted.
In some cases, when the web application becomes horribly corrupt and unusable, you could be forced to remove it—but, of course, that would never happen.
If you want to bring a preexisting content database back online, and resurrect the sites contained in the database, you can do so by creating a new web application and entering the content database in the “Database Name and Authentication’’ section.
Of course, you’ll need to know the name of the existing database and the SQL server on which it’s located.
When the web application is created, you do not want to create a new site collection to complete the install; after all, the content database already has the site collections and enclosed sites. Instead, just reset IIS by running:
Then go to your new web application URL, where you’ll see the old sites from the content database.
One feature you can control at the web-application level is Anonymous Access. When creating a new web application (or extending one, as detailed in “Alternate Access Mapping’’), you can choose Allow Anonymous for the new web application. This selection does not turn Anonymous Access for the site collections on or off; it merely permits that option for each site collection. If a web application does not allow Anonymous Access, no enclosed site collection can have Anonymous Access. If the web application does allow Anonymous Access, then the enclosed site collections have the option to Allow Anonymous Access; however, it’s still turned off by default.
Adding Anonymous Access to an Existing Web Application
If you don’t enable Allow Anonymous Access during the creation of a web application, you can enable it later. Go to Central Administration’s Application Management page and click Authentication providers.
Make sure you choose the web application you want to edit, and then click the zone on which you want to Allow Anonymous Access. (Zones are discussed in the “Alternate Access Mapping’’ section. For now, you have only the default zone). When you click the zone, you will be taken to the Edit Authentication page.
Check the Enable Anonymous Access box and click Save to permit Anonymous Access for this web application. The Authentication Providers page is covered in more detail in Chapter 10, “Central Administration: Application Management.’’
Enabling Anonymous Access on a Site Collection
As you may recall, you allowed Anonymous Access when you created the blogging web application. Now it’s time to turn it on at the site collection level. Browse to your new web application and log in as the site administrator (my example uses http://sp2:8080 and the login is dem0tek\shareadmin) to reach the top-level site. If you go to Site Settings (under the Site Actions menu) and click Advanced permissions, you will be taken back to the familiar Permissions page. Click the Settings button in the Action bar to see a new option, Anonymous Access (Figure 8.38).
Figure 8.38 Site Permissions on a web application that allows Anonymous Access
Compare this to the Settings menu for a site collection in a web application that does not permit Anonymous Access, such as the main site on http://sp2 (see Figure 8.39).
Figure 8.39 Site permissions on a web application that does not allow Anonymous Access
Go ahead and look at the Anonymous Access settings for the site collection (mine is http://sp2:8080). Click the link in the Settings menu to go to the Change Anonymous Access Settings page (shown in Figure 8.40).
Figure 8.40 The Change Anonymous Access Settings page
You have three options for how you want this site collection (remember, this is at the site-collection level) to treat anonymous users. You can grant anonymous users access to:
Entire Web Site Anonymous users have access to the entire site collection (because this is being applied at the top-level site). They can browse and read all pages, lists, and libraries.
My example grants this for the Personal Blogs top-level site. So in this demonstration anyone who could access the site can view all contents unless explicitly set to allow otherwise.
Lists and Libraries With this setting, anonymous Access is available to be enabled per list or library, but not set to allow access to any pages. You need to manually edit the permissions on whatever list or library you want to grant Anonymous Access. And even then anonymous users will have to browse directly to the list or library to see it because they will not be allowed elsewhere in the site.
Nothing No Anonymous Access is permitted. This is the default.
When Anonymous Access is granted by using the Entire Web Site setting, the anonymous user is given the Limited Access permission level by default (meaning they can only read and not write). Therefore, choosing Entire Web Site will not give them full control, but will merely allow anonymous users to have limited access to view the entire site collection. More information about permission levels can be found in Chapter 11.
If you set anonymous access to allow access to the entire site, a visiting user does not need to log in to see the site (Figure 8.41). The Welcome Menu (that usually indicates the logged in user’s name) is replaced with a Sign in link. This allows users to opt to log in if they wish to contribute to the site. Of course, people who do not have a valid user account to the site will not be able to log in. Notice that the Site Actions menu is not available because the unauthenticated user is not allowed to make any changes to the view or content of the site.
Figure 8.41 A site with Anonymous Access enabled
Editing Anonymous User Permissions on a List or Library
If Entire Web Site or Lists and Libraries is selected, you can still edit the anonymous user rights to individual lists or libraries (it isn’t an either or situation, you can change the anonymous access to individual lists and library. You can give anonymous users access (if you selected Lists and Libraries) or you can change the permissions from the default Limited Access (if you selected Entire Web Site).
At this point, all visitors can view all content on the site, but they cannot contribute. Which is basically good, we don’t want visitors adding posts, but we do want them to be able to comment. So let’s give the anonymous users the right to only add comments to the Admin Blog. All comments will be stored in the Comments list.
Browse to your Admin Blog (at http://sp2:8080/adminblog/ in my example), and navigate to the Comments List, which can be found under View All Site Content on the Quick Launch bar. (If you are not using a blog template for your site, any list will do.)
Once on the list, click the Settings button on the Action bar and choose List Settings. On the Customize Comments page, click Permissions for this list. (List settings are fully covered in Chapter 5, “Introduction to Lists,’’ and permissions are covered in more detail in Chapter 11.)
Because the list will inherit permissions from the parent site (meaning everyone can read but anonymous can’t contribute), you need to break that inheritance so you can set custom permissions for the list. Go to the Actions button and choose Edit permissions.
A dialog box will remind you that this breaks inheritance. Click OK.
The Permissions: Comments page will show the unique permissions for this list. If you click the Settings button on the Action bar, you’ll see the new Anonymous Access option (see Figure 8.42).
Figure 8.42 List permissions
Click Anonymous Access on the Settings dropdown menu.
On this page (shown in Figure 8.43), you can adjust the rights of an anonymous user on this particular list. The available permissions are:
Add Items The ability to add a new item to the list or to add a new document to a library (in this example, the ability to add a new comment).
Edit Items The ability to edit an existing item, such as an existing comment, in the list or library.
Delete Items The ability to delete an existing item.
View Items The ability to view items in the list.
Figure 8.43 The Change Anonymous Access Settings page
When you selected Entire Web Site for the Anonymous Access settings at the site-collection level, the server gave anonymous users the View Item permission, so it will be already checked here. If you set the anonymous access for the site collection to Lists and Libraries, none of these will be checked.
For the comments, you’ll want to give anonymous users rights to Add Items and View Items (which they currently already have), but not Edit or Delete, because you don’t want people to edit or delete other people’s comments. Since they are all anonymous Windows SharePoint Services can’t keep track of what anonymous user wrote what, so it’s best they don’t edit anything. Check the Add Items box and click OK.
BIG BROTHER SAYS NO You can force all site collections in a given web application to comply with a policy that just doesn’t allow anonymous contribution, no matter what the site collections want, by using Policy for Web Application at the Central Administration level. Anonymous access is simply turned on at the Web Application level. The more granular anonymous access settings are set at the site level (or the site-collection level) and can grant anonymous users the ability to add new content to the sites. But if you have a lot of site collection administrators (for example, if you have a web application running Self-Service Site Creation), you may want to force Anonymous Access to be read only for all site collections in the web application. In other words, you’ll want to give the sites Anonymous Access, but you won’t want the site administrators to grant anonymous users the ability to modify content (Add, Edit, or Delete Items). This is where Policy for Web Application can be helpful, as discussed in Chapter 10. You can restrict Anonymous Access to be write-only at the web-application level, meaning that no matter what settings the site collection administrators set on their sites, anonymous users will never be able to create new content. Permissions can be tricky. You might change the permissions on a list to grant anonymous users the ability to Add Items, only to find it doesn’t work because a web application Authentication Policy is in place. So if it happens to you, check that overriding policy and see if you’ve been blocked, invisibly, at a higher level. See Chapter 10 for more details.
You should now have a Personal Blogs site, with an Admin Blogs subsite, that allows Anonymous Access. Open a new browser window and go to http://sp2:8080. You should be able to see the site without having to log in. As you can see in Figure 8.44, the button at the top right no longer shows your name, but it provides you the option to Sign In.
Figure 8.44 Viewing a Site Anonymously
For this example, let’s see if we can comment on that Add Item enabled list. Browse to the Admin Blog (or whatever you named your subsite) and see if you can add a list item. In my case I am going to add a comment to the default post “Welcome to your Blog.’’ To do that click the Admin Blog link, and click the Comments link at the bottom of the post. You’ll be taken to the Comments list for that post. See Figure 8.45.
Figure 8.45 The Comments list
You can immediately tell if anonymous users are permitted to create comments. The Add comment ﬁelds will be available at the bottom of the page: that link does not appear if you don’t have permission to add a comment. Go ahead and add a comment, and click Submit Comment. The new comment will be posted with no username listed (as you can see with my sample mystery comment in Figure 8.46).
Figure 8.46 An anonymous comment is posted
As always, think carefully before enabling Anonymous Access. Even though this web application isn’t currently accessible from outside your network, someone could still add inappropriate comments.
Once you’ve started building multiple web applications on your server, you’ll quickly realize that having the same URL but different port numbers for all those web applications can be confusing. You also might be thinking about how great it would be if you could host websites with completely different URLs, especially if you would like your server to be referred to by something other than its internal network server name. Host headers, an IIS feature that Windows SharePoint Services is more than happy to take advantage of, can help organize the confusion.
Host headers allow you to map a web application to a custom URL. For example, rather than creating a web application with the URL http://sp2:27445/, you could set it to the URL http://tech/ or the live, external DNS name http://tech.dem0share.com/. The really nice thing is that both of these URLs can run on port 80 rather than a custom port, which simpliﬁes browser use. Because 80 is the default port for HTTP, the user won’t need to specify a port in their browser’s address bar, just the URL.
UNIQUE IS BETTER THAN GOOD, IT’S NECESSARY Keep in mind that each IIS Web Site (and therefore each web application) must be completely unique in the way it identifies itself so IIS can pass it the correct user requests. Thus the Web Site must have a unique URL, unique port, or if the server has multiple network cards, it can have its own IP address. Above all else the Web Site must be uniquely identifiable by IIS in order to work. And, if you are working with host headers, the IIS server will never get the request for that URL if DNS does not have a record for it that resolves to that server’s address. If the URL is used on the internet, that domain should be registered to your company and listed on a DNS or Name server on the internet. In addition to having a record in the internal DNS.
Host headers should be set when a web application is created or extended.
So create a new web application (Central Administration ➢ Application Management ➢ Create or Extend a Web Application ➢ Create New Web Application).
On the New SharePoint Site, Windows SharePoint Services will suggest a random port, so change the suggested port back to 80 and enter the URL to which you want the web application to respond in the Host Header ﬁeld. See Figure 8.47.
Figure 8.47 Setting a host header in the Create New Web Application page
Conﬁgure the other sections as you would any new web application; Security, Application pool, Database, Search, etc. Then click OK.
After the web application is generated, you’ll need to create the initial site collection (my example is techsite to keep with the tech theme) and run iisreset /noforce, just as we did earlier in this chapter. Keep in mind that in order for users to successfully browse to this URL, they’ll need to be able to resolve it in DNS to the IP address of your SharePoint server (so make certain that there is a record in DNS that resolves to the server’s IP). Once everything is created and IIS has been reset, you’ll be able to see the host header information in IIS.
Open Internet Information Services (IIS) Manager and browse to Web Sites in the tree pane, right-click the new website, go to Properties, and look under the Web Site tab. The default port of 80 will be listed for the site. Click Advanced to see the host header URL, as shown in Figure 8.48.
Figure 8.48 The host header of the new Web Site in IIS
Of course, browsing to the new URL (in my case http://tech.dem0share.com) will take you to the new site. See Figure 8.49.
Figure 8.49 The new URL site
Site Collections and Host Headers
Officially, you need to create a new web application to use a host header; however, the STSADM command has an undocumented feature (or should we say, underdocumented) that lets you create a new site collection using a host header. In the previous version of Windows SharePoint Services it was called Scaleable hosting mode, required that Windows SharePoint Services be installed from the command line with a switch indicating the mode, and it could only apply to one web application. With WSS 3.0 all web applications are allowed to have both site collections that follow the standard path conventions for addressing, and for hosted site collections.
Remember, site collections reside in web applications, and adding a new site collection to the web application usually means you have to place the new site collection in one of the managed paths for that web application (by default, the /sites/ path). However, you can add a site collection to a web application and have that site collection use its own host header, instead of using the managed path.
Using STSADM, the command to create a new site collection normally is as follows:
STSADM -o createsite -url http://server/sites/newsite -owneremail firstname.lastname@example.org -ownerlogin DOMAIN\username
Other switches, such as -sitetemplate to pre-specify the top-level site’s template, are covered in Chapter 13.
STSADM -o createsite -url http://sp2/sites/camper -owneremail email@example.com -ownerlogin dem0tek\shareadmin
If you go to that site in your browser, you’ll be asked to choose the template you want to use and enter some users and groups (just as you did with Self-Service Site Creation). After you enter the users and groups, you’ll be taken to the new site, where you’ll see the normal, expected, URL in the Address bar.
You can create the same site using a host header for the site collection itself (instead of for the web application). It’s still in the http://sp2 web application and must abide by that web application’s settings; however, the URL would be http://camper.dem0tek.lcl rather than http:// sp2/sites/camper. Think of it essentially masking the real normal web application based address of the site collection with the host header.
The command for this would be:
You’ll notice two changes. The -url switch displays the desired host header URL (rather than the web application’s managed path) and the -hhurl switch, which needs to point to the web application in which you want to create the site collection.
Once again, if you browse to http://camper.demotek.lcl, you’ll be prompted to choose a Site template and add users and groups. Then you’ll be taken to the new site, displayed with the nice host header URL in the address bar.
Keep in mind this new site collection is in an existing web application, so you only want to do this if you want the site collection to be constrained by the web application settings (like anonymous access, user permissions, etc.). As a last caveat, also note that SSL will not work for a host header site collection unless it is using a wildcard certificate and the host header is in the same domain. Because site collection host headers are not listed in Alternate Access Mapping, search may also return unexpected links in query results. Despite these shortcomings, the option to use site collections with their own host headers is here if you need it.
Alternate Access Mapping
With the creation of multiple web applications, multiple sites, host headers, and a complex SharePoint deployment, there will come a time when you want to start providing access to SharePoint sites from multiple places and for multiple people. At the very least, you might want to open your server to outside access; opening a port in your ﬁrewall, and forward it to the SharePoint server. Of course, no one in the outside world is going to browse to your server using the URL http://sp2/ or http://sp2.dem0tek.lcl. They’re going to use a real address, such as http://blogs.dem0share.com. You know how to make a new web application with this URL, but what about adding the URL to an existing web application? This is done through alternate access mapping.
Alternate access mapping lets you:
Map a new URL to an existing web application.
Send a URL other than the one received back to the client browser.
Allow different security policies, based on the URL, for a single web application’s content (with zones and extended web applications).
Provide access to a web application’s content on a second port.
To understand how alternate access mapping works, you ﬁrst need to establish how Windows SharePoint Services treats URLs. Fundamentally, a URL is how a user gets to a SharePoint site. The URL is also used by Windows SharePoint Services to generate links on the page. A good example of this is with search results. The links in Windows SharePoint Services aren’t hard-coded in an HTML ﬁle somewhere; they’re generated on the ﬂy, just as SharePoint pages are. When you perform a search request on a SharePoint site, and you get back some possible results, each result shows you a clickable link to that result’s location. The links have to have the correct path to work. See Figure 8.50.
Figure 8.50 Search results with links
Notice that the result link has the site’s path (http://sp2:8080/<pathtoresult>) in it. This link works great if the user can resolve the URL http://sp2:8080/, but it would be pretty useless if the user were connecting to the server from outside your ﬁrewall and couldn’t resolve http://sp2:8080/. In that case, all those search result links would be dead.
Windows SharePoint Services resolves this issue by using alternate access mapping, allowing each web application to have up to ﬁve different public URLs. That means that the same web application, with all the enclosed site collections, can be accessed from multiple URLs, and WSS is smart enough to use the corresponding public URL in all its internal links and paths, making them useful again. For example, the web application http://sp2:8080 could also respond to the URL http://blogs.dem0share.com. As such, you would have two different URLs, both pointing at the same web application content.
In order to work with alternate access mapping, you need to be familiar with some terms:
Public URL The public URL is the URL that Windows SharePoint Services displays in the Address bar of the browser and in all the paths and links generated on the page.
Internal URL The internal URL is the URL that is presented to Windows SharePoint Services during the request for a page. This is often, but not always, the same as the public URL that Windows SharePoint Services sends back.
Zone Each public URL for a web application is associated with a zone. Zones are just an easy way to keep track of which public URLs go to which internal URL. When you ﬁrst create a web application, the URL used becomes the public URL for the Default zone. The other four zones are named Intranet, Internet, Custom, and Extranet. The different zones don’t have any intrinsic differences. The names are just for clarity and the zones can be used for whatever you like. Zones are also used to address extended web applications. In other words, you can take an existing web application’s content databases and make a new web application (essentially a new IIS Web Site) that points to those databases. Allowing two different URLs to access the same data.
Creating a New Public URL (by Extending a Web Application)
You can create a new public URL by going to the Alternate Access Mappings page and typing one in order to associate it with an existing web application (and we will do that later, in case you need it). But that’s not really the point. Public URLs are associated with zones because it is possible that you might want to offer a web application’s contents to users that require different kinds of security, such as SSL or anonymous access. These kinds of users can be thought of as being in different zones. The default zone users are those that are in the local ofﬁce. They’re web application doesn’t need SSL, they may be allowed anonymous access (to read their coworkers’ blogs), and using the server’s NetBIOS name as the URL is ﬁne. The intranet users could be the ones in adjoining buildings, maybe part of the campus, but not in the ofﬁce; they should authenticate to access the site collections they are members of, and they need to use a URL that resolves outside of the ofﬁce. Extranet could be the commuting users, accessing content over the internet; they too need to use an external URL and authenticate to access their content, but they also need SSL to protect their transactions. While the Internet users could be customers or partners also accessing the web application’s content over the internet, while requiring anonymous access and SSL.
ANONYMOUS? Notice that anonymous access is being offered to certain kinds of users depending on the zone they are using to access the same web application. That is why, even though anonymous can be enabled at the web application level, it is additionally allowed or disallowed at the site collection level. Those site collections meant to contain private company data would never enable anonymous on any site, list or library therein, despite the option being available depending on what URL accesses the site collections.
In order to create a new, public URL for accessing a web application using different security settings than the original, that web application needs to be extended to a different IIS Web Site. As you know from creating a new web application, the IIS Web Site determines the URL for the web application, either by setting a custom port for the main URL (such as http://sp2:8080) or by using a host header to give the web application a custom URL (such as http://tech.dem0share.com). The IIS Web Site also determines which kind of authentication is to be used (NTLM, Kerberos, allowing Anonymous Access) and if SSL is going to be used.
Extending a web application creates a new IIS Web Site based on an existing web application’s content. This new IIS Web Site uses the same Application Pool and, therefore, the same content database as the existing web application. But extending a web application lets you add another URL and other IIS Web Site-based settings to access the existing web application’s content. This allows you to create a new public URL for the web application and adjust the security settings for that public URL without changing the existing security settings for your web application’s default public URL.
For the example, we can take the blogging site collection, running in the web application http://sp2:8080, and extend it to the public URL of blogs.dem0share.com, which, in this example, is accessible from the outside world through the ﬁrewall. While we’re at it, we can set the new URL so that it doesn’t permit Anonymous Access. This way only people with log in accounts (the company’s employees) will be able to access the blogs from outside the ﬁrewall. The default, internal URL settings (for http://sp2:8080) will stay the same, and Anonymous Access will be permitted there.
DNS IS STILL CRITICAL We’re going to be doing a lot of work with new URLs, both public and internal. All of these URLs are still dependent on DNS to function. Make sure your DNS server can resolve any URL you create and it points the client to the SharePoint server. Remember that all URLs need to map to an IP address eventually.
To extend a web application, follow these steps:
To extend a web application in Central Administration, click the Create or Extend a Web Application link on the Application Management page in the SharePoint Web Application Management category.
Instead of choosing to Create a New Web Application (as you did earlier), click Extend an Existing Web Application. This will take you to the Extend Web Application to another IIS Web Site page. See Figure 8.51.
Figure 8.51 The Extend Web Application page
Select the web application you want to extend (my example is http://sp2:8080).
Under IIS Web Site, create a new IIS website, mine is called Blogs Outside in the description. Assign it to port 80, and enter the URL you’d like it to have, my example is blogs.dem0share.com, in the Host Header field.
Under Security Configuration, leave NTLM selected, leave Allow Anonymous Access disabled, and leave SSL disabled.
Under Load Balanced URL, leave the new default (mine is http://blogs.dem0share.com:80) and set the Zone to Internet. You can set the zone to any of the five zones that have not already been used. The default zone is being used by the main URL (http://sp2:8080 in my example), so it’s not an available choice. After you’re done creating this extended web application, the Internet zone will no longer be available should you ever choose to extend the existing web application again.
Once you’ve configured the extended web application the way you like, click OK. Windows SharePoint Services will extend the web application to the new IIS Web Site (not need to add any site collections). If you have DNS set up to point the URL to the server, browsing to it will show the same site, but with a new URL in the Address bar and the corrected links and paths will display on the page. See Figure 8.52.
Figure 8.52 The same site as http://sp2:8080 with a new url
Unlike browsing to http://sp2:8080, using this new URL will prompt for authentication because Anonymous Access was disabled for the new IIS Web Site.
Changes to IIS
You can see what changes occurred in to IIS from extending a web site, by going into Internet Information Services (IIS) Manager and checking out the new website, as shown in Figure 8.53.
Figure 8.53 The new IIS Web Site
Go to the Properties of this new IIS Web Site to verify that it is listening on port 80. The Advanced button will show the expected host header. Click the Home Directory tab to see that it is using the same application pool as the original IIS Web Site (SharePoint-8080). This means all trafﬁc bound for this new IIS Web Site will be directed to the same content database as trafﬁc bound for the original SharePoint-8080 Web Site. The SharePoint-8080 Application Pool will list the new Web Site’s Root and layout paths, as shown in Figure 8.54.
Figure 8.54 Application Pool changes
Changes to Alternate Access Mappings
Let’s take a look at what Windows SharePoint Services shows with this new public URL. Go to Central Administration’s Operations page because Alternate Access Mappings, although speciﬁcally for addressing web applications, affect the whole farm. Under the Global Conﬁguration section, click Alternate access mappings. This will take you to the page in Figure 8.55.
Figure 8.55 The Alternate Access Mappings page
This page lists all the current internal URLs and public URLs on the SharePoint server. Any incoming request is examined to see if it matches one of the internal URLs. If it does, the server responds with the path shown in the corresponding public URL. If the request doesn’t match an internal URL, the server responds with the public URL of the default zone on whatever port the request was received on.
If you click the View menu (default view of this list is Show All), you can ﬁlter the view to display the mappings for a particular web application. Let’s look at the original web application we extended (mine is http://sp2:8080), as shown in Figure 8.56.
Figure 8.56 The http://sp2:8080 URLs
The original web application now has two alternate access mappings, one for the default zone and one for the Internet zone. Both mappings have an internal URL and a public URL. Therefore, any request sent to the server as http://blogs.dem0share.com in my example will come back to the requester’s browser showing http://blogs.dem0share.com in the Address bar and for all the paths and links on the page—which means they’ll work ﬁne through the ﬁrewall.
Policies for Zones
You’ll also spot a change to Windows SharePoint Services in Central Administration, on the Application Management page, in the Policy for Web Application link. Policy for Web Application is well named (although a bit vague). It was meant to allow farm administrators to create user policies, manage anonymous access, and manage permissions that are above and beyond the permissions to be applied for normal users of the site collections. When you add a new user to the policy for the web application, the new zone will appear in the dropdown menu, as shown in the graphic below, so you can apply policies to it separately. For much more about adding users to the policy, see Chapter 10, “Central Administration: Application Management.’’
You can also see the effects of zones on the Authentication Providers page (also accessed from the Application Management page). It’s here that Zones come into their own, as you can change authentication settings for a particular zone (always representing an extended web application in this case)
Creating a New Internal URL
Although you can have only ﬁve public URLs for a web application (one for each zone), it’s possible to have several internal URLs for each public URL. Remember that internal URLs are the addresses that Windows SharePoint Services responds to for a particular web application, and public URLs are what are returned to populate the address bar of the client’s browser. To create a new internal URL for a public URL, go to Central Administration’s Operations page, click Alternate Access Mappings to get back to the Alternate Access Mappings page. Click the Add Internal URLs link on the Action bar. This will take you to the page shown in Figure 8.57.
Figure 8.57 Create a new Internal URL
Make sure you’ve chosen the correct Alternate Access Mapping Collection, which is the same thing as the web application, and then enter the new internal URL and chose the zone for this URL. The zone you choose needs to have a corresponding public URL (if you don’t specify one, the new internal URL will be used to ﬁll it).
My example uses a new internal URL called http://blogs for the default zone. As such, internal users who previously had to enter http://sp2:8080 will only need to enter blogs (which is easier for them to remember) into their web browser to go to the Personal Blogs Site Collection. When they get there, it’ll kick back the default zone’s public URL of http://sp2:8080, which is ﬁne because they can resolve that URL (if they were outside the ﬁrewall, this would be a problem). The new internal URL is displayed on the Alternate Access Mappings page (see Figure 8.58).
Figure 8.58 The new Internal URL mappings
Just as you do with all URLs, you need to make sure new internal URLs exist in DNS and point to the server.
Manually Adding a Public URL
You can also edit public URLs from the Alternate Access Mapping page. For example, you can quickly add a new public URL for an unused zone (or change the URL for an existing zone) and save the changes. The public URL will be added to the web application and automatically generate a new internal URL to match. For example, you could use the URL: http://blogserver/as the Extranet zone for the web application http://sp2:8080. See Figure 8.59.
Figure 8.59 Editing a public URL
While this method will work for browsing the web application, it has one key difference from the full Extend a Web Application process: it doesn’t create a new IIS Web Site for the new public URL. This means that there is no new security policy available for the URL, and no host header exists in IIS to direct trafﬁc to the correct web application (Windows SharePoint Services does the redirect on the backend). Although editing existing public URLs is ﬁne if they are extended web applications, you really shouldn’t create new public URLs this way. It simply doesn’t allow you the ﬂexibility of being able to enable unique authentication or policy settings for the URL because it doesn’t have a corresponding Web Site in IIS.
Removing a Public URL (by Removing an Extended Web Application)
You could, conceivably just delete the entry for a public URL, regardless of whether or not it is associated with an extended web application. But if you want to correctly remove an extended web application’s public URL from a web application’s mapping, you should use the Remove SharePoint from IIS Web Site link in Central Administration (under Application Management).
It either just removes the association of the web application with the IIS Web Site in Windows SharePoint Services, or removes the Web Site altogether. This will also allow you to remove the public URL from the list in Alternate Access Mapping. See Figure 8.60.
Figure 8.60 Remove SharePoint from the IIS Web Site
Make sure you select the correct IIS Web Site and zone to remove from the extended web application.
Deleting the IIS Web Site deletes, unsurprisingly, the Web Site, which removes any custom settings you might have—but it also keeps IIS nice and clean. If you chose not to delete the IIS Web Site, the IIS server places the Web Site into the stopped state; so it’s still there, it’s just not running.
Again it is possible to delete the public URL from within the Alternate Access Mapping page, by editing the Public URLs and simply clearing the ﬁeld. However, doing so is not recommended because it makes no change to IIS. This leaves the website running, so it accepts connections for the URL (via the host header) and points them at the web application. In this case, because the public URL has been deleted, Windows SharePoint Services serves the web pages with the default URL (for example, http://sp2:8080), but it doesn’t stop service, it just doesn’t return the former public URL.
So you’ve learned what a site collection is, how to create one and how to manage it, as well as what web applications are and their conﬁguration. At this point you have covered how to use Windows SharePoint Services from web parts to web applications. It’s now time to move on to how to administer Windows SharePoint Services, from Central Administration to Maintenance and Monitoring.
The Bottom Line
Create and customize a new site collection. A new site collection has separate permissions, its own Recycle Bin, its own storage quota, and its own site collection galleries. You can change the regional settings and grant someone site administrator rights on a new site collection without compromising your existing sites.
- Master It Create a new site collection, apply a Site Quota template, and restrict the new site collection to 1GB.
Use managed paths. Windows SharePoint Services uses managed paths to tell IIS which paths in a URL are handled by Windows SharePoint Services and are, therefore, managed. All other paths are considered excluded, and IIS is free to use them with traditional websites. You can add your own managed paths, adjusting the URL of site collections. By default, SharePoint site collections have two managed paths: the path (root), which is explicit, and the path /sites/, which is a wildcard path.
- Master It Deﬁne the difference between an explicit managed path and a wildcard managed path.
Create a new web application. A new web application is fundamentally a new IIS Web Site. Using a new IIS Web Site allows you to change the port for accessing the web application, use a host header, and adjust the IIS-level authentication such as Anonymous Access. Web applications in addition to being a security boundary, are also a boundary for settings such as RSS, sending alerts, upload size limits, and blocked ﬁle types that effect all contained site collections. All SharePoint site collections must reside in a web application. At this level, serious changes can affect the way the site collections are accessed and controlled.
- Master It Create a new web application using a host header, and set up two content databases, both limited to 10,000 sites.
Conﬁgure Anonymous Access. One of the main features of web applications is the ability to allow Anonymous Access to the site collections they contain. Anonymous Access can allow the site to be viewed without requiring a login while retaining all the needed permissions for authenticated users to add, edit, modify, or delete site content. Anonymous Access is enabled in two core steps: ﬁrst by permitting anonymous access at the web-application level, and then by enabling anonymous access at the site-collection level.
- Master It Someone else has allowed Anonymous Access on a web application, and you’re conﬁguring your site collection. You want anonymous users to view only the Status list and nothing else. How do you conﬁgure the site?
Set different zones for different access. Each web application can support up to ﬁve public URLs that it displays in the Address bar and on the page in links and paths. Four of the public URLs can be used for manually entered alternate web addresses or created by extending the web application to a new IIS Web Site, providing a new URL (including a new port if desired), and applying different authentication policies to the same site. For example, one site collection within the local network can permit Anonymous Access, but authentication can be required for anyone accessing the site through the Internet public URL. The ﬁve public URLs are identiﬁed by their zone, and additional internal URLs can be mapped to each zone.
- Master It Extend a web application to a new IIS website with a port of 18080, and set it to the Extranet zone.
For more information, see the following: