locked
Failed to start workflow. Access is denied. (Exception from HRESULT: 0x80070005 (E_ACCESSDENIED)) RRS feed

  • Question

  • Hi,

     

    We are having a problem with the Workflows STOPPING, for certain users. We are using WSS 3.0 and SQL Server 2005 64bit. The problem occurs when the user tries to start the workflow. The user has full control in the site and has absolutely no problem in editing any list, library or workflow etc..

     

     

    Additional info, These users are in an AD group. This AD group is added to the Sharepoint group that has a role associated to it.

    However if these very same users are added directly into the Sharepoint group rather than through the AD group, then there is no problem. The workflow works as per normal.

     

    Pls help.

     

    MR

     

     


    MR
    • Moved by Mike Walsh FIN Friday, September 2, 2011 10:47 AM As there is a workflow forum for pre-SP 2010, use it (From:SharePoint - Setup, Upgrade, Administration and Operation (pre-SharePoint 2010))
    Friday, September 2, 2011 9:41 AM

Answers

  • Hi MR,

     

    If the users participating in the workflows have been added to the SharePoint site via Active Directory groups, SharePoint has to update the user’s security token periodically by connecting to the domain controller. By default, the token times out every 24 hours. But if the application pool account did not have the right permissions on the domain controller to update the user’s token, user will keep getting the access denied error. The error was intermittent because when the user browsed to any page other than the workflow form, the token was getting updated successfully.

     

    You can try to fix it through granting the application pool account the appropriate permission by adding the account to the group “Windows Authorization Access Group” in Active Directory.

     

    Hope this helps.

     

    Thanks,

    Pengyu Zhao

    • Marked as answer by Pengyu Zhao Tuesday, September 13, 2011 3:21 AM
    Monday, September 5, 2011 6:07 AM

All replies

  • Hi,

    Additional info - I also noticed that if this AD group is removed and added again into the Sharepoint group, the listed AD users can start the workflow for about 1 or 2 days. Thereafter these users again face the workflow STOPPED issue when they start any workflow in this library!!

     

    Thanks,

    MR


    MR
    Monday, September 5, 2011 1:40 AM
  • Hi,

    I enabled the sharepoint logs and tested again. I found the following ("PermissionMask check failed") logged into the log files. It looks like a clue? Thanks, MR

     

     Looking up the additional information about the typical site http://mytestserver1.mycompany.com.sg:80/sites/ecn/Workflows/spd_testwf2/spd_testwf2.aspx?List=e0c008fd-0d1e-4921-9667-038893e8b3da&ID=1348&TemplateID=%7B67469805-8760-4f58-8973-ce0665352651%7D&Source=http%3A%2F%2Fmytestserver1%2Emycompany%2Ecom%2Esg%2Fsites%2Fecn%2FSGAKVCLECN%2FForms%2FAllItems%2Easpx
    09/05/2011 10:47:59.64  w3wp.exe (0x058C)                        0x0E3C Windows SharePoint Services    General                        6t8f Verbose  Site lookup is replacing http://mytestserver1.mycompany.com.sg:80/sites/ecn/Workflows/spd_testwf2/spd_testwf2.aspx?List=e0c008fd-0d1e-4921-9667-038893e8b3da&ID=1348&TemplateID=%7B67469805-8760-4f58-8973-ce0665352651%7D&Source=http%3A%2F%2Fmytestserver1%2Emycompany%2Ecom%2Esg%2Fsites%2Fecn%2FSGAKVCLECN%2FForms%2FAllItems%2Easpx with the alternate access url http://mytestserver1.mycompany.com.sg
    09/05/2011 10:47:59.64  w3wp.exe (0x058C)                        0x0E3C Windows SharePoint Services    General                        6t8g Verbose  Looking up typical site http://mytestserver1.mycompany.com.sg:80/sites/ecn/Workflows/spd_testwf2/spd_testwf2.aspx?List=e0c008fd-0d1e-4921-9667-038893e8b3da&ID=1348&TemplateID=%7B67469805-8760-4f58-8973-ce0665352651%7D&Source=http%3A%2F%2Fmytestserver1%2Emycompany%2Ecom%2Esg%2Fsites%2Fecn%2FSGAKVCLECN%2FForms%2FAllItems%2Easpx in web application SPWebApplication Name=SharePoint - 80 Parent=SPWebService. 
    09/05/2011 10:47:59.64  w3wp.exe (0x058C)                        0x0E3C Windows SharePoint Services    General                        6t8h Verbose  Found typical site /sites/ecn (66541daf-75ed-4215-88f0-cfbe5d8e6f86) in web application SPWebApplication Name=SharePoint - 80 Parent=SPWebService. 
    09/05/2011 10:47:59.66  w3wp.exe (0x058C)                        0x0E3C Windows SharePoint Services    General                        8xfr Verbose  PermissionMask check failed. asking for 0x00000005, have 0x00011001 
    09/05/2011 10:47:59.66  w3wp.exe (0x058C)                        0x0E3C Windows SharePoint Services    General                        8xfr Verbose  PermissionMask check failed. asking for 0x00000015, have 0x00011001 
    09/05/2011 10:47:59.66  w3wp.exe (0x058C)                        0x0E3C Windows SharePoint Services    General                        8xfr Verbose  PermissionMask check failed. asking for 0x00000041, have 0x00011001 
    09/05/2011 10:47:59.66  w3wp.exe (0x058C)                        0x0E3C Windows SharePoint Services    General                        75g4 Verbose  Usage: Rights and Roles: GetWebPartPage: Shared 
    09/05/2011 10:47:59.66  w3wp.exe (0x058C)                        0x0E3C Windows SharePoint Services    Web Controls                   90i3 Verbose  PersonalActions::CreateChildControls() - Was called.

     

     


    MR
    Monday, September 5, 2011 3:10 AM
  • Hi,

    Just a couple of links that you can refer to for this error. I will also try to look more into this and give you some more information that might help you. But meanwhile just try to have a look at these links and see if anything you find out.

    http://social.msdn.microsoft.com/forums/en-US/sharepointworkflow/thread/136a2b04-1134-4c24-9709-32f12f127544/

     

     

    Will look more into this little later. But just for pointers that might help you refer above.

     

    Regards,

    Geetanjali


    • Edited by Mike Walsh FIN Friday, September 16, 2011 6:22 AM second and third links removed. Both go to the SP 2010 versions and are thus off-topic
    Monday, September 5, 2011 3:40 AM
  • Hi MR,

     

    If the users participating in the workflows have been added to the SharePoint site via Active Directory groups, SharePoint has to update the user’s security token periodically by connecting to the domain controller. By default, the token times out every 24 hours. But if the application pool account did not have the right permissions on the domain controller to update the user’s token, user will keep getting the access denied error. The error was intermittent because when the user browsed to any page other than the workflow form, the token was getting updated successfully.

     

    You can try to fix it through granting the application pool account the appropriate permission by adding the account to the group “Windows Authorization Access Group” in Active Directory.

     

    Hope this helps.

     

    Thanks,

    Pengyu Zhao

    • Marked as answer by Pengyu Zhao Tuesday, September 13, 2011 3:21 AM
    Monday, September 5, 2011 6:07 AM
  • Hi Pengyu Zhao,

    I will need at least a days time to get to the team on the other side of the globe. This Active Directory is on the other side. I will request them to add my sharepoint's app pool account into “Windows Authorization Access Group” in their Active Directory.

    Thanks much!

    MR


    MR
    Monday, September 5, 2011 9:42 AM
  • Hi Pengyu Zhao,

    I'm currently at it. Meanwhile i was just curious, so i thought i would check with you.

    You mentioned that "by default, the token times out every 24 hours". So, is there a way to prevent this time out such that sharepoint doesnt have to update the user's security token periodically?

    Thanks !

    MR


    MR
    Tuesday, September 6, 2011 2:03 AM
  • Hi Pengyu Zhao,

     

    I receiving feedback from the the other team that this group “Windows Authorization Access Group” does not exist in their Active Directory!

    Thanks,

    MR


    MR
    Thursday, September 8, 2011 8:51 AM
  • Hi MR,

     

    This is a “Builtin” group, so it should be there.

     

    You can find it through open Active directory Users and Computers>Click on "Builtin" >"Windows Authorization Access group" should be on the bottom of right side.

     

    Thanks

    Pengyu Zhao

    Friday, September 9, 2011 1:07 AM
  • Hi Pengyu Zhao,

     

    No, It is not listed in there. Pls see attachment.

     

    MR


    MR
    Friday, September 9, 2011 6:03 AM
  •  

    Hi MR,

     

    What is the vision of your server?

     

    You can refer to:

    http://support.microsoft.com/kb/331951

     

    Thanks,

    Pengyu Zhao


    • Edited by Pengyu Zhao Friday, September 9, 2011 6:38 AM
    Friday, September 9, 2011 6:36 AM
  • Hi Pengyu Zhao,

    Thanks. Should i  try to include the sharepoint account into this 'Pre-Windows 2000 Compatible Access' group instead ?

    Thanks,

    MR


    MR
    Friday, September 9, 2011 8:15 AM
  • Hi MR,

     

    You could try this. If it not works, you can grant access permissions to the TGGAU(token-groups-global-and-universal) attribute for that group. For this you can refer to:

     

    http://support.microsoft.com/kb/331947

     

    Thanks,

    Pengyu Zhao

    Friday, September 9, 2011 9:11 AM
  • I had the same problem: Workflows kicked, off by users that were give permission through an AD security group, were suspending.  I tried the solutions mentioned here and they didn't help.  The correlation ID is hidden in plain sight in the Suspended error message and looks like this:

    "SPRequestGuid":["ef1daf86-d098-5f5f-803b-79d047e981be"]

    Filtering the ULS logs using the ULSViewer I found these two errors:

    12/18/2015
    09:39:21.37        w3wp.exe
    (0x62A8)        0x13FC        SharePoint
    Foundation        Application
    Authentication        ajwpx        Medium        SPApplicationAuthenticationModule:
    Failed to build cache key for user        ef1daf86-d098-5f5f-88b0-e0ee5e75f6d5

     

    12/18/2015
    09:39:21.47        w3wp.exe
    (0x62A8)        0x3EFC        SharePoint
    Foundation        CSOM        ajwqh        High        The
    request does not have required permission to access
    SP.RequestContext.Current        ef1daf86-d098-5f5f-88b0-e0ee5e75f6d5

    After googling for a while I found this article:

    Solution 1:

    In
    InetMgr, go to advanced settings for Security Token Service Application Pool
    and change "Load User Profile" to true. Recycle application pool.

     

    Reason 2 and Solution 2 : There
    could be another reason for this error. The workflow authentication can fail if
    the user is given permission through active directory group and the container
    for this group is not selected to be synchronised in the active directory
    connection.

     

    From
    blog.houratious.com/2014/06/sharepoint-2013-workflow-server-was.html

    I added the AD security group to my User Profile Service Synchronization configuration, performed a sync, and I can resume the suspended workflows.

    Thank you Houratious Albert! 


    • Edited by Joe Spadea Friday, December 18, 2015 4:40 PM formatting
    Friday, December 18, 2015 4:38 PM
  • I faced similar issue, In my case the users through AD group couldn't initiate workflow only for a particular workflow. The issue happened because I copied the workflow, You can copy steps but if you copy a workflow as such this error will occur
    Friday, May 3, 2019 6:44 AM