2
SBS 2008 Gateway-Wechsel
Hi, hier mal eine kleine Nachmittagsüberraschung, die etwas länger anhielt ...
Was ich wohl nicht wieder machen werde ... den SBS-Internetverbindungsassistenten zum Wechsel des Standardgateways des SBS benutzen!
Ausgangssituation: Anbindung über DYNDNS über eine bei Strato gehostete domain. Jetzt steht eine feste IP zur Verfügung, also habe ich mir gedacht, dann wechselst Du auch gleich den Router für das Standardgateway, der alte Router soll aber im Netz bleiben ( VOIP für die TK, geht nicht anders - WIMAX).
Ergo: DYNDNS-Bindung der Domain gelösst und A-record auf die neue IP gesetzt. Dann über RDP die SBS-Konsole angeworfen, den Internetverbindungsassistenten anlaufen lassen, das neue Gateway eingegeben, und dann .... brach die RDP-Session zusammen.
Da auch auf den clients alles hakelte, habe ich versucht, den SBS anzupingen - ohne Erfolg. Dann bin ich via KVM auf die Büchse - der Server lief gemütlich. In den NIC geguckt und: ich dachte, mich trifft der Schlag: der NIC hatte plötzlich statt der 10.0.0.1 die 10.0.0.3 - im laufenden Betrieb. Zusätzlich war der LANCOM 1781A 3G auf Werkseinstellungen (!!) resettet, was ich nur daran gemerkt habe, weil dieser als neues Gateway nicht mehr pingbar war. UPnP war aus. Das Ding war komplett leer geflasht ..
Dann mit Hand den NIC wieder zurück auf die alte IP gebogen, Neustart und ... DNS im Eimer, der DNS-Server wähnte sich immer noch auf der 10.0.0.3!
Den ganzen Drösel wieder manuell auf die alte IPv4-Adresse zurückgemehrt ...
Alles in allem 5 Stunden Arbeit - nie wieder!
Bisher habe ich ja so eine Art Assistentenaffinität gehabt - vorbei.
Eventuell hat ja Jemand eine Erklärung für das Verhalten ( Ich nicht ) ... Auch das mit dem Router finde ich schick, das Teil war passwortgeschützt.
Naja, vielleicht hilft das Märchen ja einem Anderen - durch Vermeidung!
LG, Thomas
edit: Da ich meine mails vom pop-Connector abholen lasse, habe ich erst einen Tag später gemerkt, dass der Standard-Empfangsconnector auch eine neue IP-Bindung geschenkt bekommen hat ...
Mal sehen, was sonst noch so zuschlägt
Was ich wohl nicht wieder machen werde ... den SBS-Internetverbindungsassistenten zum Wechsel des Standardgateways des SBS benutzen!
Ausgangssituation: Anbindung über DYNDNS über eine bei Strato gehostete domain. Jetzt steht eine feste IP zur Verfügung, also habe ich mir gedacht, dann wechselst Du auch gleich den Router für das Standardgateway, der alte Router soll aber im Netz bleiben ( VOIP für die TK, geht nicht anders - WIMAX).
Ergo: DYNDNS-Bindung der Domain gelösst und A-record auf die neue IP gesetzt. Dann über RDP die SBS-Konsole angeworfen, den Internetverbindungsassistenten anlaufen lassen, das neue Gateway eingegeben, und dann .... brach die RDP-Session zusammen.
Da auch auf den clients alles hakelte, habe ich versucht, den SBS anzupingen - ohne Erfolg. Dann bin ich via KVM auf die Büchse - der Server lief gemütlich. In den NIC geguckt und: ich dachte, mich trifft der Schlag: der NIC hatte plötzlich statt der 10.0.0.1 die 10.0.0.3 - im laufenden Betrieb. Zusätzlich war der LANCOM 1781A 3G auf Werkseinstellungen (!!) resettet, was ich nur daran gemerkt habe, weil dieser als neues Gateway nicht mehr pingbar war. UPnP war aus. Das Ding war komplett leer geflasht ..
Dann mit Hand den NIC wieder zurück auf die alte IP gebogen, Neustart und ... DNS im Eimer, der DNS-Server wähnte sich immer noch auf der 10.0.0.3!
Den ganzen Drösel wieder manuell auf die alte IPv4-Adresse zurückgemehrt ...
Alles in allem 5 Stunden Arbeit - nie wieder!
Bisher habe ich ja so eine Art Assistentenaffinität gehabt - vorbei.
Eventuell hat ja Jemand eine Erklärung für das Verhalten ( Ich nicht ) ... Auch das mit dem Router finde ich schick, das Teil war passwortgeschützt.
Naja, vielleicht hilft das Märchen ja einem Anderen - durch Vermeidung!
LG, Thomas
edit: Da ich meine mails vom pop-Connector abholen lasse, habe ich erst einen Tag später gemerkt, dass der Standard-Empfangsconnector auch eine neue IP-Bindung geschenkt bekommen hat ...
Mal sehen, was sonst noch so zuschlägt
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: 190453
Url: https://administrator.de/contentid/190453
Ausgedruckt am: 26.11.2024 um 00:11 Uhr
2 Kommentare
Neuester Kommentar
Hallo.
Wenn du aus dem Ereignis etwas gelernt hast, dann solltest du deinen Satz etwas anders formulieren - "nie wieder eine derartige Änderung über RDP durchführen"
Den Fehler ausschließlich dem Assistenten des SBS anzurechnen, ist eine sehr oberflächliche Sicht und führt zu einem falschen Ergebnis.
- allein beim Zugriff über RDP sollte dir klar sein, dass bei Änderung der Netzwerkeinstellung die Netzwerkverbindung kurz unterbrochen wird und du aus der RDP Session fliegst. Auf jeden Fall fliegst du aus der RDP Session wenn du aus einem anderen Netz die Änderung des Gateway durchführst
- bist du auch sicher, dass UPN auf den Router aus war? Bist du auch sicher, dass der Router nicht ein Problem mit der UPNP Firmware hat? Es gibt genügend Beispiele im Internet, bei denen der Router crashte, wenn über UPNP zugegriffen wurde
- und was ist dann passiert. Der Router hat sich auf die Werkseinstellungen zurückgesetzt, und der SBS hat diese Einstellungen übernommen.
- und was hat der Passwortschutz mit UPNP zu tun. Sinn und Zweck von UPNP ist es, das das Teil automatisch von jeder Software konfiguriert werden kann. Darum ist das Ding ja so teuflisch, und gehört aus jeder halbwegs sicheren Umgebung entfernt.
Lass mich zusammenfassen. Du warst zu bequem oder zu unerfahren um zum Server zu gehen und die Änderung über die Konsole durchzuführen. Dann hat einer der beteiligten Komponenten nicht richtig mitgespielt und du hast schlicht und einfach die Kontrolle darüber verloren. Hättest du an der Konsole gesessen, hättest du jeder Zeit eingreifen können
Oder ein anderes Beispiel. Du fährst mit Auto 200 kmh auf einer kurvigen Straße, verlierst die Herrschaft über den Wagen und krachst an einen Baum. Ist jetzt der Autohersteller schuld?
Rechne diese 5 Stunden als Lernstunden ein und ziehe die richtige Schlussfolgerung. Jetzt weißt du, dass du nie wieder derartige Änderungen über RDP durchführen sollst. Wenn du bei deinem ursprünglichen Ergebnis bleibst (nie wieder mit dem Assistenten) dann wirst du vermutlich bei der nächsten, ähnlichen Aufgabe wieder 5 Stunden zubringen
LG Günther
Was ich wohl nicht wieder machen werde ... den SBS-Internetverbindungsassistenten zum Wechsel des Standardgateways des SBS benutzen!
Wenn du aus dem Ereignis etwas gelernt hast, dann solltest du deinen Satz etwas anders formulieren - "nie wieder eine derartige Änderung über RDP durchführen"
Den Fehler ausschließlich dem Assistenten des SBS anzurechnen, ist eine sehr oberflächliche Sicht und führt zu einem falschen Ergebnis.
- allein beim Zugriff über RDP sollte dir klar sein, dass bei Änderung der Netzwerkeinstellung die Netzwerkverbindung kurz unterbrochen wird und du aus der RDP Session fliegst. Auf jeden Fall fliegst du aus der RDP Session wenn du aus einem anderen Netz die Änderung des Gateway durchführst
- bist du auch sicher, dass UPN auf den Router aus war? Bist du auch sicher, dass der Router nicht ein Problem mit der UPNP Firmware hat? Es gibt genügend Beispiele im Internet, bei denen der Router crashte, wenn über UPNP zugegriffen wurde
- und was ist dann passiert. Der Router hat sich auf die Werkseinstellungen zurückgesetzt, und der SBS hat diese Einstellungen übernommen.
- und was hat der Passwortschutz mit UPNP zu tun. Sinn und Zweck von UPNP ist es, das das Teil automatisch von jeder Software konfiguriert werden kann. Darum ist das Ding ja so teuflisch, und gehört aus jeder halbwegs sicheren Umgebung entfernt.
Lass mich zusammenfassen. Du warst zu bequem oder zu unerfahren um zum Server zu gehen und die Änderung über die Konsole durchzuführen. Dann hat einer der beteiligten Komponenten nicht richtig mitgespielt und du hast schlicht und einfach die Kontrolle darüber verloren. Hättest du an der Konsole gesessen, hättest du jeder Zeit eingreifen können
Oder ein anderes Beispiel. Du fährst mit Auto 200 kmh auf einer kurvigen Straße, verlierst die Herrschaft über den Wagen und krachst an einen Baum. Ist jetzt der Autohersteller schuld?
Alles in allem 5 Stunden Arbeit - nie wieder!
Rechne diese 5 Stunden als Lernstunden ein und ziehe die richtige Schlussfolgerung. Jetzt weißt du, dass du nie wieder derartige Änderungen über RDP durchführen sollst. Wenn du bei deinem ursprünglichen Ergebnis bleibst (nie wieder mit dem Assistenten) dann wirst du vermutlich bei der nächsten, ähnlichen Aufgabe wieder 5 Stunden zubringen
LG Günther
Zurück.
. Die Operation erfolgte übrigens aus dem eigenen LAN heraus ...
Die Misere primär dem RDP-Zugriff in die Schuhe schieben zu wollen, greift für mein Verständnis ein bisschen zu kurz.
Trotzdem: perspektivisch werde ich solche Luderarbeiten dann halt über die Java-Konsole des KVMS machen, aber ich empfehle trotzdem nicht, diese Änderung über den Assistenten machen zu lassen. Das liefe auf ein Lotto: crasht der Router oder crasht er nicht hinaus. Und der eingesetzte Router ist nun in KMU kein Kolibri, das LCOS ist aktuell ...
LG, Thomas
Wenn du aus dem Ereignis etwas gelernt hast, dann solltest du deinen Satz etwas anders formulieren - "nie wieder eine
derartige Änderung über RDP durchführen"
Das kann man einesteils so sehen. Trotzdem ich Deine Sachkompetenz äusserst schätze, scheint mir hier aber nicht das Hauptproblem zu liegen. Natürlich ist es ausschliesslich meiner Bequemlichkeit zuzuordnen, direkt via RDP auf den Server zu gehen. Allerdings war ich in ca. 1 Minute über den IP-KVM-Switch wieder zurück auf dem Teil. Und was hätte ich bei laufendem Assistenten eingreifend ändern können, wenn die Sitzung nicht unterbrochen gewesen wäre ...?derartige Änderung über RDP durchführen"
Den Fehler ausschließlich dem Assistenten des SBS anzurechnen, ist eine sehr oberflächliche Sicht und führt zu
einem falschen Ergebnis.
Das mit dem ausschliesslich lassen wir mal aussen vor. Aber: so etwas darf einfach nicht passieren.einem falschen Ergebnis.
- allein beim Zugriff über RDP sollte dir klar sein, dass bei Änderung der Netzwerkeinstellung die Netzwerkverbindung
kurz unterbrochen wird und du aus der RDP Session fliegst. Auf jeden Fall fliegst du aus der RDP Session wenn du aus > > einem anderen Netz die Änderung des Gateway durchführst
Ich habe kein Problem damit, aus einer remote-Sitzung geworfen zu werden kurz unterbrochen wird und du aus der RDP Session fliegst. Auf jeden Fall fliegst du aus der RDP Session wenn du aus > > einem anderen Netz die Änderung des Gateway durchführst
. Die Operation erfolgte übrigens aus dem eigenen LAN heraus ...- bist du auch sicher, dass UPN auf den Router aus war? Bist du auch sicher, dass der Router nicht ein Problem mit der > UPNP Firmware hat? Es gibt genügend Beispiele im Internet, bei denen der Router crashte, wenn über UPNP zugegriffen > wurde
Yep. Der Router war durchkonfiguriert und hin seit > 2 Wochen bei mir "zur Bewährung" im Netz, da ich am WAN einen zusätzlichen ISP hängen habe ... Wenn es tatsächlich genügend Beispiele gibt, dass Router bei Zugriff über UPnP crashen, dann ist es sträflicher Leichtsinn von MS, diese Art der Routerkonfiguration in den Assistenten zu implementieren ...- und was ist dann passiert. Der Router hat sich auf die Werkseinstellungen zurückgesetzt, und der SBS hat diese
Einstellungen übernommen.
Das ist dann zwingend. Ebenso wie die von mir geschilderten Folgen ...Einstellungen übernommen.
Darum ist das Ding ja so teuflisch, und gehört aus jeder halbwegs sicheren Umgebung entfernt.
Das gehört auch nicht in die Installationsroutine eines Serverbetriebssystems implementiert!! Insbesondere beim SBS, der ja auch durch nicht professionelle Anwender aufgesetzt werden kann, zumindest, wenn man MS das glauben darf ...Lass mich zusammenfassen. Du warst zu bequem oder zu unerfahren um zum Server zu gehen und die Änderung über die
Konsole durchzuführen.
Ähhm .. JA! Zumal ich nicht mal zum Server hätte gehen müssen ...Konsole durchzuführen.
Dann hat einer der beteiligten Komponenten nicht richtig mitgespielt und du hast schlicht und einfach die
Kontrolle darüber verloren. Hättest du an der Konsole gesessen, hättest du jeder Zeit eingreifen können
Das wage ich zu bezweifeln ... wenn ein Eingreifen von mir vorgesehen wäre, hätte der Assistent ja kaum ohne dieses Eingreifen weitergespielt ...Kontrolle darüber verloren. Hättest du an der Konsole gesessen, hättest du jeder Zeit eingreifen können
Oder ein anderes Beispiel. Du fährst mit Auto 200 kmh auf einer kurvigen Straße, verlierst die Herrschaft über den
Wagen und krachst an einen Baum. Ist jetzt der Autohersteller schuld?
Das ist IMHO ein schlechtes Beispiel. Es sei denn, die Lenkung basiert auf einem SBS-Assistenten Wagen und krachst an einen Baum. Ist jetzt der Autohersteller schuld?
Die Misere primär dem RDP-Zugriff in die Schuhe schieben zu wollen, greift für mein Verständnis ein bisschen zu kurz.
Trotzdem: perspektivisch werde ich solche Luderarbeiten dann halt über die Java-Konsole des KVMS machen, aber ich empfehle trotzdem nicht, diese Änderung über den Assistenten machen zu lassen. Das liefe auf ein Lotto: crasht der Router oder crasht er nicht hinaus. Und der eingesetzte Router ist nun in KMU kein Kolibri, das LCOS ist aktuell ...
LG, Thomas
