Dynamics GP auto roll out of updates

GP is very configurable, that is one of its big strengths. IT teams can update reports and form layouts, developers can create wonderful new add ins, new modules can be added or removed. etc. With these different sources of updates, and frequency of changes, it becomes important to keep GP users all in sync with Dynamics GP add-ins, reports and forms. I thoughts others might be interested in how we tackle this on our infrastructure.

New install

GP is first installed from a packaged version of the basic GP version, say GP2013R2 as it was the day we upgraded. The customised reports and forms are contained in the msi package that is silently deployed as part of our network group policy management. There is a packaging option under the main setup of Dynamics GP to create a msi of the configuration for your company. This is great to get the application installed with registry settings and all the other dependences bootstrapped on too.

Machines that have GP installed then also pickup further group policy that runs an windows batch file .This batch file does a delete of the add-in directory of the GP application and then copies from a deployment location on the network, the GP program files and addin directory differences over the top of the current program files directory. Thus patching the install with our current forms and dictionary modifications, in addition to the current add ins directory. Any config files etc are also copied over. Over the years we have tried many ways of deploying these files more elegantly but time and again have found ourselves caught out by unusual events and circumstances leading to deployment fails. Thus the brute force ugly method we now use. At one point I was creating a custom msi and deploying that through network management tools, but this was too cumbersome for the operations guys (and devs) who want a quick and simple way to roll out minor tweaks such as a new reports dictionary.

The batch has a constant variable to define the current release version, comparing that against a known, versioned by filename text file included in the application directory.

With the batch file keeping the files in sync, when a user launches GP it will always be up to date. The years have taught me nothing is that simple. Some users don’t logout very often. Or others decide they will just end task or close the batch file window that performs the copy, as they are too busy to wait the 20 seconds for the update. This leads to the dangerous situation of thinking everyone is running the same version, where as they are not. So I added into our visual studio mods a version checker.

Version Check performed by Login Window

In the login window, our GP will check if the user has the current version or not, if not, it then asks if they would like to upgrade. The current version is maintained by a file with a version number in the filename that also acts as a version history text file. When challenged, the user chooses to upgrade, then GP launches another updater application that gives the user a clear message to shut down all instances of GP and wait. The updater application waits for all instances of GP to close on the machine ( we use different mechanism for terminal server). Once the last instance closes, the same sync batch script is called from the updater application. The script is called in a hidden window to minimise the chance the user will cancel it. GP is updated, the updater application closes and GP is again launched, The user is now allowed to login.

This worked great until I discovered a couple of users who NEVER clicked update and always chose to avoid the install of the update, as they are too busy to wait for an update to be applied. I discovered this when they started to experience issues due to being so far behind the current release version.

Forced updates

This made me force the update by disabling the login button on the login form, until the user has the correct version, effectively forcing them to update (unless they are in an admin security group in active directory). Since implementing this, I can be confident that everyone is running the current version of GP throughout the organisation. It also means if I update the GP install, by logging out of GP and back in again, the users get the next version, which leads to really quick releases in production.

For the terminal servers, the autoupdater application can be ran from a scheduled task, where it waits for the last user to logout and then does an upgrade.