Deployment Methodology for Dynamics GP Dictionary Files
When installing Dynamics GP files, a decision is made as to where the files will be stored. This white paper will discuss the different options and the benefits of each.
The different methods we will discuss are:
- Leaving the files in their default location (C:\Program Files\Microsoft Dynamics\GP)
- Moving the report and forms dictionary (forms.dic and reports.dic) to a network share
- Having the files reside in a source directory and pulling them to the workstation daily
Leaving the files in their default location
Pros:
- Easy to do, since this is the default behavior.
Cons:
- Difficult to update if there are modifications. In order to deploy a report modification, you would have to manually visit each work station and either import a new package through the interface or copy the new report.dic file to the local drive. Often this results in workstations with various modifications that a specific user might need - there is no consistent deployment throughout the enterprise. One user might have a report dictionary modified for a SOP document, another might have a modification for a POP document.
- Custom modifications are not backed up. If the modification exists on one workstation only, there is no corporate memory of it.
- Creates an atmosphere that might encourage individual users to make ad hoc modifications that only exist on one workstation.
Summary:
Best for 1-4 workstations, locations that have very few modifications
Moving the report and forms dictionaries to a network share
This option is best for most deployments. Create a share on the network and point the reports and forms dictionaries to that share. The dynamics.dic file is always local - it never changes and this helps to reduce network load and increase the speed of the application.
Pros:
- Modifications are consistently deployed, since all users share the same reports.dic and forms.dic files.
- Since all user share common .dic files, the inconsistent deployment created by the first option is avoided
- Provides a network location where the dictionary files can be backed up
- Ad hoc modifications are not possible
Cons:
- Slightly increased network load
- Adds an extra step to workstation installs
- Modifications to the .dic files can only be done if all users are out of Dynamics.
Summary:
Best for 5-15 workstations, and moderate modification needs.
Having the files reside in a source directory and pulling them to the workstation daily
- Create a folder (usually on the SQL Server) that is the main repository for .dic files.
- Create a logon.bat file in Active Directory that directs all workstations to download the .dic files to the workstation at logon (only the files modified since the last logon are downloaded).
Pros:
- Deployment of modifications is simple - copy the new .dic file to the deployment share and direct the users to log off and on again.
- Good balance for network loading - files are always run locally, and downloaded only when changed.
- Since all user share common .dic files, the inconsistent deployment created by the first option is avoided
- Provides a network location where the dictionary files can be backed up
- Ad hoc modifications are not possible
Cons:
- Requires some networking skills to create and maintain the logon.bat file. Should only be done at locations that have a dependable networking resource.
- Requires slightly more time to maintain going forward, adds one extra layer of complexity to the installation.
Summary:
Best for installations with more than 15 users or that expect heavy or ongoing modification needs. Requires a networking resource. Best if a developer is involved.