This configuration is important both for the performance and the security of the production environment.


Performance-wise, you can set the <deployment retail> to true in order to ensure that no one accidentally deploys an ASP.NET app in production while the <compilation debug="true"/> enabled. Leaving the <compilation debug-"true"/> switch will cause several things that can harm performance:


1) The compilation of ASP.NET pages will take longer

2) Code will sometimes execute slower (since some additional debug paths are enabled)

3) The application's runtime will use much more memory

4) Scripts and images downloaded from the WebResources.axd handler won't be cached


This blog post will cover:

  1. IIS deployment method retail policy description.
  2. IIS deployment method retail potential vulnerability.
  3. Countermeasures.
  4. IIS deployment method retail default value.
  5. CalCom’s recommended value.
  6. How to set the switch.
  7. Automating IIS hardening.



This switch is developers-focused. These kinds of switches are often enabled during active development. It is recommended that the deployment method on any production server will be set to retail.

This policy allows us to minimize possible information leakages. Setting the <compilation debug="true"/> switch will disable the application's ability to generate trace output on a page, display detailed error messages to end-users, and disabling the debug switch.


How to disable TLS 1.0 in IIS server


When this switch is not utilized, vital application and system information may leak. An attacker will be able to cover trace output in a pager and see detailed error messages.



Set <deployment retail="true"/> switch.



The <deployment retail> tag is not included in the machine.config by default.


<deployment retail="true"/>



  1. Open the machine.config file located in: %systemroot%\Microsoft.NET\Framework<bitness (if not the 32 bit)>\<framework version>\CONFIG


  1. set within your machine.config file:



<deployment retail="true"/>




** If systems are 64-bit, do the same for the machine.config located in: %systemroot%\Microsoft.NET\Framework<bitness (if not the 32 bit)>\<framework version>\CONFIG



Server hardening can be a painful procedure. If you're reading this article, you probably already know it. Endless hours, labor, and money are invested in this process, which can often result in production breakdown despite the effort to prevent it. CSH by CalCom is automating the entire server hardening process. CHS's unique ability to 'learn' your network abolishes the need to perform lab testing while ensuring zero outages to your production environment. CHS will allow you to implement your policy directly on your production hassle-free. want to know more?

Click here and get the datasheet. 


You might be interested