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.
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])
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)
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:
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.
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:
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„.
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:
