IIS supports SSL protocol version 3. SSL 3 enables encrypted data transfers between client browsers and Web servers. The sections that follow provide an overview on how SSL works and how it's used.


Using SSL Encryption
As stated previously, encryption is the process of encoding information by using a mathematical algorithm that makes it difficult for anyone other than the intended recipient to view the original information. The encryption algorithm uses a mathematical value, called a key, to scramble the data so that the key must be used to recover the data.

Many techniques are available for encrypting information so that it can be exchanged. Some encryption techniques use a combination of public and private keys—the public key can be shared and the private key can't. Some encryption techniques use shared secret keys that are transferred between authenticated systems. SSL uses a technique called public key encryption, which combines private, public, and shared secret (session) keys.

In public key encryption, there are three keys:
• A public key that's available to any application that requests it
• A private key that's known only to its owner
• A session key that's created using public and private key data

IIS uses the public key encryption component in SSL to establish sessions between clients and servers. You should use SSL whenever you want to provide additional protection for data that's transferred between clients and servers. Some specific instances in which you might want to use Certificate Services and SSL follow:
• When you remotely manage the Web server by using the Administration Web site or operator administration pages
• When your Web site has secure areas that contain sensitive company documents
• When your Web site has pages that collect sensitive personal or financial information from visitors
• When your Web site processes orders for goods or services and you collect credit or other personal information from customers

With SSL, users connect to Web pages by using a secure Uniform Resource Locator (URL) that begins with https://. The https designator tells the browser to try to establish a secure connection with IIS. SSL connections for Web pages are made on port 443 by default, but you can change the port designator as necessary. As you set out to work with SSL, keep in mind that you can't use host headers with SSL. With SSL, Hypertext Transfer Protocol (HTTP) requests are encrypted, and the host header name within the encrypted request can't be used to determine the correct site to which a request must be routed.

After the client browser contacts the server by using a secure URL, the server sends the browser its public key and server certificate. Next, the client and server negotiate the level of encryption to use for secure communications. The server always attempts to use the highest level of encryption it supports. Once the encryption level is established, the client browser creates a session key and uses the server's public key to encrypt this information for transmission. Anyone intercepting the message at this point wouldn't be able to read the session key—only the server's private key can decrypt the message.

The IIS server uses its private key to decrypt the message sent by the client. The SSL session between the client and the server is now established. The session key can be used to encrypt and decrypt data transmitted between the client and server.

To recap, secure SSL sessions are established using the following technique:
1. The user's Web browser contacts the server by using a secure URL.
2. The IIS server sends the browser its public key and server certificate.
3. The client and server negotiate the level of encryption to use for the secure communications.
4. The client browser encrypts a session key with the server's public key and sends the encrypted data back to the server.
5. The IIS server uses its private key to decrypt the message sent by the client, and the session is established.
6. Both the client and the server use the session key to encrypt and decrypt transmitted data.


Using SSL Certificates
Not reflected in the previous discussion is the way in which SSL uses certificates. You can think of a certificate as an identity card that contains information needed to establish the identity of an application or user over a network. Certificates enable Web servers and users to authenticate one another before establishing a connection. Certificates also contain keys needed to establish SSL sessions between clients and servers.

In most cases certificates used by IIS, Web browsers, and Certificate Services conform to the X.509 standard. For this reason, they're often referred to as X.509 certificates. Different versions of the X.509 standard have been issued (see RFC 3280 for more information on this standard), and these versions have been revised from time to time. Two types of X.509 certificates are used:
• Client certificates, which contain identifying information about a client
• Server certificates, which contain identifying information about a server

Certificate authorities issue both types of certificates. A certificate authority (CA) is a trusted agency responsible for confirming the identity of users, organizations, and their servers and then issuing certificates that confirm these identities. Before issuing a client certificate, CAs require that you provide information that identifies you, your organization, and the client application you're using. Before issuing a server certificate, CAs require that you provide information that identifies your organization and the server you're using.

When you're choosing CAs to create your server certificates, you have several options. If you use Certificate Services, your organization can act as its own CA. When you act as your own CA, you use the following process to enable SSL on your Web server:
1. Install Active Directory Certificate Services on a server in the domain, and then generate the root CA certificate.
2. Generate a certificate request file for each Web site on your server that has a unique name, and then use the certificate request files to create server certificates for your Web sites.
3. Install the certificates and then enable SSL on each applicable Web site.
4. Client browsers won't recognize and trust your root CA certificate. To get browsers to trust the root CA, the user must install the certificate in the browser's authorities store.
5. Initiate SSL connections by using URLs that begin with https://.

Instead of using your own CAs, you can use third-party CAs—and there's an advantage to doing so. The third-party authority can vouch for your identity, and dozens of vendors are already configured as trusted CAs in Web browsers. In Microsoft Internet Explorer version 5 or later, you can obtain a list of trusted authorities by completing the following steps:
1. On the Tools menu, select Internet Options. The Internet Options dialog box appears.
2. On the Content tab, click Certificates. The Certificates dialog box appears.
3. On the Trusted Root Certification Authorities tab. you should now see a list of trusted root CAs.

When you use a trusted third-party authority, you follow a different procedure on your Web server to enable SSL than when you act as your own root CA:
1. Create a certificate request file for each Web site on your server that has a unique name.
Submit the certificate request files to a trusted third-party authority such as Verisign. The 2. CA will process the requests and send you certificates.
3. Complete the certificate request by installing the certificate, and then enable SSL on each applicable Web site.
4. Client browsers initiate SSL sessions by using a secure URL beginning with https://.

Regardless of whether you act as your own CA or use a trusted CA, you still must manage the server certificates, and you use Active Directory Certificate Services to do this. Server certificates can expire or be revoked, if necessary. For example, if your organization is an Internet service provider (ISP) that issues its own certificates, you might want your customers' server certificates to expire annually. This forces customers to update their certificate information at least once a year to ensure that it's current. You also might want to revoke a certificate when a customer cancels service.


Understanding SSL Encryption Strength
An SSL session's encryption strength is directly proportional to the number of bits in the session key. This means that session keys with a greater number of bits are considerably more difficult to crack and, thus, are more secure.

The most commonly used encryption levels for SSL sessions are 40-bit, 128-bit, and 256-bit. Encryption at the 40-bit level is adequate for most needs, including e-commerce. Encryption at the 128-bit level provides added protection for e-commerce. Encryption at the 256-bit level provides superior protection for sensitive personal and financial information. Most versions of Microsoft Windows Server shipped in the United States are configured with 256-bit encryption.

Don't confuse the encryption level for SSL sessions (the strength of the session key expressed as bits) with the encryption level for SSL certificates (the strength of the certificate's public and private keys expressed as bits). Most encryption keys (public and private) have a bit length of 512 or higher. When a user attempts to establish an SSL session with your Web server, the user's browser and the server use the bit length of their encryption keys to determine the strongest level of encryption possible. If the encryption keys use 512 bits, the level of encryption is set to 40 bits. If the encryption keys use 1024 bits, the level of encryption is set to 128 bits. If the encryption keys use 2048 bits, the level of encryption is set to 256 bits. Other key bit lengths and encryption levels are available.



Source of Information : Microsoft Press Internet Information Services IIS 7.0 Administrators Pocket Consultant

• 0 comments »

Before you deploy IIS 7.0, you should carefully plan the server architecture. As part of your planning, you need to look closely at pre-installation requirements and the hardware you will use. IIS 7.0 is no longer the simple solution for hosting Web sites that it once was. It now provides the core infrastructure for hosting Web servers, Web applications, and Windows SharePoint Services.

Guidelines for choosing hardware for Internet servers are much different from those for choosing other types of servers. A Web hosting provider might host multiple sites on the same computer and might also have service level agreements that determine the level of availability and performance required. On the other hand, a busy e-commerce site might have a dedicated Web server or even multiple load-balanced servers. Given that Internet servers are used in a wide variety of circumstances and might be either shared or dedicated, here are some guidelines for choosing server hardware:

Memory The amount of random access memory (RAM) that's required depends on many factors, including the requirements of other services, the size of frequently accessed content files, and the RAM requirements of the Web applications. In most installations, I recommend that you use at least 1 gigabyte (GB) of RAM. High-volume servers should have a minimum of 2 to 4 GB of RAM. More RAM will allow more files to be cached, reducing disk requests. For all IIS installations, the operating system paging file size should at least equal the amount of RAM on the server.

Note
Don't forget that as you add physical memory, virtual paging to disk grows as well. With this in mind, you might want to ensure that the Pagefile.sys file is on the appropriate disk drive, one that has adequate space for the page file to grow, along with providing optimal input/output (I/O) performance.


• CPU. The CPU processes the instructions received by the computer. The clock speed of the CPU and the size of the data bus determine how quickly information moves among the CPU, RAM, and system buses. Static content, such as HTML and images, place very little burden on the processor, and standard recommended configurations should suffice. Faster clock speeds and multiple processors increase the performance scalability of a Web server, particularly for sites that rely on dynamic content. 32-bit versions of Windows run on Intel x86 or compatible hardware. 64-bit versions of Windows run on the x64 family of processors from AMD and Intel, including AMD64 and Intel Extended Memory 64 Technology (Intel EM64T). IIS provides solid benchmark performance on Intel Xeon, AMD Opteron, and AMD Athlon processors. Any of these CPUs provide good starting points for the typical IIS server. You can achieve significant performance improvements with a large processor cache. Look closely at the L1, L2, and L3 cache options available—a larger cache can yield much better performance overall.

• SMP. IIS supports symmetric multiprocessors (SMPs) and can use additional processors to improve performance. If the system is running only IIS and doesn't handle dynamic content or encryption, a single processor might suffice. You should always use multiple processors if IIS is running alongside other services, such as Microsoft SQL Server or Microsoft Exchange Server.

• Disk drives. The amount of data storage capacity you need depends entirely on the size of content files and the number of sites supported. You need enough disk space to store all your data plus workspace, system files, and virtual memory. I/O throughput is just as important as drive capacity. However, disk I/O is rarely a bottleneck for Web sites on the public Internet—generally, bandwidth limits throughput. High-bandwidth sites should consider hardware-based redundant array of independent disks (RAID) solutions using copper or fiber channel–based small computer system interface (SCSI) devices.

• Data protection. Unless you can tolerate hours of downtime, you should add protection against unexpected drive failures by using RAID. Hardware RAID implementations are always preferred over software RAID implementations. RAID 0 (disk striping without parity) offers optimal read/write performance, but if a drive fails, IIS won't be able to continue operation until the drive is replaced and its contents are restored from backup. Because of this, RAID 0 isn't the recommended choice. RAID 1 (disk mirroring) creates duplicate copies of data on separate physical drives, allowing the server to remain operational when a drive fails, and even while the RAID controller rebuilds a replacement drive in a failed mirror. RAID 5 (disk striping with parity) offers good protection against single-drive failure but has poor write performance. Keep in mind that if you've configured redundant load-balanced servers, you might not need RAID. With load balancing, the additional servers might offer the necessary fault tolerance.

• UPS. Sudden power loss and power spikes can seriously damage hardware. To prevent this, get an uninterruptible power supply (UPS). A properly configured UPS system allows the operating system to automatically shut down the server gracefully in the event of a power outage, and it's also important in maintaining system integrity when the server uses write-back caching controllers that do not have on-board battery backups. Professional hosting providers often offer UPS systems that can maintain power indefinitely during extended power outages.

Source of Information : Microsoft Press Internet Information Services IIS.7.0 Administrators Pocket Consultant

• 0 comments »

In addition to native modules, IIS 7.0 ships with several modules developed using managed code. Some of the managed modules, such as UrlAuthorization, have a native module counterpart that provides a native alternative to the managed module. Although modules developed using native code are generally faster and more efficient with memory and other system resources, native code modules can often be a less time-consuming and flexible alternative to develop. Note that managed modules require that the ManagedEngine module be installed.

The following table lists the managed modules that ship with IIS 7.0:

AnonymousIdentification. Manages anonymous identifiers, which are used by features that support anonymous identification such as ASP.NET profile.

DefaultAuthentication. Provides an authentication object to the context when no other authentication method succeeds.

FileAuthorization.Verifies that a user has permission to access the requested file.

FormsAuthentication. Supports authentication by using Forms authentication.

OutputCache. A managed code alternative to the native HttpCacheModule.

Profile. Manages user profiles by using ASP.NET profile, which stores and retrieves user settings in a data source such as a database.

RoleManager. Manages a RolePrincipal instance for the current user.

Session. Supports maintaining the session state, which enables storage of data specific to a single client within an application on the server. Note that without this module, the session state will be unavailable in your applications.

UrlAuthorization. Determines whether the current user is permitted access to the requested URL, based on the user name or the list of roles that a user is a member of.

UrlMappingsModule. Supports configurable mapping of a real URL to a more user-friendly URL (that is, URL Rewrite).

WindowsAuthentication. Sets the identity of the user for an ASP.NET application when Windows authentication is enabled.

Almost all of the feature set of IIS that was implemented as part of the core web server system in previous versions is now delivered as a set of modular plug-in components.

Components can be installed or removed as needed, thus streamlining the server workload and customizing to the specific application. Since this modular structure is based on the worker process object, this customization can be applied to any level, from discrete applications to the global web server environment.

Source of Information : Wrox Professional IIS 7

• 0 comments »

HTTP Modules
The following modules provide HTTP-specific tasks related to client–server interaction.

HttpRedirectionModule. Supports configurable redirection for HTTP requests to a local resource.

ProtocolSupportModule. Performs protocol-related actions (such as setting response headers and redirecting headers), implements the Trace and Options HTTP verbs, and manages keep-alive support via configuration controls.


Security Modules
The following lists the modules that perform security-related functions. A separate module exists for each authentication mechanism, allowing you to select which authentication mechanisms are supported on your server and to remove those that you don’t need.

Note that you must install at least one authentication module. Without at least one authentication module, IIS cannot determine whether the request is authorized to access the relevant system resources. IIS checks for a valid user object after the authentication phase and returns a 401.2 error if it doesn’t find one.

AnonymousAuthentication Module. Performs Anonymous authentication when no other authentication method succeeds, or if no other authentication module is present. Typically, this module would be removed for an intranet or secured membership application.

BasicAuthenticationModule. Performs Basic authentication as described in RFC 2617.

DigestAuthentication Module. Performs Digest authentication as described in RFC 2617. The IIS host must be part of an Active Directory domain.

IISCertificateMapping AuthenticationModule. Maps SSL client certificates to a Windows account. SSL must be enabled with the requirement to receive client certificates for this module to work.

CertificateMapping AuthenticationModule. Similar to the previous module, but performs Certificate Mapping authentication using Active Directory. SSL must be configured for this module to work, and the IIS host must be a member of an Active Directory domain. Caution: Requests may be allowed if Active Directory Certificate Mapping is configured to protect a directory but the module is removed!

RequestFilteringModule. Performs URLScan tasks such as configuring allowed verbs and file extensions, setting limits, and scanning for bad character sequences. This module is the successor of the ISAPI filter UrlScan.DLL that shipped with IIS 5.0 and 6.0.

UrlAuthorizationModule. Performs URL authorization based on configuration rules.

WindowsAuthentication Module. Performs Windows authentication (NTLM or Kerberos).

IpRestrictionModule. Restricts access to IPv4 clients based on a list of addresses in the IISconfiguration.


Content Modules
The following modules provide functionality related to static web-site content, such as images and plain HTML:

DefaultDocumentModule. Displays a default document from a list of default files in the configuration when no explicit document has been identified in the request. If a matching default document is not found, a 404 result will be returned.

DirectoryListingModule. Lists the contents of a directory if no file is explicitly requested—for example, when the request is something like http://www.server1.com/path/ or just http://www.server1.com. Note that if the DefaultDocumentModule is installed, a default document match will be attempted first. If this module is not installed, and either the default document module is not installed or there is no matching default document found, a 404 (not found) error will result.

ServerSideIncludeModule. Implements server-side includes for those requests ending in .stm, .shtm, or .shtml.

StaticFileModule Delivers static file content such as plain HTML and images. The list of file extensions supported is determined by the staticContent/mimeMap configuration collection.If this module is not present, requests for static content return an HTTP 200 (OK) response, but the entity body (page) will be blank.


Compression Modules
The following two modules perform gzip compression in the request-processing pipeline. Most modern web browsers and search engine indexers support this compression technique.

DynamicCompressionModule. Applies gzip compression to outbound responses produced by applications.

StaticCompressionModule. Performs gzip compression of static content in memory as well as persistent in the file system.


Caching Modules
The following modules manage caching of responses to requests. Note that for user mode caching, the cache resources are defined under the user account mapped to the request, whereas the kernel mode cache is handled by the Http.sys identity.

FileCacheModule. Provides user mode caching for files and handles on files opened by the server engine and modules, reducing file access overheads and improving request delivery times.

HTTPCacheModule. Provides kernel mode and user mode caching in Http.sys and manages the output cache, including cache size and cache profiles as defined via configuration controls.

TokenCacheModule. Caches Windows security tokens for password-based authentication schemes (Anonymous, Basic, IIS client certificate). For example, a password-protected
HTML page that references 50 images that are also protected would normally result in 51 logon calls to the local account database, or, even worse, to an offbox domain controller. Using the TokenCacheModule, only one logon event is called and the result is cached, with the remaining reference requests authorized through that cached authentication token.

UriCacheModule. Provides user mode caching of URL information, such as configuration settings. With this module, the server will read configuration data only for the first request for a particular URL, and reuse it on subsequent requests until it changes.


Logging and Diagnostics Modules
The following modules provide support for functions related to web-site and web application diagnostics and logging. Logging includes ordinary web request logs, as well as application execution logging during run time or failure.

CustomLoggingModule. Provided for legacy support of custom logging modules such as ODBC support. This module also supports the ILogPlugin COM interface, but you should use the new Http Module API for any new development.

FailedRequestsTracing Module. Implements tracing of failed requests, taking definition and rules for failed requests via configuration.

HttpLoggingModule. Implements the standard web-site logging functions by Http.sys.

RequestMonitorModule. Implements the IIS 7.0 Runtime State and Control Interface \ (RSCA). RSCA allows its consumers to query for runtime information like currently executing request, start/stop state of a web site, or currently executing application domains.

TracingModule. Reports events to Microsoft Event Tracing for Windows (ETW).

CustomErrorModule. Sends rich HTML content to the client on server error, and allows you to customize that default content. Without this module, IIS will send blank pages with minimal information on any server error, including 404.

ConfigurationValidation Module. Validates configuration issues, such as when an application is running in Integrated mode but has handlers or modules declared in the system.web section, and displays relevant error information if a problem is detected.


Extensibility Support Modules
The following modules support extending the web server platform to produce dynamic content and special functionality:

IsapiModule. Implements functionality for ISAPI Extensions mapped in the section (modules=”IsapiModule”) or called by a specific URL request to the dll.

IsapiFilterModule. Implements ISAPI filter functionality, such as legacy mode ASP.NET or SharePoint.

ManagedEngine Provides integration of managed code modules in the IIS request-processing pipeline. If this module is not installed, then managed code modules will not work, even if they are installed.

CgiModule. Implements the Common Gateway Interface (CGI) to allow the execution of external programs like Perl, PHP, and console programs to build response output.

FastCgiModule. Supports FastCGI, which provides a high-performance alternative to CGI.

Source of Information : Wrox Professional IIS 7

• 0 comments »

Unlike previous versions, with core server implementations that were successively larger and more complex, IIS 7.0 provides a sleek core server system cut down to the bare bones of a high-performance and robust processing engine. The basic functionality is broken into three basic components that act as the foundation of arguably the most innovative and flexible web server system ever released:

• Http.sys — The HTTP Listener does nothing more than listen on port 80 for inbound web requests and then pass those requests to the IIS 7.0 core.

• svchost.exe — The WWW Publishing Service provides the basic web server functions of identifying the specific web-site destination and managing resources and execution of the relevant worker process(es) used to handle the request.

• w3wp.exe — One or more worker processes that handle all the remaining request processing.

At first glance, the IIS 7.0 core server appears similar to previous versions. IIS 6.0 introduced the concept of independent worker processes to isolate independent applications running on the same physical server and thereby prevent a failure in one application from affecting any other.

If you are familiar with the structure of IIS 6.0, you may recognize the same basic structure of HTTP Listener, WWW Publishing Service, and application pool; but the major difference in IIS 7.0 lies in the implementation of the worker processes. Although IIS 7.0 also executes each request inside independent application pools, the way these processes handle the request is an entirely new approach.

The application pool process itself can now be considered as a simple workflow or processing pipeline. Each stage in the request life cycle is referred to as an event, and modules provide the relevant functionality for the event processing. For example, when the worker process reaches the authenticateRequest event stage, it will hand off processing to any active module providing that function.

HTTP Modules
Out of the box, IIS 7.0 ships with more than 40 individual modules. The default installation activates many of these, which, as you will discover below in this chapter, are not all required. In fact, you can obtain a perfectly functional web server using only a handful of the default modules. To understand how the core server works, it is useful to take a closer look at each of modules that ship with IIS 7.0. There are two basic categories:

• Native Code Modules — Generally, a binary .dll file, developed using languages such as VB and C++.

• Managed Code Modules — Developed using scripted and runtime interpreted languages, including C# and ASP.NET.

Source of Information : Wrox Professional IIS 7

• 0 comments »

IIS 7.0 was built with the following characteristics in mind:

• Simple to use—As previously mentioned, IIS 7.0 does not use the same metabase scheme as previous versions of IIS, but rather uses a series of plain-text XML files for configuration. With IIS 7.0, the state is in the files, thus a change to the files results in an immediate change to the server, site, or application configuration.

• Securely built—The default configuration is set to allow only the system administrator to configure the server, sites, and applications. By using Feature Delegation, system administrators can securely make site and application administration available to down-level administrators without giving more permissions on the server than necessary. The system by default does not store sensitive information like passwords. However, if there is a need to store sensitive information, it is encrypted on the hard disk. In addition to these security features, applications can be isolated to prevent other applications from sharing or reading the settings.

• Extensible — Just as the IIS Manager is extensible, so is the IIS configuration. This is made easy because the schema of IIS is contained in XML files. To extend the schema, just place an XML file in the schemas folder. You’ll see below how the settings are arranged in “sections” within the configuration files.

• Low TCO—By changing to the XML file-based schema, IIS 7.0 is easier to deploy and manage. The file-based schema allows for web settings to be published in the same files as the web-site content. With this used in conjunction with Feature Delegation, the system administrator doesn’t have to be as involved with every site change made on the server. The web.config file can contain both the IIS settings and the ASP.NET settings for a web site permitting centralized control over the site settings. The file-based structure also makes it possible to use standard file systembased tools for maintenance (backup and restore) and security.

• Compatible with previous versions — Applications created for IIS 6.0 will continue to run on IIS 7.0 by calling interfaces such as Admin Base Objects (ABO), the ADSI provider, and the IIS 6.0 WMI provider. Because .NET Framework 2.0 was built into IIS 7.0 from the ground up, current .NET applications will continue to work by calling System.Configuration and System.Web.Configuration. The config files will continue to follow the structure of the web.config and machine.config files from IIS 6.0, as well as add IIS configuration settings to the files.

Source of Information : Wrox Professional IIS 7

• 0 comments »

1xx — Positive Preliminary Reply
These status codes indicate that an action has started successfully, but the client expects another reply before it continues with a new command.
• 110 — Restart marker reply.
• 120 — Service ready in nnn minutes.
• 125 — Data connection already open; transfer starting.
• 150 — File status okay; about to open data connection.


2xx — Positive Completion Reply
An action has successfully completed. The client can execute a new command.
• 200 — Command okay.
• 202 — Command not implemented, superfluous at this site.
• 211 — System status, or system help reply.
• 212 — Directory status.
• 213 — File status.
• 214 — Help message.
• 215 — NAME system type, where NAME is an official system name from the list in the Assigned Numbers document.
• 220 — Service ready for new user.
• 221 — Service closing control connection. Logged out if appropriate.
• 225 — Data connection open; no transfer in progress.
• 226 — Closing data connection. Requested file action successful (for example, file transfer or file abort).
• 227 — Entering passive mode (h1,h2,h3,h4,p1,p2).
• 230 — User logged in, proceed.
• 250 — Requested file action okay, completed.
• 257 — “PATHNAME” created.


3xx — Positive Intermediate Reply
The command was successful, but the server needs additional information from the client to complete processing the request.
• 331 — User name okay, need password.
• 332 — Need account for login.
• 350 — Requested file action pending further information.


4xx — Transient Negative Completion Reply
The command was not successful, but the error is temporary. If the client retries the command, it may succeed.
• 421 — Service not available, closing control connection. This may be a reply to any command if the service knows it must shut down.
• 425 — Cannot open data connection.
• 426 — Connection closed; transfer aborted.
• 450 — Requested file action not taken. File unavailable (for example, file busy).
• 451 — Requested action aborted: Local error in processing.
• 452 — Requested action not taken. Insufficient storage space in system.


5xx — Permanent Negative Completion Reply
The command was not successful, and the error is permanent. If the client retries the command, it receives the same error.
• 500 — Syntax error, command unrecognized. This may include errors such as command line too long.
• 501 — Syntax error in parameters or arguments.
• 502 — Command not implemented.
• 503 — Bad sequence of commands.
• 504 — Command not implemented for that parameter.
• 530 — Not logged in.
• 532 — Need account for storing files.
• 550 — Requested action not taken. File unavailable (for example, file not found, no access).
• 551 — Requested action aborted: Page type unknown.
• 552 — Requested file action aborted. Exceeded storage allocation (for current directory or dataset).
• 553 — Requested action not taken. File name not allowed.

Source of Information : Wrox Professional IIS 7

• 0 comments »

1xx — Informational
These status codes indicate a provisional response. The client should be prepared to receive one or more 1xx responses before receiving a regular response.
• 100 — Continue.
• 101 — Switching protocols.


2xx — Success
This class of status codes indicates that the server successfully accepted the client request.
• 200 — OK. The client request has succeeded.
• 201 — Created.
• 202 — Accepted.
• 203 — Non-authoritative information.
• 204 — No content.
• 205 — Reset content.
• 206 — Partial content.


3xx — Redirection
The client browser must take more action to fulfill the request. For example, the browser may have to request a different page on the server or repeat the request by using a proxy server.
• 301 — Moved permanently.
• 302 — Object moved.
• 304 — Not modified.
• 307 — Temporary redirect.


4xx — Client Error
An error occurs, and the client appears to be at fault. For example, the client may request a page that does not exist, or the client may not provide valid authentication information.
• 400 — Bad request.
• 401 — Access denied. IIS defines a number of different 401 errors that indicate a more specific cause of the error. These specific error codes are displayed in the browser but are not displayed in the IIS log:
• 401.1 — Logon failed.
• 401.2 — Logon failed due to server configuration.
• 401.3 — Unauthorized due to ACL on resource.
• 401.4 — Authorization failed by filter.
• 401.5 — Authorization failed by ISAPI/CGI application.
• 401.7 — Access denied by URL authorization policy on the Web server. This error code is specific to IIS 6.0.
• 403 — Forbidden. IIS defines a number of different 403 errors that indicate a more specific cause of the error.
• 403.1 — Execute access forbidden.
• 403.2 — Read access forbidden.
• 403.3 — Write access forbidden.
• 403.4 — SSL required.
• 403.5 — SSL 128 required.
• 403.6 — IP address rejected.
• 403.7 — Client certificate required.
• 403.8 — Site access denied.
• 403.9 — Too many users.
• 403.10 — Invalid configuration.
• 403.11 — Password change.
• 403.12 — Mapper denied access.
• 403.13 — Client certificate revoked.
• 403.14 — Directory listing denied.
• 403.15 — Client Access Licenses exceeded.
• 403.16 — Client certificate is untrusted or invalid.
• 403.17 — Client certificate has expired or is not yet valid.
• 403.18 — Cannot execute requested URL in the current application pool. This error code is specific to IIS 6.0.
• 403.19 — Cannot execute CGIs for the client in this application pool. This error code is specific to IIS 6.0.
• 403.20 — Passport logon failed. This error code is specific to IIS 6.0.
• 404 — Not found.
• 404.0 — (None) — File or directory not found.
• 404.1 — Web site not accessible on the requested port.
• 404.2 — Web service extension lockdown policy prevents this request.
• 404.3 — MIME map policy prevents this request.
• 405 — HTTP verb used to access this page is not allowed (method not allowed).
• 406 — Client browser does not accept the MIME type of the requested page.
• 407 — Proxy authentication required.
• 412 — Precondition failed.
• 413 — Request entity too large.
• 414 — Request-URI too long.
• 415 — Unsupported media type.
• 416 — Requested range not satisfiable.
• 417 — Execution failed.
• 423 — Locked error.


5xx — Server Error
The server cannot complete the request because it encounters an error.
• 500 — Internal server error.
• 500.12 — Application is busy restarting on the Web server.
• 500.13 — Web server is too busy.
• 500.15 — Direct requests for Global.asa are not allowed.
• 500.16 — UNC authorization credentials incorrect. This error code is specific to IIS 6.0.
• 500.18—URL authorization store cannot be opened. This error code is specific to IIS 6.0.
• 500.100 — Internal ASP error.
• 501 — Header values specify a configuration that is not implemented.
• 502 — Web server received an invalid response while acting as a gateway or proxy.
• 502.1 — CGI application timeout.
• 502.2 — Error in CGI application.
• 503 — Service unavailable. This error code is specific to IIS 6.0.
• 504 — Gateway timeout.
• 505 — HTTP version not supported.

Source of Information : Wrox Professional IIS 7

• 0 comments »