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.


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.

Friday, June 6, 2014

AX 2012 R3 AOS Service Principal Name (SPN)

March 26 2015 - please also read my Update on this subject.

After working my way through both a new installation and upgrades from AX 2012 R2 (CU7), I find at least one glitch that 1) logs an Error in Event Log - Application when stopping and starting the AOS Service  and 2) that possibly increases the time to start the AOS Service.

I notice the following events beeing logged:

  • Start of AOS Service > Object Server 01:  RPC error: Failed to register service principal name (SPN): '<GUID>/<server>.<FQDN>:<AOS RPC Port#>' 
  • Stop of AOS Service > Object Server 01:  RPC error: Failed to unregister service principal name (SPN): <GUID>/<server>.<FQDN>:<AOS RPC Port#>' 
This seems to be related to utilizing Managed Service Accounts (an option when specifying the AOS Service Account) or not, where it seems like the AOS Service operates like it's always hosted by a Managed Service Account. In all installations I have used "Use the following account" and not the "Use a managed service account", but despite this deliberate choice, the messages are beeing logged.

Maybe it's difficult or even impossible to separate the different types of Service Accounts, but it should be possible to have this as a property for the Service (registry). The time it takes to start the AOS Service seems to increase in each release of AX 2012 due to the increased number of processes the AOS Service must handle and possible time consuming tasks like this, should indeed be avoided.

Bottom line - I'm supprised to see SPN errors beeing logged like this even when not utilizing a Managed Service Account (which requires a SPN and new requirements regarding integration to objecst in Active Directory).