NilsK

Moin, wenn es tatsächlich "einer deiner DCs" ist, du also noch weitere funktionierende DCs hast, würde ich gar kein Restore machen. Schalt den DC aus, übertrage die FSMO-Rollen offline auf einen anderen DC und installiere einen neuen. faq-o-matic.net » AD: Betriebsmaster-Ausfall – was tun? Künftig rate ich auf jeden Fall, System State Backups direkt aus dem jeweiligen DC zu erzeugen, also nicht vom Host aus. Falls noch eine andere Backupstrategie eingesetzt wird, würde ich die System State Backups immer ergänzend mit Bordmitteln machen. Gruß, Nils

Moin, nein, das ist kein Fehler, sondern Absicht. Auf einem RODC administriert man ja normalerweise nicht. Wenn man dort also das ADUC oder ein anderes Tool startet, greift es gleich auf einen schreibbaren DC zu. RODC geht nur durch dcpromo oder Neuinstallation. Gruß, Nils

Moin, Vorsicht, das geht zwar technisch, ist aber nur für Test und Entwicklung zu empfehlen - oder wenn es in Produktion gar nicht anders geht. Ein solcher Parallelbetrieb mehrerer Instanzen hat immer Auswirkungen und unterscheidet sich vom Normalbetrieb einer Einzelinstanz. Das nur als Hinweis, falls jemand nur flüchtig mitliest. Gruß, Nils

Moin, wahrscheinlich ein Wahrnehmungsfehler: Deine AD-Konsole war nicht mit dem lokalen RODC verbunden, sondern mit einem beschreibbaren DC. Wohin die Verbindung zeigt, siehst du ganz oben im Konsolenbaum. Gruß, Nils

Moin, selbstverständlich empfehlen wir hier keine Lizenzverstöße! Testversionen sind zum Testen, und der hier diskutierte Fall ist eindeutig kein Test. Genauso sind Lizenzen, die mal irgendwann im Rahmen von Aktionen verteilt wurden, i.d.R. nicht für so etwas einsetzbar (zumal wenn die Aktion beendet wurde). Es ist absolut legitim, für so einen Zweck Geld zu verlangen. Daher ist es nicht legitim, sich an Lizenzkosten vorbeizumogeln, insbesondere wenn man damit einen geschäftlichen Zweck verfolgt. Das BSI und andere Quellen setzen den technischen Aufwand oft sehr hoch an. Es wurde schon mehrfach nachgewiesen, dass einmaliges Überschreiben sämtlicher Bytes ausreicht, um Daten nicht wiederherstellbar zu machen. Das von mir vorgeschlagene Verfahren (Bordmittel von Windows, wenn auch nicht in allen Versionen) überschreibt allerdings auch mehrfach und braucht daher ziemlich lange. Gruß, Nils

Moin, auch in der Beta hat sich Windows Server 2008 nicht als "2007" gemeldet. Also sollte der TO noch mal genau nachsehen. Gruß, Nils

Moin, existiert die OU bereits, in der du die Kontakte erzeugen willst? Heißt sie genau so? Ist der Domänen-DN der Zieldomäne exakt richtig angegeben? Gruß, Nils

Moin, nehmt es mir nicht übel, aber ich verstehe kein Wort. Eure Ausführungen klingen, als müsste man in euren Gedankengängen schon sehr weit drinstecken, um euch zu verstehen. Macht es euch viel aus, eure Überlegungen noch mal nachvollziehbar darzulegen? Danke, Nils

Moin, das DSCT kenne ich. Wenn du mal den von mir verlinkten Artikel lesen würdest, stelltest du fest, dass ich es bereits vor drei Jahren vorgestellt habe. Es ist sogar so, dass der Autor einen von mir gemeldeten Fehler korrigiert hat. Belehrungen darüber sind also unnötig. Ich halte das Snapshot-Verfahren für das, was du vorhast, nach wie vor für einen Holzweg. Aber das willst du ja nicht hören. Gruß, Nils

Moin, grundsätzlich könntest du mit ADMT Gruppen aus DOM_A nach DOM_B übertragen und dabei die Funktion SID History nutzen. Dann sollten die bestehenden Berechtigungen für die migrierten Gruppen erkannt werden. Für diese Migration brauchst du eine Vertrauensbeziehung zwischen den Domänen. Gruß, Nils

Moin, nimm doch die Bordmittel: Windows Server Backup. Gruß, Nils

Moin, wenn die Server "hängen", wäre es wichtig, den Grund herauszufinden. Dann kann man das Monitoring viel aussagefähiger gestalten. Gruß, Nils

Moin, faq-o-matic.net » Ein AD-Attribut zu einem Logon-Namen herausfinden Gruß, Nils

Moin, um sicher zu gehen, sollte man alle Daten überschreiben. Das ginge z.B. so: faq-o-matic.net » Dateien sicher löschen mit cipher.exe Gruß, Nils

Moin, die Symptomatik, die du beschreibst, deutet jedenfalls darauf hin, dass das Setup-Programm nicht richtig mit dem SQL Server kommunizieren kann, denn offenbar gelingt es ja nicht, die Konfigurationsdaten zu bestimmen. Gibt es evtl. irgendwo ein Sprachversionsproblem? Sowas hatte ich mal in der Betaphase eines anderen SC-Produkts. UAC testweise mal ganz abgeschaltet? Gruß, Nils

Moin, es löst dein Problem nicht (zu dem ich leider momentan keinen zielführenden Hinweis habe), erspart dir aber u.U. gravierende Folgeprobleme: "Domain Admins" ist die falsche Gruppe für nahezu jedes Dienstkonto. Insbesondere SQL Server braucht weder lokale Adminrechte noch Domänen-Admin-Rechte. Wozu genau sollte der SQL Server denn auch das AD vollständig manipulieren oder auf jedem einzelnen Rechner im Netzwerk administrative Rechte haben? Ja, ich denke, genau das wird der Grund sein. Gruß, Nils

Moin, leider lässt sich aus deiner Beschreibung weder die Konfiguration noch das Problem erkennen. Bitte noch mal ausführlich und in Ruhe beschreiben. Gruß, Nils

Moin, machen wir es kurz: Mit 1000 EUR und "eigentlich keiner Zeit" ist das Ziel nicht zu erreichen. Stellt sicher, dass alle wichtigen Daten und Applikationen gesichert sind und dass im Notfall zügig Ersatzhardware da ist. Mehr kann man in dem von dir gesteckten Rahmen nicht tun. Gruß, Nils

Moin, ich meine das Problem schon mal anderswo gesehen zu haben. Wenn es genauso ist, ist gar nicht die IE9 in anderer Sprachversion installiert worden, sondern es gab nur ein Problem beim Kopieren der aktualisierten ADML-Datei (Sprachdatei für die GPO-Einstellungen im GPO-Editor). Effekt ist dann, dass der GPO-Editor die (veraltete) deutsche Sprachdatei nicht lädt und daher die GPO-Einstellungen des betreffenden Zweigs in der Originalsprache (also Englisch) anzeigt. Gruß, Nils

Moin, aber er hat das Problem doch schon gelöst ... Gruß, Nils

Moin, für mich sieht das nach "Token Bloat" aus. 300 Gruppenmitgliedschaften verdoppelt macht schon 600 - und zusätzlich zur Maximalgröße des Tokens selbst kann es noch Einschränkungen bei der Übermittlung des Tokens geben (Details dazu habe ich gerade nicht mehr im Kopf, sind aber recherchierbar). Letztere könnte man übergangsweise beheben. Um das Problem tatsächlich zu lösen, kommst du um die Bereinigung der SID History nicht herum. Gruß, Nils

Moin, nein, aber das wäre notfalls auch nachträglich über das Exchange-GUI eine Sache von Minuten. Gruß, Nils

Moin, heute morgen habe ich die Version 3.2 des AD-Dokumentationstools José freigegeben. Die Betaphase dafür ist damit beendet. faq-o-matic.net » AD-Dokumentation: José 3.2 ist da Aufgrund der Übersichtlichkeit bitte ich aber darum, dass Kommentare, Fehlerbeschreibungen und Änderungswünsche trotzdem in diesem landen. Danke & Gruß, Nils

Moin, heute morgen habe ich die Version 3.2 des AD-Dokumentationstools José freigegeben. Die Betaphase dafür ist damit beendet. faq-o-matic.net » AD-Dokumentation: José 3.2 ist da Aufgrund der Übersichtlichkeit bitte ich aber darum, dass Kommentare, Fehlerbeschreibungen und Änderungswünsche trotzdem in dem Beta-Thread landen: https://www.mcseboard.de/active-directory-forum-79/jose-3-0-betaphase-160129.html Danke & Gruß, Nils

Moin, Kontakte kannst du durchaus per csvde importieren. Dafür dürfte dein Export sogar geeignet sein. Beim Import brauchst du die Option -c, um den LDAP-Pfad anzupassen. Die doppelten Schrägstriche sind normal, weil im DN der Objekte ein Komma steht, das maskiert werden muss (das Komma ist ja sonst LDAP-Trennzeichen) und der Schrägstrich im CSV-Format verdoppelt wird. Ach, und: Natürlich willst du das vorher in einer abgeschotteten (!) Testumgebung testen. Gruß, Nils