License Automation

Every year the maintenance/subscription expiry date on your licensed Genero installations should or needs to be updated.  In the case of subscription licenses or using Genero Report Writer under the initial “free if under maintenance” offer, it needs to be updated or else your system will stop running.   A misconception that we occasionally encounter is that you expect these dates to be updated on your systems automatically when we receive payment.

You should be aware of the pages that explain how a perpetual and subscription license is managed …

• subscription
• perpetual

As per the documentation, these are the steps that the system administrator needs to perform to update the maintenance key / subscription key after we have received and processed the payment.  See …

• if using Four Js License Manager – the command  flmprg 
• if not using Four Js License Manager – the command  fglWrt

In terms of having the Genero installation update itself automatically, it is possible for you to create cronjobs / scheduled jobs on your system to do this for you.  The configuration isn’t part of Genero but part of your normal system administration.  What is Genero is the commands you execute.  It used to be that you might get the fgWrt -m auto command to execute as part of the scheduled job but that required some input redirection.  More recently you would use one of the batch options, and in particular the install-mkey-http batch command that is available in both fglWrt and flmprg, so something like …

fglWrt --batch action=install-mkey-http^login=?????

flmprg --batch action=install-mkey-http^login=?????^lnum=???#????????

… with some extra arguments if you need to navigate a proxy.

If you have not seen the batch commands, refer to the individual fglWrt and flmprg documentation.  They are a relatively recent addition that allows license tasks to be performed by scripts.

The key characteristic of the –m auto and now the install-mkey-http is that they communicate with our servers.  Our finance team have processed your payment, and so when these tasks communicate with our server, they get the new maintenance / subscription key. It is not our servers reaching out to your server and saying payment has been made, it is your server reaching out to us and asking if payment has been processed, and if it has receiving and installing the new keys.  Like any communication between servers, it is important to know the triggering event and who is triggering the communication.

If you do decide to set these up as scheduled tasks, what we do ask is that you configure them to occur at a time that is not 00:00.  This avoids everyone hitting our server at the same time.  In terms of how often you should configure this job to run, the minimum is once a year, you may decide to add a few more for safety, anything more than twice a month I’d consider excessive.

The danger with these sort of jobs that you automatically setup to run once a year is that you forget about them, so make sure you document their existence, and also set diary entries to check that they have run as you expect.  That is “trust, but verify”.