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

Automating Distribution of Customizations Part 1

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.
 

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.0 (ctb10w32.zip) from Steve Miller that we can use. The batch files provided later are setup to use this command.

http://www.stevemiller.net/apps/

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 Files\Microsoft Dynamics\GP" to "\\Server\Update\Program Files\Microsoft Dynamics\GP"
    
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).
    
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): touch /d 01-01-2000 /t 00:00:00 Data\Dex.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.

David

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.