For most, it is a day of thrills and excitement *eye roll*. For system administrators, it is a day of skepticism and uncertainty. It reminds me of an old adage you may be familiar with, “When a door closes, five windows break”.

Microsoft released an update for Remote Desktop Connection (8.1) back in February (KB2830477) to introduce new (native) features from Windows 8.1 and Windows Server 2012 R2 to computers running Windows 7 SP1. There were a few issues that stemmed from the release, including the inability to use smartcard and smartcard devices in RDP sessions. One issue that directly affected our clients was the inability to launch RDP packages from our remote desktop websites. Users could click an application icon, but the packages would not run.

One solution is to uninstall the update (KB2830477) from the respective user’s workstation, thereby reverting back to the original RDP client version. However, this did not resolve the issue for all of our client users. Interestingly, we had a mix of users within the same client organization that either had or did not encounter the issue.

After some extensive debugging, a second solution was found that requires a change to the registry on the user’s workstation. These steps are outlined below:

*Note: Serious issues can occur if registry changes are made incorrectly. Have your system administrator make the required changes, if needed.

When developing Dynamics GP customizations in our WebSan environment, our development phase is contained within a local server configuration to ensure that all modifications to the forms and reports dictionaries are local and will not affect our hosted users. However, there are a few more items to note when separating a development from a production environment.

When enabling and granting access to modified forms and reports in GP, administrative users would navigate to the Microsoft Dynamics GP menu >> Administration >> Alternative/Modified Forms and Reports and grant access to the modified item by selecting the ID, Product, and Type (Windows: Forms or Reports), then checking the box beside the version they would like accessible:

The ID field at the top of this window is used to specify which group of users has access to the forms and reports chosen in the list underneath. Users are assigned an “Alternate Modified Forms and Reports ID” in the ‘User Security’ window:

I was recently deploying a number of GP customizations in the model of Forms and Reports with VBA, when I encountered the following error during package importing:

I had never seen this error before but upon review of the customized form, I realized that my VBA code failed to import along with the form itself. All users had logged out of the current environment and the customizations had been tested successfully in a test system. I was stumped. One common IT phrase came to mind when deciding on the next troubleshooting step: “Have you tried turning it off and on again?”

Although I did not restart the terminal server, I took to a similar strategy: I wiped all customizations and started clean. This step has worked in the past when users were navigating through customized GP windows, where the application would suddenly crash without warning. The following entry was logged in EventViewer on the server:

Any time you experience strange application crashes, or error messages when importing custom VBA packages, chances are there are corrupt dictionaries and VBA files sitting in your Dynamics GP program folders. The following are a number of steps to resolve most of these issues in a short period of time:

1)      Export all custom packages from the instance of GP that you are experiencing said errors. If you imported a package and received an error, ensure that you do not include the half-imported customization within your exportation (you will be importing the necessary package separately).

It's a Friday afternoon, 3pm, going into a long weekend. You are already going to hit traffic heading up to the cottage if you leave now, however it won't be as bad as in a couple of hours. You just finished a modified SOP Blank Invoice Form and would like to import it into your client's production environment. As you click the import button in Customization Maintenance, your heart starts to race as you cross your fingers and pray that the REPORTS.DIC file is not locked by any users....and you get the "Unable to open customizations dictionary" message. The afternoon sun will have to wait until tomorrow.

When importing customized reports through Customization Maintenance, users accessing the reporting dictionary will need to log out of Dynamics GP to have the report import successfully. This can be a pain and a scheduling nightmare for users and yourself alike. "There has to be a better way!" Well, luckily, there is. If you have access to the REPORTS.DIC file found in the "Microsoft Dynamics/GP/Data" directory, then you can import the modified report straight from this dictionary file using Report Writer (this is assuming that you developed the report in a test environment and would now like to push it through to production). To do this, follow the steps below:

Step 1: Copy the REPORTS.DIC file from your test environment to a local or network shared drive that is accessible from the production server.

Step 2: Log into the production environment with 'POWERUSER' access and launch Report Writer (Microsoft Dynamics GP menu >> Tools> Customize >> Report Writer).

Step 3:  Click 'Report', then click the 'Import' button:

Learn more about Dynamics GPView Dynamics GP PricingFree Dynamics GP Training

There are a number of recorded issues with Microsoft Dynamics GP 10.0 and 2010 when attempting to reference VBA code on 64-bit machines. Both Office 2010 and Crystal Reporting are known culprits in causing this issue to occur, as their installations update some system registry keys for VBA 6 incorrectly. Office 2010 references VB7, thus it should not be affecting keys it does not require. Registry Keys are used by the system as container objects, similar to folders, that can store values or further keys. If the value of a registry key is changed without the knowledge of an application that references its value, problems can arise. This would be the case for the VBA 6 file not being found.

I recently had a client of whom we were aiding implement an on-premise installation of GP and needed to deploy the software, along with any customized forms and reports we had designed, to a dozen workstations. After completing the deployment steps without any issue on the first three workstations, it was not until the forth that the system administrator eventually encountered the “File not found: VBA6.dll” error. The error can occur either on login to GP or when accessing custom VBA code through ‘Modifier’, if installed. Upon discussion, I was told that both Office 2010 and Crystal Reporting resided on the machine (Crystal was later removed, however the effects its installation has on registry keys can remain even after its removal).

To resolve the issue, there are two steps that need to be confirmed and/or completed to allow GP to properly reference the system dll:

(NOTE: Making changes to system registry keys is only advisable for advanced users, as incorrectly performing any steps can corrupt the system if care is not taken. Contact your system administrator for help.)
1. Ensure that Dynamics GP is not running.

If you have ever created any customized reports from within Microsoft Dynamics GP, then you are quite aware of how reporting can be a useful tool in extracting the exact information needed to increase your productivity and make effective business decisions. While there are a number of different reporting methods that can be utilized (such as SQL Server Reporting Services (SSRS), SmartLists, and Word Templates), the most popular and basis for reporting within GP is Report Writer.

While exceptionally powerful, Report Writer is not the easiest application to operate without prior knowledge or experience. However, the following is a trick that one can use to have Report Writer work for you.

A few weeks ago, a client had requested a Purchase Order form for a new company that they had just recently added to GP. The formatting of the PO form was to resemble that of an existing company, the only difference being a change in logo in the top-left corner of the report. Should be easy. However, Report Writer will only allow two versions of the same type of report: either the original GP standard or the modified version. When a report is 'modified', it will print in place of the standard version of the report. Although there are both 'Copy' and 'Duplicate' options when choosing a report to customize in Report Writer, these secondary versions of the report will only be accessible through (Reports → Customized) within GP and cannot be printed or displayed, for example, from the 'Purchase Order Entry' window.

Luckily, the Purchase Order form has two documents types: the Blank form or Other form. This way, both companies can utilize their own type of purchase order form. However, if the client requests the POP Purchase Order Other Form to be a copy of the POP Purchase Order Blank Form, the latter having numerous formatting changes and functions created; the replication of this report can be a lengthy process. There must be a better way, right? Well, there is.

Through the (Microsoft Dynamics GP → Tools → Customize → Customization Maintenance) menu, you can export a package file of the report you wish to copy. Package files are XML formatted and contain all the modifications and fields used on the report. Due to their text-based nature, these files can be manipulated within a simple text editing program, such as Notepad, without ever having to access Report Writer itself. After exporting the POP Purchase Order Blank Form as a package file (the form we would like to replicate) we can open the file and copy all text between the Report “POP Purchase Order Blank Form” line and the closing </Component>line.