none
Failed to start macro 'VerifyUsers' after site collection restore containing Access Web DB site

    Pertanyaan

  • We are getting the error "Failed to start macro 'VerifyUsers'" after site collection restore of a site collection containing Access Web DB site. This is SP2010 Enterprise SP1 + FebCU.  Here are repro steps:

    • Create a site collection using the blank site template
    • add a subsite using one of the OOB web databases (ie Asset Web Database site template)
    • Browse to access db site
    • Observe it works as expected
    • Backup the site collection using Backup-spsite
    • Remove the site collection using Remove-spsite
    • Restore the site collection using Restore-spsite
    • Browse to access db site
    • Observe error 'Failed to start macro 'VerifiyUsers'

    ULS logs report:

    Exception Very serious error happened when trying to open web to start data macro workflow. Macro has not been started. System.IO.FileNotFoundException: The site with the id d52542f0-f36a-4ff4-af2b-35214e920b19 could not be found.     

    Get-spsite confirms there is no site with the given id. Presumably, some part of the access db is referencing the old site id, though I cannot find it in web or site properties, or by opening the db in access and examining the macro, etc.

    30 Mei 2012 17:28

Semua Balasan

  • Hello,

    Thank you for your post.

    This is a quick note to let you know that we are performing research on this issue.

    Thanks,


    Pengyu Zhao

    TechNet Community Support

    01 Juni 2012 10:10
  • Thank you.  I am noticing that after leaving it overnight the error goes away.  I suspect an iisreset or some other process cleans up a cache somewhere that references the "old" id? I have not tried an iisreset yet to confirm since this is a production environment.  May try after-hours today.
    01 Juni 2012 13:17
  • Hi Danroot,

    I did some testing using the steps you outlined in your initial thread; however I could not reproduce the issue you did. One thing I did notice during the restore though was that my sub site did not become immediately available and I received a 404 not found when attempting to browse the sub site for a minute or so but eventually became available.

    Depending on how much content you have, the restore process may still be in progress when attempting to restore the site which causes the issue you are seeing. I have seen previous issues with customers restoring large backups and during the time of the restore attempt to access the site causing information to be inserted into the table and the restore then eventually failing due to record already existing in the database.

    Let me know how large the backup is and how quick you are attempting to browse the site. It may be just that you are attempting to browse the site too soon before the restore process has completed fully or like your latest post indicates a job was run. It's hard to tell at the moment without full logs to review to see what was happening in the back end.

    Thanks!


    Adam Rudell | Technical Support Lead | SharePoint Technologies | Microsoft Corporation


    04 Juni 2012 20:05
  • Thanks for trying it out.  The size of the site collection backup is 28M.  We wait until Restore-SPSite completes before going to the site.  Other non-Access sites work fine, and we don't get any 404s.  It's just this macro that fails, and ULS indicates it's still looking for the "old" site id.  I can try restoring, waiting 10 minutes, then browsing the site.    

    04 Juni 2012 21:33
  • Doesn't sound like the restore would be in process then if your navigating to it especially with it being that small in size. With the backup and restore, the SiteID and all the GUIDs for that matter should remain the same so weird that its not locating it after the restore.

    Are you able to reproduce the issue again on demand in your environment?


    Adam Rudell | Technical Support Lead | SharePoint Technologies | Microsoft Corporation

    05 Juni 2012 15:46
  • I can repro on demand in my environment, though I obviously can't get it in a working state except by waiting overnight.  Looking at the Ids using Powershell. The _web_ ids do stay the same after restore-spsite, but the Site Collection Ids are different.  

    $s1 = get-spsite http://some/sites/site

    $s1.Id

    remove-spsite http://some/sites/site

    restore-spsite http://some/sites/site -path site.bak

    $s2 = get-spsite http://some/sites/site

    $s2.Id

    $s2.Id -eq $s1.Id

    My understanding from the ULS error is that Access Services is still looking for the old site collection id (ie, $s1.Id).

    05 Juni 2012 17:26
  • So I went through your steps and even though I cannot reproduce the issue I do see our IDs change for the Site Collection. Initial research I did not find any issues regarding backup / restore with Access Web Databases however I did find information regarding the Access Macros and SharePoint and found the following information regarding same error message you are receiving:

    "This happens because Access Macros are converted into Workflows when run by the Access Database Service. When the server running on Access Database Services does not have the Microsoft SharePoint Foundation Web Application service the Access Database Services is unable to retrieve the Workflow configuration settings from the Web Application's Web.config file."

    Do you maybe have a server deployed that has Access Database Services running but does not have the Microsoft SharePoint Foundation Web Application service running? I could maybe see it having issue during the conversion process of the Access Macros being converted to a workflow. Other than this I would suggest possibly opening a support ticket (http://support.microsoft.com/ph/935)  so that we can dig further into the logs.


    Adam Rudell | Technical Support Lead | SharePoint Technologies | Microsoft Corporation

    • Ditandai sebagai Jawaban oleh Rock Wang– MSFT 07 Juni 2012 6:37
    • Tanda sebagai Jawaban dihapus oleh danroot 14 Juni 2012 13:24
    05 Juni 2012 20:04
  • The server running access service has SharePoint Web Application service, so that is not the applicable answer.  I guess we'll open a ticket or else tell users not to use Access Services.
    14 Juni 2012 13:26
  • That may be the best route so that way we can analyze the logs and do some deeper analysis to determine why the restore is not functioning properly in your environment for the data web access templates.

    Adam Rudell | Technical Support Lead | SharePoint Technologies | Microsoft Corporation

    14 Juni 2012 14:15
  • I have also been getting this error

    "failed to start macro 'VerifyUser' in an Access Web database"

    The web database was working fine and then out of the blue this message appeared.

    When synchronising I started to get the following message:

    "The RunDataMacro action failed to invoke a data macro on the server. Please check your connectivity to the server."

    I recreated the data macro and that too gave the same error message.

    So I would be interested to hear if you find the route cause.

    Will you continue to post about this issue?

    Many thanks

    Nick



    • Diedit oleh badger37 14 Juni 2012 21:26
    14 Juni 2012 20:38
  • The same error came up for me after I created a new form with a picture and over 100 buttons.  After deleting the form and syncing again, the error disappeared.

    Disclaimer: I am a fledgling in the database world yet try to help with creativity if not efficiency.

    16 Agustus 2012 7:37