Chapter 11: Internet Information Services 7.0
Watching Microsoft Internet Information Services (IIS) evolve over the last decade or so has been exciting. While a high point for end-user experience was probably the worldwide release of Microsoft Windows 95, for an IT pro like me, one of the high points in Windows platform development was the Microsoft Windows NT 4.0 Option Pack release of IIS 4.0. Since then, as the version numbers have continued to climb, IIS has evolved into the most secure, reliable, and powerful Web application platform around. For instance, since IIS 6.0 was released on Windows Server 2003, there hasn’t been a single critical security update for IIS. So what could possibly be new, then, in IIS 7.0? Where can you possibly go if you’ve already reached the top?
Understanding IIS 7.0 Enhancements
Well, you can always try climbing higher. And that’s exactly what the IIS product team has done in version 7 of IIS, which was released with Windows Vista and is being further enhanced and fine-tuned for Windows Server 2008. Compared with the previous version (IIS 6.0), version 7 of IIS has been improved in five main areas:
-
Security and patching
-
Administration tools
-
Configuration and deployment
-
Diagnostics
-
Extensibility
Let’s examine each of these five areas of enhancement, and as we do so we’ll get a whirlwind tour of what IIS 7.0 is all about. Sort of like the trip my wife and I made to Europe a few years after we got married-on the left is the Eiffel Tower, on the right is the Matterhorn, over here is the Coliseum, over there is a topless beach near Corfu. Look, the Mona Lisa in the Louvre! Wow, we’re at the top of the dome in St. Peter’s Basilica! Wow, we’re five stories underground in the Catacombs! Look, wow, look at that, wow, look, wow-zoom, we’re home!
Sorry but that’s a bit what our tour of IIS 7.0 will be like because there’s so much to learn about that it would really take an entire book to do this feature justice. And we’ve got only a single chapter to do this-so let’s get started! Fortunately, we also have our tour guides (our Microsoft experts) along for the ride to help point out some of the highlights! But like any good tour operator, I want to map out for you where we’re going in this chapter. First we’ll describe each of these five areas of improvement and note some of the sights worth seeing. Along the way, we’ll briefly go inside IIS 7.0 and examine its architecture, which is more interesting than a 16th-century cathedral (well, to a geek, anyway). Then we’ll talk about some of the post-Vista improvements that are coming in Windows Server 2008 (though we’ll actually mention some of these during the earlier part of our tour). And finally, I’ll talk briefly about the Application Server role in Windows Server 2008-summarizing what it’s about and how it ties in with IIS. And for those of you who are still unsatisfied at the end of our journey and want to see more, I’ll list additional resources you can use to learn more about IIS 7.0 on your own. Sound good? Fasten your seatbelts-we’re off!
Security and Patching
One thing I really like about IIS 7.0 is its new modular architecture. What this means is that instead of IIS being a monolithic entity installed by default with only a few features available for optional installation, IIS 7.0 now has more than 40 separate setup components you can choose from and only a small set of these are installed by default. You can now install only IIS features you actually need on your Web server and leave the remaining features uninstalled. The benefits of doing this are fivefold:
-
First, your system is more secure. Why? Because the only IIS binaries installed on your system are those you actually need. And the fewer binaries, the less attack surface there is on your machine.
-
Second, your system is easier to service. Why? Because maintaining a server involves keeping it patched with the latest critical updates from Microsoft. But if you have only a subset of the available IIS modules installed on your machine, you have to patch only those modules-you don’t have to patch modules that aren’t installed.
-
Third, your system is also easier to manage. For example, as we’ll see in a moment, if the component supporting Basic authentication is not installed on your system, the configuration setting for this feature won’t be present. And the fewer configuration settings that are surfaced, the less clutter the admin UI has and the easier it is to manage your server.
-
Fourth, you can customize your Web server to function in a specific role in your environment.
-
And fifth, you can reduce the memory footprint of your Web server by removing unnecessary modules. As a result, the amount of memory used by worker processes on your machine will be reduced, which can allow you to host more Web sites and Web applications on your machine-something especially valuable in large hosting environments. Reducing the number of installed modules also means that fewer intra-process events are occurring, so this also frees up CPU cycles as well-something that, again, is important in hosting environments.
In addition, you can even create your own custom modules and use these to replace existing modules or add new features to your Web server. We’ll talk about this later when we discuss the extensibility of the IIS 7.0 platform.
The following graphic shows the IIS 7.0 components available for you to install when you add the Web Server (IIS) role to your Windows Server 2008 machine. These components are called modules, and you can add or remove them from the Web server engine, depending on what you need.
The preceding illustration shows that IIS 7.0 modules are grouped into various categories of functionality. Table 11-1 lists the different modules available in each category and provides a short description of what they do.
| Module Name | Description |
|---|---|
| HTTP Modules |
|
| CustomErrorModule | Sends default and configured HTTP error messages when an error status code is set on a response |
| HttpRedirectionModule | Supports configurable redirection for HTTP requests |
| OptionsVerbModule | Provides information about allowed verbs in response to OPTIONS verb requests |
| ProtocolSupportModule | Performs protocol-related actions, such as setting response headers and redirecting headers based on configuration |
| RequestForwarderModule | Forwards requests to external HTTP servers and captures responses |
| TraceVerbModule | Returns request headers in response to TRACE verb requests |
| Security Modules |
|
| AnonymousAuthModule | Performs Anonymous authentication when no other authentication method succeeds |
| BasicAuthModule | Performs Basic authentication |
| CertificateMappingAuthenticationModule | Performs Certificate Mapping authentication using Active Directory |
| DigestAuthModule | Performs Digest authentication |
| IISCertificateMappingAuthenticationModule | Performs Certificate Mapping authentication using IIS certificate configuration |
| RequestFilteringModule | Performs URLScan tasks, such as configuring allowed verbs and file extensions, setting limits, and scanning for bad character sequences |
| UrlAuthorizationModule | Performs URL authorization |
| WindowsAuthModule | Performs NTLM integrated authentication |
| Content Modules |
|
| CgiModule | Executes CGI processes to build response output. There™s also a FastCGI handler that™s installed as part of the CGI install. |
| DavFSModule | Sets the handler for Distributed Authoring and Versioning (DAV) requests to the DAV handler |
| DefaultDocumentModule | Attempts to return the default document for requests made to the parent directory |
| DirectoryListingModule | Lists the contents of a directory |
| IsapiModule | Hosts ISAPI DLLs |
| IsapiFilterModule | Supports ISAPI filter DLLs |
| ServerSideIncludeModule | Processes server-side includes code |
| StaticFileModule | Serves static files |
| Compression Modules |
|
| DynamicCompressionModule | Compresses responses, and applies Gzip compression transfer coding to responses |
| StaticCompressionModule | Performs precompression of static content |
| Caching Modules |
|
| FileCacheModule | Provides user-mode caching for files and file handles (required) |
| HTTPCacheModule | Provides kernel-mode and user-mode caching in HTTP.sys (required) |
| SiteCacheModule | Provides user-mode caching of site information |
| TokenCacheModule | Provides user-mode caching of user name and token pairs for modules that produce Windows user principals (required) |
| UriCacheModule | Provides user mode caching of URL information (required) |
| Logging and Diagnostics Modules |
|
| CustomLoggingModule | Loads custom logging modules |
| FailedRequestsTracingModule | Supports the Failed Request Tracing feature |
| HttpLoggingModule | Passes information and processing status to HTTP.sys for logging |
| RequestMonitorModule | Tracks requests currently executing in worker processes, and reports information with Runtime Status and Control Application (RSCA) Programming Interface |
| TracingModule | Reports events to Microsoft Event Tracing for Windows (ETW) |
Open table as spreadsheet You can install these modules by adding role services and features to the Web Server (IIS) role using Server Manager. (Note that some of these modules cannot be selectively installed or uninstalled unless you uninstall the entire w3svc.) When you add the Web Server (IIS) role to your Windows Server 2008 server, a subset of available role services and features is installed by default (though you can also choose to add role services and features at this time or later).
Note in the preceding figure that the Basic Authentication role service (that is, BasicAuthModule) is not included in a default install of the Web Server (IIS) role. Keep this in mind, as we’ll come back to it later.
To get an idea of how “minimal” IIS 7.0 is out of the box, when you add the Web Server (IIS) role using the defaults already selected for this role, only the following role services and the specified subcomponents (modules) actually get installed:
-
Common HTTP
-
Static Content
-
Default Document
-
Directory Browsing
-
HTTP Errors
-
-
Health and Diagnostics
-
HTTP Logging
-
Request Monitor
-
-
Security
-
Request Filtering
-
-
Performance
-
Static Content Compression
-
-
Management Tools
-
IIS Management Console
-
Look under the Security role service in the preceding list-no Basic authentication, right? Remember that for later.
Windows Process Activation Service
When you add the Web Server (IIS) role to your Windows Server 2008 server, you’re also required to install a feature called Windows Process Activation Service (WPAS), together with its three subfeatures: Process Model, .NET Environment, and Configuration APIs. WPAS manages application pools and worker processes running on your machine for both HTTP and non-HTTP requests. For example, when a protocol listener picks up a client request, WPAS determines whether a worker process that can service the request is already running within the application pool. If this is the case, the listener adapter passes the request to the worker process for processing. If there isn’t a worker process running in the pool, WPAS starts a new worker process and the listener adapter passes the request to it for processing.
WPAS also functions as a configuration manager that reads and maintains configuration information for sites, applications, and application pools running on IIS, as well as for the global configuration, which includes HTTP central logging and so on. In addition, WPAS maintains the life cycle of worker processes by starting them (for example, when requests come in), stopping them (when they idle out), monitoring their health, and recycling them when needed.
What new functionality does WPAS provide that wasn’t there in previous IIS platforms? Let’s hear from one of our experts:
 |
Windows Process Activation Service, also referred to as WPAS, is a new component in IIS 7.0 that manages application pool configuration and worker processes instead of the WWW process. This enables the same configuration for both HTTP and non-HTTP sites to be used. Thanks to this separation (and in combination with the new modular architecture of IIS 7.0), you can even host non-HTTP sites without the WWW Service even being installed in the first place.
What scenarios does this enable? Because WPAS is not specific to HTTP sites, you can use WPAS to host non-HTTP sites as well. But what do we mean by “non-HTTP sites”?
Well, simply put, WPAS can be used to host sites built on technologies such as Windows Communication Foundation, for example. If you are using WCF with WPAS, are you limited to listening over HTTP? Not at all. In fact, that is the beauty and power of WPAS. You can be hosting a WCF service within WPAS that is using netTcpBinding, netMsmqBinding, and so on. As an extension to this, because WPAS supports both HTTP and non-HTTP sites, you can be hosting a service that exposes itself over both HTTP and NET.TCP as well.
–Jason Olson
Technical Evangelist, Windows Server 2008 Developer & Platform Evangelism
|
Request Processing Pipeline
The modular architecture of IIS 7.0 is also important to the way in which requests are processed by IIS 7.0. By way of comparison, on the previous platform (IIS 6.0), you basically had a monolithic request-processing pipeline that could have its functionality extended through ISAPI. In IIS 7.0, however, you have all these different modules that can be plugged into your generic request pipeline to modify how requests are processed by your server. In addition, you have a public module API that you can use to extend your pipeline by adding your own custom modules.
Another way of comparing the new IIS 7.0 architecture with the old one in IIS 6.0 is by comparing how ASP.NET is integrated with IIS on these two platforms. In IIS 6.0, you basically have IIS and ASP.NET and never the twain shall meet-unless it happens via ISAPI. For example, suppose a request comes in that needs to be processed by ASP.NET. IIS hands it off to ASP.NET via the ISAPI extension aspnet_isapi.dll, which processes the request and returns it to IIS. This mechanism involves feature duplication and is not very efficient. By contrast, IIS 7.0 offers two modes of handling such requests. First, you can use the “classic” mode, where ASP.NET runs as ISAPI just like in IIS 6.0, which is useful for compatibility reasons. And second, you can use the new “integrated” mode, where ASP.NET and IIS are part of the same request-processing pipeline-that is, your .NET modules and handlers plug directly into the generic request-processing pipeline, which is much more efficient than the old model (and provides a far easier extensibility point to program to-ISAPI is so 90s).
Other Security Enhancements
If you thought IIS 6.0 was “secure by default” (and it was, to a large degree), you should take note of some other security enhancements included in IIS 7.0. For example, instead of the IUSR_computername local account that was used on previous IIS platforms to provide anonymous access to your server, IIS 7.0 now uses a new built-in anonymous user account for this purpose. To understand the significance of this change, let’s hear from one of our experts:
|
The IUSR_<servername> account in previous versions of IIS has always been a local account created when IIS was installed on the operating system (unless you install IIS on a domain controller, which is not recommended). Just short of “Internet User,” the name that IUSR is often called is anonymous user, and it’s the identity used to access content on Web sites configured to allow Anonymous authentication. This identity has worked very well to provide unauthenticated access on IIS, but because it is a local account, it has a password and security identity (SID) for NTFS permissions that are unique to the local server. As a result, certain operations involving replication of the configuration system or file permissions (such as restoring from backup or replication between servers in a Web farm) become challenging.
In IIS 7.0, an IUSR_<servername> local account has been replaced with the IUSR built-in account. The difference is quite significant. A built-in account cannot be used to log in to the server. In addition, the IUSR account has a well-known SID that is common between all editions of Windows Vista and Windows Server 2008 that have IIS 7.0 installed. If you configure a file to Deny Read for the IUSR account and then xcopy that file to another IIS 7.0 server with permissions, the Deny Read permission is still valid. This is one of the little gems that make a big difference in the life of administrators and security specialists, but it’s not as well known as other features of IIS 7.0.
–Brett Hill
IIS Technical Evangelist, Developer and Platform Evangelism
|
Another security enhancement in IIS 7.0 is built-in URL filtering, which prevents suspicious requests from being serviced by your server. Using the RequestFilteringModule module, you can specify allowed verbs and file extensions, set character limits, and scan for bad character sequences within a URL requested by a client. This means you no longer need to install URLScan as a separate add-on for IIS, as this functionality is now available out of the box. Let’s hear from another of our experts concerning this enhancement:
|
You don’t need URLScan in IIS 7.0. The core features of URLScan are now built into the new Request Filtering module of IIS. In addition to the core URLScan features, Request Filtering offers new functionality that enables you to deny access to certain segments within the URL.
Unfortunately, there is no user interface for Request Filtering. You have to edit the configuration files directly to use this feature. For more information on how to use Request Filtering, see “How To Use Request Filtering,” found at http://www.iis.net/default.aspx? tabid=2&subtabid=25&i=1040 on IIS.NET.
If you have a large library of expressions you want to block and you don’t want to add each of these expressions into the new configuration files, you might still want to use URLScan version 2.5 with IIS 7.0. You can do this, but the installer for URLScan version 2.5 does not work on Windows Vista or Windows Server 2008. To work around this issue, copy urlscan.dll and urlscan.ini to the Web Server running IIS 7.0 and then set up urlscan.dll as a global ISAPI filter in IIS.
–Tim Elhajj
Technical Writer
|
Another security enhancement is the ability to use .NET role and membership providers for authenticating users trying to access the server. You can also easily enable Forms authentication for any content on your server.
IIS 7.0 also includes an enhanced process model that automatically sandboxes applications on your server. For example, when you create a new Web site on your server, process isolation is enabled for this site by default. In other words, by default each new site you create is assigned to its own unique application pool (see Figure 11-1). By default, these application pools all run as Network Service, and each application pool also has its own separate, scoped configuration file that is created at run time.
Figure 11-1: Creating a new Web site also creates a new application pool by default
IIS 7.0 also includes a rich delegation infrastructure that lets server administrators create site and application administrators who can administer only designated sites and applications. In addition, you can configure which features of a Web site or Web application to delegate to these different levels of administrators without having to give them full control of the server.
Administration Tools
In addition to having minimized surface area, patching through a componentized architecture, and fully customizable installation options (wow, the Eiffel Tower!), IIS 7.0 also includes a raft of new feature-focused administration tools that can be used to efficiently manage Web servers, sites, and applications-including both IIS and ASP.NET configuration settings from the same place. Let’s look at these tools now-but it’s only a quick look, so have your cameras ready!
IIS Manager
IIS Manager has been totally revamped in IIS 7.0 to make it more intuitive for those using it. IIS Manager is also more task-oriented than in previous versions of IIS and the “property sheet purgatory” and “tab hell” of IIS 6.0 (actually, it wasn’t that bad) has been replaced with icons and a new context-sensitive MMC 3.0 Actions pane (which actually is a lot better!) as you can see in this figure:
Remember I told you previously that the Basic Authentication module is not installed in a default Web Server (IIS) role installation? Well, if you now select the icon for the Authentication feature (the first one in the IIS section of the Details pane in the preceding figure) and click Open Feature in the Actions pane, you get a list of authentication settings you can configure for your Web server:
Note that there’s no option available for configuring Basic authentication for your Web server. Why not? Because the binaries of that particular component aren’t even installed! In other words, the only configuration options you’re presented with are those supported by modules already installed on your server. That certainly makes administration a lot easier than the previous platform of IIS 6.0, where you had all those property sheets, tabs, and settings.
How can you make Basic Auth available for applications running on your server? Well, you just go back to Server Manager, right-click on the Web Server (IIS) role, and select Add Role Services to start the Add Role Services Wizard again. Then, in the wizard, you select the check box for Basic Auth and finish the wizard, and the component gets installed. Then, if you open the Authentication feature in IIS Manager, you get this:
Basic Auth is now installed. Of course, it’s also disabled by default and you have to enable it if you want to use it on your server. You might have to restart IIS Manager to make the new setting visible.
The configuration options (icons) you see in IIS Manager depend on the node you select in the console tree in the left pane. For example, if you select a Web site, you get options like these:
If you select any of the icons in the preceding figure, the center Details pane displays settings and might allow you to configure them, while the Action pane at the right gives you a quick way to perform common tasks relating to these settings. For example, if you open the Logging feature, the configuration settings look like this:
Obviously, we could spend a lot of time exploring all the different settings you can configure and tasks you can perform using IIS Manager, but we need to move on (look, the Coliseum!) and look at some other ways of administering IIS 7.0. But first a quick word from our sponsor-I mean tour guide-I mean expert:
|
You might want to configure a UI feature in IIS 7.0 that you don’t see in the UI.
There are several possible reasons for this situation. First, if you are running IIS 7.0 on Windows Vista, make sure that the feature you are trying to configure is available. Some features that are available for configuration in Windows Vista do not appear in the UI. You can configure supported features by using other methods-such as appcmd or WMI scripts-or by editing the configuration files directly.
Second, you might not have the feature installed on your Web server. If the feature is not installed, you will not see it in the UI.
Third, if you are running Windows Server 2008 and are connected to a site or an application, you will not see features in the UI unless they have been delegated to that site or application. Additionally, the ability to actually configure a feature that you see in the UI depends on whether the feature was delegated as Read Only or as Read/Write.
For information about IIS 7.0, including additional information about these issues, see http://www.iis.net.
–Reagan Templin
IIS Technical Writer
|
AppCmd.exe
Remember all the administration scripts that were included with IIS 6.0 so that you could administer it from the command line? These included iisweb.vbs, iisvdir.vbs, iiscnfg.vbs, iisback.vbs, iisext.vbs, and so on. They were a great way of administering IIS 6.0, but they could hardly be called an integrated solution to managing your Web server from the command line.
Well, in IIS 7.0 all those scripts have been done away with (though you can still write your own scripts using the WMI provider for IIS 7.0) and have been replaced by a single command-line tool. AppCmd.exe now gives you a single, unified command-line interface for managing virtually all aspects of your Web server, including sites, applications, application pools, worker processes, and so on. Here’s a quick look at the upper-level syntax of this command:
C:\Windows\System32\inetsrv>appcmd /? General purpose IIS command line administration tool.APPCMD (command) (object-type) <identifier> </parameter1:value1 ...> Supported object types: SITE Administration of virtual sites APP Administration of applications VDIR Administration of virtual directories APPPOOL Administration of application pools CONFIG Administration of general configuration sections WP Administration of worker processes REQUEST Administration of HTTP requests MODULE Administration of server modules BACKUP Administration of server configuration backups TRACE Working with failed request trace logs (To list commands supported by each object use /?, e.g. 'appcmd.exe site /?') General parameters: /? Display context-sensitive help message. /text<:value> Generate output in text format (default). /text:* shows all object properties in detail view. /text:<attr> shows the value of the specified attribute for each object. /xml Generate output in XML format. Use this to produce output that can be sent to another command running in /in mode. /in or - Read and operate on XML input from standard input. Use this to operate on input produced by another command running in /xml mode. /config<:*> Show configuration for displayed objects. /config:* also includes inherited configuration. /metadata Show configuration metadata when displaying configuration. /commit Set config path where configuration changes are saved. Can specify either a specific configuration path, "site", "app", or "url" to save to the appropriate portion of the path being edited by the command, or "apphost", "webroot", or "machine" for the corresponding configuration level. /debug Show debugging information for command execution.
Let’s use AppCmd.exe to view a list of Web sites on our server:
C:\Windows\System32\inetsrv>appcmd list site SITE "Default Web Site" (id:1,bindings:http/*:80:,state:Started)
There’s the Default Web Site running on the machine. Now let’s add another site and get it up and running:
C:\Windows\System32\inetsrv>appcmd add site /name:"Second Site" /id:2 /bindings:http://www.woodgrovebank.com:80 /serverAutoStart:true /physicalPath:C:\stuff SITE object "Second Site" added APP object "Second Site/" added VDIR object "Second Site/" added
Let’s see if it worked by checking for all running sites on the machine:
C:\Windows\System32\inetsrv>appcmd list sites /state:started SITE "Default Web Site" (id:1,bindings:http/*:80:,state:Started) SITE "Second Site" (id:2,bindings:http/*:80:www.woodgrovebank.com, state:Started)
And sure enough, if we refresh IIS Manager we can see the second site we just created:
And by the way, we all believe in recycling, don’t we? Think globally, act locally (or something like that-I’m a geek so I have tons of pizza cartons lying all over my office-I should recycle them someday). Well, if you’ve worked much with IIS 6.0, you know about using the iisreset command, which basically shuts down everything on your Web server and restarts it again (everything having to do with IIS that is). You wouldn’t use iisreset if you wanted to recycle an application pool in IIS 6.0, so if you wanted to recycle it from the command line you were out of luck. Well guess what-in IIS 7.0 you can do even this from the command line-but using AppCmd.exe of course. Let’s learn how:
|
When you use the iisreset command in IIS 7.0, the IIS Admin Service, the Windows Process Activation Service (WAS), and the World Wide Web Publishing Service (W3SVC) are stopped and restarted. You should avoid using iisreset unless absolutely necessary, because the Web server shuts down all applications that depend on these three services until the services successfully restart. This means that you lose the existing state in your applications, your sites and applications become unavailable, and you risk unpredictable results by stopping processes before they finish.
Instead, you can restart an individual site or recycle an application pool that is causing problems. To do this by using IIS Manager, follow these steps:
-
To restart an individual site, in the Connections pane, expand the Sites node. In the tree, click the site that you want to restart, and in the Actions pane, click Restart.
-
To recycle an application pool, in the Connections pane, click the Application Pools node. On the Application Pools page, select the application pool that you want to recycle, and in the Actions pane, click Recycle.
To do this by using appcmd, use the following commands:
-
To restart an individual site, type appcmd stop site "site_name", where site_name is the name of the site that you want to restart. Then type appcmd start site "site_name".
-
To recycle an application pool, type appcmd recycle apppool "apppool_name", where apppool_name is the name of the application pool that you want to recycle.
If you decide to use iisreset, you can include the /noforce parameter to prevent the services from being forcefully restarted if they cannot do so gracefully, and the /timeout parameter to specify a number of seconds to wait before the services are restarted. This can help prevent problems that can occur when processes are stopped before they finish.
–Reagan Templin
IIS Technical Writer
|
Windows PowerShell
Another great tool for managing IIS 7.0 is Windows PowerShell. A great primer on the capabilities of using PowerShell to administer IIS 7.0 is “An Introduction to Windows PowerShell and IIS 7.0,” which can be found on the IIS.NET site at http://www.iis.net/default.aspx? tabid=2&subtabid=25&i=1212&p=1. We can’t get into it any deeper here because the bus is running and the tour has to continue, but let’s hear a bit more first from another of our experts:
|
The Managed SDK for IIS can be used from PowerShell for quick command-line administration. This functionality is handy if you are more familiar with the SDK than with AppCmd.
First, create a script that loads all your IIS Managed SDK assemblies into PowerShell. For instance, create a script named load_iis.ps1 with the following code:
$inetsrvDir = (join-path -path $env:windir -childPath "\system32\inetsrv\") $asmPath = (join-path $inetsrvDir -childPath "Microsoft.*.dll") Get-ChildItem -Path $asmPath | ForEach-Object{ [System.Reflection.Assembly]::LoadFrom( (join-path -path $inetsrvDir -childPath $_.Name) )} Save this file, and execute it inside PowerShell by typing ./load_iis.ps1.
PowerShell will load the SDK assemblies from the GAC into the PowerShell environment. You can now use standard PowerShell syntax against the IIS SDK.
For example, if you wanted to list all the Web sites on your server, you could use the New-Object cmdlet in PowerShell to create an instance of the ServerManager class as follows:
PS C:\> (New-Object Microsoft.Web.Administration.ServerManager).Sites
This will list each of your Web sites and public members. You can also get a specific Web site by typing the following:
PS C:\> (New-Object Microsoft.Web.Administration.ServerManager).Sites["Default Web Site"];
If you take this concept a step further, you can stop Web sites by using the following code:
PS C:\> (New-Object Microsoft.Web.Administration.ServerManager).Sites["Default Web Site"].Stop();
As you use PowerShell more often, you’ll find yourself adding more global variables to your assembly load script. For instance, instead of creating a new ServerManager on each line, you might want to create a global variable called $iismgr that holds your ServerMan-ager instance. To add a global alias, put the following at the end of your load_iis.ps1 file:
$global:iismgr = (New-Object Microsoft.Web.Administration.ServerManager)
Once you have executed this script again, you can type commands like the following inside of PowerShell:
PS C:\>$iismgr.Sites.Add("MySite", "http", "*:80:", "c:\inetpub\wwwroot\mysite") PS C:\>$iismgr.ApplicationPools["DefaultAppPool"].Stop() PS C:\>$iismgr.WorkerProcesses As time goes on, you’ll find that PowerShell can be much more robust for administration than the default AppCmd.exe tool.
–Tobin Titus
Programming Writer, IIS SDK UE
|
Remote Management
Another way of managing IIS 7.0 is using remote management capability. Before you can do this, you need to run the Add Role Service Wizard for the Web Server (IIS) role in Server Manager, and select the Management Service subcomponent under Management Tools. Remote management provides a secure, firewall-friendly connection to IIS 7.0 over HTTP/SSL, and it can authenticate both Windows and non-Windows credentials.
For more information on enabling and using remote management with IIS 7.0, see the article “How to Enable Remote Administration for IIS Manager,” found on IIS.NET at http://www.iis.net/default.aspx?tabid=2&subtabid=25&i=966.
WMI Provider
Another great way of managing IIS 7.0 is using WMI scripts. But before you can do this, you need to install the new WMI Provider in IIS 7.0. And to do that, you run the Add Role Service Wizard again for the Web Server (IIS) role in Server Manager, and select the IIS Management Script And Tools subcomponent under Management Tools.
If you want to learn more about managing IIS 7.0 using WMI, a good introduction to the subject is the article “How to Manage Sites using WMI,” found on IIS.NET at http://www.iis.net/default.aspx?tabid=2&subtabid=25&i=961.
IIS 7.0 API
IIS 7.0 also includes Microsoft.Web.Administration, a new a management API that enables editing the XML configuration files for your Web server, sites, and applications. (We’ll talk more about configuration files in a moment.) The Microsoft.Web.Administration API also provides convenience objects you can use to manage your server and its properties and state.
Again, we don’t have time cover this in detail (the bus is running). You can find a great introductory tutorial called “How to Use Microsoft.Web.Administration” on IIS.NET at http://www.iis.net/default.aspx?tabid=2&subtabid=25&i=952, but we are blessed by having another of our experts tell us a bit more about this API:
|
What is new in IIS 7.0 administration? IIS 7.0 provides a comprehensive managed-code API that, among other things, allows for convenient access to server objects. IIS 7.0 includes Microsoft.Web.Administration, which is a new management API for the Web server that enables editing configuration through complete manipulation of the XML configuration files. It also provides convenience objects to manage the server, its properties, and state. The configuration editing aspect of the API provides programmatic access to read and write configuration properties in the IIS configuration file hierarchy and in specific configuration files. The object management aspect of this API provides a series of top-level administration objects for direct management of the server (for example, sites, application pools, worker processes, and so on).
The management classes reside in the Microsoft.Web.Administration namespace. The classes provide a weakly typed interface to access configuration sections and convenience objects with properties and methods representing attributes of the configuration (such as the path of a virtual directory) or actions to take on the object (such as recycling an application pool).
–Jason Olson
Technical Evangelist, Windows Server 2008 Developer & Platform Evangelism
|
Configuration and Deployment
The tour must go on (I wanna see the Matterhorn!), so let’s continue and talk briefly about IIS 7.0 configuration and deployment.
Remember the metabase? In IIS 6.0, it was a central, monolithic repository (formatted in XML) that stored pretty much all configuration settings for IIS (although a few were still stored in the registry). Well, in IIS 7.0 the metabase is gone, but that doesn’t mean all the scripts you’ve developed for managing IIS 6.0 via metabase modifications will no longer work. A feature called ABOMapper keeps those scripts working transparently in IIS 7.0. But the metabase is dead in the sense that there is no longer a single, centralized repository for all configuration settings on the Web server. Instead, it’s been replaced by a series of .config files of the kind ASP.NET developers will be familiar with.
So what are these different configuration files? Well, first there’s a file called applicationHost.config, which resides in the \System32\InetSrv\config directory. The applicationHost.config file is the main configuration file for IIS 7.0, and it contains configuration information concerning sites, applications, virtual directories, logging, and so on. The applicationHost.config file contains two main groups of settings:
-
system.applicationHost Includes settings for the activation service, such as the list of application pools, logging settings, listeners, and sites. These settings are centralized and can be specified only in applicationHost.config.
-
system.webServer Includes all other settings for the Web server, including the list of modules and ISAPI filters, ASP, CGI, and so on. These settings can be defined here or in any web.config file (if allowed).
Another configuration file is administration.config, which is stored in the same directory and contains things like delegation settings, the list of available modules, the list of administrators, and so on. Then, finally, you have web.config files, which can contain both Web server (or site) settings and ASP.NET settings for applications. These web.config files are generally found in the root directory of a site or application, but they can be located in virtual directories as well (IIS settings are necessarily tied directly to just the app, so they can also reside on vdirs).
Let’s take a look at a small snippet from the applicationHost.config file:
<security> <access sslFlags="None" /> <applicationDependencies /> <authentication> <anonymousAuthentication enabled="true" userName="IUSR" /> <basicAuthentication enabled="false" /> <clientCertificateMappingAuthentication /> <digestAuthentication /> <iisClientCertificateMappingAuthentication /> <windowsAuthentication /> </authentication>
Note that Basic authentication shows up here as disabled, just as it did in IIS Manager earlier. (Flip back a few pages, and you’ll see.) What happens if we open the applicationHost.config file in Notepad and edit it by changing “false” to “true” for the <basicAuthentication> element? Guess what-if you try this, save the file, and then open IIS Manager and open the Authentication feature, Basic authentication shows up as enabled:
So just like in IIS 6.0, where you could edit the XML metabase in real time, you can do the same with the configuration files here in IIS 7.0. But that’s not all. These XML configuration files support inheritance and also additive merging of settings. For example, the settings contained in the applicationHost.config file and in one or more web.config files will merge together to form the actual configuration settings for your site or application.
The fact that configuration settings for IIS 7.0 sites and application can live in different places, including the directories of the site or application itself, also means that distributing the configuration files like this allows you to deploy your sites and applications simply by copying their directory contents using the xcopy command. In other words, the configuration settings for your site live with your site content, so any method for copying files (xcopy, robocopy, FTP, or whatever) can now be used to deploy your site to an IIS machine.
This feature will be really welcome in large hosting environments that have racks of Web servers and thousands of customers, each having one or more Web sites. It’s also a terrific way of deploying preconfigured apps to a bunch of stateless front-end Web servers in a Web farm. This is especially true with xcopy because you can include ACLs that are globally unique- NetworkService, application pool identities, the built-in anonymous user account, and so on. And you can even use environment variables to abstract physical paths when you copy files from one server to another. Finally, you can even store your “master” web.config file on a central UNC share so that all your Web servers can share the same configuration file!
Let’s learn more about IIS 7.0 configuration from another of our experts:
|
One of the most interesting changes in IIS 7.0 is the refactored configuration system. IIS 6 had only one location for configuration settings, metabase.xml. To make changes to it, you needed to be an administrator on the server. Concentrating all the settings in a single store makes it easy for the IIS team to know where to place settings and how to read the configuration. It also makes it easy for administrators to know where to look for problems should they occur. However, it isn’t very flexible and doesn’t facilitate real-world needs like Web farm replication of settings or empowering server administrators to allow teams or developers to configure their own Web sites on intranet servers. In addition, ASP.NET and IIS 6.0 configuration systems are completely different designs, requiring multiple configuration technologies for a single Web server.
In IIS 7.0, Metabase.xml has been redesigned to become applicationHost.config. The structure of the new applicationHost.config is declared in the IISSchema.xml file, so if you’re curious about exactly what options are available for any particular setting, that’s the place to look.
The new configuration system provides new choices for how you architect your IIS 7.0 configuration:
-
Single Configuration File In this design, all your IIS 7.0 settings are stored in applicationHost.config. To do this, ensure that all IIS 7.0 settings in the IIS Manager, Feature Delegation are set to Read Only. When you make a change to a Web site or applications settings, the updated configuration will be applied using a <Location> tag inside applicationHost.config. Benefits to this design are obvious to administrators-total control!
Note The .NET configuration settings are stored in the root web.config file at microsoft.net\framework\<version>\config\web.config.
-
Delegated Configuration Configuration settings that are delegated will be written to web.config between the <system.webserver> entries. Some, but not many, settings are delegated by default. (Review the Feature Delegation page, and click Help for an explanation of what the various settings mean.) To configure a setting to be delegated, you set it to Read/Write. If you do this, understand that if you, the developer, overwrite the web.config with a new web.config, the delegated settings might be affected.
-
Shared Configuration This is a new capability of IIS 7.0 that allows you to set up all your IIS 7.0 servers so that they share a single applicationHost.config file. The shared configuration feature is designed to eliminate the need to replicate IIS configuration settings between servers in a Web farm. Specific technical details are posted on IIS.net. You can use this in conjunction with delegated configuration to allow sites or applications to control specific settings
My suggestion is that you take a good look at your Web server, application, and infrastructure design before you deploy IIS 7.0 and determine how to best leverage these new configuration capabilities.
–Brett Hill
IIS Technical Evangelist, Developer and Platform Evangelism
|
And here’s yet another of our experts to explain more about ways you can view and modify your configuration files and the steps you need to follow to do so:
|
Sometimes user accounts that are part of the Administrators group cannot view or edit server-level IIS 7.0 configuration files because they are denied access. In Windows Vista and Windows Server 2008, User Account Control (UAC) requires that all users run in standard user mode unless a task or application requires administrator privileges. The IIS 7.0 server-level configuration files, such as applicationHost.config, require administrator privileges for access. To edit server-level configuration files, you must first elevate your privileges when you open the application that you want to use to view and edit the configuration files.
To open a server-level configuration file, first determine the application that you want to use to view and edit the configuration file, such as Notepad, Microsoft Visual Web Developer Express, or Microsoft Visual Studio. When you open the application, right-click the .exe file and click Run As Administrator. You can then open the configuration file from inside the tool to view and edit configuration settings.
For example, to open applicationHost.config in Notepad with your administrator privileges, complete the following steps:
-
Click Start, click All Programs, and then click Accessories.
-
Right-click Notepad and click Run As Administrator.
-
In the User Account Control dialog box, click Continue to open Notepad using your elevated privileges.
-
In Notepad, click File, and then click Open.
-
Navigate to %windir%\system32\inetsrv\config, and double-click application-Host.config.
Note In the Open dialog box, make sure that you select All Files in the drop-down list to display all file types.
–Reagan Templin
IIS Technical Writer
|
Diagnostics
We haven’t been to that topless beach yet in Corfu, so we’ll continue racing ahead with our tour. (Actually, my wife would prefer we see the Louvre instead, so let’s forget about the beach.) Another area of enhancement in IIS 7.0 over previous versions is the detailed errors and automatic failure tracing that enables rapid troubleshooting and minimizes downtime. For example, you can view detailed errors in your Web browser, and there are plenty of new error codes that provide prescriptive guidance in various situations.
IIS log files also record more status codes that can help you troubleshoot various problems. For example, when a client’s request is denied with a 404 error, the list of sub-status codes shown in Table 11-2 is now supported. (The first three items were supported previously; all the rest are new.)
| Description | Sub-code |
|---|---|
| SITE_NOT_FOUND | 1 |
| DENIED_BY_POLICY | 2 |
| DENIED_BY_MIMEMAP | 3 |
| NO_HANDLER | 4 |
| URL_SEQUENCE_DENIED | 5 |
| VERB_DENIED | 6 |
| FILE_EXTENSION_DENIED | 7 |
| HIDDEN_NAMESPACE | 8 |
| FILE_ATTRIBUTE_HIDDEN | 9 |
| REQUEST_HEADER_TOO_LONG | 10 |
| URL_DOUBLE_ESCAPED | 11 |
| URL_HAS_HIGH_BIT_CHARS | 12 |
| CONTENT_LENGTH_TOO_LARGE | 13 |
| URL_TOO_LONG | 14 |
| QUERY_STRING_TOO_LONG | 15 |
New APIs also expose all runtime diagnostic information in real time, so by programmatically querying IIS, you can see all currently executing requests and other useful information.
Another diagnostic feature is the ability to define failure triggers by error code or time taken, which is configurable per application or per URL. The resulting Failed Request Tracing log contains a chronicle of events for the failed request, and this can quickly help you identify bottlenecks on your server. We’ll soon hear from one of our experts concerning Failed Request Tracing. First, let’s learn about the details behind failure request tracing trigger conditions:
|
Failure Request Tracing for IIS 7.0 can trigger failures on three key conditions: Status/Substatus codes, Time Taken, and Event Verbosity. One thing to remember is that the trigger overall is an OR of all the failure conditions defined. If you define all three-say, statusCodes=”400-599”, timeTaken=”00:00:10”, and verbosity=”Error”-the worker process flushes the trace log for the “failed” request upon reaching the first of those conditions. If your request eventually errors out with an http status code of 500, but it takes 30sec to do that, you’ll actually trigger on the timeTaken value. The attribute <failedRequest failureReason=”<reason>”> will tell you exactly what failure condition triggered the flush.
The events that make it into the trace log are those that are raised up to the point of the failure. What this means is that only Status/SubStatus code failure conditions (failureReason=”STATUS_CODE”) capture the entire request from start to end. For timeTaken triggers, you see all the events received up to the time limit. In the preceding example, a 10sec failure condition results in IIS capturing the events up to that 10-second limit, and no more. The same thing goes for verbosity triggers: when we receive the first event whose verbosity is equal to or more severe than the current trigger condition, we’ll flush all events received up to that point (including the trigger event). So let’s say your trigger condition wants to flush for foobar.aspx if verbosity=“WARNING”. Because verbosity levels are inclusive of the previous error levels, IIS will flush the log for foobar.aspx when it receives the FIRST trace event for a request to that URL whose verbosity level is WARNING, ERROR, or CRITICAL ERROR. If the failure condition verbosity level is ERROR, IIS will flush upon receiving the first ERROR or CRITICAL ERROR trace event.
The goal here is to give you a flexible means of defining failure conditions and flush when a certain condition is reached. Status Code and Time Taken are the most often used currently, but Verbosity is also helpful when you want to capture application failures that result in customized 200 OKs to the client that say, “Sorry, cannot connect to product database.” Slap an ERROR trace event in your code, and configure the verbosity failure condition to capture these logs to help diagnose these failures!
–Eric Deily
Senior Program Manager Lead-IIS 7.0, Developer Division
|
Next, what about your Failed Request Tracing log files? Where are they? Sometimes when you enable Failed Request Tracing, the log files don’t appear. Let’s learn why:
|
So you’ve configured Failed Request Tracing, but you cannot find your log files. Now I’ve got to troubleshoot my troubleshooting feature, eh? Let’s start with the basics:
-
Make sure that you’ve enabled Failed Request Tracing at the site level. Remember that although you can still define failure conditions and what to trace in your web.config files, you still need to have the IIS administrator enable Failed Request Tracing for your site. In the IIS Manager UI, click on the Web site in question, and under Actions select Configure. Then select Failed Request Tracing. This will bring up a dialog that allows you to select Enable Failed Request Tracing, as well as to set the directory to log to and the maximum number of files.
-
Make sure the worker process identity has FULL CONTROL access to the directory in question. You need to do this because the worker process writes out the log files under its own identity, creates the W3SVC# (where # is your site ID) directory, and finally deletes old files.
-
Check the Windows Logs | Application NT Event log for events from the Microsoft-Windows-IIS-W3SVC-WP source. The most typical errors will be permissions errors (as indicated above). Other possible errors include the following:
-
Bad Configuration-This event indicates which configuration is incorrect. This configuration needs to be fixed before that failure condition will be triggered.
-
FileSystem is full-We’re writing log files, and XML files at that. Make sure there’s space on the volume for writing the log. Though if you hit this error and it’s on the system drive, this is probably not the biggest of your worries.
This should help you figure out why you’re not getting failure request log files.
–Eric Deily
Senior Program Manager Lead-IIS 7.0, Developer Division
-
|
Finally, let’s dig a bit deeper into the different conditions that Failed Request Tracing can catch and those it can’t catch:
|
Failed Request Tracing is a powerful feature that will really help diagnose problems with Web applications. Unfortunately, there are a few conditions that Failure Request Tracing cannot help with. Those conditions include the following:
-
Worker process crashes One thing to remember about Failed Request Tracing is that it buffers the trace events for the requests it’s configured to track in process memory. So if that process suffers a failure that causes the process to terminate unexpectedly, the events buffered in that process will be lost.
-
Failures that happen before any request processing begins Failure Request Tracing reads the configuration and starts accepting trace events for requests on the Begin Request notification. However, a bit of work happens after the request arrives in the worker process but before this notification occurs. The things that happen to a request that could cause it to fail before Begin Request include the following events:
-
W3WP fails to load the configuration for the request
-
URL rewriting failures
If these failures happen, you will not get a failed request trace log. The best alternative for you here is to use ETW tracing or check the event log (the Application log again).
–Eric Deily
Senior Program Manager Lead-IIS 7.0, Developer Division
|
Extensibility
Your feet are probably tired by now, aren’t they? That’s what happens when you go on vacation and don’t take a good pair of shoes. You should know better than to try and walk 10 miles a day in flip-flops. Well, we’re almost there-only a couple more sites to see.
Let’s briefly (there’s the Mona Lisa!) talk about the extensibility of the IIS 7.0 platform. The core Web server in IIS 7.0 is built on public extensibility APIs, and as we’ve seen, it has a building-block architecture that allows you to add or remove features, including custom features you’ve developed. The IIS 7.0 team is excited about the possibilities here. They hope that an entire community of developers will mobilize to build custom modules that will extend the power of IIS 7.0-both as a Web server platform and as a more general application server platform-by adding new authentication/authorization schemes, better directory browsing, new logging capabilities, and just about anything you could conceive of doing with IIS 7.0. Plus you can develop your own modules using either native or managed code. The potential is almost limitless.
We just have time to hear from one more of our experts before we catch the bus to the airport.
|
IIS 7.0 takes ASP.NET to the next level by integrating the ASP.NET runtime extensibility model with the core server. This integration allows developers to fully extend the IIS server with the richness of ASP.NET 2.0 and the .NET Framework, instead of using the lower-level IIS C++ APIs. Existing ASP.NET applications also immediately benefit from tighter integration because they can now use existing ASP.NET features such as Forms Authentication, Roles, and Output Caching for all types of content.
Here are some great reasons to take advantage of ASP.NET integration with IIS 7.0:
-
ASP.NET services can be used for all content types In the past, ASP.NET functionality-such as Forms Authentication, Roles, URL Authorization, and Output Caching-were available only to ASP.NET content types (.aspx pages, for example). Static files, ASP pages, and other content types could not benefit from these services.
In IIS 7.0, however, all ASP.NET services can be uniformly provided to all content. For example, you can protect all your Web content, including images and ASP pages, with your existing ASP.NET 2.0 access control solution that uses ASP.NET Forms Authentication, Membership, and Login controls.
-
Fully extend IIS with ASP.NET Previous versions of IIS frequently required server extensibility to be developed using the native ISAPI filter or extension extensibility mode because of the runtime limitations of ASP.NET.
IIS 7.0 allows ASP.NET modules to plug directly into the server pipeline, with the same runtime fidelity as modules developed with the native (C++) server API. ASP.NET modules can execute in all runtime stages of the request-processing pipeline and can be executed in any order with respect to native modules. The ASP.NET API has also been expanded to allow more control over request processing than was previously possible.
-
Unified server runtime Tighter ASP.NET integration also allows many of the features between IIS and ASP.NET to be unified.
IIS 7.0 features unified configuration for IIS and ASP.NET modules and handlers. Many other features, including custom errors and tracing, have been unified to allow better management and cohesive application design.
–Claudia Lake
IIS Technical Writer
|
What’s New in IIS 7.0 in Windows Server 2008
Well, we’re in the plane now, and being way up in the sky enables us to see over the horizon. What’s on the horizon for IIS 7.0 in Windows Server 2008? Most of what we’ve discussed so far is already available in IIS 7.0 on Windows Vista (though you probably don’t want to run your corporate intranet off a Web server running Windows Vista). Here’s a quick overview of what is being enhanced in IIS 7.0 in Windows Server 2008.
Enhanced Application Pool Isolation
We demonstrated earlier that when you create a new site in IIS 7.0 and specify a name for that site, by default the site is assigned its own unique application pool having the same name as the site. A unique application pool SID and AppPool.config file are created as well, to ensure automatic identity isolation for each new application pool. That’s actually a feature of IIS 7.0 in Windows Server 2008-in Windows Vista, when you create a new site, the site is assigned to the DefaultAppPool instead. This particular enhancement will be useful in shared-hosting scenarios because sites and applications will be completely isolated from each other for greater security and stability.
Centralized Web Farm Configuration
We also mentioned earlier about storing your configuration files on a central UNC share. Well, IIS 7.0 in Windows Server 2008 lets you share all your .config files this way, including the applicationHost.config file, whose location can be configured by editing the registry on your Web server. (In IIS 6.0 you could put your web.config files on a UNC share, but IIS 7.0 also lets you put your applicationHost.config on the share, and this is configured using a redirection.config file in the inetsrv\config directory.) That’s a pretty cool enhancement, and it will be greatly appreciated for Web-farm scenarios, as it will make management of a Web farm a lot easier!
Delegated Remote Administration
Another feature of IIS 7.0 that will be available in Windows Server 2008 is the ability to enable remote management for both Administrators and Delegated Site Owners. Firewall-friendly remote management using HTTP/SSL and authenticating both Windows and non-Windows credentials are also new in Windows Server 2008, as is support for auto-deployment of new Administration features from server to client. What this means is that if you add new management capabilities to the UI (since it’s extensible), those new capabilities will be downloaded to the remote administration tool. (Note that this tool is an out-of-band release to allow Windows XP users to manage their IIS 7.0 servers also.) This feature allows IIS 7.0 to be implemented in a self-service config scenario, where your machine admin might be remotely managing the server from inside your company firewall while a remote site admin manages a scoped-out configuration for a single site on the server from a location outside your firewall.
FastCGI Support for PHP and Other Languages
Another new feature of IIS 7.0 in Windows Server 2008 is built-in support for FastCGI applications. CGI was the first Web application paradigm and was popular in the ’90s on UNIX platforms, but it suffered from a lot of overhead that made it impractical in many situations. In Windows Server 2008, however, FastCGI is optimized for high performance and reliability and can reuse CGI processes for servicing multiple requests. The result is that FastCGI is something like 25 times faster than regular CGI, making FastCGI a viable way of hosting Web applications on IIS. So this means you can now run PHP apps, Perl scripts, and Ruby applications on IIS-with a level of performance and stability that previously was available only for ISAPI applications. Clearly, this is another great driver for hosting companies to upgrade or migrate their Web servers to IIS 7.0.
Modern FTP Server with FTP/SSL
A much-requested feature has finally arrived (well, almost-see end of paragraph) in IIS 7.0 on Windows Server 2008-a secure FTP server that supports FTP over SSL. The new FTP server being developed for Windows Server 2008 will have a modern code base that supports UTF8 throughout and includes full IPv6 support, COM and .NET extensibility, and .NET membership integration with SQL Server and other repositories. This new FTP server makes IIS 7.0, with its XML configuration files, into a fully integrated Web publishing system-secure Web publishing at last! Well, in point of fact this particular feature doesn’t ship in-box but instead will ship out-of-band at the same time Windows Server 2008 RTM’s.
Advanced Schema Extensibility
Finally, IIS 7.0 in Windows Server 2008 will have a single XML schema for both config and dynamic data, and it will support the plugging in of new or merged configuration sections, dynamic properties, and methods.
A few other improvements are also coming, but we’ll move forward to the last part of our trip, which is the airport in my home town of Winnipeg. Just don’t visit Winnipeg in the middle of winter, unless you enjoy freezing your nose off.
The Application Server Role
We need to finish by talking briefly about the Application Server role, one of the many roles you can install on Windows Server 2008 using Server Manager.
So what is it?
You can think of the Application Server role as a kind of superset of IIS functionality. For example, say you’re a customer who wants to serve Web content and you want an HTTP engine to do this. It doesn’t matter whether you’re a corporate customer, a hoster, or whatever-you just need an engine to pump out HTTP. Clearly IIS 7.0 can do that, but the Application Server role on Windows Server 2008 can do even more.
For instance, what if you want to host a Web service implemented using Windows Communication Foundation instead of a Web site or Web application? Web services (that is, WCF apps) are basically services that listen on HTTP, TCP, named pipes, or whatever for clients to make requests from them. For example, say you’ve got a WCF app that is listening for requests. A request comes in, and the app does some stuff in response-maybe it accesses a database, does some computations, generates some graphics, kicks off a workflow, or whatever. It just does something in response to the request. But it has no visible Web page that a user can see-it just listens like a service, hiding beneath the surface (the UI) of the system.
Or maybe your Web service isn’t based on a request/response model at all. Maybe it just uses a scheduler to kick off a batch job at various times of the day, perhaps to perform some computations in a database or generate a report.
The point is, these apps are running on IIS 7.0, so you’ve got all the same management tasks to perform: configuring your application pools, delegating administration, monitoring worker process activity, and so on. In fact, you can (but don’t need to) use the same tools-such as IIS Manager and AppCmd.exe-to manage your Web service as you would to manage a Web site or Web application.
So how do you turn your Windows Server 2008 machine into an Application Server? You install the Application Server role, which also requires you to install the .NET Framework 3.0 on your machine. The .NET Framework 3.0 is built on top of the earlier .NET Framework 2.0 and includes the following components:
-
Windows CardSpace Formerly code-named “InfoCard,” this component provides the consistent user experience required by the identity metasystem. It’s hardened against tampering and spoofing to protect the end user’s digital identities and maintain end-user control.
-
Windows Communication Foundation Formerly code-named “Indigo,” this component is a set of .NET technologies for building and running connected systems. It provides a communications infrastructure built around the Web services model.
-
Windows Presentation Foundation Formerly code-named “Avalon,” this component provides a foundation for building Windows Server 2008 applications and experiences. It also lets you blend together the application UI, documents, and media content.
-
Windows Workflow Foundation Formerly named “WinFX,” this is the programming model, engine, and tools for building workflow-enabled applications. It consists of a.NET namespace, an in-process workflow engine, and designers for Visual Studio 2005.
So all this gets installed when you add the Application Server role, and you also get a choice of which role services and subcomponents you want to install:
Unfortunately, we can’t go any deeper into this role right now because our plane is landing and we have to extinguish all cigarettes (shhh!) and fasten our seatbelts again. But we’ll close with our Captain speaking (one of our experts, actually), who will say a few words about managing Application Servers using PowerShell. Listen up, everybody-the Captain is speaking:
|
Microsoft Windows PowerShell provides a command-line shell and scripting language that helps IT Professionals achieve greater productivity. With a new administrator-focused scripting language, more than 130 standard command-line tools, and consistent syntax and utilities, Windows PowerShell allows IT Professionals to more easily perform and automate system administration tasks. To gain some additional background on PowerShell, see the PowerShell page at http://www.microsoft.com/windowsserver2003/technologies/management/powershell/default.mspx .
Windows PowerShell 1.0 was introduced in November 2006 as a downloadable tool, suitable for use on Windows XP, Windows Vista, and Windows Server 2003. It also runs on Windows Server 2008.
For the administrator who is responsible for managing Windows Server 2008 servers in a distributed environment, PowerShell is a multitool: it can be applied in numerous ways to perform many different tasks. PowerShell will work with Windows Server 2008 servers in various workloads, but it particularly applies to Application Servers, which are typically managed in sets and need to have similar configurations, with semi-regular changes and updates.
For example, consider the task of verifying the Service Pack level or the network configuration of each machine under management. These are the kinds of things that might be mandated by an IT policy. An administrator needs an efficient and automatic way to query each machine and generate a quick and dirty report, periodically. This is an ideal job for a PowerShell script. Or consider the job of verifying the signatures on various application artifacts deployed to all members of a farm of servers.
Of course, a script running under the Windows Scripting Host can do these things, too. What makes PowerShell better for these tasks? PowerShell supports better handling of the query output, and includes sorting, filtering, reformatting (for example, to generate a .csv file suitable for import into an Excel spreadsheet), and pipelines for postprocessing of the data. Combined with a visualization toolkit such as PowerGadgets (which is described in detail at http://www.powergadgets.com) or Microsoft Excel charting, PowerShell can be a real boon to administrators of application server farms.
–Dino Chiesa
Director in the Application Platform Marketing organization at Microsoft
|
EAN: 2147483647
Pages: 138