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).
„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.
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:
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.
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:
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 …