Automating Distribution of Customizations Part 2

David Meego - Click for blog homepageThis is a reposting of an article I originally wrote on my Developing for Dynamics GP blog.

If you have not read part 1 of this posting it can be found using the link below:

So you have decided to go with Configuration 5, which means all of the client components are stored locally, but a script is used to update the client files from a central update share when the workstation logs in.  You can also run this script manually from a batch file if desired.

The technique is based on the concept that each morning a user logs into the company’s Windows domain and the system runs a login script.  We will change the login script to copy any updated files from a central Update share to the workstation.

The default locations for the login.bat script on the domain controller depends on the operating system being used.

Windows NT 4.0 DC c:winntsystem32replexportscripts
Windows 2000/2003 DC c:windowssysvolsysvol<domain name>scripts
Windows 2008/2012 DC c:windowssysvolsysvol<domain name>scripts


You can also check the location of the scripts directory by issuing the following command at a Command Prompt “net share netlogon” (minus the quotes).

There are some issues which must be considered for this configuration to work successfully:

  • All workstations will have the same customizations and products installed. Security can be used to control whether a particular user has access to a customization.
  • All workstations have the Microsoft Dynamics GP client installed in the same location (folder).
  • The Dynamics.set file has all custom forms and reports dictionaries in the application folder (for v8.0 or v9.0) or in the Data subfolder (v10.0 or later).
  • All referenced dlls in VBA customizations must be installed or available from the same path on all workstations.
  • This method does not update registry settings, it can only update files.
  • This is method can be used for updating custom forms and reports dictionaries, .vba files containing VBA customizations and Visual Studio Addins .dll files.
  • It can be used to update application dictionaries and runtime engine files, but will not make any registry changes to indicate that a particular service pack or hotfix is installed.
  • Do not copy chunk (.cnk) files to the Update share as they will then need to be extracted after every log in.
  • It is not recommended as a method of rolling out a new version or release of Microsoft Dynamics GP.
  • It is recommended to have all customisations backed up by exporting them as packages using Customization Maintenance.

Disclaimer: The copying of .VBA files between workstations is not a supported method. However, it can work as long as all .dll files and .dic files referenced in the VBA code are in the exact same paths for all workstations. See the first four bullet points above.

To make this technique work you will need a “touch” command.  This is a unix style command which can be used to change the date and time stamp on a file.  The reason for the use of this command will be explained later.

The link below has a free Touch command as part of the Win32 Console ToolBox 1.1 ( from Steve Miller that we can use. The batch files provided later are setup to use this command.

Here is the process for making this configuration work:

  1. Create an Update share on your server and make sure that the workstations have access to it.
  2. After installing the Microsoft Dynamics GP client on a workstation, copy the files from the application folder and sub folders to the Update share maintaining the paths.For example: from “C:Program FilesMicrosoft DynamicsGP” to “\ServerUpdateProgram FilesMicrosoft DynamicsGP”
  3. Copy the touch.exe file (see link above) to the application folder in the Update share.
  4. Copy the TouchDic.bat, TouchRep.bat, Update.bat, and UpdateForce.bat from the archive file attached to this posting to the application folder in the Update share.
  5. Edit the Dex.ini file to remove any workstation specific settings such as ST_MachineID (used by Named Printers). The Dex.ini file will normally be located in the application folder (for v8.0 or v9.0) or in the Data subfolder (v10.0 or later).
  6. Use the touch command to reset the Dex.ini file’s date and time stamp back into the past.  This is to ensure that the Dex.ini file does not accidentally overwrite the Dex.ini file on a workstation.For example (v8.0 or v9.0): touch /d 01-01-2000 /t 00:00:00 Dex.ini

    For example (v10.0 or later): touch /d 01-01-2000 /t 00:00:00 DataDex.ini

  7. Edit the Login.bat script on the Domain Controller to include the commands in the Login.bat provided in the archive file attached to this posting.  If you are unable to change the login script on the domain controller, you could add this batch file to the Programs >> Startup folder for all users on each workstation.This script will use xcopy to copy any updated files from the Update share to the workstation only if Microsoft Dynamics GP is already installed on the workstation.

Now when any client logs into the domain, their workstation will be updated.

NOTE: You will need to edit the source and destination paths listed at the top of the Update.bat, UpdateForce.bat, and Login.bat batch files to match your system.

If you want to manually update from the Update share you can exit Microsoft Dynamics GP and then run the Update.bat file.  You can even create a shortcut to Update.bat on the desktop if you wish.

If you want to overwrite all of the files and not just the changed files, you can exit Microsoft Dynamics GP and run the UpdateForce.bat file.  This batch file can be used after installing a new client to bring in all the settings, third party products and customizations.  Please note that it will remove any waiting chunk (.cnk) files to prevent them being extracted and overwriting the client files copied from the Update share

Now that the automatic system is in place, here are instructions for placing files into the Update share.

  • If installing a new application dictionary, copy the new application dictionary file and any associated help files and manuals as well as the updated Dynamics.set launch file to the Update share. Using Windows Explorer and sorting by date is a good way to check for updated or new files.
  • If updating modified forms or VBA customizations, copy the updated .dic and .vba files to the Update share.  Note for v10.0 onwards the .dic files will be in the Data subfolder.
  • If updating modified reports, it is a little more complex. Microsoft Dynamics GP updates the date and time stamp on the custom reports dictionary files every time the application is closed.  To ensure that the custom report dictionary which has just been modified has a later time than other workstations (which may have closed the application after the changes were made), we can use the touch command to change the time on the dictionary file to 23:59:59.To make this easy we have the TouchDic.bat file which will update the time stamp for the dictionary files passed as parameters.  The .dic extension is option as is the Data subfolder for v10.0 onwards.  We also have the TouchRep.bat file which has a list of the common custom reports dictionaries and will call TouchDic.bat for us.  You can edit TouchRep.bat to add extra file name if needed.

    Once the date and time stamp has been updated the custom reports dictionary files can be copied into the Update share.

While all this sounds a bit complex, once it is set up correctly it is very simple to use. You can work on changes on a workstation during the day, get all the changes correct and tested.  Then you can update the changes to the central Update share.  If anyone needs the change immediately, get them to either log out and log back in or run the Update.bat file, otherwise all workstations will be updated on next log in.

An archive containing all the batch files used is attached at the bottom of the article.

Please post your comments on how this system worked for you.


Thanks to Robert Cavill for his assistance on this posting.

07-Dec-2009: Also check out the funny related post: The term “Musgravion” and Wikipedia.

09-Feb-2010: Added disclaimer about the copying of .VBA files between systems.

14-Aug-2013: Updated scripts for 64 bit support, ie. handling for C:Program Files (x86) folder.

This article was originally posted on the Developing for Dynamics GP Blog and has been reposted on

15 thoughts on “Automating Distribution of Customizations Part 2

  1. A couple of clarifications.
    For a new install once you have installed the standard client from the CD, you can run the UpdateForce.bat batch file to bring all the third party products, customisations, service packs, hotfixes and settings from the Update Share down to the workstation.  That would definately speed up the new client install process.
    As for Citrix/Terminal Server, you can’t use the Login.bat approach, but once you can confirm all users are logged out of the client, you can manually run Update.bat to bring all the updates down from the Update share to the shared client.


  2. David,
    I have finally started using this method at my client and it is a big help.  Since we don’t use dexterity very much I just use it for Vba and DIC files, but it seems to be working well.
    I use a text file on the server and client so that the updates are only applied if the version of the client is lower than the version of the server.
    I have a question for you:  Some of the clients are on Outlook 2003, but most are on Outlook 2007.  So the ones on 2003 receive ‘Missing Reference’ errors.
    Do you have any suggestions for dealing with this other than using two copies of the VBA files or using package files to install the references separately?


  3. Hi Phil
    If you have a reference to Outlook 2007 objects in your VBA code and not all machines use Outlook 2007, you will need to have separate VBA files.  Which would probably mean separate update folders.  Not an easy approach to maintain.
    As I mentioned in the article, the systems need to be the same with to avoid referencing errors. I suggest you get all workstations running Office 2007, it does not make sense for a single organisation to be running two versions of Office.


  4. Have just configured, now comes the testing and if all goes to plan, it will save me a truck load of time by not having to update dictionaries at night.
    Cheers, Steve


  5. I know a comment on a very old blog post…..
    This method won't work if any workstation that you are copying files to has ever received the file not found VBA6.dll error. If you fix the error on that workstation and then overwrite the VBA files with ones from another machine you will receive the error again.


  6. Mike,
    Yes you would if that other machine currently has the issue.  The reason is, I believe, is that the 'bad' file/path of the incorrect dll is written into the vba file itself.  So even if you fix the registry to point to correct vba files, the .vba itself would now point to the wrong ones and you get the error again.


Please post feedback or comments

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.