Admini2017

Ich wollte alles zentral in einem Skript für die Anwendung machen und es fuchst mich nun, weil es nicht funktioniert :(. Ich werde es wohl über GPP machen, trotzdem ärgert es mich xD

Hallo zusammen,

 

folgendes Szenario, ich würde gerne eine Datei (Verknüpfung) von einem Vz. auf den Desktop kopieren. Habe bereits 2x Skripte erstellt und diese lokal getestet. Dies läuft ohne Probleme :).

 

Skript1: CallerBatch.ps1

powershell -executionpolicy bypass -file \\srv-file01\Skripts\Install.ps1

 

Skript2: Install.ps1

Copy-Item -Path \\srv-file01\Skripts\Tool -Destination c:\Tool -Recurse
Copy-Item -LitertalPath '\\srv-file01\Skripts\Tool\Tool.lnk' -Destination $env:homepath\desktop --> Dies scheint nicht zu funktionieren, wenn das Skript nicht lokal liegt :(
reg import C:\putty\tool.reg

 

ich habe nun im AD ein entsprechendes GPO erstellt Benutzerkonfiguration\Richtlinien\Windows-Einstellungen\Skripts\Anmelden

Skript1 habe ich im Sysvol-Vz. hinterlegt und entsprechend im GPO angebunten.

 

Die Verknüpfung zum Programm wird nicht auf dem Desktop abgelegt, führe ich das Skript lokal aus, funktioniert es. Liegt das Skript auf einem Fileshare, funktioniert es nicht.

 

 

 

 

 

Hmmmm, habe DHCP Media Sense per Registry deaktiviert und das Gerät neugestartet, leider wird eine APIPA Adresse zugewiesen :(. Es ist ein Windows 10 Client.

 

Selbst mit netsh interface ipv4 set global dhcpmediasense = disable funktioniert es nicht :(, sobald neugestartet wird, verliert der Client seine IP

 

FUNKTIONIERT! War im falschen Interface eingetragen :)

 

Dann muss ich mir wohl oder übel eine Möglichkeit überlegen, wie ich diese Option auf 300 Clients in der Registry anpassen o0

ich war immer der Meinung, dass spätestens bei einem Neustart die IP nicht mehr vorhanden ist, falls der DHCP-Server ausfällt. Ich glaube ich muss es einfach mal testen :)

vor 9 Minuten schrieb zahni:

Dann stellt Du eine Lease-Dauer von 30 Tagen ein und hast dann 30 Tage Zeit.  

dann dürfen aber keine neuen Rechner eingeschaltet oder neugestartet werden?! Diese würden dann per DHCP Request versuchen ihre IP zu verlängern und finden keinen Server. Daraus resultiert, dass sie keine IP mehr haben. Also habe ich auch keine 30 Tage zeit.

 

PS: oder irre ich mich?

Es gibt doch Verzögerungseinstellungen, mit denen ich das so einstellen kann, dass der Relay erst später antwortet.

 

vor 5 Minuten schrieb zahni:

Willst Du bei einem Ausfall  dann den DHCP-Relay manuell starten? Sonst Antworten bei DHCP-Server.

Und wie Norbert schrieb: Nimm eine längere Lease-Zeit und gut ist es. Das Netz bleibt nicht stehen, nur weil der DHCP mal kurz nicht da ist.

 

Aber was ist, wenn ein lokaler Server der Außenstandorte abschmiert und eventuell neu aufgesetzt werden muss.

vor 14 Stunden schrieb NorbertFe:

Nochmal, was passiert, wenn ein Client seinen dhcp nicht erreicht die lease aber noch nicht abgelaufen ist? Wie lange und wie oft sind die Mpls strecken down?

vor Ort hätte man noch Zugriff auf Fileshares und könnte halbwegs arbeiten. Die MPLS Strecken fallen so gut wie nie aus. Ich habe mir nochmal Gedanken gemacht xD. Wie wäre es mit folgender Idee:

 

Ich habe an jedem Standort einen lokalen DHCP Server, somit bin ich von MPLS unabhängig. Sollte ein lokaler DHCP-Server ausfallen, würde der Router als DHCP Relay fungieren und entsprechende Anfragen an den Failover DHCP des Standortes A schicken.

 

Ja okay, da stimme ich zu, administrativ alles über eine Konsole und an jedem Standort einen lokalen DHCP sind auch nicht so aufwendig zu verwalten. 

Was wäre denn ihrer Meinung nach die beste Idee? Wir sprechen von 10 Standorten die alle per MPLS verbunden sind. Bisher werden IPs statisch vergeben, was wohl nicht zeitgemäß ist. In meiner Überlegung gibt es einen DHCP am Hauptstandort und Relays an den Außenliegenschaften. Ob man jetzt noch Failover Lösungen braucht ist erstmal kein Thema. Was ist an der Idee so verwerflich :(. Bin etwas verwirrt xD

Bisher gibt es gar keinen DHCP, alle Adressen werden statisch vergeben. Und um den administrativen Aufwand gering zu halten, möchte ich nur einen DHCP und nicht einen an jedem Standort. 

 

Alternativ wäre es eine Überlegung die Server an den Außenliegenschaften als Standby DHCP Server zu betreiben falls MPLS wegfällt oder der Haupt DHCP Probleme hat.

Genau, ein Server an Standort B soll Relay für die Clients an Standort B werden. Meine Frage ist, ob die DHCP Anfragen (unicast) dann ohne weiteres durch mpls durchgeroutet werden. 

 

 

PS: der Server an Standort B soll keine IPs verteilen! Er ist NUR Relay

 

Kein Problem, bin auch schon verwirrt. Aber bei meiner Konstellation wäre es doch so, dass ich die Router nicht anpacken müsste. Der Relay von Standort B schickt ja die Anfragen per unicast weiter. Oder irre ich mich?

 

PS: an den Außenstandorten steht immer mindestens ein Server. Somit wäre ich nicht von der Telekom abhängig, was den Relay betrifft. Falls mein Gedankenspiel funktioniert :)

Ich glaube die Zeichnung ist noch nicht deutlich genug :(. An Standort A steht der Einzige DHCP Server mit Bereichen für Subnetz A und B. Clients an Standort A benötigen doch keine Relay!? Die finden ihren DHCP doch direkt per Broadcast, steht schließlich im selben Netz. Clients an Standort B benötigen einen Relay, in diesem Falle entweder einen Server oder Router.

das ist mir schon klar. Also müsste es mit einem DHCP Relay Server an Standort B funktionieren. Die Clients würden ein DHCP-Discover per Broadcast starten und den Relay-Agent an Standort B finden. Dieser schickt die Anfrage per Unicast weiter an den DHCP Standort A. Die dazwischen liegenden Switche routen zwischen den Netzen, wodurch die Unicast Anfrage ohne Probleme geroutet werden sollte.

 

So würde ich mir das vorstellen:

 

 

Genau, die Frage versuche ich zu klären.

 

Ein Relay wandelt den Broadcast in Unicast, in dem Fall würde der Server an Standort B die DHCP Anfrage per Unicast zum Server an Standort A schicken. Die Frage ist natürlich, bleibt er dann bei den Routern hängen? Eigentlich sollte das doch gehen, die Unicasts würden von den Router doch einfach durchgeroutet. Hmmmmmmmmmmm

Zwischen den Subnetzen Routen die MPLS Router, wodurch sich die Server beider Standorte erreichen können.

Wenn ich das richtig verstehe, habe ich doch folgende Möglichkeiten wenn es darum geht, die lokalen DHCP-Broadcast-Anfragen zwischen verschiedenen Netzen zu routen

 

Variante 1:

Ich habe einen DHCP Server am Standort A mit der IP 192.168.1.1 Mask 255.255.255.0

Am Standort B habe ich das Subnetz B 192.168.5.0 Mask: 255.255.255.0

Dazwischen habe ich meine MPLS Router

 

1.      Ich erstelle auf dem DHCP Standort A einen Bereich für das Subnetz A von 192.168.1.2 bis 192.168.1.100 Mask 255.255.255.0

2.      Ich erstelle auf dem DHCP Standort A einen Bereich für das Subnetz B von 192.168.5.0 bis 192.168.5.100 Mask 255.255.255.0

3.      Die Router müssen als DHCP Relay konfiguriert werden damit DHCP-Anfragen entsprechend auf den DHCP am Standort A weitergeleitet werden

 

Variante 2 (auch möglich?):

Ich habe einen DHCP Server am Standort A mit der IP 192.168.1.1 Mask 255.255.255.0

Ich habe einen Server am Standort B mit der IP 192.168.5.2 Mask 255.255.255.0 welcher als Relay-Agent konfiguriert wird und entsprechende Anfragen weiterleitet

Frage:  Für den Server an Standort B sind beide Subnetze A und B bekannt und erreichbar müssen dann noch zusätzliche Konfigurationen an den Routern vorgenommen werden? Ich denke eher nicht oder?   

stimmt, habe ich auch schon gesehen. Was meinen sie mit Inhalt? Momentan routen die MPLS router zwischen den Subnetzen der Standorte.

ich habe mir auch nochmal ein paar Gedanken gemacht. Es wäre doch möglich einen Haupt-DHCP zu betreiben und an den Außenstandorten Hot-Standby-DHCP. Würde nun MPLS wegfallen, müssten die Standby-DHCPs übernehmen. Fakt ist allerdings, dass ich mit Reservierungen arbeiten muss, jeder Client MUSS dauerhaft eine feste und gleiche IP zugewiesen bekommen.

 

Bedeutet:

 

auf dem Haupt-DHCP würden alle Bereiche und Reservierungen angelegt und bekannt sein

die DHCPs der Außenliegenschaften würden als Standby fungieren und im Fehlerfall eingreifen

 

Clients der Außenliegenschaften müssten natürlich IPs vom Haupt-DHCP erstmal bekommen, vermutlich per bootp oder iphelper..... alles nicht so einfach xD

Würde eine Subdomain anlegen und diese auf die IP routen, sry falsch ausgedrückt.

Hallo zusammen,

 

zur Zeit setzen wir auf externe Provider und holen Mails via POP-Beamer ab. Dies ist natürlich nicht mehr Zeitgemäß. Ich hätte eine kurze Verständnisfrage. Ich könnte doch bei einem externen Provider (z.B. 1und1) einfach den MX-Record auf die öffentliche IP des Exchange (Port 25 weiterleiten) umbiegen?

 

Gruß

Ui, hier hat sich ja einiges getan. Also, zur Zeit steht eigentlich an jedem Standort ein eigener Server. Die Server übernehmen WSUS, Print und Filedienste. Sollte MPLS ausfallen, hätte man zumindest noch Zugriff auf seine Dateien. Leider habe ich noch kein DHCP Konzept eigenständig umgesetzt. Ich stelle mir die Frage, ob es denn sinnvoll ist einen DHCP vor Ort zu haben oder alles über einen DHCP im Hauptstandort zu realisieren. Ich denke, wenn ein Server an jedem Standort steht, ist der administrative Aufwand größer. Sollte alles über einen DHCP und diversen Relays laufen, ist es schon bequemer. 

im Schnitt ca. 25 bis max 50 Plätze. Im Netzwerkbereich werden hintern den MPLS Routern im Moment einfache Layer 2 Switche eingesetzt. Einige Standorte haben einen eigenen Internet Breakout (Proxy + Firewall). Ja es ist MPLS, klären sie mich bitte auf, was sie mit neuen Anschlüssen meinen. Das macht mich nun etwas hellhörig :).

Gut, dann hätte ich am Hauptstandort natürlich eine Absicherung. Sollten während eines MPLS Ausfalls diverse Mitarbeiter an Außenstandorten ihre Clients hochfahren, hätten sie in dem Fall Pech.

Ok, das habe ich auch schon überlegt. Wenn aber nun der DHCP des Hauptstandortes längere Zeit ausfällt oder die MPLS Leitung wegfällt, bekommen eventuell die Clients an den Außenstandorten keine IP mehr.

 

PS: viele Standorte sind lediglich mit 2Mbit syncr. angebunden