Veeam für Office365 Warning: Processing site […] finished with warning: Cannot change web part export mode to ‘All’, because custom scripting is disabled for site

Microsoft SharePoint in Microsoft 365 nutzt „Webparts“. Das sind diese „Dokumentenblöcke“ die man in Sites einfügen kann, zum Beispiel die Office Blöcke (Promimentes Beispiel: der Excel-Table-Block). In diesen ist „Scripting“ normalerweise aus Sicherheitsgründen abgeschaltet (Office-Macros und so).

Den Effekt hatten wir hier zwar schon, aber aufgrund einer Nachfrage nach mehr Details, hier praktisch das selbe nochmal, nur kleinschrittiger 🙂

Wenn man nun die „moderne Authentifizierung“ für Veeam nutzt, also die Anmeldung als App-Only-Authentifizierung mit dem Zertifikat, muss man für Veeam die Eigenschaft „Exportmodus“ des/der Webparts ändern. Standardmäßig ist Scripting auf „Keine“ festgelegt, aber Veeam benötigt „Alle“. Wenn die Scriptingeigenschaft auf „keine“ festgelegt ist, kann man Webparts nicht via Graph API exportieren. Das gilt auch nicht nur für Veeam.

Da seit Anfang des Jahres 2023 die Änderung der Site-Eigenschaft durch einen SharePoint-Administrator verboten ist, muss man das Globaler Admin selber übernehmen.

Lösung

1. Zuerst die notwendigen Rechte prüfen oder notfalls vergeben. Dazu öffnet man das klassische (!) SharePoint AdminCenter als „Globaler Admin“ und die Einstellungen-Seite zu SharePoint:

https://SITENAME-admin.sharepoint.com/_layouts/15/online/TenantSettings.aspx

2. Im Abschnitt „Benutzerdefiniertes Skript“ stellt man die (Radio-)Auswahl auf:
Benutzern das Ausführen benutzerdefinierter Skripts auf persönlichen Websites gestatten
UND
Benutzern das Ausführen benutzerdefinierter Skripts auf Self-Service Creation-Websites gestatten

3. Dann braucht man eine SharePoint PowerShell-Verbindung:

# Prüfen obd as SharePoint Modul installiert ist
Get-Module -Name Microsoft.Online.SharePoint.PowerShell -ListAvailable

# Wenn nicht, SharePoint Modul installieren ("Als Admin")
Install-Module -Name Microsoft.Online.SharePoint.PowerShell

# Wenn doch, Update machen (sicher ist sicher)
Update-Module -Name Microsoft.Online.SharePoint.PowerShell

# Mit der SPO-Site Verbinden 
Connect-SPOService -Url https://SITENAME-admin.sharepoint.com 

4. In dieser verbundenen Shell führt man dann aus:

Set-SPOSite https://SITENAME.sharepoint.com -DenyAddAndCustomizePages 0

Die Änderung dauert dann gerne mal 1-2 Tage, also am besten nicht sofort wieder versuchen sondern eine Weile warten.

Veeam Backup for Microsoft 365: „Cannot change WebPart ExportMode to ‘All’. WebPart will be skipped“ Warnung bei SharePoint Sites

Bei der Sicherung von SharePoint-Sites für eine Organisation, die die moderne App-Authentifizierung nutzt, wird die folgende Warnung im Veeam Backup log angezeigt:

10.10.2010 01:01:01 :: Processing site <URL> finished with warning: Cannot change web part export mode to ‘All’, because custom scripting is disabled for site: <URL>. Web part will be skipped (web part ID: <GUID>, page: <URL>/pendingreq.aspx).

Um Webparts (Funktionsblöcke wie Tabellen, Bilder oder Remote-Inhalte) mit der modernen „App-Only“ Authentifizierung zu sichern, muss die Eigenschaft „Exportmodus“ des Webparts von „„Keine“ auf „Alle“ gesetzt werden.

Manchmal ist die Änderung der Eigenschaft durch den Admin verboten worden, sodass Veeam Backup for Microsoft 365 das nicht selber ändern kann; dann passierte diese Warnung.

Lösung

Man muss die Eigenschafte manuell (als Administrator) an der PowerShell setzen:

# SharePoint Online Modul installieren (falls noch nicht vorhanden)
Install-Module -Name Microsoft.Online.SharePoint.PowerShell

# Mit SPO verbinden
# -- Ohne MFA
$cred = Get-Credential
Connect-SPOService -Url https://<TENANTNAME>-admin.sharepoint.com -Credential $cred

# -- Mit MFA
Connect-SPOService -Url https://<TENANTNAME>-admin.sharepoint.com

# Custom Script in dieser SharePoint Site zulassen
Get-SPOSite -Identity https://<TENANTNAME>.sharepoint.com/sites/<SITENAME> | Set-SPOSite -DenyAddAndCustomizePages 0

Ein paar „Cloud-Minuten“ später, meint ein paar Stunden Realzeit, funktioniert das Backup wieder. Natürlich gibt es ein paar Security Considerations wenn man Custom-Scripts zulässt.

Bonus-Tipp:

Um eine übersichtliche Auflistung der fehlgeschlagenen Sites im Veeam-Job zu erhalten, folgenden einzeiler in der „Veeam Backup for Microsoft 365 365 PowerShell“ ausführen:

(Get-VBOJob | ? LastStatus -eq Warning | Get-VBOJobSession | select -First 1).Log | ? Title -like '*custom scripting*' |ft Title

Update für Fehler „401“

Die PowerShell-Verbindung gibt möglicherweise hartnäckig den Fehler „401“ aus:

PS C:\> Connect-SPOService -Url https://<TENANTNAME>-admin.sharepoint.com
Connect-SPOService : Der Remoteserver hat einen Fehler zurückgegeben: (401) Nicht autorisiert.
In Zeile:1 Zeichen:1
+ Connect-SPOService -Url https://<TENANTNAME>-admin.sharepoint.com
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (:) [Connect-SPOService], WebException
    + FullyQualifiedErrorId : System.Net.WebException,Microsoft.Online.SharePoint.PowerShell.ConnectSPOService

Das liegt dann daran, das der Administrator der das gerade ausführt nicht Mitglied der Rolle „SharePoint Administrator“ ist. Die Rolle muss im Microsoft 365 Admin Center nur schnell dazugeklickt werden, nach der nächsten Anmeldung geht das sofort wieder.

Mitglider von Office 365 Gruppen können keine Ordner in gemeinsamen Postfächern erstellen

Benutzer in Office 365 Gruppen können Gruppen-E-Mails effektiver organisieren, wenn sie Ordner erstellen und/oder Regeln innerhalb des Gruppenpostfachs anlegen können. Das ist standardmäßig deaktiveirt.

Regeln können aber auch weiterhin nur im OWA (Outlook-Webanwendung) über „Postfach eines anderen Benutzer öffnen“ angelegt werden.

Lösung

Der Admin muss nur das Feature „Ordner und Regeln“ akivieren. Das gilt dann für alle Microsoft 365-Gruppen in der gesammten Organisation (im ganzen Tenant).

Ordner- und Regeln für Gruppen einschalten:

Set-OrganizationConfig -IsGroupFoldersAndRulesEnabled

Status der Richtlinie prüfen:

Get-OrganizationConfig | fl IsGroupFolders*

Microsoft 365 Exchange online: SMTP-Relay sendet nicht mehr „SendAsDenied“ und „not allowed to send as“

„Auf einmal“ sendet ein SMTP-Relay Server nicht mehr alle E-Mails raus. Im (IIS-SMTP-) Log findet sich dieser Fehler:

SendAsDenied; <NAME> not allowed to send as <NAME>; STOREDRV.Submission.Exception:SendAsDeniedException.MapiExceptionSendAsDenied; Failed to process message due to a permanent exception with message [BeginDiagnosticData]Cannot submit message.

Wobei <NAME> ein Alias des Relay-Benutzers ist. Der Benutzer darf also nicht mehr als er selbst senden.

Lösung

Microsoft hat, natürlich ohne große Ankündigung, die implizite „Senden-Als“ Berechtigung für Aliase einer Mailbox entfernt. Man muss diese im Exchange Admin-Center einfach wieder aktivieren.

Das geht unter Einstellungen > Nachrichtenfluss > „Senden von Aliasnamen aktivieren“

… und schon kann der Nutzer wieder mit einem beliebigen Alias E-Mails (via SMTP) versenden.

Word Fehlermeldung „Die Arbeitsdatei konnte von Word nicht erstellt werden. Überprüfen Sie die TEMP-Umgebungsvariable“

Auf einer RDS Farm durften wir soeben diesen Fehler suchen. Einige Benutzer erhielten beim Versuch Word-Dateien im Explorer via Doppelklick zu öffnen die Meldung:

Irreführend: „Überprüfen Sie die TEMP-Umgebungsvariable“
Die Arbeitsdatei konnte von Word nicht erstellt werden. Überprüfen Sie die TEMP-Umgebungsvariable.

Außerdem dauert es extrem lange, bis Word die Datei(en) öffnet. Das funktioniert, dauert nur wahnsinnig lange.

Lösung

Mit der %TEMP% Variable und dem Temp-Pfad hat diese Meldung in der Regel nicht viel zu tun. Der Fehler wird auch nicht von Word selbst verursacht, sondern von der Vorschau für Word-Dateien im Explorer. Selbige holt sich einen veralteten Verweis aus der Registry für einen Vorschauhandler, den es nicht mehr gibt.

Die folgenden Schlüssel sind in der Regel (bis auf Unterschlüssel) leer, enthalten also keine Werte. Wen dem so ist, einfach den ganzen Schlüssel mit Unterschlüsseln löschen, der Fehler ist dann sofort weg.

HKEY_CLASSES_ROOT\CLSID\{84F66100-FF7C-4fb4-B0C0-02CD7FB668FE}  (Word)
HKEY_CLASSES_ROOT\CLSID\{65235197-874B-4A07-BDC5-E65EA825B718}  (PPT)
HKEY_CLASSES_ROOT\CLSID\{00020827-0000-0000-C000-000000000046}  (Excel)

Man muss nicht neu starten, nur den „hängenden “ Word-Prozess beenden. Danach funktionieren sowohl Vorschau als auch Word wieder ohne Fehler.

Wenn das noch nicht zum Erfolg führt, lont ein Blick in die ShellFolder-Pfade. Diese müssen stimmen, sonst verrutschen Office-Tools gerne mal im Pfad.

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders

Name: Cache
Soll-Wert: %userprofile%\AppData\Local\Microsoft\Windows\INetCache

Der Pfad muss natürlich auch existieren und der Nutzer muss dort schreiben dürfen.