Microsoft 365 Verwaltung

Outlook/Exchange Online: Gesendete Elemente in Shared Mailbox speichern – Ursache, PowerShell-Fix und Fehleranalyse

Sie senden eine Nachricht aus einer Shared Mailbox – und die Kopie landet im Ordner „Gesendete Elemente“ Ihres persönlichen Postfachs. Wer nur die Shared Mailbox im Blick hat, sieht die gesendete Mail nicht und verliert den Faden in der Kommunikation. Der Grund: Outlook speichert standardmäßig lokal beim Absender, auch wenn Sie „Senden als“ oder „Senden im Auftrag“ nutzen. In Exchange Online lässt sich dieses Verhalten serverseitig steuern und damit teamtauglich machen: Die Parameter MessageCopyForSentAsEnabled und MessageCopyForSendOnBehalfEnabled sorgen dafür, dass eine Kopie im Ordner der Shared Mailbox landet.

Outlook/Exchange Online: Gesendete Elemente in Shared Mailbox speichern – Ursache, PowerShell-Fix und Fehleranalyse Weiterlesen »

blank

Microsoft 365: Passwortänderung schlägt bei synchronisierten Konten fehl – Ursache und Lösungen

In hybriden Umgebungen sollten Sie Kennwörter im lokalen Active Directory ändern. Azure AD Connect synchronisiert die Kennworthashes in die Cloud. Versuchen Administratoren oder Anwender, das Kennwort direkt in Microsoft 365 zu ändern, schlägt der Vorgang fehl, solange Password Writeback nicht aktiv und korrekt konfiguriert ist. Bei Password Hash Synchronization überträgt Azure AD Connect regelmäßig Kennworthashes aus dem lokalen AD in die Cloud. Bei Pass-Through Authentication prüft ein lokaler Agent Anmeldungen gegen das AD, ohne den Hash in die Cloud zu bringen. In beiden Fällen gehört die Änderung des Kennworts zunächst on-premises.

Microsoft 365: Passwortänderung schlägt bei synchronisierten Konten fehl – Ursache und Lösungen Weiterlesen »

blank

Exchange Online Berechtigungen prüfen: Welche Cmdlets zeigen welche Rechte wirklich (Mailbox, Shared, Raum, Gruppe)?

In Exchange Online wirken Berechtigungsprobleme oft widersprüchlich: Ein Benutzer kann ein Postfach in Outlook öffnen, aber nicht senden; OWA zeigt einen Ordner, doch PowerShell meldet keine passenden Rechte; ein „Fix“ durch erneutes Zuweisen von Berechtigungen verdeckt den eigentlichen Zustand.

Exchange Online Berechtigungen prüfen: Welche Cmdlets zeigen welche Rechte wirklich (Mailbox, Shared, Raum, Gruppe)? Weiterlesen »

blank

Welche PowerShell-Cmdlets sind read-only – und welche ändern produktiv Daten oder Konfigurationen?

In PowerShell liegen Abfragen und Änderungen oft nah beieinander: Ein Cmdlet liest lediglich den Zustand aus, ein ähnlich benanntes Pendant schreibt Konfigurationen, setzt Berechtigungen zurück oder startet Prozesse neu. Gerade in Administrationsmodulen für Microsoft 365, Exchange, Entra ID oder Windows-Server führt diese Nähe regelmäßig zu unbeabsichtigten Eingriffen – etwa wenn ein Befehl in einer produktiven Session ausgeführt wird, die Umgebung aber als Testsystem angenommen wurde, oder wenn Parameter wie -Confirm, -Force oder -WhatIf missverstanden werden. Zusätzlich erschweren unterschiedliche Scopes die Risikoeinschätzung: Manche Änderungen betreffen nur ein einzelnes Objekt, andere wirken tenantweit oder verändern Sicherheitsgrenzen, etwa Richtlinien, Rollen oder Zugriffspfade.

Welche PowerShell-Cmdlets sind read-only – und welche ändern produktiv Daten oder Konfigurationen? Weiterlesen »

blank

Outlook: Gelöschte Nachrichten aus Shared Mailboxes landen im falschen Papierkorb

Viele Teams bemerken erst im Audit, dass gelöschte Mails aus freigegebenen Postfächern im Papierkorb des ausführenden Benutzers landen statt im Ordner „Gelöschte Elemente“ der Shared Mailbox. Das ist das Standardverhalten von Outlook und führt schnell zu Lücken in der Nachvollziehbarkeit, erschwert interne Kontrollen und kann Compliance-Vorgaben unterlaufen. Abhilfe schafft eine serverseitige Einstellung in Exchange: Mit MessageCopyForDeleteEnabled steuern Sie, dass gelöschte Elemente tatsächlich im Papierkorb der Shared Mailbox abgelegt werden.

Outlook: Gelöschte Nachrichten aus Shared Mailboxes landen im falschen Papierkorb Weiterlesen »

Nach oben scrollen