AxUtil and the application log

hi there,

During the set up some 2012 environments lately, we got warnings like

An error occured in writing to the event log on machine <DBServer>: cannot open log for source 'Microsoft Dynamics AX - AXUtil. You may not have write access.

when we're using the axUtil or perform actions where the axUtil tool is used behind the scenes.

It seems the problem occurs when the account running the AOS instance does not have sufficient privileges on the database server hosting the AX database.

You can go all wild add the AOS service account to the administrators group on the DB server. Or you can handle it more suble by just granting that AOS service account write access to the application log.

Windows comes with a nifty tools (called 'wevtutil') to regulate this. You can read all about it here.
What we did to solve the issue is:
- open an elevated command prompt on the DB server
- run 'wevtutil gl appication > c:\temp\out.txt', which will give you a textfile containing the security settings for the application log
- from that texfile, you copy the (seemingly uncomprehensable, but all part of MS's security descriptor definition language (SDDL)) expression that's after the 'channelAccess: ' keyword. This is the string that actually defines who has (or hasn't) access to the application log
- now you need to make sure the AOS service account is added to that string. I took the easy way and gave all 'authenticated users' the 'file write' permission by adding '(A;;FW;;;AU)'.
- the last step is to send that modification back into the system using the 'sl /ca' option on the wevtutil command: 'wevtutil sl Application /ca:<the modified channelAccess string>'

I got my inspiration on 'The Raven Report' blog, so it's only fair to mention that.

bye

Name based versus Id based

hi guys,

I'm programming some new functionallity that requires setup based on tables, fields, methods and classes. At first my solution used tableIds, fieldIds and classIds on the setup tables to store the required values. But then I figured out there will be a point in time the user will come with the question 'how he can copy the setup from the test to the production environment?'. And then it hit me: there's no guarantee whatsoever that a specific table.field combination in two environments will have the same tableId and fieldId. Same goes for classes: a class does not necesseraly have the same Id in different environments.
Or in other words: I'd had to disappoint the poor guy who putted all the effort in setting up and testing the solution in a pre-production environment.

Hey, but wait a minute! Maybe I don't have to disappoint him ...

What about this ID-issue they'd solved in Ax2012? Is that not helping me then?
Sure it is: each object gets an installation specific ID that will never ever change. That is: if you honour the best practices and don't intentionally ty to mess it up ... . Ok then, but will this solve my data export/import issue? Yes it does: the standard Ax data import/export functions have been improved to handle this. Check the full details on  http://blogs.msdn.com/b/mfp/archive/2011/07/11/the-solution-to-the-element-id-problem.aspx.
So Ax2012 does offer great advantages over previous versions regarding object ID's. And the poor guy testing my solution can export his setup from test to production.

In the end I did decide to rewrite my solution and make it name based over ID based.
Why? Because I figured it could as well be name based: this would make the code more clear to read, understand, debug and export/import would still work fine.
And also because I do have the  impression there's a shift to name based in Ax2012:
- new constructor methods 'newName' on for instance SysDictClass, sysDictTable and sysDictField
- the typical dimension[1, 2, 3] fields are gone and replaced by a new dimension framework and the corresponding bitwise-shifting-methods like fieldId2ext and fieldExt2Id are far less used throughout the application. All this makes name-based usage easier.

So should you code ID based or name based? I'm going for name based with Ax2012.
But I think there's no general rule on which of the two is better.
It's worth taking a minute or two to evaluate your situation (think about export/import, maintainability) before taking the decision.

bye

The model store has been modified

hi folks,

I've been involved in creating build scritps for Ax2012 over the last few months and have encountered (and conquered) a number of ... well, let's cal them 'obstacles'.

One of them is the 'the model store had been modified' dialog that pops up the first time you start an Ax client after the model store was modified. It actually gives you some options (start checklists, compile and sync or just skip the whole affair).
But  sometimes this happens: you don't manage to select any option. I mean: you can click an option, but it does not get selected. In fact: the (modal) dialog (including the OK/cancel/close buttons) does not react at all.

My workaround is to start the Ax client directly in a developer workspace (ax32.exe -development), where you get the same 'modelstore modified' dialog, but it does react when you click it.

Another option is to undo the installmode setting on the modelstore (axutil.exe set /noinstallmode) which prevents the modelstore modified dialog from popping up, and fire the compilation, CIL generation an synchronisation (or any option you whould have chosen) manually.


Don't know why this happens, I just hope I save someone some valuable time with this workaround.


bye!