Quantcast
Channel: Microsoft Dynamics 365 Community
Viewing all articles
Browse latest Browse all 64797

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

$
0
0

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.

publicstaticservervoid main(Args _args)
{
    container  result, args;
    UserInfo    UserInfo;

    whileselect 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

Viewing all articles
Browse latest Browse all 64797

Trending Articles



<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>