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!

Taskmanager zeigt keine CPU-Last Graphen mehr an

Problem

Der Windows Taskmanager zeigt keine CPU-Last Graphen mehr an. Es gibt zwar pro Kern eine Box, aber es wird keine Last (keine „Linie“) mehr angezeigt.

Die Graph-Anzeige bleibt leer (nicht wie hier im Bild)

Lösung

Sowohl der Windows Client (Windows 10) als auch Windows Server (2016/2019) scheinen Schwierigkeiten mit der Ermittlung der CPU-Last für den Taskmanager zu haben, wenn eine externe Lastverwaltung die Leistungsaufnahme der CPU regelt. Mit „extern“ sind hier Hardwareseitige Systeme wie das BIOS (EFI-Controller) gemeint.

In HP-Servern ist das schnell gefixt: Im BIOS einfach dem Betriebssystem die Kontrolle über die CPU-Performance/CPU-Last zurückgeben.

HPE ProLiant Server öffnen mit F9 ihr Bios, dort unter „Power Profiles“ den „HP Power Regulator“ abschalten und auf „OS Control Mode“ zurückstellen.

Negative Folgen wie eine Performanceänderung, andere Leistungsaufnahme oder instabile Systeme konnten wir nicht beobachten. Aber der Taskmanager funktioniert sofort wieder und liefert dem grapen schicke neue Werte.

WSUS Clients Fehler 0x80244010 (WU_E_PT_EXCEEDED_MAX_SERVER_TRIPS)

Problem

Fehler 0x80244010

Windows 7 Clients bekommen „auf einmal“ keine Updates mehr von einem WSUS-Server. Andere Windows-Clients und Server hingegen scheinen Fehlerfrei zu funktionieren.

Der Angegebene Fehlercode lautet 0x80244010

Im WindowsUpdate-log findet man den Eintrag:

WARNING: Exceeded max server round trips: 0x80244010 

Lösung

Dieser Fehler hat zwei mögliche Ursachen, die erste Clientseitig und die andere (WSUS-) Serverseitig.

Serverseitig ist der WSUS auf 200 „Trips“ beschränkt, also 200 Anfragen eines Clients für alle Updates pro Ziel. Das kann ab einem bestimmten Patchlevel etwas knapp werden. Hier hilft eigentlich nur „nochmal klicken“. Nach 5-7 Versuchen klappt das dann plötzlich.

Serverseitig hilft es auch oft, das Größenlimit der zurückgelieferten Updateliste (XML) zu enfernen. Standartmäßig sind das 5Mbyte, was bei Windws 7 schon mal etwas knapp werden kann. Den Konfigurationseintrag im WSUS bearbeitet man in der SQL-Konsole (SQL Management Stusio) wie folgt:

USE SUSDB
GO
UPDATE tbConfigurationC SET MaxXMLPerRequest = 0

Clientseitig hilft dann meist der Klassiker: Das Windows-Update einmal komplett und gründlich zurücksetzen. Hier die Befehle für die (CMD) Shell.

net stop Bits
net stop WuAuServ 
net stop CryptSvc
rd /s /q %windir%\SoftwareDistribution 
reg delete HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate /v SusClientId /f
reg delete HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate /v SusClientIdValidation /f
net start Bits
net start WuAuServ 
net start CryptSvc 
wuauclt /resetauthorization /detectnow 
Und schon funktioniert Windows Update wieder

Windows Server Fenster „Ereignisprotokollierung“ zu „Warum wurde der Computer unerwartet heruntergefahren“ erscheint bei jeder Anmeldung

Problem

Bei jeder Anmeldung an einem Windows Server oder einem Windows 10 erscheint das Eingabefenster „Ereignisprotokollierung“ mit der Frage, warum denn das System so unerwartet heruntergefahren wurde. Egal wie oft man dies ausfüllt und egal was man einträgt, die Meldung erscheint immer wieder. Ob „Anderer Grund“ oder Geplant, ständig nervt dieses Fenster.

Lösung

Windows legt die Informationen über den letzten „Unerwarteten“ Systemshutdown in einem Registry-Schlüssel ab. Um die Meldung loszuwerden, löscht man einfach diese drei Einträge:

HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Reliability

DirtyShutdown
DirtyShutdownTime
LastAliveStamp
TimeStampInterval

… und schon ist die Meldung verschwunden.

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

Windows Drucker taucht immer wieder auf

Problem

Ein Freigegebener Drucker von einem Druckserver taucht auf einer Windows-Maschine (in unserem Fall ein Windows Server 2016 RDS-SH) für mehrere Benutzer immer wieder auf.

Wenn man die (Hardware)-Eigenschaften überprüft, stellt man einen Zielpfad mit einer SID fest – scheinbar hat der Effekt irgendetwas mit einem bestimmten Benutzer zu tun.

Lösung

Schnelle Abhilfe schaft das einmalige vollständige entfernen des Client Side Rendering Print Provider Servers, an welchem der Drucker freigegeben ist.

Dazu einfach auf dem betroffenen Computer (oder Server) den folgenden Registry-Key entfernen:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Print\Providers\Client Side Rendering Print Provider\Servers\printserver.example.com

Sollte der Printserver dort mehrfach auftauchen (z.B. mit Servername und FQDN) am besten beider Keys löschen.

Danach die Maschine einmal neu booten und der Drucker ist verschwunden. Es kann dann vorkommen, dass Benutzer die den Drucker vorher noch zur Verfügung hatten, diesen nun als „Offline“ sehen, dann kann er einfach entfernt und neu Verbunden werden.

Unerreichbaren Lancom Accesspoint/Router via ll2mdetect und ll2mexec konfigurieren oder zurücksetzen

Problem

Ein Accesspoint ist wegen einer verpfuschten fehlerhaften Konfiguration nicht mehr erreichbar. Manchmal soll das ja mit der unbedachten Verwendung des VLAN-Moduls zu tun haben, dass einem Cisco- oder HPE erfahrenen Admin zugegebenermaßen nicht immer ganz einleuchtend erscheinen mag.

So könnte ein Admin-Albtraum aussehen

Lösung

Lancom hat glücklicherweise ein Backdoor-Protokoll zur Konsolenkonfiguration eingebaut. Böse Zungen behaupten, das sei exklusiv zur VLAN-Konfiguration geschehen, aber das ist bestimmt nur ein Gerücht.

Wichtig: Die Lancom LL2M-Erfindung ist KEINE Gerätebackdoor. Man muss immernoch passende Anmeldedaten haben; das ist nur ein Protokoll mit dem man via Layer2 (in der Regel Ethernet) auch ohne gültige IP-Konfiguration, korrekte VLANs oder bei zerstörten WLAN-Antennen auf die Gerätekonfiguration zugreifen kann.

Schritt 1: Gerät(e) finden, LL2M testen

„ll2mdetect“ listet alle via Layer2 erreichbarn Geräte auf:

> ll2mdetect
   Address 00:a0:de:ad:be:ef on Interface LAN-1:
     Name WICHTIGERAP28
     Type LANCOM IAP-822
     Serial Number 4123456789123456
     MAC-Address 00:a0:de:ad:be:ef
     HW-Release H
     Firmware-Version 11.82.0093 / 31.10.2021
   Address 00:a0:de:ad:be:eb on Interface LAN-1:
     Name WICHTIGERAP29
     Type LANCOM IAP-822
     Serial Number 4123456789012345
     MAC-Address 00:a0:de:ad:be:eb
     HW-Release H
     Firmware-Version 13.32.0066 / 31.10.2022

Schritt 2: LL2M Verbindung via ll2mexec herstellen

LL2M stellt eine echte interaktive Shell zur Verfügung. Die Verbindung ist sogar (symetrisch) verschlüsselt (mit dem Gerätepasswort) und für solche belange absolut. Sollten die Kennwörter des aktuellen Gerätes von dem die Verbindung ausgeht und des Zielgeräts nicht übereinstimmen, kann man mittels „:“ ein Kennwort in den String einfügen (name:[email protected])

> ll2mexec -i Lan-1 [email protected]

Beziehungsweise man kann auch ein anderes Kennwort verwenden:

> ll2mexec -i Lan-1 root:[email protected]

Schritt 3: Befehle via ll2mexec ausführen

Man landet auf der Konsole des Zielgerätes und kann hier sofort loskonfigurieren. Der Erfahrung zeigt das folgende Kommandos hilfreich sein können. Mit ‚cd‘ wechselt man den Konfigurationskontext, ‚ls‘ zeigt den inhalt und mit ’set‘ werden Werte gesetzt.

LL2M: VLAN-ID eines IP-Netzwerkes ändern

> cd Setup/TCP-IP/Network-list/INTRANET

> set VLAN-ID 1337
   set ok:
   VLAN-ID  VALUE:   0 
>

LL2M: VLAN-Modul deaktivieren

> cd Setup/VLAN

> set operating no

LL2M: Gerät resetten (Auf Werkszustand zurücksetzen und booten)

>  do /other/reset