Sharepoint backup error - Web part

[creativepc]

Hi

Product: Veeam Backup for Office365 5.0.3.1033

Is there any final solutions for the Web part error that occurs on new Sharepoint sites?

Here is an example:
Processing site https://customer.sharepoint.com/sites/CEO finished with warning: Cannot change web part export mode to ‘All’, because custom scripting is disabled for site: https://customer.sharepoint.com/sites/CEO. Web part will be skipped (web part ID: 72b5e62d-c984-4a17-b183-09a836645c3e, page: https://customer.sharepoint.com/sites/C ... ngreq.aspx).

Workaround so far:
If I run
Set-SPOsite https://customer.sharepoint.com/sites/CEO -DenyAddAndCustomizePages 0
then error/warnings go away, but I dont want to do it on all new Sites created every day/week/month

Any better solutions out there?

[Mike Resseler]

Hi Tommy,

Unfortunately there is not. I obviously understand you don't want to do this on a daily basis, but if you don't do it, we cannot backup that site entirely and if you would need to restore, parts will be missing. That's why we give the warning. So here are my questions:

* Are you actually OK with missing parts in your backup?
* How would you suggest we make the warning go away? Configurable?

[creativepc]

Hi
Thanks for your answer

* Are you actually OK with missing parts in your backup?
No
* How would you suggest we make the warning go away? Configurable?
Well how about if -DenyAddAndCustomizePages 0 could be a default value on new Sharepoint sites?

[sdv]

Hi Tommy,

Unfortunately there is not. I obviously understand you don't want to do this on a daily basis, but if you don't do it, we cannot backup that site entirely and if you would need to restore, parts will be missing. That's why we give the warning. So here are my questions:

* Are you actually OK with missing parts in your backup?
* How would you suggest we make the warning go away? Configurable?

Hi Mike,

I understand there is already a https://www.veeam.com/kb4091 article about surpressing webpart warnings.

However - Perhaps it is possible to create an option to skip trying to backup: Access%20Requests/pendingreq.aspx webpart by default (checkbox or in the config). Instead of surpressing all webpart warnings. Some webparts might need backups, hence surpressing all webparts is not an option for everyone, neither is looking through all those growing warnings every day .

In the last couple of weeks we run into these warnings and they seem to only occur on that specific webpart.
For reference and further research or to have it as a feature request, we've opened a case about this #05593844

[Mike Resseler]

Hmmm, interesting. That specific webpart I have seen creating issues before. Is it configured? As in, is it allowed to send requests and are the email notifications configured?

[sdv]

Yes to both. I think it is even the default setting when creating a site ? - Allowed to send requests and email notifications is also configured.

Update: Maybe good to know that we tried disabling the access request page afterwards (after someone requested access) but the list still exists. It did not matter if we remove a user from the request access page. The backup keeps giving that warning - Until we completely delete the list.

[guidovk]

Hi sdv,

Can you expand on how you deleted the list? We are also running into this warning and found, as you did, that just deleting all pending requests does not resolve the warning. The webpart remains there.

[edv@rubner.com]

@sdv

Hi,

Can you expand on how you deleted the list?
We are also running into this warning and found, as you did, that just deleting all pending requests does not resolve the warning.

Thanks

[timmi2704]

Hi all,
has a solution to this issue already been found?
We are facing the same issue for that pendingreq webpart for hundreds of sites.
Do we have a possibility to set a global exclusion or supress the warning for this webpart only?
I assume that having a backup of that specific webpart is of no use anyway.
Thanks.

[Mike Resseler]

Unfortunately in VB365 there is no global exclusion at this point in time. I will need to review this again and see if there are already more nicer solutions from us to exclude it.

[timmi2704]

Hi Mike,
that would be wonderful
It seems to affect a high percentage of our sites.
Much appreciated!

[ChickenFarmer]

Hi all,

same issue here and no solution. Took me a while to figure it out.
So far I changed the "-DenyAddAndCustomizePages"-setting to "0" let a backup job run and changed the setting back to"1" since "all" our sites have this setting.
(using Powershell commands as mentioned before)

Has anyone tried to alter successfully the global settings of the website-creation?
So that future websites will be created with the setting "-DenyAddAndCustomizePages"-setting to "0".
Even if this setting is not the prefered "security"-setting for the websites.

I before rerun the "organsiation" wizard to set the "Grant this application the requiered permissions ...." switch "enabled".
... hoping that the job/veeam-user would alter the settings the "right" way by itself.

In fact I am confused why all of our websites seem to have "-DenyAddAndCustomizePages" enabled and can be backed up succesfully and only if this list(perrmissionrequest" is created the job fails.
Is there a difference between this "list" and all the others?

Good luck
Jan

[JWH@VO]

Hi ,

This issue still Exists
it is specific to pendingreq.aspx this is a default aspx in every sharepoint page as it has to do with the acces request and permit access to sharepoint sites , it is not a custom webpart it is part of microsoft sharepoints and does not need to be restored.
because it is a microsoft systems aspx file you can not change the custom scripting to enabled.

would be good if you can make a setting in 365 to specific skip this file in the backup or at least configure that you do not get a warning ( just about this file )

JW Heins

[Mike Resseler]

I will add this to our list of items to do, but as always, I can't make a promise when this would be implemented. I'm obviously going to investigate two paths...

1. Ignore the specific aspx page
2. Succeed in actually protecting it

As always, I hope for the second one

[pateka]

Hi, has there been any development on this issue? We've just started receiving this warning (also with the pendingreq.aspx file) for one of our sites and I'm not sure what is the best approach to get rid of it.

[hpb94]

Yehp also wishing there was a better solution to this than simply ignoring all Webpart warnings.

[georgi.stoychev]

Hi,
We are receiving around 20 warnings everyday when our backup job completes. Is there any progress on finding a better solution than suppressing all web part warnings or allowing custom scripts (which we don't want)?

[Polina]

Hi Gregory and welcome to our forums,

Unfortunately, there's no better solution for now. As of now, it's either all or nothing.

[ninelyoko]

Thank you for this forum update, Wanted to clarify that I am also getting this error for custom scripting. I've found the setting to allow custom scripting in the Sharepoint Admin center (had to really dig for the classic site settings page) and I see the option to allow custom scripting. From this forum, it seems that the only solution is to exclude these sites using the command noted here?

Second question, I got this update [ (Updated) Remove Custom Script setting in OneDrive and SharePoint web
MC714186 · Published Feb 9, 2024 · Last updated Feb 16, 2024 ] stating that custom script setting will be removed in March this year, 2024. How does this affect this issue do you think? I've learned a lot about the nature of this issue in this forum, and if silencing the alarm is the best solution, please let me know, we want to make sure all parts of our clients data is backed up successfully, and based on this forum it looks like it's a Microsoft related file issue that can be ignored and skipped without affecting a potential need for a recovery. Please clarify, as I have the option to allow custom scripting in front of me now, but haven't tested it yet as I do more research on this topic and how it affects different sites on a tenant and site level, and our different customer needs. I'm pretty sure you all are stating that I need to allow custom scripting because of a Microsoft related file error in order to glean a full backup of the flagging sites, and the warnings are indicating that the affected sites are not being backed up correctly.

Case number we have open: Case #07140156

[rwgs]

I will add this to our list of items to do, but as always, I can't make a promise when this would be implemented. I'm obviously going to investigate two paths...

1. Ignore the specific aspx page
2. Succeed in actually protecting it

As always, I hope for the second one

IT DOESN'T NEED TO BE PROTECTED.

Just make it so it can be ignored. There is no reason for it to be backed up because it is NOT a custom script or even a custom page, it is part of SharePoint itself.

How hard can it be to add a simple exclusion for this file?

This has been open for well over 2 YEARS.

When. Will. It. Be. Fixed.???

[Mike Resseler]

Unfortunately it is hard. But there is a solution on its way, it will take some time because the solution is being produced by Microsoft. No, in the meantime we cannot simply exclude it. If we do, you are having gaps in your backup and restore issues and that is not what we want to have. But the need for that custom script is going to go away as they are working on a solution that allows the export of that site without the need of that custom scripting enabled. (because it is not just a webpart only, it is bigger than that).

That is also the reason why the removal of the custom script by MFST, as said above is moved from March to the end of the year

[ninelyoko]

This issue keeps coming back for me every time a Teams group is created; I had an agent guide me through using the SPO command to -DenyAddAndCustomize 0 but I have a member of my team concerned about affecting customer data without their permission. Is that something I should be worried about for this fix? I also want to know if there is a newer fix or an update that's not KB4091. Any help in this area is a huge help, I am having trouble meeting SLA on this most recent ticket.

[FictionalBeast]

I'm also having the same problem