Kategorie-Archiv: Microsoft 365

Microsoft Office 365 Apps auf RDS (RD-Sessionhosts) oder VDI Fehler „Da hat etwas nicht geklappt, [1001]“

Veröffentlicht am von — Keine Kommentare ↓

Auf RDS oder in VDI-Umgebungen, auch mit FSLogix, sehen wir schon mal diesen Fehler, wenn ein Benutzer sein Office (meit Outlook) öffnen möchte:

Fehler: Es ist ein Fehler aufgetreten. [1001]

oder auch

Fehler: Da hat etwas nicht geklappt. [1001]

Der Effekt ist nicht wirklich persistent und scheint nicht immer aufzutreten. Manchmal geht es auch „Vormittags“ und „Nachmittags“ aber nicht mehr.

Lösung

Es gibt ein paar Pfade, die eigentlich nicht roamingfähig sind, aber in Szenarien mit FSLogix-Profilcontainern trotzdem unfreiwillig umgezogen werden. Die Ordner (und Registry-Schlüssel) werden somit zwischen RDS oder VDI Hosts „geroamt“ge-roamed“. Das macht die Schlüssel und Host-Zertifikate aber ungültig.

Am einfachsten ist es, die betreffenden Pfade und Registry-Schlüssel einfach zu löschen. Nach einem ab- und wieder anmelden tritt der Fehler dann nicht mehr auf, bis es wieder zu einem Hostwechsel kommt. Dann kann das Script aber einfach wieder ausgeführt werden.

@echo off
REM /*
REM	Office (Outlook) Fehler "1001" beheben
REM	https://support.microsoft.com/en-us/office/6f63238d-d83c-437c-a929-de72fe819793
REM	10.04.2024 Admins auf ugg.li
REM */

if exist "%localappdata%\Packages\Microsoft.AAD.BrokerPlugin_cw5n1h2txyewy" rd /s /q "%localappdata%\Packages\Microsoft.AAD.BrokerPlugin_cw5n1h2txyewy"
if exist "%localappdata%\Packages\Microsoft.Windows.CloudExperienceHost_cw5n1h2txyewy" rd /s /q "%localappdata%\Packages\Microsoft.Windows.CloudExperienceHost_cw5n1h2txyewy"

for /d %%i in ("%localappdata%\Packages\*") do (
	if exist %%i\AC\TokenBroker echo rd /s /q %%i\AC\TokenBroker
)

reg delete "HKEY_CURRENT_USER\SOFTWARE\Microsoft\IdentityCRL" /f
reg delete "HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\AAD" /f
reg delete "HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows NT\CurrentVersion\WorkplaceJoin" /f

Die „richtige“ Lösung wäre eine Anpassung von FSLogix, oder einfach ein Fix von Microsoft das roamed-certificates einfach einbezieht …

Veeam für Office 365 sichert nicht mehr richtig „Failed to get folder properties. Not allowed to access Non IPM folder“

Veröffentlicht am von — Keine Kommentare ↓

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 😎

Der Fix ist zum Glück einfach

  1. Veeam-Config Datei %programdata%\Veeam\backup365\config.xml „Als Administrator“ bearbeiten
  2. In der Sektion <Archiver> diesen Tag hinzufügen:
    <Proxy SkipTeamsMessagesDataFolders="True" />
  3. Veeam Dienste neu starten, zum Beispiel an der PowerShell:
Restart-Service -Name "Veeam.Archiver.Service"

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

Veröffentlicht am von — Keine Kommentare ↓

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

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*