InfoWorks ICM Version Numbers – The rules!

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.

Coordinator

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 only exception is if the coordinator machine is also acting as a Remote Agent, in which case, the version matching rules outlined above will apply.

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.

 

Share this post!

    About Andrew Walker

    Andrew Walker is a Senior Client Services Manager with Innovyze in the United Kingdom, specializing in the computerized analysis of drainage and flooding. He has over 30 years experience of modeling the key hydraulic processes involved in urban drainage design and analysis. He is one of the key members of staff tasked with supervising the roll-out and adoption of InfoWorks ICM throughout the UK and Europe.
    This entry was posted in Information Technology, InfoWorks ICM and tagged , . Bookmark the permalink.