WebGIS Discussions

[shaun.falconerinter…]

GeoMedia WebMap / Geospatial Portal instance.

Setup with an WMS, WMPS, 2xGeoRSS, 2xWFSG.

All going well until make minor change, save new portal workspace and go to assign to the Geospatial Portal instance. 

Throws error: 

Invalid JSON primitive: The.

If I try and assign the portal instance an simple overview map I get:

The creator of this fault did not specify a Reason.

If I try to configure the portal instance I get:

ERROR SUMMARYException occured.MOST LIKELY CAUSES:

• Service instance settings were modified manually and they are not correct.
• Server settings are being modified by another user.
• Configuration Service is not operating correctly.

THINGS YOU CAN TRY:

• Please ensure that service instance settings are correct.
• Please ensure that You are the only person modifying the server settings.
• Please contact the administrator.
• Please verify, if there are no errors reported in Configuration Service logs.

C:\Program Files\Common Files\Hexagon\Administration Console Service\log:

2016-11-19 00:11:02,851 [21] ERROR ErrorHandler [(null)] - The service encountered an unhandled exception
System.ServiceModel.Security.MessageSecurityException: The HTTP request was forbidden with client authentication scheme 'Anonymous'. ---> System.Net.WebException: The remote server returned an error: (403) Forbidden.
at System.Net.HttpWebRequest.GetResponse()
at System.ServiceModel.Channels.HttpChannelFactory`1.HttpRequestChannel.HttpChannelRequest.WaitForReply(TimeSpan timeout)
--- End of inner exception stack trace ---

Server stack trace:
at System.ServiceModel.Channels.HttpChannelUtilities.ValidateAuthentication(HttpWebRequest request, HttpWebResponse response, WebException responseException, HttpChannelFactory`1 factory)
at System.ServiceModel.Channels.HttpChannelUtilities.ValidateRequestReplyResponse(HttpWebRequest request, HttpWebResponse response, HttpChannelFactory`1 factory, WebException responseException, ChannelBinding channelBinding)
at System.ServiceModel.Channels.HttpChannelFactory`1.HttpRequestChannel.HttpChannelRequest.WaitForReply(TimeSpan timeout)
at System.ServiceModel.Channels.RequestChannel.Request(Message message, TimeSpan timeout)
at System.ServiceModel.Dispatcher.RequestChannelBinder.Request(Message message, TimeSpan timeout)
at System.ServiceModel.Channels.ServiceChannel.Call(String action, Boolean oneway, ProxyOperationRuntime operation, Object[] ins, Object[] outs, TimeSpan timeout)
at System.ServiceModel.Channels.ServiceChannelProxy.InvokeService(IMethodCallMessage methodCall, ProxyOperationRuntime operation)
at System.ServiceModel.Channels.ServiceChannelProxy.Invoke(IMessage message)

Exception rethrown at [0]:
at System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage reqMsg, IMessage retMsg)
at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type)
at Intergraph.AdministrationConsole.Service.Nodes.SDIPortal.ServiceReference.IConfiguratorService.GetNodes(String path, Int32 depth)
at Intergraph.AdministrationConsole.Service.Nodes.SDIPortal.ServiceReference.ConfiguratorServiceClient.GetNodes(String path, Int32 depth)
at Intergraph.AdministrationConsole.Service.Nodes.SDIPortal.SDIPortalNode.GetChildren()
at Intergraph.AdministrationConsole.Service.Nodes.Core.NodeTree.<GetNodes>d__a.MoveNext()
at Intergraph.AdministrationConsole.Service.Nodes.Core.NodeTree.<GetNodes>d__a.MoveNext()
at Intergraph.AdministrationConsole.Service.Nodes.Core.NodeTree.<GetNodes>d__a.MoveNext()
at Intergraph.AdministrationConsole.Service.Nodes.Core.NodeTree.<GetNodes>d__a.MoveNext()
at Intergraph.AdministrationConsole.Service.Nodes.Core.NodeTree.<GetNodes>d__3.MoveNext()
at System.Linq.Enumerable.WhereSelectEnumerableIterator`2.MoveNext()
at System.Linq.Enumerable.FirstOrDefault[TSource](IEnumerable`1 source)
at Intergraph.AdministrationConsole.Service.Nodes.Core.NodeTree.GetNode(String path)
at Intergraph.AdministrationConsole.Service.AdministrationConsoleService.GetNode(String path, Int32 depth)
at SyncInvokeGetNode(Object , Object[] , Object[] )
at System.ServiceModel.Dispatcher.SyncMethodInvoker.Invoke(Object instance, Object[] inputs, Object[]& outputs)
at System.ServiceModel.Dispatcher.DispatchOperationRuntime.InvokeBegin(MessageRpc& rpc)
at System.ServiceModel.Dispatcher.ImmutableDispatchRuntime.ProcessMessage5(MessageRpc& rpc)
at System.ServiceModel.Dispatcher.ImmutableDispatchRuntime.ProcessMessage41(MessageRpc& rpc)
at System.ServiceModel.Dispatcher.ImmutableDispatchRuntime.ProcessMessage4(MessageRpc& rpc)
at System.ServiceModel.Dispatcher.ImmutableDispatchRuntime.ProcessMessage31(MessageRpc& rpc)
at System.ServiceModel.Dispatcher.ImmutableDispatchRuntime.ProcessMessage3(MessageRpc& rpc)
at System.ServiceModel.Dispatcher.ImmutableDispatchRuntime.ProcessMessage2(MessageRpc& rpc)
at System.ServiceModel.Dispatcher.ImmutableDispatchRuntime.ProcessMessage11(MessageRpc& rpc)
at System.ServiceModel.Dispatcher.ImmutableDispatchRuntime.ProcessMessage1(MessageRpc& rpc)
at System.ServiceModel.Dispatcher.MessageRpc.Process(Boolean isOperationContextSet)

Next tried full uninstall / uninstall of WebMap - failed badly. Claims it is trying to uninstall an component that was not insalled - looks like something to do with AdminPortal.

I've restored the server back to good known point, rebuilt all the content and reapplied. Ended up with same problem again. Don't know how.

Ideas?
Field crews heading out in 7hrs expecting the site to be up. 

[Colin.Bertram]

I have experienced the same issue when attempting to set a starting workspace for an instance. The easiest workaround is to grab the ID of the workspace and edit App_Data\configuration file of the Portal instance using a text editor to specify the starting workspace.

Its good to hear I'm not the only one who's experienced.

[shaun.falconerinter…]

Thanks Colin,

I got a temporary workaround in place by using a redirect to full.aspx.gpw=xxxxx.

Your idea sounds better - will try it when I'm a bit more awake.

[lukasz.baraniak]

The Admin Console Service log excerpt suggests that there is something wrong going on in the communication between itself and a Geospatial Portal instance. Specifically, the AdministrationService.svc endpoint each Geospatial Portal instance has exposed is refusing to connect using the anonymous HTTP authentication scheme, although most of the time I see an indication of the allowed authentication schemes in the fault response.

In my experience this is easily fixed by allowing anonymous authentication on the AdminService subfolder of your Geospatial Portal instance's application in the IIS manager. To be safe, enable anonymous and disable any other, and check IIS Authorization Rules and .NET Authorization Rules for whether all users are allowed. Don't worry, the AdministrationService.svc has its own security in place to prevent unauthorized modifications:

You might notice that in the .NET Authorization rules I have two Allow All Users entries. I'm not sure if it's a glitch, or I have it defined the same way on two levels of the hierarchy somewhere, but it works

Remember also, the Admin Console Service communicates with the AdministrationService.svc endpoint for both the currently configured instance of a Geospatial Portal AND the AdminPortal instance as well. So both need to have this set up the same:

[shaun.falconerinter…]

thanks for the idea, unfortunetly no go so far. My Authentication settings appear to match yours.

AdminPortal:

And the Geospatial Portal site:

[shaun.falconerinter…]

Just realised I showed screen shots of the portal level rather than the portal\AdminService level.

Note: After I restored the server, I ran into the problem again when the portal was still setup as anonymous, basic authentication was introduced after the problem occurred. So at this point I don't think basic authentication on the portal is the problem.

Screen shots for the portal\adminService

[lukasz.baraniak]

You haven't shown the adminportal/Admin service settings but I assume you checked those as well or haven't made configuration changes there so they should inherit nicely. The Portal's asminservice's security is based on the assumption that only request originating from the local machine are allowed. Since the exception logged in the admin console service log doesn't contain a hint of a list of allowed authentication methods and simply reads 403 forbidden, I'm shooting for an infrastructure configuration which interferes with the security mechanism (I needed some time to crunch through the unusual error message). My guess is that when the admin console service fires a request against the asminservice of a portal (be it the one you are configuring or the admin portal), it is actually routed through an external IP. Would I be correct to say that you have some kind of a reverse proxy in place and have used the host name overrides functionality?
If that's the case, adding the external host name to the hosts configuration file in Windows on the node in question and making it map to the loop back IP should make things running smoothly.

Or, you can use Colin's workaround still ;-)

[shaun.falconerinter…]

It is an Amazon server, and I think there are some interesting network setup somewhere along the line. Not sure how the proxies work in that environment.

There is no public name for the service, simply using IP address for everything.

However I did just try pinging the public IP address on the server and it timed out.

So that might be a lead.

however we have been using same config for a number of years, so bit surprised it broke now - but something could have changed.

I have deployed Colins suggestion and have main portal and mobile portal working fine.

Configuration still throws error, so can't add/configure a new site etc.

[shaun.falconerinter… · Accepted solution]

Finally got it.

Earlier on Friday I had changed the 'Hostname aliases' to the external IP address of the server.

Otherwise Consumer Portal WMPS search would not resolve externally and Consumer Portal wouldn't work.

Later in the day I modified the portal workspace and assigned to portal and it failed.

I didn't associate the setting of the host name to public IP address with the problem :<

I've changed the public hostname to another name that now resolves internally and externally and it all seems to be working now.

I basically knew about the public name issue - it just didn't occur to me the public IP address wouldn't resolve internally and that was what the error was about.

Thanks for the tip.

[lukasz.baraniak]

Network settings can play such tricks on you. Especially if they affect multiple components without obvious intertwine conditions.
I wonder if the internal communication of the administration console service and the Portal administration endpoint should have even been made to depend on the host name setting. It should always hit it through the loop back interface but there might be iis configurations which could prevent simply going over localhost.
I'm pretty sure there is some proxying going on in your case behind the scenes since going through the ip address resulted in a trip outside the node. Another trick would be to manipulate the windows ip routing table if you really need to use the ip number as the host name. This should work also for a reverse proxy scenario.
Anyways, great you have it solved, Shaun! :-)