Exchange Abwesenheitsbenachrichtigung (Out of office reply) nur an bekannte Absender zuslassen

Problem

Exchange-Absenheitsbenachrichtigungen (Out of Office replys) sind traditionell ein schwerwiegender Punkt interessanter Diskussionen. Technisch simpel umgesetzt, birgt das Konzept viele Gefahren für schweren Mißbrauch (Amplification-Attack, Spam, Datenschutz, Überwachung, Einbruch …).

Ein oft eingesetzer Kompromiss ist der Versand nur an „bekannte“ Absender. Da dem Exchange aber nicht alle Absender „bekannt“ sind (Exchange kann nachvollziehbarerweise nicht in Echtzeit alle Kontakte in allen Mailboxen durchsuchen) muss das pro Mailbox passieren. Outlook sieht diese Möglichkeit sinnvollerweise auch (als Mailboxsetting) vor. Leider bleibt die Auswahl weiterhin dem „fehleranfälligen“ Benutzer überlassen.

Nur in Outlook: „Jeder außerhalb meiner Organisation“ ist weiterhin anwählbar

Lösung

Die die Einstellung Serverseitig, also pro Mailbox, definiert ist, hilft hier eine Gruppenrichtlinie (GPO) nicht weiter. Diese würde vielleicht Outlook betreffen, aber von OWA und allen anderen E-Mail-Clients ignoriert werden.

Da diese Einstellung aber Pro-Exchange-Mailbox gesetzt wird, kann man via Powershell die gesetzte Einstellung relativ einfach „korrigieren“. Wir haben dazu dieses Script erstellt, das nebenbei auch den „Powershell state: busy“ Fehler umgeht, der auftritt wenn man zu viele Requests an die Exchange-API gleichzeitig sendet (foreach statt einfach |set).

$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri http://MEINSERVER.MEINFQDN/PowerShell/ -Authentication Kerberos
Import-PSSession $Session -AllowClobber
Import-Module ActiveDirectory -ErrorAction STOP

Function ChangeMailboxListWithExternalAudience {
    $MailboxListWithExternalAudience = Get-Mailbox | Get-MailboxAutoReplyConfiguration | where { ($_.AutoReplyState -eq "Enabled") -AND ($_.ExternalAudience -eq "All") }

    foreach ($eintrag in $MailboxListWithExternalAudience) { 
        Set-MailboxAutoReplyConfiguration $eintrag.Identity -ExternalAudience "Known"
    }
}

ChangeMailboxListWithExternalAudience

Das Script wird einfach regelmäßig via „Geplante Aufgaben“ ausgeführt und rediziert so die Angriffsfläche auf einen (relativ) kleinen zeitlichen Versatz.

Bein Einsatz des Scripts auf die ExecutionPolicy achten!

Outlook 2013/2016/365 Archivierung funktioniert nicht richtig, alte Elemente werden nicht korrekt archiviert

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“.

Outlook Programmgesteuerter Zugriff per GPO

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„.

Microsoft „Teams“ mittels Gruppenrichtlinie aus dem Autostart entfernen oder hinzufügen

Teams ist der neue Hauptclient für eine schnelle und intelligente Kommunikation in Office 365 und ersetzt grade mit Lichtgeschwindigkeit Skype for Business (Online). Leider setzt Microsoft das grade etwas ungeschickt um und verteilt den Teams Client in Office-Updates mit konfigurierter Autostart-Option.

Teams aus Autostart entfernen (GPO)

Notwendig ist die Erstellung und Verknüpfung einer Gruppenrichtlinie, die den unerwünschten RUN-Eintrag aus der Registry der Benutzern entfernt.

GPO erstellen, dann unter Benutzerkonfiguration > Einstellungen > Windows-Einstellungen > Registrierung > Neu:

Aktion:         Löschen 
Struktur:       HKEY_CURRENT_USER 
Schlüsselpfad:  SOFTWARE\Microsoft\Windows\CurrentVersion\Run 
Wertname:       com.squirrel.Teams.Teams 

Teams zu Autostart hinzufügen

Das Hinzufügen funktioniert genauso – nur mit der Aktion „Erstellen“. Der zugehörige Befehl lautet allerdings anders als das original.

Original (funktioniert NICHT)
C:\Users\%username%\AppData\Local\Microsoft\Teams\Update.exe --processStart "Teams.exe" --process-start-args "--system-initiated"
So funktioniert es:

C:\Users\%username%\AppData\Local\Microsoft\Teams\Update.exe --processStart "Teams.exe" --process-start-args "--user-initiated" 

Microsoft OneDrive Explorer-Fenster öffnet sich ständig von selbst

Problem

Ein Anweder klagt, es würde sich sporadisch und vor allem ohne Zutun ein Explorer-Fenster öffnen, das den Inhalt der Microsoft OneDrive (for Business) zeigt.

Lösung

Der Nutzer hat recht, es gibt tatsächlich einen Geist der das Fenster „von selbst“ öffnet. Und zwar aus der Zeit vor dem Windows 10 Update; war auf dem PC vorher schon OneDrive installiert, entfernt das Upgrade zwar die alte OneDrive-Installation, nicht aber den Update-Task dazu.

In der Aufgabenplanung nach „Microsoft OneDrive Auto Update Task“ suchen. Wenn dieser im Format „Microsoft OneDrive Auto Update Task-S-x-x-xx-xxxxxxxxxx-xxxxxxxxx-xxxxxxxxxxx-xxxx“ angelegt ist und auf „%localappdata%\Microsoft\OneDrive\OneDrive.exe /autoupdate“ zeigt, ist dieser veraltet und löst das Fenster aus.

Diesen Task einfach deaktivieren, schon ist Ruhe.

Die „richtigen“ geplanten Aufgaben heissen „OneDrive Standalone Update Task“ und zeigen auf den Installer in „%localappdata%\OneDrive\17.3.6517.0809\OneDriveStandaloneUpdater.exe“.

„Diese Kopie von Microsoft Office kann auf einem Computer, der die Terminaldienste ausführt, nicht verwendet werden.“ mit Office 365 ProPlus

Trotz korrekter Terminalserver-Installation kommt es seit Ende der Jahres 2018 unter Windows Server 2016 in einer RDS-Umgebung häufiger zu diesem Fehler beim Start der Office-Anwendungen:

Diese Kopie von Microsoft Office kann auf einem Computer, der die Terminaldienste ausführt, nicht verwendet werden. Damit Microsoft Office auf einem Computer, der die Terminaldienste ausführt, verwendet werden kann, müssen Sie eine Volumenlizenzedition von Office verwenden.
Diese Kopie von Microsoft Office kann auf einem Computer, der die Terminaldienste ausführt, nicht verwendet werden. Damit Microsoft Office auf einem Computer, der die Terminaldienste ausführt, verwendet werden kann, müssen Sie eine Volumenlizenzedition von Office verwenden.

Der Inhalt dieser Meldung ist mit Office ProPlus natürlich Unsinn und nur ein Überbleibsel aus vergangenen Tagen. Office ProPlus (oder auch „O365ProPlusRetail“) dürfen durchaus in RDS-Umgebungen genutzt werden.

Eigentlich sorgt bei der Installation der Klick-und-Los Variante („setup /configure“) der Eintrag „SharedComputerLicensing“ in der XML-Datei für die richtige Konfiguration; das scheint aber nicht immer so richtig zu klappen. Vor allem unter Office 2019 (das nur Office365 heißt) ist das der Fall – vermutlich weil sich der zugehörige Registry-Schlüssel geändert hat. Früher wohnte dieser in Office\<version>\ClickToRun, nun entfällt <version>.

„Richtige“ Bereitstellungsdatei

<Configuration>
  <Add OfficeClientEdition="32" Channel="Monthly">
    <Product ID="O365ProPlusRetail">
      <Language ID="de-de" />
    </Product>
  </Add>
<Updates Enabled="TRUE" Channel="Monthly" />
<Display Level="NONE" AcceptEULA="TRUE" />
<Property Name="AUTOACTIVATE" Value="1" />
<Property Name="SharedComputerLicensing" Value="1" />  <--_HIER____
</Configuration>

Lösung

Wenn das mal wieder nicht so recht geklappt zu haen scheint, kann man den notwendigen Registry-Eintrag jederzeiot von Hand hinzufügen und schon ist Office wieder Terminalserver-Fähig.

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\ClickToRun\Configuration
   Name: SharedComputerLicensing
   Typ: REG_SZ ("Zeichenfolge")
   Inhalt: 1

Es ist kein reboot notwendig, nach einem Neustart der Anwendungen läuft Office ohne Fehler.

Office 365 Exchange Online Powershell unter Windows 10 Verbindung herstellen

Die Office 365 Exchange Online Powershell benötigt eigentlich keine Powershell Modul-Installation, weil zu Exchange nur eine Remote-Session hergestellt wird.

Anders sieht da aus, wenn man die MFA (Mehr-Faktor-Authentifizierung) eingeschaltet hat. Dazu unten mehr.

Exchange Online Powershell ohne MFA

$credential = Get-Credential
$exchangeSession = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri "https://outlook.office365.com/powershell-liveid/" -Credential $credential -Authentication "Basic" -AllowRedirection
Import-PSSession $exchangeSession -DisableNameChecking -AllowClobber

Das erste Kommando fragt die Credentials ab und speichert diese in der Variable $credential, das zweite verwendet diese für die Verbindung und das dritte importiert die Remote-Sitzung.

Exchange Online Powershell mit 2FA (Mehr-Faktor Authentifizierung)

Hierfür muss man zuerst doch noch manuell ein Modul herunterladen, das „Exchange Online Remote PowerShell-Modul„. Man findet den Download für die Offline-Installation innerhalb seines Office 365 Portals in der EAC. Mann kann diese Spezial-Powershell aber auch direkt ohne Umwege herunterladen und starten; der Link dazu steht weiter unten.

Office 365 Portal > Exchange Administrator Center (EAC) > Hybrid > „Konfigurieren“ (‚Das Exchange Online-PowerShell-Modul unterstützt mehrstufige Authentifizierung.‘)

Hat man das Modul heruntergeladen und installiert, sollte man einmal sein WinRM-Konfiguration testen. Ein lauffähiges WinRM-System mit eingeschalteter Basic-Authentifizierung (Default) ist Voraussetzung.

WinRM-Konfiguration in der Powershell „als Administrator“ anschauen:

winrm get winrm/config/client/auth

Sollte da „Basic = false“ in der Ausgabe stehen, muss man zwingend Basic-Auth einschalten:

winrm set winrm/config/client/auth @{Basic="true"}

Dann kann man auch schon endlich fast eine Verbindung herstellen; dazu das „Microsoft Exchange Online Powershell Module“ im Startmenü öffnen. Dier hier ist der direkte Download-Link zur Exchange Shell:

https://cmdletpswmodule.blob.core.windows.net/exopsmodule/Microsoft.Online.CSE.PSModule.Client.application

In der neuen Exchange-Powershell tippt man dann:

Connect-EXOPSSession -UserPrincipalName <[email protected]>

Und schon stehen einem die altbekannten CMDlets wie Get-Mailbox, Get-DistributionGroup oder Get-MailboxPermission zur Verfügung.