WEBcnx FAQs

The exact infrastructure used for a WEBcnx installation is largely dependent on scale of use, any existing suitable infrastructure and preference. The following therefore should be used as a guideline, with further information supplied based on your proposed configuration.

Single Site Installation

The most common and straightforward configuration makes use of an existing Impact database server and mail server, and simply adds a new web server configured to run WEBcnx's various components. This web server would typically run WEBcnx, nServer and Licence Server and communicate with the databases and mail server through the Internal Firewall.

WEBcnx is very flexible in where the various component parts are situated and supports combinations from everything installed on a single server to each individual component being installed on their own servers.

Click to preview full-screen in new tab

Software Requirements

WEBcnx

• Microsoft Windows Server 64-bit (version 2016 or later), configured as a Web Server
• IIS 10
• .NET Framework 4.8 running on the server and any clients containing WEBcnx components
• Suitable client database drivers - see Databases

nServer

• nServer compatibility to be confirmed for each WEBcnx release
• O/S requirements to match WEBcnx
• Suitable client database drivers - see Databases

Licence Server

Arden Licence Server is required by nServer, and is therefore typically installed alongside WEBcnx on the web server itself, and has no specific software or hardware requirements*. Should the use of an existing and/or separate Licence Server installation be desired, any network traffic would need to be allowed to flow between the web server and the alternate Licence Server host, as detailed in the relevant KB articles, here.

*Licence Server installations on physical servers may optionally utilise a physical USB dongle.

Databases

WEBcnx connects to the existing Impact database (via nServer) for user, customer, and design data, and to its own database for all task and WEBcnx specific functionality. These two databases are most commonly hosted alongside each other. This isn't necessary, but does simplify the resources needed and is therefore the recommended configuration.

The minimum supported database platform for Arden products follows the Microsoft SQL Server Extended End Date. See here for details. As each version of SQL Server Microsoft's products reach their supported end-of-life, Arden products will similarly cease to support them for subsequent product releases.

• Recommended: SQL Server 2016 / 2017 / 2019 / 2022 - Workgroup, Standard, or Enterprise Edition
• Minimum Supported: SQL Server 2014 (until July 9, 2024)

WEBcnx Plugin

The WEBcnx plugin is installed on each Impact client computer to allow CAD users to access WEBcnx directly from within Impact. This enables Impact to interact with WEBcnx for actions such as creating and opening task linked Projects, as well as allowing the CAD user to update WEBcnx tasks, all without the need to open up their web browser separately. 

• Access to the WEBcnx site
• .NET Framework version as per WEBcnx server

WEBcnx Document Extender

The WEBcnx Document Extender is a utility that can be installed on each Impact client computer to provide CAD users with additional information about any WEBcnx references (aka 'Relationships') between documents and any tasks or Document type WEBcnx Custom Fields. Without this, users will only be able to see that a document has one or external references.

• Access to the WEBcnx site
• .NET Framework version as per WEBcnx server

Internet Browsers/Clients

For information on Supported Browsers, please see here.

Hardware Requirements

Our hardware recommendations are based on a customer's intended scale and nature of use, as determined by their site's configuration and the licensed WEBcnx modules. The following is also based on the assumption that the Web Server is to be dedicated to hosting WEBcnx, and that the nServer component is both installed alongside it, and is also dedicated to  only WEBcnx specific usage.

• CPU (Processor):
  • x86-64 compatible processor (Intel® or AMD®)
  • Up to 25 users*: 4 cores (or logical processors in a VM)
  • 25-50 users*: 6-8 cores…
  • 100+ users*:  12 + 6 cores per 50 users
• RAM (Memory)
  • 3-4 GB per allocated CPU
• Disk
  • SSD or equivalent high-speed disks
  • 25 GB disk space
• Network
  • 1 - 10 Gbps+ network card(s)

*Concurrent user sessions

Optionally:

• GPU**: 
  • nVidia chipset offering OpenGL version 2.1+ compatibility

**For 3D layer thumbnail and Impact report template generation, and to aid LiveProof render performance.

Port Configurations

Below, you can find the ports which need to be open/available for proper functioning of WEBcnx in a single site (non-Enterprise) installation:

• Port 80 (HTTP) from the internet to the WEBcnx Web Server (DMZ)
• Port 443 (HTTPS) from the internet to the WEBcnx Web Server (DMZ)
• Port 80 (HTTP) from the LAN to the WEBcnx Web Server (DMZ)
• Port 443 (HTTPS) from the LAN to the WEBcnx Web Server (DMZ)
• Port 25 (SMTP) from the WEBcnx Web Server (DMZ) to the Mail Server

The following ports are those most typically required for connection to a Microsoft SQL Server hosted Database:

• Port 1433 (TCP) from the WEBcnx Web Server (DMZ) to the Database server
• Port 1434 (TCP) from the WEBcnx Web Server (DMZ) to the Database server

Note. These port configurations are based on Arden Licence Server being located on the WEBcnx Web Server.

Further Reading

• Supported Browsers and Environments
• History of Microsoft SQL Server (external link)

If you can't get as far as the login page, there's a problem with some part of your installation that is preventing the site from loading. This is usually caused by a fault in the site's web.config file.

Symptoms

500 - Internal server error.

There is a problem with the resource you are looking for, and it cannot be displayed.

Cause

The web.config has a section defined in the body of the file but is missing a <configSections> definition. 

In the simplified example below, the <configSections> describes the expected Sections that should exist in the web.config. If one of those Sections exists but there is not a "section name" in the configuration section-handler declaration area at the top of the file (the bit between the <configSections></configSections>). In the example below, the Arden.WEBcnx.Workflow section is missing from the section-handler declaration are but it does exist in the body of the file.

<configuration>
  <configSections>
    <section name="Arden.Core.Data" type="System.Configuration.NameValueSectionHandler/>
    <section name="Arden.WEBcnx.Core" type="System.Configuration.NameValueSectionHandler/>
    <section name="Arden.WEBcnx.Site" type="System.Configuration.NameValueSectionHandler/>
  </configSections>
  
  <Arden.Core.Data>
    <add key="DataReaderReadChunkSize" value="65535"></add>
  </Arden.Core.Data>
  
  <Arden.WEBcnx.Core> 
    <add key="PublicSitesColumnName" value="ST_PUBLIC"></add>
    <add key="nServerLogEnabled" value="true"></add>
    <add key="ApplicationName" value="WEBcnx Panther"></add>
   </Arden.WEBcnx.Core>
   
  <Arden.WEBcnx.Workflow>
    <add key="Enabled" value="true" />
    <add key="WebRequestImpactConnectionName" value="" />
    <add key="WebRequestWEBcnxLoginID" value="" />
    <add key="WebRequestWEBcnxPassword" value="" />
  </Arden.WEBcnx.Workflow>
  
  <Arden.WEBcnx.Site>
  <add key="DefaultImpactConnectionName" value="Demo"></add>
  </Arden.WEBcnx.Site>

Solution

There are two options for fixing this problem. If you're unsure what you are doing, please consult a member of the WEBcnx support team.

1. The section in the configuration section-handler declaration area at the top of the file could be missing because someone has copied the main section from another file and mistakenly forgotten to also include the declaration of this in the configSection. Therefore, adding the missing section to the configuration section-handler declaration area at the top of the file should resolve the problem. You should carefully check that the correct section is added.
2. Someone has attempted to remove an unwanted configSection and having removed the section from the declaration area, they have not removed the section from the body of the file. Remove the erroneous, unreferenced section from the body of the web.config.

Still Not Working

If the above solution has not resolved your problem, you may have found another cause of this error. Please create a support ticket and describe the problem you're having in as much details as you can. If possible, please supply copies of your web.config for analysis.

Further Reading

• web.config

What is an SSL Certificate?

Whenever you view a webpage, you may notice the address starts with http (Hypertext Transfer Protocol). For websites that may use personal or sensitive data, such as your bank or other website you may log into, it's preferable to make these more secure by encrypting data transferred between the client (the web browser you're using) and the server (where the website is installed). This is done using a Secure Sockets Layer (SSL) that is configured on the server. Any website that is secured in this way will display https (Hypertext Transfer Protocol Secure) and display a locked padlock icon on the address bar.

As WEBcnx is an application that users log in to and contains potentially sensitive customer data, it is recommended that you secure it by applying an SSL certificate.

SSL Certificate Authentication Types

Depending on your needs, there are many different types of SSL certificate options available, all with their unique use cases and value propositions. The level of authentication assured by a Certificate Authority (CA) is a significant differentiator between the types. Each type of certificate requires specific information and documentation, and once that is received, a CA follows a set of Baseline Requirements to complete the certificate verification process before issuance.

There are three recognized categories of SSL certificate types:

• Extended Validation (EV)
• Organization Validation (OV)
• Domain Validation (DV)

Within these authentication types, there are also unique variations available including single domain, multi-domain, and wildcard. Which of these you choose depends on how you wish to configure your domain.

Selecting a Certificate

Depending on what type of websites, eCommerce or other web applications you may already have, you may already have an SSL certificate that covers your new WEBcnx installation. An existing Wildcard SSL certificate could be used if you wanted to host WEBcnx as a subdomain of your main corporate domain name; webcnx.yourwebsite.com for instance. If you don't already have any secure websites and are unlikely to need one in the future, a simple Single Domain SSL certificate is what you would need.

Single Domain SSL Certificates

A single domain SSL secures one domain, both the WWW and non-WWW versions. It can also secure a single subdomain, hostname, IP address, or mail server. This variation is available in DV, OV, and EV authentication options. If your WEBcnx site is the only one you need to secure, you should choose this option.

Multi-Domain (MD) or Subject Alternative Names (SAN) SSL Certificates

Also commonly referred to as SAN certificates, multi-domain certificates allow a single certificate to secure multiple domains, including subdomains of a single main domain name or entirely different domain names. One of these can secure up to 250 unique domains with a single solution. They provide a convenient option for organizations that own a lot of domains and are looking for a simplified way to secure them through a single solution rather than purchasing an individual certificate for each. Multi-domain SSL certificates are available in DV, OV, and EV validation options. If you already host a number of secure websites or web applications with different domains, you may already have a suitable SSL certificate that can be easily extended to include WEBcnx. You should discuss with your IT team for more information.

Wildcard SSL Certificates

The Wildcard SSL option is used to secure the main domain and an unlimited number of subdomains under the main domain. For example, www.yourwebsite.com, webcnx.yourwebsite.com, ecommerce.yourwebsite.com, etc., would all be secured with one Wildcard certificate. This type offers full encryption for the subdomains, making it an affordable and effective solution for most websites. They are available in DV and OV validation options. As for Multi-Domain SSL certificates, if you already have other secure websites, you may already have a suitable SSL that can be used. You should discuss with your IT team for more information.

Free vs Paid SSL Certificates

There are a number of free SSL Certificate Authorities as well as those providing paid certificates. All types offer the same level of encryption, so a Single Domain SSL certificate of a Domain Validation type is just as secure as an Extended Validation, Wildcard SSL certificate. Free SSL certificates do not validate ANYTHING about websites, but just the ownership of the domain. On the other hand, paid SSL certificates verify the BUSINESS IDENTITY of the website before issuing the certificate to the site owner. It is an in depth verification carried out by the Internet certificate authority(CA).

If you're hosting WEBcnx for largely internal users who need to be able to access WEBcnx remotely, without having to join a VPN, a free Domain Validation certificate will do the job. If you may have your customers also accessing WEBcnx, an Organization Validated certificate will give them the added reassurance that the WEBcnx site they're connected to truly belongs to you.

A good rule of thumb is this: if the certificate is issued to a company, then it should be one that requires validation of that company – either OV or EV. And anytime there are transactions occurring on a website, an OV or EV certificate should be used to instil confidence in the customer that their data is safe and that they are dealing with who they think they are.

Further Reading

• Installing an SSL Certificate (this is a link to an external resource)
• Configuring WEBcnx to Use an SSL Certificate

Changing a WEBcnx installation to use an SSL certificate requires changes to configuration files that can cause WEBcnx to cease to operate correctly. As such, this work should only be undertaken by a member of the Arden Software support team. Please contact us or raise a support ticket for further assistance.

Further Reading

• Selecting an SSL Certificate

Supported Platforms

WEBcnx is supported on three platforms - Desktop, Android and iOS. In the first two cases, the internet browsers are self-contained and automatically keep themselves up to date without the user typically needing to do anything.

Unfortunately, this is not the case on iOS. Web browsers on iOS are not self-contained, but instead use the engine provided by the Operating System. In simple terms, this means that while users can install Chrome or Firefox from the App Store and get access to those browsers' features, the actual rendering of websites is still done by Safari, the version of which is directly tied into the Operating System. This means that if a user is on an older device which doesn't have access to the most recent iOS updates, they will be incapable of upgrading their browser.

As such, at this point in time our browser support can be broken into two parts:

1. The browsers that we support on Desktop and Android.
2. The minimum supported version of iOS we support.

Supported Browsers

Since Desktop and Android browsers can be kept up to date regardless of operating system, rather than provide an official minimum supported version, we always recommend the most recent version. For whatever reason, if you are running an exceptionally old version of a supported browser, we will detect this at the point of login and inform you that you will need to upgrade (see Using Other Browsers below).

Using Other Browsers

It is worth noting that while we have our list of officially supported and unsupported browsers, there is a long list of other browsers about which we make no comment. Many of these will in all likelihood work just fine, but we do not test against them and therefore cannot formally recommend them.

For example, there are several browsers such as Brave and Samsung Internet which use the same engine as Chrome, Edge and the Impact WEBcnx Plugin - i.e. Chromium. It's likely that these browsers - as long as they're kept up to date - will work, but any functionality, performance or styling issues encountered should first be replicated in an officially supported browser before being reported as bugs.