Es kommt vor, dass Benutzer beim Öffnen von Dateien aus tief verschachtelten Ordnern (oder sehr langen Pfadnamen) diese Fehlermeldung von Office-Apps wie Excel, Word oder PowerPoint erhalten:
Die Datei kann nicht geöffnet werden, da der Dateipfad größer als 259 Zeichen. Kürzen Sie den Pfad oder den Dateinamen
Abgesehen von dem grammatikalischen Fehler, dass im ersten Satz das abschließende Verb fehlt (vermutlich „ist“), stimmt diese Meldung.
Lösung
Es gibt keine Lösung, aber einen Workaround.
Microsoft Office-Apps, allen voran Excel, unterstützen keine Pfade mit mehr als 259 Zeichen. Das hat mit der heiligen Abwärtskompatibilität zu tun, denn es könnte ja sein das noch ein Unternehmen auf VB-Macros aus den 90ern baut. Und mit „ein“ sind hier „100% der Fortune 500“ gemeint 😉
Windows local and UNC files: 260 characters
OneDrive / SharePoint files synced to the local drive: 260 characters
Online OneDrive / Online SharePoint files (opened directly in the WebApp) 400 characters
Der Workaround ist einfach: Die Excel-Web-App nutzen und die Datei direkt auf dem Sharepoint (Online) bearbeiten,
Es kommt in Hybrid-Szenarien schon mal vor, dass ein Admin einen synchronisierten AD-Benutzer nachträglich innerhalb von Microsoft 365 mit einem Postfach versieht. Das ist nicht „supported“, das Postfach taucht nicht im Exchange ECP auf und es drohen fiese Konflikte, wenn Attribute synchronisiert werden. Außerdem kann es auf einmal doppelte Mailadressen geben, weil beide Exchange-Server auf unterschiedliche Adresslisten zugreifen.
Da sollen/müssen die Benutzer wieder auftauchen.
Lösung
Eine „offizielle“ Lösung gibt es nicht so richtig. Exchange Online verwaltet Postfächer etwas anders als der „on Premises“ Exchange, man kann daher Postfächer eigentlich nicht auf die Schnelle ab- und wieder anhängen. Vor allem nicht mit verbundenen Benutzern (Outlook oder Applegeräte).
Es gibt aber einen (bisher) ganz brauchbar funktionierenden Trick.
Wenn eine Mailbox in EXO angelegt wurde
UND diese On-Premises im ECP [noch] nicht existiert (Postfachtyp „Office 365“)
DANN kann man die Mailbox „noch einmal“ On-Premises als Remote-Mailbox enablen. ACHTUNG: Dabei werden die im Exchange Online erstellten Attribute (SMTP-Adressen, Kontaktinformationen, Berechtigungen …) bei der nächsten Synchronisation überschrieben.
Schritt für Schritt geht das so
Exchange GUID der Mailbox aus Exchange Online holen: Get-Mailbox <NAME> | fl ExchangeGuid
Alle weiteren E-Mail-Adressen der Mailbox auslesen (wenn nötig): Get-Recipient <NAME> -ResultSize Unlimited | fl @{Name="EmailAddresses";Expression={($_.EmailAddresses | Where-Object {$_ -clike "smtp*"} | ForEach-Object {$_ -replace "smtp:",""}) -join ", "}}
Mailbox On-Premises „neu“ in Exchange Online enabeln Connect-ExchangeOnline Enable-RemoteMailbox <NAME> -RemoteRoutingAddress @domain.mail.onmicrosoft.com Set-RemoteMailbox <NAME> -ExchangeGuid <GUID AUS SCHRITT1>
Im ECP (On-Premises) die E-Mail Adressen aus Schritt 2 und 3 der Mailbox wieder hinzufügen und einen „Entra ID Connect“ Sync („initial“) starten.
Wenn das erledigt ist, kann es eine Weile dauern, bis das Online-Adressbuch das Postfach wieder korrekt anzeigt. In meinem letzten Fall hier etwas weniger als 24 Stunden.
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 …
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:
