Andreas-IT-Blog

Bei Remotedesktop Servern wird der Hostname des Clients in einem Registry-Key mit auf den Terminalserver in die Session mitgenommen. Oft hängen platzbezogene Einstellungen von Anwendungen an diesem mitgeschleiften Hostname. Der Eintrag ist in

Computer\HKEY_CURRENT_USER\Volatile Environment\2

zu finden. Die Ziffer variiert jeweils und entspricht der Session ID. Hat man nun aber Einstellungen, die man gerne an User-Abhängig binden will (egal von welchem Client aus eingewählt wird) kann man dies per Skript lösen. Wir hatten z.B. den Fall, dass User sich von einer Citrix-Farm von verschiedensten Hosts/Servern aus einwählen auf den RDP-Server.

Batch in den Autostart des User:

For %%A in („%TEMP%“) do @Set SessionID=%%~nxA

reg add „HKCU\Volatile Environment\%SessionID%“ /v CLIENTNAME /t REG_SZ /d %USERNAME% /f

setx.exe CLIENTNAME %USERNAME%

set CLIENTNAME=%USERNAME%

So wird den Registry-Key „permanent“ auf den jeweiligen Usernamen gesetzt – die Hostname-Abhängigen Einstellungen bleiben bestehen.

Ein häufiges Problem beim Austausch von PCs sind fehlende Druckertreiber. So hatte ich neulich einen PC unter den Fingern, der den NetPrintQueue2Fax von Microsoft / GFI verbunden hatte. Dieser lies sich vom Faxserver aber nicht mehr verbinden aus verschiedenen Gründen. In meinem Fall erwies es sich als Lösung, die Treiber vom alten PC zu exportieren und so am neuen Client über die Druckverwaltung zu installieren. Im Anschluss konnte der Drucker via Netzwerk gemappt werden.

Wie vorgehen? Am alten Gerät in der Registry suchen:

Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\.. ..Control\Print\Environments\Windows x64\Drivers\Version-3

Entscheidend der Eintrag im Schlüssel INFPATH – hier liegt quasi der Treiber bereit.

Ein sehr interessanter Fall eines Kollegen (Danke an SB!) auf einem Kundensystem: Der Kunde klagt, dass der Server immer träger wird und selbst nach Neustart nur kurzzeitig flott arbeitet. Wir sehen im Troubleshooting eine sehr hohe RAM-Auslastung.

Sehr zu empfehlen an dieser Stelle die Tools von Sysinternals: https://live.sysinternals.com

Uns half RAMMap.exe, es war sichtbar dass der Nonpaged Pool einen Löwenanteil des RAMs für sich in Beschlag nimmt. Wer oder was steckte aber dahinter?

Mein Kollege konnte mit POOLMON aus dem Windows Driver Kit analysieren und sah, dass ein Treiber der ISDN-Karte (Hersteller Gerdes Primux) immer innerhalb kürzester Zeit ans Maximum wuchs:

Set-Location „C:\Windows\System32\drivers“

Select-String -Path *.sys -Pattern „XXXX“ -CaseSensitive | Select-Object FileName -Unique

Dann den zugehörigen Treiber bzw. Hersteller auslesen:

In unserem Fall war die ISDN-Karte sowieso nicht mehr genutzt, nach Abstecken und Deinstallation der Treiber war der Fall abgeschlossen – wird das Gerät benötigt kann ich mir vorstellen dass ein Update des Treibers und/oder Austausch des Gerätes Ansätze sein könnten!

PS. beim Erstellen des Beitrages fand ich auch noch diesen Blog: https://medium.com/@clintcolding/finding-memory-leaks-with-poolmon-3da80e479040

Hier wird im Prinzip exakt unser Problem wie auch die Lösung beschrieben, dort ist zusätzlich der gute Hinweis auf den Parameter /b für Poolmon erwähnt. Dadurch werden die Ergebnisse nach Speichernutzung sortiert.

Der Vollständigkeit halber die Parameter in der Übersicht: https://learn.microsoft.com/en-us/windows-hardware/drivers/devtest/poolmon-startup-command

Support-Fall neulich, sah zuerst nach Standard aus: VPN-Einrichtung auf neuem Laptop. Der üblicherweise eingesetzte Watchguard SSL Client wird ohne Fehler installiert, verbindet auch kurz (für 1 Sekunde) und trennt VPN wieder. Mit den Infos aus den Logs lies es sich partout nicht lösen, Konfiguration passte. Da der Watchguard SSL Client auf den OpenVPN Client aufbaut also mit eben diesem direkt probiert.

Dieser aber lässt sich nicht installieren. Es stellt sich dann heraus, dass der „Laptop“ ein Samsung Galaxy Tablet ist mit Windows 11 drauf – und dieser hat einen ARM Snapdragon Prozessor.

Daher funktionieren die Open-VPN-Clients für AMD64 und x86 nicht.

OpenVPN bietet auch einen Client für ARM an, diesen installiert, konnte aber nicht verbinden:

Mon Jan 30 16:43:08 2023 OPTIONS ERROR: failed to negotiate cipher with server.  Add the server’s cipher (‚AES-256-CBC‘) to –data-ciphers (currently ‚AES-256-GCM:AES-128-GCM:CHACHA20-POLY1305‘) if you want to connect to this server.

Wir konnten dies umgehen indem wie eine ältere Version (2.5.4) installierten, der Parameter -cypher gibt es wohl nicht mehr (steht aber so in der heruntergeladenen Config von Watchguard drin).

Nach etwas Recherche sehe ich aber dass es evtl. auch geklappt hätte in der Config „cipher AES-256-CBC“ mit „data-ciphers AES-256-CBC“ zu ersetzen. Dies ist wohl der neue Parameter dazu.

Eher zur Doku – ich suche doch in gewisser Regelmäßigkeit nach dem Parameter / der genauen Notation. Möchte man eine OpenVPN-Verbindung direkt starten (per CMD oder mit einer Verknüpfung) dann so:

„C:\Program Files\OpenVPN\bin\openvpn-gui.exe“ –connect Konfiguration.ovpn

Die Konfiguration ohne Pfad angeben, vorab importieren.

Neulich passierte mir ein blödes MIssgeschick – „schnell“ noch die RAM-Konfiguration eines Servers anpassen am Abend, was soll schon schiefgehen. Um Zeit zu sparen mit dem Handy per Teamviewer, mit Kind auf dem Arm.

Am Eintippen der neuen RAM-Zahl dann aber auf die falsche Taste gekommen und irgendwie ungewollt bestätigt – und schon war der maximale RAM auf 8 MB eingestellt.

Der Prozess sqlservr.exe beendete sich promt und lies sich nicht mehr starten! Ein Einloggen ins Management Studio war ebenfalls nicht mehr möglich.

Zum Fehler fand sich allerlei im Netz „Kein Prozess am anderen Ende der Pipe“ ist weit verbreitet. Eine Lösung für meinen Fall entdeckte ich nach einiger Suche hier:

https://gavindraper.com/2017/08/09/sql_minimial_configuration_mode/

Thanks a lot @Gavin Draper!

If for any reason you can’t start a SQL Server instance due to a configuration change you can start it in minimal configuration mode so you can fix the offending settings by doing the following…

1. Log on to the computer running the SQL instance
2. Open the SQL Server configuration manager
3. In start up arguments add a new one of -f
4. Start the instance
5. Change any settings that need changing
6. Remove the -f argument from startup parameters
7. Restart the instance

Zu Punkt 3 kann ich anmerken: die zwei vorhandenen zwei Zeilen einfach unangetastet lassen. Ich konnte die eingentlich gewollten 8196 MB eintragen, der mir bisher unbekannte Parameter rettete!

Ein Dank geht an alle Administratoren, User und fleißigen Leute die sich die Zeit nehmen und mir in unzähligen Situationen Informationen schenkten.

Vorbilder und Inspiration für diesen Blog sind seiten wie

https://www.andysblog.de/
https://www.borncity.com/blog/
https://blog.workinghardinit.work/

und viele mehr!