keine-ahnung
Goto Top

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 face-sad

Content-Key: 190453

Url: https://administrator.de/contentid/190453

Ausgedruckt am: 28.03.2024 um 18:03 Uhr

Mitglied: GuentherH
GuentherH 01.09.2012 aktualisiert um 15:20:25 Uhr
Goto Top
Hallo.

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 face-wink

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? face-wink

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 face-wink

LG Günther
Mitglied: keine-ahnung
keine-ahnung 01.09.2012 um 17:21:40 Uhr
Goto Top
Zitat von @GuentherH:
Hallo.
Zurück.
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 ...?
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.
- 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 face-wink. 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 ...
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 ...face-wink
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 face-wink
Das wage ich zu bezweifeln ... wenn ein Eingreifen von mir vorgesehen wäre, hätte der Assistent ja kaum ohne dieses Eingreifen weitergespielt ...
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? face-wink
Das ist IMHO ein schlechtes Beispiel. Es sei denn, die Lenkung basiert auf einem SBS-Assistenten face-wink
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