The issue: When firming a production order sometimes it may cause for all
the AOS's in a cluster to crash and restart.
The setup: 2 AOS cluster with 1 Batch AOS (3 AOS's in total)
The research: Because firming the PO sometimes would not crash the AOS's I
looked into the windows log whenever it did and found the following error:
Object Server 01: An error has occurred in the services
framework. Method: AifMessageInspector::AfterReceiveRequest. Error:
System.ServiceModel.FaultException: Failed to logon to Microsoft Dynamics
AX.
at
Microsoft.Dynamics.Ax.Services.AxServiceOperationContext.InitializeSession()
at
Microsoft.Dynamics.Ax.Services.AxServiceOperationContext.InitializeContext()
at
Microsoft.Dynamics.Ax.Services.AxServiceOperationContext.Attach(OperationContext
owner)
at System.ServiceModel.ExtensionCollection`1.InsertItem(Int32 index,
IExtension`1 item)
at System.Collections.Generic.SynchronizedCollection`1.Add(T
item)
at
Microsoft.Dynamics.Ax.Services.AifMessageInspector.AfterReceiveRequest(Message&
request, IClientChannel channel, InstanceContext instanceContext)
Because the begining of the message contains "Failed to logon to
Microsoft Dynamics" you know it is something dealing with creditials. Currently
we have an account for the service called domain\AX_AOS_Service and an account
for the .NET Business Connector called domain\AX_BusCon so I knew that it had to
deal with one of these.
Action/Solution (Here is what I did to fix the issue):
- Make sure an SSRS default config instance is available for every aos.
Including the batch server
- Add the AOS service account to the users in AX. This account should be added
to the groups "System User" and "System Administrator" (leave employee off)
- Changed the report servers within AX from looking at a single sql server to the sql cluster
(individual server vs SQL cluster)
- Changed the "Batch Group" (under system administration > setup > batch group) so that
only batch servers were listed in any of these and the empty batch group was
changed to have no servers. Before it contained non batch servers listed as
batch servers
- Restart all 3 AOS's (Microsoft service/via services.msc)
- After restarting the AOS it would still crash but not as often. I would
also now start get the following message instead of the original one
- The description for Event ID 180 from source Microsoft
Dynamics AX cannot be found. Either the component that raises this event is not
installed on your local computer or the installation is corrupted. You can
install or repair the component on the local computer. If the event
originated on another computer, the display information had to be saved with the
event. The following information was included with the event:
Microsoft Dynamics AX Business Connector Session 9.
RPC exception 1722 in Ping occurred in session 19 ,process: Ax32.exe
,thread: 8456
- This message tells us that there is still an issue but no longer a specific
one but generic. These type of messages are usually fixed by a system
reboot.
- Restart all 3 AOS's boxes and not just the service (systems/windows)
Update:
Issue continues to be random even after all of this. After looking at a KB article from Microsoft we have also added the AX AOS Service & Bus Con accounts to the Active Directory groups
Windows
Authorization Access group & Pre-Windows 2000 Compatibility Access group (within active directory)
But we still seem to have to have the same issue. I will keep this article updated with anything else we try.
Update 3/11/15: The issue continues and we started to work with Microsoft and they were able to track down the class & table that was causing the issue. It appears there is a KB fix for this specific issue.
Issue Location: \tables\ReqTrans & \class\ReqTransPoMarkFirm
KB2936744
PROBLEM
Update on ReqTransPoMarkFirm crashing Application Object Server (AOS).
DESCRIPTION OF CHANGE
The changes in the hotfix resolve this issue.
The table method ReqTrans.reqTransDirectlyDerived() is using a code pattern that’s not supported. As hightlighted below, the method is returning a table variable that’s in the JOIN clause and holds a where condition that references a local table variable (i.e. reqTransCov). This leads to invalid cursor when ::update is called upon the returned table variable.
Changing the X++ select in ReqTrans.reqTransDirectlyDerived() so that reqTrans is the main and reqTransCov is in the JOIN clause. Since ReqTransCov is never used, put it in exists join.
You may also need KB2629981 - Orders can be firmed more than once, which leads to duplicate planned orders.
With the issue of AifMessageInspector::AfterReceiveRequest. Error: System.ServiceModel.FaultException: Failed to logon to Microsoft Dynamics AX.
If you turn off debugging on the specific aos it will no longer appear.
