Every aspect of IIS can be managed using command-line tools, and nearly as much with a completely revamped and improved IIS Manager GUI (see
Figure 1). It separates the various aspects of web server administration into different categories (for example, IIS, ASP.NET, Web Server Management, Server Components, Security, Performance, Health, and so on).
Previous versions of IIS stored most settings in a proprietary file called the Metabase. It was difficult to edit, and even more difficult to transfer to other servers. In IIS 7, configuration settings are stored in two new XML files. The Application.Host.config file (located in %Windir%\System32\inetsrv\ config) stores IIS server settings and each Web site has its own Web.config file for site-specific settings. Developers can literally copy these files to other IIS servers to create duplicate Web sites, or start with a cloned-based copy.
IIS administrators can also use Remote Desktop or another third-party remote control tool (PC Anywhere, VNC, and so on). Remote Desktop uses the Remote Desktop Protocol (RDP) over TCP port 3389 to provide a reliable and encrypted communications session.
| Note |
The RDP client should be RDP client version 6.1 or later, which corrects an authentication problem that previously allowed man-in-the-middle attackers to read encrypted communications.
|
RDP and many other remote admin tools allow complete control of the web server, and not just IIS. Whatever remote admin tool is used, the administrator should take great pains to make sure the application, password, and connection port are secure.
Feature Delegation
One of the biggest past criticisms of IIS was that it was difficult to give an IIS developer the permissions and privileges he needed to manage the Web site, without giving him control over the entire server. Or it was difficult to configure IIS so that one user had complete control over her Web site, and did not have control on other Web sites located on the same IIS server.
IIS 7 solves this problem with Feature Delegation and Administrator Lists. Unfortunately, Vista contains only the first feature, which is only half the solution. Using Feature Delegation, web administrators can set what features are modifiable on a web server basis (this should be expanded to be configurable on a per Web site or per application basis in future IIS versions). It is standard in the Windows environment that the delegation set for parent objects is inherited by child objects. Longhorn server will contain the Administrator Lists, which will then allow each allowed or denied feature set to be tied to a particular user or group. For now, Vista users will have to be happy with Feature Delegation by itself.
To use Feature Delegation, the user must be an Administrator for the parent object being delegated (i.e., Administrator for server or web administrator for Web site or application pool). The administrator does the following:
-
Open up the IIS Manager console in Features View.
-
Click the web server leaf object.
-
Double-click the Feature Delegation icon under the Management pane (see Figure 2).
Figure 2: IIS Manager with feature delegation option selected
-
Choose the feature you wish to delegate (see Figure 3) and its default delegation state.
Figure 3: Choosing the default delegation state
Each feature can then be set to one of four states:
If a feature or configuration item is set to Read Only, it cannot be modified. If a feature or configuration option is set to Read/Write, it can be modified. Remove Delegation removes any specifically set previous delegation. Reset to Inherited lets the parent object's settings follow down into the child object for that feature.
The Feature Delegation affects only what can or can't be set using the IIS Manager GUI. The users wishing to read or modify the web server, Web site, or application pool must also have the desired NTFS permissions on the ApplicationHost.config file (for the web server) and/or Web.config (for the related Web site).
