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.

Background

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
Machine: GPTOOLSTEST

Solution

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="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <EntitySetting Name="DummyUserControl">
    <Value xsi:type="xsd:string" />
  </EntitySetting>
  <EntitySetting Name="SQL Server">
    <Value xsi:type="xsd:string">GPTOOLSTEST</Value>
  </EntitySetting>
  <EntitySetting Name="DDM Database">
    <Value xsi:type="xsd:string">DDM</Value>
  </EntitySetting>
  <EntitySetting Name="Organization">
    <Value xsi:type="xsd:string">TWO</Value>
  </EntitySetting>
  <EntitySetting Name="Windows Authentication">
    <Value xsi:type="xsd:boolean">false</Value>
  </EntitySetting>
  <EntitySetting Name="SQL User">
    <Value xsi:type="xsd:string">sa</Value>
  </EntitySetting>
  <EntitySetting Name="SQL Password">
    <Value xsi:type="xsd:base64Binary">AOaPHTA9VkmLvkUcyA053AEAAABurN19cbBVL3sfs/UoYU4o3YPglXB4SSrzLzXjlavUpC+uSNKdDYDDEjS9MfKKlao=</Value>
  </EntitySetting>
  <EntitySetting Name="Enable SSL">
    <Value xsi:type="xsd:boolean">false</Value>
  </EntitySetting>
</ArrayOfEntitySetting>

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!

MG.-
Mariano Gomez, MVP