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.

Exchange EventID 1006 (MSExchangeDiagnostics) „Event Dispatchers Catching Up“

Auf Exchange Servern seit 2010 wird gerne mal dieses Ereignis alle paar Minuten in das Anwendungsprotokoll geschrieben:

The performance counter '\\EXCHANGESERVER\MSExchange Assistants - Per Database(msexchangemailboxassistants-DATABASE)\Quarantined Assistant Count Total' sustained a value of '6.015,00', for the '10' minute(s) interval starting at '10.10.2020 12:00:00'. Threshold breached since '10.10.2020 21:12'. None Trigger Name:AssistantsQuarantinedTrigger. Instance:msexchangemailboxassistants-DATABASE

Oder auch mit etwas längerem Intervall:

The performance counter ‚\\EXCHANGESERVER\MSExchange Assistants – Per Database(msexchangemailboxassistants-DATABASE)\Event Dispatchers Catching Up‘ sustained a value of ‚2.730,00‘, for the ’30‘ minute(s) interval starting at ‚10.10.2020 19:39:00‘. Threshold breached since ‚10.10.2020 20:10‘. None Trigger Name:EventDispatchersCatchupQueueTrigger. Instance:msexchangemailboxassistants-DATABASE

Lösung

Das ist ein Fehler, den es in vielen Setup auch schon unter Exchange 2013 gab (Exchange 2016 hat das genauso). Es gibt für beide einen Workaround um die nervigen Fehler-Einträge loszuwerden.

Im Verzeichnis Microsoft\Exchange\Vxxx\BIN (Powershell: $exinstall\bin) findet sich die Datei Microsoft.Exchange.Diagnostics.Service.exe mit der zugehörigen *.config Datei:

Microsoft.Exchange.Diagnostics.Service.exe.config

Diese „als Admin“ bearbeiten. Darin muss nur ein Trigger auf „false“ geändert werden, und zwar diese Zeile:

<add Name="Microsoft.Exchange.Diagnostics.Service.ExchangeJobs.Triggers.EventDispatchersCatchupQueueTrigger" Assembly="Microsoft.Exchange.Diagnostics.Service.ExchangeJobs.dll" Enabled="True" Role="Mailbox" />

in diese:

<add Name="Microsoft.Exchange.Diagnostics.Service.ExchangeJobs.Triggers.EventDispatchersCatchupQueueTrigger" Assembly="Microsoft.Exchange.Diagnostics.Service.ExchangeJobs.dll" Enabled="False" Role="Mailbox" />

Das ist in der Regel so um die Zeile 1440 herum. Danach startet man den MSExchangeDiagnostics Dienst neu und ist die Meldung los.

sc restart MSExchangeDiagnostics

Das leider Admins – hier die Top 5 aus dem echten Leben

Admins, wie wir ja auch sind, möchten ja das Infrastrukturen funktionieren. Wir wollen Benutzern helfen. Wir geben einiges damit „das Netzwerk“ funktioniert. Aber trotzdem gibt es universell bekannte „Sollbruchstellen“ über die wir oft nicht hinweghelfen können.

Das hier ist die Liste der „Top 5“ der ständigen Leiden von Admins. Das seufzen aus dem Nebenbüro oder der Technik auf den Punkt gebracht. Die häufigsten Sprüche die man bei uns hören kann.

  • „Ich hasse Drucker“ (Dauergast in der Top 5 seit 1994)
  • „Ich hasse VoIP“ (Meint Telefonanlagen, Cloudfonie und vor allem das prinzipielle Problem, das menschliche Sprache Echtkommunikation bedeutet, aber TCP/IP [das Intenet] by Design das exakte Gegenteil davon umsetzt. Daher kommt es ständig zu zahlreichen, aber prakisch nie reproduzierbaren oder findbaren Fehlern)
  • „Wer (zum|zur|…) (Hölle|Geier|…) hat das hier gebaut?“ (… und sich DABEI gedacht? Wurde ÜBERAHAUPT dabei gedacht? Aus welchem Jahrtausend ist DAS denn noch?)
  • „Können Sie mal eben“ oder „Wo sie schonmal da sind“. (Die weltweit standartisierte Formulierung für überraschende Admin-Überstunden, absurde IT-Rätsel und von der Meinung her diametral gegenüberstehend zu einem kurzen und/oder planbaren Zeitraum)
  • „Die E-Mail habe ich (nicht|nie|aufkeinenFall|sichernicht) bekommen“ (Das System E-Mail versagt besonders oft bei angekündigten Wartungsarbeiten, Systemumstellungen oder wichtigen Informationen, die zwar nur mittelbar das Tätigkeitsfeld eines Benutzers tangieren aber [angekündigterweise] zu umittelbaren Fehlern oder Ausfällen führen).

Wenn wir etwas offensichtliches vergessen haben, freuen wir uns über einen Kommentar. Ansonsten sind wir jetzt schon gespannt auf 2024. Mal sehen wie viele der Dazergäste sich weiterhin halten 😂

Windows 10/11 und Windows Server „Automatische Reparatur“ vollständig abschalten

Windows 10/11 und Windows Server meinen es eigentlich gut, wenn Sie nach jeweils zwei „unerwarteten Neustarts“ (z.B. Strom aus) in die „Automatische Reparaturumgebung“ booten, anstatt das eigentlich Betriebssystem zu starten. Die Automatische Reparatur kann man zwir überspringen, aber nur wenn man eine Taste drücke.

Im Prinzip eine nette Idee, denn bei plötzlichen Stromausfällen könnte ja das Dateisystem beschädigt worden sein.

Manchmal braucht man aber ein System, das IMMER bootet. Beispielsweise für POS-Geräte die nur Informationen anzeigen sollen oder Geräte die gar keine Tastatur angeschlossen haben. Solche Geräte werden gerne öfter mal „hart“ ohne „herunterfahren“ ausgeschaltet und starten dann nicht mehr alleine.

Lösung

Um den freundlichen „Automatic Repair“ Assistenten vollständig loszuwerden, sind mehrere Schritte notwendig. Alles natürlich an der Administrator („Als Admin“) CMD Kommandozeile.

1. Die WinRE Umgebung komplett abschalten

reagentc /disable

2. Ruhezustand („Fastboot“) grundsätzlich abschalten

powercfg -h off

3. Die Recovery-Umgebung im Windows Bootlaufwerk abschalten
{current} ist dabei die Windows-Installation um die es geht. Eine Liste aller Installationen gibt bcdedit aus.

bcdedit /set {current} recoveryenabled no

4. Alle Startfehler beim booten ignorieren (auch das „dirty“ flag von NTFS)

bcdedit /set {current} bootstatuspolicy IgnoreAllFailures

Ab jetzt startet die Reparaturumgebung wirklich nicht mehr und man benötigt einen bootfähigen USB-Stick um das System im ernstfall zu prüfen.

Schnell große Dateien an der Windows Kommandozeile erstellen

Manchmal braucht mal „auf die Schnelle“ eine Testdatei. Sei es um Fileserver zu testen, Netzwerkverbindungen auszulasten oder ein Dateisystem zu stressen.

Der schnellste bekannte Weg große Dateien zu erstellen ist mit dem Tool fsutil. Das geht an der CMD-Shell und natürlich auch in der PowerShell.

Lösung

fsutil file createnew <DATEINAME> <GROESSE>

Die Größe wird dabei in bytes angegeben.

Beispiele

fsutil file createnew 01MB-TESTDATEI.TEST 1048576

fsutil file createnew 01GB-TESTDATEI.TEST 1073741824

fsutil file createnew 05GB-TESTDATEI.TEST 5368709120

fsutil file createnew 10GB-TESTDATEI.TEST 10737418240

Falls man Probleme hat MB/MiB, KB/KiB und so weiter auseinanderzuhalten, es gibt da ein wundervolles XKCD das einiges erklärt 🙂