[Sturmovik]

Ach mittlerweile reicht doch ein Anonymer Hinweis auf nen Terroranschlag und unsere Behörden schalten in den "Wir werden alle störben!!1!!einself!" Modus.

Diese Hysterie kotzt mich fast so an wie die wahnsinnig aussagekräftigen Fehlermeldungen in Windows

Powershell sagte:

Eine Schnittstelle dieses Namens wurde noch nicht f�r den Router registriert.

Dieser Beitrag wurde von Sturmovik bearbeitet: 15. Februar 2015 - 12:56

[DK2000]

In der Fehlermeldung fehlt ein 'ü'. Dann wird sie verständlicher.

Mir geht der Kuchen so langsam alle. Mal noch ein Stück für morgen früh aufheben.

Moin Sturmi.

[Sturmovik]

Das interessante ist, dass dieser netsh-Befehl in der CMD-Shell bestens funktioniert, in der Admin-Powershell auch, aber als User wirft er diese bescheuerte Meldung

Get-Credentials hilft auch nicht

[Urne]

Zitat

Mir geht der Kuchen so langsam alle. Mal noch ein Stück für morgen früh aufheben.

Meiner ist auch gerade zu Ende gegangen. Zwei Nachfolger Kuchen stehen aber schon bereit.
Moin

[DK2000]

@Sturmovik:


Weil die PowerShell als 'User' das Interface nicht sieht. Das ist das selbe Problem wie mit Shares oder Laufwerken, welche man als 'Admin' anlegt. Der User bekommt sie auch nicht zu sehen, außer man startet einen neuen Explorer als Admin.

Theoretisch müsste es gehen, wenn Du Den Umweg über New-PSSession gehst, eine neue Shell als Administrator öffnest und in dieser dann das Ganze ausführst.

Zitat (Urne: 15. Februar 2015 - 13:47)

Zwei Nachfolger Kuchen stehen aber schon bereit.

Bei mir steht nichts, auch nicht bereit.

[Sturmovik]

Der netsh-Befehl war eh nur ein kruder Workaround ums eigentliche Problem:

Ich hol mir den VirtualBox-Netzwerkadapter über ne WMI-Abfrage und lese den Status aus:

$wmi = Get-WmiObject -Class Win32_NetworkAdapter | Where-Object {$_.ServiceName -eq $name}
$state=$wmi.NetConnectionStatus

Wenn das Ding aus ist, solls eingeschaltet werden und andersrum.
Leider hat $wmi.Enable() bzw $wmi.Disable() in der Powershell ISE nicht funktioniert.
Wie ich grade sehe funktioniert das aber prima, wenn ich das Script aus ner Administrativen PS ausführe.

Ich taste mich mal an deinen Workaround ran...

[Urne]

Zitat

Bei mir steht nichts,

Nichtmal die Haare zu Berge?

[DK2000]

Zitat (Urne: 15. Februar 2015 - 13:59)

Nichtmal die Haare zu Berge?

Na, die stehen immer.

[Sturmovik]

Zitat (DK2000: 15. Februar 2015 - 13:53)

Theoretisch müsste es gehen, wenn Du Den Umweg über New-PSSession gehst, eine neue Shell als Administrator öffnest und in dieser dann das Ganze ausführst.

An der Stelle steh ich total im Wald...
da mich jetzt akute Themenspezifische Bocklosigkeit befallen hat, löse ich das temporär mit ner Verknüfung die ich eben als Admin ausführe... :/
Mal sehn ob das mit Win8.1 einfacher geht, da gibts ja spezielle Cmdlets für den Spaß, die MS leider den Win7 Usern vorenthält.

Und wenn ich mal Zeit dafür hab, also ca. September 2018, setz ich den Karren hier mit Win8 neu auf.

Nu erstmal nen Kaffee runterspüln

Dieser Beitrag wurde von Sturmovik bearbeitet: 15. Februar 2015 - 14:41

[DK2000]

Ich habe es gerade mal mit Windows 8.1 versucht und da ging das gar nicht, egal ob Admin oder User. Wenn ich die paar Zeilen von Dir da oben anpasse:

$wmi = Get-WmiObject -Class Win32_NetworkAdapter | Where-Object {$_.ServiceName -eq "RTL8168"}
$state=$wmi.NetConnectionStatus

Dann ist $state immer leer. Darüber erhalte ich überhaupt gar keine nützlichen Informationen mehr über den Status Netzwerkadapter.

---

Ach doch, geht doch. Man sollte den Namen auch richtig schreibe.

Geht auch als User. Jetzt ist $state=2, was für "Connected" steht.

Aber Enable() und Disable() funktionieren hier auch nur, wenn der Script als Admin ausgeführt wird.

Zitat (Sturmovik: 15. Februar 2015 - 14:40)

Mal sehn ob das mit Win8.1 einfacher geht, da gibts ja spezielle Cmdlets für den Spaß, die MS leider den Win7 Usern vorenthält.

Sind die nicht im Update enthalten? Oder ist das kastriert worden?

Aber das würde vermutlich auch nur als Admin laufen.

Get-NetAdapter -Name "VirtualBox*"|Disable-NetAdapter führt als Benutzer zu einem netten "Zugriff verweigert". Als Admin läuft es aber normal.
---

Kaffee ist da eine gute Idee. Und ein paar Keksi.

[Sturmovik]

Leider ist das nicht in PS 4.0 enthalten, das gibts nur für Server2k12 und win8.x
Irgendwie muss man die Leute doch motivieren, auf die Kachelei umzusteigen

Wär ich nicht viel zu faul, die Kiste neu aufzusetzen (was dringend nötig ist, da sich mein Windows7 an manchen Ecken schon etwas seltsam verhält), hätt ich schon längst Win8 drauf.

Naja, noch nen Kaffee und ne Scheibe Kuchen und dann weiter scripten, und zwar in ner Sprache, wo ich wenigstens kapiere was passiert

[DK2000]

Zitat (Sturmovik: 15. Februar 2015 - 16:27)

Leider ist das nicht in PS 4.0 enthalten, das gibts nur für Server2k12 und win8.x

Ach und ich dachte, damit erhält man unter Windows 7 die selbe Umgebung wie bei 8.1. Das ist ja Käse. Wenn man dann unter 8.1 einen Script schreibt, dann läuft der ja am Ende gar nicht unter Windows 7, obwohl beide dann PS 4 haben. Das ist ja selten doof.

[Sturmovik]

Das ist doch selbst innerhalb der gleichen Betriebssystemversion so.
will man zum Bleistift nen 2012er Failovercluster remote über seinen Zustand befragen, dann scheitert das an den fehlenden Powershellmodulen, die man erst nachladen muss.

[DK2000]

Das ist normal. Solange das Modul aber vorhanden ist, ist das ja kein Problem. Nur wenn das Modul komplett fehlt, dann wird das doof. Ich habe das jetzt so verstanden, das in der PS4 für Windows 7 das Modul komplett fehlt.

[RalphS]

Mooo

Richtig was los hier. Mh? Gabs in PS nicht ein Applet, mit dem man den Elevated-Status erreichen konnte? War mir so.