Workflow: Failed to create a session; confirm that the user has the proper privileges to log on to Microsoft Dynamics.

July 24, 2015 at 17:38
filed under Dynamics AX
Tagged , , , , , ,

On AX2012 FP the vendor invoice line workflow was throwing the following error which caused the workflow to stop:

Failed to create a session; confirm that the user has the proper privileges to log on to Microsoft Dynamics.

I couldn’t really figure out what was wrong, but the internet said “do a full compile and full CIL”. So I did, it didn’t help.
My colleague had a blog post about this error but that was about partitions and these are only available on R2 and R3, not on Feature Pack, so that was no help either.

After some debugging, it was clear that the error was thrown when the runAs function was executed. So I created a class and put the following method in it to test which users could not execute the runas function successfully. In this example I use the SysWorkflowDocument::assertAsUser method but it is better to create your own empty static method to test with. Remember that you have to perform an incremental CIL compilation after you have created a new static method to use in the runAs function.

public static server void main(Args _args)
{
    container   result, args;
    UserInfo    UserInfo;

    while select id from UserInfo
    {
        try
        {
            new RunAsPermission(UserInfo.id).assert();
            result = runAs(UserInfo.id, classNum(SysWorkflowDocument), staticMethodStr(SysWorkflowDocument, assertAsUser), args);
            CodeAccessPermission::revertAssert();
        }
        catch
        {
            CodeAccessPermission::revertAssert();
            info(UserInfo.id);
        }
    }
}

This gave me a list of all users that were causing problems. Everything seemed fine with these users, so I decided to check if the SID in the UserInfo.sid field matches those on the domain for those users. I didn’t. Most likely these users were deleted on the domain and recreated with the same username, but a different SID. After the users were deleted in AX and the imported again, the error disappeared.

By the way, you can retrieve the SID of a domain user using Windows PowerShell with this command:

$objUser = New-Object System.Security.Principal.NTAccount("YOURDOMAIN", "YOURUSERNAME")
$strSID = $objUser.Translate([System.Security.Principal.SecurityIdentifier])
$strSID.Value

no comments

RSS / trackback

respond