Ungatewayed portlet requests have no portal settings

Question

Hello,
I'm getting the following error when hitting search to search in our staff directory. Anyone know what's going on?
Ungatewayed portlet requests have no portal settings.
Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code.
Exception Details: Plumtree.Remote.Portlet.NotGatewayedException: Ungatewayed portlet requests have no portal settings.
Source Error:
Line 48: context = PortletContextFactory.CreatePortletContext(HttpContext.Current.Request, HttpContext.Current.Response)
Line 49: groupID = CInt(context.GetRequest.GetSettingValue(SettingType.Admin, GROUPNAME))
Source File: xxxxxxxx\AppPage.vb Line: 49
Stack Trace:
[NotGatewayedException: Ungatewayed portlet requests have no portal settings.]
Plumtree.Remote.Portlet.PortletRequestWrapper.GetSettingValue(SettingType type, String name) +204
xxx.PTL.StaffDirectory.Web.AppPage.isAdmin() in xxxxxx\xxx.PTL.StaffDirectory.Web\AppPage.vb:49
xxx.PTL.StaffDirectory.Web.StaffSearch.AddIncludeTerminatedRow(Int32 controlIndex) in xxxxxxxx\StaffSearch.aspx.vb:285
xxx.PTL.StaffDirectory.Web.StaffSearch.LoadLOVs() in xxxxxxxx\StaffSearch.aspx.vb:188
xxx.PTL.StaffDirectory.Web.StaffSearch.Page_Load(Object sender, EventArgs e) in xxxxxxxx\StaffSearch.aspx.vb:76
System.EventHandler.Invoke(Object sender, EventArgs e) +0
System.Web.UI.Control.OnLoad(EventArgs e) +127
System.Web.UI.Control.LoadRecursive() +92
System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint) +3360
Version Information: Microsoft .NET Framework Version:2.0.50727.3603; ASP.NET Version:2.0.50727.3614

Answer 1

Hello and thank you for your response. This is a custom application through a remote portlet. It is a popup window where this error occurs. The weird thing is that it works on another server but not this particular one where I need to get it working on.
The Gateway URL Prefixes are all set to the application server. I'm sure that this is correct as it is working like this on our production environment. The difference is that the app was .NET 1.1 on Portal 6.1 and now it is .NET 2.0 on Portal 10.3.
Is it possible that something was missed during the Portal upgrade to 10.3? If yes, do you have any idea what it could be?