Quantcast
Channel: Andy – Andy's Blog
Viewing all 2171 articles
Browse latest View live

Aktuelles Windows 10-Medium herunterladen

$
0
0

Dank Windows-as-a-Service benötigt man eigentlich ständig ein aktuelles Installationmedium von Windows 10. Download-Möglichkeiten gibt es einige.

Der offizielle Weg seitens Microsoft besteht in der Verwendung des Media Creation Tools (kurz MCT). Dieses wird mit jedem Windows 10-Upgrade aktualisiert und lädt das ausgewählte ISO herunter oder erstellt aus einem USB-Stick ein entsprechendes Installationsmedium:

Microsoft – Windows 10 herunterladen

Direkt von Microsoft gibt es allerdings ebenfalls ISO-Dateien, die man mit einem kleinen Trick ebenfalls herunterladen kann. Man muss die gleiche Seite mit einem Browser aufrufen, der sich nicht als Windows zu erkennen gibt.

Mit Internet Explorer 11 und Edge geht dies durch das Emulieren eines anderen Browsers. Dazu „F12 Entwickleroptionen“ öffnen und bei „Benutzer-Agents“ z.B. „Apple Safari (iPad)“ auswählen. Ggf. muss die Seite dann nochmal geladen werden.

Bei Firefox hilft das Add-on User-Agent Switcher von Linder:

Für Google’s Chrome gibt es ebenfalls Anleitungen im Netz.

Zum direkten Suchen und Herunterladen gibt es dann noch Seiten wie rg-adbuard.net. Da gibt’s dann auch Office und weitere Microsoft Produkte.

Von HeiDoc.net gibt’s ein Download-Tool für Windows und Office:

Microsoft Windows and Office ISO Download Tool

Dann gibt’s als weiteres noch Tools wie UUP dump. Auf der Seite wählt man aus, was man haben möchte, läd in einem Archiv ein entsprechendes Skript samt Tools herunter, entpackt dieses und führt das Skript aus. Danach ist je nach Internetanschluss und Rechnerperformance erstmal etwas Geduld gefragt, da das ausgewählte Abbild sozusagen live auf dem eigenen PC zusammengebaut wird.

Hier ist zwar das Ende des Beitrags erreicht, es gibt für das Thema aber noch mehr kleine Helferlein im Netz. Dies hier stellt nur einen Auszug dar.


Linux: Schneller Daten von fehlerhafter Festplatte retten

$
0
0

Mit ddrescue lassen sich sehr gut Daten von einer defekten Festplatte retten. Beschrieben wurde dies bereits hier. Bei großen Kapazitäten dauert dies allerdings sehr lange und man kopiert mitunter viel ungenutzten freien Speicherplatz mit.

Am Fallbeispiel einer 1 TB Notebook-Festplatte, auf der Windows 10 in einer 915 GB großen Partition installiert ist (LW C:\) und dabei lediglich nur um die 44 GB belegt sind, dauert die Erstellung eines RAW-Abbilds mit ddrescue etwas mehr als zwei Tage. Dabei ist der überweigende Teil dieses Abbilds unnütz.

Effektiver und schneller geht der Vorgang vonstatten, wenn man ddrescue vorher eine Art Karte mitgibt, auf der verzeichnet ist welche Bereiche belegt sind und folglich gesichert werden sollten. Möglich macht das Partclone.

Das betroffene Notebook wurde mit einer PartedMagic-CD gestartet und dann Schritt für Schritt wie folgt vorgegangen.

Die zu sichernde Partition mit

fdisk -l

ermitteln. Beispielausgabe:

Festplatte /dev/sda: 931,5 GiB, 1000204886016 Bytes, 1953525168 Sektoren
Einheiten: Sektoren von 1 * 512 = 512 Bytes
Sektorgröße (logisch/physikalisch): 512 Bytes / 4096 Bytes
E/A-Größe (minimal/optimal): 4096 Bytes / 4096 Bytes
Festplattenbezeichnungstyp: gpt
Festplattenbezeichner: 9FF70AAA-D393-4B8A-8EA7-9F5598BC5D28

Device          Start        End    Sectors   Size Type
/dev/sda1        2048     534527     532480   260M EFI System
/dev/sda2      534528     567295      32768    16M Microsoft reserved
/dev/sda3      567296 1920621392 1920054097 915,6G Microsoft basic data
/dev/sda4  1920622592 1924184063    3561472   1,7G Windows recovery environment
/dev/sda5  1924184064 1953513471   29329408    14G Microsoft basic data

Festplatte /dev/sdb: 465,8 GiB, 500107862016 Bytes, 976773168 Sektoren
Einheiten: Sektoren von 1 * 512 = 512 Bytes
Sektorgröße (logisch/physikalisch): 512 Bytes / 512 Bytes
E/A-Größe (minimal/optimal): 512 Bytes / 512 Bytes
Festplattenbezeichnungstyp: dos
Festplattenbezeichner: 0x7028503f

Device     Boot Start       End   Sectors   Size Id Type
/dev/sdb1        2048 976769023 976766976 465,8G  7 HPFS/NTFS/exFAT

„/dev/sda“ ist die im Notebook verbaute Festplatte, „/dev/sda3“ ist dabei die zuvor erwähnte Windows-Partition. „/dev/sdb1“ ist eine via USB angeschlossen Festplatte, die als Backup-Ziel dient.

Nun erstellt man mit Partclone die „Karte“ der belegten Sektoren:

partclone.ntfs -s /dev/sda3 -D -o sda3.domain

Beispielausgabe:

Partclone v0.2.73 http://partclone.org
Starting to map device (/dev/sda3) to domain log (sda3.domain)
Elapsed: 00:02:13, Remaining: 00:00:00, Completed: 100.00%                      
Total Time: 00:02:13, 100.00% completed!
done!
File system:  NTFS
Device size:  983,1 GB = 240006762 Blocks
Space in use:  51,7 GB = 12631621 Blocks
Free Space:   931,3 GB = 227375141 Blocks
Block size:   4096 Byte
Elapsed: 00:00:08, Remaining: 00:00:00, Completed: 100.00%, Rate: 388,04GB/min, 
current block:  240006763, total block:  240006762, Complete: 100.00%           
Total Time: 00:00:08, Ave. Rate:  388,0GB/min, 100.00% completed!
Syncing... OK!
Partclone successfully mapped the device (/dev/sda3) to the domain log (sda3.domain)
Cloned successfully.

Zuvor wurde mittels „cd /media/sdb1/Backup/RAW“ in das Ziel-Verzeichnis auf der Backup-Platte gewechselt. Gut zu wissen ist, das Partclone mit verschiedenen Dateisystemen umgehen kann. So lässt sich z.B. mit „partclone.ext3“ eintsprechend eine mit ext3 formatierte Partition behandeln.

Als letzten Schritt lässt man ddrescue mit der zuvor erstellten Datei arbeiten:

ddrescue --domain-log sda3.domain /dev/sda3 sda3.img sda3.log -n

Beispielsausgabe:

GNU ddrescue 1.18.1
Press Ctrl-C to interrupt
rescued:    51739 MB,  errsize:   12288 B,  current rate:      392 B/s
   ipos:    28704 MB,   errors:       2,    average rate:    8045 kB/s
   opos:    28704 MB, run time:    1.78 h,  successful read:       0 s ago
Finished

Mit dem so erstellten Abbild kann man weiterarbeiten, sei es um dieses direkt auf einer neuen Festplatte wiederherzustellen, dieses zu Mounten oder z.B. unter Windows mit OSFMount und weiteren Tools bearbeiten zu können.

Apropos OSFMount: Dieses läuft nur unter Windows. Bei einem wie oben erstellen Abbild muss man die Meldung nach der Abbild-/Disk-Größe (Image-/Disk-Size) mit „Ja“ bestätigen, andernfalls klappt es nicht richtig.

Evtl. muss zudem „Read-only“ deaktiviert werden, falls es mit nicht funktioniert.

Quellen:

superuser – Why can’t ddrescue just recover blocks used by the filesystem?

Partclone – [Partclone-user] [PATCH] Using partclone to create a domain log file for GNU ddrescue

Open Source und Cross-Platform CAD-Programme für Schaltpläne

$
0
0

Kurz notiert: Neulich habe ich etwas angefangen zu basteln und dazu ganz klassich mit Papier und Bleistift einen Schaltplan gezeichnet und korrigiert. Bei dieser Gelegenheit kam die Frage auf, wie es denn für solche Vorhaben mit entsprechenden CAD-Programmen gerade und vor allem im Open Source-Bereich als auch für verschiedene Betriebssysteme aussieht.

Auf die Schnelle fanden sich dann

KiCad EDA – Kann neben Schaltplan ebenfalls PCB-Layout und 3D-Ansicht

QElectroTech – Klassicher Stromlaufplan

Getestet habe ich beide bislang leider nicht und die Bastelei liegt gerade auf Eis, aber bevor man noch mal sucht hat man hier schon mal die Links.

ownCloud: Installierte Version ermitteln

$
0
0

Mit einem Geschäftspartner tauschen wir Dokumente über dessen ownCloud-Installation aus. Nachts fahren wir automatisch via WebDAV ein Backup dieser Daten (zusätzlich zu seiner eigenen vollständigen Sicherung).

Heute früh begrüsste mich ein Monitoring-Alarm, das dabei irgendetwas schief gelaufen ist. Das kommt nahezu regelmässig vor, meist scheitert es an einem abgelaufenen Let’s Encrypt-Zertifikat. Das war auch heute so. Soweit, so gut. Aus irgendeinem Grund wollte ich heute früh allerdings zusätzlich in Erfahrung bringen, welche Version von ownCloud im Einsatz ist.

Da ich keinen administrativen Zugang zu dieser Installation habe wurde kurz im Netz geschaut und es fand sich eine Antwort:

ownCloud Central – How to find out which version I am using?

Durch den Aufruf der Status-Seite kann die Version ausgelesen werden. Das wurde gleich ausprobiert. Im Browser die Adresse nach folgender Syntax eingeben:

https://<domain.tld>:<Port>/status.php

Die Ausgabe sind dann z.B.so aus:

{"installed":true,"maintenance":false,"version":"8.0.4.2","versionstring":"8.0.4","edition":""}

Wie schon geahnt handelt es sich um eine sehr alte Version von ownCloud. Version 8.x wurde 2015 veröffentlicht. Hautpversionen erhalten 18 Monate lang Updates. So oder so ist diese Version EOL.

Den aktuellen Versionsstand kann man beispielsweise unter folgenden Adressen nachlesen:

ownCloud – Server- Changelog

GitHub – owncloud/core – Maintenance and Release Schedule

Wikipedia – ownCloud

Windows: Per Skript oder Befehl die Startzeit einer Aufgabe ändern

$
0
0

Möchte man automatisiert per Skript oder aus der Ferne den Startzeitpunkt einer Aufgabe ändern, so lässt sich das einfach bewerkstelligen.

Anbei in Kopie die Ausgabe einer PsExec-Sitzung:

C:\windows\system32>schtasks /query /tn "Datensicherung"

Ordner: \
Aufgabenname                             Nächste Laufzeit       Status
======================================== ====================== ===============
Datensicherung                           12.02.2019 23:00:00    Bereit

C:\windows\system32>schtasks /TN Datensicherung /CHANGE /ST 23:30
Geben Sie das Kennwort für <Benutzername> ein, mit dem der Befehl ausgeführt wird: <Kennwort>
ERFOLGREICH: Die Parameter der geplanten Aufgabe "Datensicherung" wurden geändert.

C:\windows\system32>
C:\windows\system32>schtasks /query /tn "Datensicherung"

Ordner: \
Aufgabenname                             Nächste Laufzeit       Status
======================================== ====================== ===============
Datensicherung                           12.02.2019 23:30:00    Bereit

Die eigentliche Änderung wird mit

schtasks /TN <Aufgabenname> /CHANGE /ST <Uhrzeit>

durchgeführt.

Nebenbei bemerkt: Die *.xml-Datei einer bereits vorhandenen Aufgabe zu bearbeiten hilft meiner Erfahrung nach nicht. Auf der sicheren Seite ist man mit dem oben genannten Befehl oder einem Reimport.

Quellen:

stackoverflow – SCHTASKS Change Start Time of Task

Microsoft Windows DevCenter – Docs – Windows – Desktop – Task Scheduler – Task Scheduler Reference – Schtasks. exe

Windows: Alternative Geräte-Manager über’s Netzwerk nutzen

$
0
0

Wie einst im Jahre 2014 in Kein Zugriff mehr auf den Geräte-Manager unter Windows über das Netzwerk möglich beschrieben, so funktioniert der Geräte-Manager von Microsoft auch 2019 nicht mehr über das Netzwerk. Abhilfe steht in Form von Alternativen bereit.

Zum einen wäre da DeviceTool, zum anderen DevManView.

Beide sind portable, also keine Installation notwendig. DeviceTool ist etwas hübscher als auch schneller und die Verbindung zu einem anderen PC ist einfacher zu erreichen („Aktion – Verbindung mit anderem Computer herstellen“ vs. „Options – Advanced Options“). Das Tool von NirSoft ist über’s Netzwerk recht langsam, dafür aber Detailreicher.

Voraussetzung neben dem administrativen Zugriff auf den entfernten Rechner ist zumindest bei DeviceTool das WMI in der Windows-Firewall zugelassen ist. Andernfalls können keine Informationen abgerufen werden.

Es bleibt allerdings bei der klassischen Einschränkung wie beim Windows-eigenen Geräte-Manager im Netzwerkbetrieb auch das man nur Anschauen, aber nicht Anfassen kann. Eine kleine Ausnahme stellt DeviceTool dar, da es in Verbindung mit PsExec Geräte deaktivieren kann.

Hilfreich sind die zwei Tools so oder so, schon allein aus informativen Gründen.

Quellen:

Microsoft TechNet Forum – Unable to access device manager remotely

Windows 10: Updateinstallationen werden nicht abgeschlossen, WoL funktioniert nicht mehr, usw.

$
0
0

Der Schnellstart-Modus von Windows 10, genau genommen gibt’s diesen sogar seit Windows 8, sorgt leider immer wieder für Probleme.

Bei einigen Kunden haben wir beobachtet, das z.B. die Installation von Windows Updates nicht abgeschlossen werden, da der Neustart ausbleibt. Der „vermeintliche“ Neustart bei ab Werk aktiven Schnellstart hilft dabei nicht.

In der Vergangenheit und auch aktuell streikt dann z.B. auch Wake-on-LAN (WoL).

Relativ neu hinzu gekommen ist das Phänomen, das Windows 10-Computer beim Herunterfahren (mitunter als Teil des Neustarts zum Abschluss von Windows Updates) hängen bleiben. Der Computer läuft zwar weiter, reagiert aber nicht mehr (außer vielleicht auf Ping), die Displays bleiben dabei schwarz. Da hilft nur noch hart ausschalten und/oder Stecker ziehen.

In den allermeisten Fällen hilft das Deaktivieren des Schnellstarts und ein bis zwei anschließende saubere Neustarts damit die Änderung übernommen wird.

    • Nacheinander auf „Einstellungen – System – Netzbetrieb und Energiesparen – Zusätzliche Eneergieeinstellungen – Auswählen, was beim Drücken von Netzschaltern geschehen soll“ klicken.
    • „Einige Einstellungen sind momentan nicht verfügbar.“ anklicken.
    • Den Haken bei „Schnellstart aktivieren (empfohlen)“ entfernen und auf „Änderungen speichern“ klicken.

Mittels Skript oder Befehl lässt sich der Schnellstart wie folgt deaktivieren:

REG ADD "HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Power" /V HiberbootEnabled /T REG_dWORD /D 0 /F

Am besten dann über die Eingabeaufforderung mit

shutdown -r -f -t 0

neu starten.

Quelle:

superuser – Disable Windows 10 fast boot via CMD/Powershell

Windows Ten Forums – How to Turn On or Off Fast Startup in Windows 10

Windows: WsusContent-Ordner wird immer größer

$
0
0

Bei einem Kunden wunderten wir uns das der WsusContent-Ordner immer umfangreicher wurde und bei den Downloads mittlerweile über 300 GB herunterzuladen wären. Bei gerade mal acht Arbeitsplätzen mit Windows 7, 10 und Office 2010 als zu aktualisierende Produkte eine recht stolze Zahl. Bei vergleichbaren Installationen ist der WSUS genügsamer.

Abhilfe schaffte zuerst ein Reset und die anschließende Bereinigung:

net stop wsusservice
cd "C:\Program Files\Update Services\Tools"
wsusutil.exe reset
net start wsusservice

Während der Vorgang lief erzeugt der SQL Server einige Last und man konnte bei den herunterzuladenden Dateien einige Sprünge beobachten. Sagen wir’s mal so: Mehrere zweistellige GB-Bereiche werden bei einem sehr langsamen DSL-Anschluss nicht gerade in wenigen Minuten übertragen. Offenbar war da einiges im Argen.

Nachdem die Befehle ausgeführt waren, kann man nach etwas Wartezeit (30-60 Minuten, einfach die CPU-Last des SQL beobachten, sobald diese sinkt, kann es weitergehen) den Server-Bereinigungsassistenten ausführen:

Der WsusContent-Ordner hatte zuletzt eine Größe von 329 GB. Nach dem Reset und dem Ausführen des Server-Bereinigungsassistenten schrumpfte dieser auf 62 GB. Die ausstehenden Downloads verringerten sich von über 300 GB auf gerade mal 5 GB.

Quelle:

xenappblog.com – How To Clean Up WSUS


VirtualBox: Größe einer VHD ändern

$
0
0

Mit dem Kommandozeilen-Tool VboxManage.exe lässt sich bequem die Größe einer virtuellen Festplatte ändern.

Möchte man z.B. eine dynamisch wachsende VHD vergrößern, so gibt man

VboxManage modifyhd <absolute path to file> --resize <size in MB>

ein. Beispiel:

VboxManage modifyhd "D:\VirtualBox VMs\Test\Test.vhd" --resize 320000

Dadurch ändert sich nur die maximal-erreichbare Größe der VHD. Partitionen oder Volumes innerhalb der virtuellen Festplatte muss man zusätzlich ändern. Unter Windows geht das bequem über die Datenträgerverwaltung oder mittels diskpart.

Quelle:

VirtualBox Forum – How to resize a Virtual Drive

Windows-Terminalserver: Fehler beim Senden der disconnect (7)-Nachricht an das Windows-Videosubsystem. Der relevante Statuscode lautete 0x80070102

$
0
0

Ein sehr lediges Problem begleitet uns bei einem Kunden seit Ende Januar 2019. Beim Versuch sich zu einem Terminalserver zu verbinden bleibt der Bildschirm schwarz. Black oder blank screen kann mehrere Gründe haben. Häufig liegt’s z.B. an der Bitmapzwischenspeicherung (Bitmap-Caching). So einfach ist es in diesem Fall leider nicht.

Die Umgebung basiert auf Windows Server 2016 Standard. Der WTS ist eine virtuelle Maschinen auf einem Hyper-V. Beides mit aktuellem Patchlevel. Das Ganze ist eine Arbeitsgruppe, d.h. stand-alone und ohne AD.

Der erste Gedanke bzw. mit diesem fiel es zunächst auf, war die Firmware von bestimmten Igel ThinClients. Wie sich im Verlauf allerdings zeigte, tauchte das Verbindungsproblem auch von Windows aus auf.

Richtig ungut ist, das sich der Terminalserver nicht mehr neustarten lässt, er bleibt beim Herunterfahren hängen. Da hilft nur den virtuellen Stecker zu ziehen.

Recherchiert und ausprobiert wurde schon einiges wie z.B.:

Firmware der ThinClients down-/upgraden, RDP-Verbindungsprotokoll auf TCP beschränken (UDP via GPO deaktiviert), RemoteFX sowohl an den ThinClients als auch auf dem WTS deaktiviert, aufgrund der Meldung im EventLog (siehe weiter unten) Video-Redirection auf den ThinClients deaktiviert, Virenschutz deaktiviert (Support-Anfrage beim Hersteller, ob es daran liegen könnte läuft, in der Vergangenheit gab es wohl mal Schwierigkeiten mit dem Hersteller WebRoot), Netzwerkauthentifizierung de-/aktiviert, usw.

Soviel zur Vorgeschichte.

Ereignisprotokollmeldungen

Auf eine wohl erstmal falsche Fährte führten Meldungen zu RemoteFX unter

Windows-Protokolle - Anwendungs- und Dienstprotokoll - Microsoft - RemoteDesktopServices - RdpCoreTS - Betriebsbereit

Dort finden sich Einträge wie:

Protokollname: Microsoft-Windows-RemoteDesktopServices-RdpCoreTS/Operational
Quelle:        Microsoft-Windows-RemoteDesktopServices-RdpCoreTS
Datum:         19.02.2019 07:28:57
Ereignis-ID:   227
Aufgabenkategorie:RemoteFX-Modul
Ebene:         Fehler
Schlüsselwörter:
Benutzer:      Netzwerkdienst
Computer:      wts02
Beschreibung:
'Failed CreateVirtualChannel call on this Connections Stack' in CUMRDPConnection::CreateVirtualChannel at 2349 err=[0x80070032]
Protokollname: Microsoft-Windows-RemoteDesktopServices-RdpCoreTS/Operational
Quelle:        Microsoft-Windows-RemoteDesktopServices-RdpCoreTS
Datum:         19.02.2019 07:28:57
Ereignis-ID:   227
Aufgabenkategorie:RemoteFX-Modul
Ebene:         Fehler
Schlüsselwörter:
Benutzer:      Netzwerkdienst
Computer:      wts02
Beschreibung:
'Connection doesn't support logon error redirector' in CUMRDPConnection::GetLogonErrorRedirector at 4073 err=[0x80004001]
Protokollname: Microsoft-Windows-RemoteDesktopServices-RdpCoreTS/Operational
Quelle:        Microsoft-Windows-RemoteDesktopServices-RdpCoreTS
Datum:         19.02.2019 07:28:56
Ereignis-ID:   101
Aufgabenkategorie:RemoteFX-Modul
Ebene:         Warnung
Schlüsselwörter:
Benutzer:      Netzwerkdienst
Computer:      wts02
Beschreibung:
Die Funktion zur Erkennung von Netzwerkmerkmalen wurde deaktiviert. Ursache: Reason Code: 1(Client not supported)..
Protokollname: Microsoft-Windows-RemoteDesktopServices-RdpCoreTS/Operational
Quelle:        Microsoft-Windows-RemoteDesktopServices-RdpCoreTS
Datum:         19.02.2019 07:28:56
Ereignis-ID:   101
Aufgabenkategorie:RemoteFX-Modul
Ebene:         Warnung
Schlüsselwörter:
Benutzer:      Netzwerkdienst
Computer:      wts02
Beschreibung:
Die Funktion zur Erkennung von Netzwerkmerkmalen wurde deaktiviert. Ursache: Reason Code: 2(Server Configuration)..
Protokollname: Microsoft-Windows-RemoteDesktopServices-RdpCoreTS/Operational
Quelle:        Microsoft-Windows-RemoteDesktopServices-RdpCoreTS
Datum:         19.02.2019 08:22:40
Ereignis-ID:   142
Aufgabenkategorie:RemoteFX-Modul
Ebene:         Warnung
Schlüsselwörter:
Benutzer:      Netzwerkdienst
Computer:      wts02
Beschreibung:
Fehler beim READ-Vorgang des TCP-Sockets, Fehler: "64".
Protokollname: Microsoft-Windows-RemoteDesktopServices-RdpCoreTS/Operational
Quelle:        Microsoft-Windows-RemoteDesktopServices-RdpCoreTS
Datum:         19.02.2019 08:22:40
Ereignis-ID:   226
Aufgabenkategorie:RemoteFX-Modul
Ebene:         Warnung
Schlüsselwörter:
Benutzer:      Netzwerkdienst
Computer:      wts02
Beschreibung:
RDP_TCP: Fehler beim Übergang von "StateUnknown" in Reaktion auf "Event_Disconnect". (Fehlercode: 0x80070040)

Wie bereits erwähnt wurde RemoteFX deaktiviert, ohne das sich am „Hauptproblem“ etwas geändert hat. Übrigens passen zeitlich die RemoteFX-Einträge nicht zu den fehlerhaften Anmelde-/Verbindungsversuchen. Daher gibt es vmtl. keinen Zusammenhang.

Interessant zu den RemoteFX-Meldungen ist dieser Beitrag:

Microsoft TechNet Forums – RDS 2016 – RemoteFX killing connections

Die dort beschriebene Maßnahmen wurden ergriffen. Die Protokolleinträge sind seitdem weniger geworden.

Im weitesten Sinne interessanter sind die folgenden Protokolleinträge, die ausgehend vom zeitlichen Verlauf mit den gescheiterten Verbindungsversuchen zusammenhängen. Pro Fehlerfall werden anscheinend immer diese vier Meldungen erfasst.

Protokollname: Microsoft-Windows-TerminalServices-LocalSessionManager/Operational
Quelle:        Microsoft-Windows-TerminalServices-LocalSessionManager
Datum:         19.02.2019 07:31:09
Ereignis-ID:   20
Aufgabenkategorie:Keine
Ebene:         Fehler
Schlüsselwörter:
Benutzer:      SYSTEM
Computer:      wts02
Beschreibung:
Fehler beim Senden der disconnect (6)-Nachricht an das Windows-Videosubsystem. Der relevante Statuscode lautete 0x80070102.
Protokollname: Microsoft-Windows-TerminalServices-LocalSessionManager/Operational
Quelle:        Microsoft-Windows-TerminalServices-LocalSessionManager
Datum:         19.02.2019 07:31:09
Ereignis-ID:   36
Aufgabenkategorie:Keine
Ebene:         Fehler
Schlüsselwörter:
Benutzer:      SYSTEM
Computer:      wts02
Beschreibung:
Fehler beim Übergang von "CsrInitialized" in Reaktion auf "EvDisconnected". (Fehlercode: 0x80070102)
Protokollname: Microsoft-Windows-TerminalServices-LocalSessionManager/Operational
Quelle:        Microsoft-Windows-TerminalServices-LocalSessionManager
Datum:         19.02.2019 07:31:30
Ereignis-ID:   20
Aufgabenkategorie:Keine
Ebene:         Fehler
Schlüsselwörter:
Benutzer:      SYSTEM
Computer:      wts02
Beschreibung:
Fehler beim Senden der disconnect (7)-Nachricht an das Windows-Videosubsystem. Der relevante Statuscode lautete 0x80070102.
Protokollname: Microsoft-Windows-TerminalServices-LocalSessionManager/Operational
Quelle:        Microsoft-Windows-TerminalServices-LocalSessionManager
Datum:         19.02.2019 07:31:30
Ereignis-ID:   36
Aufgabenkategorie:Keine
Ebene:         Fehler
Schlüsselwörter:
Benutzer:      SYSTEM
Computer:      wts02
Beschreibung:
Fehler beim Übergang von "CsrInitialized" in Reaktion auf "EvDisconnected". (Fehlercode: 0x80070102)

Die Einträge mit dem Verweis auf das Video-Subsystem veranlassten mich dazu, die Video-Umleitung zu deaktivieren. Bei einem anschließenden 45-minütigen Test klappte zunächst alles und ich war guter Dinge. Am Morgen danach war wieder einer Mail vom Kunden im Postfach, das es immer noch Probleme gibt.

Weiteres

Im Moment bin ich ratlos, das Ganze habe ich zudem im TechNet Forum gepostet:

Terminalserver – Fehler beim Senden der disconnect (7)-Nachricht an das Windows-Videosubsystem. Der relevante Statuscode lautete 0x80070102.

Seit knapp 20 Jahren mache ich nun schon Terminalserver, aber solch ein Pech hatte ich bislang noch nie. Für weitere Tipps, Tricks und Hinweise wäre ich sehr dankbar.

Bisherige zu bzw. aus diesem Thema heraus entstandene Blog-Beiträge sind:

Igel Thin Client: Keine Netzwerkverbindung mehr nach Firmware-Upgrade

Windows: Terminalserver – RDP-Transportprotokolle konfigurieren

Windows: Terminalserver – Abfrage nach einem Absturz für den Grund des ungeplanten Neustarts unterbinden

Windows: Hyper-V – Virtuellen Computer normal neu starten, wenn das nicht gelingt dann Ausschalten und Starten

Igel Thin Client: Schwarzer Bildschirm beim oder nach dem Verbindungsaufbau

Securepoint UTM: DHCP-Reservierung einrichten

$
0
0

Seit ein paar Versionen beherrscht (endlich) auch die Securepoint UTM das Reservieren von IP-Adressen im DHCP-Server.

Im Web-Interface unter „Netzwerk – Netzwerkkonfiguration“ auf der Registerkarte „Statisches DHCP“ werden die Reservierungen konfiguriert.

Dazu aber noch eine Geschichte aus der Praxis mit einer wichtigen Erkenntnis:

Wir freuten uns sehr und richteten die DHCP-Reservierung auch gleich bei einem Kunden-Projekt ein. Die Aufgabenstellung lautete dabei ein zum LAN hin zusätzliches Netz in einer Fertigungshalle zu etablieren. Via Firewall sollten diese Netze getrennt sein und die Maschinen dürfen nicht ins Internet. Soweit so gut. Nun gibt es ein Notebook in der Halle das bei Bedarf ins Internet kann und zudem auf einen Server zwecks Laden von Maschinendaten zugreifen muss, hinzu kommt das dieses mitunter auch mal im Büro genutzt wird. Daher kam eine statische IP-Konfiguration nicht in Frage, es bot sich die DHCP-Reservierung gerade zu an. Mittels entsprechender Firewall-Regeln war zudem die „Verkehrsregelung“ möglich.

Das klappte zunächst ganz gut, doch eines schönen Montag-Morgens klingelte allerdings das Telefon mit der Meldung, dass das Notebook nicht mehr ans Netz gehen würde. Seltsamerweise funktionierte alles im Büro, nur nicht (mehr) in der Halle. Wir hatten zunächst Kabel, Switch-(Port) als auch den Netzwerkkartentreiber in Verdacht, das war’s alles nicht.

Ich muss gestehen, wir haben erstmal eine Weile mit dem Kunden am Telefon zusammen gesucht, bis wir raus hatten das die IP-Adresse doppelt vergeben war, man hatte schlichtweg überhaupt nicht mit sowas gerechnet. Erst als das Netzwerkkabel aus dem Notebook raus war und die betreffende IP-Adresse dennoch angepingt werden konnte machte es Klick auf unserer Seite des Telefons als auch Aha auf der anderen Seite. So stellte sich heraus, das eine der Maschinen sich die IP-Adresse „geschnappt“ hatte. Das warum war erstmal nicht klar. Als schneller workaround wurde für das Notebook eine Reservierung am Ende des Pools eingerichtet. So schnell sollte man da nicht hinkommen.

Neulich war dann der Securepoint Außendienst bei uns und wir sprachen unter anderem über diese Geschichte. Einen Tag später rief dann der Support an und die Angelegenheit konnte geklärt werden.

Weder im Changelog, dem Wiki, noch in der Online-Hilfe der UTM ist dokumentiert, das es sich gar nicht um eine Reserveriung sondern (Supportaussage) um eine Priorisierung handelt. D.h. laut Support: Ist die „reservierte“ Adresse frei und irgendein Gerät benötigt eine freie IP-Adresse, wird diese vermeintlich reservierte Adresse (dennoch) an andere Geräte vergeben!

Das erklärt, warum es beim Kunden erstmal funktionierte und dann irgendwann schepperte. Die Empfehlung sowohl vom Support als nun auch von uns lautet daher, die reservierten IP-Adressen ausserhalb des Pools anzulegen.

Gut zu wissen und wieder etwas gelernt. Persönlich kenne ich das in ähnlicher Form z.B. von pfSense. Dort kann man DHCP-Reservierungen nur außerhalb des Pools anlegen, innerhalb ist überhaupt nicht möglich. Wäre gut, wenn dies in einer zukünftigen Version der UTM-Firmware ebenfalls verriegelt wäre.

AVM FRITZ!Box automatisch neu starten (lassen)

$
0
0

Eine FRITZ!Box kann eine feine Sache sein, aber so manchmal gibt’s auch kleine Makel, wie z.B. diesen: Bei einem Kunden streikt schon fast regelmässig das WLAN.

Oft geht die Performance zurück und manchmal bleiben Geräte als Verbunden „hängen“, obwohl diese nicht mal mehr ansatzweise in der Nähe sind (Live beobachtet z.B. mit meinem Notebook als auch mit diversen Smartphones und Tablets). Helfen tut in aller Regel ein Neustart.

Nun ist es lästig alle paar Tage sich mit dem Webinterface verbinden zu dürfen, um einen Neustart auszulösen. Unterm Tag ist das zwecks „arbeiten können“ sowieso eher ungut. Abhilfe schafft das Auslösen des Neustarts z.B. von einem sowieso immer laufenden System aus wieetwa Server, NAS oder ähnliches.

Im Netz kursieren hierzu viele Beispiele. Wichtig ist, dass das verwendete Skript mit aktuellen Firmware-Versionen funktioniert. Ältere Skripte die auf die WEBCM-Schnittstelle setzen können nicht mehr angewendet werden. Eine weitere Möglichkeit wäre telnet zu verwenden, sofern man es vorher aktiviert. Ohne größere Umwege geht es über das Router-Verwaltungsprotokoll TR-064.

Ein sehr schönes und leicht zu verstehendes Skript für Linux liefert Nico Hartung:

loggn.de – FRITZ!Box oder Repeater automatisch neustarten lassen – Linux Bash-Skript

GitHub – cron_fritzbox-reboot – FRITZ!Box Neustart Skript – jede Nacht, einmal die Woche, wie ihr wollt

Bei meinen Tests klappte das Auslösen eines Neustarts aber nur mit einem Benutzer, der FRITZ!Box-Einstellungen ändern darf. Nur mit dem Weboberflächen-Kennwort kommt folgende Fehlermeldung:

<?xml version="1.0"?>
<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/" s:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<s:Body>
<s:Fault>
<faultcode>s:Client</faultcode>
<faultstring>UPnPError</faultstring>
<detail>
<UPnPError xmlns="urn:dslforum-org:control-1-0">
<errorCode>606</errorCode>
<errorDescription>Action Not Authorized</errorDescription>
</UPnPError>
</detail>
</s:Fault>
</s:Body>
</s:Envelope>

Dieses Verhalten ist bekannt:

Authentifizierung nicht möglich

Dokumentation der FRITZUSER Variable verbessern

D.h. einen neuen FRITZ!Box-Benutzer anlegen, bei diesem den Haken setzen bei

  • FRITZ!Box Einstellungen
    Benutzer mit dieser Berechtigung können alle Einstellungen der FRITZ!Box sehen und bearbeiten.

Diese Zugangsdaten dann in das Skript bei den entsprechenden Variablen eintragen.

FreeBSD / pfSense

Das Skript lässt sich nahezu unverändert unter FreeBSD bzw. pfSense verwenden. Man muss lediglich die erste Zeile von

#!/bin/bash

zu

#!/bin/sh

ändern.

Apropos pfSense: Beim besagten Kunden läuft eine pfSense, die dort lediglich als OpenVPN-Server dient. Das Skript kann man einfach via (Win)SCP im Pfad

/usr/local/etc/

ablegen und mittels ssh noch ausführbar machen:

chmod 0755 /usr/local/etc/fritzbox-reboot.sh

ssh muss für beides (natürlich) vorher in pfSense aktiviert sein. Mit der Cron-Erweiterung kann der Zeitpunkt für den automatischen Neustart via Web-Interface bequem geplant werden. Ein Beispiel für täglich 04:30 Uhr:

Was ist mit Windows?

Gerne hätte ich eine Lösung für Windows, da man nicht überall etwas unixoides vorfindet. Bei der Recherche bin ich über ein Powershell-Skript gestolpert:

Administrator.de – Powershell: FritzBox über TR-064 im Netzwerk konfigurieren und auslesen

Leider lies sich dieses nicht erfolgreich ausführen. Sozusagen als Plan B habe ich dann versucht den curl-Befehl vom zuvor genannten Skript unter Windows zum Laufen zu bekommen.

Also erstmal curl für Windows heruntergeladen, entpackt und im bin-Ordner das Skript als Windows-Batch hinterlegt und natürlich OS-bedingt geändert. Dieses sieht aktuell so aus:

@echo off

set IP=192.168.178.1
set FRITZUSER=<Benutzername>
set FRITZPW=<Kennwort>

set location=/upnp/control/deviceconfig
set uri=urn:dslforum-org:service:DeviceConfig:1
set action=Reboot

curl -k -m 5 --anyauth -u %FRITZUSER%:%FRITZPW% http://%IP%:49000%location% -H Content-Type: text/xml; charset="utf-8" -H SoapAction:%uri%#%action% -d ^<?xml version='1.0' encoding='utf-8'?^>^<s:Envelope s:encodingStyle='http://schemas.xmlsoap.org/soap/encoding/' xmlns:s='http://schemas.xmlsoap.org/soap/envelope/'^>^<s:Body^>^<u:Reboot xmlns:u='urn:dslforum-org:service:DeviceConfig:1'^>^</u:Reboot^>^</s:Body^>^</s:Envelope^> -s > output.log 2>&1

Leider meldet die FritzBox immer dieses zurück:

<HTML>
<HEAD>
<TITLE>500 Internal Server Error (ERR_INVALID_REQ)</TITLE>
</HEAD>
<BODY>
<H1>500 Internal Server Error</H1>
<BR>ERR_INVALID_REQ<HR>
<B>Webserver</B> Wed, 20 Feb 2019 13:04:50 GMT
</BODY>
</HTML>

Mit anderen Worten: Es klappt nicht. Auch dann nicht, wenn man alles (ohne Variablen) in eine Zeile packt. Seltsam finde ich, das der Aufruf, wenn man sich diesen mittels echo sowohl unter Linux als auch Windows anzeigen lässt identisch aussieht:

Linux:

curl -k -m 5 --anyauth -u <Benutzername>:<Kennwort> http://192.168.178.1:49000/upnp/control/deviceconfig -H Content-Type: text/xml; charset="utf-8" -H SoapAction:urn:dslforum-org:service:DeviceConfig:1#Reboot -d <?xml version='1.0' encoding='utf-8'?><s:Envelope s:encodingStyle='http://schemas.xmlsoap.org/soap/encoding/' xmlns:s='http://schemas.xmlsoap.org/soap/envelope/'><s:Body><u:Reboot xmlns:u='urn:dslforum-org:service:DeviceConfig:1'></u:Reboot></s:Body></s:Envelope> -s

Windows:

curl -k -m 5 --anyauth -u <Benutzername>:<Kennwort> http://192.168.178.1:49000/upnp/control/deviceconfig -H Content-Type: text/xml; charset="utf-8" -H SoapAction:urn:dslforum-org:service:DeviceConfig:1#Reboot -d <?xml version='1.0' encoding='utf-8'?><s:Envelope s:encodingStyle='http://schemas.xmlsoap.org/soap/encoding/' xmlns:s='http://schemas.xmlsoap.org/soap/envelope/'><s:Body><u:Reboot xmlns:u='urn:dslforum-org:service:DeviceConfig:1'></u:Reboot></s:Body></s:Envelope> -s

Evtl. hat ja noch jemand einen Tipp 😉

Windows: CrystalDiskInfo ohne Benutzerkontenabfrage bei Anmeldung ausführen

$
0
0

Manchmal ist die Sache einfacher, als zunächst angenommen. Möchte man CrystalDiskInfo bei der Anmeldung ausführen, genügt es unter „Optionen – Mit Windows starten“ zu aktivieren.

Tipp: Möchten man CrystalDiskInfo minimiert starten, muss der Haken bei „Optionen – Im SysTray anzeigen“ gesetzt sein.

Daraufhin wird automatisch im Hintergrund eine Aufgabe angelegt, die bei der Anmeldung des Benutzers ausgeführt wird. Da in dieser Aufgabe der Haken bei „Mit höchsten Priviligien ausführen“ gesetzt ist, erscheint zudem keine Benutzerkontenabfrage.

Das Ganze gelingt allerdings nur, wenn der angemeldete Benutzer administrative Berechtigungen hat.

Was ist, wenn der Benutzer keine Administrator-Rechte hat?

Hat der Benutzer keine administrativen Rechte, kann die Aufgabe so wie sie von CrystalDiskInfo erstellt wird, nicht ausgeführt werden:

Lösen lässt sich das, wenn man über Drittanbieter-Tools dafür sorgt das CrystslDiskInfo dennoch mit erhöhten Rechten bzw. als Administrator ausgeführt wird. Als quick’n’dirty-Lösung beispielsweise mit MiniRunAs. Man erstellt ein simples Skript wie dieses:

@echo off

cd "C:\Tools\CrystalDiskInfo"

miniRunAs.exe Administrator <Kennwort> DiskInfo64.exe /Startup

Und lässt es dann als Aufgabe bei Anmeldung ausführen.

Das Skript sollte natürlich vor neugierigen Augen geschützt werden, damit nicht jeder an das Administrator-Kennwort gelangt. Dies gelingt in dem man es in einem Ordner ablegt und auf diesem Ordner die Rechte für „Otto-Normal-Benutzer“ dahingehend einschränkt, das zwar die Aufgabenplanung laufen kann, aber nicht der Dateiinhalt eingesehen werden kann. Anbei stichpunktartig die notwendigen Schritte:

  • Auf Ordner-Ebene die Vererbung deaktivieren.
  • „Benutzer“ und „Authentifizierte Benutzer“ die Rechte auf den Ordner und seinen Inhalt entziehen (die entsprechenden Gruppen entfernen).
  • Nur dem Benutzer bzw. besser der gewünschten Gruppe auf Ordnerebene das (erweiterte) Recht „Ordner durchsuchen / Datei ausführen“ erteilen.

Quelle: Dr. Windows – Datei ausführbar, aber nicht lesbar machen

Troubleshooting

Klappt es auf Anhieb nicht, das CrystalDiskInfo via Aufgabe gestartet wird, kann es helfen, eine Verzögerung einzustellen. Dazu die Aufgabe editierien, auf die Registerkarte „Trigger“ wechseln, doppelt auf „Bei Anmeldung eines Benutzers“ klicken und bei „Verzögern für“ z.B. ein bis zwei Minuten eintragen.

Danksagung

Danke an Bernd für die Inspiration zu diesem Beitrag.

Windows 10 – 1809: Probleme beim Ausführen mittels runas

$
0
0

So manches Programm lässt sich bei Windows 10 – 1809 mittels „Als Administrator ausführen“, runas oder Drittanbietertools wie z.B. MiniRunAs nicht mehr ausführen. Bis Windows 10  – 1803 funktionierte das noch ohne Schwierigkeiten.

Die Fehlerbilder reichen von das überhaupt nichts passiert bis hin z.B. bei runas in der Eingabeaufforderung diese Meldungen erscheinen:

  • 5: Zugriff verweigert
  • 740: Der angeforderte Vorgang benötigt erhöhte Rechte

Offenbar hat Microsoft eine (Vor-)Einstellung verändert. Unter Windows 10 Pro kann man via Gruppenrichtlinie Abhilfe schaffen:

  • Den Gruppenrichtlinien-Editor öffnen.
  • Zu „Computerkonfiguration – Windows-Einstellungen – Sicherheitseinstellungen – Lokale Richtlinien – Sicherheitsoptionen“ wechseln.
  • Dort die Richtlinie „Benutzerkontensteuerung: Administratorgenehmigungsmodus für das integrierte Administratorkonto“ auf „Deaktiviert“ setzen.

In einer Domäne führt das allerdings zu anderem Ungemach, siehe dazu:

Windows 10: Domänen-Administrator hat keine ausreichenden Berechtigungen

Außerhalb der GPO kann man die Einstellung manuell in der Registry, via *.reg-Datei

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System]
"FilterAdministratorToken"=dword:00000000

oder per Befehl ändern:

reg add HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System /v FilterAdministratorToken /t REG_DWORD /d 0 /f

P.S.: Windows 10 Home wurde nicht getestet.

Update 28.02.2019

Der oben genannte Weg funktioniert bei stand-alone Computern mit dem Buildin-Administrator. Hat man allerdings zusätzliche angelegte Administratoren, kommt es dennoch zu Fehlern. Theoretisch könnte die Richtlinie

Benutzerkontensteuerung: Alle Administratoren im Administratorgenehmigungsmodus ausführen

auf „Deaktiviert“ zu setzen helfen, allerdings hat dies der Beobachtung nach sehr viele negative Auswirkungen. So klappte zwar die Ausführung von runas und MiniRunas, allerdings funktionierte dann „Als Administrator ausführen“ und z.B. entsprechend markierte Punkte in der Systemsteuerung (die erhöhte Rechte erfordern) nicht mehr. Vermutlich betrifft das auch weitere Punkte im System.

Von daher ist dieser Weg über die letztgenannte Richtlinie aktuell nicht zu empfehlen.

Windows: runas – Automatische Kennwort-Eingabe mit UniPass

$
0
0

Bekanntlich lässt sich bei Microsoft’s runas-Befehl kein Kennwort mitgeben. Versuche dies mittels echo zu tun scheitern bei aktuellen Versionen.

Sofern runas grafisch sichtbar ausgeführt wird, kann mittels Unipass die Eingabe des Kennworts automatisiert werden. Damit das gelingt, bemüht man ein kleines Skript, da Unipass einen Fenstertitel benötigt. Anbei ein Beispiel:

@echo off
start UniPass_x64.exe RunAs-Window Geheim

title RunAs-Window

runas /noprofile /user:"%computername%\administrator" "C:\Program Files (x86)\FreeCommander XE\FreeCommander.exe"

Microsoft Office: Product Key ungültig (oder auch nicht)

$
0
0

Die Microsoft Produktaktiviererei kann eine lästige Angelegenheit sein, vorallem immer dann, wenn es nicht klappt.

So brauchte ich vor gut drei Wochen fast einen kompletten Arbeitstag um ein Office 2016 Home and Business zu aktivieren. Nach dem x-ten Anruf bei Microsoft und einem der vielen Support-Gespräche stellte sich damals heraus, das gerade Wartungsarbeiten durchgeführt werden und es wohl deswegen über Stunden nicht möglich war, das Produkt freizuschalten.

Ein anderes Ärgernis besteht darin, das es relevant ist, über welchen Vertriebskanal (ESD, Retail, …) Office bezogen wurde, welches Setup man verwendet und welches Setup mit welchem Produktschlüssel verwendet werden kann. Dies hängt immer mit dem Vertriebskanal zusammen. Hinzu kommt, das Product Key nicht gleich Product Key ist. Ein aktuelles Fallbeispiel:

Die Aktivierung eines Office 2019 Home and Business klappte zunächst nicht. Nach der Installation und beim ersten Start von Word wurde der Produktschlüssel abgefragt. Dieser wurde eingetragen, daraufhin erscheint folgender Dialog:

Ohne Konto geht es an dieser Stelle nicht weiter. Versucht man den Produktschlüssel via Eingabeaufforderung einzutragen erscheint diese Meldung:

C:\Windows\system32>cscript "C:\Program Files (x86)\Microsoft Office\Office16\OSPP.VBS" /inpkey:xxxxx-xxxxx-xxxxx-xxxxx-xxxxx
Microsoft (R) Windows Script Host, Version 5.812
Copyright (C) Microsoft Corporation. Alle Rechte vorbehalten.

---Processing--------------------------
---------------------------------------
ERROR CODE: 0xC004F050
ERROR DESCRIPTION: The Software Licensing Service reported that the product key is invalid.
---------------------------------------
---Exiting-----------------------------

Liest man, das der Produktschlüssel ungültig ist, kommt man evtl. erst Mal auf den Gedanken, das etwas nicht stimmt. Dem ist allerdings nicht so. In diesem Fall handelt es sich um ein Retail-Office, dieses benötigt zwingend seit Version 2016 zur Aktivierung ein Microsoft (Live) Konto! Hat man keines, kann man ab dem dargestellten Dialog eines anlegen. Es muss nicht zwingend eine neue E-Mail-Adresse verwendet werden.

Ist das Konto angelegt und bestätigt, kann man die E-Mail-Adresse samt Kennwort eingeben und im Idealfall ist Office sofort freigeschaltet. Manchmal ist ein Neustart des Office notwendig, damit unter „Datei – Konto“ endlich „Produkt aktiviert“ angezeigt wird.

Der vom Händler erhaltene Product Key ist also nicht die eigentliche Lizenz, sondern dient lediglich dem Hinzufügen der Lizenz zum MS Konto. Daher die Aussage „Product Key ist nicht gleich Product Key“.

Für Microsoft bietet diese herangehensweise Vorteile, wird so doch recht effektiv unterbunden, das man ein Office-Paket, das man nicht mehr benötigt weiter veräußert wird, denn ein Herauslösen aus einem MS Konto ist laut Support nicht vorgesehen.

Tipp: Möchte man nicht, das nun (dauerhaft) die E-Mail-Adresse des „Aktivierungskontos“ angezeigt wird, kann man, sofern keine MS Dienste verwendet werden, unter „Datei – Konto“ dieses Konto abmelden.

Quelle:

Gebrauchtsoftware.de – Office 2016 Retail / OEM: Microsoft verbietet Installation ohne Live-Account 

Windows: Probleme beim RDP Wrapper lösen

$
0
0

Da es immer wieder Kommentare oder gar E-Mails zum Thema RDP Wrapper in Verbindung „geht nicht“ gibt, versuche ich mit diesem Beitrag eine Art zentrale Anlaufstelle (innerhalb dieses Blogs) dafür zu schaffen. Das bedeutet, wenn möglich soll der Beitrag weiter aktualisiert werden.

Zu Beginn ein wenig Historie und Hintergrund

Während RDP Wrapper beispielsweise unter Windows 7 lange Zeit ohne Updates auskam ist es bei Windows 10, aktuell allem voran bei 1809 leider ganz anders. Die Ursache ist dabei relativ einfach: Ändert Microsoft die „termsrv.dll“, das ist die Bibliothek die die Remotedesktopdienste realisiert, muss auch die „rdpwrap.ini“ des RDP Wrappers angepasst werden.

Zugegeben, leider kommen vom Macher des RDP Wrappers schon seit geraumer Zeit keine Updates mehr, daher nutzt es dann auch wenig wenn man die „update.bat“ ausführt, helfen tut dafür in der Regel die Community. Auf GitHub findet man unter Issues der Projektseite meist relativ schnell die notwendigen Änderungen, die man selbst per Hand einpflegen darf.

Als Alternative zum Aktualisieren der „rdpwrap.ini“ kann man ein Downgrade/Rollback der „termsrv.dll“ durchführen, damit der RDP Wrapper wieder läuft. Erwähnt wurde dies z.B. bereits hier:

Windows: Wenn RDP Wrapper nicht mehr funktioniert, ein Downgrade der termsrv.dll durchführen

Als auch in den Kommentaren zu

Windows Vista, 7, 8.x und 10 mit dem RDP Wrapper zum Terminalserver machen

Grundsätzlich muss man allerdings festhalten, das Microsoft jederzeit durch entsprechende Änderungen den RDP Wrapper (oder andere Lösungen dieser Art) unbrauchbar machen kann oder gar gänzlich diese „Option“ verbaut. Ferner stören sich zudem so manche Virenscanner am RDP Wrapper, das ist sogar verständlich, können solche Tools positiv wie negativ verwendet werden.

Zu Empfehlen vor dem Einspielen von Windows Updates, nicht nur wegen dem RDP Wrapper, ist ein Backup anzulegen oder z.B. in einer virtuellen Maschine zunächst zu prüfen, ob alles nach der Installation der Updates noch so läuft, wie es soll.

Das häufigste Problem lösen: Nach Windows Update funktioniert der RDP Wrapper nicht mehr, die „RDPconf.exe“ meldet „unsupported“.

I.d.R. habe ich fast ausschließlich mit Windows 7, 8 und 10 in der Pro-Edition zu tun, von daher kann ich zu den Home-Editionen nicht allzuviel beitragen. Ferner sind die allermeisten Systeme mit 64-bit-Windows bestückt, 32-bit wäre damit ebenfalls quasi raus. Ferner verwende ich keine Test- oder Vorabversionen von zukünftigen Windows 10 Builds. Was den RDP Wrapper betrifft greife ich immer zur ZIP-Datei, die MSI habe ich noch nie verwendet (oder es ist solange her, das ich mich nicht mehr daran erinnern kann).

Meldet die „RDPconf.exe“ bei „Listener state“ ein „[not supported]“ liegt das an einer Version der „termsrv.dll“ die bislang nicht unterstützt wird und folglich ein Update der „rdpwrap.ini“ notwendig ist.

„rdpwrap.ini“ aktualisieren

Die „rdpwrap.ini“ findet sich unter „C:\Program Files\RDP Wrapper“. Diese kann mit einem einfachen Text-Editor wie dem Windows-Bordmittel Notepad oder externen Tools wie z.B. Notepad++ editiert werden. Es werden erhöhte Rechte benötigt.

In der Regel müssen nur weitere Zeilen für die neu zu unterstützende „termsrv.dll“-Version am Ende der Datei hinzugefügt werden.

Wichtig: Ganz am Ende der „rdpwrap.ini“ muss eine Leerzeile sein! Andernfalls funktioniert es nicht (mehr).

Damit die Änderung direkt an der Datei vorgenommen werden kann, muss der Dienst „Remotedesktopdienste“ beendet sein. Gleiches gilt, wenn man die Datei ersetzen möchte.

Wichtig: Führt man diese Änderung bereits über eine RDP-Verbindung durch und es geht irgendetwas schief, sperrt man sich aus! Ein Plan B um z.B. mittels VNC, TeamViewer, PsExec oder direkt an der Konsole Zugriff zu haben ist also wärmstens zu empfehlen!

Anbei nun ein Beispiel von der Installation bis zum Updaten des RDP Wrappers:

System: Windows 10 Pro – 1809 – Build 17763.348
Die Version der „termsrv.dll“ lautet: 10.0.17763.292

Ist der RDP Wrapper noch nicht installiert, sieht die Ausgabe von „RDPconfig.exe“ so aus:

Nach dem Ausführen des „install.bat“ sieht es so aus (daran ändert auch das Ausführen der „update.bat“ nichts):

Das wäre soweit der klassische Fall, das eine „termsrv.dll“-Version nicht unterstützt wird. Für die angezeigte Version findet sich die Lösung unter

Add support for build 10.0.17763.292 #645

in der Antwort von RoosterIllusion und von ditchmagnet. Letzerer bietet sogar eine fertige „rdpwrap.ini“ zum Download an. Das Archiv entpacken, den Dienst „Remotedesktopdienste“ beenden, die Datei unter „C:\Program Files\RDP Wrapper“ ersetzen und den Dienst wieder starten.

Das Ergebnis von „RDPconf.exe“ nach diesem Eingriff sieht so aus:

Damit sind die grundsätzlichen Voraussetzungen für den (Weiter-)Betrieb des „Quasi-Terminalserver“ geschaffen.

Vergleich der original und der aktualisierten „rdpwrap.ini“

Mit Tools wie WinMerge lässt sich leicht ermitteln, was es für Differenzen zwischen zwei Dateien gibt. Nachfolgend als Screenshot der Vergleich zwischen Original (links) und Fälschung ähm Update (rechts):

Letztlich wurden für diese Version nur die folgenden Zeilen eingefügt:

[10.0.17763.292]
; Patch CEnforcementCore::GetInstanceOfTSLicense
LocalOnlyPatch.x86=1
LocalOnlyOffset.x86=AFAD4
LocalOnlyCode.x86=jmpshort
LocalOnlyPatch.x64=1
LocalOnlyOffset.x64=77A11
LocalOnlyCode.x64=jmpshort
; Patch CSessionArbitrationHelper::IsSingleSessionPerUserEnabled
SingleUserPatch.x86=1
SingleUserOffset.x86=4D665
SingleUserCode.x86=nop
SingleUserPatch.x64=1
SingleUserOffset.x64=1322C
SingleUserCode.x64=Zero
; Patch CDefPolicy::Query
DefPolicyPatch.x86=1
DefPolicyOffset.x86=4BE69
DefPolicyCode.x86=CDefPolicy_Query_eax_ecx
DefPolicyPatch.x64=1
DefPolicyOffset.x64=17F45
DefPolicyCode.x64=CDefPolicy_Query_eax_rcx
; Hook CSLQuery::Initialize
SLInitHook.x86=1
SLInitOffset.x86=5B18A
SLInitFunc.x86=New_CSLQuery_Initialize
SLInitHook.x64=1
SLInitOffset.x64=1ABFC
SLInitFunc.x64=New_CSLQuery_Initialize
[10.0.17763.292-SLInit]
bInitialized.x86 =CD798
bServerSku.x86 =CD79C
lMaxUserSessions.x86 =CD7A0
bAppServerAllowed.x86 =CD7A8
bRemoteConnAllowed.x86=CD7AC
bMultimonAllowed.x86 =CD7B0
ulMaxDebugSessions.x86=CD7B4
bFUSEnabled.x86 =CD7B8

bInitialized.x64 =ECAB0
bServerSku.x64 =ECAB4
lMaxUserSessions.x64 =ECAB8
bAppServerAllowed.x64 =ECAC0
bRemoteConnAllowed.x64=ECAC4
bMultimonAllowed.x64 =ECAC8
ulMaxDebugSessions.x64=ECACC
bFUSEnabled.x64 =ECAD0

Zugriffsrecht erteilen

Damit Nicht-Administratoren via Remotedesktop zugreifen dürfen, müssen diese Mitglied der Gruppe „Remotedesktopbenutzer“ sein. Es gibt mehrere Wege die Benutzer dieser Gruppe zuzuweisen:

Der Klassiker wäre:

Computerverwaltung - System - Lokale Benutzer und Gruppen - Gruppen

In der Eingabeaufforderung mit

net localgroup Remotedesktopbenutzer <Benutzername> /add

Weitere Probleme:

Firewall

RDP Wrapper richtet bei der Installation eine Regel in der Windows-Firewall ein, die den Zugriff zulässt. Verwendet man eine Firewall von einem Drittanbieter, so müssen dort ggf. die Ports 3389/tcp und 3389/udp freigegeben werden.

Nach der Deinstallation von RDP Wrapper funktioniert RDP überhaupt nicht mehr

Bei der Deinstallation wird RDP deaktiviert, man kann es ganz einfach wieder aktivieren.

Windows 10 Kuriositäten

Ob RDP aktiv ist oder nicht, sollte man einfach via Einstellungen oder Systemsteuerung klären können. Bei meinem Testsystem fiel mir folgendes auf:

Hinweis am Rande: RDP Wrapper ist installiert und funktioniert. Warum unter „Einstellungen – System – Remotedesktop“ allerdings Remotedesktop als „Aus“ angezeigt wird und unter „Systemsteuerung – System – Remoteeinstellungen“ als aktiviert bleibt offen.

Wenn man Hilfe benötigt

Grundsätzlich muss man folgende Angaben parat haben:

  • Windows-Version und -Edition, Beispiel: Windows 10 Pro – 1809, idealerweise mit Build-Nummer
  • Version der „termsrv.dll“ (kann via „RDPconf.exe“ ermittelt werden)
  • Status des RDP Wrapper (gemeint ist das was die „RDPconf.exe“ anzeigt)
  • Genaue Fehlerbeschreibung und zwar so, das man das Vorgehen reproduzieren kann! Einfach zu schreiben „geht ned“ hilft nicht.

Die erste Anlaufstelle bei Schwierigkeiten ist die „RDPconf.exe“, steht da schon ein „unsupported“, „not installed“, „stopped“, „not listening“ o.ä. ist das schonmal ungut. Als nächstes lohnt ein Blick auf die Issues-Seite des RDP Wrapper.

Windows: Kein Drucken oder Scannen mehr mit Canon-Multifunktionsgerät

$
0
0

Neulich meldete sich ein Kunde, das er plötzlich weder Drucken noch Scannen könnte. Geändert hatte sich nichts, auch keine Updates etc. Es ging vom einen auf den anderen Tag nicht mehr.

Das Gerät ist via Netzwerkkabel angeschlossen und über’s Netzwerk auch einwandfrei erreichbar, Ping als auch der Zugriff auf das Web-Interface sind tadellos. Virenscanner (G Data) schlossen wir als erstes nach der grundsätzlichen Konnektivitätsprüfung als Ursache aus.

„Interessant“ wurde es über das Canon IJ Network Device Setup Utility, das beständig behauptete, es gäbe keine Netzwerkverbindung:

Drucken konnte reanimiert werden, in dem man den Anschluss von WSD-irgendwas auf TCP/IP umstellte. Beim Scannen gab es leider keine funktionierende Alternative.

Der Canon-Support benötigte jenseits der ersten Kontaktaufnahme und dem üblichen ersten Blabla (Installieren sie die neuesten Software, prüfen sie die Verbindung, …) drei Wochen um eine weitere Antwort zu senden, die dann lautete: Wir können das Problem nicht nachstellen, prüfen sie die Netzwerkverbindung.

In solchen Momenten möchte man in die Tischplatte beißen.

Vom Hersteller hat sich im übrigen nie jemand das Problem mal direkt auf dem betreffenden Windows 10-Computer angesehen, es gab auch kein Log oder sonstige Diagnose-Tools die man hätte verwenden können. Enttäuschend.

Jedenfalls nach ein paar Tagen lief es plötzlich wieder, woran es lag oder wie lange es nun gut geht kann man nicht sagen. Naheliegend das es an der WSD-Schnittstelle liegt. Schaut man im Netz, ganz gleich zu welchem Hersteller, findet man weitere Probleme in dieser Richtung.

Das gleiche Problem begenete mir bereits vor zwei Jahren bei einem anderem Kunden, seinerzeit mit Windows 7, eine Lösung gab es damals ebenfalls nicht. Drucken lief dort ebenfalls nur noch via TCP/IP. Scannen klappte wenigstens an einem von fünf PC noch. Letztlich wurde Canon, nicht nur deswegen, verbannt und durch Brother ersetzt.

Vor Jahren hatte ich zudem oft bei HP und solchen Problemen zu kämpfen, allerdings weiß ich nicht mehr, ob es da schon WSD war, die alte Software war gruselig, der Support aber wenigstens bemüht die Probleme zu lösen. Bei neueren Geräten (inkl. neuere Software) war’s dann besser.

Auf der anderen Seite hatten wir noch nie Probleme in der Art mit Geräten von Epson (gilt für WorkForce- und AcuLaser-Modelle).

Debian 9 Stretch: Auflösung der Konsolensitzung bei Hyper-V ändern

$
0
0

Bei einem Kunden läuft unter anderem ein Debian 9 Stretch als virtuelle Maschine unter Hyper-V auf Basis eines Windows Server 2012 R2. Leider ist „ab Werk“ die Auflösung an der Konsole größer, als das Display bzw. via RDP und so darf man mitunter etwas Scrollen.

Es geht zwar „nur“ um ab und an jenseits von ssh etwas tippen zu können, da kein Desktop zum Einsatz kommt. Spätestens beim Editieren von Konfigurationsdateien mittels nano wird’s dann lästig die Bildlaufleisten bemühen zu müssen.

Ändert lässt sich die Auflösung durch eine Ergänzung der GRUB-Konfiguration (alle Befehle als root ausführen):

  • nano /etc/default/grub
  • Die Zeile „GRUB_CMDLINE_LINUX_DEFAULT=“quiet“ um „video=hyperv_fb:<Auflösung>“ erweitern. Diese sieht dann z.B. so aus:
    GRUB_CMDLINE_LINUX_DEFAULT="quiet video=hyperv_fb:1024x768"
  • grub-update
  • reboot

Zur besseren Veranschaulichung noch ein Screenshot:

Diese Lösung funktioniert laut den Kommentaren der Quelle (s.u.) ebenso mit anderen Distri’s wie z.B. Ubuntu und Derivate, RedHat, Fedora, usw.

Quelle:

Ben Armstrong’s Virtualization Blog – Changing Ubuntu Screen Resolution in a Hyper-V VM

Linux/Windows: Prüfen, ob eine Festplatte Aktiv oder im Standby ist

$
0
0

In der Voreinstellung von Windows sollten Festplatten nach 20 Minuten der Inaktivität schlafen gehen. Das klappt nicht immer und kann verschiedene Gründe haben.

Grundsätzlich lässt sich sowohl unter Linux als auch unter Windows (und unter BSD sowie macOS) mit folgenden Tools der aktuelle Status der Festplatte ermitteln:

hdparm -C /dev/sdb
smartctl -n standby /dev/sdb

Zusätzlich kann man mit hdparm eine Festplatte manuell schlafen legen:

hdparm -y /dev/sdb

Den Status abzufragen hilft dabei zu Überprüfen, ob die Energiespareinstellungen überhaupt greifen. Bei Laufwerken kommt erschwerend hinzu, das Zugriffe als auch Treiberfehler den Wechsel in den Standby verhindern.

Unter Windows kann z.B. der ProcessMonitor mit einem gesetzten Filter für das gewünschte Laufwerk dabei helfen, festzustellen, welche Zugriffe stattfinden und so das Energiesparen verhindern:

Zu bedenken gilt allerdings, das nicht jeder Zugriff das Aufwachen (spinup) verursacht. Die im Screenshot zu sehenden Zugriffe durch Explorer oder Panda (AgentSvc.exe) lösen keinen Moduswechsel aus. Automatische Wartung wie z.B. chkdsk (Datenträgerprüfung) und defrag (Defragmentierung) hingegen schon.

Weitere Beispiele für ungewolltes Aufwachen der Festplatte

Bei meinem Heimserver sorgte wiederum ein aktiviertes UPnP des DVBViewers dafür, das die Datenplatte immer wieder aufwachte. Beim Test sorgten Tools wie HWiNFO oder CrystalDiskInfo ebenfalls dafür, das die Festplatte erst gar nicht in den Standby wechselte.

Tricky können manche Versionen von Intel-Festplattencontroller-Treiber (Intel Rapid Storage Technology, RST) sein, die einen Bug enthielten, durch den die Festplatte erst gar nicht schlafen ging. Ein Wechsel zum Microsoft-eigenen Treiber hilft mitunter.

Plan B wenn die OS-Bordmittel zum Energiesparen streiken

Auf einem Windows Server 2012 R2 Standard, der Hauptsächlich als Datengrab läuft, sollte die Datenplatte (neben der SSD für’s OS gibt es tatsächlich nur diese Eine, kein RAID) sich schlafen legen. Leider klappte es trotz entsprechender Einstellung in den Energieoptionen, Intel-Treiber up-/downgrade als auch mit dem Microsoft-Treiber einfach nicht. „Verdächtige Zugriffe“ konnten ebenfalls nicht ausgemacht werden.

In solchen Fällen kann man mittels hdparm versuchen einen Timer für das Abschalten der Platte zu setzen:

hdparm -S 240 /dev/sdb

Das wären die 20 Minuten. Doch dies half beim betreffenden System nur zum Teil. Soll heißen: Zwar ging die Platte nun immer mal wieder in den Standby, dieser dauerte aber meist nie allzulange, mal nur 5, 10 oder evtl. auch mehr mehr Minuten.

Da häufige Spinup’s und -downs sowohl für den Energieverbrauch als auch für die Lebensdauer der Festplatte kontraproduktiv sind, blieb in diesem Fall keine andere Wahl über, als sie doch einfach durchlaufen zu lassen.

Quellen:

hdparm

HDPARM TOOL FOR WINDOWS

smatmontools

superuser – See if HDD is in Sleep Mode for Windows (enthält auch Beispiele für WMI und PowerShell)

LUI – Festplatten automatisch im Betrieb in den Standby schalten

howtoeverything – List Of Timeout Values For „hdparm -S“

Viewing all 2171 articles
Browse latest View live