Jump to content

Daim

Members
  • Gesamte Inhalte

    4.534
  • Registriert seit

  • Letzter Besuch

Alle erstellten Inhalte von Daim

  1. Aloha, mit ADSIEdit und Organisations-Adminrechten sollte das kein Problem sein. Beachte aber den nächsten Absatz. Ganz, ganz schlecht. Domänencontroller gehören (um nicht zu sagen "müssen") ordnungsgemäß aus dem Active Directory entfernt werden. Sauber aus dem AD wird ein DC aber nur, wenn der DCPROMO-Assistent ausgeführt wird. Wenn der DC einfach ausgeschaltet und neu installiert werden würde, bleiben im AD alle Einträge bestehen und für das AD sieht es so aus, als ob der DC noch bestünde. Das bedeutet für den Admin das er diese Einträge händisch mit NTDSUTIL oder ADSIEdit entfernen muss, da ansonsten Leichen im AD übrig bleiben. Abgesehen davon protokollieren die Replikationspartner das im Verzeichnisdienstprotokoll, dass sie ihren Replikationspartner nicht erreichen konnten. Wie du die DCs aus dem AD entfernst, erfährst du aus diesem Artikel: How to remove data in Active Directory after an unsuccessful domain controller demotion Wenn du die DCs aus dem AD endgültig entfernt hast, sollte diese Meldung nicht erscheinen. Ansonsten mit ADSIEdit und passender Berechtigung.
  2. Servus, bringt denn DCDIAG sowie NetDIAG irgendwelche Fehlermeldungen auf beiden DCs (Quell- sowie Ziel-DC)? Wie sieht das Eventlog (Verzeichnisdienst- und DNS-Log) auf den DCs aus (Quell- sowie Ziel-DC)? Haben die DCs das aktuelle Service Pack installiert?
  3. Servus, da sich die Snap-Ins im AdminPak befinden, musst du natürlich das AdminPak installieren. Korrekt und zwar nur unter Windows Server 2003 (Memberserver und DCs). Leider falsch entschieden... das waren verschenkte Punkte. In den Support Tools, die sich auf der Windows Server 2003 CD im Ordner "Support\Tools" befinden, sind die folgenden Tools enthalten: Windows Server 2003 Service Pack 1 Support Tools Wenn eine CA installiert ist, wird mit sichern des System-States auch die CA gesichert. Weiß aber nicht ob die Frage darauf zielte...
  4. Servus, wie sieht es hiermit aus? Keine Anmeldung möglich, wenn sich der Laufwerkbuchstabe der Startpartition geändert hat
  5. Servus, installiere die mal das AdminPak von einem Windows Server 2003, aus dem Verzeichnis %windir%\system32\Adminpak.msi auf Deinem Client und kontrolliere ob es dort funktioniert. Falls es funktioniert, installiere das AdminPak dann auf dem DC und prüfe ob es nun auf dem DC klappt.
  6. Moin, kontrolliere doch mal deine Vorgehensweise und vorallem wie die Berechtigungen aussehen sollten, mit dieser Anleitung: Yusuf`s Directory - Blog - Profile (lokal/servergespeichert)
  7. Dann brauchst du lediglich auf dem defekten DC das System-State rückzusichern, OHNE einen autoritativen Restore durchzuführen. Denn das ist nicht notwendig, da kein anderer DC in der Domäne existiert. Anschließend musst du dann noch händisch mit NTDSUTIL oder ADSIEdit den gecrashten DC aus dem AD entfernen.
  8. Servus, korrekt. Genau so ist es. In diesem Fall muss dann die Replikation "repariert" werden. Denn bei einem autoritativen Restore musst du ja angeben, was du autoritativ wiederherstellen möchtest. Abgesehen davon, im Idealfall wenn zufällig auch noch Standorte existieren sollten, musst du sogar keinen Restore durchführen, sondern kennzeichnest auf dem DC der die Replikation noch nicht erhalten hat, die Objekte als autoritativ.
  9. Ja, dass ist "by Design" so. Sie irren sich. Bei der Authentifizierung ist das DNS und das Desgin im Snap-In "Active Directory-Standorte und -Dienste" entscheidend. Denn der Client fragt im DNS nach, welche DCs es gibt. Er erhält eine Liste aus der DNS-Antwort und geht diese durch, um einen DC zu finden der online ist und auch funktioniert. Dabei nimmt er bevorzugt einen DC aus seinem Standort. Die DNS-Abfrage die der Client in diesem Moment stellt, wäre: _ldap._tcp.<Standort>._sites.dc._msdcs.<Domäne>.<TLD>. Erst wenn er bei dieser Anfrage keine Antwort erhält, fragt der Client nach einem DC diesmal aus seiner DOMÄNE nach. Die Abfrage lautet: _ldap._tcp.dc._msdcs.<Domäne>.<TLD>. Die Clients sollten natürlich ihren DNS-Server vor Ort (und einen sekundären) in den TCP/IP-Einstellungen eingetragen haben, sei es statisch oder per DHCP. Es ollte im DNS geprüft werden, ob sich die DCs mit ihren SRV-Records für ihren Standort eingetragen haben. Dabei ist ein Blick in "_tcp.Standort.DC._MSDCS.Domäne.TLD" zu werfen. Es sollte darauf geachtet werden im AD auch Standorte einzurichten, in den vor Ort kein DC steht. Dort sollte auch alles soweit konfiguriert werden (Subnetze erstellen und diese mit dem jeweiligen Standort verknüpfen, Kosten einstellen). Denn dann nimmt sich ein DC aus einem anderen Standort der dem "DC losen" Standort am nächsten ist (wichtig dabei sind die Kosten der Standortverknüpfungen), trägt sich im DNS als DC für diesen Standort ein. Dei Technik die dabei zum Einstz kommt bzw. die das ermöglicht, lautet Automatic Site Coverage. Siehe auch: Yusuf`s Directory - Blog - Domänencontroller am Standort
  10. Es ist an drei Stellen die ich bereits aufgeführt hatte, der standardwert von 7 Tagen eingetragen. Drei mal sieben ergeben 21 Tage ;) .
  11. Servus, Yusuf`s Directory - Blog - Wo ist der User angemeldet ? Yusuf`s Directory - Blog - Welcher DC ist der Anmeldeserver ? Eine elegante Variante ist, den Benutzer durch das DNS ausfindig zu machen: Wolfgang on the Road: 72: Wo ist der Benutzer angemeldet? Bei der vertrauten Domäne müsstest du die einzelnen Option die ich hier angegeben haben noch verifizieren.
  12. In den Eigenschaften der Forward Lookup Zone musst Du zuerst die Option "Veraltete Ressourcen aufräumen" aktivieren. Standardmäßig sind dort die folgenden Werte eingestellt: - Intervall für Nichtaktualisierung (standardmäßig 7 Tage) - Aktualisierungsintervall (standardmäßig 7 Tage) Dann kommt noch in den Eigenschaften des DNS-Servers die Option "Aufräumvorgang bei veralteten Einträgen automatisch aktivieren" dazu. Die Einstellung in den Servereigenschaften gibt an, in welchen Intervallen der Aufräumvorgang auf dem DNS durchgeführt wird! In den Zoneneigenschaften wird definiert, wann ein Eintrag als veraltet gilt (und damit aufgeräumt werden kann). Lies Dir diesen Artikel durch: faq-o-matic.net » Endlich Ordnung auf dem DNS-Server
  13. Servus, wenn du es gerne über die GUI abfragen möchtest, kannst du dir eine gespeicherte Abfrage in der MMC "Active Directory-Benutzer und -Computer" erstellen, in dem du eine "Benutzerdefinierte Suche" erstellst und im Reiter ERWEITERT den folgenden Filter verwendest: (objectclass=contact)(!(memberof=*)) Yusuf`s Directory - Blog - Gespeicherte Abfragen
  14. Man kann da was basteln, verstößt aber ganz klar gegen die Lizenzbestimmung.
  15. Moin, genau das ist doch das Problem vom SBS. Der SBS kann keine Vertrauensstellung einrichten! Yusuf`s Directory - Blog - Die Besonderheiten eines Small Business Server`s (SBS)
  16. Natürlich <Klatscht auf die Stirn>, wie konnte ich nur... ;) .
  17. Dann stimmt irgendetwas an der geschilderten Situation oder an deiner Wahrnehmung nicht ganz. Mit erfolgreich meine ich, dass du eine Antwort erhälst die so in etwa aussieht: Wenn du den Namen anpingst und du darauf erolgreich eine Antwort erhälst, dann trägt irgendein Gerät noch diesen Namen. Nein, keineswegs. Mit dem PING speilt aber noch etwas anderes mit eine Rolle.
  18. Servus, was bitte genau heißt "...kann ich den Computernamen immer noch anpingen"? Wird der PING erfolgreich ausgeführt?
  19. 100%ig kannst du das nur behaupten, wenn beide DCs miteinander kommunizieren können, ohne einen ISA dazwischen zu haben. Erst dann kann man sich sicher sein, dass es nichts mit dem ISA zu tun hat. Du könntest dich auch mal mit diesen beiden Tools auseinandersetzen um zu kontrollieren, ob nicht doch etwas geblockt wird. Download details: Port Reporter (PortRptr.exe) New features and functionality in PortQry version 2.0 Nö, dass mit Sicherheit nicht. Deinstalliere doch mal den Virenscanner auf dem DC (deaktivieren reicht nicht und führe anschließend in der Kommandozeile ein "net stop netlogon & net start netlogn" durch und kontrolleire was passiert.
  20. Moin, ja, du kennst doch den "Trick 17" ;) . Da der Ursprungsrolleninhaber nicht mehr zur Verfügung steht, kannst du somit die FSMO-Rollen nicht online übertragen. Daher musst du diese nun "mit Gewalt" auf den anderen DC "sizen". Das kannst du über die GUI erledigen, bis auf den RID-Master. Diesen musst du zwingend mit NTDSUTIL verschieben. Wie das im einzelnen geht, steht in dem Link den Stevie-B gepostet hat. Der neue DC muss alle fünf FSMO-Rollen bekommen und zusätzlich sollte auf diesem der globale Katalog aktiviert werden. Yusuf`s Directory - Blog - Globaler Katalog (Global Catalog - GC) Zum Schluss kannst du dann den Domänen- und/oder Gesamtstrukturfunktionsmodus heraufstufen. Yusuf`s Directory - Blog - Domänen- und Gesamtstrukturfunktionsmodus
  21. Ohne auf den Rest einzugehen... was genau bedeutet das? Hast du einen bestehenden DC mit dem VMWare Converter virtualisiert und möchtest nun das beide DCs miteinander replizieren? Bitte genau erklären.
  22. Moin, gibt es für diese Konstellation auch einen trifftigen Grund? ... scheinbar doch nicht. Dann könntest du den DC immer noch "mit Gewalt" entfernen. Dazu führst du das DCPROMO /FORCEREMOVAL aus und entfernst LOKAL die AD-Daten von dem Server. Anschließend musst du aber aber noch mit NTDSUTIL den DC aus dem AD entfernen. Yusuf`s Directory - Blog - Das Active Directory gewaltsam vom DC entfernen Das kann leider an vieles liegen, ich nehme aber stark an, dass es mit dem ISA zusammenhängt. Die DCs können sich eben nicht 100%ig erreichen. Gerade die dynamischen RPC-Ports stellen oftmals ein Problem dar. http://support.microsoft.com/kb/839880/en-us Du könntest die zu verwenden RPC-Ports fest vorgeben... Lies den folgenden samt weiterführende Artikel dazu durch: Yusuf`s Directory - Blog - Active Directory Replikation durch eine Firewall Die Domäne neu aufsetzen musst du deswegen noch lange nicht. Wenn nichts hilft, bringt dich das gewaltsame entfernen weiter. Trotzdem sollte das Konzept - wenn es keinen plausiblen Grund dazu gibt - mit dem ISA dazwischen überdacht werden.
  23. Servus, der einzige Grund ist im Prinzip, dass die englischen Pachtes/Hotfixe schneller erscheinen als z.B. in der deutschen Version. Die Verzögerung befindet sich höchstens um 2-3 Tage und dabei werden die Updates auch ordentlich getestet. Lange Rede kurzer Sinn; Wenn es aus unternehmerischer Sicht keinen Grund gibt englische Systeme einzusetzen, dann ist das bezgl. der Updates IMHO auch nicht notwendig.
  24. ... und ist hiermit erledigt: Yusuf`s Directory - Blog - Domänen- und Gesamtstrukturfunktionsmodus
  25. Ahoi, Yusuf`s Directory - Blog - Active Directory Topology Diagrammer - ADTD
×
×
  • Neu erstellen...