I'm encountering an issue where a company has more than one domain.
Let's say we have domain "DomainA" and "DomainB". AX 2012 R2 (+CU7) is installed on DomainA.
All users are setup with their own domain. They can use the system, e.g. writing timesheets regarless if they are in DomainA or DomainB.
The problem is when the workflow tries to assign a user from DomainB as approver for the timesheet. The workflow stops with the error: "Failed to create a session; confirm that the user has proper privileges to log on to Microsoft Dynamics."
The user has also an email account for DomainA which is the one they should use. Now if I setup this user as DomainA the workflow continues.
Problem is that he cannot login hiself with the DomainA account on the network. He should use DomainB.
Another funny thing is that, when I change the SID in the user info table for this user to the SID belongs to DomainA, the workflow also continues, but he then also cannot log on within AX client himself.
Did anyone encountered this problem before or knows a workaround? It is not possible to convert the user to DomainA yet...
Can we consider this as a bug in AX 2012?
André Arnaud de Calavon | Microsoft Dynamics AX Solution architect | My blog | My company
This post is my own opinion and does not necessarily reflect the opinion or view of my company, Microsoft, both its employees, or other MVPs.
I never faced this issue, but in my opinion is a Bug.
What do you mean with "Problem is that he cannot login hiself with the DomainA account on the network. He should use DomainB"
Thanks & Regards
Senior Technical Architect
Thanks for your interest. I would like to make it the problem for someone else :-(.
The people did get an email account in AccountA. This happens to be the same network alias, only within DomainA. So the same alias is known in Active Directory with DomainA and DomainB for people coming from DomainB.
Strange is that the import wizard only can show the people listed in DomainA and not DomainB. By manual creation of the users we can enter these people with the DomainB network domain.
After reading well, could be a trust domain problem.
The domains are "two-way" trusted?
From domain B you are able to ping the AX Server, installed on Domain A?
If no, add host entry of the AX Servers in domain B
Sorry for the late answer. Due to illness from several people including myself, we were not able to verify your last question.
I was thinking it could be related to having the same network alias in both network domains where some AX logic will assume this alias should bbe unique across the network.
I will come back later.
I have more details now. There is a domainA and a domainB.
DomainB is divided into other sub domains per region.
There are no users in DomainB
The users with the problems are in the sub domains.
There is a two-way trust between domainA and DomainB.
Also there are two-way trusts between DomainB and the sub domains.
There is NO direct two-way trust between DomainA and the sub(region) domains.
It is strange that the user is able to run AX (client and EP) while the RunAs command raises an error.
What are your thoughts?
A interesting test, could be create a simply class where try if RunAs work fine for a Sub Domain user.
Just to understand if the problem is on RunAs command.
If doesn't work, mean that RunAs have some issue with the Sub Domains and you can open a MS case with more details.
Hi André, can you find any solution for this problem. i've same problem.
Out of the 250 users only 2 had this problem as almost all approvers were already in Domain A. These persons were migrated to the new Domain with some priority.
Can you try to see wheter domain trusts could help? At the customer we could not do anything related to the trusts because of other dependencies.
Thanks for answer. We have checked trusted domain each other. no problem for this case. So I think it is a bug. User can login AX from different Domain. Class SysWorkflowDocument.assert() method have run as code. Maybe there is a problem in this code. Did you open a issue to MS about this before?
The customer did not report this to Microsoft as it was solved in another way.