Jump to content

JoeSan

Members
  • Gesamte Inhalte

    60
  • Registriert seit

  • Letzter Besuch

Alle erstellten Inhalte von JoeSan

  1. Hallo, Eine Firma hat eine einzelne Domäne mit 2003 R2 DCs an mehreren Standorten (Sites). Neben der Forward-Lookup-Zone gibt es noch die _msdcs.<forest.root> Zone mit den SRV-Records für GC etc. Es gibt beim Start eines jeden DNS-Servers die Fehlermeldung mit der ID 4515: Die Zone "<Domänensuffix>" wurde bereits von der Verzeichnispartition "MicrosoftDNS" geladen, aber eine neue Kopie der Zone wurde in der Verzeichnispartition "DomainDnsZones.<Domänensuffix>" gefunden. Der DNS-Server wird diese neue Kopie der Zone ignorieren. Beheben Sie diesen Konflikt so bald wie möglich. Um diese Fehlermeldung wegzukriegen hat der Admin die dazu gehörende _msdcs -Zonendelegierung in der Forward-Lookupzone in DNS gelöscht :confused:. Der Fehler ging dadurch natürlich nicht weg - warum auch - Es scheint dadurch aber auch keine Funktionsbeeinträchtigung zu geben, ich möchte diese Delegierung nun neu erstellen, bevor ich mit ADSI-Edit den doppelten Eintrag in der Verzeichnispartition lösche. Wenn ich ein Testnetz mit mehreren Standorten aufbaue, dann wird die _msdcs-Delegierung automatisch erstellt, es wird nur der erste Domänencontroller der Gesamtstruktur als Delegierungs-NS eingetragen, Egal wieviele DCs ich in die Standorte der Domäne packe, es kommt kein weiterer NS-Eintrag hinzu. Ich frage mich, ob das so korrekt ist. Kann jemand dazu was sagen, ich habe die Funktion dieser Delegierung nicht so recht verstanden. Gruß, JoeSan
  2. Hallo, nur zur Info, das Problem ist beseitigt::p Man darf Bereichsdefinitionen mit verschiedenen Subnetzen nicht zu einer Bereichsgruppierung (Superscope) zusammenfassen. Es ist in den DHCP-Hilfsdateien etwas missverständlich dargestellt, wozu diese Bereichsgruppierungen da sind. Tatsache ist, dass in einer Bereichsgruppierung zu jeder MAC-Adresse immer nur eine Lease existiert. Wenn sich der Client einmal eine Lease aus einem Bereich gezogen hat, dann bekommt er in keinem anderen Bereich innerhalb der Bereichsgruppierung eine neue Lease, auch dann nicht, wenn der DHCP-Request über das Relay aus einem anderen Remote-Subnetz stammt. Also: Bereichsdefinitionen aus verschiedenen Subnetzen nicht zu einer Bereichsgruppierung zusammenfassen ... Dann klappts auch mit dem Nachbarn.;) Danke für die Anteilnahme und Gruß, JoeSan
  3. Hallo, ich betreibe einen einzelnen DHCP-Server unter Windows 2003 Server Enterprise Edition, auf dem 10 Bereiche für verschiedene Remote-Subnetze definiert sind. Die Subnetze sind alle über einen einzelnen Abteilungs-Router mit dem Netz verbunden, in dem der DHCP-Server steht. Die Clients sind ausschließlich XP SP2 und holen sich sich brav eine Lease über die DHCP-Relays des Routers, der die Requests an den DHCP-Server weiterleitet. Das funktioniert auch prima. Aber: wenn ich z.B. ein Notebook in Subnetz 1 vorinstalliere und es hinterher in Subnetz 2 in Betrieb nehmen will, dann versucht der DHCP-Server weiter die noch gültige Lease aus dem Subnetz 1 auszugeben (mit Wireshark und Fluke überprüft) und das schlägt natürlich fehl. Es erfolgt auch kein weiterer Versuch, eine Lease aus dem neuen Subnetzbereich 2auszugeben und das Notebook (XP) zieht sich schließlich eine APIPA-Adresse. Selbst wenn ich die Lease aus dem Subnetz1 lösche oder die Lease-Dauer abgelaufen ist, bekommt das Notebook in Subnetz 2 keine neue Lease. Erst wenn ich die Lease in Subnetz1 lösche und den DHCP-Dienst neu starte, dann bekommt der Client eine Lease aus dem Subnetz 2 Kann das jemand nachvollziehen und weiß vielleicht eine Lösung? Gruß von JoeSan
  4. Kurz zusammengefasst: Bei SBS 2003 gibt es nur einen Standort in Active Directory. Deshalb sind mehrere DCs meist gar nicht sinnvoll; Wohin sollte man auch was replizieren...?, man kann maximal 75 SBS-CALs einsetzen und alle mit SBS lizenzierten Backoffice-Komponenten (ISA und SQL bei der Premium Edition, Exchange, Fax etc. bei der Standard Edition) müssen bei lizenztechnisch korrekter Installation auf dem ersten in der Domäne aufgesetzten DC installiert sein. Das ist schon eine Einschränkung Gruß, JoeSan
  5. Yo, jetzt ist das klar, muss ich halt erst die BDCs (und dazu Exchange 5.5 migrieren - weil es auf einem der BDCs installiert ist -, die BDCs dann rausnehmen und dann den Level hochstufen, ist aber schon irgendwie verwirrend. Danke und Gruß, JoeSan
  6. Hallo, danke für die Rückmeldung, den KB-Artikel kenne ich bereits, er war auch eine Grundlage zur Festlegung des Windows 2003 interim functional level bei der durchgeführten Migration, er gibt für mein Problem nur leider nicht viel her. Die Beschreibung des Domain Functional Level enthält zwar den Hinweis: "Windows Server 2003-interim • Unterstützte Domänencontroller: Windows NT 4.0, Windows Server 2003 • Unterstützte Funktionen: Auf dieser Ebene sind keine domänenweiten Funktionen aktiviert. Alle Domänen in einer Gesamtstruktur werden automatisch auf diese Ebene heraufgestuft, wenn die Gesamtstrukturebene auf "interim" heraufgestuft wird. Dieser Modus wird nur dann verwendet, wenn Sie einen Upgrade von Domänencontrollern in Windows NT 4.0-Domänen auf Windows Server 2003-Domänencontroller durchführen" Aber: Was bedeutet das? Zählen die domänenlokalen Gruppen zu den im interim-Level "nicht aktivierten" domänenweiten Funktionen? :suspect: Rätsel über Rätsel...
  7. Hallo, ich habe ein Netzwerk bestehend aus nur einer Domäne direkt von NT4 Nach 2003 (in-Place auf dem NT4 PDC) migriert. Da vorübergehend noch zwei NT4 BDCs im Netz verbleiben müssen, habe ich das Netz jetzt im Windows 2003-interim functional level. Ziel der Migration war es u.a. die Berechtigungsstrukturen im Netz zu bereinigen. Dafür möchte ich die altbekannte Struktur einsetzen: Benutzer kommen in Globale Gruppen, diese in Lokale Gruppen und diesen werden die Berechtigungen auf Ressourcen erteilt. Auf Universelle Gruppen will ich vorerst verzichten, weil es wohl bei der einen Domäne mit einer Gesamtstruktur bleiben wird. Jetzt habe ich das Problem, dass ich domänenlokale Gruppen in Active Directory zwar anlegen kann, diese jedoch offenbar auf Memberservern nicht anwendbar sind, d.h. ich kann auf einem Memberserver den domänenlokalen Gruppen keine Berechtigungen auf Ressourcen erteilen. Die domänenlokalen Gruppen sind in der AD-Auswahl gar nicht sichtbar. Auf Domänencontrollern ist alles wie erwartet. Weiß jemand, woran das liegt und ob es hier Abhilfe gibt? Sonst müsste ich die Neustrukturierung der Berechtigungen verschieben, bis ich mein Netz in den reinen 2003 Server functional level versetzen kann oder den als Fileserver eingesetzen Memberserver (vorübergehend) zu einem weiteren DC hochstufen. In der Windows Hilfe und auf der MS-Site habe ich zu dieser Problematik nichts explizites gefunden. ich bin für jeden Hinweis dankbar, Gruß, JoeSan
  8. Der Backupserver soll auch einige Systeme über das Corporate-Lan sichern können, z.B den PDC, der nicht mehrfach vernetzt ist. Die Backup-Clients lassen sich beliebig konfigurieren (sonst denke ich wäre es sehr schwierig). Das mit den weiteren Hostnamen für den Backup-Server werde ich gleich mal testen, das hört sich vielversprechend an. Ich bin halt auf der Suche nach einer "Standard Lösung" über DNS, bin bei MS aber bisher nicht fündig geworden, da ist für Mehrfach vernetzte Systeme immer nur von Problemen z.B, mit den NetBios, WINS und den Suchdiensten die Rede, deshalb habe ich z.B. den PDC auch nicht mehrfach vernetzt. Ziel der Aktion ist eine Entlastung des Corporate Lan, weil tagsüber umfangreiche Transaktionslogsicherungen gefahren werden müssen. Gruß, JoeSan
  9. Dacht ichs mir, HKey_Current_User wird ja erst nach der erfolgten Anmeldung aus dem Profil des Benutzers erstellt, also nutzt es nix, da vor der Anmeldung was zu ändern. Ohne die passenden Berechtigung wird da aber nix gehen. Die korrekte Position des Patches wäre das Logon-Script des Benutzers. Es geht nun aber um SUS und Windows Update. Deshalb könnte man das Ganze besser direkt über eine Gruppenrichtlinie regeln. Die würde ich in eine OU für alle Benutzer oder parallel zur Default Domain Policy einrichten. Dafür muss man halt eine Gruppenrichtlinie in der passenden Domäne einrichten dürfen und ggf. eine administrative Vorlage für SUS erstellen. An einer Uni kann sowas natürlich schwierig werden... Gruß, JoeSan
  10. Hm, ist alles ein wenig undurchsichtig... Wenn man über \\server\printers die Druckerverwaltung aufruft und dann auf "Verbindung herstellen" geht, dann versucht das lokale System, den Treiber für den entsprechenden Drucker zu installieren. Die Lösung wäre dann, einen wirklich "unbekannten Druckertreiber" für die automatische Treiberinstallation über die "Servereigenschaften" erst mal auf dem Printserver nachzuinstallieren. Für diese Treiberinstallation muss man dann auf dem lokalen System natürlich die entsprechenden Rechte haben... ich würde mal die Gruppe der Domänen-Administratoren zur Gruppe der lokalen Administratoren hinzufügen und es dann nochmal probieren. Gruß, JoeSan
  11. Vielleicht ja keine andere Policy... Auf welchen Hive und welchen Schlüssel wird der Patch angewendet? Was ist der Inhalt des Patches? Wenns vor der Benutzeranmeldung passiert, dann geht es z.B. nicht auf Hkey_Current_User... Gruß, JoeSan
  12. Hallo, ich habe eine NT4 Einzeldomäne mit mehr als 10 Servern (W2K und 2K3 Memberserver). Außer dem PDC ist jeder der Server mit zwei Netzwerkkarten ausgestattet. Eine Verbindung geht jeweils ins Corporate LAN, die zweite geht in ein Server-LAN. Teil des Server-LAN ist ein W2k Backup-Server, der ebenfalls mehrfach vernetzt und mit einem Bandwechsler ausgestattet ist. Im Corporate LAN ist Ein DNS Server für die Namensauflösung zuständig. Ich möchte nun die Kontrolle darüber haben, welche Verbindungen von bestimmten Anwendungen wie den Backup-Clients genutzt werden. Am besten soll die Namensauflösung weiterhin nur mit DNS ohne Verwendung der LMHosts oder hosts-Dateien erfolgen. Wenn ich auf dem DNS-Server die IP-Adressen des Server-LAN als weitere A-Einträge in der Forward-Lookup-Zone zu den bereits vorhandenen A-Einträgen des Corporate Lan hinzufüge, so ist nach meinem Eindruck nicht vorhersehbar, welche der beiden IP-Adressen zuerst zurückgeliefert wird. Wie kriege ich die Namensauflösung so hin, dass normalerweise eine Kommunikation nur über das Corporate Lan stattfindet, jedoch z.B. die Backup-Clients den Namen des Backup-Servers in die IP der Server-LAN-Verbindung und nicht der Corporate-LAN Verbindung auflösen? Wie müssen dafür die DNS-Clienteinstellungen unter W2k aussehen? Gruß, JoeSan
  13. Nö, man muss keinen Produktkey für eine 2k WS eingeben Wenn man den W2k Terminalserverdienst im Anwendungservermodus installiert, gibt er erst mal die "90 Tage -ab Installation" Lizenzen für alle (!) aus. Über die Installation der Terminalserverlizenzierung kann man in dieser Zeit den Terminalserver dann dauerhaft lizenzieren - also über die telefonische Freischaltprozedur mit dem MS Clearing House. Ab dann gibt er für Clients größer Windows 2000 automatisch die dauerhaften Lizenzen aus, man muss dazu keinen Produktkey der WS eingeben. Das "Lizenz installieren" braucht man nach der Installation der Terminalserver-Lizenzierung aber für die NT-Clients und drunter. Über diesen Menüpunkt werden - getrennt von der Lizenzierungsprozedur des Servers - die extra TS-CALs installiert, für die man auch extra Produkt-Schlüssel bekommt. Man muss dann tatsächlich erst mal aufpassen, dass man sich erstmal nur mit den dauerhaft dafür vorgesehenen NT-Clients (<2k) verbindet, weil denen dann eine permanente Lizenz zugeordnet wird. Unter 2003 Server müssen dann wieder alle eine extra TS-CAL haben... Gruß, JoeSan
  14. Hallo, hatte grade den Fall, scheint gelöst: "Information needed to do the installation has not been downloaded by the activex setup controls due an unexpected reason." Die Reason ist, dass der Client nicht auf die Web-Freigabe des Verzeichnisses C:\Programme\Trend Micro\OfficeScan\PCCNT\ zurückschreiben kann, weil dort unter 2003/IIS6.0 standardmäßig erstmal keine Schreibzugriffe erlaubt sind. Wenn man die gestattet (Eigenschaften der Freigabe), dann gehts. Ich habe vorher auch auf dem Client Java installiert und im IIS Managment CGI freigeschaltet, scheint aber gar nicht nötig zu sein Auf den TM-Seiten, gibt es diesen Workaraound nicht, es ist aber ein anderer Workaround beschrieben, der sich auf die Kombination Officescan/IIS6 bezieht, also sollte es gehen. Gruß, JoeSan
  15. Hm, habe das jetzt alles mal ausprobiert: Das mit dem Initialisieren der Verbindung mit "net use" über die IP funktioniert leider nicht (Systemfehler 53), komischerweise aber über den Netzwerkverbindungsassistenten: Nachteil: wenn die Verbindung bei einem Neustart nicht da ist, braucht der Rechner sehr lange Zeit zum booten, wohl weil er den Timeout für die Verbindungsherstellung abwartet. Da muss ich noch etwas tunen.... Das mit den Metriken funktioniert definitiv nicht, sobald ich ein Standard-Gateway auf dem Gigabit-Subnetz eintrage, kommt der Rechner (über die anderen Schnittstelle) nicht mehr ins Internet, egal welche Metrik, eine Namensauflösung findet sogar noch statt, aber offenbar findet z.B. der Browser die Route über das Internet-Gateway dann nicht mehr. ich werde das Ganze wohl doch eine Weile austesten müssen, Danke für Eure Postings, JoeSan
  16. Hm, scheint doch ein kniffliges Problem zu werden... Routing bringt mich da wohl nicht viel weiter, denn es gibt hier erstmal keine Remote-Subnetze, deshalb auch kein Gateway auf dem Gigabit-Subnetz, denn alle Subnetzte für die lokale Kommunikation, um die es hier geht, sind eben: lokal Kann man eine solche Route überhaupt mit route del löschen? Werde es bald mal ausprobieren... Ich will mein Ziel nochmal etwas genauer formulieren: Das Ziel ist die optimale Ausnutzung der zur Verfügung stehenden Bandbreiten. Wenn RechnerA (192.168.0.1; 10.0.0.1) z.B. mit RechnerB (192.168.0.2; 10.0.0.2) eine Session aufbauen will, dann soll er dies immer nur mit der IP 10.0.0.2 tun, also die Gigabit-Ethernet Schnittstelle verwenden. Ich bin schon seit einigen Jahren im Geschäft, aber mir will derzeit einfach nicht einfallen, auf welcher Ebene da anzusetzen wäre. Vielleicht auf Anwendungsebene , z.B. mit "net use" eine Verbindung direkt mit der IP der Gigabit-Schnittstelle des anderen Rechners herstellen? Ich habe eine ähnliche Konfiguration schonmal mit einem Netzwerk gemacht, wo ein multihomed Client mit der IP eines SQL-Servers auf der exklusiven Gigabit-Verbindung kommuniziert, weil es da möglich war, den Client so zu konfigurieren, dass er eben nur gezielt eine Verbindung mit einer IP (bzw mit dem Socket IP:Port) herstellt, und nicht mit dem Rechnernamen. Hm komme im Moment gedanklich da nicht weiter... Gruß, JoeSan
  17. Jo, es handelt sich um unterschiedliche Subnetze: Das LAN hat die Netzwerkadresse 192.168.0./24 Hier ist der Router als Stdt.-Gateway und als DNS-Server eingetragen, da er als auch als DNS-Forwarder fungiert. Das Gigabit-Subnetz hat die 10.0.0/24. Hier ist sonst nichts weiter eingetragen. Gruß, JoeSan
  18. Hallo, da in letzter Zeit die Gigabit-Ethernet Karten recht billig geworden sind, habe ich jetzt folgendes Szenario: Zwei Produktionsrechner unter Windows XP Professional, zwischen denen große Datenmengen ausgetauscht werden, sollen über 100Mbit/S mit dem LAN und über 1Gbit/s untereinander vernetzt werden. Beide Rechner hängen über die 100Mbit-Schnittstelle an einem LAN-Switch und gehen über einen externen Router ins Internet. Beide Rechner haben außerdem eine Gigabit-Schnittstelle, die über ein Crosspatchkabel verbunden sind. Wie muss das Ganze konfiguriert werden, damit - Die Rechner über die 100Mbit-Schnittstelle mit den anderen Rechnern in der Arbeitsgruppe kommunizieren und ins Internet gehen. - Die Rechner z.B. bei Netzwerkfreigaben untereinander ausschließlich über die Gigabit-Schnittstelle kommunizieren. Die Rechner sind in einer Arbeitsgruppe (insgesamt sind nur 8 Rechner ohne dedizierten Server im LAN) Meine Versuche mit einer Netzwerkbrücke schlugen fehl, die Kommunikation erfolgte außschließlich über die 100Mbit-schnittstelle. Auch die Konfiguration der hosts-Datei (Ein Eintrag für den Hostnamen des jeweils anderen Rechners mit der IP von dessen Gigabit-Schnittstelle) brachte nichts. Wie war noch die Reihenfolge bei der Namensauflösung in einer Arbeitsgruppe (Knotentyp ist "unbekannt") Weiß jemand eine Standard-Lösung? Gruß, JoeSan
  19. Hallo, RIP muss nicht aktiviert werden, das ist eine andere Baustelle... Kannst Du aus dem internen Netz per TS-Client auf den Server zugreifen? Ein Kollege hat seinen DynDns-Host erst nach einigem Konfigurationsaufwand ans Laufen gebracht, deshalb nochmal ein paar Fragen: Kannst Du Deinen Server aus dem Internet anpingen? Mach mal einen tracert auf aus dem Internet auf deinen DynDNS-Host. Meldet er sich auf eine telnet-Anfrage (d.H ist das routing in Ordnung. Hat der Terminalserverzugriff vor der Aktion mit den zwei Netzwerkkarten funktioniert, d.h. konntest Du per TS-Client übers Internet auf den Server in Deinem internen Netz (mit also funktionierendem Dyn-DNS) zugreifen, oder nicht? Welchen TS-Client hast Du dafür genutzt (Remotedesktopclient, TS-Client oder TS-Webaccess), Wie ist TS auf Deinem Server eingerichtet: Remoteverwaltungsmodus oder Anwendungsservermodus und wenn Anwendungsservermodus, hast Du den TS-Lizenzserver installiert und aktiviert? Ich weiß, viele Fragen... aber mir fehlt leider immer noch das Verständnis für Dein Netzwerk. Gruß, JoeSan
  20. JoeSan

    www1, www2, www3

    Das sind die CNAME-Aliases von mehreren Webservern, über die ein DNS-Loadbalancing konfiguriert ist, das heißt, auf den Webservern www1-3 liegt der gleiche Inhalt, eingehende Anfragen auf die gleiche Web-Adresse werden nach einem bestimmten Muster (reihum, zufällig oder lastabhängig) auf alle Server (hier drei) verteilt, damit die Last für jeden einzelnen Server verringert wird. Es gibt da auch noch andere Szenarien, anfragen können z.b. nach Protokoll (telnet, ftp, http ...) aufgeteilt werden und es meldet sich jeweils wieder ein an anderer Server ... Gruß, JoeSan
  21. Hm, neue Situation, wenn ich das richtig verstanden habe: Der DSL-Router ist jetzt in dem neuen Subnetz 192.168.1.0/24 und also nicht mehr direkt mit dem internen Netz verbunden. Der Server muss also routen. Der DSL-Router braucht eine statische Route in Dein internes Netz mit der IP der externen Schnittstelle des Servers als Gateway, also 192.168.115.0 Mask 255.255.255.0 Gateway 192.168.1.2. Was meinst Du mit "externen Leuten"? Sollen die von außen über VPN auf den Terminalserver (Der gleichzeitig dein DC ist, zugreifen? Übers Internet? Dann bräuchtest Du eine öffentliche IP von Deinem Provider, mit dem Du NAT-Betreiben kannst. Dieses NAT muss auf dem DSL-Router konfiguriert werden. Außerdem ist das mit oder ohne Firewall und DMZ gefährlich..., so ein DC mit Exchange Server und aktiviertem Terminalserver hat ziemlich viele Ports offen... Gruß, JoeSan
  22. Also Thema NAT: Klar, viele Firmennetze haben eine oder mehrere öffentliche IP-Adressen offiziell reserviert. Damit kann man in der DMZ einen VPN- oder Web-Server realisieren und diese Server und ganze interne Netze über NAT an das Internet anbinden. Oder man braucht die IP nur für ausgehende Verbindugen wie mail über PoP3 oder http per NAT und bekommt diese dynamisch zugewiesen. Ein ganz unwahrscheinlicher Fall könnte dann doch eintreten, wenn der ISP mir zufällig Adressen aus dem Bereich zuweist, der schon fälschlicherweise für mein internes Netz konfiguriert ist, z.B. Internes Netz: 123.123.123.0/24 Vom ISP zugewiesene öffentliche IP für NAT (statisch oder dynamisch) z.B.: 123.123.123.123. Dann kann nicht mehr geroutet werden, keiner kommt ins Internet und mails können nicht mehr abgeholt werden. Trotz NAT, oder? Oder wenn zufällig ein anderer ISP diese Adresse einem Zielnetz für NAT zugeordnet hat, das ich aus meinem Netz mit der gleichen Netzwerkadresse erreichen will. Dann kommt wieder das DNS-Problem zum Tragen und das Zielnetz kann trotz NAT nicht erreicht werden. Das hat immer die gleiche Ursache, nämlich dass Qell- und Zielnetz die gleiche Netzwerkadresse haben, dann kann halt an irgendeiner Stelle nicht mehr geroutet werden, egal wie viele NATs dazwischen sind... Gruß, JoeSan
  23. Hallo Rüdiger, in der DNS-Konfiguration liegt der Hund begraben: Active Directory benötigt als Voraussetzung einen funktionierenden DNS-Server in der Microsoft-Version (DDNS), der die sogenannten SRV-Einträge für bestimmte Netzwerkdienste der Domäne bereitstellt. Damit diese Einträge überhaupt erstellt werden, muss sich Dein Server sich erst mal "bei sich selbst" registrieren. Folgendes ist zu tun: 1) Trage in der IP-Konfiguration auf dem DC als DNS-Server nur die eigene IP 192.168.115.10 ein, also nicht die DNS-Server des Providers (194.25.2.192 und 121.185.252.136). dann gibst Du an der Eingabeaufforderung ein: ipconfig /registerdns Ein Serverneustart bewirkt in diesem Fall natürlich das gleiche. 2) Trage auf dem DC in der DNS-Konfiguration unter "Weiterleitung" die beiden DNS-Server Deines Providers (194.25.2.192 und 121.185.252.136) als "Forwarder" in die Liste ein. Wenn Du Die root-Zone (.) in der DNS-Standardkonfiguration bereits gelöscht hast, sollten die entsprechenden Einträge unter diesem Registerreiter möglich sein. Sonst erscheint das Ganze grau, und man kann nichts eintragen. Wenn alles eingetragen ist, solltest Du den DNS-Server mal neu starten (Rechtsklick auf den Servernamen in der DNS-Konfiguration...) 3) Du musst sicherstellen, dass alle Clients als DNS-Server nur die IP des lokalen DC eingetragen haben, das geht entweder per DHCP oder eben händisch. Dann solltest Du noch sicherstellen, dass die Clients auch selbst ein Domänensuffix (domain.local) besitzen, das geht auch per DHCP oder händisch in den Eigenschaften der Arbeitsumgebung. Wenn alle Clients dann mal neu gestartet wurden oder eben auf jedem client nach dem korrekten DNS-Eintrag lokal mal ipconfig /registerdns ausgeführt wurde, erfolgt die DNS-Auflösung nur noch über den DC: Der löst jetzt DNS-Abfragen für die lokale Zone selbst auf (weil er sich jetzt auch selbst fragen darf...) und leitet die Anfragen, die er selbst nicht auflösen kann an die DNS-Server des Providers im Internet weiter. Die Antworten gibt er an den Client zurück und speichert sie in seinem DNS-Cache zwischen. Jetzt sollte alles korrekt funktionieren. Gruß, JoeSan
  24. Bisher gings mir mit dieser Frage wie Euch auch: Ich überlege und spekuliere, aber wie sich das genau auswirkt, weiß ich eigentlich nicht, obwohl es mir täglich begegnet. So konnte ich bisher kaum einschätzen, welche Priorität das Umkonfigurieren solcher Netze hat. Ich kann an einem Router, für den ich als Administrator zuständig bin, eben auch eine Route in ein lokales Subnetz eintragen, dessen Netzwerkadresse aus dem öffentlichen Adressbereich stammt. Auch meine internen DNS-Server, die ich spätestens für Active Directory benötige, und auch meine Firewall kann ich so falsch konfigurieren, wie ich will. Für mein lokales Firmennetz funktioniert dann alles ganz prächtig, aber sobald bestimmte Anfragen an das Internet gestellt werden, kann es die bereits geschilderten Probleme geben. Jetzt bin ich aber schon schlauer... :wink2: Das mit der Personal Firewall auf dem Notebook leuchtet mir ein, wenn über ISDN durchs Internet ein VPN aufgebaut wird, dann ist die öffentliche IP im Internet wohl "sichtbar", Bei RAS-Einwahlverbindungen ist das Problem dann relevant, wenn z.B. gleichzeitig eine zweite Netzwerkverbindung mit dem Internet besteht. Gruß, JoeSan
  25. Oha, sieht glaub ich ziemlich schlecht aus. Meine erste Idee dazu wäre, Routing und RAS auf dem DC zu aktivieren, aber das Routing von den DC-Netzwerkdiensten auf der anderen Schnittstelle unabhängig zu machen scheint mir nicht möglich. Ich würde Dir stattdessen empfehlen, die Netzwerkstruktur nochmal zu überdenken. Du hast ja schon eine Firewall, die von der Grundidee her besser für die Internetrouting-Aufgabe geeignet ist als ausgerechnet ein Domänencontroller. Die Standardlösung für das von Dir beschriebene Szenario wäre, der Firewall eine weitere Schnittstelle zu spendieren und beide VLAN-Subnetze direkt zu verbinden, sodass die Firewall die gesamte Kontrolle über den Netzwerkverkehr und die Funktion des Internetrouters übernimmt. Die Regelbasis der Firewall sollte dann so eingerichtet werden, dass Zugriffe zwischen den beiden zu trennenden Subnetzen unterbunden werden, das Routing in Richtung Internet jedoch für beide Subnetze zugelassen ist. Gruß, JoeSan
×
×
  • Neu erstellen...