Daim

Salut, in dem du dir eine Abfrage erstellst und die Attribute OperatingSystem sowie OperatingSystemVersion abfrägst. Einen Ansatz findest du hier: faq-o-matic.net Wie kann ich abfragen, welche Rechner welches Service Pack haben?

Moin, nein, eben nicht. Das ist doch das schöne an ADMT. Quasi auf Knopfdruck verschiebst du die Benutzer- sowie Computerkonten von einer Domäne in die andere. Somit bleiben alle Profile der Benutzer erhalten. Der Benutzer merkt nichts davon.

Servus, standardmäßig lautet die Primary-Group-ID eines jeden Domänen-Benutzers "Domain Users". Diese kannst du dir entweder mit DSQUERY oder einer gespeicherten Abfrage anzeigen lassen. Siehe hier, letzter Abschnitt: Yusufs Directory Blog - Active Directory - Abfrage Das Attribut Primary-Group-ID ist aber nur im Benutzerkonto und nicht im Gruppenkonto enthalten. Im Gruppenkonto existiert das Attribut Primary-Group-Token.

Schon mal an einem Client net user ausgeführt? Nein? Dann mach mal. ;)

Servus, von einem Windows Server 2003 Memberserver kannst du auch mit DSMOD in der Kommandozeile das Benutzerkonto aktivieren: dsmod user <DN des Benutzerkontos> -disabled no Skriptbasiert funktioniert das natürlich auch, genauso wie durch Dritt-Anbieter Tools. Aber das wird in dem Buch sicher nicht enthalten sein.

Dann geht es hier weiter: Beheben von Fehlern bei der RPC-Endpunktzuordnung Falls eine Firewall auf den Servern aktiviert sein sollte, deaktiviere diese vorübergehend.

Aloha, schau mal hier: Event ID 1153 ? Schema Operations

Das wird das Beste sein. Hier noch die Seite des Restaurants: Colosseo - Mainz - Ristorante Pizzeria - Pasta - Pizza - Salate

Aloha, das könnten die SIDs der (alten, also noch vor der Migration) gleichen Gruppenzugehörigkeiten sein. Nein, dass sieht bisher korrekt aus. Die SID-History sollte ohnehin nur während der Migration genutzt werden. Nach der Migration ist es empfehlenswert diese zu löschen. Bei einer Migration (z.B. mit ADMT) wird ein neues Benutzerobjekt in der Ziel-Domäne erstellt und die SID des Benutzerobjekts aus der "alten" Domäne, in das Attribut SIDHistory des neuen Benutzerobjekts geschrieben. Z.B. so: How To Use Visual Basic Script to Clear SidHistory Sieht bisher ok aus.

Das stimmt (leider). Meine Frau war gestern dort und kann das bestätigen. Sie hat einen Tipp und sagte, dass es im Malakoff-Park ein italienisches Restaurant gäbe (mit Blick auf den Rhein bei zivilisierter Lautstärke) namens Colosseum. Das gute am Malakoff-Park ist, es gibt eine günstige Tiefgarage und dort befinden sich mehrere Cafès. Ich denke das ist ein guter Kompromiss.

Servus, Genau. Stimmt. Unter Windows Server 2003 muss man Dritt-Anbieter Tolls einsetzen, damit mehrere Kenwortrichtlinien eingesetzt werden können. Unter Windows Server 2008 ist dies mit Bordmitteln (Password Settings Objects, kurs PSO) möglich. Ja, in einer Gesamtstruktur besteht zwischen den Domänen eine transitive bidirektionale Vertrauensstellung. In einer Gesamtstruktur existiert immer für alle Domänen das gleiche Schema. Dabei spielt es auch keine Rolle, ob mehrere Domänenstrukturen (Trees) in der Gesamtstruktur existieren. Auch dabei gibt es nur ein einziges Schema. Es kommt auf die Anforderung an. Was soll wie erreicht werden.

Off-Topic:Türke und Qualität? Kann man das essen? Zwei Welten treffen aufeinander. :cool:

Bonjour, es wurde aber keine Sicherung verwendet. Der OP hat das Tombstone wiederbelebt. Das ist etwas anderes. Der Vorteil beim wiederbeleben des Tombstones ist, dass es online ohne den DC neu zu starten erfolgen kann. Der Nachteil widerum ist, dass die meisten Attribute auf ewig vom Objekt entfernt werden. Diese Informationen müssten auf einem "anderen Weg" erneut eingepflegt werden. Yusufs Directory Blog - Active Directory Wiederherstellung

Salut, aber Hallo! Du läufst Gefahr einen USN-Rollback zu bekommen. Lass lieber die Finger davon. Alle weiteren Informationen erhälst du dazu aus dem folgenden und den weiterführenden Artikeln: Yusufs Directory Blog - Images als Sicherung?

Wer weiß, wer weiß... bestimmt nicht mehr vom Entwickler selbst, der ja mittlerweile bei Microsoft arbeitet, aber vielleicht dessen alter AG. Kloar. Ich wollte ohnehin darüber die Tage etwas pinseln. ;)

Servus, das Tool steht mitlerweile auf einer anderen Seite (dem ehemaligen AG des Entwicklers) zur Verfügung. http://www.mcseboard.de/tipps-links-5/coreconfigurator-windows-server-2008-core-132285.html#post865460

Merhaba, zuerst einmal wird das installieren eines Exchange-Servers auf einem DC seitens Microsoft nicht empfohlen, wird aber supportet. Wenn du die Exchange-Erweiterung so wie Norbert es erwähnt hat, durchgeführt hast, musst du noch das Schema auf Windows Server 2003 aktualisieren. Du führst quasi zwei Schemaaktualisierungen durch, einmal für Exchange und einmal für das Serverbetriebssystem. Dazu führst du das Tool ADPREP von der Windows Server 2003 CD aus. Falls die neue Maschine ein Windows Server 2003 --> R2 <-- sein sollte, beachte bitte, dass du das ADPREP von der zweiten R2 CD verwendest. Denn das ADPREP bei R2 befindet sich auf beiden CDs. Du führst das ADPREP mit dem Parameter /FORESTPREP auf deinem 2000er Schema-Master in der Kommandozeile aus. Anschließend führst du ADPREP mit dem Parameter /DOMAINPREP /GPPREP auf dem Infrastruktur-Master in der Domäne aus, in der du den neuen Server hinzufügen möchtest. Yusufs Directory Blog - Schemaupdate beim Windows Server 2003 R2 Yusufs Directory Blog - Das Active Directory Preparation Tool - ADPREP Danach füge den neuen Server als "zusätzlichen Domänencontroller einer bereits existierenden Domäne" hinzu. Deine Forward Lookup Zone (FLZ) im DNS sollte auf deinem 2000er DC idealerweise AD-integriert gespeichert sein und "Nur sichere" Updates zulassen". Wenn die FLZ im AD gespeichert ist, erleichtert dir die Replikation das Leben ein wenig. Yusufs Directory Blog - Einen zusätzlichen DC in die Domäne hinzufügen In den TCP/IP Einstellungen des neuen Servers trägst Du als ersten und einzigsten DNS den bestehenden 2000er DC ein. Erst wenn die Replikation stattgefunden hat, kannst du die DNS-Server Einstellung verändern. Siehe: Yusufs Directory Blog - Welcher DNS-Server sollte eingetragen werden ? Somit hast Du das AD und DNS auf Deinen neuen DC "gesichert". Dann solltest Du die 5 FSMO-Rollen auf den Windows Server 2003 DC noch verschieben, damit die neuen Grupen erstellt werden: Yusufs Directory Blog - Der PDC-Emulator Yusufs Directory Blog - Die FSMO-Rollen verschieben Zusätzlich solltest Du den neuen DC zum GC deklarieren. Dieses kannst Du in dem Snap-In "Standorte- und Dienste" in dem jeweiligen Standort, auf Deinem Server - in den Eigenschaften der NTDS-Settings den Haken bei "Globaler Katalog" setzen. Yusufs Directory Blog - Globaler Katalog (Global Catalog - GC) Ansonsten beachte noch: http://blog.dikmenoglu.de/PermaLink,guid,0f062c72-4b37-4db2-9f0e-af3fa8bd5104.aspx

Bonjour, wird dir die Rolle des PDC-Emulators auch in der MMC "Active Directory-Benutzer und -Computer" (Rechtsklick auf den FQDN - Betriebsmaster..) korrekt angezeigt? Oder über NETDOM QUERY FSMO. Läuft nun DCDIAG sauber durch? Der Anmeldedienst läuft ebenfalls und steht auf "Automatisch"?

Hmm... auf der Webseite steht, sie nehmen keine Reservierungen unter 10 Personen an aber ok, wenn sie doch reservieren umso besser. Auf welchen Namen und für wieviele Personen hattest du reserviert?

Oki doki. Termin und Ort sind Fix. Das Treffen findet am Samstag, den 25.10.2008 um 19:00 Uhr in Mainz im Heilig Geist statt. Es ist leider keine Reservierung möglich. Aber wir werden bestimmt ein Plätzchen finden. Hier nochmals der Link zum Lokal: Heiliggeist

Salut, siehe: Yusufs Directory Blog - Computerkonto löschen

Ich kenne die Lokation zwar nicht, allerdings finde ich Gonsenheim alleine von dem "hinkommen" schon nicht sehr ideal gewählt. Mir persönlich wäre es egal, aber die meisten kommen (so wie du) von ausserhalb. Da wäre die Innenstadt die bessere Variante. Ja, 19:00 Uhr dürfte doch für alle eine humane Uhrzeit sein.

Salut, ich bin zwar nicht Nils, aber ich antworte trotzdem mal. :p falls bereits eine Domäne besteht und die Benutzer aus der Arbeitsgruppe in die bestehende Domäne migriert werden sollen, dann stimmt das. Falls aber erst die Domäne erstellt werden soll, kann man das so wie Nils es geschrieben hat, lösen. Man beachte aber, lediglich die Benutzerkonten auf dem ersten Server, der Server der also zum DC gestuft wird, werden in die AD-Domäne übernommen. Die lokalen Benutzerkonten die auf den weiteren Arbeitsgruppenservern gespeichert sind und evtl. auch zu DCs gestuft werden sollen, werden danach nicht mehr in die AD-Domäne übernommen. Klar, wäre auch möglich.

Servus, wie der Client "seinen" DC findet, läuft folgendermaßen ab: Bei der Authentifizierung eines Clients ist das DNS und das Desgin im Snap-In "Active Directory-Standorte und -Dienste" entscheidend. Falls AD-Standorte eingerichtet werden sollen, darf das erstellen der jeweiligen Subnetze und das verknüpfen an den entsprechenden Standorten nicht vergessen werden. Natürlich müssen dann noch die DC-Icons an ihre AD-Standorte, in der MMC "Active Directory-Standorte und -Dienste" verschoben werden. Die Vorgehensweise wie ein Client "einen" DC findet, ist wie folgt: - 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 funktioniert und auch online ist. 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 der Client bei dieser Anfrage (von einem DC aus seinem Standort) keine Antwort erhält oder er noch keine Standortinformationen hat (z.B. nach einer Neuinstallation), fragt er nach einem DC diesmal aus seiner DOMÄNE nach. Die Abfrage lautet: _ldap._tcp.dc._msdcs.<Domäne>.<TLD>. Spätestens bei dieser Abfrage erhält der Client einen DC mitgeteilt. Auf der Gegenseite geht der DC der die Anfrage eines Clients erhält wie folgt vor: - Der Domänencontroller reicht die Clientanfrage an seinen NETLOGON-Prozess durch, der dann die Client-IP in seiner Subnet to Site Mapping Table nachsieht und dann das treffende Standort-Objekt heraussucht. - Der Netlogon-Prozess des DCs übergibt an den DC die folgenden Infos: 1. Den Namen des Standorts, in der sich der befragte Domänencontroller befindet 2. Den Standortnamen, in dem sich der Client befindet 3. Ein Flag das angezeigt wird, wenn sich der angefragte DC im gleichen Standort befindet (Bit gesetzt) oder ob der DC ausserhalb des Standortes ist (Bit nicht gesetzt). Diese Informationen werden dann an den Client gesendet, der sich nun die Informationen näher anschaut: - Wenn sich der Domänencontroller an dem gleichen (oder nächstgelegenen) Standort befindet (gesetztes Bit), nimmt der Client bevorzugt diesen DC. - Wenn sich kein DC an dem Standort des Clients befindet, entscheidet das Design in der MMC "Standorte und Dienste", an welchem DC sich der Client authentifiziert. Er verwendet der einen Domänencontroller der am nächsten zu seinem Standort ist. Dabei ist z.B. die Einstellung der Verbindungskosten entscheidend. - Nachdem der Client einen Domänencontroller ermittelt hat, wird dieser Eintrag des DCs zwischengespeichert. Falls sich der DC nicht an dem Standort des Clients oder an einem optimalen Standort befinden sollte (Kosten), leert der Client nach 15 Minuten den Zwischenspeicher und verwirft somit den zwischengespeicherten DC. Der Client versucht dann einen nächstgelegenen DC, idealerweise an seinem eigenen Standort zu finden. Lange Rede kurzer Sinn; Kontrolliere im DNS ob der entfernte DC an dem sich die Clients authentifizieren, mit seinen SRV-Records im DNS, noch für den alten Standort eingetragen ist. Wenn das der Fall sein sollte, musst du die Einträge löschen. Lies dazu diesen Artikel: Yusufs Directory Blog - Domänencontroller am Standort

Servus, wenn du vom DC die IP-Adresse des Clients nicht pingen kannst, hängt eine Firewall dazwischen.