The following steps must be performed before installing Intrexx 18.09 or
when updating an older version of Intrexx to ensure that Intrexx 18.09
1. Web server configuration
Every Intrexx portal needs to be accessible via HTTP, or rather every
productive portal needs to be encrypted and accessible via HTTPS.
For this reason, a web connector (an embedded Apache Tomcat) runs in every
portal instance that provides the HTTP interface. There are different options
for providing a portal available with HTTP(S). Multiple portals can
be operated with the same protocol, host name and port but a different
path or virtual directory, such as:
This option is prone to errors and raises
It is therefore not recommended.
Depending on the operating system and user account, which the portal service
is operated with, the portal's web connector can use the HTTP default
port (443, unencrypted 80). By default, Intrexx suggests non-privileged ports (> 1024).
Standalone means that clients connect to the portal directly via the
portal's web connector.
All static and dynamic resources are delivered to the clients by the
The web connector is responsible for the transport encryption.
Each portal requires a freely selectable combination of a host name
or IP address (binding address) and a port..
To run multiple standalone portals on one server, there are various
configuration options available:
The same host name, the same binding address, but different ports, such as
An additional IP address is configured on the operating system, the assignment
of the host name via DNS (A or AAAA record).
1.2. Portal with an upstream reverse proxy or load balancer
Nginx, Microsoft IIS with ARR, HAProxy, Apache Traffic Server, or similar,
come into question as an upstream proxy.
Optionally, static resources can be delivered by the front-end server (proxy).
The front-end server is normally responsible for the transport encryption.
Communication between the front-end server and the Intrexx portal service
is usually unencrypted.
The Intrexx web connector cannot be accessed directly from outside. It listens
to the loopback interface or (on distributed servers) has an IP address that
clients cannot access.
With an upstream front-end, any number of portals can be hosted virtually
(with the standard port). The server only requires an IP address as well as an
A, AAAA or CNAME record in the DMS for each virtual host, such as
Tomcat is included in the portal service in Intrexx Version 18.09 or higher
and is automatically started when the portal service
is started. Typically, you can access your portal in the browser via the
base URL https://localhost:1337. Each portal has its own Tomcat configuration.
An upstream web server is not absolutely necessary.
3. Multiple portals under one address / Integrated authentication
If you want to use integrated Windows authentication or Kerberos authentication
on a server that operates multiple portals, the Microsoft
Internet Information Server needs to be implemented as a reverse proxy.
This is the only way to implement the required authentication.
The following guide shows you how you can operate multiple portals on one
server while continuing to use integrated authentication.
3.1. Install ASP.Net
To install ASP.Net / ARR, please activate
Windows Features / Internet Information Services / World Wide Web Services / Application Development Features / ASP.NET 4.5 (or higher)
before creating a portal.
Apply all suggested additional features such as ISAPI Extensions, ISAPI Filters
and the .NET Extensibility.
3.2. Install the ARR module
to download the IIS Web Platform Installer (WebPI 5.0 or higher) and execute the installation.
Once the installation is completed, start the Internet Information Services
Manager. Select your server and start the Web Platform Installer
that is now available in the administration.
Search for "routing" and install the module "Application Request Routing 3.0".
Please make sure not to install the older version (2.5).
3.3. Activate reverse proxy
Select "Application Request Routing" at the server level in the IIS Manager.
On the right-hand side, select "Server Proxy Settings".
Activate the setting "Enable proxy".
In addition, the option "Reverse rewrite host in response headers" needs
to be deactivated. Otherwise the Intrexx OAuth2 SSO redirect will no
longer work because the IIS automatically writes the IIS host name in the
location header instead of the external host.
Save the changes by clicking on "Apply" on the right.
3.4. Install portal with IIS support
If the internal Tomcat is set to port 1337 (default for new installations), the
portal should be accessible in the browser as usual after the
portal installation with
The Internet Information Server can be selected as the front-end web server
at a later point in the
3.5. Automatic transfer during update
During an update, the Windows authentication is automatically activated
or transferred if the portal was already run with Windows authentication.
In this case, the Service Principal Names for the
It's not always the case that a completely trouble-free installation
of the Internet Information Server connector is guaranteed.
The following provides a description of the most common causes of error
and potential solutions.
3.6.1. Switch portal to Windows authentication after installing Intrexx without IIS support
Because the manual integration of the IIS connector is very complex
and prone to errors, we recommend the following approach:
Reinstall with IIS support (automatically preselected)
Import the portal
Switch the authentication
3.6.2. Port is already in use
Check the port allocation. A portal can only be accessed when it is
accessible via the default port 443 (for HTTPS). When setting up the
ARR module in the IIS, this connection is defined accordingly.
If this port is already in use from a different software product
or set-up website, then a connection to the portal is not possible.
To check whether another product is using the port, proceed as follows:
Open the command line.
Enter the command
c:\> netstat –anop tcp
If you receive an entry in the format
Local Address: "0.0.0.0:443" State:"LISTENING"
then you know that the port is already in use.
To find out which program is using this port, you need to search for
the process with a suitable tool (e.g. Process Explorer from Sysinternals).
This process is stated in the PID column in the results of the netstat command.
3.6.3. Incorrectly configured application pool for the virtual website
In the IIS Manager, check the used application pool for your portal.
Proceed as follows:
Open the IIS Manager
Open the entry "Default Website" in the tree
Right click on the entry for your portal and select
"Manage Application / Advanced Settings"
Note the name of the defined application pool (e.g. "DefaultAppPool" in this case)
Open the "Application Pools" node in the tree
Check the following settings:
.Net CLR Version: At least version "v4.0" should be defined here.
Managed Pipeline Mode: The option "integrated" should be defined here.
3.6.4. Windows authentication: Tomcat filter not yet activated
To use Windows authentication in the portal as well as for Single Sign On
for the connectors, a filter must be activated in the web.xml file. This can
be found in the portal directory
external/htmlroot/WEB-INF. This filter is usually activated automatically
as soon as Windows authentication has been activated.
Open the file with a suitable editor (e.g. Notepad++)
Search for the term "External Authentication Filter".
<filter-name>External Authentication Filter</filter-name>
This property is used to enable or disable the filter.
IMPORTANT: For compatibility reasons the default value of this property
is true for the External Authentication Filter.
Values: true (default) or false.
Modify the line
Save the file.
Restart the portal service.
3.6.5. Kerberos authentication for connectors: Tomcat filter not yet activated
When using connectors with the Kerberos authentication, an additional filter
is required that in some cases needs to be added to the web.xml file manually like
in the step above:
Open the file with a suitable editor (e.g. Notepad++)
Search for the term "connector.portalserver.additionalHeaders"