Cannot change WebPart ExportMode to ‘All’. WebPart will be skipped (WebPart ID: <guid>)

I’ve been overlooking the above error with the intention to address it (and have attempted a couple times), but never found enough time to dedicate to a final resolution. However, with Veeam releasing Veeam Backup for Microsoft 365 v8.1 last week, this particular issue has been addressed as noted in KB4091 along with few others which can be found in the v8.1 Release Notes. The cause of this particular error was Veeam would attempt to set a Web Part in a SharePoint Online site as exportable, but because the “Allow custom script” had to be enabled. However, Microsoft removed this ability in November (and disabled this option if it was previously enabled), so Veeam and Microsoft worked together for a resolution and this is no longer an issue for VB365 v8.1.0.305 and newer. So let’s run an upgrade and see how things go.

First stop, I’m going to verify the current running version as seen above, and the I’m going to check for an available update by going to the “hamburger” menu and select Upgrade. Curiously, when I log into my VB365 deployment, I’m running v8.0.5.20 P20241111 but when I check for available updates, none are found.

Fortunately, I can of course manually download it from the Veeam Product Download Portal which is my preference anyway. Once downloaded, you can follow the Upgrade Guide. In my case, make sure to stop any running jobs and disable all jobs to prevent them from running again. It also may not be a bad idea to reboot after disabling the jobs so that you have a nice clean surface on which you can run the upgrade – a great practice that I learned as an Exchange admin when applying updates. But apparently Microsoft 365 has made me lazy and that wasn’t engrained deeply enough within me as I didn’t reboot, but we’ll soon see my reasoning for this recommendation.

Do note that Microsoft Windows Server 2012 is no longer supported. Although this has been out of support since October, so hopefully you’re not running it anyway.

Ruh roh…..that’s not supposed to happen. I noticed that it was taking a pretty long time to get past step 1, and VB365 updates/installations are generally pretty fast. So let’s dig into the logs and figure out what what failed. Setup logs can be found at %ProgramData%\Veeam\Backup365\Logs\Setup. In my case, after digging a bit for the cause, I came across these entries.

MSI (s) (88:38) [13:41:41:427]: Product: Veeam Backup for Microsoft 365 -- Error 1921. Service 'Veeam Backup for Microsoft 365 Proxy Service' (Veeam.Archiver.Proxy) could not be stopped. Verify that you have sufficient privileges to stop system services.

Error 1921. Service 'Veeam Backup for Microsoft 365 Proxy Service' (Veeam.Archiver.Proxy) could not be stopped. Verify that you have sufficient privileges to stop system services.

Indeed, when I look at my services, I can see that the Veeam Backup for Microsoft 365 Proxy Service is stuck in a “Stopping” state.

Now I’d be tempted to just go kill the process Veeam.Archiver.Proxy.exe, but realizing my mistake, I instead decided to reboot my server and give it a nice clean boot, and then rerun the installation tasks. And alas, my newfound discipline was rewarded with success this time.

Indeed, now when I log into the console and check the version number, I’m running the latest and greatest v8.1.0.305.

So let’s rerun the job that I know has a far amount of these errors and see if everything is looking a bit more quiet. And indeed, while I still had some failures due to mailboxes not having a group owner account assigned which I’ll need to address, I no longer received any warning when processing the sites with the Web Part export mode not being set to “All”. And I’ll take that as a win because that will reduce the Warning noise and allow me to better address the actual failures.