DMZ permanent standby Scripts not running in ViewX or Virtual ViewX but are in WebX

[geoffpatton]

Just wondering if anyone else has seen this. I have not looked into it much or contacted support yet.

I just noticed on a customer's system that their scripts are not running on their DMZ permanent standby from ViewX or Virtual ViewX but they work fine in WebX.

The customer has not complained I think it is because they don't really use the only script that really can do anything on a DMZ server. The script creates a menu navigation that is dynamic so that when screens are added in the database they automatically get added to the menu. I think the users always use other navigation buttons on the screens so they have not noticed. There are some screens you have to use the menu to access but they are not used by the average Virtual ViewX client user.

We recently migrated them to Virtual ViewX and they still have the WebX licensing active. So I checked if WebX was working since scripting uses the same connection. I honestly thought that was where the problem was and WebX would not load but it loaded, I logged on. and successfully ran the script from the WebX connection to the DMZ server.

[AdamWoodlandToo]

My first guess would be that the port configured to inform the ViewX clients what port WebX/scripting runs on is incorrectly defined in Server Configuration on the DMZ server. Possibly a hangover from when IIS was installed infront of DBServer as part of the upgrade to a more recent version.

WebX can just use the port the user puts in the URL for both mimic content and scripting, but with ViewX (and Virtual ViewX) the server needs to tell ViewX as it can't use 5481 for the scripting part and since IIS is now in front of DBServer it doesn't know and so someone needs to make sure DBServer is configured with the port.

In Geo SCADA 2023 it is System Configuration -> WebX -> Local Proxy. Make sure they align with what IIS is running as (use 0 if either port is not configured in IIS)

[geoffpatton · Accepted solution]

Adam, That was not the problem.

I checked that the IIS ports matched up with the Configuration Ports.

I also verified there is nothing else running that would be conflicting with any of the ports.

I had not thought to look at IIS before. So that got me to think about anything else that I might not have looked at. I saw in Configure Connection it was using computer name and I know their Main/Standby Pair uses IP address.

Trying IP address on the DMZ server did allows the scripts to run.

I suppose that using IP address is really more a workaround than actually a solution to the problem encountered. The customer is fine with using the IP address though so I am not going to pursue it any further.

Also they are using Geo SCADA 2022 December update so it is possible it is not a problem in the most current versions.

[geoffpatton]

I have been meaning to upgrade my development system to GS 2023 and curiosity got the better of me. So I first tried computer name, on it, instead of localhost with GS 20202 May 2023 Update.

It did not work but this time I got a 502 Bad Gateway error when the script used Server.GetOPCValue.

I upgraded my development system to GS 2023 and the script ran correctly.

[tfranklin]

Just adding my experience here.  We've seen the same behavior and after looking at the IIS logs we saw that IIS was making requests using an IPv6 address instead of IPv4, so the hostname being used in configure connections was never working.  Swapping to IP worked as that seems to instruct IIS to use IPv4.  Another option we validated as successful after running into this is to disable the IPv6 adapter on the machine while still continuing to use the hostname.