Archive for the ‘Windows 8.1’ Category

Einfacher SNMP Walker in Powershell

15 März 2017

Ein Uraltprotokoll das Simple Network Management Protokoll kurz SNMP gibt es heute immer noch. Teilweise hilft es sogar ganz schnell Informationen zu erhalten, die sonst nur mühsam aus anderen Geräten, z. B. Druckern zu erhalten sind.

Auch im Server 2016 und Windows 10 gibt es standardmäßig eine COM-Bibliothek welche die Kommunikation mit SNMP-Geräten ermöglicht. Die Bibliothek bringt eine Funktion mit Namen GetTree mit. Mittels dieser Funktion kann man auf einen Schlag alle relevanten Informationen erhalten. Dies hilft oft schon einen ersten Eindruck von einem Gerät zu erhalten, man muss lediglich die IP-Adresse kennen. Wichtig zu wissen, die OIDs müssen mit einem führenden Punkt angegeben werden:

$IP = "192.168.1.87"
$SNMP = New-Object -ComObject olePrn.OleSNMP
$SNMP.Open($IP, "public")
$SNMP.GetTree(".1.3.6.1")
$SNMP.Close()

Die Zahl 1.3.6.1 ist quasi eine Art Adresse. Bei einem aktuellen HP-Drucker funktioniert diese 1.3.6.1 die Adresse 1.3.6 allerdings nicht. Interessiert man sich speziell für Managementdaten dann wird man unter 1.3.6.1.2 fündig. Hier eine schöne Auflistung mit RFC-Verweisen, was wo gefunden werden kann: http://www.multinet.de/fileadmin/mib2/. Drucker werden speziell über die OID 1.3.6.1.2.1.43 abgefragt. Auf der Internetseite http://www.alvestrand.no/objectid/ ist die Hierarchie schön erklärt. Darüber kann man dann den Sinn der Zahlen verstehen.

Was kann man mit diesen OIDs und SNMP anstellen? Z. B. kann man einen Reboot eines Druckers im Netz auslösen: https://newyear2006.wordpress.com/2016/07/10/hp-netzwerkdrucker-per-remote-und-reboot-txt-neu-starten-nix-klappt-aber-snmp-bringt-die-lsung/. Man findet z. B. für die OID 1.3.6.1.2.1.43.5.1.1.3 folgenden Eintrag:

{iso(1) identified-organization(3) dod(6) internet(1) mgmt(2) mib-2(1) printmib(43) prtGeneral(5) prtGeneralTable(1) prtGeneralEntry(1) prtGeneralReset(3)}

prtGeneralReset OBJECT-TYPE
-- This value is a type 3 enumeration
SYNTAX INTEGER {
notResetting(3),
powerCycleReset(4), -- Cold Start
resetToNVRAM(5), -- Warm Start
resetToFactoryDefaults(6) -- Reset contents of
-- NVRAM to factory defaults
}
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"Setting this value to `powerCycleReset, `resetToNVRAM, or `resetToFactoryDefaults will result in the resetting of the printer. When read, this object will always have the value `notResetting(3), and a SET of the value `notResetting shall have no effect on the printer. Some of the defined values are optional. However, every implementation must support at least the values `notResetting and resetToNVRAM."

Quelle: http://oid-info.com/get/1.3.6.1.2.1.43.5.1.1.3

Die tatsächliche Quelle in diesem Fall ist aber eine RFC, die RFC 1759, https://tools.ietf.org/html/rfc1759.html. Dadurch, dass es eine RFC ist, wird es natürlich klar, dass es bei dem Script für den Druckreboot nicht um eine HP spezifische OID handelt sondern um eine allgemein gültige OID, welche auch von anderen Druckerherstellern verwendet werden kann. Damit funktioniert der Neustart auch bei anderen Netzwerkdruckern.

Noch ein Hinweise zum Artikel mit dem Druckerreset. Die Angabe des Parameters 4 ist nun auch klar, denn die steht für powerCycleReset, siehe oben die Parameter.

Um einfache Infos zu einem Gerät zu erhalten fragt mein einfach den sysDescr ab. Der sysDescr stellt eine Gerätebeschreibung dar. http://www.alvestrand.no/objectid/1.3.6.1.2.1.1.1.html. Der Aufruf sieht dann so aus:

$snmp.get(".1.3.6.1.2.1.1.1.0")
HP ETHERNET MULTI-ENVIRONMENT

oder noch besser, man fragt mittels Tree nach:

$snmp.GetTree(".1.3.6.1.2.1.1.1")
system.sysDescr.0
HP ETHERNET MULTI-ENVIRONMENT

Dabei ist offensichtlich, dass sich HP nicht an die Vorgabe hält und Versionsinformationen unterdrückt. Das Beispiel zeigt aber auch, dass man einen einzelnen Wert mittels Get() und .0 erhalten kann und bei GetTree() automatisch alles dazugehörige erhält, sogar den Typ.

Mit dieser Information können wir nun auch folgendes schreiben:

$snmp.get("system.sysDescr.0")
HP ETHERNET MULTI-ENVIRONMENT

D. h. man kann nun sprechendere Namen verwenden. Für unser Druckerreset wäre dies:

$snmp.gettree(".1.3.6.1.2.1.43.5.1.1.3")
printmib.prtGeneral.prtGeneralTable.prtGeneralEntry.prtGeneralReset.1
3
$snmp.get("printmib.prtGeneral.prtGeneralTable.prtGeneralEntry.prtGeneralReset.1")
3

Beides mal wird die 3 für notResetting geliefert.

Noch ein Punkt der wichtig ist, um die Rückgaben von GetTree() besser zu verstehen. Es werden immer zwei Arrays zurückgegeben, d. h. zuerst ein Array mit den Namen der OIDs und danach ein Array mit den eigentlichen Werten zu den OIDs. Dies wird deutlich wenn man die verfügbaren Sprachen des Druckers abfragt:

$snmp.gettree("printmib.prtLocalization.prtLocalizationTable.prtLocalizationEntry.
prtLocalizationLanguage")
printmib.prtLocalization.prtLocalizationTable.prtLocalizationEntry.
prtLocalizationLanguage.1.1
printmib.prtLocalization.prtLocalizationTable.prtLocalizationEntry.
prtLocalizationLanguage.1.2
printmib.prtLocalization.prtLocalizationTable.prtLocalizationEntry.
prtLocalizationLanguage.1.3
printmib.prtLocalization.prtLocalizationTable.prtLocalizationEntry.
prtLocalizationLanguage.1.4
printmib.prtLocalization.prtLocalizationTable.prtLocalizationEntry.
prtLocalizationLanguage.1.5
printmib.prtLocalization.prtLocalizationTable.prtLocalizationEntry.
prtLocalizationLanguage.1.6
printmib.prtLocalization.prtLocalizationTable.prtLocalizationEntry.
prtLocalizationLanguage.1.7
printmib.prtLocalization.prtLocalizationTable.prtLocalizationEntry.
prtLocalizationLanguage.1.8
en
es
de
fr
ar
it
pt
nl

In Wahrheit ist es jedoch ein verschachteltes bzw. zweidimensionales Array:

($snmp.gettree(".1.3.6.1.2.1.43.7.1.1.2"))[0]
Der Index [0] ist für einen Zugriff auf ein 2-dimensionales Array unzulässig.
In Zeile:1 Zeichen:1
+ ($snmp.gettree(".1.3.6.1.2.1.43.7.1.1.2"))[0]
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : InvalidOperation: (:) [], RuntimeException
    + FullyQualifiedErrorId : NeedMultidimensionalIndex

($snmp.gettree(".1.3.6.1.2.1.43.7.1.1.2"))[0,0]
printmib.prtLocalization.prtLocalizationTable.prtLocalizationEntry.
prtLocalizationLanguage.1.1
($snmp.gettree(".1.3.6.1.2.1.43.7.1.1.2"))[1,0]
en

Man erhält zuerst die Namen und in der zweiten Dimension die Werte. Also [0,*] enthält alle Namen und [1,*] enthält alle Werte.

Achso, wie bin ich jetzt von “printmib.prtLocalization.prtLocalizationTable.prtLocalizationEntry.
prtLocalizationLanguage” auf 1.3.6.1.2.1.43.7.1.1.2 gekommen? Auch dazu gibt es eine Funktion:

$snmp.OIDFromString("printmib.prtLocalization.prtLocalizationTable.prtLocalizationEntry.
prtLocalizationLanguage") -join "."
1.3.6.1.2.1.43.7.1.1.2

Jetzt hab ich soviel von den ganzen Zusammenhängen geschwafelt, warum nun nicht am Schluss noch etwas sinnvolles zusammenbauen, z. B. eine Tabelle mit allen sinnvollen Werten?

$e=$SNMP.GetTree(".1.3.6.1")
$d=@()
# umsortieren der Arraystruktur
for($i=0;$i-lt $e.length/2;$i++){$d+=@($e[0,$i], $e[1,$i]) }
$d | out-gridView

Oder noch besser alles mehr powershelllike mit Objekten:

$e=$SNMP.GetTree(".1.3.6.1")
$d=@()
# umsortieren der Arraystruktur
for($i=0;$i-lt $e.length/2;$i++){$d+=[pscustomobject]@{ID=$e[0,$i];Value=$e[1,$i];OID=($snmp.OIDFromString(($e[0,$i])) -join ".")} }
$d | out-gridView

Damit steht dem Erkunden der SNMP-Welt nichts mehr im Wege!

Advertisements

UEFI Boot und Probleme ins BIOS/UEFI zu kommen

3 Dezember 2016

Bei aktuellen Rechnern mit ihren superschnellen Bootvorgängen kann es schon schwierig werden ins BIOS bzw. UEFI zu kommen. Man hämmert wie blöde auf irgendwelche F-Tasten, die man manchmal schon gar nicht mehr auf der Tastatur hat, um dann später festzustellen, es war die falsche oder man war mal wieder zu langsam. Hier eine Aufstellung von möglichen Tasten: http://www.isunshare.com/windows-password/how-to-set-your-computer-to-boot-from-usb-drive.html#opt4.

Windows
Für obiges Problem gibt es seit Windows 8 Abhilfe. Man konnte seither unter den PC-Einstellungen->Update und Sicherheit->Wiederherstellung den Erweiterten Start aufrufen. Da konnte man dann meist den Eintrag UEFI-Firmware Einstellungen unter Problembehandlung->Erweiterte Optionen aufrufen oder die Starteinstellungen ändern. Diese Möglichkeit ist gut aber als bekennender Commandliner nicht sehr befriedigend.

Nun hat Microsoft bereits bei Windows 8 beim Shutdownbefehl den Parameter /o eingeführt. Dieser kürzt die Sache deutlich ab und man gelangt direkt in den Bildschirm mit den Erweiterten Startmöglichkeiten. So gehts:

shutdown /r /o

Wer sich nun unter Windows 10 v1607 die Parameter des Shutdown-Befehls anschaut, der stellt fest, es gibt nun auch einen Parameter /fw, welcher für Firmware steht und Firmware steht wiederum für die ganze UEFI-Geschichte. Man kann also mittels

shutdown /r /fw

direkt in die UEFI-Einstellungen booten! Endlich ein sauber gesteuerter Zugriff ohne zig unnötige Menüs zwischendrin!

Übrigens noch ein Tipp: Es gibt Situationen, da hat man SetHC.EXE oder UTILMAN.EXE umgebogen. Hier ein Beispiel dafür: https://newyear2006.wordpress.com/2015/08/30/abgelaufene-aktivierungen-erschweren-einem-das-leben-unter-windows/. In diesem Fall funktioniert shutdown /r /o z. B. nicht. Man kann sich jedoch behelfen, wenn man statt shutdown /o einfach

reagentc.exe /boottore

verwendet. Hat den gleichen Effekt, funktioniert aber bisher in allen Situationen! Einzige Voraussetzung dafür ist ein korrekt eingerichtetes RecoveryEnvironment. Infos dazu erhält man über reagentc /info.

Linux
Wer nun mit Linux unterwegs ist welches bereits SystemD nutzt, der kommt mit diesem Befehl in die UEFI-Einstellungen:

systemctl reboot --firmware-setup

Hier noch ein paar erhellende Infos zu UEFI unter Linux, vor allem, wie man Firmwarevariablen erzeugen kann und wie man darauf zugreift: https://firmware.intel.com/blog/accessing-uefi-variables-linux.

Ein weiterer interessanter Link für Linux und UEFI: http://superuser.com/questions/519718/linux-on-uefi-how-to-reboot-to-the-uefi-setup-screen-like-windows-8-can.

Vorsicht mit Get-NetFirewallRule bzw. WMI MSFT_NetFirewallRule-Klasse bei Abfrage der Enabled-Eigenschaft – gilt allgemein bei $True und $False in Powershell

10 Juli 2016

Ein Script welches Windows Firewall Regel-Eigenschaften abfragte funktionierte nicht wie erwartet. Es wurde immer die Enabled Eigenschaft abgefragt aber es kam nicht das erwartete Ergebnis, wurde die Abfrage aber negiert, kam das erwartete Ergebnis heraus! Am Ende stellte es sich heraus, dass die Enabled-Eigenschaften kein klassisches Bool sondern einen String zurückgibt, hier die Story:

Fragen wir zunächst die aktuelle Anzahl von Regeln ab, hier bei einem aktuellen Windows 10:

$r=Get-NetFirewallRule
$r.length
413

Es gibt also 413 Regeln. Nun sollen alle Regeln ermitteln werden, die aktiviert sind:

($r | where enabled -eq $true).length
184

Jetzt sollen alle Regeln ermittelt werden, die nicht aktiviert sind:

($r | where enabled -eq $false).length
0

Die 0 ist jetzt nicht das erwartete Ergebnis, wenn man davon ausgeht, dass es 413 Regeln gibt, davon sind 184 aktiv, dann sollten mehr als 0 inaktiv sein.

Wo liegt das Problem? Das Problem ist, dass bei $True oder $False in Powershell immer True oder False am Bildschirm ausgegeben wird. Man interpretiert einen solchen Wert schnell als Boolean. Aber in diesem Fall hat man es nicht mit einem Boolean zu tun:

$r[0].enabled.pstypenames
Microsoft.PowerShell.Cmdletization.GeneratedTypes.NetSecurity.Enabled
System.Enum
System.ValueType
System.Object

Es ist also ein Aufzählungstyp!

($r | where enabled -eq "True").length
184
($r | where enabled -eq "False").length
229

So macht die Sache mehr Sinn!

Oder man macht die Abfrage über den passenden Typ:

($r| where enabled -eq ([Microsoft.PowerShell.Cmdletization.GeneratedTypes.NetSecurity.Enabled]:
:True)).length
184
($r| where enabled -eq ([Microsoft.PowerShell.Cmdletization.GeneratedTypes.NetSecurity.Enabled]:
:False)).length
229

Übrigens: $true –eq "True" ergibt immer True, auch wenn man $true –eq "irgendwas" setzt! Und $False –eq "False" ergibt immer False, egal mit was verglichen wird, außer $false!

Unterschiede zwischen Windows Funktionen bzw. Features bei der Installation

25 Januar 2016

Microsoft hat es über die letzten Jahre mal wieder geschafft ordentlich Verwirrung zu stiften. Wenn man Windows Funktionen wie z. B. das .NET-Framework installiert, so gibt es zig verschiedene Varianten wie man dies erreichen kann.

In diesem Zusammenhang findet man:

Enable-WindowsOptionalFeature
Install-WindowsFeature
Add-WindowsFeature
dism.exe
pkgmgr.exe

Ein schöne Übersicht welche Variante auf welcher Platform, sogar bis 2016 und Nano-Server verfügbar ist, findet man hier: http://peter.hahndorf.eu/blog/WindowsFeatureViaCmd

Nicht nur, dass es unterschiedliche Aufrufe zur Installation gibt, nein je nach Variante haben die Pakete auch unterschiedliche Namen!

Um nun z. B. das .Net 3.5 Framework zu installieren, verwendet man unter Windows Server 2012:

Install-WindowsFeature –Name NET-Framework-Core

und unter Windows 10:

Enable-WindowsOptionalFeature –Featurename NetFx3

Weitere Beispiele hier: http://blog.ittoby.com/2012/11/installing-net-35-on-windows8server.html

Windows 8.1 Backup mit WBADMIN bricht mit Fehler “Auf das bereitgestellte Sicherungsvolume konnte nicht zugegriffen werden” ab, bzw. Fehlercode 0x807800C5

19 Dezember 2015

Viele der Gründe, die hier beschrieben sind http://www.borncity.com/blog/2013/11/11/windows-8-1-backup-probleme-bei-uefigpt-datentrgern/ können zutreffen. Aber meine Theorie ist folgende.

Eine Sicherung, eines Windows 8.1 Rechners mit UEFI Installation und 40GB Platte, mittels

wbadmin START backup -backupTarget:\\NAS2\Freigabe\Sicherungen -include:c: -allCritical -quiet

funktionierte nicht und brachte immer die Fehlermeldung:

Fehler beim Sichern des Volumes "\\?\GLOBALROOT\Device\HarddiskVolume2\": Auf das bereitgestellte Sicherungsvolume konnte nicht zugegriffen werden. Wiederholen Sie den Vorgang.

bzw.

Fehler beim Sichern des Volumes "\\?\GLOBALROOT\Device\HarddiskVolume2\": Der angegebene Sicherungsdatenträger wurde nicht gefunden.

Dadurch wurde bereits im Sicherungsverzeichnis auf einem NAS eine ESP-Partition angelegt. Das wird später noch wichtig!

Zunächst wurde mittels VSSADMIN untersucht, ob es Probleme mit den Providern gibt. Aber nichts in der Richtung.

Dann kam mir die Schattenkopie-Speichergröße mit 3% etwas mickrig vor:

C:\>vssadmin list shadowstorage
vssadmin 1.1 – Verwaltungsbefehlszeilenprogramm des Volumeschattenkopie-Dienstes

(C) Copyright 2001-2013 Microsoft Corp.

Schattenkopie-Speicherassoziation
   Für Volume: (C:)\\?\Volume{ce1bcdaa-9909-464e-2002-4893f5c7566e}\
   Schattenkopie-Speichervolume: (C:)\\?\Volume{ce1bcdaa-9909-464e-2002-4893f5c7566e}\
   Verwendeter Schattenkopie-Speicherbereich: 1,48 GB (3%)
   Zugewiesener Schattenkopie-Speicherbereich: 1,75 GB (4%)
   Max. Schattenkopie-Speicherbereich: 1,18 GB (3%)

Also die Größe auf 10% und 3,95GB erhöht:

vssadmin resize shadowstorage /For=C: /On=C: /MaxSize=10%

Wieder versucht, wieder selbe Fehlermeldung.

Nach verschiedenen anderen nutzlosen Aktionen, den obigen Born-Artikel gefunden und studiert. Viele Aktionen scheinen dann zu klappen, wenn die Partitionsgröße verändert wurde.

Oben hatte ich schon die ESP-Partition im Sicherungsverzeichnis erwähnt. Da dachte ich mir, weil es eh noch keine Historie gab, lösch doch einfach mal das bisher angelegte Backup-Verzeichnis. BANG!

Das war es, nun klappte alles. Was ich durch Vergrößern des Shadowstorage-Bereich und Löschen des Backup-Verzeichnis geschafft habe, schafften andere durch das Ändern der Parititionsgröße? Nur eine Idee, leider keine Zeit zum Nachprüfen.

Weitere Leidensgenossen:
http://superuser.com/questions/663782/windows-8-1-insufficient-storage-available-to-create-shadow-copy

Nachdem nun ein zweiter Rechner das gleiche Problem zeigte, kann ich nun bestätigen, dass die Maßnahme mit Shadowstorage vergrößern und löschen des Sicherungszielverzeichnis die Lösung bringt.

Hier noch weitere Infos. In den Windows Backup Ereignissen wird folgendes Problem aufgezeichnet:

Get-WinEvent -LogName Microsoft-Windows-Backup | select –first 3

   ProviderName: Microsoft-Windows-Backup

TimeCreated                     Id LevelDisplayName Message
———–                     — —————- ——-
18.12.2015 22:12:08             14 Informationen    Die Sicherung ist abgeschlossen.
18.12.2015 22:12:08              5 Fehler           Fehler bei der um ?2015?-?12?-?18T21:11:37.607836100Z gestartete…
18.12.2015 22:11:37              1 Informationen    Die Sicherung wurde gestartet.

Wenn man sich den Fehler näher anschaut, erscheint:

Fehler bei der um ?2015?-?12?-?18T21:11:37.607836100Z gestarteten Sicherung. Fehlercode:
"0x807800C5" ("Fehler beim Vorbereiten des Sicherungsabbilds eines der Volumes im
Sicherungssatz."). Suchen Sie in den Ereignisdetails nach einer Lösung, beheben Sie das
Problem, und führen Sie die Sicherung erneut aus.

Windows 10 geht im kleinsten Detail die Puste aus–oder warum werden meine Icons im Windows Explorer falsch dargestellt?

31 Oktober 2015

Wie erbärmlich ist das denn? Windows 10 liefert von Haus aus OneDrive mit aus. Die Sache an sich ist schon zweifelhaft aber jetzt kommt das Highlight. Um den Status der Dateien welche Offline, Online, gesynct werden usw. anzeigen zu können, werden zum Icon der Datei sogenannte Icon Overlays benutzt. OneDrive bringt schon fünf mit, vier sind von Windows generell für den Explorer reserviert. Sind also neun Overlay Icons. Dumm ist jetzt nur, dass bei Windows 10 aus unerfindlichen Gründen nur maximal 15(!) Icon Overlays vorgesehen sind. Wer jetzt Dropbox oder ähnliches installiert…

https://support.microsoft.com/en-us/kb/3106961

https://msdn.microsoft.com/en-us/library/windows/desktop/cc144123(v=vs.85).aspx

Bilder unter Windows gezielt mit der Windows Fotoanzeige öffnen

30 August 2015

Eine Variante die unter Windows XP – Windows 10 immer verfügbar ist, solange es um übliche Dateiformate wie PNG, BMP, TIFF oder JPG handelt ist die Windows Fotoanzeige. Hier der passende Aufruf:

RunDLL32 "%ProgramFiles%\Windows Photo Viewer\PhotoViewer.dll",ImageViewer_Fullscreen C:\temp\test.bmp

Dabei muss der Bilddateiname immer als absoluter Pfad angegeben werden!

Leider kennen die Server Versionen von Windows den Photoviewer nicht.

http://www.autohotkey.com/board/topic/51203-run-rundllexe-photoviewerdll-syntax/

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"

Passwörter ändern bei Remote-Desktop bzw. Terminalserversitzungen von Windows XP bis Windows 10

20 Juli 2015

Ein harmloses Thema aber dank der Genialität von Microsoft ein Thema, welches schnell ausarten kann. Zunächst einmal die Ausgangsbasis. Es geht darum den Windows Sicherheitsschirm zu bekommen, dass ist der, wenn man an einem physikalischen Rechner sitzt und STRG+ALT+ENTF drückt. Dort werden meistens diese Punkte angezeigt:

  • Computer sperren
  • Benutzer wechseln
  • Abmelden
  • Kennwort ändern
  • Task Manager starten

Jetzt das Problem: Bei einer Remotedesktopsitzung wird STRG+ALT+ENTF immer auf dem lokalen, also physikalischen Rechner ausgeführt und nicht in der Remotesitzung. Ergo kann der Benutzer sein Kennwort nicht selbständig ändern.

Zu Windows XP und Windows 7 Zeiten konnte man nun im normalen Startmenü in der rechten Spalte auf “Windows Sicherheit” klicken. Dieser Eintrag ist immer automatisch verfügbar sobald man sich in einer Remotedesktopsitzung befindet. Aber durch das verschwinden des Startmenü bei Windows 8 verschwand auch der Eintrag mit “Windows Sicherheit”. Selbst die ganzen nachfolgenden Updates zu Windows 8 mit Windows 8.1 Update Update usw. brachten keine Lösung. Auch Windows 10 mit Build 10240 kennt dazu keinen direkten Startmenüeintrag mehr.

Hier nun die möglichen Lösungen:

Variante 1)
Die einfachste Variante man drückt anstatt STRG+ALT+ENTF die Tastenkombination STRG+ALT+ENDE, also anstatt der Entfernen-Taste die Ende-Taste drücken. In den meisten Fällen sollte dies zum Erfolg führen.

Variante 2)
Alternativ kann man mit der Bildschirmtastatur arbeiten. Dazu ruft man OSK.EXE auf und _wichtig_ drückt auf seiner physikalischen Tastatur STRG+ALT und klickt dann auf dem OSK-Keyboard mit der Maus auf die ENTF-Taste.

Variante 3)
Man verwendet ein kleines Skript, üblicherweise Powershell:

Powershell  -command  "(New-Object -ComObject Shell.Application).WindowsSecurity()"

Damit wird auch der Windows Sicherheitsbildschirm angezeigt. Allerdings funktioniert dieses Skript nur, wenn man sich in einer Remotedesktopsitzung befindet. Im normalen Betrieb aufgerufen passiert einfach nichts.

https://msdn.microsoft.com/en-us/library/windows/desktop/gg537748(v=vs.85).aspx?cs-save-lang=1&cs-lang=vb#code-snippet-1

Variante 4)
Seit Windows 8 hat sich ja alles auf die modernen Apps verlagert was bei Tablets auch Sinn macht, denn wer hat schon STRG+ALT-Tasten an seinem Tablet? Deshalb gibt es bei Windows 8 und nachfolgend unter PC-Einstellungen->Konten->Anmeldeoptionen die Möglichkeit sein Kennwort zu ändern. Unter Windows 10 geht man dazu auf Einstellungen->Konten->Anmeldeoptionen.

Eine weitere Variante für Commandliner ab Windows 10 ist der Aufruf von:

start ms-settings:signinoptions

Man kann auch im hypermodernen Edgebrowser in der URL-Zeile direkt ms-settings:signinoptions eingeben und landet dann in der Einstellungsseite. Nur Cortana versteht das noch nicht, irgendwie komisch…

 

So das war der kleine Ausflug in der Geschichte der Passwortänderungen für die Benutzer. Hier noch hilfreiche Links zum Thema:

http://superuser.com/questions/492856/how-can-i-send-a-ctrlaltdelete-through-remote-desktop-in-windows-8

https://social.technet.microsoft.com/forums/windowsserver/en-US/2b67fa96-707b-47c4-90f5-c3a087ba16a9/how-do-i-change-password-when-connected-to-remote-desktop

Hier noch Links zum Thema ms-settings: http://winaero.com/blog/how-to-open-various-settings-pages-directly-in-windows-10/ sowie https://msdn.microsoft.com/en-us/library/windows/apps/xaml/dn741261.aspx und wo es herkommt: https://msdn.microsoft.com/en-us/library/windows/apps/jj662937(v=vs.105).aspx

Ä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…