Showing posts with label DIXF. Show all posts
Showing posts with label DIXF. Show all posts

Wednesday, April 8, 2015

AX 2012 R3 - Data Import Export Framework - Key not valid for use in specified state

I came accross this issue after replacing the Business Database in a Test Environment. This should not be a very common issue, but I'm sharing it since the possible solution is rather simple.

Scenario

When validating a Data Source (DB) from the form Data Import Export Framework > Setup > Source Data Formats, the following exception was thrown:

System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> System.Security.Cryptography.CryptographicException: Key not valid for use in specified state.

After examining the underlying code, it pointed to the a specific table.

Solution/workaround

NB! I have deliberately choosen not to reveal the real table or column name (pretty obvious)

  1. Run a simple SELECT from the table.
  2. Check if a value is stored in the "Secret" Column for the Data Source Type (typically DB:Database).
  3. If you find a value in this "Secret" Column, try to run a simple UPDATE statement to clear the value.
  4. Do a Log Off - Log On Sequence in the AX Windows Client and try to validate the Data Source again and you will probably have solved your issue.
Hypothesis

When replacing the Business Database, it's always a Best Practice to create a new GLOBALGUID. It could be that the GLOBALGUID is used as the or part of the Encryption Key. After changing the GLOBALGUID, it's no longer possible to Decrypt the information stored in the table (and that's the way it should be).

Monday, February 2, 2015

AX 2012 R3 - Data Import Export Framework - Could not load file or assembly Microsoft.SQLServer.ManagedDTS, Version=11.0.0.0

Scenario


  • A single server install of AX 2012 R3 used for Data Migration purposes
  • SQL Server 2012 was originially installed on the server together with all DIXF Components
  • SQL Server 2014 implemented (uninstall SQL Server 2012 Services and Shared Components and install SQL Server 2014 Services with Shared Components) - DIXF Components kept
After restoring databases from another AX solution and performing the needed operations on the databases, Preview in DIXF raised a Stop error in AX with the following message "Could not load file or assembly Microsoft.SQLServer.ManagedDTS, Version=11.0.0.0".

Solution
  1. Stop the AOS instance
  2. Reinstall (uninstall - install) DIXF Components
  3. Start the AOS instance
  4. Verify DIXF Preview functionality
Hypothesis

DIXF registers the reference (in AOT) to this SSIS assembly at DIXF install time.


Wednesday, June 11, 2014

AX 2012 R3 Data Import Export Framework (DIXF), Exception at Microsoft.Dynamics.AX.Framework.Tools.DMF.ServiceProxy.DmfEntityProxy.DoWork[T](Func`1 work)

A preliminary warning about a potential issue for Data Import Export Framework released for AX 2012 R3 based on experience from 
  • Scenario 1: Single-Server install (AOS and SSDS + SSIS with all DIXF Components) 
  • Scenario 2: Multi-Server install (2x AOS with DIXF AOS and Client Component, SSDS + SSIS with DIXF Framework Service Component)
In scenario 1, the Service Account for the AOS Service was utilized for the DIXF Framework Service while in scenario 2 a separate Integration User Account was utilized for the DIXF Framework Service.

Symptom:

In scenario 2 an exception was thrown when validating the working directory for DIXF (button in form DIXF Parameters) > Microsoft.Dynamics.AX.Framework.Tools.DMF.
ServiceProxy.DmfEntityProxy.DoWork[T](Func`1 work).
This worked fine in scenario 1.

Issue 1 - Local Security Group not created by the installer when installing the DIXF AOS Component:

When installing the DIXF Framework Service, a new Local Security Group called Microsoft Dynamics AX Data Import Export Framework Service Users was created and populated with the AD Account hosting the DIXF Framework Service. This Local Security Group was not created by the installer when installing the DIXF AOS Component on the AOS servers. After manually creating this Security Group on the AOS servers, populating it according to the instructions given in Install the Data import/export framework (AX 2012 R3) [AX 2012] and restarting the AOS servers (caching), the error still was thrown.

Issue 2 - Required membership in new Local Security Group:

The instructions on TechNet states that the DIXF Framework Service Account must be added to the Security Group on the server hosting the Framework Service, and similarly the AOS Service Account to be added to the Security Group on the servers hosting the AOS Service and the DIXF AOS Component. In scenario 2 I had to add both Service Accounts to the Security Group on all three servers followed by a restart of the AOS servers, to get the validation working without throwing the exception (issue solved)

It could of course be something related to the In-Place Upgrade procedure, but I doubt this since you have to uninstall all pre AX 2012 R3 Components before any AX 2012 R3 Components can be installed. My best practise includes a restart of each server after performing the uninstall and other clean up tasks, and I think the difference between the scenarios (single versus multi-server setup), points in the direction of the Security Groups not being created automatically by the installer and that all Accounts used by DIXF, must be added to each group.