Archive for the ‘Problemlöser’ Category

“Wie soll diese Website geöffnet werden?”-Dialog wegbekommen

10 März 2017

In bestimmten Situationen, vor allem nach einer Installation oder Deinstallation eines Programms, kann es bei einem neu eingerichteten Windows 10 dazu kommen, dass ein Dialog geöffnet wird mit dem Text:

Wie soll diese Website geöffnet werden?

App verwenden
—–
Standardbrowser verwenden

[  ]  Immer diese App zum Öffnen von <Website> verwenden

OK

Da die Installationen oder Deinstallationen meistens mit Adminrechten durchgeführt werden, kann es zu einer Situation kommen, wenn man die Meldung nicht beachtet und der eigentliche administrative Vorgang bereits abgeschlossen ist, dass die Meldung weiterhin am Bildschirm stehen bleibt und nicht mehr wegzubekommen ist. Das hat mit den fehlenden Rechten des Standardbenutzers nach der Installation zu tun.

Was also tun?

Entweder Rechnerneustart oder im Taskmanager die Datei OpenWith.EXE beenden.

Advertisements

Treiber von Windows 10 im Windows Server 2016 installieren wenn es keine offiziellen Treiber gibt, am Beispiel einer Intel-Netzwerkkarte

7 März 2017

Eigentlich sind sich Windows 10 und Windows Server 2016 recht nahe, je nach Versionsstand von Windows 10. Dennoch gibt es manchmal bei der verwendeten Hardware Einschränkungen in Bezug auf Treiber. In einem aktuellen Fall war in einem Rechner eine Intel I219-V Netzwerkkarte verbaut. Dieser Karte genügt natürlich heutigen Managementansprüchen in Servern nicht unbedingt und deshalb wurde in Server 2016 die Treiberunterstützung für diese Karte unterlassen. Was an dieser Karte aber komisch ist, ist dass es eine Zertifizierung im Windows Server Katalog dafür gibt: https://www.windowsservercatalog.com/item.aspx?idItem=985d89e0-d6d1-b9e0-654c-0209df71a8c7&bCatID=1468.

Was kann man machen um die Karte trotzdem nutzen zu können? Früher ging man her und änderte die zugehörige Treiber-INF-Datei und aktivierte die Windows 10 Treiber für Server 2016. Diese Methode wurde seit Windows Vista Zeiten immer schwieriger. Man benötigt nun passende Zertifikate, damit Änderungen an INF-Dateien autorisiert sind. Man kann aber in Server 2016 noch die bewährte Methode gehen, die Überprüfung der Treibersignatur auszuschalten, dann installiert man einmal die Treiber, ladet und segnet sie ab. Danach aktiviert man wieder die Prüfung der Treibersignaturen. Nun kann man die Geräte mit Windows 10 Treibern unter Windows Server 2016 nutzen.

Für obiges Beispiel beschreibt dieser Blogartikel den Vorgang sehr schön: http://blog.citrix24.com/install-windows-server-2016-core-intel-nuc/.

Hier mache ich aber eine komplette Beschreibung wegen ein paar Besonderheiten und weil oft Blogs im Internet auch verschwinden.

Ermittlung der HardwareID
Fangen wir an die betreffenden Geräte ausfindig zu machen. Normalerweise würden erkannte Netzwerkadapter mittels Get-NetAdapter auftauchen. Aber die Intel I219-V ist nicht dabei. Nun kann man wie im Blogartikel beschrieben mittels

GetWMIObject win32_PNPEntity |select name,deviceid |where {$_.Name match "Ethernet"}

die HardwareID ermitteln, welche

name     : Intel(R) Ethernet Connection I219-V
deviceid : PCI\VEN_8086&DEV_1570&SUBSYS_20638086&REV_21\3&11583659&0&FE

ergibt. Von dieser Info ist die VEN_8086&DEV_1570 von Bedeutung. Im Blogartikel wird noch eine zweite Variante genannt, die bezieht sich auf die WLAN-Karte, welche nicht unter Ethernet zu finden ist, sondern unter Network. Wenn man allerdings unter einem deutschsprachigen Windows diesen Befehl ausführt

GetWMIObject win32_PNPEntity |select name,deviceid |where {$_.Name match "Network"}

dann erscheint nicht die gesuchte Info, sondern

name                                   deviceid
—-                                   ——–
Microsoft Kernel Debug Network Adapter ROOT\KDNIC\0000

weil es Network nicht gibt. Man muss statt dessen nach

GetWMIObject win32_PNPEntity |select name,deviceid |where {$_.Name match "Netzwerkcontroller"}

suchen, um z. B. dieses Ergebnis zu bekommen:

name     : Netzwerkcontroller
deviceid : PCI\VEN_8086&DEV_24F3&SUBSYS_90108086&REV_3A
\4&A711841&0&00E0

Blöd und umständlich so was. Aber wir sind ja auf Server 2016, da gibt es neuere Möglichkeiten Hardwaredinge abzufragen:

Get-PnpDevice -Class Net| select status, friendlyname, instanceid|fl *

status       : OK
FriendlyName : Intel(R) Ethernet Connection I219-V
InstanceId   : PCI\VEN_8086&DEV_1570&SUBSYS_20638086&REV_21\3&11583659&0&FE

status       : Error
FriendlyName : Netzwerkcontroller
InstanceId   : PCI\VEN_8086&DEV_24F3&SUBSYS_90108086&REV_3A
\4&A711841&0&00E0

Prima. Hier sehen wir auch gleich, dass es beim Wirelesscontroller ebenso Probleme gibt, weil dort der Status Error steht. Dies war beim I219-V am Anfang natürlich auch, allerdings sind hier im Beispiel bereits die LAN-Treiber geladen.

Wir müssen uns also nur merken, dass wir anstatt der WMI-Abfrage von Win32_PNPEntity auch direkt Get-PnPDevice –Class Net verwenden können.

Treiber herunterladen und entpacken
Neben der HardwareID benötigen wir auch die passenden Treiber von Windows 10. In diesem Fall waren diese unter https://downloadcenter.intel.com/de/download/ unter dem Stichwort ProWin und ProsetWireless zu finden. Damit man aber mit den Dateien etwas anfangen kann, müssen diese aber entpackt werden. Leider wird es immer mehr zur Unsitte nicht mehr hinzuzuschreiben, wie man Treiber nur entpacken aber nicht installieren kann. Im Zweifel verwendet man 7zip um die Treiber aus den .EXE-Dateien zu extrahieren.

INF-Datei modifizieren
So nun muss man zu den IDs den passenden Treiber finden. Dazu ruft man

Get-ChildItem –Recurse | Select-String –Pattern "VEN_8086&DEV_1570" | group Path | select name

Name
—-
D:\IntelTreiber\PRO1000\Winx64\NDIS62\e1d62x64.inf
D:\IntelTreiber\PRO1000\Winx64\NDIS63\e1d63x64.inf
D:\IntelTreiber\PRO1000\Winx64\NDIS64\e1d64x64.inf
D:\IntelTreiber\PRO1000\Winx64\NDIS65\e1d65x64.inf

auf. Dabei sollte man bereits im Pfad stehen, wo man die Treiber entpackt liegen hat.

Eine Frage ergibt sich, welche Datei man nun bearbeitet? Im konkreten Fall die e1d65x64.inf. Mit den kryptischen Versionen 62, 63, 64 und 65 ist die NDIS-Version gemeint. Windows Server 2016 beherrscht zwar bereits NDIS 6.60 aber ist abwärtskompatibel, deshalb die 65 für Version 6.50. Hier findet man ein paar Infos zu den verschiedenen NDIS-Versionen bei Windowsversionen: https://en.wikipedia.org/wiki/Network_Driver_Interface_Specification.

Man ladet nun die INF-Datei einfach in Notepad, im obigen Beispiel so:

Notepad D:\IntelTreiber\PRO1000\Winx64\NDIS65\e1d65x64.inf

Nun müssen wir uns die Sektionen [Intel.NTamd64.10.0.1] und [Intel.NTamd64.10.0] genauer ansehen. Kurz die 10.0.1 steht für Windows Clientversionen, und 10.0 für Server.

Die Sektionen haben bei INF-Dateien eine besondere Bedeutung. Das lustige ist, dass in der betreffenden INF-Datei nicht nur Windows 10 sondern auch Server 2016 Informationen stehen, ja sogar explizit für die I219-V Netzwerkkarte. Allerdings wurde im für Server entscheidenden Abschnitt die I219-V ausgelassen!

Mehr Infos zu den Herstellerangaben bei INF-Dateien findet man hier, da wird auch der genaue Aufbau der Sektionsnamen beschrieben: https://msdn.microsoft.com/de-de/windows/hardware/drivers/install/inf-manufacturer-section.

Man fügt also unter [Intel.NTamd64.10.0] diesen Eintrag hinzu

%E1570NC.DeviceDesc%            = E1570.10.0.1,       PCI\VEN_8086&DEV_1570
%E1570NC.DeviceDesc%            = E1570.10.0.1,       PCI\VEN_8086&DEV_1570&SUBSYS_00008086
%E1570NC.DeviceDesc%            = E1570.10.0.1,       PCI\VEN_8086&DEV_1570&SUBSYS_00011179

dabei müsste auch

%E1570NC.DeviceDesc%            = E1570,       PCI\VEN_8086&DEV_1570
%E1570NC.DeviceDesc%            = E1570,       PCI\VEN_8086&DEV_1570&SUBSYS_00008086
%E1570NC.DeviceDesc%            = E1570,       PCI\VEN_8086&DEV_1570&SUBSYS_00011179

funktionieren und stellt sogar die sicherere Variante dar.

Treibersignaturprüfung ausschalten
Jetzt kommt der eigentlich wichtigste Punkt. Ohne diesen bekommt man die Sache nicht zum Laufen.

bcdedit /set LOADOPTIONS DISABLE_INTEGRITY_CHECKS
bcdedit /set TESTSIGNING ON
bcdedit /set NOINTEGRITYCHECKS ON

Für diese Änderung muss allerdings der Rechner neu gestartet werden, also

Restart-Computer

Treiber installieren
Nun kommt der spannende Moment, wenn man die Treiber lädt, ob es klappt.

pnputil.exe -i -a D:\IntelTreiber\PRO1000\Winx64\NDIS65\e1d65x64.inf

Wenn dann so was ausgegeben wird, hat alles geklappt:

Microsoft-PnP-Hilfsprogramm

Verarbeitungsinf.:            e1d65x64.inf
Der Treiber konnte auf einem Gerät dieses Systems installiert werden.
Das Treiberpaket wurde erfolgreich hinzugefügt.
Veröffentlichter Name:            oem2.inf

Versuche gesamt:              1
Anzahl erfolgreicher Importe: 1

Abschlussarbeit
Natürlich muss man nun die Treibersignaturprüfung wieder aktivieren.

bcdedit /set LOADOPTIONS ENABLE_INTEGRITY_CHECKS
bcdedit /set TESTSIGNING OFF
bcdedit /set NOINTEGRITYCHECKS OFF

 

Probleme mit Exchange, IMAP, POP3, SMTP, Outlook, Office365 usw. mit dem Microsoft Remote Connectivity Analyzer aufspühren

26 Oktober 2016

Mittels diesem Link kann man bei Microsoft verschiedene Dienste testen, ob diese generell funktionieren. Man muss zwar sein Zugangsdaten eingeben, aber was macht man nicht alles in verzweifelten Situationen, wenn gar nichts mehr geht.

https://testconnectivity.microsoft.com/

Deutsche Tastaturbelegung bei 16-Bit Programmen unter Windows 10

7 Juni 2016

Noch ein kleiner Nachschlag zum vorherigen Blogeintrag https://newyear2006.wordpress.com/2016/06/06/16-bit-komponenten-unter-windows-10-und-fehlermeldung-ntvdm-angeschlossenes-gert-funktioniert-nicht/. Wer so 16-Bit Programme verwendet, der wird sich wundern wo die Umlaute geblieben sind. Man kann das Problem ganz einfach nachstellen:

Macht man eine Eingabeaufforderung auf, dann handelt es sich um eine 32-Bit Eingabeaufforderung, hier sind die Umlaute noch verfügbar. Gibt man nun COMMAND ein, wird die eigentliche 16-Bit Umgebung geladen, sind auf einmal die Umlaute weg. Selbiges passiert auch beim direkten Laden von 16-Bit Programmen über Verknüpfung oder Namenseingabe.

Microsoft Windows [Version 10.0.10586]
(c) 2015 Microsoft Corporation. Alle Rechte vorbehalten.

C:\Users\Benutzer>öäß
Der Befehl "öäß" ist entweder falsch geschrieben oder
konnte nicht gefunden werden.

C:\Users\Benutzer>command
Microsoft(R) Windows DOS
(C)Copyright Microsoft Corp 1990-2001.

C:\USERS\BENUTZER>;‘-

Dieser Artikel ist zwar alt aber hat auch bei Windows 10 immer noch Gültigkeit https://newyear2006.wordpress.com/2006/09/18/deutsche-tastaturbelegung-fur-16bit-dos-programme-unter-vista-rc1/. D. h. man aktiviert durch einfügen von

LH KB16 GR,,%SystemRoot%\system32\keyboard.sys

in der C:\Windows\System32\AUTOEXEC.NT Datei die deutsche Tastaturunterstützung. Nun muss das Programm oder die Eingabeaufforderung nur nochmal neu gestartet werden, dann ist alles gut.

Noch ein Hinweis: Nicht wundern, wenn man diesen Schritt immer wieder nach jedem größeren Windowsupgrade machen muss, da das Gesamtsystem durch z. B. das kommende Anniversary Update immer wieder zurückgesetzt wird!

Probleme mit leeren Bildschirm bei Sichern und Wiederherstellen unter Windows 7 und allgemeines Sicherungsdebugging

30 Mai 2016

Datensicherungen sind wichtig, gerade in Zeiten von Cryptolocker-Malware. Was macht man aber, wenn man mit einer leeren Seite und ohne Fehlermeldung begrüßt wird, wenn man den Sicherungsstatus überprüfen möchte?

In einem Fall unter Windows 7 zeigte der Aufruf der “Sichern und Wiederherstellen”-Seite über die Systemsteuerung einfach nur ein leeres Bild. Schlecht so was. Auch der direkte Aufruf von sdclt.exe brachte die gleiche Darstellung. Hier ist das Problem nochmal mit Bildern beschrieben: http://www.borncity.com/blog/2014/09/29/windows-sichern-und-wiederherstellen-bleibt-leer/.

Gut wenn die Oberfläche nichts anzeigt, dann schaut man halt tiefer und ein Aufruf von wbadmin get versions brachte erschreckendes zu Tage, dass die letzte Sicherung schon ein paar Wochen her ist!

Dann der nächste Blick in die Windows Ereignisanzeige unter Anwendungs- und Dienstprotokolle/Microsoft/Windows/Backup. Oh je, der Eindruck mit denen von wbadmin stimmt überein, keine Backups wurden für die letzten Wochen protokolliert.

An was liegt es? Ist womöglich die Ausführung in der Aufgabenplanung deaktiviert? Witzig: Nein, die scheint immer schön brav jeden Tag durchzulaufen und meldet keine Fehler!

Gibt es hier einen Masterplan? Keine Ahnung, zunächst kann man natürlich die Ressourcenüberprüfung mittels SFC.EXE /SCANNOW drüberjagen, doch die brachte nichts.

Jetzt sollte man sich mal Gedanken machen, welche Dienste für eine Datensicherung benötigt werden. Da gibt es drei:

PS> Get-Service wbengine, SDRSVC, VSS

Status   Name               DisplayName
——   —-               ———–
Stopped  SDRSVC             Windows-Sicherung
Stopped  VSS                Volumeschattenkopie
Stopped  wbengine           Blockebenen-Sicherungsmodul

stellt sich die Frage, lassen die sich starten?

PS> Start-Service wbengine, SDRSVC, VSS
start-Service : Der Dienst "Windows-Sicherung (SDRSVC)" kann aufgrund des folgenden Fehlers nicht gestartet werden:
Der Dienst SDRSVC kann nicht auf dem Computer . gestartet werden.

In Zeile:1 Zeichen:1
+ start-Service wbengine, SDRSVC, VSS
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : OpenError: (System.ServiceProcess.ServiceController:ServiceController) [Start-Service],
   ServiceCommandException
    + FullyQualifiedErrorId : CouldNotStartService,Microsoft.PowerShell.Commands.StartServiceCommand

PS> Get-Service wbengine, SDRSVC, VSS

Status   Name               DisplayName
——   —-               ———–
Stopped  SDRSVC             Windows-Sicherung
Running  VSS                Volumeschattenkopie
Running  wbengine           Blockebenen-Sicherungsmodul

OK, das ist eine Aussage: Der Dienst kann nicht gestartet werden, weil der Dienst nicht gestartet werden kann! Blöd so was, aber warum kann er nicht gestartet werden?

PS> Get-Service SDRSVC | fl *

Name                : SDRSVC
RequiredServices    : {RPCSS}
CanPauseAndContinue : False
CanShutdown         : False
CanStop             : False
DisplayName         : Windows-Sicherung
DependentServices   : {}
MachineName         : .
ServiceName         : SDRSVC
ServicesDependedOn  : {RPCSS}
ServiceHandle       : SafeServiceHandle
Status              : Stopped
ServiceType         : Win32OwnProcess
StartType           : Disabled
Site                :
Container           :

Klar, wenn ein Dienst deaktiviert ist, dann kann er auch nicht gestartet werden!

Also setzen wir den Dienst auf seinen Standardwert:

PS> Set-Service SDRSVC -StartupType Manual

Nun kann man mittels SDClt.EXE oder, wie gewohnt, mit vielen Klicks den Punkt “Sichern und Wiederherstellen” aufrufen und siehe da, es wird wieder alles angezeigt!

Ob dann die Sicherung auch wirklich klappt? Keine Ahnung, aber wer so eine Einstellung hat, der hat vielleicht einen weiteren Dienst deaktiviert, also schauen wir uns noch die anderen Dienste an:

PS> Get-Service wbengine, SDRSVC, VSS| select name, displayname, starttype

Name     DisplayName                 StartType
—-     ———–                 ———
SDRSVC   Windows-Sicherung              Manual
VSS      Volumeschattenkopie            Manual
wbengine Blockebenen-Sicherungsmodul    Manual

Also sieht ja gut aus.

Da wir gerade dabei sind, wenn es schon Probleme gibt, dann helfen diese Abfragen (Powershell 3.0 muss vorhanden sein):

Get-WinEvent -LogName Microsoft-Windows-Backup|select -First 10

Get-ScheduledTask -Recurse | where name -match backup| select name,status,lastruntime,lasttaskresult, nextruntime| ft –AutoSize

Get-Service wbengine, SDRSVC, VSS| select name, displayname, starttype, status

vssadmin list writers

Bei Get-ScheduledTask ist wichtig LastTaskResult mit anzuzeigen, weil dies standardmäßig nicht mit aufgelistet wird aber wertvolle Hinweise geben kann.

Bei vssadmin list writers sind insbesondere die Angaben zum letzten Fehler der einzelnen Writer zu beachten! Eine Idee, wie man mit vssadmin umgeht, geben diese beiden Artikel: https://newyear2006.wordpress.com/2015/12/19/windows-8-1-backup-mit-wbadmin-bricht-mit-fehler-auf-das-bereitgestellte-sicherungsvolume-konnte-nicht-zugegriffen-werden-ab-bzw-fehlercode-0x807800c5/ und https://newyear2006.wordpress.com/2011/09/09/sbs2011-backup-bricht-mit-fehler-2155348129-ab-und-was-hat-das-mit-sharepoint-updates-zu-tun/.

Probleme beim Abruf von Internet Seiten durch Meldung: Bad Request–HTTP Error 400

17 Februar 2016

Wenn man Probleme mit der Meldung

Bad Request – Request Too Long


HTTP Error 400. The size of the request headers is too long.

bekommt, kann es daran liegen, dass der Überwachungsapparat einem zu viel Daten unterjubelt. Gemeint sind Cookies, welche von den Webservern an die Browser gesendet werden. Sammeln sich davon zuviele, weil z. B. ein Systemwechsel auf Serverseite stattgefunden hat und dabei das Ablaufdatum der alten Cookies nicht nah genug beschränkt waren, so kann es schon mal zu einem Überlauf kommen. Wie immer findet man dann kryptische Fehlermeldungen, die einen dumm dastehen lassen.

Was ist also zu tun? Browsercookies löschen!

Man kann auch z. B. in Chrome gezielt mit F12 die Entwicklertools aufrufen und dort bei Ressourcen unter Cookies diese nach der Größe sortieren lassen. Dann kommen da schnell so Brocken mit 2KB zum Vorschein, davon abgesehen, dass nicht ein, zwei sondern gleich zig Cookies zugegen sein können.

Was gibt der Registrierungsschlüssel DHCPGatewayHardware her? Oder – wie kann man alternativ per Powershell das DHCP-IPv4-Gateway ermitteln?

28 September 2015

Hier mal etwas für Forensiker. Aus der Not geboren, dass nur eine Fernwartung beim Kunden möglich war – die nur einmal aufgebaut werden konnte, galt es herauszufinden, warum Netzprobleme bei der IPv4-Adressvergabe auftraten. Eigentlich sollten die Clientrechner IP-Adressen im Bereich 192.168.0.X bekommen aber effektiv bekamen fast alle Rechner eine im Bereich 192.168.1.X. Dadurch war kein Internetzugang mehr möglich und auch der Fileserver unter 192.168.0.1 war nicht mehr erreichbar. Da im konkreten Fall ein Speedport mit der Adresse 192.168.0.100 der DHCP-Server war, wurde zunächst eine Station mit einer fixen IP-Adresse im Bereich des Speedport versehen. Von dort aus war dann der Zugriff zum Speedport möglich. Auch das Internet mit einer Fernwartungssitzung klappte dadurch wieder. Jetzt galt es aber rauszubekommen, warum die Rechner teilweise falsche IP-Adresse bekamen. Nur wie macht man das, wenn man auf der einzigen Netzwerkkarte per Fernwartung aufgeschaltet ist?

Zunächst versuchte ich Scapy per Python ans laufen zu bekommen,  um dieses Script ausführen zu können: https://bitbucket.org/secdev/scapy/wiki/doc/IdentifyingRogueDHCPServers. Die Idee war ganz einfach einen Netzwerkmitschnitt über DHCP-Server-Ankündigungen zu machen. Aber leider beschwerte sich Scapy, beim Versuch der Installation, ständig über eine weitere, fehlende Abhängigkeit. Am Ende lief es auf jeden Fall nicht.

Wireshark wäre noch eine Option gewesen, da die WinPCap-Treiber wegen Scapy eh schon installiert waren. Aber Wireshark kann jeder.

Wie immer wäre mir eine Powershell-Lösung die liebste, aber leider gibt es noch nichts Vergleichbares zu Scapy. Bei der Suche nach der Powershell-Lösung bin ich allerdings über diesen Artikel gestolpert: http://www.ingmarverheij.com/read-dhcp-options-received-by-the-client/. Ich hatte zwar beim betreffenden Windows 7 Rechner keinen Eintrag mit DhcpInterfaceOptions aber zumindest der Eintrag DhcpGatewayHardware war vorhanden. Der Eintrag war als REG_BINARY mit dem Wert

c0 a8 01 01 06 00 00 00 e8 fc af ab c0 24

eingetragen. Der Wert von DhcpGatewayHardware ist zu finden unter HKLM\SYSTEM\CurrentControlSet\services\Tcpip\Parameters\Interfaces\{GUID}.

Per Powershell erreicht man den Wert über

$a = gwmi Win32_NetworkadapterConfiguration
$i = $a | where {$_.Description –like "*Intel*"}

$i.SettingID

$si = $i.SettingID

$ri = Get-ItemProperty -path "registry::HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\Tcpip\Parameters\Interfaces\$si" -name dhcpgatewayhardware | select DHCPGatewayHardware

$ri

Bei *Intel* sollte man den Hersteller seiner Netzwerkarte eintragen, für Realtek z. B. *Realt*, wenn es mehrere geben sollte, muss natürlich die betreffende herausgefiltert werden. Das entscheidende dabei ist, dass man die GUID der SettingID bekommt, über welche man weiß wo man in der Registrierung bei den Interfaces suchen muss.

Auf jeden Fall bekommt man am Ende bei $ri z. B.  diese Ausgabe:

DhcpGatewayHardware
——————-
{192, 168, 1, 1…}

Man sieht bereits, dies ist der falsche Wert, der am Anfang dafür gesorgt hatte, dass der Kunde nicht arbeiten konnte. Das interessante dabei ist, 192.168.1.1 entspricht hexadezimal genau “c0 a8 01 01”, die grüne Markierung verdeutlicht nochmal den Zusammenhang. Also ist der Zusammenhang schon mal hergestellt. Der hintere Wert e8 fc af ab c0 24 sieht wie eine MAC-Adresse aus, denn warum sonst sollte Microsoft den Eintrag DhcpGatewayHardware nennen?

Also noch die Bytes 8-14 ausgelesen und daraus eine MAC-Adresse gebastelt:

$mac=$ri.DhcpGatewayHardware[8..14]
$mac=$mac| foreach {$new=""} {$new+="{0:x02}:" -f $_} {$new}
$mac=$mac.TrimEnd(":")

$mac

Nun hat man in $mac die MAC-Adresse des DHCP-Servers, welcher die IP-Adresse 192.168.1.1 geliefert hatte.

Also mal Google bemüht und dies gefunden: http://macaddress.webwat.ch/hwaddr/E8:FC:AF. Hier wird E8:FC:AF Netgear zugeordnet:

Device mac address: E8:FC:AF
Base16 encoding: E8FCAF
producer name: NETGEAR INC.,

producer address:

350 EAST PLUMERIA DRIVE
SAN JOSE CALIFORNIA 95134
UNITED STATES

Jetzt galt es nur noch ein Gerät ausfindig zu machen. Aber mit dem Wissen, dass es sich um ein Netgear Gerät handelte, war der weitere Weg wesentlich einfacher, als wenn es irgendein Gerät im Netz gewesen wäre. Vor allem war dadurch auch klar, dass es sich nicht um einen gefakten bzw. Rogue-DHCP-Server handelte, welcher eine Attacke im Netz ritt.

Übrigens: Bei einem korrekt konfigurierten und funktionierendem Netz bekommt man, bei Anwendung obigen Scripts, einfach das Gateway mit der betreffenden MAC-Adresse, wenn DHCP aktiviert ist.

Windows Emergency Management Services (EMS) Konsole

25 September 2015

Mal wieder so eine Sache, die es schon jahrelang gibt, auf die man dann per Zufall stößt. Man kann mittels Emergency Management Services Rechner neu starten, die eigentlich einen Bluescreen darstellen. Offenbar geht dann auch noch Powershell, irgendwie. Da gerade die Zeit fehlt tiefergehende Tests zu machen, hier einfach mal die einschlägigen Ressourcen zum Thema:

https://www.myotherpcisacloud.com/post/Windows-Emergency-Management-Services

Mit dieser (USB):

Bcdedit.exe /EMS ON /EMSSETTINGS BIOS

bzw. dieser (RS-232):

Bcdedit.exe /EMS ON /EMSSETTINGS EMSPORT:COM2 EMSBAUDRATE:9600

Änderung vor einem Problem, kommt man auf die Kiste von extern wieder drauf und es meldet sich die Special Administration Console (SAC), wo man dann eine herkömmliche Shell hat.

Hier bestätigt tatsächlich jemand, dass dort auch Powershell möglich ist: http://serverfault.com/questions/554298/windows-serial-console.

Hier noch Beschreibungen zu den BCDEdit.EXE und EMS-Parameter: https://msdn.microsoft.com/en-us/library/ff542282%28v=vs.85%29.aspx?f=255&MSPPError=-2147217396

Weitere Infos von MS: http://social.technet.microsoft.com/wiki/contents/articles/2469.windows-server-emergency-management-resources.aspx

Abgelaufene Aktivierungen erschweren einem das Leben unter Windows und wie man diese zurücksetzen kann

30 August 2015

Wer viel mit virtuellen Maschinen zu tun hat, der kennt vielleicht das Problem, man macht schnell eine Kopie eine VHD oder VHDX und setzt eine neue Maschine auf um etwas zu testen. Dann gerät die Sache in Vergessenheit und später fragt man sich, um was ging es eigentlich genau. Es ist ja kein Problem das System nochmals hochzufahren und nachzuschauen. Blöd nur, wenn dann auf einmal Microsoft nach der Aktivierung fragt. Noch blöder ist es, wenn man keine Aktivierung durchführen kann, weil man keine ordentliche Internetverbindung zustande bekommt.

Eine Lösung ist seit Windows Vista die Sache mit UTILMAN.EXE. Man benennt UTILMAN.EXE unter WinPE oder WinRE um und kopiert einfach CMD.EXE auf UTILMAN.EXE. Danach kann man am Anmeldebildschirm die Eingabehilfen aktivieren und schwupps öffnet sich die Eingabeaufforderung. Hier eine ausführliche Beschreibung, wie man zum Ziel kommt: https://www.petri.com/bypass-windows-server-2008-activation, hier etwas einfacher: https://www.technibble.com/bypass-windows-logons-utilman/.

Soweit so gut. Aktuell war aber eine Small Business Server 2003 R2 zur Mitarbeit zu überreden. Nur leider funktionierte obige Variante dort nicht. Zum Glück gibt es auch hier eine Alternative, die hier beschrieben steht: https://cyberwaves.wordpress.com/2011/06/20/windows-server-2003-aktivierung-umgehen-circumvent-activation/.

Hier nochmal die wesentlichen Punkte: Beim Aktivierungsassistenten drückt man STRG+L, dann auf Durchsuchen, dort gibt man C:\WIDNOWS\SYSTEM32\*.* ein und sucht dann CMD.EXE, klickt dort mit der rechten Maustaste und wählt “Ausführen als” aus. Man muss zwingend den unteren Eintrag mit der expliziten Anmeldung wählen und seine Anmeldedaten eingeben. Nun öffnet sich eine Eingabeaufforderung.

Leider bleibt diese nicht ewig erhalten, sondern LSASS.EXE sorgt dafür, dass nach einiger Zeit die Shell wieder geschlossen wird. Man kann problemlos wieder eine Shell öffnen. Wenn man etwas mehr Zeit braucht, kann man den Sysinternals Prozessexplorer starten, auch Regedit bleibt dauerhaft erhalten. Warum keine Ahnung, aber scheinbar kann man etwas aktivieren, damit die Programme erhalten bleiben. Durch den Prozessexplorer kann man auch LSASS auf den Suspendstatus setzen allerdings gibt es dadurch später irgendwann stress, durch ungewollte Blockierung.

Hier noch weiteres, interessantes Material: http://blog.didierstevens.com/2006/08/21/playing-with-utilmanexe/

Per Zufall bin ich nun noch auf etwas anderes gestoßen, damit ist die Variante perfekt. Also, wie oben die Eingabeaufforderung öffnen und dann diesen Befehl eingeben:

rundll32.exe syssetup,SetupOobeBnk

Der sorgt dafür, dass nach dem erneuten Start des Servers die Anmeldung ganz normal funktioniert!!

Komischer Eintrag im Taskmanager beim Autostartregister

1 August 2015

Der Taskmanager von Windows 8 und Windows 10 kann, wenn man die Detailanzeige aktiviert hat ein Register Autostart anzeigen. In diesem Fenster werden dann alle Programme aufgelistet, die beim Rechnerstart automatisch ausgeführt werden.

Mit der rechten Maustaste kann man zusätzliche Infos zu den Programmen erhalten, indem man die Punkte “Dateipfad öffnen” oder “Eigenschaften” anklickt. Wenn man allerdings einen Eintrag hat, der beide Punkte nicht zulässt, um was handelt es sich dann?

Mittels http://live.sysinternals.com/autoruns.exe kann man sich die Lage genauer anschauen. Dort wird man dann rausfinden, dass das entsprechende Programm einfach nicht mehr existiert, obwohl der automatische Starteintrag noch vorhanden ist. Dies führt dazu, dass die beiden genannten Menüpunkte nicht aufrufbar sind.

Man kann also den Eintrag in Autoruns löschen und wie von magischer Hand verschwindet postwendend auch der Eintrag im Tastmanager.

Man kann den Vorgang auch simulieren, indem man z. B. folgenden Eintrag per Powershell ausführt:

New-ItemProperty -Name Test -Value "C:\temp\test.exe" -Path "HK
CU:\SOFTWARE\Microsoft\Windows\CurrentVersion\Run"

Schupps taucht ein Eintrag beim Autostartregister im Taskmanager auf.

So bekommt man ihn wieder weg:

Remove-ItemProperty -Name Test -Path "HKCU:\SOFTWARE\Microsoft\
Windows\CurrentVersion\Run"