JoeSan

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

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

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

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

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

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...

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

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

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

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

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

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

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

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

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