When it comes to version numbers, there are different rules for the various components of InfoWorks ICM and its associated Services.
Local and Remote Simulations
When creating and scheduling a simulation from your local machine and running it on a remote machine, there must be an exact match between the version of ICM on the local machine and the version of ICM on the remote machine. The remote machine can have either a full installation of ICM, or just the Remote Agent, but either way, the version number must match, right down to the build number (i.e. v7.0.4, build 14015). This rule ensures that regardless of whether you run your simulation locally on your machine or remotely on another machine, you are guaranteed to get the same answers each time (because you’re using the exact same software version each time). The Agents and Coordinator will only allow a remote simulation when there is an exact match between Local and Remote machine, so the end-user doesn’t need to check anything at run-time.
It is common practice for a Remote Machine to have multiple version of InfoWorks ICM installed (say, v6.5.9, v7.0.4 and v7.5.0), so that a variety of different clients running different versions of ICM can utilise the Remote Machine for Simulations.
The coordinator can be a machine running any version of ICM. The coordinators job is simply to direct traffic and manage communications between Local and Remote machines. Obviously, over time, we’ve optimised the scheduling capabilities of the ICM Coordinator, so it would be good practice to use the most up-to-date version of ICM on your coordinator machine to ensure optimum performance, but it’s not a pre-requisite, and the version doesn’t have to match any of the clients or remote machines. The one major exception is if the coordinator machine is also acting as a Remote Agent, in which case, the version matching rules outlined above will apply.
Extra Note: If you are using v8.0 (or later), but the coordinator is older, you can end up with a ‘waiting on server’ message in the job control window if you’re choosing to save state files. Updating the coordinator to v8.0 (or later) will resolve this issue.
Workgroup Data Server
The Workgroup Data Server (WGDS) must be as new, or newer, than the clients connecting to it. It’s not the version of the WGDS that determines the version of the database. It’s the version of the Client software that sets the Version of the Database. From a maintenance point of view, you need to ensure the version of the WGDS you’re running is always up-to-date, the actual databases can date right back to version 2.0 without any issues. The WGDS is not licenced, it’s a Windows Service, and so you don’t have to worry about dongles or licence files.
The Workgroup Data Server manages all the interactions from the local ICM clients and then tunnels those requests to the database. The end-users communicate with the Workgroup Data Server (a Windows Service), and the Workgroup Data Server interacts with the actual Workgroup Database. In other words, the only ‘user’ that’s ever connected to the actual database is the “Workgroup Data Server”.
Floating Licence Manager/Licence Key Wizard/Setkey
The Floating Licence Manager (FLM) can be any version from v5.0.10 onwards. The Licence Key Wizard (a.k.a Setkey) can be any version from v4.0 onwards. With that said, we recommend keeping both up-to-date to ensure you have the best possible user experience.