Christoph35

Hinzu kommt, dass Computer standardmäßig alle 30 Tage ihr Maschinenkennwort in der Domain ändern. Wenn du also den defekten DC mit einem Image Stand April wiederherstellst, ist das darin enthaltene Kennwort in der Domain nicht mehr gültig. Am besten installierst du windows 2003 und AD auf einem Rechner komplett neu (als zusätzlichen DC). Falls der defekte DC vorher FSMO Rollen hatte müssen diese zuvor auf den verbleibenden DC übertragen werden. Christoph

Hi, vielen Dank! Direkt gehts leider nicht, da unser Proxy ein Linux Squid ist, der nochmal eine gesonderte Authentifizierung erfordert, aber die CABs haben mir weitergeholfen! :) Christoph

Herzlichen Glückwünsch auch von mir! :jau: Christoph

Frage zu eurer AD-Umgebung: Gibt es in der Gesamtstruktur nur eine Domain, oder mehrere? Falls mehrere Domains: Gibt es in der Domain einen Global Catalog Server? Scheint irgendwie, der Client kann keine Verbindung zu einem Global Catalog aufnehmen. Christoph

Hi, schau mal in die Eigenschaften der mail-aktivierten Gruppe. Da müsste es auf dem Tabreiter "Exchange Allgemein" einen Abschnitt "zustellungsbeschränkungen" (engl. delivery restrictions) geben, wo du das einstellen kannst. Näheres siehe unter http://www.microsoft.com/technet/prodtechnol/exchange/2000/maintain/exrecip.mspx#ECAA Christoph

Hi Blub, in dem von dir angeführten Artikel steht aber unmittelbar nach dem von Dir zitierten Absatz folgende Bemerkung: D.h. in Single Domain Forests ist kein GC zur Anmeldung notwendig. Christoph

Aha, danke dir. Ich hatte übrigens ein ähnliches Problem, auch ständige Synchronisationsfehler mit Fehler 0x8004010F (wars das bei Dir auch?). Löschen des Profils und neu erstellen mit deaktiviertem Cached mode und wieder zurück zum aktiviertem Cache-Mode hat auch nichts geholfen. Ich habe mir dann mal die System-Folders angesehen und bemerkt, dass da 2 Einträge fehlten. Die habe ich mittels Rebuild des OAB erzeugen können und danach keine Probleme mehr mit Synch. Hier gibts dazu mehrere Threads, von denen mich einer auf die richtige Spur gesetzt hatte. Hab jetzt die Thread Nummer nicht mehr im Kopf :D. Such einfach mal nach nach Offline address book oder offline adressbuch. Christoph

Und beachten: Das muß auf dem Schemamaster gemacht werden. Falls du nicht weisst, welcher DC das ist: Gib mal an der Kommandozeile ein: regsvr32 schmmgmt.dll. Danach kannst du in einer MMC das AD-Schema-Snap-In laden, wo du sehen kannst, welcher DC derzeit Schemamaster ist. Christoph

Hi, ich habe ein paar Fragen: Wie sind die DNS-Zonen konfiguriert? Replikation zu allen DCs in der Domain oder zu allen DNS Servern in der Domain, im Forest? Ich würde mir mal die Support-Tools installieren, falls noch nicht geschehen und mal folgendes Commando ausführen: dnscmd /enumdirectorypartitions. Was gibt obiges Kommando aus? Christoph

Nun ja, ich habe das, genau wie Grizzly, noch mal getestet: Single Domain Forest, 1 DC mit GC, 1 DC ohne GC, 1 Client. User, die vorher nicht am Client bereits einmal angemeldet waren, konnten sich auch dann anmelden, wenn der GC heruntergefahren, mithin nicht erreichbar, war. Und nein, GC Caching war nicht eingeschaltet ;). Das gilt selbst dann, wenn der User Mitglied in einer universellen Sicherheitsgruppe ist. Das ganze habe ich im Functional Level W2K mixed und W2k native ausprobiert. Beide male konnte ich mich anmelden. Für den User mit der univ. Gruppe natürlich nur im W2K Native Functional Level. Christoph

Mit Zeile 2 ist die 2. Zeile in der .csv-Datei gemeint, also der 1. User (in Zeile 1 stehen ja die Attribute). Ich würde dir empfehlen, nicht alle Attribute exportieren zu lassen, sondern mit -l beim Export schon eine Liste der Felder anzugeben, die exportiert werden sollen. Alternativ kannst Du eine csv-Datei vorbereiten, in die du in der 1. Zeile die Attribute schreibst, die Dich interessieren und diese Datei dann als Ziel angeben. Dann werden nur die Attribute exportiert, die du in der Kopfzeile angegeben hast. /edit: mit /d kannst du eine start ou vorgeben, falls du nicht die ganze domain exportieren willst. Christoph

Hi, produktiv habe ich sowas noch nicht machen dürfen/müssen. Nur mal in Testumgebungen. Du solltest Dich vielleicht mal mit dem Active Directory Migration Toolkit vertraut machen; ansonsten würde ich dir empfehlen, unter anderem mal das Deployment Kit von MS zu lesen. Da steht jede Menge drin zum Thema Migration NT4 Domain->AD 200x. Christoph

@data: stimmt. hätte ich natürlich höflicherweise auch noch mal drauf verweisen sollen, aber ich hab den Thread wohl auch etwas zu schnell überflogen. Christoph

Ach ja, jetzt erinnere ich mich. Als ich den Test ausgeführt hatte war der User Mitglied von Serveroperators, um sich am Server anmelden zu können. Als Print-Operator gings dann nicht mehr. Christoph

Große Erfahrung damit hab ich nicht. Ich meine, hier im Forum gibts nen ähnlichen Thread, noch nicht allzulang her. Such mal nach ADPREP. Christoph

Hmm, ich geh mal davon aus, du hast eine W2K Domain aufgebaut (also den win 2003 einer 2000er domain hinzugefügt)? Dann mußt du adprep /forestprep und anschließend adprep /domainprep ausführen. Das hätte eigentlich auch BEVOR du den 2003er DC hinzugefügt hast, geschehen sollen. Christoph

Ok, muß wohl irgendwie falsch getestet haben. Du hast recht :) Christoph

Dafür werden sie auf jeden Fall benötigt. Aber ich habe auch nochmal einen Artikel ausgegraben, der bestätigt, dass sie auch für den Logonverkehr ausgewertet werden: http://www.microsoft.com/resources/documentation/Windows/2000/server/reskit/en-us/Default.asp?url=/resources/documentation/Windows/2000/server/reskit/en-us/distrib/dsbc_nar_jevl.asp Gruß Christoph

Das auch, aber du brauchst auch NTFS Full Permissions um Share Permissions ändern zu können (habs vorhin probiert). Christoph

Jo, das ist richtig, habe das grad auch noch mal getestet. Es sieht so aus, dass wenn die Freigabe- und die NTFS Berechtigungen sich unterscheiden, die restriktivere der beiden zieht. Deshalb brauchst du auch NTFS Full Access um Share-Berechtigungen zu ändern. Zum Beispiel beim Windows 2003 Server ist die Default-Share Permission "everyone Read" (statt wie bei W2K everyone Full access). Wenn da nicht dran gedacht wird das zu ändern, können die User nur lesend auf einen Share zugreifen. Christoph

Hi, wenn er einen DC am eigenen Standort findet, wird er den nehmen. Das mit den Kosten ist ja nur relevant, wenn der DC am eigenen Standort ausgefallen ist. Also: in Sites and Services sollte je Site nur der DC aufgeführt sein, der auch in der Site steht, wenn du die anderen DCs da löschst bzw. in die entsprechenden Sites verschiebst, wird auch das DNS angepasst. Die andere Frage: das hatte ich auch überlegt, ob das nur dafür relevant ist, aber mein Kollege hier meint, dass die Kosten auch für den Logon-Verkehr ausgewertet werden. Wie schon mal gesagt: falls jemand andere Info hat, lasse ich mich da auch gerne überzeugen. Christoph

Jo, das ist ja korrekt, aber das war nicht der Sinn meiner Frage ;). Ich hatte dich so verstanden, dass du meintest man könne mit ShareBerechtigung Full Access nicht die Share-Berechtigungen ändern. Du hattest Dich aber damit auf die NTFS Berechtigungen bezogen, was mir nicht so ganz klar war. :) Christoph

Hast Du dir den Artikel genau durchgelesen? Freigabe Vollzugriff->Ändern an den Shareberechtigungen möglich. NTFS Vollzugriff->Ändern der NTFS-Berechtigungen möglich. Wozu sollte es Vollzugriff auf die Freigabe geben, wenn damit das ändern der Freigabeberechtigungen nicht möglich sein sollte Christoph

Es gibt natürlich Router (RFC 1542 kompatibel), die DHCP Broadcasts weiterleiten. Das müsste dann ggf. deaktiviert werden. Christoph

Er wird einen DC an einem anderen Standort auswählen, und zwar den, den er zu den geringsten Kosten erreichen kann. Die Kosten sind ja eine Eigenschaft der Sitelinks. Wenn du also einen Sitelink von x nach y mit Kosten 1 hast und einen link zu Standort z mit Kosten 2, wird er versuchen, sich gegen einen DC am Standort y zu authentifizieren. Sollte das falsch sein, bitte korrigieren. Christoph