Archive for the ‘Problemlöser’ Category

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"

ProgrammXYZ funktioniert nicht mehr

28 Juli 2015

Wenn man aus heiterem Himmel eine Windowsfehlermeldung präsentiert bekommt, dass ProgrammXYZ nicht mehr funktioniert, so kann es dafür massig Gründe geben.

In dem auftauchenden Dialog kann man Problemdetails einblenden. Im konkreten Fall wurde als Fehlermodulname dhcpcsvc6.dll gemeldet, wobei sich dies sicher jederzeit ändern kann. Der Ausnahmecode war c0000005. Das Programm, welches den Fehler auslöste war ein altes VB6 Programm, welches sonst auf zig anderen Rechnern scheinbar klaglos arbeitet. Der Grund für den Fehler dürfte ein zum Prozess geladenes DLL-Modul, womöglich vom Virenscanner sein. Leider war eine schnelle Lösung notwendig und keine langwierige Fehleranalyse möglich.

Was auffiel, war, dass bei weiteren Tests auf einmal der Fehlermodulname StackHash_055e auftauchte. Ein ungewöhnlicher Name für ein Modul, zumal ohne Extension. Etwas googeln brachte dann dieses zutage: http://tdistler.com/2009/04/10/stackhash-and-application-crashes-on-windows, http://group-mail.com/microsoft-windows/windows-7-and-vista-stackhash-or-appcrash-error-fix/ und http://answers.microsoft.com/en-us/windows/forum/windows_other-windows_programs/problem-event-name-bex-error-message/cf5baf73-0877-4070-abfb-a2c3a17a9e10?auth=1.

Das Problem hatte also mit DEP zu tun: https://technet.microsoft.com/en-us/library/cc738483(v=ws.10).aspx.

Die schnelle Lösung war also DEP für das ProgrammXYZ einfach auszuschalten. Zwar nicht die feine Art aber damit lief es zunächst wieder.

Änderungen an Windows Firewall protokollieren mit Vergleich vorher/nachher

18 Juli 2015

Wenn man manchmal Programme installiert, dann ändern diese Einstellungen an der Firewall. Wenn man nun protokollieren möchte, was geändert wurde, so kann man sich – wie immer – Powershell bedienen.

Seit Windows 8 gibt es die Network Security Cmdlets, dort findet sich Get-NetFirewallRule. Hiermit kann man folgendes machen:

$fwVorher = Get-NetFirewallRule

Damit erzeugt man quasi einen Snapshot $fwVorher mit den alten Einstellungen der Firewall. Hier ein paar kurze Infos zum Status:

PS C:\Windows\system32> $fwVorher.Count
384
PS C:\Windows\system32> ($fwVorher|where enabled -eq True).Count
138

Es gibt also insgesamt 384 Firewallregeln, davon sind schon 138 aktiviert.

Jetzt geht man her und nimmt Änderungen am System vor. Hier aktiviere ich in einem neu eingerichteten Windows 8.1 Pro den RemoteDesktop und frage danach nochmal obige Informationen ab. Ich speichere es aber wieder in einer Variablen.

PS C:\Windows\system32> $fwNachher=Get-NetFirewallRule
PS C:\Windows\system32> ($fwNachher|where enabled -eq True).Count
141

Es sind also drei Regeln aktiviert worden. Stellt sich die Frage, welche das waren? Hier kommt nun wieder die Mächtigkeit von Powershell zum Tragen, denn wir kennen den Zustand davor und danach, somit können wir Powershell beauftragen die Unterschiede zu finden:

PS C:\Windows\system32> diff $fwVorher $fwNachher

InputObject                                                 SideIndicator
———–                                                 ————-
MSFT_NetFirewallRule (CreationClassName = "MSFT?FW?Firew… =>
MSFT_NetFirewallRule (CreationClassName = "MSFT?FW?Firew… =>
MSFT_NetFirewallRule (CreationClassName = "MSFT?FW?Firew… =>

Ja toll, super das wussten wir davor schon, dass es drei Regeln sind. Die Informationsaussage ist gleich 0. Nächster Versuch, das Compare-Object Cmdlet welches dem diff-Alias zugrunde liegt kennt einen Parameter Property mit dem kann man die Eigenschaft bestimmen, welche verglichen werden soll. Vielleicht klappt es ja damit:

PS C:\Windows\system32> diff $fwVorher $fwNachher -Property Enabled

                                                    Enabled SideIndicator
                                                    ——- ————-
                                                       True =>
                                                       True =>
                                                       True =>

Nicht viel besser wie die erste Variante.

OK, die Lösung des Problems ist ein weiterer Paramater: Passthru

Hier die Variante, wo alles schön ausführlich ausgibt:

diff $fwVorher $fwNachher -Property Enabled -PassThru

Eine etwas besser lesbare Variante wäre die hier:

PS C:\Windows\system32> (diff $fwVorher $fwNachher -Property Enabled -PassThru)| select dis*, des*, ena* | Fl *

DisplayName  : Remotedesktop – Schatten (TCP eingehend)
DisplayGroup : Remotedesktop
Description  : Eingehende Regel für den Remotedesktopdienst, um das Spiegeln einer vorhandenen Remotedesktopsitzung
               zuzulassen. (TCP eingehend)
Enabled      : True

DisplayName  : Remotedesktop – Benutzermodus (UDP eingehend)
DisplayGroup : Remotedesktop
Description  : Eingehende Regel für den Remotedesktopdienst, die RDP-Datenverkehr zulässt [UDP 3389]
Enabled      : True

DisplayName  : Remotedesktop – Benutzermodus (TCP eingehend)
DisplayGroup : Remotedesktop
Description  : Eingehende Regel für den Remotedesktopdienst, die RDP-Datenverkehr zulässt. [TCP 3389]
Enabled      : True

Damit hat man nun ein schönes Protokoll, welche Firewallregel aktiviert bzw. deaktiviert wurde.

Übrigens Windows 10 Build 10158 bringt in der Pro Fassung 626 Firewallregeln mit! Da geht was…

Batchdatei als Administrator ausführen funktioniert nicht und was dies mit dem &-Zeichen im Benutzernamen zu tun hat

27 Februar 2015

Windows hat so seine Eigenheiten. Aktuell bin ich mal wieder über eine solche gestolpert, wo man sich fragt: Was geht da ab? Kurz zur Geschichte, ein Kunde hatte Probleme mit dem Adobe Reader Update: https://newyear2006.wordpress.com/2014/07/03/adobe-reader-installation-meldet-umgltiges-laufwerk-und-bricht-die-installation-ab/. Meine Antwort darauf war, eine Batchdatei anzulegen und diese mit Adminrechten auszuführen. Nur funktionierte die Variante nicht. Nach einigem hin und her wurde es dann klar, dass keinerlei Batchdatei des Kunden, welche über den Windows Explorer mit rechter Maustaste und “Als Administrator ausführen” angefordert wurde, klappte.

Dazu wurde eine einfach Test.BAT-Batchdatei im Benutzer-Verzeichnis C:\USERS\M&M geschrieben:

@ECHO Hallo
PAUSE

Also nichts weltbewegendes. Führt man diese Batchdatei in der Commandline aus, funktioniert alles wie gewünscht, ob mit oder ohne Adminrechte. Führt man die Batchdatei jedoch im Windows Explorer aus, funktioniert nur die Variante ohne Adminrechte. Bei der Variante mit den Adminrechten wird zwar nach dem Zulassen von CONSENT.EXE mit dem bekannten UAC-Dialog gefragt aber es wird effektiv nichts ausgeführt.

Bei der näheren Analyse mittels Procmon.EXE fiel dann folgendes auf, der Punkt  wo der CMD.EXE-Prozess erzeugt wird, wird die richtige Commandline übergeben:

Parent PID: 1996, Command line: "C:\Windows\System32\cmd.exe" /C "C:\Users\M&M\Test.bat" , …

Einige Zeilen später, wo die .BAT-Datei auf Vorhandensein geprüft wird, findet sich auf einmal diese Zeile:

QueryDirectory  C:\Users\M.*

Wo doch der Benutzer M&M heißt und nicht M.*!!

Und genau da entsteht nun das Problem, so dass wieder einige Zeilen später, der Versuch die Batchdatei zu lesen ins Leere läuft:

CreateFile C:\Windows\system32\M\Test.bat PATH NOT FOUND

Echt interessant! D. h. hier wird der Pfadname quasi in zwei Teile aufgelöst, einmal in C:\Users\M und einmal in M\Test.Bat, was eigentlich C:\Users\M&M\Test.Bat lauten sollte.

Dies bedeutet, dass keine Batchdatei des Benutzers M&M als Administrator ausgeführt werden kann! Sobald man aber hergeht und z. B. ein Verzeichnis C:\TestDir anlegt, dort die Test.BAT-Datei ablegt und diese als Administrator ausführt klappt wieder alles.

Was lernen wir daraus: Verwende unter Windows niemals einen Benutzernamen mit einem &-Zeichen!

Dieses Phänomen tritt von Windows 7 bis Windows 10 auf, wahrscheinlich sind aber generell auch ältere Versionen davon betroffen. Man könnte es zwar durch Escapen des &-Zeichen lösen aber im Punkt bei “Ausführen als Administrator” sind einem die Hände gebunden. Hier wird das Escapen beschrieben: http://www.robvanderwoude.com/escapechars.php.


Folgen

Erhalte jeden neuen Beitrag in deinen Posteingang.