The proper way to install AX 2012 RTM on Windows 2012

When installing AX RTM on Windows 2012 the prerequisite validation tool gets stuck on KB2390372, an update that you cannot possible install on Windows 2012. It gives a weird error message, "KB2390372v2 does not apply, or is blocked by another condition on your computer."

In theory CU5 solves this issue, but how can you install CU5, before installing RTM?

I have found contradictory information on the net, so I thought I would share with you guys what worked for me. Not sure if all the steps are neccessary, but..

1. Install the web server and the app server roles, make sure to include .NET and Identity foundation (not sure if this is n
2. Start the AX RTM setup
3. Install the setup support files, and configure most of the prerequisities
4. Download the CU5. 
5. Unpack CU5
6. Start installing CU5, tell it to patch the setup support files
7. Start AX RTM setup again
8. You DO NOT have to copy the CU5 files under the Updates folder of your AX install folder. This is a false piece of information (or at least it was not neccessary for me... but you know... it's AX. Your mileage may vary)
9. Just continue as usual, it should not ask for KB2390372 anymore

LedgertransStatementDP.ProcessOffSetAccountInStaging has a copy-paste error

I found a bug in AX today in the data provider class of the Ledger trans statement report, and I will share it here, in case it helps anyone.


The task: lets fill the fields (OffsetAcct1, OffsetAcct2, and OffsetAcct3) with some data.
What happens: the code fills OffsetAcct1, OffsetAcct2 and for good measure fills OffsetAcct2 again, never using OffsetAcct3 despite the intention obvious from the comments.

The whole function is a nasty mess of a way of solving the task, but at least it doesn't even work.
Here is the original code snippet;

And here is my no- so-complicated fix for the offending paragraph

// Fill in the third offset account (where possible) update_recordSet offsetAccountTmp setting OffsetAcct3 = mainAccount.MainAccountId join MainAccountId from mainAccount where mainAccount.MainAccountId != offsetAccountTmp.OffsetAcct1 && mainAccount.MainAccountId != offsetAccountTmp.OffsetAcct2 exists join dimensionAttributeValueCombinationr where dimensionAttributeValueCombination.MainAccount == mainAccount.RecId exists join generalJournalAccountEntry where generalJournalAccountEntry.LedgerDimension == dimensionAttributeValueCombination.RecId && generalJournalAccountEntry.GeneralJournalEntry == offsetAccountTmp.GeneralJournalEntry && generalJournalAccountEntry.RecId != offsetAccountTmp.GeneralJournalAccountEntry;

Show all fields: Property name has max length 40

I spent some time today with the following error:
The user right-clicked an Advance Invoice record, then chose "Record Info", then "Show all fields" and got the tasty error message below:

Property Name has max length 40. An attempt to set it to a string having length 41 has been made.

You would get similar error messages, if you called the same function on the Advance invoice lines, though then it would say length 45.

The solutions: the SysRecordInfo Form on the SYP layer contains a bug.

The problem is with the line marked with red (duh).

showAllFieldsForm.name('_ShowAllRecords_'+dictTable.name());

The Form's name can be only 40 characters long. The DictTable.name() is "CzCustAdvanceInvoiceTable" (25 chars) + _ShowAllRecords_(15 chars) is too long. Tough luck.

I don't know which KB article dropped the ball on this one, but it's okay in SYS layer, and wrong in SYP layer.

I took the easy way out and simply removed the '_ShowAllRecords_' from the function call, and presto!, it worked.

AX: Original (installed configuration) in registry for new users

The back story

We have a terminal server used by nearly a hundred users simultaneously to launch AX clients. The AX client had been installed a while back, and since then the original AX farm has been extended, some of the servers have been marked as dedicated batch servers, etc. Long story short, the "original configuration" in the registry is pretty much useless at this moment.

Of course they are all using .axc files to connect to the AOS, but unfortunately when AX crashes (and oh boy, does that happen), it nicely offers to restart. However, at restarting it does NOT use the same configuration it was started with, it defaults to the one stored in the registry, and the user arrives to an AOS where he is not supposed to be.

The task

Update both all of the current AX configurations and the default configuration for new users to a correct set of AOSes.

The solution

all users
The users part is pretty straightforward: under HKEY_USERS\<SID>\Software\Microsoft\Dynamics\6.0\Configuration\Original (installeded configuration), the information is stored in the AOS2 and WSDL string values. If you want to add more than one AOS, in then you can list them separated with a semicolon

default user
However the default user profile is not stored under HKEY_USERS\.Default, but is copied from HKLM, when the client launches his first AX using registry. If he always launches AX using an connection file, the registry keys are apparently not created. 

Also, this is where the configuration for Business Connector is stored

The following script will fix all of the above, for all the configs of all the users

#New valid values $AOS2= "AOSSERVER:2712" $WSDL= "8101" #Save current script location Push-Location #Into the registry we go! Set-Location Registry::\HKEY_USERS #Iterating through all the users foreach($sid in $(ls)){ if(Test-Path "\$sid\Software\Microsoft\Dynamics\6.0\Configuration\") { Set-Location "\$sid\Software\Microsoft\Dynamics\6.0\Configuration\" #Iterating through all the configs of the user foreach($config in $(ls)) { Set-Itemproperty -path "$($config.PSChildName)" -name "aos2" -Value $AOS2 Set-Itemproperty -path "$($config.PSChildName)" -name "wsdlport" -Value $WSDL } } } #HKLM stores the default users config, should only have the Original (installed configuration) config, #no need to check all the configs here Set-Location Registry::\HKEY_LOCAL_MACHINE\Software\Microsoft\Dynamics\6.0\Configuration\ Set-Itemproperty -path "Original (installed configuration)" -name "aos2" -Value $AOS2 Set-Itemproperty -path "Original (installed configuration)" -name "wsdlport" -Value $WSDL #Back to the original path Pop-Location

AX installation needs file sharing to be enabled on the SQL server

Today during an AX installation I got the following error in the DynamicsSetupLog.tct


Checking for the existence of the service 'MSSQLFDLauncher' on the machine 'SQLSERVER'.<br /> *** ERROR ***<br /> Cannot open Service Control Manager on computer 'SQLSERVER'. This operation might require other privileges.<br /> Cannot open Service Control Manager on computer 'SQLSERVER. This operation might require other privileges.<br /> The root cause was that the SQL server (a Windows Server 2012) didn't have File sharing enabled amongst its roles, so AX couldn't verify if an SQL component was installed. Solution: After I enabled file sharing on the target server, the setup continued without any further problems.