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 😎
ReFS ab v3.1 unterstützt bekanntlich zwei verschiedene Clustergrößen: 4 KB und 64 KB. Welches nimmt man für ein B&R Repository?
tl;dr: 64KB für ReFS als Veeam-Repository
Aber warum?
Unter anderem Microsoft hat 2019 in einem Technet-Artikel einige Empfehlungen zur Clustergröße für ReFS und NTFS veröffentlicht. Die Standard-Clustergröße beider Dateisysteme ist 4K, was bis heute die Vorgabe ist, wenn man ein neues Volume formatiert. Der Artikel enthält aber auch eine detaillierte Erklärung, warum man eine bessere Performance mit 64K großen Zuordnungseinheiten erhält, wenn man große Dateien ließt oder schreibt.
64-KB-Cluster sind grundsätzlich immer dann sinnvoll, wenn man mit großen, sequentiellen E/A-Vorgängen (auf HDDs) arbeitet. Viel weniger Verwaltungsaufwand bei der Adressierung, mehr Payload und damit höherer Durchsatz bei deutlich weniger Last (etwa ein sechzehntel). Sicherungen und Wiederherstellungen erfolgen naturgemäß in aller Regel sequentiell, daher sind Veeam-Blöcke schon immer größer gewesen, nämlich 1Mbyte.
Insbesondere die „brutto“ Read/Write-Leistung unterscheidet sich erheblich, wenn dasselbe Volume auf derselben Hardware mit einer Clustergröße von 64 KB statt mit 4 KB formatiert wird. Eine bis zu vierfachen Steigerung der Netto-Geschwindigkeit von Merge-Vorgängen (Inkremental-Forever, Synthetic-Fulls …) ist üblich. Beide Vorgänge sind dank der Block-Cloning-API (ReFS-only!) immer noch erheblich schneller als „normales“ i/o, aber der Unterschied ist gewaltig. Die reine Backup-Schreibleistung hängt meist von der Quelle ab, daher fällt der gefühlte Unterschied hier ncht so groß aus.
Nachteile?
Ein Nachteil ist der zusätzliche Speicherplatzverbrauch. Dier beträgt, aus Erfahrung, etwa 5–10% der Dateigröße (nicht Volumengröße). Der Grund dafür ist, dass von Veeam erstellte Blöcke zunächst eine feste Größe von 1MB haben. In den allermeisten Veeam-Jobs ist aber standardmäßig die Komprimierung aktiv, die „im Durchschnitt“ die Größe nachträglich um etwa etwa 50% reduziert. Je nach Quelldaten fällt das natürlich leicht unterschiedlich aus, was in variabler „Verwendung“ von Cluster-„Rändern“ mündet.
Wir halten den Preis von <10% Speicherplatz für die Geschwindigkeits-Vervielfachung für hinnehmbar und empfehlen daher ebenfalls die 64KB Blockgröße.
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:
Failed to prepare guest for hot backup. Details: VSSControl: -2147467259 Backup job failed.
Cannot create a shadow copy of the volumes containing writer's data.
VSS asynchronous operation is not completed. Operation: [Shadow copies commit]. Code: [0x8004231f].
Lösung
Der Fehlercode 0x8004231f steht für „VSS_E_INSUFFICIENT_STORAGE“ oder auch „nicht genügend Speicherplatz für die Schattenkopie“. Die Festplatte ist voll.
Schattenspeicherplatz wird für die Systemwiederherstellungspunkte von Veeam Backup & Recovery verwendet, wenn „Appication Image Aware Processing“ eingeschaltet ist (was auch empfohne ist).
Der Fehler tritt auf wenn die Festplatte tatsächlich voll ist. Das kann zum Beispiel ungewollt passieren, wenn man der 100Mbyte großen Windows „EFI-Systempartition“ oder der (möglicherweise eingerichteten) „Widerherstellungspartition“ einen Laufwerksbuchstaben gegeben hat. Naturgemäß haben diese Partitionen praktisch keinen freien Speicherplatz. „Voll“ bedeutet hier, „nicht genug Platz für eine Volumenschattenkopie“. Bei Maschinen mit viel Arbeitsspeicherbedarf, zum Beispiel ERP-Systeme oder SQL-Server, kann das plötzlich sehr viel sein. Wir haben einen SQL-Server VSS Dump „mal eben“ 20Gbyte schreiben sehen.
Jeden Tag laufen eine Menge Backup-Jobs. Einer nicht – oder besser, einige Maschinen darin nicht. Der Fehler im Veeam Backup & Replication Protokoll lautet:
[Error Unhandled exception was thrown during licensing process]
Die Lizenzierung wurde natürlich geprüft und alle Hosts und vCenter waren mit korrkten Lizenen ausgestatte. Es wurden auch keine Instanzen separat lizenziert oder ähnliches.
Lösung
Es stellte sich heraus, dass selbiges kein Lizenzproblem ist. Der genutzte vCenter-Server war einfach nicht erreichbar (502 nach Neustart). Der selbe Fehler tritt auch auf, wenn man das Passwort des Benutzers, der für die Verbindung mit VMware vCenter verwendet wird, ändert.
Als der vCenter wieder da war (respektive das Kennwort angepasst), läuft auch alles wieder einwandfrei.
