|
|
In the previous two chapters, we examined the various tools that can be used to administer IIS 6 machines. In this chapter, we’ll look at how to create and configure websites on these machines. Specifically, we’ll look at basic website configuration and how to create and use virtual directories for hosting site content. Configuration settings related to security, performance, and content publishing will be covered later in Chapter 10, “Securing IIS”; Chapter 12, “Performance Tuning and Monitoring”; and Chapter 16, “Publishing with IIS.”
Let’s begin by looking at the Default Web Site that is created automatically when IIS 6 is installed on a Windows Server 2003 machine (see Figure 7-1). The Default Web Site in IIS 6 contains only a static “under construction” page called iisstart.htm in its home directory C:\Inetpub\wwwroot. If you right-click this site in IIS Manager and select Browse, Internet Explorer will open and display this page. Selecting the Default Web Site node in the console tree of IIS Manager displays some details about this site in the left-hand details pane. For example, the Default Web Site has a site identifier of 1, its state is Running, its IP address is All Unassigned, its port number is 80, and so on. Site identifiers are numbers automatically assigned by IIS when you create websites, and each new website you create has an identifier assigned that is incremented by one over the last created site.
Figure 7-1: The Default Web Site on IIS
If you want to start publishing content on your web server immediately, you can simply copy your HTML files to the \wwwroot directory, and your site will be up and running. Users can then access this site by using any of the following URLs:
http://server_name, where server_name is the NetBIOS name of your IIS machine. This method usually works only on an intranet, that is, within a corporate network. It won’t work across the public Internet unless you’re running your IIS machine on a home network using a cable modem, in which case other users in your neighborhood may be able to access it this way.
http://IP_address where IP_address is the IP address of your IIS machine. This method will work in an Internet environment if your IIS machine is sitting on the perimeter network and has a globally unique IP address assigned to it by your ISP. It can also work from the Internet if your firewall’s Network Address Translation (NAT) filter is configured to forward incoming HTTP requests to your IIS machine when it is behind your firewall.
Of course, if you really want users to be able to access your website from the Internet, you should register a DNS name for the IP address of the Default Web Site on your IIS machine. Users will then be able to access the site using the URL http://domain_name, where domain_name is something like www.mycompanyname.com. For more information on registering DNS names, see the Internet Corporation for Assigned Names and Numbers (ICANN) website (www.icann.org) or contact your company’s ISP.
Once you’ve decided to use the Default Web Site on your IIS machine for hosting content, you can further configure the site using properties sheets in IIS Manager. Of course, you don’t have to use the Default Web Site if you don’t want to. In fact, you can delete it without any harm and create new sites—it’s up to you.
Note | If you delete the Default Web Site and then create a new site with the same name and identical properties, the new site will have a different site identifier randomly assigned to it. |
An important thing to know about IIS properties sheets is that they exist at different levels, with those lower down inheriting their settings from (or overriding the settings of, if you select that option) those higher up. There are five different levels of IIS properties sheets that can be used to configure website settings:
server_name Properties Where server_name is the name of the IIS machine. You saw this sheet in Chapter 5, “Administering Standard/Enterprise Edition,” (see Figure 5-10 in that chapter). It has only one tab, Internet Information Services, on which you can configure global MIME types, enable direct metabase editing, and enable UTF-8 logging. Of these settings, only MIME types can be configured at lower levels; I’ll discuss this shortly.
Web Sites Properties You saw this sheet also in Chapter 5 (see Figure 5-2). It has nine tabs that can be used to configure global settings for all websites on the IIS machine. Any changes made on this sheet are inherited by all sites and virtual directories on the machine. As shown on Figure 5-2, certain configuration settings are grayed because these settings are specific to individual websites. Examples of such unique settings include Web Site Identity on the Web Sites tab (it must be different for each site on the machine) and Content Location on the Home Directory tab (it’s usually different for each site on the machine).
web_site_name Properties Where web_site_name is the name of a particular website on the IIS machine (see Figure 7-2 for the properties sheet of the Default Web Site). This sheet has eight tabs, all of which are also on the Web Sites Properties sheet just described (it’s lacking the nine tab called Service), and any settings configured here override those configured at the Web Site Properties level above it.
Figure 7-2: Properties sheet for the Default Web Site, showing the Web Site tab
Directory (or Virtual Directory) Properties The name of this sheet depends on whether you are configuring the properties of a physical or virtual directory within a website. Physical directories are created using Windows Explorer, while virtual directories are usually created using IIS Manager; I’ll talk more about their difference later in this chapter. Either way, this properties sheet has five tabs that correspond to five similar ones at the web_site_name and Web Site properties levels just discussed.
file_name Properties Where file_name is the name of the file; for example, iisstart.htm Properties would be the name of the properties sheet for the file iisstart.htm in the home directory of the Default Web Site.
To help you get the big picture of configuring websites and their directories and files, Table 7-1 shows which tabs appear on the properties sheets for each configuration level just described.
Tab | Web Sites Level | web_site Level | Directory Level | File Level |
---|---|---|---|---|
Web Site | Ö | Ö | ||
Performance | Ö | Ö | ||
ISAPI Filters | Ö | Ö | ||
Home Directory | Ö | Ö | Ö | Ö |
Documents | Ö | Ö | Ö | Ö |
Directory Security | Ö | Ö | Ö | Ö |
HTTP Headers | Ö | Ö | Ö | Ö |
Custom Errors | Ö | Ö | Ö | Ö |
Service | Ö | Ö | Ö | Ö |
1. This tab is called Directory for physical directories and Virtual Directory for virtual directories.
2. This tab is called File at the File level.
3. This tab is called File Security at the File level.
The following walkthrough demonstrates how inheritance and override of properties sheet settings work with IIS. Open the properties sheet for the Default Web Site, select the HTTP Headers tab, and verify that the content expiration feature is disabled (unchecked). Close this properties sheet and open the one for the Web Sites node, which is one level above the properties for individual web sites. Select the HTTP Headers tab and click the check box to enable content expiration globally for all websites on IIS. Close this properties sheet to apply the changes, and then open the Default Web Site Properties again and verify the change has been applied to this specific website. Close the Default Web Site Properties and open the properties sheet for the iisstart.htm file in this site’s home directory. Switch to the HTTP Headers tab of the iisstart.htm Properties and verify again that individual files have inherited this setting.
Now clear the check box on the HTTP Headers tab of iisstart.htm Properties to disable content expiration for this specific file and override the global setting made earlier at the Web Site level. Click OK to apply the changes and close the sheet. Open the Default Web Site Properties, switch to the HTTP Headers tab, and clear the check box here as well. Click OK to apply the changes, and notice that this time an Inheritance Overrides dialog box appears (see Figure 7-3). This didn’t appear when you made the change at the file level because there are no child nodes beneath the file level. Now you are making a change at the website, and the site contains a file (iisstart.htm) that has previously had this setting changed, so IIS asks you whether you want to apply these changes to child nodes beneath the selected level and override the changes made previously. Select the iisstart.htm file within this dialog box (or click the Select All button to cause all child nodes to inherit the change), and close the box to apply the changes.
Figure 7-3: The Inheritance Overrides dialog box tells you when you are about to overwrite previously configured IIS settings.
Note | The Inheritance Overrides dialog box only appears when the action you are about to perform might override similar settings that have been previously configured at a lower level. In other words, it only appears when a conflict in settings occurs. For example, say you changed the content expiration setting on a virtual directory within a website. If you then changed a different setting at the site level, such as defining a custom HTTP header, the Inheritance Overrides dialog box will not appear because the custom HTTP header settings were not previously changed at the directory level—the dialog box will only appear if you try to change the same setting (content expiration) at the higher level that was previously changed at the lower level. |
Let’s now examine some of the basic configuration settings at the individual website level. I won’t cover everything about configuring websites in this chapter; I’ll defer discussing application, performance, and publishing settings later in Chapters 8, 10, and 16, where they can be covered in a more consistent fashion.
We’ll begin by looking at the Web Site tab of the Default Web Site Properties sheet (see Figure 7-2 again). Every website you create using IIS has to have a website identity. In this case, the Description (name) specified for the site is Default Web Site, the IP Address is (All Unassigned), and the TCP port is 80. Changing the description here changes the name displayed for the site in IIS Manager but has no effect on how users access the site using their web browsers. In other words, the Description field is simply a friendly name for the site as displayed in IIS Manager. The Web Site Identification specified here is different from the site identifier discussed previously, which is generated automatically by IIS when the site is created and cannot be changed here.
The interesting thing about the identity of the Default Web Site is that its IP address is (All Unassigned). To understand this, consider that IIS is designed to host multiple websites, and often each site will have its own assigned IP address. Say you had five IP addresses ranging from 172.16.11.15 through 172.16.11.19, bound to the IIS machine’s network card (I’ll use addresses from the private class B address space 172.16.0.0–172.31.255.255 because I’m working in an intranet environment). Now say you create two new websites on the machine and assign the address 172.16.11.15 to site A and 172.16.11.16 to site B. The following list shows what happens when you try to open different URLs using Internet Explorer on a computer on our network:
http://172.16.11.15 opens home page for site A.
http://172.16.11.16 opens home page for site B.
http://172.16.11.17 through 172.16.11.19 opens the home page (or under construction page) for Default Web Site.
Thus, (All Unassigned) means that when you try to open a URL with any IP address bound to your IIS machine’s NIC, but which is not specifically assigned to another website on the machine, the Default Web Site is opened in the browser window. I’ll talk more about website identities later in this chapter in the “Creating Websites” section. I’ll defer a discussion of connections settings until Chapter 12 and website logging until Chapter 13. First, I’ll delve a little deeper into this idea of a default website.
Note | If you have multiple IP addresses and multiple websites on your IIS machine and try to open the URL http://server_name, where server_name is your machine’s NetBIOS name, you will open the website that has been assigned the first IP address in the IP address drop-down list on the Website tab. |
By the way, only one website on your machine can have All Unassigned as its IP address on the Web Site tab of its properties sheet. Whatever the actual name (description) of that site, by assigning it this address it becomes the default website on the machine. However, you don’t have to have a website with this setting on your machine, and if you like, you can assign the Default Web Site a specific IP address from the drop-down list of addresses. The whole idea is that this All Unassigned option lets you have your machine serve up a specific default site whenever a user tries to open a URL with an IP address bound to the machine’s network adapter but not specifically assigned to a website on the machine. This is particularly useful in a public web-hosting environment at an ISP. For example, say you have 100 IP addresses on your IIS machine and it hosts 50 websites with 50 of these addresses. You can create a home page for your fifty-first site, the Default Web Site, and have that page display your ISP company logo, a suggestion like “This space available for web hosting,” and your pricing scheme for hosting. Then if a user tries browsing all the IP addresses of your machine in sequence (yes, there are people who actually like to do this), half the time they will see the page showing your logo and pricing message.
Another use for this feature is to make the home page of your Default Web Site say something like, “There’s a problem with your site, please contact your ISP administrator.” Say you’re a customer that owns one of the 50 websites created on the IIS machine, and say your website stops for some reason (maybe the administrator stopped it to make some changes and forgot to restart it). Now when your customers try to access your stopped site, the home page for the Default Web Site will be displayed instead. Soon they’ll be phoning you and asking you what the problem is, and you’ll know to contact your ISP to find out if your site is stopped.
What if you don’t have a website on your server that has All Unassigned as its IP address? When users try to open URLs containing IP addresses that are bound to the machine but not assigned to specific sites, they will get a simple message saying “Bad Request (Invalid Hostname)” in their browser window. Not very informative, is it? Perhaps you can come up with some other creative scenarios in which there might be a default website on your machine that has All Unassigned for its IP address setting!
Switch to the Home Directory tab of the Default Web Site Properties (Figure 7-4). As you can see, there are three possible locations for a website’s content: local directory, network share, or redirection.
Figure 7-4: The Home Directory tab of the Default Web Site Properties sheet
If you select the A Directory Located On This Computer option, your home directory will be a directory on the IIS machine itself. By default, the Default Web Site is assigned the home directory C:\Inetpub\wwwroot on the local machine, but you can change this to a different directory by clicking the Browse button on the Home Directory tab. Locating content on the local machine provides best performance in most cases.
Tip | To change the location of content on your local server, you can either move the content of the \wwwroot directory to a new folder on your machine or rename the \wwwroot directory directly. Be sure to stop your website before you specify a new location for the content associated with its home directory. You will learn how to pause, stop, resume, and restart a website later in this chapter in the section “Stopping, Pausing, and Starting Sites.” |
Note | You can also change the location of your site’s home directory by editing the metabase, something you’ll learn about later in Chapter 14, “Working with the Metabase.” |
If you select the A Share Located On Another Computer option (see Figure 7-5), your home directory will be a shared folder on another machine. It may often be desirable or convenient to create and store web content on a different machine—for example, a file server on your network. In this case, you can point IIS to the network share as the home directory for your website. If you select this option and specify a share (using a UNC pathname such as \\server_name\share_name), the default setting is for the connection to use the credentials of the logged-on user (the user trying to access the content) for purposes of accessing the share. Alternatively, you can also enter other credentials for accessing this share. For these credentials, do not use an account belonging to the local Administrators group or Domain Admins group because this may constitute a security risk and allow clients access to server operations. Instead, create an ordinary user account and make sure the shared folder permissions grant this account sufficient permissions for IIS to access the content using the account. You can also do this by granting the appropriate permissions to the Users Or Domain Users group to which this user account belongs, or by granting these permissions to the Everyone built-in group.
Figure 7-5: Specifying a remote home directory for the Default Web Site
If you are working in a domain environment, you can select a specific domain account for connecting your IIS machine to the remote network share by clicking the Connect As button, deselecting the Always Use The Authenticated User’s Credentials When Validating Access To The Network Directory check box (see Figure 7-6), and clicking the Browse button to search Active Directory for the domain account you want to use. If you are working in a workgroup scenario, it’s a little trickier: first use Local Users And Groups in Computer Management to create identical local user accounts (identical names and passwords) on both the IIS machine and file server, and then deselect the check box shown in Figure 7-6 and enter the username and password for the account (you will be prompted to confirm the password). If you try to use a local user account on the file server but don’t have an identical local account on the IIS machine, you may be able to initially connect to the share in IIS Manager, but when you try to browse the website you will get an HTTP 500 Internal Server Error message. Make sure the local user account you create is a member of the Users local group but not the Administrators group, and the account is configured so that the password is complex (it can’t be guessed) and does not expire.
Figure 7-6: Specifying credentials for accessing content located in a remote directory
An alternative to locating your website content on the local IIS machine or a share on a network file server is to use redirection, which allows you to point your home directory to a file or folder on another website, even one located elsewhere on the Internet. Redirection is often used temporarily when content is being moved or reorganized on a site, or it can be used permanently when a business changes its name or becomes a subsidiary of another business. Because redirection is more of a publishing issue than a basic administration one, we’ll discuss it in detail in Chapter 16, Publishing With IIS.
Once you’ve decided on the location for the home directory of your website, you can create additional directories for hosting other portions of your site’s content. IIS gives you a great deal of flexibility in how to do this, and you can use either physical or virtual directories, as I’ll describe next.
A physical directory is simply a subdirectory of your home directory. For example, say you’ve decided to use the Default Web Site on your server for hosting your company’s intranet site. The default home directory for this site is C:\Inetpub\wwwroot, and users can access the home page Default.htm for this site by using the URL http://snoopy where SNOOPY is the name of your IIS machine (or they could use the server’s IP address or DNS name if DNS is configured). Say you want to create two subsections for the intranet, one for Sales and one for Support, and you want employees to be able to access these sections using http://snoopy/sales and http://snoopy/support. First, create a physical directory for the Sales Department as follows: right-click the Default Web Site in the console tree in IIS Manager and select Explore. This displays the contents of the home directory \wwwroot using a Windows Explorer window for the details pane. Now right-click an empty spot in the details pane and select New | Folder, and then type sales for the name of the folder and press ENTER. Press F5 to refresh the console and expand the Default Web Site node to display the new subfolder \wwwroot\sales you’ve created. To test this, copy the iisstart.htm page from the home directory into the Sales subdirectory and then click Start | Run and type http://localhost/sales. Note that the Sales directory appears in your browser window as expected.
There’s another way to do this using virtual instead of physical directories. A virtual directory behaves as if it were simply a subdirectory of the home directory, but in fact it is located in a different part of the local file system or even on a remote file server somewhere else on the network. Continuing the previous example, you could create a virtual directory called Support that allows users to access the Support portion of the intranet using the URL http://snoopy/support. However, instead of this department’s content being located in the folder C:\Inetpub\wwwroot\support as expected, it’s actually in C:\other. I’ll show you how to do this now.
Use Windows Explorer to create the C:\other folder and copy iisstart.htm into it. Now go to IIS Manager, right-click Default Web Site and select New | Virtual Directory. This opens the Virtual Directory Creation Wizard. Click Next and type support as the alias for the virtual directory you are going to create (see Figure 7-7). The alias of a virtual directory is the name that will be used to identify the directory in URL used to access it, and since you want to access this directory using http://snoopy/support, you’d use Support as the alias for the directory.
Figure 7-7: Specifying an alias for a new virtual directory
Click Next and specify the path to the directory as C:\other, or click Browse to locate this folder. Click Next and specify the IIS permissions for this directory, which by default are to allow Read And Run Scripts and to deny anything else. (I’ll talk about permissions in detail in Chapter 10, so just accept the defaults for now.) Click Next and then Finish to complete the wizard and create the new Support virtual directory within the Default Web Site. Then click Start | Run and type http://localhost/support; the Support virtual directory opens up in your browser window as expected. Now select the Default Web Site in the console tree and note that virtual directories are displayed differently from physical ones in two ways: they have a different icon (the gear icon) and display the corresponding physical directory C:\other to which the alias is mapped (see Figure 7-8).
Figure 7-8: The Default Web Site showing the new Sales (physical) and Support (virtual) directories
Security Alert! | Using virtual directories instead of physical ones has a security aspect as well, since it means users won’t be able to guess where the content they are viewing is actually being stored. Another advantage of virtual over physical directories is that they make it easier for you to relocate your content when required, even if it means moving content to a different server. |
Note | Note that deleting a physical directory deletes your content as well, while deleting a virtual directory in IIS Manager simply removes the alias but has no effect on the content directory it was mapped to. |
Virtual directories may be either local or remote—in other words, an alias can map to either a folder on the local file system or a UNC path to a network share on some file server. Creating a remote virtual directory is almost the same as making a local one— simply start the Virtual Directory Creation Wizard; and when asked to specify the location of the website content directory, type the UNC path to the network share and then specify credentials for accessing this share (similar to credentials for accessing a remote home directory, as described earlier in this chapter). Alternatively, you can create a local virtual directory first and then open its properties sheet, select the Virtual Directory tab, and specify that the content for this directory will come from a share located on another computer.
Another way of creating a virtual directory is to use the Web Sharing feature of Windows Explorer. Simply right-click the physical folder in Windows Explorer for which you want to create an alias and select Properties, and then select the Web Sharing tab. To use this tab to create a new virtual directory, follow this procedure:
Select the website within which the virtual directory is to be created using the Share On drop-down box.
Select the Share This Folder option to open the Edit Alias dialog box (Figure 7-9).
Figure 7-9: Creating a virtual directory using Web Sharing
Specify an alias for the virtual directory (or accept the default alias, which is the same as the name of the physical directory it maps to).
Select the default permissions or modify them as desired.
Click OK to create the virtual directory.
Now go to IIS Manager and refresh the console to verify that the virtual directory was indeed created.
Tip | Using Web Sharing, you can easily create multiple aliases for a directory and then assign each alias to a different website. |
You can create a virtual directory by importing a configuration file, which is an XML file containing a portion of the metabase describing the configuration of the virtual directory. You could create such a configuration file by hand—if you were bold (or crazy) enough—but it’s more likely you would export a virtual directory configuration file from another IIS server and import it into your own server, for example, when migrating virtual directories from one site to another or from one server to another. Try this:
Open IIS Manager, right-click a virtual directory you created earlier, and select All Tasks | Save Configuration To A File to open the Save Configuration To a File dialog box (see Figure 7-10).
Figure 7-10: Saving the configuration of a virtual directory to an XML file
Specify a name for the configuration file, the folder in which to save the file, and optional password for encrypting the file.
Click OK to save the configuration file (you can open it in Notepad to view its contents).
Right-click the virtual directory, and select Delete to remove it from your site (this deletes the alias only, not the content).
Right-click the Default Web Site and select New | Virtual Directory (From File) to open the Import Configuration dialog box, and browse to locate the saved configuration file you created earlier.
Click the Read File button, and the alias of the virtual directory will be read from the configuration file and displayed in the dialog box.
Select the name of the virtual directory under Location, and click OK to import the configuration and re-create the virtual directory.
You should now again see the virtual directory you previously deleted in IIS Manager!
Note | You’ll learn more about the new XML metabase and how to work with it in Chapter 14. |
Tip | You can also create virtual directories from the command line using the iisvdir.vbs script included with IIS 6. We’ll look at command-line administration of IIS in Chapter 11. |
When you try to open a nonspecific URL like http://snoopy or http://snoopy/sales, one that doesn’t explicitly specify the name of the exact file that should be opened, IIS responds to the browser by sending it the default document for the site or directory. Typical names for default documents include
Default.htm
Default.asp
index.htm
The Default Web Site includes a special default document called iisstart.htm that displays an “under construction” page when viewed in a browser. But how does IIS know which file is the default document for a given site or directory? The answer is on the Documents tab of the properties sheet for the site or directory. For example, the Documents tab for the Default Web Site properties sheet shows several possible names for default documents (see Figure 7-11). When a nonspecific URL is used to access this site, IIS begins at the top of the list and searches for a file in the home directory having one of the names listed. You can rearrange the order of these default documents so that IIS searches for them in a different order, and you can add additional names for default documents or remove unneeded ones.
Figure 7-11: Specifying default documents for the Default Web Site
If you deselect the Enable Default Content Page check box, IIS won’t look for a default document, and it will respond to nonspecific URL requests with an HTTP 403 Forbidden message unless you also enable directory browsing on the Home Directory tab. (Directory browsing is not usually recommended, however, because it exposes the contents of your directory to users if there is no default document in the directory.) Note that you can specify default documents separately for the site’s home directory and for each virtual directory within the site.
I mentioned MIME types in Chapter 5, and now’s the time to talk about them detail. On the HTTP Headers tab of the Default Web Site properties sheet, there is a button called MIME Types that you can use to register additional MIME types for this website, that is, in addition to the default MIME types defined globally at the server level for all sites on IIS. MIME stands for Multipurpose Internet Mail Exchange and is used to specify which types of files IIS will serve to browser clients in response to HTTP GET requests. To understand MIME types better, try the following exercise: Create a simple HTML page named test.xyz and place it in the \wwwroot directory, which is the home directory for the Default Web Site on your machine. Open Internet Explorer and try to open the URL http://localhost/test.xyz and see what happens. You should get an HTTP 404 Error—File or directory not found. This is because the file extension .xyz is unknown to IIS—that is, it has no associated MIME type registered for it. To verify this fact, right-click the server_name node in IIS Manager and select Properties to open the properties sheet for the IIS server (see Figure 5-10 again in Chapter 5). Click the MIME Types button to open the MIME Types box showing global MIME mappings defined by default on IIS (see Figure 7-12). Now if you scroll through this list, you can verify that there is no longer any registered mapping for the .xyz extension. In other words, when IIS receives a URL requesting a file of type .xyz, it simply doesn’t know what to do with it, so it generates a 404.3 error.
Figure 7-12: The list of global MIME mappings that are registered by default
Note | In the previous version of IIS, if a client requested a file having an extension with no registered MIME type associated with it, the MIME type defaulted to application/octet-stream and the server prompted the user to download the file using a dialog box. The fact that version 6 of IIS no longer does this is a security improvement to reject improper client requests. Creating a wildcard MIME mapping, as described next, essentially has the effect of disabling this new IIS 6 security feature. |
Tip | You only have to restart IIS after changing MIME types if you want your changes to take effect immediately. Otherwise, the server will cause the changes to take effect when the worker processes recycle. |
Let’s say that for some weird reason you want your IIS machine to recognize and serve .xyz files as standard HTML files. To see how to do this, scroll down the list of registered MIME types in the global MIME Types dialog box and note that the MIME type for .htm files, which is the normal extension for HTML files, is text/html. To define a new MIME type at the global level that applies to all sites running on the IIS machine, click the New button and type xyz in the Extension field and text/html in the MIME Type field (see Figure 7-13). Click OK, and the new MIME type should appear in the list. Right-click the server_name node and select Restart IIS to update the server’s internal list of MIME types, and then try opening the URL http://localhost/test.xyz. It should display the HTML page as expected.
Figure 7-13: Creating a new MIME type mapping
You can also define MIME types for the Web Sites node and at the level of individual websites or directories on your machine, and the usual rules of inheritance and override apply. You can configure IIS to serve any requested file type by creating a wildcard MIME type that has an asterisk (*) for its extension. If you do this and specify text/html as the MIME type, any file extension not in the global MIME map will be interpreted by IIS as an HTML file and served that way to clients. Or, if you map the wildcard extension to the MIME type application/octet-stream, IIS will treat any file extension not in the MIME map as a binary file (IIS will first try to interpret it as HTML, and if it can’t do so, will ask the client if it would like to download the file).
IIS has three different mechanisms for deciding what to do when clients request files, and they are applied in the following order:
Special extensions File extensions like .exe or .dll are treated as ISAPI extensions or CGI applications. This behavior is hard-coded into IIS and cannot be changed.
Scriptmap entries File extensions that match a scriptmap entry are processed by the ISAPI extension or CGI application indicated in the scriptmap. The IIS scriptmap specifies which script processor is used for executing a given script type (for example, .asp for Active Server Pages). You can view or modify scriptmap settings on the Home Directory tab of a website’s properties sheet (or the Virtual Directory of a virtual directory’s properties sheet). Scriptmap settings are in the IIS metabase in a series of lines starting with ScriptMaps and can be modified by editing the metabase (see Chapter 14 for more info).
MIME types All other file extensions are passed to the internal MIME map and are served by IIS using the HTTP protocol, except that for the application/octet-stream MIME type, the client is prompted to download the file instead.
Before you make a configuration change to a live site, you should stop the site. Stopping a website disconnects any users connected to it and prevents others from accessing it. You can also pause a site, which leaves users presently connected to the site unaffected while preventing others from accessing the site. This would be preferable in an e-commerce scenario where you want to allow user transactions to be completed to avoid causing problems for users and losing business. In this case, pause the site for a short period of time until all users disconnect, and then stop the site, make your configuration changes, and start the site again.
To stop, pause, resume, and start a website on IIS, right-click the site in IIS Manager and select Stop, Pause, or Start (selecting Pause twice resumes a paused site).
Note | If you stop a website and then restart IIS using the method described in Chapter 5, the website will still be in a stopped state afterward and must be restarted using the method just described. |
Tip | You can also stop, pause, and start websites from the command line, which I’ll cover in Chapter 11. |
I already mentioned that you can save the configuration of an individual virtual directory as an XML file and then use this to move the virtual directory to another site or IIS machine. The same goes with entire websites—you can save their configuration as a file and import it back into the same server or a different one. Let’s try this with the Default Web Site:
Right-click the Default Web Site, and select All Tasks | Save Configuration To A File.
Right-click the Default Web Site and select Delete to remove it from your server. This deletes only the alias for the virtual server for the site—the C:\Inetpub\wwwroot content directory is unaffected by this action.
Right-click the Web Sites node in the console tree and select New | Web Site (From File)
Browse to find the configuration file you saved earlier, and click the Read File button to verify its integrity.
Select Default Web Site as the configuration you wish to import.
Click OK to import the configuration and re-create the Default Web Site again.
Restart the Default Web Site (importing a website configuration from a file leaves the new site in a stopped condition).
Here are a few more administration tasks you can perform on the Default Web Site by right-clicking its node in IIS Manager:
Explore Switches the details pane to Windows Explorer view—but only while that node is still selected in the console tree!
Open Opens a separate Explorer window displaying the contents of the home directory C:\Inetpub\wwwroot.
Permissions Lets you configure the NTFS permissions of the home directory.
Browse Switches the details pane to Internet Explorer view—again, only while that node is still selected in the console tree.
Rename Same effect as changing the Description field on the Web Site tab of the Default Web Site Properties sheet.
You can list all the websites on your server by selecting the Web Sites node in IIS Manager. This will display the identifier, IP address, port number, status, and other attributes of each site.
|
|