Daim

Ja, es ist seitens Microsoft supportet, aber in erster Linie in ihren eigenen VM-Produkten. Das wird sich aber noch ändern, so das auch andere Hersteller (VMWare) für jederman vollstens supportet werden. Trotzdem existiert eine weitere (virtuelle) Schicht, die es zu "administrieren" gilt und die eben evtl. solche Fehler verursachen könnte. Dann könnte DCPROMO eine Lösung sein. Wenn man überhaupt von "Risiken" sprechen kann, dann ist der einzigste Grund der, dass beim Hochstufen des Domain-/Forest-Mode keine älteren DCs mehr eingesetzt werden können. Das ist aber auch nicht tragisch. Denn wenn eine Applikation z.B. nur auf einem älteren Server installiert werden kann, dann kann es auch ein älterer Memberserver sein. Von dem Modus sind ja lediglich die DCs betroffen. Siehe auch (und bitte lesen): Yusufs Directory Blog - Domänen- und Gesamtstrukturfunktionsmodus Dann solltest du den Forest-Mode "Windows Server 2003" einstellen. Du hast dadurch keine Nachteile, im Gegenteil, sondern nur Vorteile. Denn das keine älteren DCs mehr eingesetzt werden können, ist alles andere als ein Nachteil. Du musst dir schon genauer den Artikel anschauen. Da wird auch der Fehler 2103 erwähnt.

Salut, das könnte schon die Ursache gewesen sein. Daher sehe ich persönlich die Virtualisierung auf den Infrastrukturservern, auch wenn es noch so lukrativ aussieht, skeptisch. Entweder es hat eine Rücksicherung stattgefunden bzw. ein Snapshot wurde in der VM rückgespielt oder der VM-Crash hat einen irreparablen Defekt auf dem DC verursacht, so das der DC der Meinung ist, dass eine nicht unterstützte Rücksicherung stattgefunden hat. Kontrolliere sicherheitshalber ob nicht ein USN-Rollback vorliegt. How to detect and recover from a USN rollback in Windows 2000 Server How to detect and recover from a USN rollback in Windows Server 2003 Ich hoffe aber nicht das er der einzigste DC der Domäne ist. Wenn lediglich Windows Server 2003 DCs existieren, solltest du den Domänen- respektive Gesamtstrukturfunktionsmodus auf "Windows Server 2003" stellen.

Buenas tardes, versuche es mal hiermit: VBScript program demonstrating the use of an efficient IsMember function to test for group membership for a single user or computer

Na weil du eben als MCSA auch eine Multi-Domänenumgebung administrieren musst. Abgesehen davon, Theorie und Praxis sind auch nochmal zwei Welten...

Servus, Download details: SubInACL (SubInACL.exe) FILEACL Main page How to use Xcacls.vbs to modify NTFS permissions JSI Tip 9640. How do I print permissions on a folder tree using standard commands? SetACL - Windows permission management Showaccs Syntax: File and Storage Services 135268 - Geändert am: Dienstag, 20. Februar 2007 - Version: 2.2 Wie Verwenden von CACLS.EXE in Batchdateien

Salut, es ist dein Netz und du musst es entscheiden. Aber wie meine Vorgänger bereits geschrieben hatten, ein System das einmal verseucht war - auch wenn der Schädling beseitigt wurde - ist nicht mehr vertrauenswürdig. Man weiß nicht, was bereits angerichtet wurde. Du musst ja nicht sofort auf der Stelle tätig werden, nur würde ich es angehen und die Systeme neu aufsetzen, sicher ist sicher.

Einen Replikationskonflikt löst AD folgendermaßen: Yusufs Directory Blog - Active Directory-Replikationskonflikt Im Fall des Kennworts kann man das so sagen. Doch, natürlich. Das Kennwort kann an jedem DC geändert werden. Seit es das AD gibt existiert doch eine Multimaster-Replikation. – Das kann man nicht so pauschal beurteilen. In den meisten Umgebungen stimmt das sicherlich. Aber je nachdem wie groß die Firma ist und wie AD-lastig gearbeitet wird, kann das schon Replikationslast erzeugen. Daher gilt es dann in solchen Umgebungen das genauer zu untersuchen. Das ist korrekt... und das mit dem Eventlog, schau einfach nicht rein solange die Leitung down ist. :D Ich wollte es nur hervorheben, diese Konfiguration nur nach genauerer Untersuchung zu aktivieren. Ahh... oki.

Eben. Das Replikationsaufkommen müsste dann genauer untersucht werden. Nur wenn es wirklich notwendig ist, dass jede Änderung sofort standortübergreifend repliziert werden muss, nur dann sollte man darüber nachdenken die Änderungsbenachrichtigung auch standortübergreifend zu konfigurieren. Yusufs Directory Blog - Die Inter-Site (standortübergreifende) Änderungsbenachrichtigung aktivieren Doch, hätte er auch. Z.B. mit der DNS-Anwendungsverzeichnispartition "_msdcs.Root-Domäne" die bekanntermaßen ab Windows Server 2003 in der Gesamtstruktur repliziert wird. Ober aber auch die Konfigurationspartition.

Wenn der Benutzer1 am Standort1 sein Kennwort am DC1 ändert, pusht der DC1 das Kennwort über den sicheren Kanal zeitnah an den PDC-Emulator der in der Zentrale steht. Wenn der Benutzer1 nun zum Standort2 fährt und sich vor Ort an dem DC2 authentifizieren will, der noch nicht das neue Kennwort des Benutzers kennt, fragt der DC2 zuerst beim PDC-Emulator nach ob sich das Kennwort von dem Benutzer geändert hat. Wenn vor Ort kein DC stehen würde und zum Zeitpunkt der Anmeldung die WAN-Leitung down ist, kann sich der Benutzer nicht an der Domäne, sondern nur mit seinen zwischengespeicherten Benutzerinformationen anmelden. Befindet sich ein DC vor Ort und die Leitung ist dwon, kann sich der Benutzer ganz normal anmelden. Was schief gehen würde solange die Leitung down ist, wäre z.B. die AD-Replikation. Eine absehbare Unterbrechung der Leitung stellt ansonsten kein Problem dar. Doch, auch bei mehreren Subdomänen würde die Replikation fehlschlagen, wenn die Leitung down wäre. Denn schließlich wird die Schema-, Konfigurations- oder Anwendungsverzeichnispartitionen auf alle DCs (egal in welcher Domäne) in der Gesamtstruktur repliziert.

Moin, und zwar in der Default Domain Controllers Richtlinie.

Salut, wenn es keinen trifftigen Grund für weitere Domänen gibt, würde ich das Ein-Domänenmodell empfehlen. Das erleichtert die Administration ungemein. Der Nachteil bei mehreren Domänen wäre: - Bei mehreren Domänen ist der adminstrative Aufwand Updates,Virenscanner usw.) höher, da auch jede Domäne zwei DCs haben sollte. - Dadurch entstehen hohe Hardware- sowie Lizenzkosten. - Jeder DC sollte/muss vor Ort physikalisch geschützt sein. - Jede Domäne muss gesichert werden (Backup). Die Vorteile bei mehreren Domänen wären, wenn man z.B. unterschiedliche DNS-Namensräume haben möchte. Oder unterschiedliche Administratoren sollen "nur" ihre eigene Domäne verwalten und nur dort der Admin sein. Mit mehreren Domänen kann man unterschiedliche Kennwortrichtlinien anwenden (unter Windows Server 2008 gibt es die Password Settings Objects). Der Vorteil einer Domäne wäre z.B. das man nur eine DNS-Zone/Domäne verwalten muss. Mit einer Domäne hat man eine bessere Übersicht und leichtere Administration. Rechte können im AD gezielt an die enbtsprechenden Personen delegiert werden. Aber AD-Standorte würde ich auf alle Fälle für jeden physikalischen Standort erstellen. Ich persönlich tendiere gerne zu dem Ein-Domänen-Modell, aber das kommt immer auf die Gegebenheiten darauf an. Evtl. solltet ihr euch dazu einen Dienstleister zur Seite holen.

Ahoi, kannst du das mit Sicherheit bestätigen, dass die Tombstone Lifetime nicht im nachhinein bearbeitet wurde? Denn in deinem vorherigen Post hattest du geschrieben:

Nicht ganz. Wenn du die Bereinigung mit NTDSUTIL oder ADSIEdit meinst, ja. Da ist die Vorgehensweise seit Windows 2000 fast identisch. Erst mit Windows Server 2008 ist es aber möglich, die Bereinigung auch nur durch die grafische Oberfläche durchzuführen, in dem eben das DC-Objekt in der MMC dsa.msc oder dssite.msc gelöscht wird. Aber alles halb so schlimm. Halte ich an den o.g. Artikel.

Wie gesagt, dass das technisch möglich ist und auch funktioniert, steht ausser Frage. Wenn es sich aber vermeiden lässt, sollte man einen "single-label" Domänennamen meiden.

Das ist doch genau der Grund warum die Variante mit der internen Sub-Domäne so interessant ist. Man hat DNS-technisch das sauber getrennt, zwischen internen und externen DNS-Einträgen. Somit entstehen keine Konflikte mit externen Ressourcen.

Salut, beachte in dem folgenden Artikel, den Abschnitt mit dem 64Bit. Yusufs Directory Blog - Schemaupdate beim Windows Server 2003 R2 Genau. Nein, es ist eine Schemaaktualisierung notwendig. Jedoch ist hier insbesonders auf die 64Bit Stolperfalle zu achten. "Ohne Probleme" in der IT ist schon so eine Angelegenheit. I.d.R. läuft es im laufenden Betrieb ohne das die Benutzer etwas davon mitbekommen. Es ist auch kein Neustart notwendig. Jedoch sollte ADPREP in einer ruhigen Minute ausgeführt werden. Yusufs Directory Blog - Das Active Directory Preparation Tool - ADPREP Nebeneinander laufen die Systeme. Die Besonderheit ist an dieser Stelle eben das ADPREP von der 64Bit CD. Daher beachte o.g. Artikel.

Wer hätte denn daran geglaubt (ausser dem Pfarrer), dass die TLD "info" mal offiziell werden würde...

Servus, der einfache DNS-Name einer Domäne, dem Volksmund auch als "Single-Label" Domänenname bekannt, sollte vermieden werden. Wenn du im Internet danach suchst, wirst du einiges zu dem Thema finden. Man kann das ganze zwar auch so zum laufen bringen, jedoch benötigt es höheren Aufwand und birgt für die Zukunft immer Stolpersteine. Information about configuring Windows for domains with single-label DNS names Aber idealerweise wählt man einen ordnungsgemäßen Fully Quallified Domain Name (FQDN). Dabei gibt es für die Wahl des Domänen-Namens, mehrere Varianten: 1. Der Active Directory-Name lautet so wie die Internetdomain. 2. Der Active Directory-Name ist eine Subdomäne zum externen Internet-Auftritt. Bedeutet, wenn der Inet-Auftritt "Contoso.com" lautet, so wäre der AD-Name "intra.contoso.com". Diese Variante, wäre auch meine empfohlene. 3. Der Active Directory-Name ist ein anderer als die Inet-Domain z.B. contoso.local usw. Sogar die Endung LOCAL kann zu Problemen führen, denn es wäre denkbar, dass die Endung LOCAL offiziell wird (sowie info, biz usw.). 4. Oder der Webauftritt lautet contoso.de und die interne AD-Domäne lautet contoso.net. Dabei sollten natürlich beide Domains beim ISP registriert werden. 5. Die TLD AA, ZZ und die Bereiche QM–QZ und XA–XZ. ISO 3166 ? Wikipedia

Salut, du hast dich "vergriffen". Der Link zeigt wie man die AD-Informationen vom DC selbst "mit Gewalt" entfernt. Da aber der DC gecrasht/defekt ist und nicht mehr zur Verfügung steht bzw. der DC nicht mehr ordnungsgemäß sich mit seinen Replikationspartnern replizieren wird, müsste der DC aus den Metadaten des AD mit NTDSUTIL oder ADSIEdit entfernt werden. Der dazu passende Link wäre dieser: Yusufs Directory Blog - Die Metadaten des Active Directory unter Windows Server 2008 bereinigen Man könnte zwar den DC wieder zur Replikation "zwingen", jedoch ist das nicht leicht zu konfigurieren (Stichwort: Lingering Objects [1]). Schon garnicht, wenn man wenige Kenntnisse über das Thema AD hat. [1] Yusufs Directory Blog - Lingering Objects (veraltete Objekte) @ msdnbernd Das kannst du, aber vorher muss der "defekte" DC aus dem AD entfernt werden.

Hallo, kontrolliere mal, in wie fern dir die beiden Links weiterhelfen: Yusufs Directory Blog - Den einzigen Domänencontroller austauschen Yusufs Directory Blog - Einen zusätzlichen DC in die Domäne hinzufügen

Ja, klar, wenn zum Zeitpunkt der Anmeldung die WAN-Leitung nicht zur Verfügung steht, dann funktioniert die Anmeldung naürlich nicht. Nur wie oft kommt das vor? Wenn die Leitung irgendwann nach der Anmeldung wegbricht, ist das für die angemeldeten Benutzer nicht weiter tragisch. Aber wenn du unbedingt möchtest, dann kannst du auch einen DC vor Ort installieren. Das bedeutet eben, ein weiterer Server/Dienst den es abzusichern gilt, der Server sollte in einem abschließbaren Raum untergebracht sein usw.

Salut, ja, dass schon. Ändere doch auf dem Client das Feld Computerbeschreibung (Systemsteuerung-System-Reiter Computername) und kontrolliere an welchem Computerobjekt im AD sich das Feld ändert.

DNS gehört einfach auf jedem DC. Punkt. Also sollte es auf jedem DC installiert werden. Wenn das bei dir nicht funktioniert, dann läuft noch etwas schief. OK, ich würde trotzdem erstmal ohne einen DC vor Ort anfangen. Bei einer 3 MBit-Leitung sollte die Anmeldung recht fix funktionieren. Ein DC ist ansonsten schnell installiert. Soo viel ist das nicht. Um genaue Informationen zu bekommen, kannst du mit dem Netzwerkmonitor das mal überprüfen. Es handelt sich je nach Umgebung um wenige KBs.

Bonjour, ich muss auch noch meinen Senf dazu geben. :) das stimmt, der Domänen- respektive Gesamtstrukturfunktionsmodus steht in der grafischen Oberfläche nur bei einem Inplace-Upgrade von NT4 zu Windows Server 2003 zur Verfügung. Jedoch kann dieser Modus auch durch das bearbeiten des entsprechenden Attributs msDS-Behavior-Version konfiguriert werden. Somit hätte man die Möglichkeit diesen Modus auch dann einzustellen, wenn kein Inplace-Upgrade durchgeführt wurde. Der Sinn bzw. Unsinn sei mal dahingestellt, technisch ist das aber möglich. Naja... so ganz stimmt das nicht. Im Domänen- bzw. Gesamtstrukturfunktionsmodus "Windows Server 2003" stehen schon noch ein paar mehr Funktionen als im Modus "Windows Server 2003 Interim" zur Verfügung. Einfach im Internet danach suchen. Nicht nur "normalerweise". ;) @IThome Das ist ein wenig missverständlich. Wenn du damit sagen willst, dass es auch einen "Windows Server 2003 Interim" Forest-Mode gibt, dann stimmt das. Aber ein "Windows 2000 gemischt" Forest-Mode existiert nicht. Es gibt die Forest-Modis "Windows 2000", "Windows Server 2003 Interim", "Windows Server 2003" und "Windows Server 2008".

Kannst du das etwas weiter erläutern. Welche Abfrage hast du denn durchgeführt, dass dir "alte" GCs noch angezeigt werden?