Seit einer Weile™️ schlagen Veeam für Office 365 Sichrungsjobs fehl. Nach und nach sind immer mehr Unternehmen betroffen. Ein Job sichert dann praktisch keine Mailbox mehr, oder zumindest erweckt die Meldung den Anschein.
Die neue Fehlermeldung lautet:
Failed to get folder properties. Not allowed to access Non IPM folder
Lösung
Die Ursache: Microsoft rollt changes aus. Es geht um die Neuigkeit „Microsoft will restrict access via EWS to Teams message data starting on January 31, 2023„.
Das bedeutet natürlich nicht, das alle Tenants der ganzen Welt das „Update“ gleichzeitig bekommen. Mein Fall für heute ist auch genau von heute. Also vom 9.4.2024 (!). Wenn sich also jemand wundert, wie lange Updates manchmal zum ausrollen brauchen 😎
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:
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:
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
# Custom Script in ALLEN Sites auf einmal erlauben
Get-SPOSite | 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.
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).
„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.
