People inside and outside Microsoft often call the new IIS 7.0 web server one of Microsoft's most important development tasks in the past few years. This comment is important considering Microsoft has recently launched a series of notable technologies, including Windows Vista!
The release time of IIS 7.0 is exactly Windows NTThe tenth anniversary of the first IIS version in 4.0. In 2001, after four versions, IIS 5.0 became the most popular Web server on the Internet, although it became the notorious code red and nimhei worm attack object in a few months. IIS 6.0 is on Windows ServerReleased in 2003, it has made significant changes to the server, focusing entirely on improving security, reliability, and performance. Since then, IIS 6.0 has proved to be a rock-solid Web server. Since its release, it has gained high reliability and security records, and has only one key Security Bulletin (not remotely available ).
In this article, I will take this opportunity to introduce to developers and administrators the main reason why the next generation of IIS 7.0 web server has such a big difference, it also gives you a good start when using many of its new features.
The vision of IIS 7.0 is to inherit the speed, reliability, and security of the Basic Code of IIS 6.0, and develop it into a highly scalable and manageable web server platform, powerful functions to run Web applications in the future. Eventually becoming the most promising Microsoft Web server and bringing the greatest architectural improvements in IIS history.
The core of IIS 7.0 is a fully modular web server, which consists of more than 40 functions. These functions can be combined into a small Web Server optimized for the roles required in the application topology. These features are based on a new extensible layer that allows developers to use local code or Microsoft. NET Framework to extend or replace almost any aspect of the server. IIS 7.0 provides scalability for the entire Runtime Library, management, and operation functions to help you build end-to-end solutions for specific needs. On the basis of the core platform, IIS 7.0 solves many problems related to server manageability and operations. It adopts a completely new configuration system that can fully delegate site management, and finally make xcopy deployment of Web applications a reality. The new management API and diagnostic functions make server deployment, management, and troubleshooting easier and more convenient than before.
But before the next Windows Server version (codenamed "Longhorn") is about to be released, why should we consider the IIS server application? It is important to consider using it Because Windows Vista will come with the same full-featured IIS 7.0 programs that are expected to be released in Windows Server longhorn. This means that you can immediately use the new IIS 7.0 feature to build your personal website and host it on Windows Vista. In addition, when Windows Server "Longhorn" is released, you will deploy the production Web application and web server infrastructure to the same IIS platform, you can start developing and testing them first.
Are you interested? Let's discuss the details in depth.
Modular Web Server
IIS 7.0 divides Web servers into a lightweight server core and can insert more than 40 functional modules into the core. These modules (such as staticfilemodule that allows downloading static Web content, or windowsauthmodule that supports integrated NTLM authentication) can be separately installed on the server to provide the specific functions you need.
These modules can be fully detached from the server at any time (see figure 1), or they are specifically disabled for specific applications that do not require them. This will help server administrators quickly deploy small servers, greatly reduce the possibility of attacks, and greatly improve performance by executing only the required code.
Figure 1 only use the required features (click the image to get a smaller view)
Figure 1 only use the required features (click the image to get a larger view)
Componentized architecture is a key attribute of IIS 7.0. It can reduce security risks and minimize the need to install patches. It also supports specialized server deployment. This deployment can combine the IIS feature and custom components to optimize specific server roles in the application topology. For example, reverse proxy and cache server, HTTP Server Load balancer, or SSL and secure sentinel server.
All server functions attached to IIS 7.0 are based on the new public extensible API. As a developer, you can use your own functions to replace any existing server functions, or you can build new modules to add them to the IIS 7.0 feature set. Do you want to replace the built-in authentication mechanism with a custom authentication module or provide a new form of response compression? Continue.
The new extensible API is a fundamental improvement to the previous ISAPI extensible model, allowing you to more flexibly and easily enhance servers. Almost every aspect of the server (from the core server to configuration, management, and diagnosis) provides scalability, allowing you to expand and cut servers as needed. This article will provide more information about scalability later.
Simplified deployment and Configuration
The centralized configuration storage (which is affectionately called metadatabase) used in earlier versions of IIS is gone forever. IIS 7.0 has a new delegate configuration system based on the hierarchical structure of distributed xml configuration files. This hierarchy consists of the global applicationhost. config file (which includes the default server-level configuration settings) and the distributed Web. config file in the application directory structure. These files are the same as the Web. config file used by the ASP. NET application framework to store application settings in a portable manner. Therefore, you can use clean and powerful structured XML commands to store IIS and ASP. NET configurations side by side. The following is an example:
<?xml version="1.0" encoding="UTF-8"?><configuration><system.web><customErrors mode="Off" /></system.web><system.webServer><directoryBrowse enabled="true" /></system.webServer></configuration>
In the past, the IIS application settings must be explicitly configured in the machine-level Metadata inventory library before the application can work properly. With the distributed Web. config file, the application encapsulates the necessary server configurations in its directory structure. This greatly simplifies the deployment, so that independent applications can be directly copied to the application directory of the target server, so as to start and run immediately as needed.
The new configuration system also provides server administrators with full control, allowing them to delegate certain configuration options to applications, while maintaining control over other options for security or business reasons. In this way, the application on the hosting server can directly set the required configuration in its application, without turning to the server administrator or using the external configuration panel.
In IIS 7.0, the configuration system is fully scalable. New modules can add their own configuration architecture so that applications can configure their functions side by side with IIS and ASP. NET configurations:
<configuration><system.webServer><directoryBrowse enabled="true" /></system.webServer><myBandwidthThrottler enabled="true" /></configuration>
The custom configuration section uses the same configuration architecture as the configuration of the IIS 7.0 function, so as to take advantage of powerful type attribute values, set syntax and hierarchical rewriting and lock semantics.
IIS 7.0 continues to support the use of existing installation code to write data to the original metadatabase using the management basic object (ABO) API, or to use more advanced Active DirectoryConfigure IIS in the script of the Service Interface (ADSI) and Windows Management Instrumentation (Wmi) object. It supports this by providing the compatibility layer for simulating the Abo API (all other original configuration APIs are based on this compatibility layer ), this allows the above script to read and change the configuration just like in earlier versions of IIS. (For more information about metadatabase compatibility, see "improved performance" and "backward compatibility" at the end of this Article .) Although the new structured XML configuration format makes it easier for you to process configurations in your favorite text editor, IIS provides administrators with many management tools and APIs to simplify server management, and supports automatic configuration and deployment.
IIS 7.0 provides a rich set of management functions, allowing you to manage servers in a wide range of solutions. The new graphical IIS manager management tool replaces the inetmgr.exe MMC management unit and makes manual server management very simple (see figure 2) through its Task-Based Management Interface ).
Figure 2 IIS manager provides a graphical management tool (click the image to get a small view)
Figure 2 IIS manager provides a graphical management tool (click the image to get a large view)
IIS Manager allows you to manage most IIS 7.0 features and monitor server operations. This tool supports remote management through firewall-friendly HTTP/SSL connections, and supports both Windows-based creden。 and other creden。 for authentication.
In addition, the tool supports delegate management so that application owners can remotely manage their applications without having to have administrative access to server computers. With this feature, managed service users can run management tools on their home desktops and remotely connect to manage their applications on managed servers. Of course, the server administrator has full control over which management functions can be delegated to the application owner.
Finally, the management tool is fully scalable. It allows you to add custom management UIS to the tool based on the scalability of the Configuration System. In iis.net/default.aspx? In Tabid = 7 & subtabid = 73, you can learn more about the IIS manager tool and how to add your own management plug-ins.
To achieve more flexible command line management, IIS 7.0 provides the appcmd.exe command line tool (see figure 3 ). This tool provides a set of comprehensive management functions and better batch operation support than the UI. With this powerful utility, you can easily read and write configuration, access site and application pool status information from a command prompt, and execute almost any other management tasks.
Figure 3 IIS 7.0 appcmd.exe command line management (click the image to get a small view)
Figure 3 IIS 7.0 appcmd.exe command line management (click the image to get a large view)
Appcmd.exe allows you to create and configure sites, applications, application pools, and virtual directories. It enables you to start and stop sites, recycle application pools, list running processes, check ongoing requests, and search for failed event request buffering (Freb) trace logs. You can also search, edit, export, and import IIS and ASP. NET configuration data.
This tool allows you to flexibly search for supported server objects. For example, it allows you to quickly find sites with specific settings or stopped application pools. When performing a search, you can use any number of conditions for any object attribute, including matching with a simple wildcard string using a number range.
Appcmd also supports link operations similar to those in Windows powershell, allowing you to perform multiple operations on a group of related objects from a single command line. For example, you can use a command to find and recycle all application pools that host applications of a site. To learn how to use appcmd to manage IIS, see iis.net/default.aspx? Tabid = 2 & subtabid = 25 & I = 954 & P = 1.
. NET Framework and scripts
In addition to using the IIS manager or appcmd.exe command line tool for manual Server Management, IIS 7.0 also provides rich options for programming management. First, you can use the Microsoft. Web. Administration API to manage servers through. NET applications. You can also use the new com api to directly manage the IIS configuration system, orAccess a script environment such as Script Host (wsh. There are also new WMI providers and support for the original WMI and ADSI providers through the metabase compatibility layer.
Microsoft. web. administration is new. net management API, which allows hosted code applications to easily set IIS sites and applications, access important status and diagnostic information, and configure servers in other ways. By enabling.. NET Framework applications can easily access IIS configuration and status information. net installation and management of applications, or even directly from ASP.. NET page.
As an example, figure 4 shows a small C # program that uses Microsoft. Web. Administration to create a website from the command line.
Microsoft. Web. Administration enables IIS operations and configuration tasks to be easily completed directly within the application that supports the. NET language you select. It also allows you to easily access the running database status information about the server, such as running processes or ongoing requests.
Microsoft. Web. Administration API is the basis for accessing custom configurations in the custom. NET Server Module and the UI plug-in of the IIS manager tool. For examples of end-to-end server packages, including image copyright handlers used to enhance web servers and related configuration and management components, see iis.net/default.aspx? Tabid = 2 & subtabid = 25 & I = 1076.
Within the Windows Server "Longhorn" time range, the IIS team will create a unified extensible model to add custom management objects or expand existing management objects, these models enable custom management functions through different management functions (including scripts and Microsoft. web. administration API) is automatically published. When you cannot add or expand management objects in Windows Vista, you can use Microsoft. Web. Administration and other APIs to access and manage custom configurations just like the existing IIS configuration section.
Build Web Server Functions
IIS 7.0 allows you to create Servers Based on your needs and allows you to add or replace any functions on the servers to provide the functions you need. The core of this function is the new web server scalable API. All existing IIS 7.0 HTTP functions are built on it. This API is public, which means that you can implement any features attached to IIS 7.0. This is the first time for IIS and is a fundamental improvement to the extended model of the previous limited ISAPI.
The new extensible API is a set of intuitive C ++ classes that define the Web Server Object Model and enable a module to provide request processing services on IIS. These classes are defined in the \ Inc \ httpserv. h header file in the Windows Vista SDK.
Compared with isapis, these APIs are more powerful, and their ease of use is greatly enhanced. How is this implemented? First, the new API has a type-safe, well-encapsulated object model. With the new server object model, you can develop it more easily. This model provides specialized interfaces for all basic server objects and tasks. Including:
- Use the ihttprequest class to check requests
- Use the ihttpresponse class to manage responses
- Use useful utility functions from the ihttpserver class
- Provide authentication using the ihttpuser class
- Use the configuration API to access the custom configuration of your module
These classes expose more server features than previously (more than all features required to build IIS), but are still easier to use than loose typed ISAPI interfaces.
Developers will also benefit from improved memory and status management modes. Most IIS 7.0 server APIs use server-hosted memory to store the data they return, rather than ISAPI and most existing Win32The API requires you to allocate and manage the buffer. In the past, this has always been the easiest and most annoying aspect of ISAPI development. The new API also simplifies many complex request processing tasks, such as response buffering, authentication, and preparing response data for the client. A few months ago, I began posting a series of my blog articles to explain major improvements and patterns in the new programming model. If you are considering C ++ development for IIS, visit the following website to refer to the relevant content.
IIS 7.0 also provides fully integrated. NET framework APIs for the extension server. In addition, this is the same as the API provided by ASP. NET for building ASP. NET modules and processing programs since ASP. NET 2000 was released on Windows 1.0. But there is a difference between the two, people are familiar with ASP. net model allows existing ASP. the net module and processing program continue to work on the IIS 7.0 server, but in fact it is completely different from the old technology.
In IIS 7.0, ASP. NET has two versions: Classic mode and integration mode. The classic mode works in exactly the same way as in earlier versions of IIS. The integration mode is the default setting for the new platform. It uses a brand new engine to provide unprecedented integration with IIS web servers. In integration mode, Asp.. Net API to develop the IIS 7.0 module. This module can be directly integrated with the Web server and provide almost all services that can be implemented using basic C ++ APIs.
This is basically the best combination of two aspects: Member identities and role management. net Framework and ASP. NET 2.0 application services have familiar interfaces and conveniences, as well as the original capabilities of extended servers that were previously only available for C-based ISAPI components.
In addition to writing new ASP. in addition to the net module (built on the specific advantages of the integration mode), you only need. you can modify a small number of configuration options in the config file to make a lot of original ASP. net module becomes more powerful.
ASP. NET Integration
Using IIS 7.0 and ASP. NET 2.0 is not only an excellent framework for creating dynamic applications. It also becomes a platform for expanding IIS web servers, making ASP. NET components a complete Member of the IIS request processing pipeline. The following describes how it works.
In IIS versions up to 6.0, ASP. NET is connected to the Web server as an independent application framework. It is responsible for processing request extensions registered with it (usually. aspx and a small number of other extensions), and it also provides powerful features for these requests, such as form authentication, response output cache, and other features, including by custom ASP.. Net module. Therefore, only content types registered with ASP. NET can benefit from these services. Other types, including ASP pages, PHP pages, images, and CGI applications, cannot benefit. In addition, due to Runtime Library restrictions, some Web server functions cannot be implemented in ASP. NET even for ASP. NET Resources. For example, it cannot check the outgoing HTTP Response Header set and modify them before sending them to the client.
When the ASP. NET module runs in integrated mode in IIS 7.0, it runs side by side with the local C ++ IIS module in the unified request processing pipeline (see figure 5 ). This means that existing ASP. NET services (such as output caching, URL rewriting, and any other services provided by the custom ASP. NET module) can now be applied to any content type. Better integration of running libraries also enables the ASP. NET module to access previously unavailable server functions. In this way, the native IIS scalability is no longer required in most cases.
Figure 5 integration with ASP. NET in IIS 6.0 and IIS 7.0 (click the image to get a small view)
Figure 5 integration with ASP. NET in IIS 6.0 and IIS 7.0 (click the image to get a large view)
Finally, ASP. NET provides a small number of new APIs in the integration mode to publish other functions available due to tight integration with IIS. This includes the ability to check all response headers (no matter who generates the response) and to completely rewrite the request execution operation to another URL.
In general, existing applications can use the integration mode, instead of using the new ASP. NET module with functions specific to the integration mode. By changing the configuration, the application can perform the following operations: use ASP.. Net form authentication and URL Authorization protect the entire website through the user security mechanism, or use ASP.. Net URL ing. To view examples that prevent web leech from hot link to site images in integrated mode, see the sample ASP. NET module: mvolo.com/2006/11/10/stopping-hotlinking-with-iis-and-aspnet.aspx. This example demonstrates how to better utilize existing third-party ASP. NET modules in the integration mode.
To view the detailed steps for using the existing application integration mode, see my article: iis.net/default.aspx? Tabid = 2 & subtabid = 25 & I = 1081 & P = 1.
IIS 7.0 is built on the Basic Code of IIS 6.0. Due to careful coding practices and default security design principles, these codes have proven to be secure. On this basis, IIS 7.0 introduces several architectural changes to provide enhanced security and a large number of features to help you build secure Web applications.
Reducing the possibility of attacks is one of the basic principles for designing and deploying security systems. By default, the default locking method of IIS 6.0 is developed to the next level. By default, IIS 7.0 has fewer features, so that more servers can be locked. By further using the modular nature of the server to delete all useless functions, You can minimize the possibility of server attacks, thus greatly reducing the risk of server attacks.
If a vulnerability is found in any unused components on the server, you do not need to immediately stop the server from working to prevent attacks or repair the vulnerability components. This improves application availability and reduces the management cost of patches.
In addition to core security improvements, IIS 7.0 also provides a large number of security features that can be used to further lock and deploy security applications on servers. IIS has been providing powerful support for protecting application content through authentication. Now, use ASP. net integration mode, you can use the popular ASP.. Net security features (such as form authentication, membership identity, and logon Control) to provide a complete authentication and access control solution for the entire application. Generally, you can complete this setting within several minutes without writing any code.
The new URL Authorization feature evolved from the ASP. Net URL Authorization feature and can be used to configure declarative access control rules for the entire application. These access rules allow or deny access to the URL in the application based on the user name and role. URL Authorization and ASP.. NET 2.0 member identities and role management functions can be seamlessly integrated with ASP.. Net form authentication and logon control are used together to quickly enable the application's user security mechanism.
The new request filtering feature provides powerful locking functions, which are available in popular URLScan tools. By rejecting requests containing suspicious data, protecting sensitive resources, or imposing attack request restrictions, you can use the request filtering function to further lock the site.
IIS 7.0 has also undergone a large number of changes to make it easier to deploy and manage security settings. The new iis_iusr anonymous account is built in, which means it is not affected by password expiration and does not require password synchronization between computers. The new iis_iusrs group replaces the iis_wpg group and is automatically injected into the workflow ID during runtime. This relieves the need to manually add a workflow ID to the group when using a custom account.
The built-in iis_usr account and iis_usrs group are used to specify an access control list (ACL) for anonymous IIS accounts and groups) the application content can be directly copied from one IIS server to another, without any additional steps to keep the security settings. This greatly simplifies the application deployment process across the development-test-production cycle.
The distributed configuration system discussed earlier allows the application owner to directly manage the required web server settings in the application, without having to have administrator permissions on the server. When uploading an application to a server, the application administrator can. specify the required configuration in the config file, or use the IIS manager tool to remotely configure its application.
IIS manager provides secure remote management through firewall-friendly HTTPS connections. Because the management tool can use the membership service to verify the identity of the application Administrator (either a Windows user or a Custom User Account), the management tool allows remote application management, the owner does not need to have any windows permissions on the server.
As a server administrator, by configuring flexible lock support in the system, you have full control over the settings that can be configured by the application. Likewise, you can control which IIS manager tools can be used by application administrators who remotely manage their applications.
Among all the new features supported by windows, IIS 7.0, and Web applications, Web servers are very complex systems that usually require a lot of effort for troubleshooting. IIS 7.0 introduces a large number of new features to help you monitor server running conditions and debug application problems.
First, IIS 7.0 allows you to view the real-time status of the server in depth. This function is called the runtime database status and control API, or rsca (read as "reeska"). It can publish the active status of the site and application pool, and the running worker process, you can even view the requests currently being executed on the server. It also allows you to control the status of the server, such as starting and stopping the site, or revoking the application pool. In Windows Vista, you can access this information programmatically by using the appcmd.exe command line tool in IIS manager or Microsoft. Web. Administration API.
For example, you can view the currently executed requests and their server stages. This allows you to quickly fix pending requests and track which scripts are consuming CPU (see figure 6 ).
Rsca is very easy to use when investigating server problems or adjusting server performance. It can be used to quickly view the situation in the system and control the server during troubleshooting. When investigating a bug in the office, I usually choose to use appcmd.exe to view the status of the application pool, check the working process, start or stop the harmful application pool, to locate the problem.
Figure 6 track blocked scripts in IIS Manager (click the image to get a small view)
Figure 6 track blocked scripts in IIS Manager (click the image to get a large view)
Errors in Web applications may be caused by incorrect server configurations, application errors, or various environmental factors. Status Codes and standard error messages provide few error clues, which may cause server troubleshooting to be a nightmare. IIS 7.0 provides detailed error information about most errors, so that you can know the root cause and cause of the error and how to fix it (see figure 7 ).
Figure 7 Error details indicate the problem and solution (click the image to get a small view)
Figure 7 Error details indicate the problem and solution (click the image to get a larger view)
Detailed errors follow a security solution similar to ASP. NET detailed errors. By default, you can obtain detailed information only when browsing a website from a local computer. As before, you can configure custom error pages for different error codes or redirect to custom URLs. The detailed error page is now also localized. If you have installed a Language Pack for the corresponding language, you can provide the error description in the preferred language of the client.
Diagnose errors without debugging
What if you encounter an unknown error or a complex superposition of multiple web server components? No worries. IIS 7.0 provides a comprehensive tracking mechanism that generates detailed written tracing records for each request to quickly track problems.
Windows Server 2003 Service Pack 1 (SP1) adds Windows event tracking (ETW) events to IIS 6.0. Based on this event, IIS 7.0 adds more information events. These events contain useful information about each stage of server processing. By checking this information, you can trace the request execution process in reverse order to locate the error location. These events can be routed to the Windows tracking infrastructure, which allows multiple Windows components (including ASP. NET and SQL Server) to link their tracing information to a single logic execution trace of the request.
You can also route them to the new failed request tracking function (also known as Freb), which saves the tracing logs to the XML log file, you can then use the provided XSLT style sheet to view these files (see figure 8) or use them programmatically.
Figure 8 view the XML log file (click the image to get a smaller view)
Figure 8 view the XML log file (click the image to get a large view)
The coolest thing about the failed request tracking feature is that you can keep it enabled on the server. It can be used to automatically capture trace logs for requests that encounter configurable fault conditions, and to avoid performance degradation caused by storing trace logs for successfully completed requests. For example, you can open a request that causes a server error or that has completed more than a specific time.
Failed request tracing can always capture valuable tracing information when an error occurs, even if they are intermittent or hard to reproduce. This can help diagnose and solve difficult debugging problems.
The basic tracing infrastructure is exposed to the IIS module through the server scalable model, allowing all server components (whether they are included in IIS or developed by a third party) sends detailed tracing information during request processing. Through the system. Diagnostics API and ASP. NET page tracking, the IIS 7.0 tracking function is integrated with the ASP. NET tracking function, allowing the hosting module to use the unified tracking model. To proceed further, you can write your own tracking module to provide a new way to process and output tracking information. For example, you can write a module to save IIS tracking information to SQL Server or the first person in a text file.
Although Windows Vista is a client operating system and is not deployed for High-throughput production (IIS on Windows Vista is limited by 10 concurrent requests each time ), however, it does reflect some important architecture improvements designed to significantly improve the performance of Web applications. These improvements will help IIS 7.0 improve server performance by combining a wide range of performance improvements that we are doing within the Windows Server "Longhorn" time range.
Of course, the first improvement is componentization. The modular nature of servers allows administrators to delete unwanted server functions, saving memory and CPU usage during request processing. This will lead to significant improvements in computer throughput and capacity. Enable the function in a granular manner when only some parts of the site require specific functions (enable and disable the corresponding functions for each application on the server) it will further improve the performance of the application.
In IIS 7.0, another noteworthy performance feature is the new IIS output cache. This feature provides support for reuse of high-cost dynamic page responses on the server, thus alleviating the need for high-cost display processing and database transactions to return responses to the client. The IIS output cache is for ASP.. Net supports a set of smaller caching functions, but can provide sufficient flexibility for caching dynamic content in an enhanced performance mode.
By caching the dynamic content, whether it is ASP. NET page, PHP script, or CGI application, you can get 5-10 times of performance improvement, while greatly reducing the load on disks and databases.
IIS 7.0 should be able to run most existing applications without modification. This was a huge success considering the scope of changes to the architecture required to support innovation in this version. The Configuration System has been changed to a maximum, from a centralized loosely typed configuration storage to a delegated xml configuration file hierarchy. The structure and storage of configuration information are completely different from those of the IIS 6.0 metabase, and access through the original configuration API is not supported.
IIS 7.0 solves this problem by providing the metadatabase simulation layer. The simulation layer performs real-time conversion between the basic data of the Configuration System and the interface exposed by the metadatabase API. This enables the code to work correctly when accessing the code written for the metabase through ABO or higher-level WMI or ADSI scripts. However, you must install the compatibility component to obtain this function.
Although IIS 7.0 provides a new extensible model for IIS component development, it still supports ISAPI components. If you install the ISAPI extension and ISAPI filter installation components, you can run your extensions and filters as before. However, if new components are being developed, ensure that new extensible models are used for a stronger and improved development experience.
A few ASP. NET applications that are incompatible with the Runtime Library in the integration mode may have to be moved to the application pool running in the Classic mode. In this case, by placing multiple applications in a separate application pool, you can run these applications in two modes on the same server side by side. For a complete list of major ASP. Net changes and general ASP. NET compatibility information on IIS 7.0, see ASP. NET compatibility White Paper: iis.net/default.aspx? Tabid = 2 & subtabid = 25 & I = 1223.
The IIS 7.0 released in Windows Vista aims to provide the optimal architecture foundation for the next-generation Web application platform, focusing on the correct core architecture, scalability, and management platform for Web servers. Windows Vista enables you to develop and test these applications on the same server platform that is used to deploy applications when the Windows Vista server version is released.
Since IIS 7.0 was released in Windows Vista, the focus of the Web Platform and tool team is to prepare the Web server for the production environment and improve stability and performance for the production solution. However, the core development and management features included in Windows Vista will remain unchanged, and when the server version of IIS 7.0 is completed, it is expected to be provided to Windows Vista through the service pack. At that time, your client and server computer will run the same IIS version again, so that you can continue to develop and test web applications on the desktop running Windows Vista.
For a preliminary understanding of IIS 7.0, refer to a large number of useful resources provided on the Web. The iis.net website is the new homepage of the IIS team. Our new site is a portal containing all information about IIS 7.0, including detailed articles and usage steps for all IIS 7.0 features. Make sure you use the forum to ask questions and discuss the questions with the IIS team and the IIS community.
You can also find in-depth introduction to IIS 7.0 and internal information on my blog www.mvolo.com. Please be sure to visit to let me know your favorite IIS 7.0 theme, and I will try my best to discuss them in my blog.
Http://msdn.microsoft.com/msdnmag/issues/07/03/IIS7/default.aspx? Loc = ZH