Skip to main content
Version: 2024

IIS configuration

Quick reference guide to configuring IIS​

Follow these steps to configure IIS (Microsoft's Internet Information Services):
1. Check - Before you start, check if your systems meet the prerequisites.
2. Application Pool - Create an Application Pool in IIS.
3. Application Pool Identity - Create an Application Pool Identity in IIS.
4. If necessary: Restart the application - Do this every time the application directory has been changed.
5. Security - Take the necessary measures in IIS to protect your application and organization.
6. Performance - Optimize your application's performance with IIS.
If necessary: Troubleshooting

Prerequisites IIS​

A number of prerequisites needs to be met before IIS can be configured for use in the Thinkwise Platform:

RequiredMore information
IISSee the Lifecycle policy for the supported versions.
An IIS version is included with the standard installation of Windows on a server or PC. Different versions of IIS are released with the different versions of Windows. Checking the installed IIS version can be done by typing http://localhost in the web browser, the IIS version screen will then be displayed.
IIS 8 welcome page
IIS 8 welcome page
.NET Framework 4.7See the Lifecycle policy for the supported versions for running an ASP .NET application.
To check which version has been installed: https://docs.microsoft.com/en-us/dotnet/framework/migration-guide/how-to-determine-which-versions-are-installed. If the web server has no .NET Framework or a lower version than supported, then use the following link to install the latest version: https://www.microsoft.com/net/download/thank-you/net472.
Windows Server 2012R2
Windows Server 2012R2

Configuration​

Application Pool​

IIS uses Application Pools to run applications and to make configurations for these applications. By using different Application Pools, it is ensured that web applications can function separately from each other. It also ensures that they are not in the way of each other if an error arises with one of the web applications due to a crash or memory problems. Thinkwise therefore advises that a new pool is made in IIS for each Thinkwise Web GUI or Indicium (used by Universal GUI).

Application Pool Application Pools

  • Name: give the Application Pool a suitable name, related to the corresponding application to which it is going to be connected.
  • .NET CLR:
  • Managed pipeline mode: set this to 'Integrated'.

Add Application Pool Add Application Pool

Press OK to create the Application Pool.

Application Pool Identity​

The Application Pool Identity is also used to access files in the network. This could include, for example, images and icons that the application uses or report files. To do this:

***Advanced Settings > Process Model > Identity ***

  1. Specify a domain user that has rights to the locations of the used files. If access to the network is not needed, then the default identity suffices.

Application Pool Identity Assign Application Pool Identity

(Re)starting the application​

Restarting is necessary after the contents of the Application Directory have been changed or if there are problems with the application. After a restart, the application will start up again with a clean slate, but users will lose the session in which they were working and will need to log in again. Therefore Thinkwise recommends preventing this as much as possible in production environments while users work with the application.

Restarting the application can be done via the Application Pool overview:

  1. Select a pool and click Recycle... in the Actions bar on the right.

Restarting the Application Pool Restarting the Application Pool

Security​

After deploying a web application, it is essential to secure the web environment against hackers and malicious intentions. Users' credentials and available data must be safely sent to the client or back to the web server. Furthermore, the application must not be able to be abused by people who have not been granted access to it. This section will describe which options are available to set up the web environment safely and what Thinkwise does in the application to enable users to work safely with the web application.

HTTPS​

HTTPS or SSL encryption ensures that all information sent via the internet between the web server and the client is sent encrypted. Therefore, it is not possible to see the sent information during the transport. The information may contain user credentials or data from the database.

More information about HTTPS is available via this link: http://en.WIKIpedia.org/WIKI/HTTP_Secure

Thinkwise strongly recommends to always use HTTPS. An URL Rewrite rule can redirect users from HTTP to HTTPS automatically.

HTTPS Certificates​

HTTPS works with a certificate that is installed on the web server. An HTTPS certificate is connected to the URL with which the application is going to be accessed. If the URL is not yet available, it should first be requested. For external access to the application, a domain name is needed, for example, <www.thinkwisesoftware.com>.

There are various providers of SSL certificates with various options and prices. There is a choice of:

  • Type of validation:
    1. Domain name validation
    2. Organization validation
    3. Comprehensive validation
  • Type of certificate:
    1. Single domain name certificate
    2. Multiple domain names certificate
    3. Wild card certificate
  • Lifespan in years
note

Please note that the certificate is extended in good time in order to prevent cancellation.

The certificate is linked to the URL with which the user can access the web application. Usually, port 443 of the web environment is used to access the web application through HTTPS.

Connecting the certificate to the URL is done in IIS by right-clicking on the website in which the web application has been placed and choosing Edit Bindings… .

Edit bindings Edit bindings…

Normally, one binding has already been specified for a website. This refers to the HTTP type with the IP Address *. This is meant to test the application locally on the web server without HTTPS after deployment.

If a binding is changed or added, the dialogue below will appear. In this dialog, the properties of the web application can be specified in order to access this application externally via the internet. At the bottom of this pop-up, the SSL certificate that has just been installed is chosen. Now, the certificate is connected to the web application's URL and the application can be accessed via HTTPS.

Edit site bindings Edit site bindings

Security headers​

Universal GUI

There are several security headers that web servers can return to browsers to prevent or limit certain capabilities that malicious users could exploit.

tip

Since Indicium is a web application, it sets these headers to the appropriate values itself. For Indicium, further configuration is not necessary.

However, the Universal GUI is served as static content from a web server. For this reason, it cannot set any headers. Therefore, we recommend configuring the web server to set these headers on the static content requests of the Universal GUI as well.

  • Do not use the X-XSS-Protection header. Read the warnings in the link. It is an old security header that comes with its own risks, for deprecated browsers.

  • The X-Frame-Optionsheader should be returned with the value SAMEORIGIN. It ensures that your Universal GUI cannot be embedded in an iframe on another website. This prevents click-jacking attacks that trick the user into clicking on the wrong link and potentially leaking sensitive information. When configured correctly, every request for Universal GUI assets will include X-Frame-Options: SAMEORIGIN in its response headers.

  • The Referrer-Policy header should be returned with the value same-origin. This ensures that the Referer request header, which can contain sensitive information, can only be included in requests to the same site. When configured correctly, every request for Universal GUI assets will include Referrer-Policy: same-origin in its response headers.

  • The X-Content-Type-Options header should be returned with the value nosniff. This ensures that the browser always respects the Content-Type response and does not try to infer the content type from the response data itself. When configured correctly, every request for Universal GUI assets will include X-Content-Type-Options: nosniff in its response headers.

When serving the Universal GUI from IIS, you can configure all of these headers in the web.config file:

<system.webServer>
  …
  <httpProtocol>
    <customHeaders>
      <add name="X-Frame-Options" value="SAMEORIGIN" />
      <add name="Referrer-Policy" value="same-origin" />
      <add name="X-Content-Type-Options" value="nosniff" />
    </customHeaders>
  </httpProtocol>
  …
</system.webServer>
warning

If the Universal GUI is in the root of the web server and Indicium is a child application, Indicium inherits the custom headers listed in the web.config. This will cause duplicate headers in the Indicium application which might cause issues. You can remove them by adding <remove name="X-Frame-Options" /> and the other custom headers in the Indicium web.config file.

Aside from adding these important security headers, it is also important to remove certain standard response headers that can leak information that attackers might use to exploit vulnerabilities.

  • The Server response header leaks the type of web server on which an application is hosted. Attackers can use this information to focus their attention on vulnerabilities of that type of web server.
  • The X-Powered-By response header leaks the web technology an application uses (e.g., ASP.NET). Attackers can use this information to focus their attention on vulnerabilities of that web technology.

You can remove these headers in the same section of the web.config file:

<system.webServer>
  …
  <httpProtocol>
    <customHeaders>
      <remove name="Server" />
      <remove name="X-Powered-By" />
    </customHeaders>
  </httpProtocol>
  …
</system.webServer>

Content Security Policy header​

Universal GUI

The Content Security Policy header (CSP) is a header that prevents certain types of attacks, such as cross-site scripting. The CSP prevents these attacks by only allowing content to load from web domains that are specified in your CSP. For example, loading the Map component will only work if the URL is whitelisted in the CSP header.

Setting up the CSP header requires knowledge of the features you are using in your application. The Universal GUI is served as static content, so to enable this header, you must configure it for your web server.

warning

A CSP header can cause some parts of your application to not work as expected if not configured properly.

Enable the CSP header​

To enable the CSP header for the Universal GUI:

  1. Open your web.config.

  2. Find the customHeaders section.

  3. Add the following line to the customHeaders section:

    <add name="Content-Security-Policy"
         value="default-src 'self';
                script-src 'self';
                style-src 'self' 'unsafe-inline' https://fonts.googleapis.com;
                object-src 'none';
                connect-src 'self' https://o70260.ingest.sentry.io; 
                font-src 'self' data: https://fonts.gstatic.com;
                img-src 'self' data: blob:;
                base-uri 'self'; 
                frame-src 'self';
                manifest-src 'self';
                media-src 'self';
                worker-src 'self';" />

The basic settings for the CSP header are now enabled. Configure the CSP header if necessary.

Configure the CSP header​

Depending on your application requirements, you may need to make some changes to the CSP header settings.

warning

If the Universal GUI is in the root of the web server and Indicium is a child application, Indicium inherits the custom headers listed in the web.config. This will cause duplicate headers in the Indicium application which might cause issues. You can remove them by adding <remove name="X-Frame-Options" /> and the other custom headers in the Indicium web.config file.

To configure the CSP header settings:

  1. Open your web.config.
  2. Find the Content-Security-Policy in the customHeaders section.
  3. If Indicium is hosted on a different domain than the Universal GUI, add the domain of Indicium to the connect-src and img-src directives.
    For example, if the Universal GUI is hosted on https://universal.thinkwise.app and Indicium is hosted on https://indicium.thinkwise.app, the values are:
DirectiveValue
connect-srcconnect-src 'self' https://o70260.ingest.sentry.io https://indicium.thinkwise.app;
img-srcimg-src 'self' data: blob: https://indicium.thinkwise.app;
  1. If you use the Maps component, add additional entries to the img-src directive.
    For example, if you use the OpenStreetMap tile server, you will need to add https://*.tile.openstreetmap.org to the img-src directive:
DirectiveValue
img-srcimg-src 'self' data: https://*.tile.openstreetmap.org;

The URL for your tile server might be different. In that case, add its value to base-url. You can find the Base layer URI in the Software Factory in the menu User interface > Maps > Base layers.

  1. If you use the Previewer with the URL control, add the URL of the previewer to the frame-src directive. For example, if you are hosting Universal on https://thinkwise.app and want to be able to include something from a different domain, add https://example.com to the frame-src directive:
DirectiveValue
frame-srcframe-src 'self' data: https://example.com;

  1. If you use the Barcode scanner:

    • The standard Barcode scanner requires the use of wasm-eval:
    DirectiveValue
    script-srcscript-src 'self' wasm-eval;
    • The Cortex barcode scanner control requires the use of unsafe-eval:
    DirectiveValue
    script-srcscript-src 'self' unsafe-eval;

    The Cortex barcode scanner control requires the use of unsafe-eval in the script-src directive. This is because the barcode scanner uses the eval function to execute the code that is returned by the barcode scanner. It is a known limitation of the barcode scanner control. If you do not use the barcode scanner control, you can remove the unsafe-eval from the script-src directive.

  2. If something is not working, open the developer tools in your browser and check the console for errors that look like this:

    Refused to evaluate a string as JavaScript because 'unsafe-eval' is not an allowed source of script
    in the following Content Security Policy directive:  "script-src 'self'".

    The error above indicates that something is trying to use eval to execute code. In this case, this happened because of the Cortex barcode scanner control.

More information about CSP can be found on the Mozilla Developer Network

Additionally, certain features of the platform might require additional CSP headers.

HSTS header​

The HTTP Strict-Transport-Security response header can be used by servers to signal modern browsers to access a domain only through HTTPS. Configuring your site to return this header makes it more secure than with only HTTP to HTTPS redirection enabled. The reason is that after receiving the response header, browsers will know to change HTTP requests to HTTPS client side. This can decrease the chance of man-in-the-middle attacks between the client and server.

In the latest versions of IIS, you can configure HSTS through the manager UI:

Site HSTS settings in IIS Manager HSTS settings for a site

note

HSTS should ideally be configured on your infrastructure's gateway/reverse proxy server level. Not doing so can result in unexpected issues. For example, when enabling the Redirect Http to Https option on a site that is also using the Application initialization module, the initialization request might not work correctly because it will be sent through HTTP instead of HTTPS.

For older IIS versions and more examples of how to properly configure the HTTP to HTTPS redirect, please refer to this site.

warning

Technically, enabling the preload function is required for full protection against man-in-the-middle type attacks. Without it, browsers can potentially still make an initial connection through HTTP before receiving the HSTS header. However, to use this option, the site domain must be registered in a hard-coded list used by the browsers. Be sure to read what is required to make this work before enabling it: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Strict-Transport-Security#preloading_strict_transport_security

Session timeout​

When the session timeout has expired which, by default, is at 20 minutes, the user is automatically logged out. The timeout takes effect from the moment that the user stops clicking within the application. The session timeout can be set up in the IIS manager. This is done as follows:

  1. Choose the correct website where the timeout has to be changed.
  2. After selecting the website, click on the Session State option.
  3. After adjusting the time, click on Apply on to implement the new timeout.

Session timeout

Session timeout Setting up the session timeout

Performance and tuning​

Compression​

In order to limit the data traffic and, by extension, improve the performance, we strongly advise that Dynamic Content Compression is turned on in IIS. Less data traffic means that the end user will be able to see the result of the executed action more quickly. This functionality must first be installed before it can be used. This can be done by enabling it in Windows Features.

Dynamic Content Compression enabled Dynamic Content Compression enabled

After installing the Dynamic Content Compression, the functionality in IIS can be turned on for specific applications.

Compression button

Ensure that both dynamic and static compression are on. Then restart the Application Pool.

Compression Compression

For Static compression, it can be further specified wat and how much may be compressed. The default settings are sufficient for Thinkwise applications.

Idle time of the Application Pool​

By default, IIS stops an Application Pool if it is not used for more than 20 minutes. This Idle time setting can be set on 0 to turn this off. This is especially important for mobile devices with offline data. If the service layer can go off, then the application has lost its memory and thus also its caches.

Thinkwise advises that the Idle time is set on 0 because the first user who accesses the application after this will always have to wait for the application to start up. Depending on the size of the application, this extra waiting time can vary from half a minute to two minutes.

This can be set up on the Application Pool in IIS via Advanced settings > Process model > Idle Time-out.

Automatic recycling of the Application Pool​

By default, IIS recycles an application every 1740 minutes (29 hours) in order to prevent potential problems in the application or server. This means that logged-in users will lose their session and have to log in again. Thinkwise advises that recycling be done at a fixed time, for example, daily or weekly at 03:00.

info

Why 29 hours? Wade suggested 29 hours for the simple reason that it is the smallest prime number over 24. He wanted a staggered and non-repeating pattern that does not occur more frequently than once per day. In Wade's words:'you don't get a resonate pattern'. The default has been 1740 minutes (29 hours) ever since! (Source: https://weblogs.asp.net/owscott/why-is-the-iis-default-app-pool-recycle-set-to-1740-minutes)

This setting can be configured by clicking on the Application Pool in IIS and then right-clicking on the Recycling button.

Recycling settings Recycling settings

Application initialization​

After a manual or automatic recycle of the Application Pool, IIS provides various Application Initialization options to prepare and "warm up" the application before the first user sends a request. This way, the first request is just as fast as all other requests. You can enable the Application Initialization feature through Windows Features.

https://weblog.west-wind.com/images/2013Windows-Live-Writer/Use-IIS-Application-Initi.NET-Apps-alive_14732/WindowsFeatures_2.png Enable Application Initialization

See http://www.iis.net/learn/get-started/whats-new-in-iis-8/iis-80-application-initialization for more information. Recycle the Application Pool in order to use the changes.

Start mode​

On the Application Pool, the Start Mode can be set up on AlwaysRunning instead of OnDemand.

Preload​

On the application in IIS, Preload enabled can be set up on True instead of False.

When enabled, a new Application Pool is started after a recycle and, when this is done, the old pool is stopped. In this way, active users do not need to wait for very long before they can continue. Via Windows' Task manager, what happens to the Application Pools during a restart process can be seen by keeping an eye on the w3wp.exe processes.

Troubleshooting IIS deployment​

Errors that have occurred can be found in the Windows Event Viewer in Windows Logs > Application.

Was this page helpful?