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

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:kennwort@mac)

> ll2mexec -i Lan-1 root@00a0deadbeef

Beziehungsweise man kann auch ein anderes Kennwort verwenden:

> ll2mexec -i Lan-1 root:SUPERgeheim123@00a0deadbeef

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 

Windows Server 2019 als NTP-Server

Problem

Der NTP-Server als Teil des Windows-Zeitgeber („W32Time“) vergisst nach einem In-Place-Update gerne das er als Zeitquelle zur Verfügung stehen soll. Auch wenn der Server vorher als Zeitquelle korrekt konfiguriert war, funktioniert die Zeitübergabe plötzlich nicht mehr (für nicht-windows-clients, die ja nicht NTP verwenden).

NTP Clients erhalten keine korrekte Zeit mehr und w32tm von einem Client-PC aus meldet den Fehler 0x800705B4

C:\> w32tm /stripchart /computer:SERVER.DOMAIN.TLD /dataonly
SERVER wird verfolgt [192.168.42.42:123].
 Es ist 11.11.2019 11:11:17.
 16:46:17, Fehler: 0x800705B4

Lösung

Der Upgrade-Prozesschaltet den NTP-Lieferanten auf Port 123 ab. Einschalten des NTP-Servers über die Registry („Enabled “ auf „1“) hilft:

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders\NtpClient]

 "Enabled"=dword:00000001

Danach den Zeitdienst neu starten und alles ist wieder in Ordnung.

C:\> net stop w32time && net start w32time

TrendMicro WFBS 10 (Worry Free Business Security) Installationsfehler „Fehler 311, 0xfffffb57“

Trend Micro WFBS 10.0 SP1 Patch Build 2178 hat einen Fehler in der Installationsroutine via Autopcc. Die Installation bricht nach einer Weile mit dem „Fehler 311,0xfffffb57“ ab und lässt sich nicht korrekt beenden.

Lösung

Das liegt daran, das der Client bei der Installation für den Pre-Setup-Scan die Scan-Engine laden will, diese aber DLLs auf dem lokalen System voraussetzt die in dem knapp 1Gbyte großen MSI-Paket (das auch nach %temp% kopiert wird) nicht enthalten sind.

  • Auf dem WFBS Security Server in dem Pfad: %program files%\Trend Micro\Security Server\PCCSRV\Autopcc.cfg\ die Datei AUTOPCC.INI bearbeiten
  • Im Abschnitt [INSTALL] den Wert NoPrescan auf „1“ stellen
  • Datei speichern, danach läuft die Client-Installation sofort fehlerfrei durch

Vermutlich (hoffentlich) wird der Fehler im nächsten Update behoben.

Windows Eventlog CAPI2 Event 513 „AddLegacyDriverFiles: Unable to back up image of binary“

Problem

Bei jedem Backup das einen externen VSS-Agenten benutzt, beispielsweise Veeam B&R mit Application Awareness, werden diese Fehler vom Kryptografiedienst (CAPI2 steht für „Windows CryptoAPI v2“) gemeldet. In der Meldung steht „Zugriff zudem verweigert“, was auf fehlenden Zugriffsrechte hindeutet.

Fehler beim Kryptografiedienst während der Verarbeitung des „OnIdentity()“-Aufrufobjekts „System Writer“.

Lösung

Das Dienstobjekt „Microsoft Link-Layer Discovery Protocol“ hat tatsächlich nicht die korrekten Berechtigungen, um vom VSS System Writer gelesen zu werden.

Man kann die Berechtiugung manuell hinzufügen, oder das die Kommandozeile erledigen lassen:

C:\> sc sdset mslldp D:(D;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;BG)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;SY)(A;;CCDCLCSWRPDTLOCRSDRCWDWO;;;BA)(A;;CCLCSWRPWPDTLOCRRC;;;SO)(A;;CCLCSWLOCRRC;;;SU)(A;;LCRPWP;;;S-1-5-80-3141615172-2057878085-1754447212-2405740020-3916490453)

Danach ist die Meldung sofort verschwunden 🙂

Update: Microsoft hat dazu einen KB-Artikel veröffentlicht https://support.microsoft.com/en-us/help/3209092/event-id-513-when-running-vss-in-windows-server