Kleineres Powershell Problem

[edv.kleini]

Etwas ist mir noch aufgefallen
Wenn das Skript richtig laufen soll, muss die setdpi.exe in den Ordner C:\Windows kopiert werden.
Des Weiteren muss man in einem DOS-Fenster mit administrativen Rechten:


Dort powershell.exe set-ExecutionPolicy -ExecutionPolicy Bypass -force eintippen...
Damit wird eingestellt, dass der Computer Powershell Skripte öffnen kann...

Danke auch an @ThorstenBerlin für den Hinweis...

 

[edv.kleini]

So
Das Powershellsript zur Datenerfassung des Computers ist über das Wochenende nochmals größer geworden.
Jeder, aber auch wirklich jeder Netzwerkadapter wird erfasst und seitenweise mit seinen Werten ausgegeben.
Das habe ich über den Windows befehl IPconfig.exe /all erreicht.
Dieses Programm speichert die Daten in einer kleinen Text-Datei zwischen.
Powershell liest diese Werte ein und löscht diese zwischengespeicherte Text-Datei direkt wieder.
Selbst die KI hat keine bessere Lösung angeboten, da es mit dem Powershell CIM Instance-Befehl bei der Erfassung
der Netzwerkadapter und deren IP-Adressen immer wieder Probleme gab.
Viel schneller und effektiver (und darauf bin ich letzten Endes gekommen) war die IPConfig-Methode!
Das Powershellsript erfasst jetzt zudem noch Web-Cams, Digital-Kameras und Scanner.
Diese Multimediagruppe zu erfassen ist nicht immer 100%ig präzise.
Bei Multifunktionsdruckern habe ich daher einen Filter gesetzt, so dass eben nur reine Scanner erfasst werden.
Aber auch das alles halt nur im Bereich des mir technisch machbaren.
Zur weiteren Software-Erfassung sind noch folgende Sachen hinzugekommen.
MS-DOT-NET Framework Pakete werden erfasst (soweit vorhanden und wenn ja dann auch runter bis zur 2.0 Version).
DirectX 9 (soweit vorhanden bzw. installiert) und DirectX 12.
Ausserdem wurden die drei wichtigsten RUN-Keys aus der Registry mit erfasst.
Das sind:
HKCU\Software\Microsoft\Windows\Current Version\Run
HKLM\Software\Microsoft\Windows\Current Version\Run
HKLM\Software\WoW6432Node\Microsoft\Windows\Current Version\Run
Eine wichtige Verbesserung noch am Rande...
Das Powershellskript kann, wenn es im selben Verzeichnis liegt wie die SETDPI.exe,
jetzt problemlos gestartet werden.
Man braucht die SETDPI.exe nicht mehr in C:\Windows abspeichern.

Im Anhang daher eine ZIP-Datei und darin ein Verzeichnis mit allen Skripten in Farbe oder
im Original Powershell-Design (Blauer Hintergrund und weisse Schrift).
Die SETDPI.exe liegt bei.
Die Farbe "gelb" wurde in den farbigen Skripten selten bis garnicht mehr verwendet.

 

[ThorstenBerlin]

Das Powershellskript kann, wenn es im selben Verzeichnis liegt wie die SETDPI.exe,
jetzt problemlos gestartet werden.
Man braucht die SETDPI.exe nicht mehr in C:\Windows abspeichern.

Ich habe die "SETDPI.exe" aus "C:\Windows" gelöscht und "Normal_USER.zip" auf dem Desktop in den Ordner "COMPUTERINFOS (VON EDV.KLEINI)" entpackt.
Nach Starten der "Check_for_Updates1.ps1" erscheint folgendes:

Nachdem ich "Um fortfahren zu können drücken Sie eine beliebige Taste..." ausgeführt hatte, erschien folgendes:

Auch nachdem ich die "SETDPI.exe" wieder in "C:\Windows" kopiert hatte und nach Starten der "Check_for_Updates1.ps1" erschien erneut Bild 2.

Selbst wenn ich den gesamten Ordner "COMPUTERINFOS (VON EDV.KLEINI)" nach "C:\Windows" kopiere erscheint wieder Bild 2.

Auch der Befehl "powershell.exe set-ExecutionPolicy -ExecutionPolicy Bypass -force" in einer cmd mit Admin-Rechten ändert daran nichts.

Auf den "Folgeseiten" ("Um fortfahren zu können drücken Sie eine beliebige Taste...") ist alles in Ordnung.

 

[skorpion68]

Ich habe die "SETDPI.exe" aus "C:\Windows" gelöscht ...

Das war richtig, denn dort gehört sie nicht hin, siehe Befehl Zeile 9:

$setDpiPath = ".\setdpi.exe"  # Pfad zur setdpi.exe

Die Anwendung SETDPI.exe befindet sich also im Ordner, von wo das Script Check_for_Updates1.ps1 aus gestartet wurde.

Selbst wenn ich den gesamten Ordner "COMPUTERINFOS (VON EDV.KLEINI)" nach "C:\Windows" kopiere erscheint wieder Bild 2.

Was soll dieser Unfug, du hättest nur die Zeile 187 von:

$ipconfigOutputPath = "C:\ipconfiguration.txt"

in ändern müssen, damit das Log im selben Ordner erstellt wird, aus dem das Script Check_for_Updates1.ps1 gestartet wurde:

$ipconfigOutputPath = ".\ipconfiguration.txt"

Übrigens: im Script Check_for_Updates2.ps1 ist es Zeile 216, im Script Check_for_Updates3.ps1 ist es Zeile 185 und im Script Check_for_Updates4.ps1 ist es Zeile 218.

Auch der Befehl "powershell.exe set-ExecutionPolicy -ExecutionPolicy Bypass -force" in einer cmd mit Admin-Rechten ändert daran nichts.

Für das Script Check_for_Updates1.ps1 sind keine administrative Rechte nötig, deshalb wohl auch der Name des Archivs Normal_USER.zip.

 

[edv.kleini]

Hallo

Das Skript wird immer grösser und umfangreicher in dem was jetzt alles erfasst wird.

Endlich ist es mir gelungen auch angeschlossene Navigationsgeräte von den Herstellern
Garmin, JimWey und TomTom zu erfassen.
Unglücklicher weise tauchten die Geräte zwei mal auf.
Es gibt Navigationsgeräte, die aufgrund ihrer Treiberkonfiguration als
Kabelgebundener Ethernet Netzwerkadapter erkannt werden.
Da waren ganz schöne Klimmzüge notwendig um zu verhindern, dass
die Navis als Netzwerkkarte aufgebröselt werden.
Jetzt erscheinen sie mit in der Gruppe der erfassten USB-Scanner, USB Web-Cams und Digitalkameras
eben als Navigationsgeräte.
Bei den farbigen Skripts ist es zumeist so geregelt, dass wenn ein Gerät nicht vorhanden ist,
dass dann als Ausgabetext in roter Fabe erscheint Beispiel "Es wurden keine Web-Cams erkannt."

Wenn noch jemandem was einfällt z.B. ob ein Navi-Hersteller oder sowas fehlt, bitte melden...

@skorpion68
Das ist genau das was ich ja immer gesagt habe und auch immer gewarnt habe, Powershell ist nichst für Laien.
Und solche Pfade anpassen ist nicht jedermanns Sache.

Ich habe gerade nochmal die Skriptdateien entsprechend angepasst, und getestet ohne setdpi.exe
im Windows Verzeichnis und oder D:\Programme\batch Verzeichnis.
Ausserdem wurde der Pfad auf $ipconfigOutputPath = ".\ipconfiguration.txt" umgestellt..

Wie Du schon richtig erwähnt hattest. Damit sollte das Skript jetzt fehlerfrei funktionieren.
Und zwar auch bei den Leuten, die nicht die gleiche Umgebung auf dem Computer haben, wie ich.

Des Weiteren habe ich eine Datei Namen mit Powershell_Bypass.bat erstellt und mit in das Zip-Paket getan.
Diese Datei muss vor dem allerersten Aufruf von Powershell einmalig mit administrativen Rechten ausgeführt werden.
So wird sichergestellt, dass Powershellskripte auch ausgeführt werden dürfen!
@ThorstenBerlin Ich entschuldige mich für die Unannehmlichkeiten!

23.59 h nochmals überarbeitet dank KI

 

[g-force]

@edv.kleini
Ich habe dein Script jetzt noch nicht getestet, aber lese fleissig mit.
Das mit den Pfaden solltest Du doch über eine Variable lösen können. PS kann doch ermitteln, aus welchem Pfad es ausgeführt wurde - dies als Variable mit Unterpfad zu "Tools" oder "EXE" sollte die ganze Geschichte doch variabel machen - egal, wo es liegt?

 

[ThorstenBerlin]

@edv.kleini
Ich habe auf meinem Laptop folgende Schritte durchgeführt:

1. im Ordner "C:\Windows" die "SetDpi.exe" gelöscht (war noch vorhanden)
2. den Ordner "COMPUTERINFOS (VON EDV.KLEINI)" unter "Dokumente" komplett gelöscht
3. die Datei "For_Normal_Users.zip" aus Deinem Post #65 heruntergeladen
4. unter "Dokumente" einen neuen Ordner "COMPUTERINFOS (VON EDV.KLEINI)" angelegt und die Datei "For_Normal_Users.zip" dorthin entpackt
5. die "Powershell_Bypass.bat" wie angegeben im Ordner unter Nr. "4" erstmalig gestartet
6. die "Check_for_Updates1.ps1" im Ordner unter Nr. "4" mit rechter Maustaste ("Mit Powershell öffnen") gestartet
7. funktioniert bei mir einwandfrei, auch nach einem Neustart des Laptops (jedenfalls bei mir).

Vielen Dank für Deine Mühe.

 

[edv.kleini]

Scheibenkleister
Ein kleiner Fehler war doch noch drin in den farbigen Skripten!
in der Zeile 987 heisst es "-foregroundcolor -darkred"
es muss heissen "-foregroundcolor darkred" Vor der Farbe darkred darf kein "-" Zeichen sein!
Aber bei knapp 70.000 Byte kann sowas schonmal passieren.
Ich bin auch nur ein Mensch........

Edited bei mich um 6.18. Uhr

Es gibt mal wieder ein paar Verschönerungen.
Diesmal sind es keine Fehler, sondern das Ganze ist echt nur Kosmetik.
Es kann vorkommen, dass in einem ausgewerteten Namen einer CPU
zwischen den einzelen Bezeichnungsfragmenten mehr als ein Leerzeichen ist.
Das finde ich sieht schäbig aus.
Der Trimbefehl in den Zeilen hat auch diesmal ohne CHAT GPT ( KI ) geklappt.
Nun sieht der Text vernünfitg aus.
Auch Chat GPT sagte mir, dass es unmöglich sei den Code-Namen
einer CPU, wie , was weiss ich Comet-Lake, Coffee-Lake, Yorkfield oder Wolfdale
direkt in Powershell zu ermitteln. Schade eigentlich...

 

[edv.kleini]

So
Ich habe die Skripte noch mal angefasst.
Alles nur Kosmetik.
Ich habe eine weitere Logik verbaut, die verhindern soll, dass das Skript abstürzt.
Dies betrifft die setdpi.exe. Wird diese nicht gefunden, wird in einer normalen
Skriptzeile mit rotem Text angezeigt:
"Monitordaten konnten nicht erfasst werden, da die Datei setdpi.exe fehlt."
Die Ablauf des Skripts wird also nicht mehr unterbrochen.
Wer eines der farbigen Skripte mit einem Editor öffnet,
der bekommt ganz zu Anfang kleine Erläuterungen angezeigt.
Welche Text-Farbe wurde wofür ausgewählt.
Die Filter für Scanner, Digital-Kameras, Web-Cams und Navigationsgeräte wurden angepasst.
Die Gruppe der Treiber enthält jetzt eine einzelne Gruppe für Treiberhersteller,
deren Name mit dem Buchstaben I beginnt.
Damit sollte gewährleistet sein, dass die Gruppe groß genug ist.
Intel basierte Mainboards und CPUs sowie einige Intel Grakas sind ja wohl
m. E. am weitesten verbreitet.
Es wurde ein kleines und bebildertes Word-Dokument erstellt, in dem die
Vorgehensweise erklärt wird, wie man die Grundvoraussetzung dafür schafft,
dass die Powershellskripte ohne Probleme ausgeführt werden können.

LG

edv.kleini

Euch allen einen schönen Feiertag und hoffentlich ein langes WE.

 

[ThorstenBerlin]

@edv.kleini
Auch Dir auch einen schönen Feiertag.
Ich habe mir erlaubt, Dein "Powershell-Skripte_ausführen.docx" für mich etwas anzupassen (Rechtschreibfehler beseitigt und Schriftart auf "Times New Roman (12)" umgestellt.
Ansonsten habe ich die Zip-Datei in (bei mir) "Dokumente - COMPUTERINFOS (VON EDV.KLEINI)" entpackt.
Es funktioniert bei mir alles einwandfrei.
Ist nur eine Idee von mir (falls es nicht zu aufwendig ist): Wäre es möglich, die Seriennnummer bzw. -nummern des(r) installierten Programms(e) mit anzeigen zu lassen?
Nochmals vielen Dank für Deine Mühe, die Du Dir machst.

 

[edv.kleini]

Es scheint so als sei es vollbracht.
Folgendes hat mich noch genervt.
Die Netzwerkkonfiguration jedes Computers ist anders.
Der eine hat nur eine kabelgebundene Netzwerkkarte. Ein anderer hat nur W-LAN.
Der nächste hat VMWare drauf (dann gibt es noch zwei weitere Netzwerkkarten zusätzlich VMNet1 und VMNet8)
Der nächste Computer hat noch Bluetooth oder ein weiterer Computer hat ein Navigationsgerät über USB angeschlossen.
Dieses Navigationsgerät wird in vielen Fällen dann zusätzlich auch als Netzwerk-Adapter erkannt.
Bei anderen Navigationsgeräten kann es sein, dass es als externer Datenträger erkannt wird.
Auch beide Varianten (Netzwerk-Adapter und externer Datenträger) in einem Navigationsgerät sind möglich.
Das Problem war die komplette Auswertung aller Adapter unter einen Hut zu bekommen.
Ich wollte es so haben, dass für jeden Adapter eine eigene Seite aufgemacht wird
und dort in einer detaillierten Tabelle alle möglichen Werte angezeigt werden.
Und jetz kommt der Clou.
Werden alle Netzwerk-Adapter deaktiviert
und es ist kein Navigationsgerät über USB angeschlossen, bleibt eine Information dennoch erhalten...
und das ist die Windows IP-Konfiguration des Computers mit diesen Infos:
Hostname
Primäres DNS-Suffix
Knotentyp
IP-Routing aktiviert
Wins-Proxy aktiviert
In einem roten Text steht dann "Es wurden keine aktivierten Netzwerk-Adapter gefunden."
Schaltet man die Netzwerk-Adapter ein, klar, dann läuft es normal wie vorgesehen.

LG

edv.kleini

@ThorstenBerlin
Seriennummern erfassen.
upps da muss ich die nächsten Tage mal schauen was die KI so hergibt
Ich glaube aber eher nicht, dass das geht, die sind zumeist verschlüsselt und nicht immer
in der Regsitry eingetragen, sondern stehen irgendwo im Benutzerprofil.
Und das dann für zig. Millionen Programme, die es so weltweit gibt, rauszuklamüsern...
Echt havy duty....Schwerstarbeit bis in Jahr 2999 LOL...

Der Text im Word-Dokument wurde angepasst und korrigiert.
Die Schrift ist jetzt Times New Roman 12 wie gewünscht.
räschtshreypunk war noch nie meine Stärke.
Rechtschreibfehler sind immer Eigentum von mich...
Ähm, wie war das noch mit der Grammatik?
Setzen .... sechs ............durchgefallen.......

 

[ThorstenBerlin]

Seriennummern erfassen.
upps da muss ich die nächsten Tage mal schauen was die KI so hergibt
Ich glaube aber eher nicht, dass das geht, die sind zumeist verschlüsselt und nicht immer
in der Regsitry eingetragen, sondern stehen irgendwo im Benutzerprofil.
Und das dann für zig. Millionen Programme, die es so weltweit gibt, rauszuklamüsern...
Echt havy duty....Schwerstarbeit bis in Jahr 2999 LOL...

Das war nur ein Vorschlag eines Bekannten von mir, dem ich "For_Normal_Users.zip" gezeigt habe.
Ich vermute, dass dieser Vorschlag sehr schwer umzusetzen ist, ich will Dich damit nicht unter Druck setzen.
Den Vorschlag finde ich trotzdem irgendwie interessant.

(In eigener Sache: Ich bin ab morgen bis einschließlich 11.10.2024 in Bochum und habe keinen Zugriff auf einen Computer.)

Ich wünsche Dir ein schönes Wochenende.

 

[edv.kleini]

Lade Dir bitte nochmal die For_Normal_Users.zip aus Beitrag 71 herunter.
Ich habe da noch etwas entdeckt.
Bei vielen Mainboards kann die Seriennummer ja nicht richtig erfasst werden.
Die Logik dafür habe ich gerade noch mal angepasst----Auch ohne KI zu nutzen
klappt sowas jetzt mittlerweile ganz gut. Aber ehrlich ich stecke noch in den
Anfängen was Powershell anbetrifft...
LG
edv.kleini....................

Von wegen Seriennummern erfassen und so.
Interessant ist das allemale, aber es war schon verdammt schwer von MS-Dot Net Framework
die verschiedenen Versionen zu erfassen und beim Office Paket die Buildnummer rauszubröseln!

 

[ThorstenBerlin]

Lade Dir bitte nochmal die For_Normal_Users.zip aus Beitrag 71 herunter.
Ich habe da noch etwas entdeckt.
Bei vielen Mainboards kann die Seriennummer ja nicht richtig erfasst werden.
Die Logik dafür habe ich gerade noch mal angepasst

Ich habe die Zip-Datei erneut heruntergeladen, entpackt und getestet, bei mir wird die Seriennummer des Mainboards angezeigt (siehe Screenshot):

Ich habe nochmals "mit Speccy" verglichen, die Angaben stimmen, jedoch wird mir bei "Speccy" KEINE Seriennummer des Mainboards angezeigt:

BIOS ist aktuell, eine neuere Version ist noch nicht von HP veröffentlicht worden.

Nochmals danke für Deine Bemühungen.

 

[edv.kleini]

Hallo Thorsten, klasse dass Du so eifrig mittestest.
Mit den Seriennummern ist das so eine Sache....
Bei mir wird bei vielen Mainboards "Default String" oder "System Serial Number" angezeigt.
Aber eben keine richtige Nummer.
Wenn eine "richtige Nummer" vorhanden ist, dann steht die z.B. bei meinen Computern auch so im BIOS.
Aber ob das eine BIOS-Seriennummer, Chipsatzseriennummer oder Mainboardseriennummer ist,
lässt sich nicht immer genau sagen!
Die Befehle in Powershell sind diesbezüglich leider auch nur zweideutig.
$biosDate = $biosInfo.ReleaseDate ist ja noch eindeutig. Von wann ist das BIOS.
$biosSeriennummer = $biosInfo.SerialNumber ..... Aber hier?
Hast Du mal CPU-Z bzw. CPU-ID probiert....
Mit den Netzwerk-Adaptern habe ich noch mal was verändert, ist aber nur Kosmetik...
Des Weiteren habe ich die Ausgaben für das BIOS jetzt so abgeändert, dass da steht
BIOS-Seriennummer ... wenn richtige Nummer, dann wird die auch gezeigt.


Wenn irgendwas mit "Default" oder "System Ser" drinne steht, dann wird ein teilweise roter Text ausgegeben

Hinweis: Die BIOS-Seriennummer des Mainboards konnte nicht erfasst werden.
Ich glaube damit kann man leben!

Es ist alles etwas schwierig mit Powershell. Es kann eben doch nicht alles 100%ig genau erfasst werden.

Nochmals überarbeitet um 22.18. Uhr

 

[ThorstenBerlin]

Ich habe eben die ZIP-Datei erneut heruntergeladen und getestet.
Bei mir wird die Seriennummer angezeigt:

Bei CPU-Z wird KEINE Seriennummer angezeigt:

Ansonsten stimmen die Daten überein.

So, für mich ist "Schicht im Schacht", ich muss um 5 Uhr aufstehen (um 8 Uhr fährt mein Zug).

 

[edv.kleini]

Ich krich noch mal ´ne Krise

Echt Hilfe zur Selbsthilfe...
Chat GPT oder KI (Knubbelige Intelligenz) genannt,
hat wohl nicht so ganz verstanden was ich wollte.
Es ging mir bei den Netzwerk-Adaptern in einem Computer um Folgendes:
Wenn Netzwerk-Adpater in einem Computer verbaut sind, dann soll
Powershell die mir auch anzeigen, wenn sie mit keinem Router,
DHCP-Server oder Switch verbunden sind.
Was mach die KI, sie legt einfach fest
wenn Adapterinfo = IPv4

also

$activeAdapters = $adapterInfo | Where-Object { $_.Info -match "IPv4-Adresse" }
dann wird mir nur ein Netzwerk-Adapter angezeigt wenn er mit einem Router,
DHCP-Server oder Switch verbunden ist.
Da habe ich aber nichts von.
Dann kam ich selbst auf die Idee zu sagen
$activeAdapters = $adapterInfo | Where-Object { $_.Info -match "getrennt" }
und zack Ruhe war´s... Alle Netzwerkadapter werden seitenweise angezeigt.
Deaktiviert man im Gerätemanager einen oder alle vorhandenen Netzwerk-Adapter, dann passiert Folgendes:
Der einzelne deaktivierte Netzwerk-Adapter wird nicht mehr angezeigt. Das ist klar.
Handelt es sich aber um den WLAN Adapter oder um den Bluetooth Adapter, der deaktiviert wurde,
so werden auch die dazugehörigen Adapter aus dieser Gruppe nicht mehr angezeigt.
Was ja auch logisch ist, wenn das Hauptgerät deaktiviert wird.
Deaktiviert man alle Netzwerk-Adapter, habe ich in Powershell
einen Text eingefügt, der dann sagt:
"Es wurden keine aktivierten bzw. angeschlossenen oder verbundenen Netzwerk-Adapter erkannt."
Bei den farbigen Powershellskripten ist der Text dunkelrot!
Mann, mann, mann was für eine Sucherei....

Jetzt habe ich noch was hinzugefügt. 12.19 h
Es wird nun die Anzahl aktiver Netzwerkadapter angezeigt.
Das kann dann von Nutzen sein, wenn man mehrere WiFi, Bluetooth oder WLAN Adapter hat.
Mit dem Blauzahn habe ich zwischen meinen beiden Notebooks mal ein paar Dateien
hin und her geschoben. Was für ein Aufwand... da bisse mit´m Netzwerk schneller.
Bilder dazu liegen bei! Aberwitzig der Blauzahn...

 

[edv.kleini]

Die Logik in Powershell für die Netzwerk-Adapter macht mich noch vollkommen kirre...
Ich musste eine Zeile abändern:
von

$activeAdapters = $adapterInfo | Where-Object { $_.Info -match "getrennt" }

nach

$activeAdapters = $adapterInfo | Where-Object { $_.Info -match "getrennt" -or $anzahladapternw -match "ein" }

Damit aktive und der eine verbundene aktive Netzwerk-Adapter angezeigt werden.
Nur getrennt reicht nicht aus.
Oh mann wie kompliziert ist das denn?

Schonmal vorweg ein Dankeschön an die Jenigen, die so geduldig mit mir sind!

 

[g-force]

Ich mache das in einem eigenen PS-Script mit "$adapters = Get-NetAdapter"
Ich weiß jetzt aber nicht, ob das deine Zwecke erfüllt.

 

[ThorstenBerlin]

@edv.kleini
Ich komme erst nächsten Samstag an mein Laptop, sitze gerade im ICE nach Bochum.
Nochmals vielen Dank für Deine Mühen.