Reppy

Keine Bange, die Einführung von 2008 R2 ist beschlossene Sache. Wir wollen DFS-R zwischen den Standorten einsetzen. Da müssen wir eh mindestens auf 2003 R2 setzen. Und da wir auch an die Domäne ranmüssen, haben wir gesagt, dass wir gleich den großen Schritt machen. Aber das will halt gut vorbereitet sein und ich bin nur nebenbei Admin. Mein Verdacht geht übrigens jetzt dahin, dass die Probleme wahrscheinlich daher kommen, dass ich die Firewall als Reserve-DNS gesetzt habe. Die kennt natürlich die DNS-Einträge im Server nicht. Kann es sein, dass der Reserve-DNS auch bemüht wird, obwohl der primäre DNS läuft? Viele Grüße und schonmal ein schönes Wochenende Reppy

:confused:

Null sessions sind ein 1a Einfallspunkt für's Hacking. :cool:

Ich beiß noch in die Tischkante! :cry: Das hat nicht geholfen. Ich habe aber noch die Firewall in der DNS-Liste, damit die Benutzer auch surfen können, wenn ich den Server mal in den Update-Reboot schicken muss. Die DNS-Liste, die übrigens natürlich per DHCP verteilt wird, sieht folgendermaßen aus: Lokaler Server Server des anderen Standorts (neu) Firewall Plötzlich meldete meine Kollegin, dass der Fehler wieder aufgetreten ist. Ich habe es getestet und auch bei mir schlug die Verbindung fehl. Auffällig: Immer wenn der Fehler auftritt ist die Antwortzeit sehr kurz. Nun habe ich in der Firewall auch noch einen DNS-Forward eingetragen. Nachdem ich das getan habe, habe ich den Link getestet, es ging aber immer noch nicht. Kurz "ipconfig /flushdns" eingegeben und danach ging's. Jetzt kommt noch ein Witz: Ich habe zwei Aliase. "www" verweist auf die meisten Dienste auf dem Server, zusätzlich gibt es den Alias "wiki", der auf ein internes Wiki verweist. Bei meinem Test (vor dem FlushDNS-Befehl) ging nun der Zugriff aufs Wiki, auf den WWW aber nicht. Das kann jetzt aber auch daran gelegen haben, dass ich die beiden Regeln auf der Firewall hinzugefügt habe. Ich hatte vorher nämlich nur mit WWW getestet und nicht mit Wiki. Ein "nochmal versuchen" auf WWW hat nämlich auch nichts gebracht, obwohl Wiki ging. Ich musste den Link komplett neu aufrufen, damit es funktioniert. Ich werde berichten, ob es das jetzt war. Gespannte Grüße :suspect: Reppy

Der Eintrag zur Konfiguration hat mich auf die grandiose Idee gebracht, den Server des anderen Standorts als zweiten DNS in der Liste einzutragen. Wieso bin ich da nicht schon früher drauf gekommen? Mal schauen, wie es sich jetzt verhält. Ich beobachte das mal ein paar Tage und melde mich dann mal, ob's geholfen hat. Danke und viele Grüße Reppy

Vielleicht eine dumme Frage: Hilft diese TechNet-Seite evtl. weiter?

Ja, das sind wirklich zwei unabhängige Domänen mit jeweils eigenen Schemas und Domänenadministratoren, keine Sites. Meines Wissens kann man bei einer SBS-Domäne auch keinen zweiten DC einbinden. Insofern könnten wir nur das Wagnis eingehen, einen Standort ohne Server zu betreiben. Aber das wollen wir auch nicht. Es gibt auch schon einen Plan für die Zukunft: Wir werden die SBS-Lizenzen gegen normale Serverlizenzen tauschen und dabei auch gleich zu 2008 R2 wechseln. Dann werden wir auch genau das tun: Wir werden eine Domäne mit zwei Sites betreiben. Aber das will gut vorbereitet werden, weil wir die Domäne komplett neu aufsetzen und alle Clients und vor allem das Berechtigungskonzept auf dem Fileserver migrieren müssen. Das dauert also noch etwas. Wir hoffen, dass sich das DNS-Problem dann auch erledigt hat, weil dann die beiden Server miteinander replizieren können. Im Moment trauen die sich ja gegenseitig nicht. Aber bis das mal so weit ist nervt das DNS-Problem ganz schön. Die Sache mit den SBSen ist eine Altlast von einem Vorgänger und mag damals vielleicht eine gute Idee gewesen sein. Aber es wurde nie richtig genutzt, weil der Exchange gar nicht installiert wurde. Heute sind wir schlauer. Die übergeordnete Domäne "firma.local" gibt es nicht. Insofern wird die Domäne "standort[1/2].firma.local" als Root-Domäne betrachtet. Die Anmeldung läuft über den Prä-Windows-2000-Namen der Domäne. Das sieht dann ungefähr so aus: "firma-standort\benutzer"

Hallo zusammen, ich habe das Problem, dass die Namensauflösung bei den Client-Browsern nicht zuverlässig funktioniert. Manchmal klappt der Aufruf über über den Domänennamen und manchmal nur über die IP-Adresse. Wenn ich dann nslookup bemühe, funktioniert die Namensauflösung ohne Probleme. Trotzdem kriegt der Browser es nicht hin. Auch ein "ipconfig /flushdns" hilft nicht. Nach einiger Zeit kann es dann sein, dass es wie von Geisterhand wieder geht, ohne dass ich etwas gemacht hätte. Kennt einer von euch das Problem? Ich habe schon die Suchfunktion hier bemüht, konnte aber keinen passenden Thread finden. Zum Hintergrund: Wir haben im LAN einen Server (Win 2k3 SBS) für die Rollen DC, DHCP, DNS, Fileserver und Intranetserver (companyweb). Die Clients laufen unter XP Pro SP3. Alles auf aktuellem Stand. Wenn das Problem auftritt, nützt auch die Benutzung von IE 8 statt Firefox nichts. Bisher hat uns das nicht wirklich gejuckt, weil wir das Companyweb nicht so intensiv nutzen. Nun haben wir aber einen weiteren Standort per VPN angebunden. Auf einem Server am anderen Standort laufen Anwendungen mit Web-Interface, die wir häufiger brauchen. Dadurch fällt das Problem jetzt erst richtig auf. Der andere Standort hat ebenfalls einen 2k3-DC. Die beiden Domänen sind voneinander unabhängig (Kopplung geht ja bei SBS nicht), aber einheitlich benannt: standort1.firma.local standort2.firma.local Zusätzlich gibt es am anderen Standort einen Linux-Server, auf dem die Anwendungen laufen. Da ich die Domänenweiterleitung in Verdacht hatte, habe ich einfach manuell eine Forward-Zone eingetragen (standort2.firma.local). Zu der habe ich die IP-Adressen der beiden Server eingerichtet: server1.standort2.firma.local -> 10.0.0.1 server2.standort2.firma.local -> 10.0.0.2 Außerdem habe ich einen Alias eingerichtet: http://www.standort2.firma.local -> server2.standort2.firma.local Zusätzlich habe ich auch die passende Reverse-Lookup-Zone eingerichtet (als primäre Zone, die Pointer habe ich manuell gesetzt). Wie geschrieben: Mal funktioniert's und mal nicht. Fällt einem von euch etwas dazu ein? Danke im Voraus für eure Hilfe Reppy

Bei uns läuft nachts ein Backup-Script, das auf dem Weg Fehlermeldungen absetzt. Die E-Mails werden per Blat an den IIS-SMTP geschickt und der bläst die dann über sein Sendekonto beim Mailprovider raus. Außerdem werden verschiedene Überwachungsmeldungen vom Board und von der USV so verschickt. Vielleicht solltest du dann mal die Hosen runter lassen und posten, was du eingestellt hast. :confused: Beste Grüße Reppy

Hallo, ich schreibe mal eine etwas längere Antwort... ;) Hast du die Remotedomäne für den E-Mail-Empfänger denn eingerichtet? Das machst du in der IIS-Verwaltung unter "Virtueller Standardserver für SMTP" und da unter "Domänen". Dort richtest du eine Remotedomäne für den Empfänger ein, z. B. contoso.com. Dann aktivierst du in den Eigenschaften die Option "Eingehende Nachrichten können an diese Domäne weitergegeben werden", falls die nicht eh schon aktiv ist. Die Option "HELO anstelle von EHLO senden" ist meines Wissens vom SMTP-Server abhängig, über den die E-Mail weitergeleitet werden soll. Unter "Routingdomäne" aktivierst du "Gesamte Mail an Smarthost weiterleiten" und gibst dort den SMTP-Server an, über den das laufen soll, z. B. smtp.web.de. Unter "Ausgehende Sicherheit" aktivierst du "Standardauthentifizierung" und gibst da Benuternamen und Passwort an. Wenn der SMTP-Server das unterstützt, solltest du "TLS-Verschlüsselung" aktivieren. Das kann aber u. U. auch dein Problem sein, wenn der SMTP-Server kein TLS beherrscht. So, ich hoffe, dass ich helfen konnte. :wink2: Viele Grüße Reppy

Hallo zusammen, ich habe mich hier angemeldet, weil ich auf der Suche nach Praxiserfahrungen mit DFS-R bin. Ich habe schon einiges im TechNet gelesen und die sehr guten Anleitungen von OLC in den Windows Server How-To Guides habe ich auch durch. Mein Chef möchte aber gerne, dass ich mir mal von einem Admin mit Praxiserfahrungen bestätigen lasse, dass DFS-R auch tatsächlich zuverlässig funktioniert - oder schlechterdings das Gegenteil. Ein paar Facts zu unserer Umgebung, die vielleicht bei der Einordnung helfen: Wir haben zwei Standorte, an denen jeweils maximal 10 Benutzer arbeiten werden. Die Nutzung einer Domäne für beide Standorte mit Verwendung von AD-Standorten ist geplant. Die Standorte sind per DSL mit dem Internet verbunden (6016/576 kbps bzw. 3456/448 kbps). Wir denken auch über ein Upgrade auf jeweils 2000er SDSL nach. Zwischen den Standorten gibt es ein IPSec-VPN mit einer Bandbreite von derzeit ca. 256 kbps (über DSL halt). Die Benutzer arbeiten standortübergreifend gemeinsam an Projekten (Beratung zur Informationssicherheit). Die Arbeit wird offline am Laptop durchgeführt und dann zur Datensicherung auf den Server gesynct (Beyond Compare). Die Änderungshoheit für Dateien ist organisatorisch geregelt und macht selten Probleme. ;) Tägliches Änderungsvolumen sind ca. 50 MB - meistens weniger, manchmal mehr. Nun möchten wir die Daten auf den Servern synchronisieren, damit wir zwischen den Standorten nicht mehr mit E-Mail arbeiten müssen - was bei großen Dateien und Verschlüsselung ein echter Krampf ist. :cry: Das Hochladen der Dateien sollte für jeden Benutzer an seinem Standort möglich sein und dann automatisch zum anderen repliziert werden (was DFS-R nach meinem Verständnis ja auch macht). Wer mag mir dazu ein bisschen aus seiner Praxis berichten? Darf gerne auch per E-Mail oder persönlich sein, wenn's nicht hier diskutiert werden soll. Mich interessieren die folgenden Fragen: Verschwinden Dateien, ohne dass es auf ein Layer-8-Problem zurück zu führen ist? Wie häufig müssen Konflikte bereinigt werden, die nicht auf Layer 8 zurück zu führen sind? Müssen wir das Benutzerverhalten anpassen? Wie bereits oben geschrieben, sollte immer klar sein, wer an einer Datei arbeiten und diese hochladen darf. Klappt die Replikation auch ohne WAN-Optimizer à la Riverbed gut? Sollte so sein, denn das verspricht Microsoft ja. Wie viel Arbeit hat der Admin mit dem DSF-R? Muss der Dienst häufiger neu gestartet werden? (Ich las hier einen Hinweis darauf.) Dann hätte ich noch eine andere Frage: Ist es bei unserer Konstellation sinnvoll, mit DFS-N zu arbeiten, so dass der jeweils andere Fileserver bei einem Ausfall als Ersatz dient oder funktioniert das ganz schlecht über das VPN? Ich danke euch für eure Hilfe! :) Viele Grüße Reppy