12
Treiber erst beim Login laden statt beim Booten?
Hallo zusammen,
wir haben auf Arbeit ein Gerät, das per USB an Windows-Endgeräte angeschlossen wird und das sich als Netzwerkgerät ins System hängt. Es nutzt Inbox-Treiber und ist im Gerätemanager als virtueller Adapter namens "Remote NDIS Compatible Device" aufgelistet. Das funktionierte bislang auch alles gut, mehrere Jahre lang.
Aktuell macht das Gerät aber Probleme: nach einer Netz-Änderung stört dieser NDIS-Adapter jetzt beim Booten die physikalische NIC und behindert scheinbar das korrekte Ziehen der DHCP-Lease, so daß der Bootvorgang mehrere Minuten dauert. Der genaue Grund dafür ist mir nicht bekannt und ein Call beim Hersteller ist schon eröffnet, ich möchte nur bis zur Lösung einen Workaround schaffen.
Ich hatte die Idee, das Device über Powershell (Disable-PnpDevice) beim Herunterfahren zu deaktivieren und beim Login des Users wieder zu re-aktivieren. Die Scripts habe ich jeweils als Startup- und Shutdown-Script in der lokalen Policy über gpedit.msc eingehängt und sie befinden sich auch im Ordner, in dem die lokale Policy sie erwartet. Das Shutdown-Script schickt aber den Shutdown-Vorgang in einen Endlos-Loop, der erst dann beendet wird, wenn man das System hart ausschaltet oder es hart per Remote-Shutdown beendet.
Jetzt meine Frage ==> kann man das Laden / die Zuordnung des PnP-Treibers beim Bootvorgang verhindern oder verzögern? Also quasi für das Device / den Treiber die Startart ändern von System auf Manual, so wie man das bei einem Dienst machen würde? Oder ist das bei einem Gerät, das per USB-PnP den Treiber zugewiesen bekommt nicht möglich?
Kennt einer diese oder ähnliche Störungen? Bin ich mit den genannten Ansätzen überhaupt auf dem richtigen oder eher auf dem Holz-Weg oder hat jemand hierzu eine schlaue Idee oder kann mich zumindest in die richtige Richtung deuen? Wäre sehr nett!
Danke im Voraus und liebe Grüße,
Fritz
wir haben auf Arbeit ein Gerät, das per USB an Windows-Endgeräte angeschlossen wird und das sich als Netzwerkgerät ins System hängt. Es nutzt Inbox-Treiber und ist im Gerätemanager als virtueller Adapter namens "Remote NDIS Compatible Device" aufgelistet. Das funktionierte bislang auch alles gut, mehrere Jahre lang.
Aktuell macht das Gerät aber Probleme: nach einer Netz-Änderung stört dieser NDIS-Adapter jetzt beim Booten die physikalische NIC und behindert scheinbar das korrekte Ziehen der DHCP-Lease, so daß der Bootvorgang mehrere Minuten dauert. Der genaue Grund dafür ist mir nicht bekannt und ein Call beim Hersteller ist schon eröffnet, ich möchte nur bis zur Lösung einen Workaround schaffen.
Ich hatte die Idee, das Device über Powershell (Disable-PnpDevice) beim Herunterfahren zu deaktivieren und beim Login des Users wieder zu re-aktivieren. Die Scripts habe ich jeweils als Startup- und Shutdown-Script in der lokalen Policy über gpedit.msc eingehängt und sie befinden sich auch im Ordner, in dem die lokale Policy sie erwartet. Das Shutdown-Script schickt aber den Shutdown-Vorgang in einen Endlos-Loop, der erst dann beendet wird, wenn man das System hart ausschaltet oder es hart per Remote-Shutdown beendet.
Jetzt meine Frage ==> kann man das Laden / die Zuordnung des PnP-Treibers beim Bootvorgang verhindern oder verzögern? Also quasi für das Device / den Treiber die Startart ändern von System auf Manual, so wie man das bei einem Dienst machen würde? Oder ist das bei einem Gerät, das per USB-PnP den Treiber zugewiesen bekommt nicht möglich?
Kennt einer diese oder ähnliche Störungen? Bin ich mit den genannten Ansätzen überhaupt auf dem richtigen oder eher auf dem Holz-Weg oder hat jemand hierzu eine schlaue Idee oder kann mich zumindest in die richtige Richtung deuen? Wäre sehr nett!
Danke im Voraus und liebe Grüße,
Fritz
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 53218989288
Url: https://administrator.de/contentid/53218989288
Ausgedruckt am: 06.10.2024 um 05:10 Uhr
12 Kommentare
Neuester Kommentar
Hi
Nein, du kannst das Laden beim Booten nicht verhindern ...
Aber du kannst über die Abhängigkeiten die Reihenfolge steuern ..
Nein, du kannst das Laden beim Booten nicht verhindern ...
Aber du kannst über die Abhängigkeiten die Reihenfolge steuern ..
1
@MirkoKR
Hi,
danke erstmal! Kannst Du mir vielleicht sagen, wo bzw. mit was ich diese Dependencies setzen kann und welche Dependency Du nehmen würdest, damit der Treiber erst nach dem Login zugewiesen wird?
Danke und viele Grüße
Fritz
---
Was ich schon versucht habe:
Sieht aus, als würde es funktionieren, aber beim Booten setzt das System den Wert zurück auf System..
Hi,
danke erstmal! Kannst Du mir vielleicht sagen, wo bzw. mit was ich diese Dependencies setzen kann und welche Dependency Du nehmen würdest, damit der Treiber erst nach dem Login zugewiesen wird?
Danke und viele Grüße
Fritz
---
Was ich schon versucht habe:
$wmi = gwmi -ClassName Win32_SystemDriver | Where-Object { $_.Name -match 'Remote NDIS Compatible Driver' }
$wmi.ChangeStartMode('Manual')
$wmi.StartMode
Output: "Manual" Sieht aus, als würde es funktionieren, aber beim Booten setzt das System den Wert zurück auf System..
Hi
du kannst auch die Priorität der Netzwerkkarte/Verbindung ändern.
Setzt deiner Lokalen Lankarte einen anderen Wert zu als dem NDIS-Adapter und des Problem sollte weg sein.
Reihenfolge der Netzwerkverbindungen festlegen bei Windows 10
Erläuterung des Features "Automatische Metrik" für IPv4-Routen
du kannst auch die Priorität der Netzwerkkarte/Verbindung ändern.
Setzt deiner Lokalen Lankarte einen anderen Wert zu als dem NDIS-Adapter und des Problem sollte weg sein.
Reihenfolge der Netzwerkverbindungen festlegen bei Windows 10
Erläuterung des Features "Automatische Metrik" für IPv4-Routen
1
@kaiand1
Mensch na klar, die Metrik - stimmt, da war doch noch was. Ich hatte mich auf PnP-Devices und das Ladeverhalten generell versteift, aber stimmt, bei Netzwerkadaptern kann man die Priorität ja darüber steuern. Das liest sich vielversprechend.
Ok, ich versuche das morgen früh direkt (ich hoffe, die Maschine, die sie mir zum Testen genannt haben, ist noch nicht wieder vom User in Beschlag genommen worden) und gebe Euch anschließend Rückmeldung.
Danke und viele Grüße
Fritz
Mensch na klar, die Metrik - stimmt, da war doch noch was. Ich hatte mich auf PnP-Devices und das Ladeverhalten generell versteift, aber stimmt, bei Netzwerkadaptern kann man die Priorität ja darüber steuern. Das liest sich vielversprechend.
Ok, ich versuche das morgen früh direkt (ich hoffe, die Maschine, die sie mir zum Testen genannt haben, ist noch nicht wieder vom User in Beschlag genommen worden) und gebe Euch anschließend Rückmeldung.
Danke und viele Grüße
Fritz
oder die hardware generell deaktivieren wenn man sie nicht benötigt?
https://learn.microsoft.com/en-us/powershell/module/pnpdevice/disable-pn ...
oder eben deaktivieren und nach 5 minuten wieder aktivieren... oder sowas....
oder per shutdownscript deaktivieren und beim hochfahren erst nach paar minuten wieder aktivieren.
https://learn.microsoft.com/en-us/powershell/module/pnpdevice/disable-pn ...
oder eben deaktivieren und nach 5 minuten wieder aktivieren... oder sowas....
oder per shutdownscript deaktivieren und beim hochfahren erst nach paar minuten wieder aktivieren.
@ThePinky777
Habe ich auch schon versucht, siehe mein Original-Post
Habe ich auch schon versucht, siehe mein Original-Post
Ich hatte die Idee, das Device über Powershell (Disable-PnpDevice)
beim Herunterfahren zu deaktivieren und beim Login des Users wieder zu
re-aktivieren. [...] Shutdown-Script schickt aber den Shutdown-Vorgang in
einen Endlos-Loop, der erst dann beendet wird, wenn man das System hart
ausschaltet oder es hart per Remote-Shutdown beendet.
beim Herunterfahren zu deaktivieren und beim Login des Users wieder zu
re-aktivieren. [...] Shutdown-Script schickt aber den Shutdown-Vorgang in
einen Endlos-Loop, der erst dann beendet wird, wenn man das System hart
ausschaltet oder es hart per Remote-Shutdown beendet.
@kaiand1
Es sah zuerst gut aus, aber lt. unseren Netzwerkadministratoren tritt das Problem vor Ort trotz geänderter Metrik auf.
Wobei die Aussagen ein bißchen widersprüchlich daher kommen - angeblich sind alle Maschinen betroffen, die das Gerät angeschlossen haben, ich konnte aber heute verifizieren, daß drei von vier Maschinen trotz Remote-NDIS-Adapter sauber booten, nur eine erhält keine Lease. Und das Ganze tritt auch erst seit einer Änderung der Netzwerkkomponenten auf, vorher liefen die Rechner mit derselben Config über Jahre hinweg tadellos. Things that make you go 'hmm'.
Es sah zuerst gut aus, aber lt. unseren Netzwerkadministratoren tritt das Problem vor Ort trotz geänderter Metrik auf.
Wobei die Aussagen ein bißchen widersprüchlich daher kommen - angeblich sind alle Maschinen betroffen, die das Gerät angeschlossen haben, ich konnte aber heute verifizieren, daß drei von vier Maschinen trotz Remote-NDIS-Adapter sauber booten, nur eine erhält keine Lease. Und das Ganze tritt auch erst seit einer Änderung der Netzwerkkomponenten auf, vorher liefen die Rechner mit derselben Config über Jahre hinweg tadellos. Things that make you go 'hmm'.
Hi, ich hab neue Infos: die Umstellung soll erst noch erfolgen, das Problem wurde beim Vorab-Test festgestellt, es sind also "alle Maschinen, die umgestellt werden", also stimmt die Aussage grundsätzlich.
Neuer Ansatz: ich habe ein Binary erstellt, das quasi ein ipconfig /release durchführt, eine Sekunde wartet und dann ein ipconfig /renew hinterherschießt (dieses Vorgehen beseitigt lt. Aussage der Kollegen den Fehler). Das klappt auch sauber bei manueller Ausführung, nur habe ich erneut das Problem, das ich sie nicht sauber in den Bootvorgang eingehängt kriege. Erstelle ich mit dem Scheduler einen AT-Job und wähle "Beim Systemstart" als Trigger, dann wird der Job komplett ignoriert und nicht ausgeführt, egal, welche Accounts / Rechte ich ihm verpasse.
=> Wisst Ihr als allwissender Schwarm vielleicht, wie ich die EXE bei jedem Neustart gestartet kriege? (sie benötigt elevated rights für das ipconfig /release, ist im Configfile aber gesetzt, das Binary ist signiert und funktioniert bei manuellem Start des Scheduler-Jobs oder in einer Adminshell problemlos)
Möglicherweise über Runkeys?
Danke und viele Grüße,
Fritz
Neuer Ansatz: ich habe ein Binary erstellt, das quasi ein ipconfig /release durchführt, eine Sekunde wartet und dann ein ipconfig /renew hinterherschießt (dieses Vorgehen beseitigt lt. Aussage der Kollegen den Fehler). Das klappt auch sauber bei manueller Ausführung, nur habe ich erneut das Problem, das ich sie nicht sauber in den Bootvorgang eingehängt kriege. Erstelle ich mit dem Scheduler einen AT-Job und wähle "Beim Systemstart" als Trigger, dann wird der Job komplett ignoriert und nicht ausgeführt, egal, welche Accounts / Rechte ich ihm verpasse.
=> Wisst Ihr als allwissender Schwarm vielleicht, wie ich die EXE bei jedem Neustart gestartet kriege? (sie benötigt elevated rights für das ipconfig /release, ist im Configfile aber gesetzt, das Binary ist signiert und funktioniert bei manuellem Start des Scheduler-Jobs oder in einer Adminshell problemlos)
Möglicherweise über Runkeys?
Danke und viele Grüße,
Fritz
Ok, Runkeys sind für Logins. Der einzige Weg, zwischen Bootprozess und Login etwas zu starten. ist ein Dienst... 🤢
Hi,
falls noch jemand mitliest - ich habe das dann mal als Dienst programmiert, läuft zumindest im Test auf meiner Maschine und einer weiteren einwandfrei. Der Dienst startet nach dem Bootvorgang an, führt ein ipconfig /renew durch und beendet sich sauber.
Morgen dann Funktionstest in der Produktion, bin gespannt.
VG, Fritz
falls noch jemand mitliest - ich habe das dann mal als Dienst programmiert, läuft zumindest im Test auf meiner Maschine und einer weiteren einwandfrei. Der Dienst startet nach dem Bootvorgang an, führt ein ipconfig /renew durch und beendet sich sauber.
Morgen dann Funktionstest in der Produktion, bin gespannt.
VG, Fritz
Parallel dazu hat der Hersteller jetzt Lösungsvorschläge geliefert:
1. Ändern der Metrik, hatten wir ja schon getan
2. das Gerät stattdessen als Smartcardreader einbinden, der Netzwerkadapter fällt dann weg
Wir testen ab morgen Lösungsansatz 2, wir werden sehen.
VG, Fritz
1. Ändern der Metrik, hatten wir ja schon getan
2. das Gerät stattdessen als Smartcardreader einbinden, der Netzwerkadapter fällt dann weg
Wir testen ab morgen Lösungsansatz 2, wir werden sehen.
VG, Fritz
Lösung 2 mit der Einbindung als Smartcardreader funktioniert.
