Many of our on-premise customers have integrated Spira with their Microsoft Active Directory (AD) infrastructure using our LDAP integration option. When they want to move to the cloud, they need to switch their users from LDAP to Single Sign On (SSO) using an Oauth based option such as ActiveDirectory Federated Services (ADFS) or AzureAD. This article describes the process.
We had a customer that was installing Spira (this article applies to SpiraTest, SpiraTeam, and SpiraPlan editions) on a new server that had recently been hardened by their IT department and it would not load Spira or display the login page. After much debugging, the customer helped us realize it was the .NET Trust Level that was the culprit.
Most on-premise Spira and KronoDesk installations will be using the Microsoft Internet Information Services (IIS) Server to serve the application to users. If you are experiencing performance problems or slow page load times (and you cannot move to our cloud version), this article will help you troubleshoot IIS worker process requests.
We had a customer that was using a VPN / Firewall to access our cloud instances of Spira. Most firewalls simply pass through the HTTPS traffic on port 443 unaltered. However some more stringent ones actually decrypt the HTTPS traffic, inspect the packets and then re-encrypt it for the user. In one case, this was causing an ERR_CONNECTION_CLOSED error.
If you are using older ESET Antivirus products (e.g. v6.x) on Amazon Web Services (EC2) Elastic Cloud Compute (EC2) Windows instances (which we use for Spira and KronoDesk) you may not be able to easily upgrade to the latest version of ESET 7.x because ESET 6.5 will block its own un-installation. We have a solution that worked for us that we'd like to share.