sammy65
Goto Top

Standardgateway bei Clients mit statischer IP Adresse ändern

Hallo miteinander,

Wie kann ich über eine GPO die Standardgateway an meinen Clients ändern?
Ich habe das versucht?:

netsh int ip set address name="Ethernet" gateway=192.168.20.40 gwmetric=1   

Es wird dann auch die Gateway überschrieben, aber auch die IP und das Subnet geändert, das soll aber bleiben, ich möchte lediglich, dass meine clients eine neue Standardgateway erhalten.


lg
Thomas

Content-ID: 463382

Url: https://administrator.de/forum/standardgateway-bei-clients-mit-statischer-ip-adresse-aendern-463382.html

Ausgedruckt am: 23.12.2024 um 13:12 Uhr

Pjordorf
Pjordorf 18.06.2019 um 12:20:51 Uhr
Goto Top
Hallo,

Zitat von @sammy65:
Es wird dann auch die Gateway überschrieben, aber auch die IP und das Subnet geändert, das soll aber bleiben,
Schon mal versucht die IP auch gleichzeitg zu setzen? Habt ihr 2 verschieden Netze aber nur ein Gateway im anderen (nicht IP Netz der Clients)?

Gruß,
Peter
sammy65
sammy65 18.06.2019 um 12:42:42 Uhr
Goto Top
Hi Peter

Nein, nur 1 Netz,
das mit den Festen IP ist historisch gewachsen. Irgendwann werden wir auf DHCP umstellen wollen....

Wichtig ist , dass die bestehende IP und die SubnetMask erhalten bleibt, ich möchte nur die Gateway überschreiben......

Gruß
Thomas
em-pie
em-pie 18.06.2019 um 12:53:12 Uhr
Goto Top
Moin,

ohne konkrete Befehle im Gepäck zu haben. Würde mir als "Workaround" folgendes einfallen:
  • per Script Subnetmask und IP-Adresse ermitteln
  • im Weiteren Script verlauf dann Gateway, die IP-Adresse und Subnetzmaske neu setzen. Die letzteren beiden aus der zuvor ermittelten Abfrage.

Alternative 2:
Nimm die Powershell:
QUELLE für nachfolgendes: https://www.virtualizationhowto.com/2016/09/change-default-gateway-powershell/

#variables
$ipaddress='1.2.3.4'  
$index = get-netipaddress | where-object {$_.IPAddress -eq $ipaddress} | select -ExpandProperty InterfaceIndex
$Log = 'c:\windows\options\gateway\gatewaychange.log'  
$gateway = get-netroute -DestinationPrefix '0.0.0.0/0' | select -ExpandProperty NextHop  
$oldroute = '1.1.1.1'  
$newroute = '2.2.2.2'  
$destination = '0.0.0.0/0'  

#Start Changing the Gateway if needed

Function Swap-Gateway() {

remove-netroute -interfaceindex $index -NextHop $oldroute -confirm:$false
new-netroute -interfaceindex $index -NextHop $newroute -destinationprefix $destination -confirm:$false
sleep 3

}

if ($gateway -eq $oldroute) {
Write-Warning -Message "Gateway is set to $gateway and will be changed to $newroute"  
Swap-Gateway | Out-file $Log -Append

}
elseif ($gateway -eq $newroute) {
Write-Warning -Message "Gateway is already set to $newroute and needs no change"  

}

Zeile 4 und 5 dann auf den ALIAS (="Ethernet") anpassen!?

Gruß
em-pie
sammy65
sammy65 18.06.2019 aktualisiert um 13:25:18 Uhr
Goto Top
Hi,

dankeschön für das Script...
Nur in powerShell bin ich absolut nicht fit.....

du meinst das so?

#variables
$ipaddress='Ethernet'  
$index = get-netipaddress | where-object {$_.IPAddress -eq $ipaddress} | select -ExpandProperty InterfaceIndex

Und wo trage ich die neue Gateway ein?

Es wäre cool wenn du mir helfen könntest, das Script anzupassen.

Meine neue Gateway Adresse ist die 192.168.20.40
die alte 192.168.20.9

Die statischen IP´s, sowie die Gateway Adresse der Clients sollen erhalten bleiben.

lg
Thomas
Exilschwaelmer
Exilschwaelmer 18.06.2019 um 13:58:54 Uhr
Goto Top
Hallo,

wenn es auf allen Client nur eine einzige Netzwerkverbindung / -Adapter gibt, reicht das hier:

$NewGW = '192.168.120.1' # Hier Dein neues Standardgateway eintragen  
$DestPrefix = '0.0.0.0/0'  
$ifindex = Get-NetIPConfiguration |  Select -ExpandProperty Interfaceindex
Remove-NetRoute -InterfaceIndex $ifindex -confirm:$false
New-NetRoute -InterfaceIndex $ifindex -NextHop $NewGW -DestinationPrefix $DestPrefix

Get-NetipConfiguration # Config ausgeben

Wenn's evtl. mehrere Netzwerkverbindungen / -Adapter gibt, aber immer 'Ethernet' genommen werden soll:

$NewGW = '192.168.120.1'  

$IFAlias = 'Ethernet'  

$DestPrefix = '0.0.0.0/0'  
$ifindex = Get-NetIPConfiguration | Where-Object {$_.InterfaceAlias -eq $IFAlias} | Select -ExpandProperty Interfaceindex
Remove-NetRoute -InterfaceIndex $ifindex -confirm:$false
New-NetRoute -InterfaceIndex $ifindex -NextHop $NewGW -DestinationPrefix $DestPrefix
Get-NetipConfiguration
igetyaall
igetyaall 18.06.2019 um 14:16:46 Uhr
Goto Top
Hallo,

bekommen die Clients ihre IP Adresse über einen DHCP Server oder wer vergibt hier die IPs?

Wenn die Clients über den DHCP Server ihre IP bekommen, dann wird dort auch in der Regel das Gateway mitgegeben. Dort kannst du ein neues GW definieren.

Auch wenn das nicht deine Frage war, kann es ja sein das du dir hiermit einfach Arbeit sparst.

VG
brammer
brammer 18.06.2019 um 14:24:28 Uhr
Goto Top
Halloo,

generell mal die Frage, wieso willst du das Gateway ändern?
Neues Gerät?
Da würde ich einen 1 zu 1 Tausch machen....

oder wieso?

brammer
sammy65
sammy65 18.06.2019 um 14:38:05 Uhr
Goto Top
Hi,

Nein.....
Ich ändere die Gateway von der firewall 20.9 auf einen meiner Hauptswitche 20.40 (wegen Ausfallsicherheit)
sammy65
sammy65 18.06.2019 um 14:39:13 Uhr
Goto Top
Diese Clients haben noch statische Adressen , eine umstellung auf DHCP ist erst später geplant.....(hatte ich bereits weiter oben erläutert)
colinardo
colinardo 18.06.2019 aktualisiert um 15:42:00 Uhr
Goto Top
Servus,
Meine neue Gateway Adresse ist die 192.168.20.40
die alte 192.168.20.9
ein Einzeiler reicht dir für den Krams face-smile :
Get-NetRoute -DestinationPrefix 0.0.0.0/0 -NextHop 192.168.20.9 -EA SilentlyContinue | Remove-NetRoute -Confirm:$false -PassThru | New-NetRoute -DestinationPrefix 0.0.0.0/0 -NextHop 192.168.20.40
Alternativ geht auch folgendes was auch unter älteren OS funktioniert
gwmi win32_NetworkadapterConfiguration | ?{$_.DefaultIPGateway -eq '192.168.20.9'} | %{$_.SetGateways('192.168.20.40')}  
Grüße Uwe
brammer
brammer 18.06.2019 um 16:24:11 Uhr
Goto Top
Hallo,

dann ändere den Switch und die Firewall....
5 minuten... fertig

brammer
sammy65
sammy65 19.06.2019 um 07:51:44 Uhr
Goto Top
Zitat von @brammer:

Hallo,

dann ändere den Switch und die Firewall....
5 minuten... fertig

brammer
Da möchte ich jetzt nicht drüber diskutieren... Es hat seine Gründe warum ich das so machen MUSS...
Klar ist das die einfachere Lösung....
sammy65
sammy65 19.06.2019 um 07:58:06 Uhr
Goto Top
Zitat von @Exilschwaelmer:

Hallo,

wenn es auf allen Client nur eine einzige Netzwerkverbindung / -Adapter gibt, reicht das hier:

> $NewGW = '192.168.120.1' # Hier Dein neues Standardgateway eintragen  
> $DestPrefix = '0.0.0.0/0'  
> $ifindex = Get-NetIPConfiguration |  Select -ExpandProperty Interfaceindex
> Remove-NetRoute -InterfaceIndex $ifindex -confirm:$false
> New-NetRoute -InterfaceIndex $ifindex -NextHop $NewGW -DestinationPrefix $DestPrefix
> 
> Get-NetipConfiguration # Config ausgeben
> 

Wenn's evtl. mehrere Netzwerkverbindungen / -Adapter gibt, aber immer 'Ethernet' genommen werden soll:

> $NewGW = '192.168.120.1'  
> 
> $IFAlias = 'Ethernet'  
> 
> $DestPrefix = '0.0.0.0/0'  
> $ifindex = Get-NetIPConfiguration | Where-Object {$_.InterfaceAlias -eq $IFAlias} | Select -ExpandProperty Interfaceindex
> Remove-NetRoute -InterfaceIndex $ifindex -confirm:$false
> New-NetRoute -InterfaceIndex $ifindex -NextHop $NewGW -DestinationPrefix $DestPrefix
> Get-NetipConfiguration
> 
So, das hier funktioniert wenn ich es manuell ausführe.
Get-NetRoute -DestinationPrefix 0.0.0.0/0 -NextHop 192.168.20.9 -EA SilentlyContinue | Remove-NetRoute -Confirm:$false -PassThru | New-NetRoute -DestinationPrefix 0.0.0.0/0 -NextHop 192.168.20.40

Jetzt habe ich das Ganze ich einbe Batch verpackt und möchte es über eine GPO (Beim Starten) ausrollen.
Der Client reagiert aber nicht darauf, das Script wird nicht ausgeführt.....

Manuell klappt es einwandfrei

Die Batch sieht so aus:
C:\Windows\SysWOW64\WindowsPowerShell\v1.0\powershell.exe -ExecutionPolicy Bypass -File \\sab070\Softwareverteilung\Netzwerkverbindungen\standardgateway.ps1

Die Batch liegt auch auch \\SAB070\Softwareverteilung\Netzwerkverbindungen


Andrere Scripts klappen einwandfrei, die liegen am selben Ort.

lg
Thomas
colinardo
colinardo 19.06.2019 aktualisiert um 10:23:07 Uhr
Goto Top
Manchmal frage ich mich wozu die Leute da so ein rundes Ding auf dem Hals haben. Heute beim Frühstück vergessen?

1. Wir leben im 21 Jahrhundert und da muss man Powershell-Skripte nicht mehr umständlich über eine Batch starten, dafür gibt es unter Computerkonfiguration->Windows-Einstellungen->Skripte (Starten/Herunterfahren) eine entsprechende Sektion nur für Powershell-Skripte. Und hier muss man auch nicht die Policy auf Bypass stellen, denn per Policy zugewiesene Skripte laufen immer im Bypass!

2. Sollte dir klar sein das eine Default-Route erst verfügbar wird sobald das Netzwerk auch online ist, ist der Rechner sehr schnell und das Startskript schon vor dem Netzwerk dran ist logisch das das erste CMDLet keine entsprechende Route findet, ergo es geschieht auch nichts, logisch! Dafür gibt es dann entweder die Richtlinie das auf den Netzwerkstack gewartet werden soll, oder man baut sich eine While-Schleife ins Skript ein welche auf das Netzwerk selbst wartet.

3. Muss natürlich sichergestellt sein das der Computeraccount auch Zugriffsrechte auf den Pfad und die Freigabe besitzt.

4. Hätte man sich das ganze auch mit einem Start-Transcript im Skript mal in eine Datei ausgeben lassen können, aber die Arbeit lassen wir mal dem Forum, ne ...
sammy65
sammy65 19.06.2019 aktualisiert um 09:07:47 Uhr
Goto Top
Zitat von @colinardo:

Manchmal frage ich mich wozu die Leute da so ein rundes Ding auf dem Hals haben. Heute beim Frühstück vergessen?

1. Wir leben im 21 Jahrhundert und da muss man Powershell-Skripte nicht mehr umständlich über eine Batch starten, dafür gibt es unter Computerkonfiguration->Windows-Einstellungen->Skripte (Starten/Herunterfahren) eine entsprechende Sektion nur für Powershell-Skripte. Und hier muss man auch nicht die Policy auf Bypass stellen, denn per Policy zugewiesene Skripte laufen immer im Bypass!

2. Sollte dir klar sein das eine Default-Route erst verfügbar wird sobald das Netzwerk auch online ist, ist der Rechner sehr schnell und das Startskript schon vor dem Netzwerk dran ist logisch das das erste CMDLet keine entsprechende Route findet, ergo es geschieht auch nichts, logisch! Dafür gibt es dann entweder die Richtlinie das auf den Netzwerkstack gewartet werden soll, oder man baut sich eine While-Schleife ins Skript ein welche auf das Netzwerk selbst wartet.

3. Muss natürlich sichergestellt sein das der Computeraccount auch Zugriffsrechte auf den Pfad und die Freigabe besitzt.

4. Hätte man sich das ganze auch mit einem Start-Transkript im Skript mal in eine Datei ausgeben lassen können, aber die Arbeit lassen wir mal dem Forum, ne ...


Also, das runde Ding hab ich nicht vergessen..... (bin nur ratlos, deswegen frage ich hier) und Danke für deine doch so freundlichen Antworten....

zu 1. Das hab ich versucht, hatte aber auch nicht geklappt, ich habe es unter "Stareten als PowerShell Script hinterlegt, ddesshalt hab ich es so und so versucht

zu 2. Die Gruppenrichtlinie für die Deaktivierung des Schnellstarts ist aktiv und funktioniert. Der ensprechende Key ist eingetragen auf den Clients....
(oder man baut sich eine While-Schleife ins Skript ein welche auf das Netzwerk selbst wartet.) Das weiss ich wiederum nicht wie das geht
Auf das Netzwerk warten ist auch aktiv (mach ich eigentlich immer)

zu 3. Alle Client Computer haben lesenden Zugriff auf die entsprechende Freigabe (Und ich schrieb ja bereits, dass andere Scripte von da aus funktionieren)
zu 4. Was ist ein Start-Transkript

freundliche Grüße
Thomas
em-pie
em-pie 19.06.2019 um 09:56:26 Uhr
Goto Top
Zitat von @sammy65:

zu 4. Was ist ein Start-Transkript

Im ernst?
https://www.google.com/search?q=start-transcript
sammy65
sammy65 19.06.2019 um 10:14:46 Uhr
Goto Top
Wie gesagt.....
Von PowerShell hab ich Null Plan....
colinardo
colinardo 19.06.2019 aktualisiert um 11:32:16 Uhr
Goto Top
Klappt hier testweise einwandfrei. Und wie @em-pie schon gesagt hat, lesen hilft, dann siehst du auch schwarz auf weiß was bei dir schief läuft. Debuggen von Startskripten hat eigentlich nichts mit Powershell verstehen oder nicht zu tun. Man kann sich auch anstellen. Dazu lernen müssen wir alle, sich dumm stellen hilft da in den wenigsten Fällen.
Das Handwerkszeug hast du nun.

Viel Erfolg, i'm out.
Grüße Uwe
brammer
brammer 19.06.2019 um 11:36:24 Uhr
Goto Top
Hallo,

getreu dem Motto "warum einfach, wenn es auch kompliziert geht"?

brammer