Arijit Basu: AX 4 AOS Basics: [Level 100]

[Blog bot]

Источник: http://daxguy.blogspot.com/2007/11/a...level-100.html
==============

You are well aware that AX 4.0 has gone some serious Architectural change . If we consider the "Chart Of Accounts" as the functional heart of an ERP system, then the AOS is the technical heart of AX :). Its a very important pece in AX and it has undergone significant changes in 4.0. I'll point some major ones for techie folks who are new to AX.

AOS changed to Windows service
The Dynamics AOS is now a True windows service and can be viewed in Services.msc window. It also means that AOS Exceptions is available in the Windows event viewer. In case of any issues regarding AOS errors, the same can be viewed in the Windows Event Viewer.Also the 2-Tier configuration has been removed. All connections via 3 Tier AOS Authorized only :)

Dynamics Server$instance-numberAOS-instance-name.
AOS Service:


AOS Logs in the Windows Event viewer:




Session management
Session info moved to database - No more .udb file in the application file folder which means no more writing the user sessions in the .udb file. The user session management has been migrated to the database making it possible to manage all user and business connector sessions from one console. It also makes it possible to view all AOS sessions from 1 console which was not available in AX v 3.x.User specific information is now stored in the database.


Active directory integration
All users must use AD Authentication to access the AOS. Also no more ‘sa’ / ‘bmssa’ authentication. Normally when we install the AOS, the default User is NT AUTHORITY\NETWORK SERVICEThis is not recommended in a production environment and the AOS must have separate Domain accounts with adequate rights and privileges.
The AOS account must be a user in the database and be assigned to the following database roles
• db_ddladmin,
• db_datareader, and
• db_datawriter
Also the AOS user must have execute rights to the following stored procedures in the AX Database
• createserversessions
• createusersessions



Normally when we install AOS, we select NT AUTHORITY\NETWORK SERVICE as the AOS Startup account. Later when we go to services and want to change the startup Account, the changes must also be made in the database for the new AOS User account.

Other Improvements

• You can easily restrict number of sessions for an AOS. You can now restrict the nos. of connections an AOS can accept from the AOS Server Manager utility in the main page.




• Load Balancing - You can now dedicate an AOS instance as a “load balancer”. For this you do not need a high end server. This piece will access all incoming requests and distribute to the available AOS Servers. Kind of useful in TS scenario. Also now we have NLB clustering features available.



• You can easily drain stop an AOS before removing from a cluster. It is useful for maintenance mode and during upgrades. This reduces downtime of the application.


• The proprietary AOCP (AX v 3.x) has been replaced by RPC. Improved Client Server calls.


• Enhanced server API securityLot of work has been done regarding security API & CAS.
Lot of new security API’s are available. (For reference see the whitepaper by MFP – “Writing secure code in Microsoft Dynamics AX

• Secured write access to the AOT & table permissions framework AOS
Table permissions framework helps avoid unauthorized access to AX system tables. Normally when we use the .NET BC / COM connector by validating against a AD User, the AD user Security (Set in AX) is bypassed :(.
This is security vulnerability. In AX 4.x, the table permission framework has been introduced to counteract this issue. It also means that now we can secure access to the AOT Tables. In the Table property sheet, we have a new property called AOS Authorization with the following values as shown. By default its set to ‘None’ for all tables except the System Tables (See table SysUserInfo where this property has been set to “CreateDelete”).




The AOS Authorization property helps us to enable security @ the server tier. In simple words, it tells to validate User Permissions for any CRUD operations on that table. The options for this property are shown above. If we select “Create Delete” then it will enforce User Permissions for Create & Delete operations on that table. If we select “CreateReadUpdateDelete” then it will enforce User Permissions for all operations on that table. That’s smart :).You also have this at the table level for specific user levels. There are 4 new methods in a Table.





• AOS authorization – All authentications via Active Directory.

• 64 Bit Table Level RecId – Now no more worrying about running out of RecId’s :)

HAPPY DAX - ing :)

Источник: http://daxguy.blogspot.com/2007/11/a...level-100.html