Daim

Servus, Yusuf`s Directory - Blog - Active Directory - Abfrage

Exakto Mundo. Nein, alle beteiligten Server müssen R2 sein.

OK. Wenn du nur den File Server Ressource Manager (FSRM) auf einem Memberserver nutzen möchtest, dann brauchst du auch nicht das Schema zu aktualisieren. Da dieses Feature keine Schema Aktualisierung verlangt. Da reicht es lediglich aus, deinen Memberserver mit der zweiten CD auf R2 zu aktualisieren.

Die technische Umsetzung der Schemaerweiterung ist nichts dramatisches. Aber besser ist es, die Erweiterung vorher in einer Testumgebung getestet zu haben. Brauchst du allerdings die R2 Erweiterungen ?

Servus, um die R2-Features zu nutzen, musst du das Schema mit der zweiten R2 CD erweitern. Dazu musst du das ADPREP von der zweiten R2 CD mit dem Schalter /FORESTPREP auf deinem Schema-Master ausführen. Lies diesen Artikel: Yusuf`s Directory - Blog - Schemaupdate beim Windows Server 2003 R2 R2 müßte man eher "Feature-Pack" nennen. Die erste CD von R2 ist ein Windows Server 2003 mit Service Pack 1. Die zweite CD macht daraus ein "R2" indem Zusatzkomponenten unter Systemsteuerung - Software eingetragen werden, die man dann für bestimmte Szenarien nachinstallieren kann. Die Vorraussetzung um auf R2 zu aktuslisieren wären: - Windows Server 2003 SP1 muss installiert sein - Die zweite CD von der R2 Version muss vorhanden sein - Der Windows Server 2003 R2 Produkt-Key muss vorhanden sein (was auch eine gültige Lizenz voraussetzt: Entweder hat man R2 neu erworben oder man verfügt für den vorhandenen Windows Server 2003 über eine Software Assurance)

Nein, du lässt es genau so wie ich es geschrieben habe (samt den Hochkomma`s). Mit dieser Abfrage wird eine TXT erstellt mit allen Benutzern (saMAccountName sowie DN) die in der Gesamtstruktur existieren. Ich hatte allerdings deine Frage anders verstanden. Möchtest du nur wissen in welcher Domäne ein bestimmter Benutzer ist, dann lautet die Abfrage: dsquery user forestroot -samid <Benutzername> -scope subtree Ersetze <Benutzername> durch den echten Benutzernamen des Users. Mit dieser Abfarge bekommst du den DN des Benutzers angezeigt. http://www.microsoft.com/technet/prodtechnol/windowsserver2003/de/library/ServerHelp/46ba1426-43fd-4985-b429-cd53d3046f01.mspx?mfr=true

Servus, gehe auf einem Windows Server 2003 Memberserver in die Kommandozeile (Start-Ausführen-CMD). Dort gibst du z.B. folgende Abfrage ein (alles in einer Zeile): dsquery * forestroot -filter "(&(objectCategory=Person)(objectClass=User))" -attr distinguishedname sAMAccountName -Limit 0 > C:\Dsquery.txt

Ahoi, du weißt was du da schreibst ?

Hallo, du musst die Kennwörter LOKAL auf den Clients ändern. Die lokalen Adminstrator Kennwörter können mit folgendem Tool geändert werden: S@muel-AreA

Servus, kontrolliere zuerst ob du das Schema aktualisierenen darfst: Schema Updates Require Write Access to Schema in Active Directory Was diese Meldung betrifft: überprüfe: Cannot Upgrade Windows 2000 Server to Windows Server 2003 with Windows Services for UNIX 2.0 Installed

Servus, kontrolliere ob folgende Richtlinie aktiviert ist: Computerkonfiguration\Administrative Vorlagen\System\Benutzerprofile\"Zwischengespeicherte Kopien von servergespeicherten Profilen löschen" Edit // Sorry, es handelt sich um lokale Profile !

Wie es (auf deutsch) der Eintrag selbst sagt: Alterung/Aufräumvorgang für alle Zonen festlegen... Damit legst du die Zeiten für ALLE (existierenden) Zonen fest. Du kannst aber in den Eingenschaften jeder einzelnen FLZ die Einstellungen separat/unterschiedlich konfigurieren. Und auch dort, können die Zeiten unterschiedlich eingestellt werden.

Ja, dass könnte klappen. Du solltest eben nach so einer Aktion den DC anschließend auf Herz und Niere prüfen. Mit DCDIAG sowie Netdiag, den DC samt der Netzwerkkonnektivität prüfen. Checkdisk über die HDDs laufen lassen. Die AD-Datenbank auf dem DC würde ich mit der SEMANTIC DATABASE ANALYSES prüfen. Yusuf`s Directory - Blog - Die Active Directory-Datenbank reparieren Eventlog überprüfen.

Nein, müssen nicht. Du musst nur dann zusammen zählen und wissen, wann spätestens ein "alter" Eintrag verschwunden sein muss. Die Tage kannst du beliebig einstellen.

Servus, so wie grizzly es bereits schilderte, lässt sich die "dringende Replikation" nicht verändern. Diese Einstellung wird standardmäßig nur standortintern genutzt. Um die dringende Replikation über standortgrenzen hinweg zu nutzen, musst du die Änderungsbenachrichtigung über standortgrenzen hinweg konfigurieren. Wie man das konfiguriert, siehe folgenden Artikel: Yusuf`s Directory - Blog - Die Inter-Site (standortübergreifende) Änderungsbenachrichtigung aktivieren

Ahoi, die Alterung musst Du in den Einstellungen des Servers UND in den Eingenschaften der Forward lookup Zone aktivieren. In den Eigenschaften Deiner Forward Lookup Zone musst Du zuerst die Option "Veraltete Ressourcen aufräumen" aktivieren. Dann gilt es die folgenden Einstellungen zu addieren: - Intervall für Nichtaktualisierung (standardmäßig 7 Tage) - Aktualisierungsintervall (standardmäßig 7 Tage) - In den Eigenschaften des DNS-Servers die Option "Aufräumvorgang bei veralteten Einträgen automatisch aktivieren" dazu (standardmäßig 7 Tage).

Servus, also das überlegst du dir bitte noch einmal. @ Mcdaniels Wenn die FSMO-Rollen "mit Gewalt" verschoben werden, darf der Ursprungsträger nicht mehr online gehen und diesen müsste man neu installieren und die Daten händisch mit NTDSUTIL aus dem AD entfernen. Eine AD-Domäne kann im günstigsten Fall, weiterhin x-Tage ohne Probleme weiterlaufen, ohne das die FSMO-Rollen verfügbar sind. Was die Tombstone Lifetime betrifft sind es 60 Tage, dass ist korrekt. Länger sollte ein DC nicht aus sein. Allerdings sind die FSMO-Rollen wichtiger. Denn wenn z.B. ein neuer Benutzer erstellt wird, werden dazu RIDs verwendet die vom RID-Master vergeben wurden. Jeder DC fordert vom RID-Master 500 RIDs an und wenn diese (ab SP2/3) zur Hälfte verbraucht wurden, versucht der DC vom RID-Master in regelmäßigem Abstand, neue RIDs anzufordern. Sind die RIDs auf einem DC verbraucht, kann er keine Änderungen mehr vollziehen. Das war nur ein Beispiel mit dem RID-Master. Wenn man absehen könnte, dass der erste DC 2 Wochen down ist, dann würde ich vorher die FSMO-Rollen online auf den zweiten DC übertragen. Wenn der erste dann repariert ist, kann man die Rollen erneut zurück übertragen. Dieses Szenario schilderst du falsch. Wenn die gecrashte Hardware durch neue Hardware ersetzt wird, musst du die neue Hardware installieren und als zusätzlichen DC in deine Domäne integrieren. Schildere dein Szenario 2 genauer.

Probleme kann man leider nie ausschließen. Deine jetztige Konstellation kann so auch laufen, dass viele Firmen so laufen haben. Denn nicht jede Firma kann sich zwei Server leisten. Fakt ist, Exchange auf einem DC wird eben nicht empfohlen. Wichtige Dienste sollten nicht alle auf einer Maschine laufen, daher sollte man Exchange wenn möglich, auf einem Memberserver installieren. Entweder du holst dir einen externen Dienstleister und versuchst deine jetztige Situation zum laufen zu bringen oder du stellst das ganze um.

Wie geasgt, nur bei geimageten System kenne ich das Problem. Abhilfe = händisch installieren.

Servus, das Zauberwort lautet DNS. Du kannst an der Priorität sowie Gewichtung drehen, damit die Clients der einen DC benutzen. Denn wenn sich ein Client an der Domäne anmeldet, brauch er folgende vier Informationen zur Anmeldung: _gc _kpasswd _kerberos _ldap Über das DNS kannst du steuern, wenn die Clients als Logon-Server verwenden. Siehe: Yusuf`s Directory - Blog - Domänencontroller am Standort Ja, es ist nicht empfohlen. Es wird nicht empfohlen die "Situation" eines laufenden Exchanges zu ändern. Das bedeutet, wenn ein Exchange auf einem Memberserver laufen würde, ist es nicht empfohlen diesen Memberserver später zum DC zu stufen. Das gleiche gilt auch umgelehrt. Overview of operating system and Active Directory requirements for Exchange Server 2003

Servus, wie wurde denn der Client installiert ? Ich kenne dieses Problem im Zusammenhang mit gecloneten bzw. geimageten Systemen.

Servus, das ist das KO-Kriterium für dein Vorhaben. Denn ein SBS kann keine Vertrauensstellungen. Was die Besonderheiten eines SBS betrifft, lies: Yusuf`s Directory - Blog - Die Besonderheiten eines Small Business Server`s (SBS)

Servus, z.B. über einen UNC-Pfad. Start - Ausführen - \\Rechnername\c$

Servus, mit Sicherheit ;) Schraube deinen PC auf und nimm die Batterie vorsichtig heraus und warte ca. 15 min. Danach steckst du die Batterie erneut ein und ...."et voila" das Kennwort ist verschwunden.

Also doch nicht alles klar... Dein Windows 2000 Server ist also ein Domänencontroller und diesen möchtest du durch eine neue Maschine auf der Windows Server 2003 läuft, der ebenfalls als Domänencontroller laufen soll. Wenn die neue Maschine auch ein Domänencontroller werden soll, so musst du auf dem 2000er Schema-Master das ADPREP zuerst mit dem Schalter /FORESTPREP, dann mit dem Schalter /DOMAINPREP ausführen. In den TCP/IP-Einstellungen der neuen MAschine trägst du den 2000er DC als ersten DNs-Server ein. Anschließend führst du auf der neuen Maschine das DCPROMO aus und wählst "zusätzlicher Domänencontroller für eine bereits existierende Domäne". Denke daran die FSMO-Rollen zu verschieben, dass DNS auf dem neuen DC zu installieren sowie den GC zu aktivieren. Dazu beachte diesen Artikel: Yusuf`s Directory - Blog - Den ersten/einzigsten Domänencontroller austauschen