Dynamics AX Client error: An invalid directory structure for Microsoft Dynamics AX was detected

This error appeared in our environment when we started importing configuration files for bulk deployment. You can export a working configuration so that the same can be distributed to n number of clients. 

Exporting the working configuration from one environment and re-importing in another gave this error on one of the clients.

---------------------------
Microsoft Dynamics AX Error
---------------------------
An invalid directory structure for Microsoft Dynamics AX was detected. The subdirectory C:\Program Files (x86)\Microsoft Dynamics AX\60\\Client\bin does not exist.
---------------------------
OK
---------------------------

To my surprise, the path mentioned in the error, "\Program Files (x86)\Microsoft Dynamics AX\60\\Client\bin" never existed at the client I was working on. Why would this false path generate from this client ? Left curious at my place, I googled the same and came accross the post: 

Running AX 2009 Client raises error: "An invalid directory structure for Microsoft Dynamics AX was detected" 

As rightly mentioned in the post, you need to fix the registry. These configurations are actually stored in the registry. The config executables modify the registry entries actually. And from there, the client or the server reads and loads accordingly. A different client directory path in the original configuration (exported from) will propagate in all clients with imported configurations. At this error, check the registry at the path:

HKEY_CURRENT_USER\Software\Microsoft\Dynamics\5.0\Configuration\Original (installed configuration)

 and look for the directory, bindir and datadir values.

What actually happened is that the client initially configured [and configurations exported from there] had its client installed in the \Program Files (x86) folder. However a few other clients were in the \Program Files folder. Now exported configurations are totally dependent on the original system paths and directories. Hence the initial system path propagated and didn't get checked in the middle. 

Perhaps we can have system variables representing the AX client path and AX server path and other significant locations so that such issues are mitigated.

Connecting AX client [AX32.exe] to different AOS Server configuration using command line parameters

A scenario at our end required to have the same client able to connect to multiple AOS server instances, say DEVELOPMENT, TEST and PRODUCTION environments. One way is to have multiple client configurations, and toggle them to the desired server configuration when needed. See the image below;

Dynamics AX Client configuration utility

However for more ease of use and friendly behaviour, we can have a single client with multiple shortcuts each toggling the client configurations on run time based on command line parameters :) But to successfully do this, we obviously need to know the command parameters we can attach to the AX client executable [AX32.exe]. So here we go;

Client configuration commands [AX 2012]

http://technet.microsoft.com/EN-US/library/aa569653.aspx

Now with the information from the above link, we come to know that regConfig is the parameter we can provide with the AX32.exe to mention the client configuration name the client will run accordingly. A sample command is compiled as follows;

ax32.exe -regConfig=ConfigName

You can test the above command with correct configuration names from the Run command box [Windows+R] and can play with it too :)
Try to provide an incorrect configuration name and see what happens. Try giving a wrong command and notice the behaviour.

Coming back to the topic, what we did was to have two different shortcuts, each with its own command line parameters

• Client 1 - "AX32.exe - regConfig=YourFirstAOSClientConfig"  
• Client 2 - "AX32.exe - regConfig=YourSecondAOSClientConfig"  

See the image below;

Now both the shortcuts are pointing to the same single AX32.exe but with different values in the parameter '-regConfig' thus directing the client to connect to a different client configuration from the default one. Now these configurations can be a copy of each other or associated to the same server with different databases or entirely different AOS servers, this is entirely up to you how you need it :)