Thursday, January 30, 2014

AX Technical Conference (#AXTech2014)

The Technical Conference is a major event in the AX Community and I'm scheduled to attend (thank you). It's been a while since I last attended a similar conference (I think it was Convergence in Copenhagen back in 2008) and after looking at the agenda and session catalogue, it seems to cover a lot of ground both from a functional and technical point of view.

The conference is called the AX Technical Conference, but it seems like Microsoft will cover the functional area. The focus is of cource AX 2012 R3 scheduled for RTM in Q2 2014 (CTP 4 right now). AX 2012 R3 seems to be a functional release incorporating the Warehouse and Transportation functionality bought from Blue Horseshoe (Industry focus) and improvements within the Retail area. In addition some technical news like the Deployment Tool for Azure. The latter is no supprise given the major focus on Azure which we also see in the Norwegian market (more in a later post togheter with some thoughts around the future).

So what do I expect? Well most of all this is a good opportunity to sit down and pay attention to the people closest to the product and an opportunity to interact with key resources. In addition I expect to go back to Norway next week with a better understanding of R3 and increased understanding of what we have ahead of us the next year. With the next major release of AX ("Rainier") beeing scheduled for release as soon as Q4 2014, I also expect some information related to this which probably will introduce some ground braking changes for the presentation layer in AX. All in all a good opportunity to slow down from the rather hectic daily schedule and fill up with valuable targeted and product specific information.

I'm not very into NFL, but I noticed that the Seattle Seahawks has reached the Super Bowl final and we will probably notice a little bit of interest around this event also...

I'm off to Seattle tomorrow (11 hour flight) and I will try to report the headlines from each day next week and give a final assesment based on my expectations when I return to Norway.

Friday, January 17, 2014

AX 2012 - Unable to write the generated WCF configuration to local storage

I noticed the following entry logged in Event Log, Application on 3 EP/ES servers:

Unable to write the generated WCF configuration to local storage. The generated WCF configuration will be used from memory. The contents of the new configuration are written to the following temp file: C:\Users\i<BC Account> \AppData\Local\Temp\Microsoft.Dynamics.AX.Framework.Services.Client.Configuration.ClientConfigurationInternal.log.

Exception details:
System.ComponentModel.Win32Exception (0x80004005): Access is denied
   at Microsoft.Dynamics.AX.Framework.Client.ConfigurationModel.NativeRegistry.OpenNativeRegistryKey(String keyPath, Boolean writable)
   at Microsoft.Dynamics.AX.Framework.Client.ConfigurationModel.MachineWideRegistryConfigurationModel.GetConfigurationKey(Boolean writable)
   at Microsoft.Dynamics.AX.Framework.Client.ConfigurationModel.RegistryConfigurationModel.WriteWcfConfiguration(String configuration, Guid versionId)
   at Microsoft.Dynamics.AX.Framework.Services.Client.Configuration.ClientConfigurationInternal.GetClientConfiguration()

All servers configured to use local configurations stored in the registry.

Possible solution:

  1. Grant the AD Account used as the Business Connector Proxy Account, Full Control to the current configuration in the registry (remember HKEY_LOCAL_MACHINE - not HKEY_CURRENT_USER)
  2. Use the approach described in Install multiple Enterprise Portals on the same server [AX 2012] (TechNet) to use persistent (AXC-files) configuration files instead of local configurations stored in the registry
As a side note, this is another example of undocumented requirements, and in my mind something the installer should configure during installation or at least describe as a manual configuration item.

Apparently the Business Connector binary (assembly) has built in functionality to automatically refresh the WCF configuration part of the AX configuration requiring additional configuration steps to be performed.


This could also be caused by Group Policy (domain) settings applied after the AX Components were installed.