Overview

By default, SupportSoft installer creates a single website and multiple virtuals (sub-pages) for admin (/sdcadmin), user (/sdcxuser), and content authoring (/sdccontent) portals.

However, you can reconfigure your SupportSoft in IIS to use three separate sites to access admin, user, and author portals (eg: due to your specific security setup using Microsoft AD for SSO).

After upgrading, you are getting "HTTP 500 Internal Server Error" when trying to access the separate sites, but you are able to log in just fine when trying to access the modules from the sub-pages.

Solution

Use case description

There might be cases when you prefer to add an additional layer of separation to your SupportSoft portals, by publishing them as separate Web Sites under IIS.

Eg: Admin portal as an Admin website, the Content Authoring portal as Author website, and User Management as User portal, while the actual deployment is still under the Default Web Site (or any other Web Site). So your deployment would look something like this in IIS.

In such cases you are able to access, for eg. the Admin portal using two URLs:

• admin.yourservername.com - this would be published for the users
• yourservername.com/sdcadmin - this might not be published for the users.

However after an upgrade, you might be getting "HTTP 500 Internal Server Error" when trying to access the Admin website (admin.yourservername.com), but still, be able to access the admin portal correctly on the default (out of the box configuration) yourservername/sdcadmin.

Root Cause

This issue can be a result of that the SupportSoft installer is prepared out of the box only for using one website for all portals. This is why, when upgrading, the configuration of the non-default additional websites in IIS might get broken (eg: when the installation directory changes).

Possible Solutions

Verify and update the settings of the websites

This can be solved by verifying the following settings of the three separate websites:

• bindings - verify the bindings of the websites. They should be still be bound to their respective hostnames. eg: for admin portal admin.yourservername.com
• virtual applications - the virtual applications within the websites should point to the correct physical path (the new install/upgrade location). Eg: within the Admin website the sdcadmin virtual application should point to the correct physical install location.
• 

Bind the hostnames of the website to the default website

An alternate solution would be to bind all three hostnames to the Default Web Site, and remove the separate portal-specific websites. In that case, the binding of the Default Web Site would look something like this:

In this case, you might lose some host-specific IIS features, or you might need to update your security settings eg. when using Microsoft AD as SSO in a host/domain-specific way.

Testing

After updating your websites settings (bindings, physical paths), or moving all bindings to one website, you should be able to access correctly /sdcadmin, /sdcxuser, and /sdccontent.

Back to the top