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.
