olc

Hey Mike, optimal - vielen Danke für Deine Rückmeldung. :) Viele Grüße olc

Hi, such einmal nach dem String (Namen) des gelöschten DFS Namespaces in der Registrierung aller beteiligten DFSN Server. Ich denke, irgendwo sollte es da hängen. Viele Grüße olc

Hi, die Berechtigungen habe ich bei meinem letzten Post übersehen, bitte entschuldige. ;) Es fehlen den DCs die Autoenrollment-Rechte. Deine derzeitige Konfiguration sieht laut Deinem zweiten Post so aus: Auth. Benutzer: L Dom. Admins:L/S/R Dom. Controller: R Dom. Controller der Organisation: R Du brauchst aber für das automatische Enrollment auch die entsprechenden Rechte. Insgesamt benötigt also zum Beispiel die Gruppe der "Domänen Controller": Dom. Controller: Lesen, Registrieren, Auto-Registrieren Ich hoffe die Übersetzungen sind korrekt, im Englischen ist es "read, enroll, autoenroll". Alternativ kannst Du die CertServ Webseite nutzen oder den CertMgr.msc und das ganze manuell durchführen. Autoenrollment macht jedoch in vielen Fällen mehr Sinn. Viele Grüße olc

Hi, sorry - ich habe scheinbar anstatt des Links How to rebuild the SYSVOL tree and its content in a domain offensichtlich noch einen alten Link aus einem anderen Post im Zwischenspeicher gehabt. :D Ich meinte natürlich den von Dir genannten Artikel, der Hinweis auf D2 / D4 war auf den KB zugeschnitten. :) Keine Einwände, ein Backup der beteiligten Systeme sollte natürlich vor einer solchen Aktion immer existieren. Viele Grüße olc

Hi, ok, Du möchtest also nicht selbst Zertifikate ausstellen, sondern nur "Fremdzertifikate" verwalten. Das geht mit einer MS PKI nicht. Eine konkrete Lösung außer Scripts oder Gruppenrichtlinien wäre mir in dem Fall nicht bekannt. Viele Grüße olc

Hallo Mike, Du mußt zwischen der SYSVOL (FRS) und der DFSR Replikation trennen, das sind zwei verschiedene Techniken. Oder repliziert Ihr die Nutzdaten auf dem R2 auch noch über FRS anstatt von DFSR? Wäre zumindest nicht so optimal. ;) Für das SYSVOL könntest Du versuchen, einen SYSVOL Restore zu fahren, etwa mit D2 oder D2 / D4, siehe dazu: https://www.mcseboard.de/post6-957558.html Viele Grüße olc

Hi, Christoph hat Dir oben schon die richtige Fragen gestellt: https://www.mcseboard.de/post6-957558.html ;) Viele Grüße olc

Hi, unter Windows Server 2008 könnte es im "v2" Zweig liegen: "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Dfs\Roots\domainV2" Ansonsten gibt es bei DFSUTIL einen "/cleanup" befehl (oder so ähnlich), der sollte das automatisch erledigen. Viele Grüße olc

Hi Ben, je nachdem, was Du konkret machen möchtest, kann eine MS CA durchaus interessant sein. Gut sind die Bücher von "Brian Komar" zu dem Thema, so etwa Windows Server 2008 - PKI- und Zertifikat-Sicherheit von Brian Komar erschienen bei Microsoft-Press (gibt es auch für 2003). Ansonsten gibt es bei MS direkt einige Ressourcen dazu. Einfach mal auf Technet nach "PKI" oder "CA" suchen. Viele Grüße olc

Hi Mike, schau einmal hier hinein, wahrscheinlich läufst Du in das selbe Problem: https://www.mcseboard.de/windows-forum-ms-backoffice-31/sysvol-repliziert-andere-dfs-staemme-schon-152548.html Viele Grüße olc

Hi, je nachdem, ob Du nur ein paar Pings absenden möchtest oder mehr erwartest, könnte vielleicht auch der BROFMON interessant für Dich sein: Windows Server How-To Guides: AD Monitoring mit BROFMON - ServerHowTo.de Viele Grüße olc

Hi Stefan und willkommen an Board, :) grundsätzlich sollten die Einstellungen auch in Windows 7 greifen. Jedoch gab es ab Vista einige Veränderungen an Ordnerumleitungen, so daß es nun zwei verschiedene "Versionen" davon gibt (also 1x bis XP / 2003 und 1x ab Vista / 2008). Wenn Du also komplett auf Windows Vista / 7 umgestiegen bist, kannst Du die Einstellungen grundsätzlich noch einmal anpassen. Das ist dann jedoch nicht mehr abwärtskompatibel. Aber wie gesagt, in dem derzeitigen Status sollte es problemlos klappen. P.S.: Ein kleiner Test sollte das auch zeigen. ;) Viele Grüße olc

Hi, Jepp, mein Fehler. Ich war mir sicher, daß sich damit auch Kennwörter speichern lassen, was jedoch standardmäßig nicht der Fall ist. Entschuldige. Der Hinweis von Tobikom sieht doch aber auch gut aus. :) Viele Grüße olc

Hi pastors, die sauberste Lösung ist meiner Meinung nach ein DCPROMO. Da Du kein normales Demoting mehr vornehmen kannst, würde ich so vorgehen: 1. DCPROMO /FORCEREMOVAL auf dem Niederlassungs-DC 2. Metadata Cleanup des Niederlassungs-DCs auf dem Haupt-DC, inkl. DNS Säuberung etc. 3. Erneutes DCPROMO des Zeigstellen-DCs Dabei solltest Du beachten, daß Benutzer der Zweigstelle in dieser Zeit an einigen Stellen eventuell Probleme bekommen können, je nach Netzwerkverbindung. Daher würde ich den Vorgang außerhalb der Betriebszeiten durchführen. Zusätzlich hast Du das Problem, daß Änderungen am Zweigstellen DC nun nicht mit dem DC der Zentrale mehr synchronisiert sind - und das betrifft nicht nur neue Benutzer oder Änderungen an Benutzer, Gruppen, Druckern etc. Vielmehr sind auch Computerkennwörter und Benutzerkennwörter auf den DCs unterschiedlich. Daher wird es mit Sicherheit zu Problemen in der Zweigstelle kommen, wenn Du den DC demotest. Das solltest Du auf dem Schirm haben und ggf. Vorsichtsmaßnahmen treffen. Ich gehe davon aus, daß alle FSMO Rollen auf dem Zentrale-DC liegen, korrekt? Andere Applikationen sind auf dem Niederlassungs-DC nicht installiert? Am besten Du schraubst auch gleich die TombstoneLifetime auf 180 Tage hoch, damit Du zukünftig nicht mehr "so schnell" in Probleme läufst. Ein rudimentäres Monitoring hätte hier auch schon Wunder gewirkt. ;) Viele Grüße olc

Wirklich gut gemachte Videos, klasse Sache. :) Viele Grüße olc

Hi Mini, schön, daß es geklappt hat. Vielen Dank für Deine Rückmeldung. :) Viele Grüße olc

Hi, da Du PuTTY schon angesprochen hast - warum verwendest Du es dann nicht? ;) PuTTY kann auch Telnet - einfach den Connection Type von SSH auf Telnet umstellen (direkt in der Verbindungsübersicht). Ansonsten geht auch PuTTYtel. PuTTY Download Page Viele Grüße olc

Hi zahu, mit "typeperf" kannst Du doch mit ganz wenig Aufwand die vier "Zahlenwerte" exportieren. Ansonsten stehen Performance Counter zur Verfügung, per WMI kann man auch einige Dinge abfragen. Aber wie gesagt, noch einfacher als mit "typeperf" geht es kaum. Viele Grüße olc

Hi, es gibt verschiedene Möglichkeiten, die Du für Dein Vorhaben nutzen kannst. Wenn es nicht nur Batch-Dateien sein sollen, kommt fast jede Scriptsprache in Betracht, mit der Du Daten direkt per WMI oder ähnlichem auslesen kannst. Sollen es ausschließlich Batch-Dateien sein, kannst Du an die Performance Werte zum Beispiel mit Typeperf auslesen und die Ereignisprotokolle beispielsweise mit PsLogList . Schau Dir zusätzlich auch einmal den LogParser an: Windows Server How-To Guides: Auswertung von Eventlogs mit dem MS-Logparser - ServerHowTo.de Viele Grüße olc

Hi SBK, genau - denn die Einstellungen liegen sonst weiterhin in der Datei "Registry.pol", die im Sysvol für die Gruppenrichtlinienclients bereitsteht. Wenn der Editor in dieser Datei also die von Dir definierten Registry Schlüssel findet, jedoch keine "Interpretationsvorlage" (also keine entsprechende ADM / ADMX Datei), dann kommt es zu dem Fehler. Je nachdem, ob Du die Einstellungen weiter in der GPO behalten willst oder nicht, macht es also unter Umständen Sinn die ADM-Dateien einfach zu behalten. Ansonsten bleibt auch die Variante, die Gruppenrichtlinie selbst zu löschen - was natürlich nur dann Sinn macht, wenn die gewünschten Einstellungen von Dir vorher in eine andere GPO übernommen wurden. Wichtig für das Verständnis ist es sich immer wieder ins Gedächtnis zu rufen, daß die ADM-Dateien selbst keinerlei konfigurierte Werte enthalten - es sind lediglich die Vorlagen, die genutzt werden, um die gewünschten Registry-Werte im GPO-Editor "lesbar" darzustellen. Die Einstellungen selbst bleiben in der o.g. Datei auch ohne ADM-Templates in der GPO vorhanden, bis man sie wieder entfernt. Warum möchtest Du denn die ADM-Dateien löschen? Was ist der Hintergrund für das Vorhaben? Viele Grüße olc

Hi, die Fehlermeldung sollte verschwinden, sobald Du die Einstellungen in der jeweiligen Gruppenrichtlinie entfernt hast, die Du über diese ADM-Templates zur Verfügung hattest. D.h. also die Word, Ecxel, PPT etc. Settings. Viele Grüße olc

Hi, d.h. Du sprichst nicht von Benutzerzertifikaten, sondern vom Data Recovery Agent. Wenn intern keine CA vorhanden ist, kannst Du mit dem oben angesprochenen "cipher.exe" ein neues Zertifikat erstellen und in die "Default Domain Policy" einbinden. Siehe dazu: Windows Server How-To Guides: Teil 2 - Einrichtung von Data Recovery Agents - ServerHowTo.de Viele Grüße olc

Hi Nils, die Ereignisprotokoll-Inhalte kann man nicht so einfach "touchen". Daher auch der Hinweis darauf. Den Vorschlag mit den Inhalten von Log-Dateien habe ich auch explizit als nicht optimal gekennzeichnet, da dies leichter zu manipulieren ist. ;) Viele Grüße olc

Hi Mini, nach knappen 4 1/2 Stunden zu pushen, ist schon eine harte Nummer. Dienstleister nehmen da richtig Geld für, vielleicht solltest Du daher einmal einen Dienstleister mit SLA in Erwägung ziehen und nicht ein kostenfreies Forum dafür einbinden... :wink2: Deine Beschreibung läßt leider keine Hilfe zu, denn im Moment ist vollkommen unklar, ob Ihr eine CA betreibt oder ob Ihr pro Client einfach ein selbstsigniertes Zertifikat verwendet. Ein Anfang wäre also, wenn Du uns einen Hinweis gibst, ob Ihr eine CA betreibt. Falls ja, kann das EFS Template entsprechend angepaßt werden, um manuell oder automatisch neue EFS Zertifikate auszustellen. Wenn keine interne CA vorhanden ist, stellen die Clients selbst ein Zertifikat aus. Das sollte im Normalfall automatisch passieren. Wenn das nicht der Fall ist, kann man dafür beispielsweise "cipher.exe" verwenden. Beschreib doch bitte noch einmal etwas genauer, wie genau Eure Umgebung aussieht, was Ihr konkret erreichen wollt und was genau der Fehler / das Problem ist. Viele Grüße olc

Hi Btytesplit, das "read only" ist deshalb ausgegraut, weil das Betriebssystem nicht bei jedem Zugriff in den Tiefen des Verzeichnisses prüfen kann, ob schreibgeschützte Daten vorliegen. Daher "gaukelt" es Dir einen potentiellen "nur Lesezugriff" vor. Unter welchen Rechten läuft der Dienst denn, der die Daten schreiben soll? Du könntest zum Beispiel ein "Auditing" auf dem Ordner einrichten, um fehlschlagende Zugriffsversuche zu loggen. Woran machst Du fest, daß der Dienst nicht schreiben kann? Vielleicht liegt das Problem ja auch an andere Stelle und Du vermutest nur, daß der Schreibzugriff fehlschlägt. Viele Grüße olc