Subscribing is a smart move!
You can subscribe to this board after you log in or create your free account.
Invite a Co-worker
Send a co-worker an invite to the portal.Just enter their email address and we'll connect them to register. After joining, they will belong to the same company.
Send Invite Cancel
Link copied. Please paste this link to share this article on your social media post.
Errors with Scripting
Are you having strange issues with scripting accessing data within Geo SCADA Expert? Does it return a strange runtime error or just take a long time to initially execute? If so, please read this article to understand how the scripting gets the data from the Geo SCADA database, and will hopefully allow you to understand and fix the issue.
This document goes through the common causes, in decreasing order of likelihood, that will cause scripting to fail to get data rather than looking at the possible errors generated and then the possible causes. This is because the possible errors depend on the external problem, i.e. errors returned from IIS and Apache will often be different, and what exactly is being requested of the web server. Hopefully the causes however can still be traced through to a resolution of the error.
Whilst the guide does try to explain some of the basic concepts, knowledge of TCP/IP networking will greatly help the user understand the possible issues and hopefully fix any problem sooner.
Overview of Scripting
Scripting is based on Microsoft's ActiveScript and is included as part of the functionality of ViewX. It is extended with some custom objects. It is not possible for scripting to access database properties from Geo SCADA via the standard connection paths that the mimics and trends use, and so must instead use the Web Services SOAP interface which is provided by the same core functionality as WebX. This means that when scripting needs to access Geo SCADA database properties it must open a connection to the WebX port to get that data.
Whenever you use the Server or Alarm.Server object in scripting, that call is requiring access to data from Geo SCADA and this request is transmitted via the Web Services port.
Example Script
The following mimic script will return an error if scripting is having issues accessing the Geo SCADA database for any reason and can be used to test your connection if needs be:
Option Explicit
Public Sub GetRootObject
Dim Obj
Set Obj = Server.RootObject
MsgBox "If you are reading this your connection worked"
End Sub
Note that if your problem is that a different Geo SCADA database listening on the WebX ports then this script will probably still work.
What are the Possible Problems?
Port Not Listening
By default Geo SCADA's web ports will listen for incoming connections on TCP port 80 for HTTP traffic and TCP port 443 for HTTPS traffic. These are also the default ports for any general purpose web server. This means that if another web server such as IIS or Apache is installed and left configured as their default then these are going to compete for access to that port and these services may start up before Geo SCADA blocking Geo SCADA from using those ports.
If that happens then when scripting tries to access the database instead of accessing Geo SCADA it will instead access whatever else is listening on that port instead. It is unlikely to be another Geo SCADA database and so it will not understand what is being requested of it and will return one of a various number of errors almost immediately to the client including 'page not found', 'method error' or 'gateway timeout'.
Check if a server's ports are conflicting by looking at the Server Status 'General' page. You will see the red text 'port already in use' if there is a problem:
If you are running multiple instances of Geo SCADA on the same machine then each instance must have its own unique ports for scripting to connect to, otherwise your scripting will probably connect to the wrong Geo SCADA database and possibly return incorrect data depending on what exactly you are requesting and how your database configuration is configured. Configure the ports in the WebX section of the Server Configuration tool. This changed from Geo SCADA 2021 and the IIS Reverse Proxy was added, so please see below for further advice.
Symptoms of this problem will be the same on all ViewX clients, including when running ViewX on the Geo SCADA server itself.
Bear in mind that if the HTTPS port is enabled it will be used even if Geo SCADA couldn't actually listen on that port, only if it is disabled then it will use the HTTP port.
The simplest way to see if Geo SCADA is correctly listening on the required ports using Server Status go to General -> Information and look for the lines starting with 'HTTP Web Server:' and 'HTTPS Web Server:'. The following image shows what it should show with the default ports correctly listening, note that the ports you choose to use for your Geo SCADA instance may be different to the ones shown below: 
If Geo SCADA is unable to listen on a port then it will be indicated as shown in the image below: 
If the WebX ports are in use then the options you have are:
- Change the WebX ports within Geo SCADA to ports which are not in use
- Reconfigure whatever is currently listening on those ports to free that port up for Geo SCADA (a restart of Geo SCADA or a quick reconfiguration of the ports is needed).
To find the current user of a port use the standard Windows 'netstat -ano' or 'netstat -bn' commands, or the more user-friendly TCPView application available from the Microsoft website.
Client-Side Proxy Problems
This section refers to client-side proxy behavior. Geo SCADA has configuration fields for this in the WebX section of the Server Configuration tool, and the fields are named 'Network Proxy'. Do not confuse this with 'Local Proxy'.
Scripting uses the same API calls to access the Geo SCADA web server in the same way that Internet Explorer connects to Internet sites such as http://www.schneider-electric.com. This means that if you have a proxy server configured within your Windows settings then these settings will be used when trying to connect to Geo SCADA.
Typically a company's proxy server will not know what the Geo SCADA servers are as they are an internal server, and are normally in a segregated network, and so the proxy will reject the connection and the script will either successfully connect to the server directly bypassing the proxy or report an error.
If the proxy cannot be contacted due to working remotely or being on an isolated network then you typically may see a delay and then suddenly scripting will work for the rest of the mimic being open. This is a fairly common problem when using standard operating environments provided by IT departments.
If you are seeing initial delays of about 20-30 seconds before an error or successful data gathering then it may be a proxy issue. Symptoms will likely be isolated to specific machines, maybe all machines from the same image or same office location. Typically running ViewX on Geo SCADA servers is unaffected as the loopback network address (127.0.0.1 or localhost) should always just work.
The solution, depending on the specific cause involves removing the proxy configuration from your machine or modifying the proxy configuration (or auto configuration/PAC) to exclude the Geo SCADA servers. There is no Geo SCADA server or client-side configuration option you can change to help with this issue as it is the underlying operating system functionality that is causing the problems. The 'Network Proxy' configuration on the WebX section of the Server Configuration tool is used for the ActiveX component in WebX and is not necessary for ViewX scripting.
Server Side Reverse Proxy Problems - Geo SCADA 2021 and up
From Geo SCADA 2021 ViewX accesses the web services via an IIS web server proxy which is automatically set up by the Geo SCADA Expert installer. Please read the Release Notes for Geo SCADA 2021 (also copied for reference in the Geo SCADA 2022 Release Notes) to understand how this is set up, particularly if you want to set up non-default configuration or change the security settings and certificates.
Links to Release Notes for 2021 and 2022.
Once the Reverse Proxy is set up you can go to its port as defined in IIS and check that it is working, for example by directing a web browser http://localhost or https://localhost on the server, or using the computer address of name from a different server. You should see the WebX login screen.
For https, the Web server which ViewX sees is IIS. Check the certificate set up and server name using the IIS Configuration applet:
Check that the certificate and host name have matching details.
For local use only you could add the Host name of localhost into the site. The red underlines in the image above show where to click. Restart the web site.
Local (Reverse) Proxy Setup for Multiple Geo SCADA Servers
This page has a document explaining how to set up the IIS web server proxy, beginning with the installation:
https://community.se.com/t5/Geo-SCADA-Knowledge-Base/WebX/ba-p/279109?attachment-id=32978
But if you are using multiple Geo SCADA servers on the same PC, then you will need to manually copy the proxy setup from the first server to subsequent servers. Follow these steps:
- Server Config | System Config | WebX
- set Listen Port to something unique and note it down (default is 8080).
- set Local Proxy HTTPS port to something unique and note it down (default is 443).
- Copy the directory C:\ProgramData\Schneider Electric\ClearSCADA\IISRP . Perhaps just leave the copy in the same parent directory but with a suffix (eg IISRP - dbname ). Note down this path.
- In this new directory edit the file web.config. Notice the line that contains localhost:8080 . Change 8080 to the port number in step [1.1]. Change the rule name if desired.
- Open IIS and create a new site. Set the physical path to that in step [2]. Set the binding type to https and to the port in step [1.2].
Script Certificate Checks
When using ViewX scripting (either on mimics or the ‘Global Script’ for alarm banner scripting) your script code may need to access the database, and to do that it uses the Geo SCADA Web Services. It is important that the ViewX client uses encrypted communications and is configured to check the identity of the server. This can lead to problems with scripting if not set up right. Here is some advice to help you.
To set this up fully you are advised to obtain a public signed certificate for the IIS web server. For test and development or internal-only networking you may choose to use different settings.
The following settings in the Server Configuration tool are used to advise ViewX how to respond to the certificate. The settings in the screenshot are ‘less secure’ and allow the user to check and import the certificate.
Importing the Certificate on the ViewX Client
When ViewX queries the certificate this dialog is shown:
If ‘Yes’ is selected the request will proceed but just for a specific web request. Typical scripts may require many requests, even for a single database property to be retrieved, so the certificate needs to be added to the client.
- Click 'View Certificate'
- Click 'Install Certificate'
- Select either Current User or use Local Machine if this is to be set up the same for other users.
- Click Next
- When prompted select the Certificate Store location. This must be Trusted Root Certification Authorities.
- You will get a UAC authorization prompt because this requires Administrator privileges. Click Yes to install the certificate.
- Now you will see the certificate if you open the User (or machine) Certificate Utility (certutil).
- Future requests to the server should not show a dialog box, UNLESS the certificate does not identify the web server.
Port Not Contactable
Quite simply, something is blocking ViewX from connecting to the WebX port on the server. Possible causes:
- Firewall on the server not configured to allow a connection between the machines on that port
- Firewall on the client not expecting an outbound connection, although if using the default ports of 80 or 443 this fairly unlikely
- Intermediate firewall on the network not having a rule in its ACL for the WebX connection
- PAT ("NAT") port forwarding not being configured properly
- HIPS (Host-based Intrusion Prevention System) software on the client treating the outbound connection as suspicious and killing the connection
If this is the case then you should seek help from your system administrator and/or network administrator. As a user there is not much you can do.
In this scenario you may find that some workstations work correctly whereas other workstations do not, normally there will be a pattern to the machines which show an error (i.e. workstations in a specific office all show the same problem but those in other offices do not).
If you can open WebX on the server from a client then the port isn't being blocked. ViewX running on the Geo SCADA server itself will also run without a problem as it will use the loopback address which will be unaffected by network and system restrictions
Certificate Revocation List (CRL) Out of Date
Industrial control systems often are not connected to the Internet and this often includes the clients. If these clients are not kept up to date with updates from Microsoft the revocation lists can get out of date and may produce various errors (such as when installing software) and may interfere with scripting's connection to the Geo SCADA servers.
You can update the lists themselves. The relevant links are:
- http://crl.microsoft.com/pki/crl/products/CSPCA.crl
- http://crl.microsoft.com/pki/crl/products/microsoftrootcert.crl
- http://crl.microsoft.com/pki/crl/products/tspca.crl
Download each file, right click on the file and choose 'Install CRL'. You need to be an administrator on the machine to import the changes.
If Windows tries to download a Certificate Revocation List (CRL) from the internet, and fails this adds 15-30 seconds to any secure connection and certificate validation. You can see detailed logs about this in the Windows Event Viewer, under: Applications and Services Logs > Microsoft > Windows > CAPI2 > Operational. You will have to ENABLE this log using the 'Enable log' button on the right hand side. Once this is enabled, make a connection, run a script and you should see messages about CRL downloads and certificate checks. You can change the settings (please take security advice), under the Group Policy Editor > Computer Configuration > Windows Settings > Security Settings > Public Key Policies > Certificate Path Validation Settings. The Network Retrieval tab contains the timeout options you can modify. This might be necessary to use HTTPS connections on networks which are completely isolated.
For further information on the CRL process and how it might affect you refer to http://en.wikipedia.org/wiki/Revocation_list
SSL Certificate Too Short - Applies to ClearSCADA Systems installed before 2012
In late 2012 Microsoft released an update to all their operating systems which blocked any certificate that is less than 1024 bits in length in an attempt to improve overall system security. Additional information is available from Microsoft at http://support.microsoft.com/kb/2661254.
When Geo SCADA starts for the very first time it generates a self-signed certificate, in recent versions they are at least 1024 bits in size however in past versions they were only 512 bits. When Geo SCADA is upgraded these certificates are not regenerated and so older systems may still carry 512-bit sized certificates with current versions of the software.
The effect is that the operating system will reject the certificate used by Geo SCADA and the WebX website will not be displayed instead showing a '404 page not found' error, yet Geo SCADA will show it is correctly listening on the ports. To verify the size of the current certificate you are using, you can do:
- Loading up the Geo SCADA Server Configuration tool
- Navigate to System Configuration -> WebX
- Find the location for the Certificate (in the Certificates section), the one with the *.cer extension
- Open up that location in Windows explorer on the Geo SCADA server
- Double-click the .cer file
- Select the Details tab
- Scroll down to the 'Public Key' entry and the value will be the bit size, for example 'RSA (1024 bits)' is a 1024-bit key
If the size is less reported as less than 1024, renaming the key and restarting Geo SCADA will generate a new certificate of at least 1024 in size. This newly generated certificate would then need to be distributed to any WebX clients to ensure that no errors are shown when accessing the system via HTTPS. Delete the old renamed certificate once you are happy with the new certificate's functionality.
Ideally on production systems you would be using a certificate issued from a trusted CA, in which case if they have provided a certificate smaller than 1024 bits then a new certificate should be issued prior to installation of the Microsoft update.
If you are unable to regenerate or reissue certificates, the Microsoft article above provides detailed information on how to change the setting to allow smaller key sizes to be used (i.e. using 'certutil' command). This is however not recommended, at least not as a long term solution.
Still Having a Problem?
Each end user architecture is unique and so the information above might not match what you're seeing but may help point you in the right direction. If you are still having issues:
- Ensure that the Windows operating system you are using is fully patched
- Disable the Geo SCADA HTTPS port (temporarily) and see if that fixes the problem which may narrow down the problem area
- Speak to Schneider Electric support, there could well be a known bug with your Geo SCADA version and the agents will be willing to help you out. They may ask for log files
- If policy allows, review the traffic between ViewX and the Geo SCADA server using network sniffing software such as Wireshark, as this may show some interesting information that may indicate where the problems are located
- Use independent software such as nc/ncat to verify connectivity between ports
- Within Internet Explorer disable "Check for server certificate revocation" (Tools -> Options -> Advanced) and restart ViewX. See if that fixes the problem which helps to narrow down the cause of the error
Author
Create your free account or log in to subscribe to the board - and gain access to more than 10,000+ support articles along with insights from experts and peers.