Update on AX 2012 R3 AOS Service Principal Name (SPN)

I wrote about this back in June 2014 and based on the experience gained since this and the fact that Microsoft just published some relevant information, it's necessary with an update to this subject.

First of all, this is all about securing RPC Connections requiring Kerberos Authentication. RPC Connections are connections through the AX Windows Client or the .NET Business Connector. Not all AX Environments will require Kerberos Authentication, but the AOS Binary will by default try to  register (and de-register) a Service Principal Name (SPN) at Service Start up (and Shutdown) to support "a Kerberos and NTLM mix" (see URL for corresponding Microsoft Blog post below).

Secondly, this has nothing to do with the installer confusing a Standard Service Account with a Managed Service Account in AD. The number part of the SPN is in fact the reference to the Service Class for the AOS instance.

And finally, Microsoft recently (March 20 2015) published information on their Microsoft Dynamics AX Support Blog titled Enhanced security with Kerberos only authentication in Microsoft Dynamics AX. This is the only information I have found covering this subject and it contains very valuable information to understand the new behavior. And most importantly it reveals that this is now the default behavior for all Binaries released after AX 2012 R2 CU7 covering AX 2009, AX 2012 R2 and AX 2012 R3.

If not already described as a requirement by the customer, you should ask your customer if they require Kerberos or not. If they require Kerberos, you need to approach this as a separate configuration task since it requires more that the AOS successfully registering the SPN in AD. If the customer does not require Kerberos (can live with NTLM) Authentication and you want to get rid of the Error logged at AOS Instance Start and Stop, all you have to do is

1. Regedit - Add a new String Value to the Current AOS Configuration with the name authn_regspn
2. Enter 0 (zero) as the value of authn_regspn

This will disable automatic registration and de-registration of the SPN, and avoid the message from being logged to the Event Log every time the AOS Instance starts and stops. And it will possibly also shave off some seconds from the start and stop sequence.

Additional information can be found in the Dynamics AX Community Forum.

I will try to write about a possible approach to configure AX for Kerberos Authentication in a separate post.

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.

Microsoft Dynamics Technical Conference 2015

First of all - A Happy New Year!

I attended The AX Technical Conference last year and after following the progress of the upcoming Conference (Session Catalog), I have concluded that I can't justify the cost (attendance, travel, living and lost Income for my employeer) of attending this year. The main reasons are the lack of deep technical sessions (level 400) and the fact that the Conference now also covers CRM which is not on my agenda.

I found last years Conference to be "light" with regards to technical depth and coverage, but my expectations where based on what was called the Technical Briefing back in the days when Damgaard owned Axapta (some years ago - I know) and not the fact that AX 2012 R3 was a functional release. My latest experience before AXTech 2014, was Convergence in 2008 and even this conference (more customer oriented) was more technical compared to AXTech 2014.

I see the dilemma for Microsoft with the current product focus around added functionality (horizontally and vertically). The first event or conference covering AX 7 (AX 2016?) will be more interesting to me, since this release means a real architectural change (product revolution and a tehnological shift). At the time of writing this post (the first one in 2015), this is still unknown, and I don't expect AX 7 to be covered until the next Technical Conference in 2016. I wonder what Microsoft will name this conference when it again quailify for AX Technical Conference...

I have had my first looks at AX 7 CTP4 in Azure and I will probably post some information when the time allows it.

Update on Life Cycle Services, AX Update Installer

This is a short follow up on my last post.

LCS has been down for partners in Norway for a while, but it is available now (maybe a candidate for a later post titled “The downside of being dependent upon services in the Cloud”).

A short check today (October 31 2014) revealed a change in the mysterious “Updates until a given date” limitation and right now, this includes Updates until October 19 2014 as shown below:

Like people blogging about the different updates (builds) for AX, SQL Server and SharePoint (very useful information indeed and a life saver), this could also be a hot candidate for such information.

But the gap is not as big as it was last time and it seems like Microsoft has included most of the available updates for AX 2012 R3 in the current range.

Don't get me wrong - I think Life Cycle Services will be an important part of the future services around AX, and clearly something Customers (projects are initiated by Customers) and Partners (invited to participate) will benefit from in a long term relationship. Many thoughts and reflections could be tied to this, but I'll leave it for now...

Life Cycle Services, AX Update Installer

Microsoft is now investing heavily in Life Cycle Services (LCS) with monthly releases.

One of the most interesting features for Technical resources is AX Update Installer found under the Updates tile for AX 2012 R3 projects. This is the content after opening the tile:

After downloading the package, you have to extract the special build of AXUpdate.exe and then execute AXUpdate.exe to connect to the project in Life Cycle Services and get the magic started.

I will not go into details around this, since it is a quite straightforward and self-explaining process. One thing to mention is the requirement to have the System Diagnostics configured and at least have uploaded the Discovered Environment once. This uploads (push) Diagnostics information from your On Premise solution to Life Cycle Services including Metadata, which is important for several of the technical features in LCS like Cloud Power Support and Updates.

What I found compelling about the new AXUpdate approach was that it seemed to address the pain trying to keep up with the number of hotfixes released both for the application and for binaries. Therefore, I went through a test earlier in September to see how this really fitted with the description and my expectations. The expected benefit was to be able to produce solution specific update packages without the need to identify and download many individual fixes between Cumulative Updates (a collection of hotfixes and new features). This would be very efficient in a project where we are approaching GOLIVE on R3 (CU8 will be the first CU for R3, but no formal information about expected release date yet).

Everything played surprisingly well and I managed to update a default AX 2012 R3 solution (Model Store) without any modifications with approximately 500 application fixes and binaries for all server roles. The possibility to create and store an Update Package is another nice feature.

After finishing the Update process including the The Model Store has been modified Wizard, it was time for QA and I therefore opened Help > About from the AX Windows Client. As expected I now had many new Models in the SYP-layer (you get one SYP-model for each KB number), but when I checked the current Kernel Build number against the latest/current build number, I discovered that the updated binaries had a lower Build number than the most recent released Binary Build. This was indeed not the expected outcome…

After a couple of days I ran AXUpdate.exe again to check if any new hotfixes where available and the answer was zero (0) applicable updates. I then reviewed one of the first steps in the process after logging in to LCS called Select updates and this revealed the reason as shown below (performed October 06):

In the Combobox to Select a group of updates to evaluate, Most recent was explained as “Contains all updates until August 04, 2014”.

I have not checked after this, but Microsoft has for whatever reason defined a limitation on the set of available updates to include updates until a given date. If this was (is) intentionally it is hard to understand why since the power of AXUpdate.exe connected to LCS, is to address the pain of discovering available updates and downloading them periodically (or when needed) as a package.

I will check this again as soon as LCS is available (still inaccessible for me) to see what the date limit is right now – hopefully this was a onetime glitch and not an intended limitation.

Bottom line – do not be surprised if you do not get all available updates when using AXUpdateInstaller connected to LCS. I would like to add that this was a possible onetime glitch, but it could also explain why you do not end up with the updates you expect.

AX 2012 R3, Error running Cmdlet Test-AXReportServerConfiguration -The Network Path not Found

After successfully installing Reporting Extensions and modifying the Report Configuration, I wanted to test the configuration from the RS Server. The cmdlet test-axtestreportserverconfiguration is obviously the best candidate to do the job, but it threw an error stating "The Network Path was not found" and "Could not open the registry to read the EnableLUA key" like shown below (ran the AX Management Shell as Administrator):

I have experienced issues due to UAC (User Access Control), but after first trying to disable UAC completely (registry, EnableLUA key) on the RS Server, the error still was thrown.

I then noticed that the error actually was thrown when the cmdlet tried to read the EnableLUA key on the AOS Server (it's a two-phased test) and after checking for some references, I found an article on TechNet titled "Configure Remote Management in Server Manager" (Windows Server 2012 & R2) and the section "To configure MMC or other tool remote management over DCOM", seemed to point in the right direction.

After enabling the following rules (and Enabling EnableLUA again), the cmdlet worked as expected.

• COM+ Network Access (DCOM-In)*
• Remote Event Log Management (NP-In)
• Remote Event Log Management (RPC)
• Remote Event Log Management (RPC-EPMAP)

*It's probably the DCOM-In rule that's most important (I did not check combinations of the rules since I was working on building a Production solution for a customer).

Verification

Windows Firewall will have different rules enabled according to the customers policy and you should pay attention to the Firewall rules when experiencing issues during installation of AX Components or when a cmdlet throws errors. I have described several issues due to Windows Firewall in other posts related to installation issues and this was the first one related to PowerShell cmdlets.

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.