Kategorie-Archiv: Microsoft 365

Microsoft Azure AD Connect Sync Fehler „permission-issue“ mit „Connected data source error code: 5“

Veröffentlicht am von — Keine Kommentare ↓

Wir hatten einen spannenden AADConnect (Entra ID Connect) Fehler zu suchen. Manche Microsoft 365 Gruppen wurden nicht (mehr) korrekt in das lokale AD zurückgeschrieben. Der Fehler lautete, natürlich ohne weitere Details, „Zugriff verweigert“ (permission-issue). Der Hinweis der „Connected data source error code: 5“ ist zwar ein Indiz, aber keine Lösung.

Lösung

Was die Ursache dazu war, ist nicht bekannt. Aber es sind die AD-Berechtigungen für das Synchronisationskonto auf den betroffenen Objekten. In diesem Fall „Generisches Lesen/Schreiben“ von allen Attributen einer Objekttypgruppe (und von deren Unterobjekten).

Auf dem AADConnect-Server in einer PowerShell (als Administrator) ist der Fehler schnell behoben:

# AAD Connect PS-Modul importieren
Import-Module "C:\Program Files\Microsoft Azure Active Directory Connect\AdSyncConfig\AdSyncConfig.psm1"

# Sync-Account-Namen besorgen
Get-ADSyncADConnectorAccount
# (den "ADConnectorAccountName" kopieren)

# Berechtigungen schreiben
Set-ADSyncUnifiedGroupWritebackPermissions -ADConnectorAccountName "<ADConnectorAccountName>" -ADConnectorAccountDomain EXAMPLE.LOCAL

Beispiel:

Set-ADSyncUnifiedGroupWritebackPermissions -ADConnectorAccountName "MSOL_1111aaaa1111" -ADConnectorAccountDomain mydomain.local

Excel Makros in Microsoft 365 Excel (x64) unter Windows 11 sehr langsam

Veröffentlicht am von — Keine Kommentare ↓

Problem

Unter Windows 11 sind Excel-Makros plötzlich extrem langsam. Unter Windows 10 mit der seloben Excel Version ist die selbe Datei mit dem selben Makro deutlich schneller.

Das trifft sogar für absolut identische PCs zu: Unter Windows 10 ist die Excel-Datei schnell, nach einem einfachn InPlace-Upgrade auf Windows 11 sind die Makros wahnsinnig langsam. Ein rollback des PCs zu Windows 10 löst das Problem auch, die Excel-Dateien werden sofort wieder schnell.

Lösung

Wir haben natürlich keine Ahnung was die Ursache ist, aber wir beobachten das es in nahezu allen Fällen hilft, die „Multithread-Verarbeitung“ in Excel abzuschalten. Sobald man das für einen Benutzer getan hat, sind die Makros wieder so schnell wie vorher.

In sehr wenigen Ausnahmefällen hat das nicht geholfen, aber es war eine andere Ursache auffindbar (Virenscanner, Firewall-Software, Netzwerk’tuning‘ Software …).

„Outlook (new)“ Fehler beim öffnen von EML/MSG Dateien „Sie sind nicht berechtigt, die Datei zu öffnen, oder die Datei ist leer“

Veröffentlicht am von — Keine Kommentare ↓

Microsoft versucht ja bekanntlich, mit „Outlook (new)“ den guten, alten, abgehangenen und leidlich stabilen Outlook-Client abzulösen. Allerdings macht das neue JavaScript-Programm auch nach Jahren der Anpassungen immer noch einen äußerst unfertigen Eindruck, ganz abgesehen von der (naturgegebenen) zähen Langsamkeit der Weboberfläche. Wenn man dem Feedback-Hub zum neuen Outlook folgt, sind „zufriedene Anwender“ im maximal einstelligen Prozentbereich zu finden.

Ein überraschendes neues und ägerliches Phänomen ist, dass das „neue Outlook“ den Umgang mit langen Dateipfaden verlernt hat. Wenn man eine MSG/EML/PST Datei aus einem Pfad mit 1024 oder mehr Zeichen Länge öffnen möchte, erhält man diese irreführende (und offensichtlich nicht ans neue Design angepasst) Fehlermeldung:

Die Datei „XXX“ konnte leider nicht geöffnet werden.
Sie sind nicht berechtigt, die Datei zu öffnen, oder die Datei ist leer.

Lösung

Inhaltlich ist das natürlich Unsinn, der Benutzer und praktisch alle anderen Windows-Apps (Notepad, Word, Excel, Outlook …) können die Datei problemlos öffnen. Nur das neue „Outlook (new)“ nicht. Verschiebt man die Datei an einen „kürzeren“ Ort, verschwindet das Problem aber sofort.

Microsoft Outlook 365 wirft plötzlich Fehler und stürzt ab (Windows Server 2016 RDS) [UPDATE: Offizieller Fix]

Veröffentlicht am von — 15 Kommentare ↓

Update: Es gibt (fast) endlich (nach „nur“ 5 Tagen) einen offiziellen Fix (bald). Vorsichtige Formulierung, denn im ‚Current‘ Channel steht das Update noch auf „wird veröffentlicht“.
Informationen: https://learn.microsoft.com/de-de/officeupdates/current-channel#version-2412-january-16
Download: https://www.catalog.update.microsoft.com/Search.aspx?q=%20Microsoft%20365%20Current%20Channel

Problem

Microsoft Outlook, Excel und Word 365 aus den „Microsoft Apps for Enterrprise“ (früher Office Apps) stürzt seit Freitag in der Version Build 16.0.18324.20168 mit der „Programm reagiert nicht“ ab. Das passiert unter Windows Server 2016, beispielweise auf einem RDS (früher Terminalserver).

Die vorherige Version der „Microsoft Apps for Enterprise“ Office Version Build 16.0.18324.20168 funktioniert hingegen ohne Probleme.

Lösung

Lange Rede, kurzer Sinn: Ein aktuelles Microsoft Edge Update sorgt dafür, dass die Office-Apps unter Windows Server 2016 jetzt crashen. Schuld ist die neue Version der react-native-win32.dll.

Man ersetze einfach diese Datei hier:

C:\Program Files (x86)\Microsoft Office\root\Office16\react-native-win32.dll

ersetzen durch diese ältere Version:

react-native-win32_0.74.21.0.zipHerunterladen

Wir hoffen. Microsoft verklagt uns nicht, sondern repariert das defekte Update schnellstmöglich. Die Datei ist auch sicher echt, die Datei-Signatur ist intakt (SHA256: b15ea215d8cbb213c98a4d4ee45a2f42de07f5819a26394c40debae388882dae). Diese Lösung ist natürlich NICHT offiziell supported und wir warten auf ein repariertes Update von Microsoft.

⚠️ Wichtig: Die MP3-Endung der Datei ist aus Gründen da, aber das ist eine ganz normale ZIP-Datei. Einfach die MP3-Endung entfernen 😉

Update

Nach nur wenigen hundert Supportfällen, hat Microsoft das Problem anerkannt 👍

Die offizielle Meldung im Service-Portal: „Benutzerbeeinträchtigung: Microsoft 365-Anwendungen können auf Windows Server 2016 und 2019 Geräten unerwartet abstürzen.“

Während wir uns auf die Minderung konzentrieren, empfehlen wir betroffenen Kunden, ein Update zu erzwingen, um auf Version 2411 (Build 18227.20162) zurückzusetzen. Dies kann auch durch folgende Schritte erreicht werden:

  1. Öffnen Sie die Eingabeaufforderung „als Administrator“
  2. Führen Sie den folgenden Befehl aus:
    cd "C:\Program Files\Common Files\microsoft shared\ClickToRun"
  3. Führen Sie den folgenden Befehl aus:
    OfficeC2RClient.exe /changesetting Channel=Broad
  4. Führen Sie den folgenden Befehl aus:
    OfficeC2RClient.exe /update user

Ursache: Ein kürzliches Office-Update, das das React Native-Framework integriert, um bestimmte Funktionen in Microsoft 365-Anwendungen zu unterstützen, hat ein Problem eingeführt, das zu dieser Beeinträchtigung führt.

Kennwortänderung für alle Benutzer in Microsoft 365 erzwingen

Veröffentlicht am von — Keine Kommentare ↓
„Free digital security background“/ CC0 1.0

Das Erzwingen einer „selbstständigen“ Kennwortänderung kommt schon mal vor – vor allem, wenn ein Admin mit viel Wissen ein Unternehmen verlässt. Das ist in Microsoft 365 im GUI leider nicht möglich, aber natürlich an der PowerShell.

So zwingt man einen (oder mehrere) Benutzer, das eigene Kennwort bei der nächsten Anmeldung zu ändern – ohne das Kennwort zu kennen.

Lösung

Nach dem Obligatorischen Connect-MsolService:

Set-MsolUserPassword -UserPrincipalName [email protected] -ForceChangePasswordOnly $true -ForceChangePassword $true

Das lässt sich nun weiterverarbeiten.

Zum Beispiel, um alle Microsoft 365 Benutzer „auf einmal“ zu zwingen, ihr Kennwort zu ändern:

Get-MsolUser -All | Set-MsolUserPassword -ForceChangePasswordOnly $true -ForceChangePassword $true

So filtert man (zum Beispiel) eine Gruppe von Benutzern und erzwingt die Änderung:

Get-MsolUser -All | ? { $_.Country -eq "Hessen"} | Set-MsolUserPassword -ForceChangePasswordOnly $true -ForceChangePassword $true

Wichtig: Man muss sowohl den Parameter ForceChangePassword als auch ForceChangePasswordOnly setzen. Wenn man ForceChangePasswordOnly überspringt, wird nur ein neues Kennwort für den Benutzer (automatisch) generiert und man muss selbiges manuell verteilen (Stichwort „Initialkennwort“).