Our support engineers have assembled the top recommended solutions for you.
Microsoft Dynamics AX 2012
Data Import, Export, and Migration
Upgrading to Microsoft Dynamics AX 2012
Microsoft Dynamics AX 2009
Application Object Server (AOS)
Enterprise Portal and Role Centers
SSRS and SSAS Integration
Thanks in Advance.
We attempted to create a routine to export user security settings out of one environment and importing them into another using native functionality in AX 2012. One of the key tables, among others, is SecurityUserRole. Imagine our surprise when we could not find this table (and others) listed in the Import/Export select tables group even after selecting all possible options. We even searched the .dat file created for any name fragment, but found no matches.
We searched TechNet and found the article http://technet.microsoft.com/en-us/library/gg731855.aspx about the table groups in the Import/Export utility. It included a download for a spreadsheet of over 4,500 tables, and SecurityUserRole was not among them. There was a note however that read:
The preceding list does not include Kernel tables because Kernel tables are not associated with table groups. Additionally, we do not recommend that you export or import Kernel tables.
The list also does not include tables that are used by the model store.
So that left us scratching our heads. Does AX 2012 have an approved way to move users from one environment to another with security role information intact?
I also found a blog that claims to show a way to copy a full company from one environment to another at http://microsoftfeed.com/2011/company-export-import-function-in-microsoft-dynamics-ax-2012/. It appears to have erroneous instructions. At one step it instructs to select the “All” tables group, which we could not find (please educate us if we are missing something). If you were to follow the intent and export all visible tables and import them into another company, then you would have an incomplete company based on our experiments.
We have been told with some authority that AX 2009 had the ability to copy a company from one to another using native functionality. We were also told that the same was true for moving users. Did AX 2012 really get released without these features?
The export/import of a full company is not recommended for AX 2012. I've even heard the words "unsupported". In fact, even the "duplicate company" button was taken away in AX 2012 because of it. So whatever the article tells you there, definitely do not rely on the export/import for a full company copy, it's very unreliable due to the way foreign key relationships are handled in AX 2012, as well as the non-company specific tables.
Full company export/imports had become somewhat of an issue in AX 2009 already.
As far as moving users, this has always been somewhat of an issue in any release of AX. If you don't have a lot of users, just set them up again in other environments. If you have a lot of users, you should use AD user groups instead of users. This is a new feature in AX 2012 and I find it very useful in environments with a lot of users. You can assign roles to user groups, and just by adding or removing users to those user groups, the users will get the roles for the groups they are in.
As far as security artifacts such as roles or duties definitions (in case you modified the standard ones), those are stored in the AOT models. So a model store or individual model move should be done, effectively like a code release.
Dynamics AX MVP | My Blog | Sikich | Twitter @JorisdG
JorisdG, do you have resources on how to implement AD user groups in AX 2012? I'm new to AX and would very much like to understand how this works. Thanks in advance!
You basically create a user group in AD (active directory - your domain controller where the users are defined for your network). You can find more info here: msdn.microsoft.com/.../aa545347(v=cs.70).aspx
Once you have user groups, you can add those to AX, and users within that group will have access to AX: technet.microsoft.com/.../aa834422.aspx
One caveat is that you only know that a member of an AD group logged in or performed a transaction in AX, not which member per se. There are liable to be other ways to figure out who did what, but it's more work. Keep that in mind in case you have any audit requirements.
Other Microsoft Sites
I'm a Customer
I'm a Partner
Follow Microsoft Dynamics