olc

Ach ok, bei Exchange heißt das "prepareAD", nicht "Domainprep" wie ich es schrieb. Hatte ich nicht auf dem Schirm, danke für den Hinweis. :) Viele Grüße olc

Hi, bei Ausführung des Befehls auf dem DC hast Du damit auch einige AD GPO Einstellungen in der Default Domain Controller Policy überschrieben. Keine gute Idee also. So fehlt nun vermutlich für die "Exchange Server der Organisation" das Recht, sich übers Netzwerk anzumelden. Hast Du ein Backup deiner "Default Domain Controller Policy" vor der Änderung, die Du wiederherstellen kannst? Ggf. könntest Du das Recht auch manuell hinzufügen. Vielleicht hast Du ja eine Testumgebung, in der Du die Berechtigungen innerhalb der "Default Domain Controller Policy" abgleichen kannst? Ansonsten sollte Dir das "Domainprep" aus dem Exchange Setup helfen - ich weiß jedoch nicht, inwieweit das Seiteneffekte hat. Im SYSVOL selbst Berechtigungen zu verändern ist im Regelfall ein "no go". Das passiert über die GPMC. Wenn Du in eine GPO per GPMC hinein klickst, bekommst Du dann eine Meldung, daß die ACLs nicht passen? Alles in allem ein guter Zeitpunkt, um Dein Backup/Restore Vorgehen in Bezug auf Deine Umgebung, im speziellen Deiner Group Policies zu prüfen. Und ein guter Zeitpunkt über einen Dienstleister nachzudenken, der Dich aus dem Schlamassel vielleicht befreien kann. Viele Grüße olc

Gemach, gemach - der Screenshot ist noch nicht freigeschaltet. Du bist als CA Administrator an der Maschine angemeldet? Viele Grüße olc

Hier gehts weiter...: http://www.mcseboard.de/active-directory-forum-79/sysvol-reparatur-laeuft-exchange-mehr-184597.html Viele Grüße olc

Hi, sichere das Backup Deines Servers zurück. Bedenke dabei, daß hierbei Daten aus den Postfächern verloren gehen können. Falls Du damit Probleme hast, prüfe das Ereignisprotokoll des Servers. Sind hier Fehlermeldungen zu finden, die auf die Ursache des Problems hindeuten können. Wo genau hast Du den Secedit Befehl ausgeführt - auf dem Exchange Server? Was genau meinst Du mit "SYSVOL Berechtigungen konfiguriert"? P.S.: Laß Dir das eine Lehre sein, nicht mal eben irgendwelchen Tipps aus dem Netz zu folgen, wenn Du es vorher nicht getestet hast... Viele Grüße olc

Hi, kannst Du einen Screenshot davon bereitstellen? Viele Grüße olc

Hi, hast Du unter Umständen eine Standard Version vom Windows Server installiert? Erst ab der Enterprise Version ist die Nutzung von Templates (bis Windows Server 2008 R2, ab da gehts auch mit einer "Standard" Version) als auch die Key Recovery Funktion verfügbar. Viele Grüße olc

Hi, schau einmal hier hinein: Implementing Key Archival Walkthrough Viele Grüße olc

Auch wenn ich das noch nicht getestet habe - "nein", er könnte dennoch den gewünschten Server (Ziel) erreichen. Denn das Referral wird ja auf dem Server erzeugt, nicht vom Client zusammengebaut. Der Client sendet seine IP und der Server baut dann entsprechend des Subnetzes die Referral-Liste in entsprechender Reihenfolge zusammen. Viele Grüße olc

Vermutlich schon, das ist jedoch im Wortsinne tatsächlich nur eine Vermutung. :) Viele Grüße olc

Hi, mit IPv6 auseinandersetzen und AD Sites zuweisen, nicht deaktivieren. :) Viele Grüße olc

Hi, DFSR vergibt eine GUID für jede DB, die der Dienst fest an ein Volume bindet. D.h. auf jedem Volume, auf dem eine DFSR Replikationsgruppe liegt, existiert eine eigene DB für dieses Volume. Wenn die HDD defekt war und die Daten komplett auf einer anderen HDD wiederhergestellt wurden, kann das Probleme geben, da hierbei eine neue Volume GUID eingesetzt wird (vom Betriebssystem). Am besten richtest Du den ehemals defekten Partner neu ein, so daß dieser wieder durch die Initialreplikation für diese Replikationsgruppe(n) des Volumes geht. Jedoch sollte dafür sichergestellt sein, daß zwischenzeitlich keine neuen Daten auf diesem System abgelegt wurden. Sonst werden diese entweder im ConflictedAndDeleted oder PreExisting Ordner landen. Ersteres hat ein Quota und überschreibt standardmäßig nach 660MB den C&D Bereich - das kann also sehr weh tun... Viele Grüße olc

Hi, sind die Subnetze auch korrekt in den AD Sites & Services hinterlegt, also das jeweilige Subnetz der richtigen AD Site zugewiesen? Viele Grüße olc

Hi Marcoo, willkommen an Bo(a)rd, :) hast Du unter Umständen einen zweiten Benutzer angelegt oder einen schon vorhandenen Account "aktiviert"? Das würde dazu führen, daß nicht mehr nur ein Benutzer im Anmeldedialog angezeigt wird. Viele Grüße olc

Hi, die GPPs haben ein eigenes Logging, welches Aufschluß über den Fehler geben sollte: Enabling Group Policy Preferences Debug Logging using the RSAT - Ask the Directory Services Team - Site Home - TechNet Blogs Vorher schau Dir jedoch einmal den folgenden Hotfix an: An item-level targeting security group filter in Group Policy preferences settings does not work on a computer that is running Windows Server 2008 R2 or Windows 7 in a disjoint namespace Viele Grüße olc

Hi Maik, in 2008 werden die Einträge per Auditpol immer wieder überschrieben. Entweder beim Neustart oder nach 16 Stunden (standardmäßig). Siehe dazu auch: Getting the Effective Audit Policy in Windows 7 and 2008 R2 - Ask the Directory Services Team - Site Home - TechNet Blogs Lösung für Vista / 2008 wäre zum Beispiel ein geplanter Task, der bei Auftreten eines bestimmten Events läuft. Darin könnte eine Batch-Datei aufgerufen werden, die ungefähr so aussehen könnte: How to use Group Policy to configure detailed security auditing settings for Windows Vista-based and Windows Server 2008-based computers in a Windows Server 2008 domain, in a Windows Server 2003 domain, or in a Windows 2000 domain. Für W7 / 2008 R2 kannst Du die Audit-GPOs nutzen. Viele Grüße olc

Hi, der Fehler war genau der, den ich oben beschrieben hatte. :) Nach dem Entfernen des "Sub-NC" klappt das Metadata Cleanup problemlos. Besten Dank für Deine Rückmeldung und Gruß olc

Hi, welches Artikel hast Du denn konkret "verwendet"? Das Verfahren dürfte im Kern dasselbe sein: ein Metadata Cleanup für die Child-Domäne nach dem Entfernen der darin enthaltenen DCs (und ggf. der DomainDNSZone Partition). Der Vorgang ist hier beschrieben: How to remove orphaned domains from Active Directory Viele Grüße olc

...wie genau? ;)

...bzw. solltet Ihr zumindest die Subnetzzuordnungen in den Sites & Services entsprechend anpassen, da das Netz ja größer wird und nicht kleiner. ;) Viele Grüße olc

Hi, schau einmal hier hinein: How to decommission a Windows enterprise certification authority and how to remove all related objects from Windows Server 2003 and from Windows Server 2000 Entscheiden, ob die CA tatsächlich nicht mehr genutzt wird, mußt Du selbst... ;) Viele Grüße olc

Hi, das ist eine sogenannte "Operational GUID" die angibt, welche konkrete Aktion Adprep.exe gerade ausführen möchte. War die Umgebung zum Zeitpunkt des Schema Upgrades "sauber", d.h. Ereignisprotokolle des Schema Masters wiesen keine Fehlermeldungen auf? Was sagt ein "dcdiag.exe" in der Umgebung - irgendwelche Fehler? Viele Grüße olc

Hi, "Sollte" finde ich in dem Kontext schwierig. Prüfe das lieber noch einmal genau über eine Baseline. ;) Ein Wort: "Konflikte". Schau Dir einmal den Hintergrund für das MS Support Statement an, dann wird die Problematik etwas klarer. Mehrere Ziele für einen replizierten Ordner sind problematisch, nicht nur bei Ordnerumleitung oder Roaming Profiles: Information about Microsoft support policy for a DFS-R and DFS-N deployment scenario DFSN / DFSR ist demnach für das von Dir beschriebene Szenario nicht optimal geeignet. Viele Grüße olc

Hi, das spielt keine Rolle. Der einzige Unterschied ist, daß Du nicht den gesamten Registry Zweig umziehen kannst, sondern nur die von Dir angepaßten Werte übernehmen solltest. Der Rest ist gleich. Ein Test der Migration in Deiner Testumgebung wird Dir alle notwendigen Schritte verdeutlichen... ;) Viele Grüße olc

Hi, Genau anders herum - NTLM statt Kerberos. ;) Das führt jetzt ganz schön weit... ;) Ganz kurz und knapp: Kerberos ist sicherer, performanter, kann Tickets delegieren, single sign-on usw. usf. Insgesamt hat es Sinn, das Thema wie angesprochen anders zu adressieren, z.B. mit einem Service Account. :) Viele Grüße olc