Microsoft Dynamics GP 2010 : Network requirements, The Terminal Server only approach, Shared files, Data backups

1. Network requirements

To install Dynamics GP on a network, the following are required:

• Domain: Domain is listed as a requirement in the Dynamics GP 2010 installation manual, however, as Peer to Peer environments are now supported with Dynamics GP, technically a domain is not needed. That said, it is recommended that all client and server computers are joined to a domain.

• Network Protocol: TCP/IP is the only required and supported protocol for Dynamics GP. While Named Pipes can sometimes be used successfully, it is not required and may not be supported.

• Name resolution: Name resolution needs to be used so that each computer is indentified by a unique host name. Internally handled resolution is recommended for the most reliable Dynamics GP performance.

Recently, Microsoft added Peer to Peer Environment to the supported list of configurations. From our experience a Peer to Peer Environment is not recommended for Dynamics GP implementations.

2. The Terminal Server only approach

With the proliferation of Terminal Server and advances in Terminal Services functionality, many organizations have been implementing Dynamics GP on Terminal Server only, foregoing installations on client workstations completely. Whether this approach is right for your implementation may depend on a great many factors. Let's take a look at some of the pros and cons.

Pros of a Terminal Server only implementation

Following are the benefits of a Terminal Server only implementation:

• No need to upgrade any workstations: This may be a great approach for companies where many client computers do not meet the requirements for Dynamics GP and there are no other reasons to upgrade.

• Installation, updates, maintenance, and support are all simplified tremendously: For environments where there are limited IT resources, it is a great deal easier, not to mention less expensive, to install, maintain, and support the Dynamics GP client application on a Terminal Server as opposed to multiple client workstations. For implementations that have already planned on a Terminal Server for remote users, it may add only a small incremental amount of work and cost to set up the rest of the users on the same Terminal Server.

Cons of a Terminal Server only implementation

Following are the negatives of a Terminal Server only implementation:

• Server specifications may need to be more robust: As there will be more users on the Terminal Server, the server used for this may need to be significantly more robust, and thus more expensive than if it were just being used for a limited number of remote users.

• More licensing costs may be incurred: Additional users on the Terminal Server may necessitate the purchase of additional licensing that may not have been planned on otherwise. For example, additional Microsoft Office licensing may be needed on the Terminal Server so that users have the ability to export from Dynamics GP into Excel or Word.

• Single point of failure: If all Dynamics GP users are accessing the same Terminal Server, if that server is down then no users can access Dynamics GP. This can be mitigated by routine maintenance and possibly an additional or standby Terminal Server.

As you can see from the preceding lists of pros and cons, the Terminal Server only approach may save time and money on ongoing IT resources, but may cost more in hardware and licensing. As with any infrastructure decision, contemplate this with all the other infrastructure considerations we have discussed to determine the best course of action for your organization.

3. Test/development environment

At different stages of your Dynamics GP implementation, as well as for ongoing development and support, a test or development environment may be required for Dynamics GP.

By this stage of your implementation planning, you will have a good idea of the major components of your Dynamics GP environment and how complicated it will be. A simple environment will include the Dynamics GP application and modules, Management Reporter or FRx, and possibly an add-on product. A complex Dynamics GP environment will consist of the Dynamics GP application, Management Reporter or FRx, integrations with other systems, and multiple add-on products or customizations.

For a simple Dynamics GP environment, a test environment can be as straightforward as setting up a new company. Dynamics GP has a sample company available, but it will most likely have a different setup, and certainly different data, than your live Dynamics GP companies. To have a more realistic test environment, you can create a new Dynamics GP company and restore a backup of a live company to it. This can provide a much more practical test area for users to train and test functionality. It can also be used by support and development users for their needs; however, this must be done carefully as any system-wide settings changed will impact the production environment. A KnowledgeBase article is available with the steps to create a copy of an existing company: https://mbs.microsoft.com/knowledgebase/KBDisplay.aspx?scid=kb;en-us;871973 (requires access to PartnerSource or CustomerSource).

For complex Dynamics GP environments it is recommended to set up a separate server for testing and development. The hardware does not have to be the same, but otherwise the development server should be as close as possible to your production server. Your Dynamics GP license allows a development server to be set up for internal use with no additional license needed. The Microsoft Dynamics GP End User License Agreement can be found here: https://mbs.microsoft.com/downloads/partner/partneressentials/agreements/newSLTdocs/DynamicsSLT_US_English_Dec_2008.pdf (requires access to PartnerSource).

Even with a separate development server you may decide to create a test company on the production server to facilitate end user training and testing.

4. Add-on products

If you are planning on any add-on and third-party products for Dynamics GP, verify the system requirements and recommendations for them with the manufacturer. Most add-on products will have the same requirements as Dynamics GP, but some may not yet be supported on newer operating systems or service packs. Some may also require different Dynamics GP service pack levels than what you may be planning.

If the add-on product you're planning on collects large volumes of data, talk to the product manufacturer about expected database growth so that you can plan your storage capacity accordingly.

5. Shared files

Most Dynamics GP implementations will have a number of files that may need to be shared by all or some Dynamics GP users. These files include modified reports and forms dictionaries, OLE notes, FRx files, and Integration Manager files. We have seen implementations share as many Dynamics GP components as possible. This is not a recommended approach as it creates unnecessary network activity and impacts Dynamics GP performance for very little gain. Most of these components are static until there is a service pack or upgrade, and having them local to the Dynamics GP client installation greatly improves stability and performance.

The recommendation is to only share files that are modified or custom for your implementation.

Modified dictionary files

Most Dynamics GP implementations will require at least a few report modifications for common reports such as payables checks. The two most typical methods of storing these files are in a shared network location, or locally on each computer running Dynamics GP.

Shared network location

Using a shared network location is the more common and recommended approach, most companies already have a file share in place that can be used for this. Having modified dictionary files in one shared network location allows easier maintenance, backup, and updates of these files, as any changes only need to be made in one place. The drawback to this approach is that all users must be out of Dynamics GP before any changes or additional modifications can be made, otherwise it is easy for the dictionary files to get corrupted. This approach can also cause slower performance, although on most networks this is not an issue.

Locally on each Dynamics GP client

Storing modified dictionaries locally on each client may be a good approach when only a few Dynamics GP users need modified reports, or for situations where performance may be an issue. The major drawback to this is that any change made will have to be propagated to all users that need it. Also, if users are modifying their own dictionaries, backups are needed for all these local files.

If all users are utilizing the same modified dictionaries, there is a technique for automating the distribution of changes described on the Developing for Dynamics GP blog: http://blogs.msdn.com/developingfordynamicsgp/archive/2008/08/26/automating-distribution-of-customisations-part-2.aspx.

Keep in mind that this technique may not be easy to set up in all environments, as it relies on all users logging in to Windows daily and having the Dynamics GP installation in the same exact location on each computer, which may not be the case for many companies.

OLE notes

Just about every screen, transaction, and master record in Dynamics GP has the ability to store associated notes. Notes can be text only, in which case they are stored directly in SQL Server tables, or they can be file attachments. Attachments are stored in an OLE container in a predefined location. (OLE stands for Object Linking and Embedding.)

The OLE notes location is set individually for each Dynamics GP client. If it is not the same for all installations, users across your Dynamics GP implementation will not be able to see each others' attachments. The recommendation is to have this location on a network share.

FRx files

If you will be using FRx, all global configuration settings and report definitions will be stored in the SysData directory. FRx also uses a directory called IO_Data as a default report storage location when reports are generated. It is recommended to put both of these directories on a network share if multiple users will be accessing FRx.

Integration Manager files

If Integration Manager will be used for the Dynamics GP implementation, a database containing all the integration setup files (typically called IM.mdb) can be shared by all Integration Manager users. Sometimes this is useful, other times it is better to have the integration database stored locally for each installation because the integrations differ by user.

One final consideration for all the shared files we have discussed is that all Dynamics GP users will require full control of these files.

6. Data backups

Most organizations implementing Dynamics GP will already have a backup solution and schedule in place. If there is no existing backup solution, it is highly recommended to implement one prior to the Dynamics GP implementation. For new or existing backup solutions, you should verify that there is adequate room to add the additional data generated by the Dynamics GP implementation.

For backup solutions with a lot of available space, companies may choose to backup an entire server. At the very least, plan to back up the following:

Depending on the components of your Dynamics GP implementation, you may need to add to the list of what data you back up. Backup frequencies and retention policies may differ by organization. If there is any question, it is always better to err on the side of having more backups available, no one ever got in trouble for having too many backups.

Something that few companies do is test their backups. Once Dynamics GP is in place, consider testing your backups to make sure they can be used to restore your data successfully.