Wednesday, August 26, 2015

You receive "Could'n retrieve the list of available databases: The connection attempt failed" error when updating Management Reporter 2012

Hi everyone! I'm on the tail-end of upgrading a client to Microsoft Dynamics GP 2015 R2 and came up on an interesting issue when attempting to update Management Reporter 2012 CU6 to CU9.


In order to create my client's test environment for this upgrade, we cloned their production VMWare environment and went through all the usual server renames, static IP changes, SQL Server renaming, and so forth.

For the Management Reporter 2012 database server, we followed the applicable entries outlined in How to move Microsoft Management Reporter 2012 to a new server (CustomerSource access required), and in particular we removed the Application and Process services then ran the T-SQL script to re-create the certificate and symmetric key.

Once these portions of the configuration were in place, we proceeded to install Management Reporter 2012 CU9, first installing the Application and Process services - which also performed the overall ManagementReporter database update.

Next was to create the Data Mart database.

When we tried to connect to the Dynamics GP server to retrieve a list of the available databases to select the system database, we stumbled upon the following error: "Couldn't retrieve the list of available databases. The connection attempt failed."

Configuration Console - Dynamics GP Connection information error when clicking on the Database drop-down list

When I checked the Event Viewer, the following entry could be seen:

The encrypted setting, Password, could not be decrypted.
--- Exception Dump --- 
Caught Exception: [System.Security.Cryptography.CryptographicException] Encrypted data was invalid and cannot be decrypted.
Stack trace:
   at Microsoft.Dynamics.Integration.DataAccessLayer.DataProtection.Decrypt(Byte[] data)
   at Microsoft.Dynamics.Integration.DataAccessLayer.DataProtection.DecryptSettings(XElement settings)

User: Domain\MRAdmin


Clearly, the data source information to the Dynamics GP database server wasn't being adequately validated somewhere by the installer. Furthermore, the installer was attempting to decrypt the password I was passing in via Microsoft.Dynamics.Integration.DataAccessLayer.DataProtection.Decrypt() method which happens to be a part of the Dexterity Shared Components.

I then recalled that the Management Reporter Server installation process uses the Dexterity Shared Components to validate the connection to the system database. In reviewing the Dexterity Shared Components on the server, I found out that version 14 was installed -- version 14 corresponds to the Dexterity Shared Components installed by Dynamics GP 2015. So, I was a bit puzzled. However, further analyzing this issue, I realized that CU9 predates the days of Dynamics GP 2015, so the version of the Dexterity Shared Components it must be looking for were those of Dynamics GP 2013 or earlier. It was a long shot, but I installed the Dexterity Shared Components version 12 from the Dynamics GP 2013 CD.

Once I fired up Configuration Console and attempted the configuration of Data Mart, I was then able to choose the system database from the Dynamics GP server and complete the process just fine.

Additional Notes

In doing some poking around into the ManagementReporter database tables, searching for a potential answer to this issue, I found that the dbo.ControlCompany table contains the GLEntityConnectionInformation column, which stores an XML document with some connection information. If your test environment is a result of cloning a VMWare or Hyper-V image, chances are the data stored in this column will contain the original server information and will need to be edited to reflect the current test environment server information. By simply right-clicking on the table and choosing to Edit the Top 200 rows option, you can edit the server name. The content of the XML document stored in this column looks something like this (server name in red):

<?xml version="1.0" encoding="utf-16"?>
<ArrayOfEntitySetting xmlns:xsd="" xmlns:xsi="">
  <EntitySetting Name="DummyUserControl">
    <Value xsi:type="xsd:string" />
  <EntitySetting Name="SQL Server">
    <Value xsi:type="xsd:string">GPTOOLSTEST</Value>
  <EntitySetting Name="DDM Database">
    <Value xsi:type="xsd:string">DDM</Value>
  <EntitySetting Name="Organization">
    <Value xsi:type="xsd:string">TWO</Value>
  <EntitySetting Name="Windows Authentication">
    <Value xsi:type="xsd:boolean">false</Value>
  <EntitySetting Name="SQL User">
    <Value xsi:type="xsd:string">sa</Value>
  <EntitySetting Name="SQL Password">
    <Value xsi:type="xsd:base64Binary">AOaPHTA9VkmLvkUcyA053AEAAABurN19cbBVL3sfs/UoYU4o3YPglXB4SSrzLzXjlavUpC+uSNKdDYDDEjS9MfKKlao=</Value>
  <EntitySetting Name="Enable SSL">
    <Value xsi:type="xsd:boolean">false</Value>

So you maybe asking, "why not update from CU6 to CU13+Hotfix directly?". As it turned out, I found out that this while technically possible, causes some very undesired results with very complex reports. More on this in a follow up post.

Until next post!

Mariano Gomez, MVP

Wednesday, August 12, 2015

You experience slow performance exiting Microsoft Dynamics GP 2015 on Windows 10

Today I ran across a very interesting partner forum post, in which the consultant described a slow performance issue when closing (exiting) Microsoft Dynamics GP 2015, which started happenning after his client upgraded their Windows workstations to the newly minted Windows 10 operating system.

A Microsoft support engineer acknowledge that "there have been a few people experiencing this issue". The recommendation to bypass the slow application closing is to change or add the following Dex.ini setting to see if it resolves the issue on exit. The setting changes a Microsoft Dynamics GP global variable and avoids the pause that seems to be occurring during the exiting process.


This Dex.ini setting controls whether the Microsoft Dynamics GP application checks for the OLE Container application being opened at the time of shutdown -- a "shutdown" can occur if the user legitimately exits Dynamics GP or simply chooses to open either the Report Writer or Modifier tools. If the Container is open during the shutdown operation, Dynamics GP will attempt a graceful closure of it.

The default value of this setting is TRUE, whether the setting is present in the Dex.ini with a value of true or empty, or simply not present at all. This indicates to GP that it should always attempt to close down the Container if it is found to be open.

Given the fact that most customers are now taking advantage of Document Attachment (Doc Attach) and moving away from the Container application, there should be less and less dependency on Container, which would almost require that the default value for our flag is set to FALSE, rather than it's current state.

As usual, you must apply these changes to your environment only if you are experiencing this issue.

Until next post!

Mariano Gomez, MVP