So gut Teams technisch auch immer funktionieren mag, die Standardvorgabe bei der Erstellung eines neuen Termins auf „Online“ zu stellen ist nicht immer sinnvoll – vor allem nach der Corona-Pandemie.
Wie genau sich die Vorgabe (Standartmäßig offline) geändert hat konnten wir nicht nachvollziehen, „auf einmal“ sind viele Outlooks auf Standartmäßige Teams-Meetings umgestellt. Wir haben auch schon viele Meetings bekommen, mit einem Nachtrag „nicht mehr online“ 😏
Bei der Erstellung eines neuen Termins kommt es in Outlook zudem zu einer nervigen zusätzlichen Wartepause, weil Outlook erst auf die Antwort der Teams-Clouddienste wartet. Das ist oft unnötig – zumal man bei Bedarf durchaus auch wieder „An Teams Besprechung teilnehmen“ auswählen kann.
Outlook Termin/Besprechung pro Termin umstellen
„Nicht online Hosten“ lässt die Teams-Besprechung nachträglich verschwinden
Teams entfernen geht natürlich im ersten Schritt für jeden Termin einzeln, über den Button „Nicht online Hosten“.
Dieser entfernt alle Teams-Settings aus der Besprechung und auch die automatisch eingefügen Inhalte, wie den Besprechungs-Link.
Outlook Standart-Vorgabe für neue Termine ändern
Die Standardeinstellung für neue Termin lässt sich in Outlook grundsätzlich ändern:
Datei > Optionen > Kalender > „Besprechungsanbieter hinzufügen“ > „Onlinebesprechungen zu allen Terminen hinzufügen“ (Haken entfernen)
Man speichert „jahrelang“ Excel-Dateien auf dem Netzlaufwerk, hat dort jede Menge Links auf andere (Netzwerk-)Dateien gesetzt alles funktioniert wunderbar. Doch plötzlich gibt es beim Klick auf die Links nur noch Fehlermeldungen, nicht geht mehr.
Es erscheint statt der Dokumente ein „Sicherheitshinweis“ und vermeldet „Office hat ein potentielles Sicherheitsrisiko erkannt“. Außerdem sei „Dieser Speicherort ist möglicherweise nicht mehr sicher“.
Vorweg: Links in Excel-Dokumenten zu anderen Dokumenten sind (außer in Web- oder SharePoint Dateien) nicht absolut. Die Links bleiben also nicht bei dem was man manuell hinterlegt, sondern werden „verwaltet“. Excel versucht anhand eines Regelwerkes die Links „funktional“ zu halten und ändert beim Speichern gerne „mal eben“ alle Links des Dokumentes entsprechend ab.
Was ist das? Links zu Dokumenten auf Netzlaufwerken sind auf einmal „geändert“?
Ein wahrscheinliches Szenario das wir schon öfter gesehen haben könnte also zum Beispiel so aussehen:
Es gibt ein Netzlaufwerk X: das von \\Server\Share\Folder verbunden ist
Es gibt Links in einer Arbeitsmappe dort und das Dokument wird stets dort bearbeitet
Man öffnet die Datei vermeintlich von dort
Man speichert die Datei wieder dort
Oh nein! Alle Links sind geändert und stehen plötzlich auf Profilpfaden (%appdata%\local\Folder) oder dem Systemlaufwerk (C:\Folder)
Das, also der „Link-Verlust“ (das Phänomen nennt sich neudeutsch auch „Link-Loss“) passiert immer wenn:
Das Dokument (=der PC) zwischen durch „Offline“ war und Windows die Datei im Offlinecache bearbeitet hat. Der liegt nämlich auf c:\ (siehe CSC)
Die Datei mal „kopiert“ wurde, zum Beispiel auf einen USB-Stick oder den Desktop (C:\ oder f:\ …)
Die Datei via UNC-Pfad geöffnet wurde (\\Server\Share\Folder\Datei.xlsx)
Die Datei wurde automatisch zwischengespeichert (Default: 10 Minuten). Das passiert (Default) in %appdata%\roaming\microsoft\excel
In diesen Varianten findet Excel keinen Referenzort der Datei mehr zum relativen Pfad des geöffneten Dokumentes und ändert aus „Sicherheits- und Komfortgründen“ alle Pfade. Allerdings erst beim speichern, solang das Dokument noch geöffnet ist, ist die „zukünftige“ Änderung nicht sichtbar.
Lösung
Es gibt keine „richtige“ Lösung. Links in Excel-Tabellen sind supergefährlich. In dem Moment in den Man Daten (wie z.B. Links) in einer Tabellenkalukation verwendet, ist etwas schief gelaufen, Daten verwaltet man in Datenbanken (z.B. Access).
Aber: man kann das Problem etwas einzuschränken. Das geht natürlich auch per GPO.
„Automatisches Speichern“ komplett deaktivieren
Unter Optionen/Speichern -> Automatisches Speichern den standardmäßigen Speicherort auf den (relativen!!) Pfad des Dokumentes ändern. Je nach Anzahl der Netzlaufwerke ist es natürlich unsinn, bei jeder Datei den Ort immer wieder zu ändern.
Excel (und alle anderen Office-Apps) speichern alle 10 Minuten die aktuellen Dateien. Das ist auch sehr gut so, denn wenn eine Office-App mal abstürzt oder der Datei-Handle verloren geht (Standy, Docking-Station, WLAN-Wechsel, Windows-Updates, USB-Stick Backup, Netzwerktrennung …) wird man ja von der „letzte bekannte Version“ begrüßt. Selbige kommt genau daher.
Die Outlook-Suche verhält sich ja häufiger etwas ungewöhnlich, das man aber sei einer Weile praktisch nicht mehr freigegebene Ordnern (Nicht freigegebene Postfächer) von anderen Nutzern suchen kann, ist merh als ärgerlich. Grade in Zeiten von Exchange Online ist das sehr ärgerlich.
Schuld ist Outlook in Verbindunge mit dem Windows Indexdienst. Freigegebene Ordner werden standartmäßig wie freigegebene Postfächer heruntergeladen; diese landen somit im Index. Leider beauftragt Outllook bei der Sucher nur noch „Eigenes Postfach“ und liefer somit bei freigegebenen Ordnern nur leere Ergebnismengen zurück.
Woraround
Man kann Exchange dazu zwingen, die Serverseitige Suche zu verwenden. Der Zugriff auf Microsoft 365 Exchange Online-Postfächer ist dann zwar etwas langsamer, dafür liefert die Outlook-Suche plötzliche wieder korrekte Ergebnisse. Bonus: Neu vergebene Berechtigungen greifen nun ebenfalls sofort.
Das geht unter den E-Mail Konten > E-Mail > Postfach auswähen und oben „Ändern“ > Weitere Einstellungen > Erweitert > Freigegebene Ordner herunterladen AUS schalten.
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:
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“.
