dasding

Hallo. Folgendes kleines Problem: Habe hier einen Windows 2003 Server, welcher sich über einen ISDN-Router die Zeit holen soll. Das Problem: Wenn ich z.B. die Zeit manuell über die Schaltfläche 'Jetzt aktualisieren' sync. will, baut der ISDN-Router die Verbindung nicht schnell genung auf, es kommt zu einem timeout. Klicke ich nun ein 2. mal auf die Schaltfl., klappt's. Da muss natürlich geschehen, bevor der ISDN-Router auflegt - sonst klappts wieder nicht ;-) Kann man den Timeout erhöhen? Oder kann ich dem 2k3-Server dazu bringen, nach kurzer Zeit (der ISDN-Router soll nach 60Sek Leerlauf auflegen) selbstständig einen 2. Versuch zu starten? Danke für Eure Ideen/Hinweise. Gruss, Thorsten

Hallo. Bin zwar nur ein -Einäugiger-, versuchs aber mal trotzdem: Wo steht denn in dem von Dir markierten Satz, das einzelnen Rechnern spezielle IP-Adressen zugewisen werden sollen? Da gehts doch nur darum, das für jedes Subnetz ein zugehöriger Bereich erstellt wird. Klingt für mich irgendwie plausibel. Naja, funktionieren sollte das aber - auch ohne weitere DHCP-Server in den anderen Netzen. Denn da steht doch was von einem Router mit aktiviertem BootP-Relay. Oder gehts dir um die in der Fragestellung genannten Netzwerkdrucker? Da würden mir natürlich Reservierungen in den jeweiligen Bereich einfallen in dem der Drucker steht - und dann auch bleiben sollte. Oder extrem lange Leases - kommt mir aber nicht so elegant vor. Hilft Dir jetzt nicht wirklich, oder? Gruss, Thorsten

Hallo dippas. Du schreibst weiter Der Client lässt sich im Netz A deshalb einfügen, weil er den PDC nur via Broadcast findet (WINS ist ja aus). Broadcast = nicht routbar = nicht von Netz B nach A. Ist mir grundsätzlich bekannt. Der NT-Client kanns aber trotzdem durch einen entsprechenden Eintrag in der lmhosts (dort steht der PDC mit Params #DOM... und #PRE). So sucht er dann wohl gezielt nach dem PDC, da ihm die Zieladresse bekannt ist. W2K-Clients scheinen solche Einträge in Ihrer lmhosts auch zu akzeptieren. Jedenfalls interpretiere ich die Ausgabe des Befehls nbtstat -c so, wenn ich diesen auf einem W2k-Clients ausführe und mir der entsprechende Eintrag der Windows-Domäne samt IP-Adresse des PDC's ausgegeben werden. Es gibts sicher einen einfachen Grund, warums unter W2K trotzdem nicht geht, oder? Wertet etwa der W2K-Client anderes wie der NT-Client solche Einträge in der lmhosts für die Suche nach dem Dom.-Contr. grundsätzlich nicht aus? Weiterhin schreibst Du Ein BDC kann authentifizieren und noch ein paar andere Kleinigkeiten, aber NICHT Computerkonten anlegen. Richtiger ausgedrückt: Das klappt bei Dir im Netz B nicht, weil der Client/der BDC den PDC nicht findet. Auch soweit klar - hab ich mal in einem alten Technet-Band gelesen. Aber wie gesagt/geschrieben: im Netz B steht kein BAC. PDC wie BAC stehen beide im Netz A. NT4.0- wie auch der W2K-Client stehen im Netz B und haben beide in ihrer lmhosts einen entsprechenden Eintrag (mit Params #DOM... und #PRE, siehe oben), der auf den PDC zeigt. NT: Computerkonto kann vom Netz B aus angelegt werden, W2K: selbiges klappt im Netz B nicht. Du rätst mir 1. testweise kannst Du ja mal in der HOSTS-Datei (nicht LMHOST) den PDC eintragen. Ist aber wenig sinnvoll für die Zukunft 2. Installieren WINS in den Netzen A und B und gebe jeweils Replikationspartner an. Zu 1 Hilft leider nicht Zu 2 Einen ganzen Dienst damit ich W2K-Clients ein Domänenkonto verpassen kann. Hmmm. Da es unter NT ja klappt, hatte ich gehofft, das ich die W2K-Clients auch irgendwie hinbiegen kann. Und ansonsten hätte dieser Dienst in unserem speziellen Fall doch auch keinen hohen Nährwert, da ja die Reverse-Auflösung, die wir unbedingt über DNS brauchen, über WINS-Lookup nicht funktioniert. Hätte also weiterhin die Handarbeit im DHCP und DNS, die ich oben beschrieben habe. Oder sehe ich wieder nur mit einem Auge? Wie gesagt, bin für jede Idee und jeden Tip dankbar. Gruss,Thorsten

Hallo dippas. Vielen Dank für Deinen Willkommengruß und füre Deine Antworten. Ich fang mal von hinten an ;-) Du schreibst Ansonsten finde ich, dass Du ziemlich viel Handarbeit betreibst, dessen Sinn mir sich nicht wirklich erschließt. Die bei uns laufenden Client-/Server-Anwendungen erfordern DNS. Soweit mit bekannt ist, unterstützt DNS von NT kein DDNS. Somit können vergebene DHCP-Leases weder durch den DHCP-Serverdienst, noch durch den Client in DNS eingetragen werden. Mit dem so fehlenden Client-Eintrag funktionieren unsere Anwendungen nicht, da der Anwendungsserver vor dem Aufbau einer Sitzung den Client-Namen erfolgreich nach IP-Adresse auflösen will. Klappt das nicht, wird der Client abgewiesen. Frag mich nicht, warum das so ist - diese Anwendungen haben mir meine Vorgänger vererbt. Wenn ich nun WINS hinzunehme, dann kann ich zwar durch Aktivierung der Funktion WINS-Lookup im DNS die Clients prima über Ihren DNS-Namen+Domäne nach IP-Adr. auflösen, die ihre vorher über DHCP erhaltenen Adr. im WINS registriert haben. Aber rückwärts wills nicht laufen. Die Client-Anwednung wird also wie gesagt jedesmal vom Anwendungsserver abgewiesen, weil letzterer die Client-Adresse nicht -rückwärts- nach Namen im DNS auflösen kann. Und so habe ich mir dann mit DHCP-Reservierungen und entsprechend passenden DNS+PTR-Einträgen geholfen. Ist jetzt nicht soviel Aufwand; wir haben zwar insgesamt 3 Standorte/respektive IP-Netze, in denen Clients stehen, aber wir haben nur rund 40 Clients. Die wechseln allerdings vereinzelt auch mal die Liegenschaft/sprich das IP-Netz. Daher wollte ich nicht auf DHCP verzichten. Hast Du für den Einäugigen im Reich der Blinden (mit den Blinden meine ich natürlich nicht Dich/Euch!!) eine bessere Idee, ohne die Serverlandschaft grossartig zu ändern? Bis Anfang 2006 gibts nämlich nicht viel Geld ;-). Ich bin für jeden Tip dankbar. Boaah, jetzt hab ich mich fusselig geschrieben und bin noch nicht mal auf das Kernproblem zu sprechen gekommen. Und dann sind hier -nur- 4000 Zeichen möglich. Dann mach ich mal ne zweite Runde auf....

Hallo. Habe folgendes Problem. Habe hier ein Netzwerk mit zwei IP-Netzen, verbunden über einen Xylan-/Alcatel-Router. Im Netz A steht ein NT 4.0 PDC und ein NT 4.0 BAC. Auf dem PDC läuft zusätzlich noch MS-DHCP und MS-DNS. Der Router -spielt- quasi DHCP-Relay und leitet entsprechende Anforderungen aus dem Netz B an den PDC weiter. Wins läuft nicht, da DNS zwingend laufen muss und der Wins-Lookup vom MS-DNS zum WINS nur -vorwärts- funktioniert. Es laufen aber hausbackene Services, die Ihre Dienste nur solchen Clients anbieten wollen, welche durch jene Services auch -Rückwärts- aufgelöst werden können. Und das krieg ich über Wins-Lookup nicht hin. Habe mir dann mit DHCP-Reservierungen und dazu passenden DNS-Einträgen geholfen. Nun zum Kern: Nehme ich im Netz B einen neuen NT 4.0-Client in Betrieb, schnuckelt alles. Für die MAC des Clients im entspr. DHCP-Bereich eine Adr.-Reservierung gemacht, Im DNS den Rechnernamen samt jener IP-Adr in der entspr. Zone angelegt, Rechner einschalten, als lokaler Admin anmelden, Ein Computerkonto in der Domäne erzeugen, Neustart, Anmeldung als Domänen-Benutzer und alles ist gut. Nehme ich im Netz B einen neuen W2K-Client in Betrieb, schnuckelt nix. Für die MAC des Clients im entspr. DHCP-Bereich eine Adr.-Reservierung gemacht, Im DNS den Rechnernamen samt jener IP-Adr in der entspr. Zone angelegt, Rechner einschalten, als lokaler Admin anmelden, DNS-Registrierung abgeschaltet Der Versuch, ein Domänenkonto zu erzeugen, scheitert mit der sinngem. Meldung, das kein Dom-Contr. zu finden sei. Nehme ich den gleichen W2K-Client im Netz A, also im gleichen Netz, in dem die NT 4.0 Domänen-Contr. stehen, in Betrieb, dann funktioniert die Erzeugung eines Computerkontos. Anschliessend kann ich den Rechner auch wieder in Netz B stellen - die Anmeldung mit verschiedenen Domänen-Benutzer funktioniert. Achja: In beiden Fällen (NT wie W2K) gibbet auf den Clients eine LMHOST mit fest verdrahtetem Eintrag für den PDC (#DOM.... und #PRE). Vermutlich liegts an der -anders funktionierenden- Namensauflösung des W2K im Vergleich zu NT4.0, oder? Hatte gehofft, hier durch Deaktivierung des DDNS entgegenwirken zu können. Oder lieg ich damit völlig falsch? Grüsse aus dem Taunus, Thorsten