The evidence isolates the fault to remote web access rather than a Rapid SCADA application startup failure. The web page opens locally on the server, while another PC cannot open it. Diagnose the network-facing web-server path before changing the SCADA configuration.
Establish the Installed Version Baseline
The installation is described as Rapid SCADA 6.3, but ScadaWeb.log identifies the running Webstation as 6.2.0.3. Resolve this discrepancy first: confirm which package was installed and which application directory IIS actually serves. Do not assume that the displayed product version and the running web components match.
| Observed item | Evidence | Engineering decision |
|---|---|---|
| Reported installation | Rapid SCADA 6.3 | Compare the installed package with the deployed IIS application. |
| Running Webstation | 6.2.0.3 |
Verify IIS is not pointing to an older deployment. |
| Installed runtimes |
dotnet-hosting-8.0.11-win and windowsdesktop-runtime-8.0.11-win-x64
|
Confirm the IIS ASP.NET Core hosting component is installed and registered; installation alone does not prove IIS is using it. |
| Previous system | Rapid SCADA 5 on another server | Treat the new installation as a fresh deployment, not a verified migration. |
Interpret ScadaWeb.log Correctly
The supplied log shows Webstation starting, loading FileStorage.dll and the listed plugins, receiving the configuration database successfully, and reporting that the application is ready. The only shown [ERR] records are failed admin login attempts caused by an incorrect username or password. Later records confirm successful admin logins with role 1 from ::1.
These entries do not demonstrate a Webstation startup fault. They also do not prove that IIS accepts connections from another computer. The address ::1 is local loopback traffic, so the successful sessions verify local access only.
Separate Local Application Health from Remote Reachability
Because the page opens through localhost on the server, the application can respond locally. On another PC, localhost refers to that PC, not the SCADA server. Test the server's network address and the configured web port instead.
| Test result | Meaning | Next check |
|---|---|---|
Fails on the server through localhost
|
Local IIS, hosting-module, site, or application problem | Inspect IIS configuration, Windows event logs, and ScadaWeb.log. |
| Works locally but fails from another PC | Remote path, listener binding, firewall, or security-policy problem | Inspect the IIS binding, listening port, and inbound access. |
Remote PC uses localhost
|
The request targets the remote PC itself | Use the SCADA server's network address. |
Account for IIS and the Existing Server Workload
The replacement host already runs EnergySphere 8.1 for electricity-meter polling. The evidence does not establish an incompatibility between the two applications. It does justify checking IIS for competing sites, overlapping bindings, and server-specific security rules. The other application reportedly does not require a web interface, but that statement alone does not exclude shared ports, services, or policies.
In IIS Manager, identify every configured site and compare its address, port, host-name binding, state, and physical path. The reported access attempt references port 10008; confirm that this is actually the port bound to the Rapid SCADA site rather than assuming it from the previous installation.
Run the Diagnostic Procedure
- On the server, confirm that the site still opens through
localhost. Record the exact port used by the working local request. - Open IIS Manager and identify the site serving Rapid SCADA. Verify that its physical path corresponds to the intended installation rather than an older Webstation deployment.
- Inspect the site's bindings. Confirm that the working port, including
10008if configured, is available on the server's network interface and is not assigned incompatibly to another IIS site. - Confirm that the ASP.NET Core hosting component required by the IIS deployment is installed and available to IIS. The supplied evidence confirms installation of
dotnet-hosting-8.0.11-win, but not successful IIS module registration. - Check whether the server is listening on the configured port, then review inbound firewall and server security rules for that same port. Apply the check to the server hosting both SCADA and the meter-polling software.
- From another PC, browse to the SCADA server's network address and confirmed port. Do not use
localhost. - Correlate the remote attempt with IIS access records, Windows event logs, browser developer-console errors, and new entries in
ScadaWeb.log. If no server-side request appears, continue troubleshooting the network path and listener rather than SCADA authentication.
Verify the Repair
A valid repair must satisfy all of the following: the page opens locally, the same IIS site responds through the server's network address from another PC, the expected interface loads, and the new request produces no relevant application or browser-console error. Finally, confirm that the running Webstation version and plugin set belong to the intended installation. The supplied startup log lists Webstation 6.2.0.3, FileStorage 6.2.0.0, and plugins in the 6.1.0.0 or 6.1.0.1 range; that mixed baseline must be reconciled with the reported Rapid SCADA 6.3 installation.
FAQ
Why does Rapid SCADA open on the server but not another PC?
The evidence points to IIS binding, port-listener, firewall, or server-policy checks because Webstation starts successfully and responds locally. Test the server's network address on the confirmed IIS port.
Can I open the Rapid SCADA server using localhost from another PC?
No. localhost targets the PC where the browser is running; use the SCADA server's network address and its configured port, such as 10008 only if IIS confirms that binding.
Do the admin login errors explain the missing remote page?
No. The shown [ERR] entries are incorrect-credential attempts, followed by successful admin logins with role 1 from ::1. They confirm local authentication activity but do not verify remote IIS reachability.