Kategorie-Archiv: Microsoft 365

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

Veröffentlicht am von — 1 Kommentar ↓

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.

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

Veröffentlicht am von — Keine Kommentare ↓

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“

Veröffentlicht am von — 1 Kommentar ↓

„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“

Veröffentlicht am von — 2 Kommentare ↓

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.

PIN zurücksetzen Fehler“CAA2000B“ auf AzureAD „registered“ Geräten nach Office 365 Installation

Veröffentlicht am von — Keine Kommentare ↓

Man registriert sein Windows-Gerät, auch den Home-PC, automatisch ins Microsot 365 AzureAD eines Unternehmens, indem man nach einer Office 365 Installation den Haken bei „Verwaltung meines Gerätes durch meine Organisation zulassen“ nicht entfernt. Alternativ kann man auch links unten auf den „unsichtbaren“ Button „Nein, nur bei dieser App anmelden“ klicken.

Wenn man sein Gerät registiert hat taucht es auch nach wenigen Cloudmomenten im AzureAD Device Manager auf:

Und bekommt von dort einige Richtlinien. Vor allem die Sicherheitsrichtlinien greifen dann auf dem Gerät – machmal ist das bei „Privat-PCs“ etwas überraschend.

Fehler CAA2000B (AADSTS500014)

Standardmäßig tritt beim zurücksetzen der Windows-Hello PIN auf dem PC nach dem Azure AD Registrierungsvorgang dieser Fehler auf:

Es ist ein Problem aufgetreten

wir konnten sie nicht anmelden. Falls dieser Fehler weiterhin besteht, wenden Sie sich an den Systemadministrator, und geben Sie den Fehlercode an: CAA2000B.

Das liegt daran, das der Administrator die „App“ die die Zugangs-PIN ändern will erst zu „seinem“ Azure AD hinzufügen und bestötigen muss.

Lösung

1. Die PIN-Reset Web-App „Service“ aufrufen und als Globaler Administrator anmelden. Am einfachten mit GENAU diesem Link:

https://login.windows.net/common/oauth2/authorize?response_type=code&client_id=b8456c59-1230-44c7-a4a2-99b085333e84&resource=https%3A%2F%2Fgraph.windows.net&redirect_uri=https%3A%2F%2Fcred.microsoft.com&state=e9191523-6c2f-4f1d-a4f9-c36f26f89df0&prompt=admin_consent

2. Die PIN-Reset Web-App „Client“ aufrufen und als Globaler Administrator anmelden. Am einfachten mit GENAU diesem Link:

https://login.windows.net/common/oauth2/authorize?response_type=code&client_id=9115dd05-fad5-4f9c-acc7-305d08b1b04e&resource=https%3A%2F%2Fcred.microsoft.com%2F&redirect_uri=ms-appx-web%3A%2F%2FMicrosoft.AAD.BrokerPlugin%2F9115dd05-fad5-4f9c-acc7-305d08b1b04e&state=6765f8c5-f4a7-4029-b667-46a6776ad611&prompt=admin_consent

2. Im folgenden Assistenten in BEIDEN Fällen die App „Microsoft Pin Reset Service Production“ (Client und Service) bestätigen:

„Microsoft PIN Reste Service Production“ für Windows Hello erlauben

Ob das geklappt hat kann man danach sofort im Microsoft Entra Admin Center überprüfen:

  1. Ins AzureAD einloggen via https://entra.microsoft.com/
  2. Azure Active Directory > Anwendungen > Unternehmensanwendungen > Alle Anwendungen > „PIN“ suchen

Es sollten dort nun zwei Apps auftauchen:

Und schon (nach dem nächsten Neustart mit Internet) funktioniert das PIN-Ändern wieder wie vorher.

Wenn der Vorgang trotzdem noch fehlschlägt, hilft oft ein Blick in das Cloud App Security Dashboard für Anwendungen; möglicherweise hat hier anderer Admin das OAUTH dieser Apps vielleicht blockiert …