Home     RSSRSS

Posts Tagged ‘IIS 6’

How to enable logging in IIS 7.0

February 24, 2014 by kiranbadi1991 | Comments Off on How to enable logging in IIS 7.0 | Filed in Development, Environment, Performance Engineering, Web Server

IIS 7 on Windows 2008 Server has increased the logging capability of IIS compare to IIS 6. IIS 7 ships with below modules which are default on set up,

HTTP Logging Module(loghttp.dll)

Interacts with HTTP.sys process and processes request status. It is required for generation of logs.

Failed Request Tracing Module(iisfreb.dll)

Logs failed Requests for debugging purpose

Request Monitor Module(iisreqs.dll)

Watches the worker process activity

Tracing Module(iisetw.dll)

ETW tracing to capture trace file

Custom log Module(logcust.dll)

Logs custom module information

All the modules are located in system 32 /inetsrv directory of the server (Please see below screenshot),


It’s now possible to log information on per site basis or globally with IIS. It’s also possible to log just only the failed requests or only successful requests. Centralized logging can be done in Binary or W3C format.

In Order to enable logging, below steps needs to be followed,

  • Open Server Manager. Open command Prompt window and Type Run. Run Window will open. In Run window type CompMgmtLauncher.exe
  • Click on Roles (Web Server Roles).Check if Http logging is installed. If it’s not then you need to install it by adding appropriate Role.
  • Check the HTTP Logging box and install it.
  • Close the Server manager.
  • Once enabled you should be able to see something like below screen once you click on HTTP logging Module. (Below screen is from IIS 8).


Once the logging is enabled, logs tags are automatically created in applicationhost config file.

<centralBinaryLogFile enabled=”truedirectory=”%SystemDrive%\inetpub\logs\LogFiles/>
<centralW3CLogFile enabled=”truedirectory=”%SystemDrive%\inetpub\logs\LogFiles/>

Its always a best practice to generate logs in the separate drive from your main drive where we have installed IIS 6 or the drive where heavy lifting of requests take place.

Tags: , , , ,

Understanding Various Types of Authentication in IIS

April 9, 2013 by kiranbadi1991 | Comments Off on Understanding Various Types of Authentication in IIS | Filed in Browser, Development, Environment, Web Server

Few Days back I was a part of the debate with few ASP.NET developers where we were discussing the pros and cons of various web servers available in the market and types of authentication methods supported by them, why quite often public facing sites uses form based authentication and not any other types of authentication.I have been the fan of IIS since its 5x days and have learned a quite a bit about it from IIS product team members.( I am also huge fan of Apache Webserver, only think I hate about them is that they stopped giving binaries to Windows Users and its pain to built it from source unless we are on .nix platform).

I call Authentication as something where users supply their credential in order to identify themselves to the server and servers based on the roles configured in some system it determines their authorization powers as what type of operations users are entitled to do in the application.Authorization always happens after Authentication and almost at the same time.

Latest version of IIS provides around 6 ways for doing authentication and they are ,

  • Anonymous Authentication: In this type end user do not supply credentials, effectively making an anonymous request. IIS 7 impersonates a fixed user account when attempting to process the request.This type of authentication is mostly used for public-facing web sites where visitors are not required to supply credentials.Users can access the site freely and browsers will not prompt the users for any kind of challenge. Its enabled by default in IIS 7.0 version. One of the best way to prevent users from accessing any resource which requires credentials is to create separate group and assign appropriate  permission levels to it. Also execute permission levels should be denied to Anonymous users on windows directories.
  • Basic Authentication: In this type end users is prompted to supply credentials, which are then transmitted unencrypted in base 64 format across the network. Basic Authentication is supported by all major browsers. This type of Authentication should be used only when traffic flows entirely on SSL so that the data flowing in the wire is encrypted.Anonymous Authentication should be disabled in case we want to use Basic Authentication.
  • Digest Authentication: Over here end user are prompted to supply credentials, however not like in Basic authentication, the user’s password is not passed in clear text across the wire but it’s hashed using MD5.It’s mostly used along with Windows Domain Controller.Browsers needs to http 1.1 compliant in order to use this type of authentication.In addition to this Anonymous Authentication should be disabled. Quite a few intranet application in the large companies uses this type of Authentication internally for their application.
  • Integrated Windows Authentication: It contains two separate authentication schemes: NTLM v2 (NT Challenge/Response) and Kerberos. Enabling Integrated Windows authentication using IIS Manager enables support for both of these two schemes. NTLM works similar to to Digest authentication (it hashes users password). Kerberos relies on shared secrets between the client, ADC, and the IIS server to authenticate the user. Kerberos is only available for Windows Active Directory accounts, whereas NTLM can be used for local accounts as well. IIS 7.0 does not present Kerberos as a discrete authentication option to the client, instead sending a “Negotiate” option, allowing the client to choose Kerberos or NTLM. NTLM can be presented as a discrete authentication option to the client. Microsoft recommends using this type of authentication for Intranet Applications since client and servers share the same domain. This type of authentication is not useful for internet because there is no encryption in the internet.
  • Client Certificate Authentication:When using this type of authentication, the client presents a certificate to the server. The server is configured to map certificates to one or more Windows user accounts (it is possible to map multiple certificates to a single user account or to map each certificate to an individual user account). IIS logs on the mapped user account.Client Certificate authentication requires that SSL/TLS be enabled for the resource being secured.Mapping client certificates lets you automatically authenticate users who log on with client certificates, without requiring the use of other supported authentication methods such as Basic, Digest, or Integrated Windows authentication.
  • UNC Authentication : When Server needs to retrieve files from a remote network resource e g file share, a virtual directory in IIS can be mapped to a UNC path. When configuring this virtual directory, it is possible to specify a some fixed user account that will be used to connect to that file share, irrespective of the identity of the end user.
  • Form Based Authentication:It relies on the supply of credentials via html form as part of the HTTP traffic.In this way, the request for the login form is an anonymous request. After authenticating via the HTML form, an authentication cookie is set by the server.The client must return this cookie with each subsequent request in order for the request to be authenticated. Although this authentication can be configured using IIS Manager, it is effectively ASP.NET’s Form Based Authentication.Forms Based Authentication can be combined with either ASP.NET’s authorization features
    (available with previous versions of ASP.NET) or IIS 7.0 new inbuilt URL Authorization feature to protect access to resources.

All these types of Authentication can be configured at directory level, website level or at file level. Maybe sometimes later I will write some posts as how to configure these types of Authentication in IIS.

Tags: , , ,

Understanding IIS Logs

March 6, 2012 by kiranbadi1991 | Comments Off on Understanding IIS Logs | Filed in Development, Environment, Performance Engineering, Testing

Webserver logs provides lot of information to the performance engineer with regard to errors, response time and many other things which cannot be seen from the front end or User interface side of the application. So it’s important for the performance engineer to understand as what information these logs contain and what type of issues we can identify and confirm from the Webserver logs. So for the sake of understanding, I would take the example of IIS and quickly run through the some of the fields these  logs contains.

The typical IIS logs (taken from Microsoft Site) will contain the below mentioned data in its access logs,



The date on which the activity occurred.



The time, in coordinated universal time (UTC), at which the activity occurred.

Client IP Address


The IP address of the client that made the request.

User Name


The name of the authenticated user who accessed your server. Anonymous users are indicated by a hyphen.

Service Name and Instance Number


The Internet service name and instance number that was running on the client.

Server Name


The name of the server on which the log file entry was generated.

Server IP Address


The IP address of the server on which the log file entry was generated.

Server Port


The server port number that is configured for the service.



The requested action, for example, a GET method.

URI Stem


The target of the action, for example, Default.htm.

URI Query


The query, if any, that the client was trying to perform. A Universal Resource Identifier (URI) query is necessary only for dynamic pages.

HTTP Status


The HTTP status code.

Win32 Status


The Windows status code.

Bytes Sent


The number of bytes that the server sent.

Bytes Received


The number of bytes that the server received.

Time Taken


The length of time that the action took, in milliseconds.

Protocol Version


The protocol version —HTTP or FTP —that the client used.



The host header name, if any.

User Agent


The browser type that the client used.



The content of the cookie sent or received, if any.



The site that the user last visited. This site provided a link to the current site.

Protocol Substatus


The substatus error code.

Some fields in the above logs are optional and so they need to be enabled in some cases. I suggest you if your logs don’t contain all those fields, then probably you should talk to server admin and get those enabled.Its always helps to have as many fields as possible enabled.

From the response time prospective, time taken field gives the information about the processing time it takes for IIS to process the request and in most cases contains the network timelines as well. For IIS 5x, its just the processing time at IIS level without network timeline. However starting from IIS 6x/7x , time taken field contains processing time as well as network time. This is one of most important log field which can help  to quickly identify URL’s which are taking high response time.All you need to do pull the URL with high time taken value and map it back to script and from script pull the transaction details.

sc-win32-status is also one of the important fields which we need to check in the IIS logs, if your tests contains lot of client abort exceptions or system.net exceptions, this field can confirm you your doubts about network issues.There are many integers codes which are written for every request IIS serves and whenever if any kind of issues are encountered by IIS , appropriate win32 code is written for that request in the logs. Interpreting that code can help you in identifying the root cause of the issue.To know the meaning of each sc-win32-status code, all you need to do is go to cmd command and type below lines

c: >net helpmsg  <your sc-win32-statuscode>

for example,
C:\>net helpmsg 64

The specified network name is no longer available.

s-ip and s-port  can also be helpful in cases where in your application user interface layer is protected at front end by load balancer and in these cases its load balancer which routes the requests to the various backend server using its own ip address.So If you are troubleshooting load balancing issues, then ip and port here can save you lot of time.Believe me its real pain to through packets and open around 1gb of pcap files and run through each frame.

IIS logs can also help you in confirming various issues that we normally encounter during load testing. If time taken field in IIS logs shows more response time than response time SLA’s then probably you don’t need to go into any kind of test results analysis and just post these logs to concerned teams so that they can have a look at the application or environment without wasting any further time of testing.Then there are also some cases where in advanced analysis of logs can confirm or deny some kind of network contention issues,

for example consider the below data from access logs,

#Fields: date time s-ip cs-method cs-uri-stem cs-uri-query s-port cs-username c-ip cs(User-Agent) sc-status sc-substatus sc-win32-status sc-bytes cs-bytes

2009-08-11 20:19:32 x.x.x.x GET /File.aspx – 80 – y.y.y.y Mozilla/4.0+(compatible;+MSIE+8.0;+Windows+NT;+WOW64;+Trident/4.0; 200 0 0 2232 123

2009-08-11 20:19:45 x.x.x.x POST /File.aspx – 80 – y.y.y.y Mozilla/4.0+(compatible;+MSIE+8.0;+Windows+NT;+Trident/4.0; 200 0 64 0 123

In the above example, if you look at the sc-win32-status code, its 64 which means that network name is not available and http status is 200, if you see many such lines in your logs during load test, you can easily make the conclusion that something went wrong on the network side where as  IIS was able to process request successfully ,but for some reasons was not able to send the response back to client due to some network issue or say communication issues between server and the client. Checking for sc-bytes as 0 confirms that nothing was send to the client for that request. This kind of analysis will directly help you in ruling out other causes and will help you in identifying the root cause quickly.

Then there might be cases where in you might also need to map IIS logs data to the native performance counters like asp.net request queued or requests failed etc to confirm or deny some variables which might give confusing symptoms specially in cases where in we see appdomain unload events or application restart events during load tests.

So if you are having application which deals with IIS, then please do make sure that you ask for access to IIS Access logs in addition to HTTP Err logs. Both these logs will help you in identifying and fixing some of the hardest performance issues.


Tags: , ,