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:
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 (ctb11w32.zip) 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:
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.
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.
PingBack from http://blogs.msdn.com/developingfordynamicsgp/archive/2008/08/20/automating-distribution-of-customisations-part-1.aspx
Posting from the Dynamics GP Blogster
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.
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?
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.
This was just the ticket David. Thanks for all you do.
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.
Please let us know how you go.
Post from Jivtesh Singh at About Dynamics, Development and Life
Posting by Rubal at Dynamics GP Help
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.
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 READ BEFORE POSTING
Please only post comments relating to the topic of this page.
If you wish to ask a technical question, please use the links in the links section (scroll down, on right hand side) to ask on the Newsgroups or Forums. If you ask on the Newsgroups or Forums, others in the community can respond and the answers are available for everyone in the future.