Kategorie-Archiv: Microsoft 365

Problem

Office 365 wurde korrekt und mit aktiviertem „Shared Computer Activation“ installiert. Nach einer Weile berichten Benutzer von „unlizenziertem Office“ und das man seine Lizenz nicht mehr aktivieren könne.

Das Anmelde-Feld erscheint zwar, man kann hier seine E-Mail Adresse auch eingebene, aber dann verschwindet es wieder und Office wird nicht aktiviert. Es gibt keine Fehler und sogar die Ereignisanzeige bleibt leer.

Lösung

Standardmäßig verwendet Microsoft Office 365 ProPlus (seit Version 2016) die Frameworkbasierte Authentifizierung der Azure Active Directory-Authentifizierungsbibliothek („ADAL“). Nach der Umstellung auf die neue „modern Authentication“ via „WAM“ passieren aber leider häufiger mal Fehler.

Es hilft zuverlässig, WAM und ADAL einfach zu überspringen:

Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Common\Identity]
"DisableADALatopWAMOverride"=dword:00000001

[HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Common\Identity]
"DisableAADWAM"=dword:00000001

Das geht natürlich auch per Gruppenrichtlinie (GPO) im Benutzerkontext (Benutzerkonfiguration) und benötigt nicht mal einen reboot.

Erlärung

Ab Build 16.0.7967 verwendet Office nun den „moderneren“ Web Account Manager („WAM“) für Office-Anmelde-Workflows. Es war auch mal wieder Zeit für neue TLAs. Selbiger bringt, wie immer, einige spannende neue „Eigenheiten“ mit.

WAM sucht beim Start nach den neuen Voraussetzungen für den Identity Providers (IdP), die beim Zusammenführen von Office 365 Konten verwendet werden (IdP IDReg_Match). Für synchronisierte Domänen an sich ein segen – es funktioniert nun auch der lokale UPN. Theoretisch.

Wenn Windows 10 oder Windows Server 2019 mit einem lokalen Active Directory verbunden ist, muss der IdP für WAM/O365 nun aber das sogenannte „WS-Trust-Protokoll“ (respektive Flag) unterstützen. Dies geschieht aber nicht automatisch in allen Konfigurationen; warum das oft nicht der Fall ist, haben wir noch nicht herausgefunden. Wenn beispielsweise das Authentifizierungstoken eines Benutzers ungültig wurde, zum Beispiel beim Kennwort-Zurücksetzen oder deaktivieren eines Nutzers, versucht das WAM den Benutzer erneut zu authentifizieren. Soweit idst das ja auch richtig – aber man erwartet hier nun das altbekannte Popup-Fenster des IdP, das bei einem fehlgeschlagenen Zugriff aber nur kurz geöffnet und dann sofort wider geschlossen wird wenn das Flag nicht korrekt/lesbar/vorhanden ist.

Mit der coolen Archivierungsfunktion in Microsoft Outlook kann man sein Postfach bereinigen und alte Objekte (beispielsweise Dinge im Ordner Gesendete Objekte oder dem Posteingang) in eine Archivdatei verschieben.

Dies ist öfters notwendig, wenn man ein Exchange-Postfach mit Größenlimitierung verwendet.

Problem

Outlook archiviert (scheinbar) nicht „korrekt“, oder vielmehr wie erwartet. Man möchte Beispielsweise Mails eines Jahres (… von 1. Januar bis 31. Dezember …) archivieren, aber einige (wenn nicht alle) Mails verbleiben standhaft im Quellordner.

Vielen Admins ist dabei vermutlich aufgefallen, dass Outlook trotz der Vorgabe, Objekte bis zu einem bestimmten Datum zu sichern, einige alte Objekte wie Mails trotzdem nicht ins Archiv verschiebt.

Lösung

Der Grund ist die Umstellung, dass Outlook nicht (mehr) vom Datum des Objektes ausgeht, sondern vom Änderungsdatum. Selbiges ist natürlich weder offensichtlich noch überhaupt ohne weiteres einsichtig.

Zudem wird das Datum bei jedem Zugriff auf das Element gesetzt, sodaß ein simples öffnen einer Nachricht oder das Verschieben in einen anderen Ordner das Änderungsdatum aktualisiert. Natürlich tut das ein guter Virenscanner auch regelmäßig.

Dieser Registry-Key stellt das Verhalten wieder zurück:

[HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\Preferences]
"ArchiveIgnoreLastModifiedTime"=dword:00000001

Fact: Interessanterweise lautet die Archivierungsrichtlinie im „Exchange Online Archive“ vermutlich daher auch korrekt, wenn auch etwas holperig: „Elemente die länger als … im Ordner … gespeichert waren ohne benutzt worden zu sein“.

Problem:

Ein externes Programm greift (automatisiert) auf Outlook zu. Dabei kommt es (sofern kein aktueller Virenscanner verfügbar) oft zu Bestätigungsmeldungen. (Meist kann man den Zugriff dann für bis zu 10 Minuten gewähren.)

In diesem fall soll auf einem Windows Server mit installiertem Outlook ein Prozess automatisiert werden. Dazu muss die automatisierungssoftware aber auf Outlook zugreifen können, ohne dass ein Benutzer aktiv diese Berechtigung vergeben kann.

Die Optionen im Trust Center („Programmgesteuerter Zugriff“) sind allerdings ausgegraut.

Lösung:

Die Steuerung der Trust Center Optionen ist (sogar noch etwas detaillierter) via GPO (ADMX-Vorlage) möglich.

Dazu werden die ADMX-Templates für die entsprechende Office-Version benötigt (Hier gibt’s die für Office 2016/2019 und Office365)

Nachdem selbige installiert wurden, findet man die passenden Einstellungen in den Gruppenrichtlinien hier:

Benutzerkonfiguration > Richtlinien > Administrative Vorlagen > Microsoft Outlook 2016 > Sicherheit > Sicherheitsformulareinstellungen

Zunächst muss hier die Einstellung „Outlook Sicherheitsmodus“ Aktiviert und als „Outlook-Sicherheitsrichtlinie: Outlook-Sicherheitsgruppenrichtlinie verwenden“ ausgewählt werden.

Danach lassen sich im Bereich „Programmatische Sicherheit“ die entsprechenden Meldungen konfigurieren. Die meisten externen Anwendungen benötigen hier „Eingabeaufforderung für Outlook-Objektmodell beim Lesen von Adressinformationen konfigurieren“ und „Eingabeaufforderung für Outlook-Objektmodell beim Senden von E-Mail konfigurieren“ Aktiv und „Schutzverhalten: Automatisch genehmigen„.