Selecting Geo SCADA Expert Windows 10 Licensing Model

Operators can open Geo SCADA screens and receive live data while the Windows host appears healthy, yet that successful connection says nothing about whether the operating-system license permits the deployment. Trace the installation from screen access through the Geo SCADA service, Windows host, and field-device connections before selecting a licensing model.

What is the screen telling you?

A working display proves that the client reached the application and that the server returned data. It does not prove that Windows permits the host to provide that service to multiple users. Licensing is an architectural constraint, not a runtime diagnostic: the screen can remain fully operational while the installation falls outside the applicable use rights.

The quoted Windows 10 OEM terms restrict using the software as server software, making it available for simultaneous use by multiple users over a network, installing it on a server for remote access, or dedicating the device to remote users. The same terms describe limited remote-access rights involving a designated licensed user and separately licensed devices. The wording leaves room for different interpretations when third-party SCADA software supplies the service, so record the actual access pattern and obtain a licensing determination for that pattern.

Is the computer a local HMI or a network server?

Start with the physical operating model. A machine used only by the operator standing at its console is materially different from a host delivering Geo SCADA services to remote workstations, browsers, engineering stations, or other users. The local-HMI case is the clearest candidate for a client operating system because access stays in front of the panel.

If any user depends on the host from another device, treat the installation as a server-use review. Do not classify it by the computer's form factor, the number of active sessions at the moment, or the fact that Geo SCADA is third-party software. Classify it by what the host provides and who or what accesses it.

1. Stand at the host and identify whether normal operation requires only its local keyboard, pointer, and display.
2. List every remote display, engineering tool, reporting client, maintenance connection, and remote interactive session.
3. Record whether access is sequential or simultaneous. The quoted OEM restriction expressly mentions simultaneous network use by multiple users, but sequential remote use still requires review under the remote-access provisions.
4. If the list contains no remote access, document the local-HMI boundary and continue to the software-edition review. If it contains any remote access, continue to the user-versus-device check.

Who receives the service: users or devices?

The server licensing approaches described for this architecture use Client Access Licenses assigned by user or by device. These are alternative counting models. Choose the model that matches the stable, countable side of the system; mixing assumptions during estimation produces a license count that cannot be defended.

User assignment is procedural rather than a technical binding performed inside Geo SCADA. An application login list alone is therefore insufficient: shared accounts can hide multiple people, while one person with several accounts must not automatically be counted several times. Build the user count from authorized people and the device count from communicating assets.

When a system has many RTUs but a bounded operations team, user-based licensing is usually the more useful configuration because it avoids counting every RTU as a device consumer. The final selection still depends on the applicable agreement and the entire access population.

Do RTUs change the device-license count?

They can. Under the device-based interpretation described for Windows Server access, a device using Windows services may require a device Client Access License. The stated service scope includes DNS, DHCP, and TCP/IP. An RTU communicating with a Windows-hosted Geo SCADA service can therefore become part of the device count even though it never opens an operator screen.

The tag can be right while the licensing binding is wrong: a valid DNP3 value reaching the database proves communications, but it does not convert the RTU into a user or remove it from a device-based calculation. Large RTU populations make this branch financially significant.

1. Export or manually compile the active RTU and remote-device inventory from the control-system design records.
2. Identify which devices communicate with the Windows host, including devices that reach it through routed or translated networks.
3. Compare that device population with the number of unique authorized users.
4. If the device count dominates, price and review the user-based model. If shared terminals make the user count dominate, review the device-based model while explicitly including RTUs in the licensing question.
5. Request a written determination from the Microsoft licensing channel or licensing partner for field-device access to the exact server configuration.

Past licensing interpretations for DNP3 RTUs have differed between Microsoft partners. Do not settle that disagreement through a protocol trace or application setting; settle it in writing against the agreement that will cover the deployed host.

Are Remote Desktop sessions being mistaken for operator access?

Separate Remote Desktop licensing from Geo SCADA client access. The default allowance of two Remote Desktop connections is described as administrative use, not as a pool of operator sessions. Using those connections for routine control-room access creates a distinct licensing issue even if the underlying Geo SCADA server and Client Access Licenses have been addressed.

A connection that succeeds is not a license test. Capture the session purpose in the access matrix, because the same protocol can support either administration or normal production operation.

Is the service exposed to a broad or public audience?

An internet-facing or broadly visible Geo SCADA service breaks the assumption that the user population is small and assignable. User-based licensing becomes difficult when the organization cannot identify every unique person who may access the service. Device-based licensing becomes equally difficult when client devices are uncontrolled.

Some Microsoft server components have had special licensing treatment, including contexts involving IIS or SQL, but that does not automatically extend to a Geo SCADA service that does not use those components for the relevant access. Map the actual request path instead of applying an exemption by association.

1. Identify whether access is limited to named employees and contractors or available to an open-ended audience.
2. Record whether a web tier, database tier, terminal-service tier, or direct Geo SCADA connection handles each request.
3. Match each tier to its own operating-system and application license terms.
4. If the audience cannot be enumerated, escalate the architecture to a Microsoft licensing specialist before release rather than guessing a CAL quantity.

How do you resolve the licensing decision and verify it?

Use one controlled review package so the technical architecture and commercial decision refer to the same installation. A verbal answer based on “a SCADA server” is too broad; the reviewer needs the operating-system edition, access paths, user population, device population, and Remote Desktop purpose.

1. Record the installed Windows product and license channel. The quoted restrictions came from Windows 10 OEM terms; volume-license terms may differ and must be read as the governing agreement.
2. Draw the connection boundary around the Geo SCADA host. Mark the local console, operator clients, engineering clients, remote sessions, RTUs, web tiers, and database tiers.
3. Count unique authorized people independently of account count. Then count accessing devices independently of user count, including RTUs for the device-based review.
4. Classify every Remote Desktop connection as administration, operation, engineering, or maintenance.
5. Compare three resolving branches: retain Windows 10 only for a documented local-HMI use case; move the service role to Windows Server with user-based access licensing; or move it to Windows Server with device-based access licensing.
6. Select the branch only after the applicable Microsoft licensing channel confirms in writing how Geo SCADA clients, RTUs, broad external access, and Remote Desktop sessions are counted.
7. Store the confirmation with the architecture drawing, user register, device register, purchase records, and change-control record.
8. Recheck the decision whenever the Windows edition, license channel, remote-access method, user population, RTU population, or public exposure changes.

Frequently asked questions