olc

Hi blutgraf, grundsätzlich kann man das shon so machen, wie Du es geschildert hast. Jedoch läßt sich die gesamtsicherheit der offline CA nicht mit zwei Sätzen beschreiben. Ob die VM "sicher" ist, ob die berechtigten Personen "sicher" sind, ob das Rack / der Server, auf dem die VM gehostet wird, "sicher" ist - all das sind Fragen, die man im Einzelfall prüfen muß. Die Frage ist also eher, wie Du das ganze in einem größeren Kontext siehst, nicht nur ausschließlich im rein technischen. Dazu gibt es auch eine ganze Menge Literatur. So zum Beispiel: Designing a Public Key Infrastructure: Public Key zu a) Generell kannst Du natürlich eine VM problemlos sichern und "wegsperren". Je nach Sicherheitsbedürfnis der Umgebung spielen dann jedoch der Transport der VM (medium, Transportweg, Zugriffsmöglichkeiten, Kopie-Möglichkeiten etc.) eine wichtige Rolle, zusätzlich die Absicherung des Gasts auf der Host-Maschine. Wer hat hier Zugriff, wer macht Backups etc. Gleiches gilt für den Safe. zu b) Das kommt auf Deine Umgebung an - je nach Größenordnung und nach PKI-Design kann eine mehr als zweistufige CA Sinn machen oder aber auch vollkommen überflüssig sein. Man könnte alternativ aber auch etwa eine offline Root CA und zwei Issuing CAs betreiben. So etwa für Benutzer Zertifikate eine und eine für Devices. Aber da gibt es noch 1.000 andere Konstellationen - wie gesagt, das Design ist von einigen Faktoren abhängig. Grundsätzliche Überlegung: PKI ist ein kritsiches Thema und auch Schlüsselthema in einer IT-Umgebung - es kann also Sinn machen, etwas Geld in die Hand zu nehmen, um einen Dienstleister mit entsprechenden Referenzen mit der Konzeption der CA zu betrauen. Viele Grüße olc

Hallo Andi, im PreExisting Ordner liegen Daten, die während der Initialreplikation auf dem "nicht-autorativen" System vorhanden waren, aber nicht auf dem Primary Member. Wenn Du die Daten wiederherstellen möchtest, schau Dir einmal folgendes Script an: http://blogs.technet.com/filecab/archive/2008/01/02/a-script-to-restore-data-from-the-dfsr-conflictanddeleted-or-preexisting-folders-for-disaster-recovery-purposes.aspx Viele Grüße olc

Hi, ok, dann beschreibe doch noch einmal etwas genauer, was genau Deine Frage ist. Aus den Angaben oben sah es eher nach einer Produktempfehlung aus und nicht nach einer Frage zur VPN- / Firewall-Einrichtung. Viele Grüße olc

Hi, handelt es sich um Windows Server 2003 oder 2003 R2? Fall letzteres der Fall ist, könntest Du DFSR nutzen. Handelt es sich um 2003 Server, schau Dir einmal das SyncToy an. Viele Grüße olc

Hi, nein, der private Schlüssel sollte nie importiert werden - es sei denn, Du mußt Daten wiederherstellen. Das Zertifikat hattest Du in den Trusted Root Store importiert, korrekt? (Schritt 6 des KB). Der Cipher Befehl ist auch korrekt. Viele Grüße olc

Hi aeigb, Du benötigst beide DNS-Namen im Zertifikat, einen beispielsweise als Subject, den anderen als Subject Alternative Name. Schau einmal hier hinein: MSXFAQ.DE - SANZertifkate Viele Grüße olc

Hi Snoopy, ehrlich gesagt habe ich im Moment keine Ahnung, was Du auf die Schnelle noch testen könntest. Soweit sieht ja alles korrekt aus, wahrscheinlich liegt das Problem tiefer. Wenn Du Dir über der Certmgr-Optionen View --> Options auch den "physical store" anzeigen läßt - wo liegt das Recovery Agent Zertifikat? Im Store, der über die Group Policies kommt? Ist unter Umständen lokal in der Registry des SBS noch ein alter Agent definiert? Durchsuche doch einmal alle Stores nach dem DRA - liegt irgendwo noch ein altes Zertifikat herum? Viele Grüße olc

Hi Stephan, vielleicht sind schlichtweg keine Zertifikattemplates vorhanden, auf die die Clients Lese- und Autoenrollment Berechtigungen haben? Prüf das doch noch einmal - oftmals liegt das Problem näher als man denkt. Geht es um Benutzer oder Computer Autoenrollment oder beides? Du könntest das erweiterte Autoenrollment Logging aktivieren, siehe dazu Troubleshooting (Certificate Autoenrollment in Windows Server 2003) Viele Grüße olc

Hi Sascha, das macht irgendwie keinen Sinn: Warum sollte das Quota für DFSR ein Problem sein, wenn es auf "Soft" eingestellt ist? Hast Du das auf dem Problemserver geprüft oder nur auf dem Quellserver? Die Quotas können sich unterscheiden, da Du diese auf jedem Server festlegen mußt. Habt Ihr vielleicht mit den alten Disc-Quotas etwas gedreht, so daß das Problem nicht die FSRM-Quotas sind, sondern die Disk-Speicherkontingente? Im Ereignisprotokoll von DFSR müßten bei harten Limits ebenfalls Events zu finden sein, daß die HDD voll ist. Wird hier etwas geloggt? Viele Grüße olc

Hi, ja, das stellt FRS sicher. Aber das ist doch in Deinem Szenario nicht relevant, denn Du betreibst nur einen Server und es werden daher keine Daten repliziert, wie Du sagst. Auf einem DC würde ich FRS trotzdem nicht abstellen, auch wenn es der einzige DC der Domäne ist. Laß den Dienst also am besten in dem Status, in dem er standardmäßig ist. Bei dem Thema: Nur einen DC in einer Domäne zu betreiben kann schnell ein großes Problem werden. Vielleicht wäre es sinnvoll, hier noch einen zweiten DC zu platzieren. Viele Grüße olc

Hi, Was genau meinst Du damit? So richtig verstehe ich die Aussage nicht. :) Wenn Du keine Daten replizierst und es auch kein DC ist, dann ja. Aber was meinst Du mit "deinstallieren" - meinst Du "deaktivieren"? Viele Grüße olc

Hi, Hier stimmt etwas nicht. Entweder es ist ein selbstsigniertes Zertifikat oder es ist ein Zertifikat, welches von einer CA ausgestellt wurde. Also scheinbar nicht selbstsigniert, sondern ein CA issued certificate. Das importieren des Root CA Zertifikats bringt hier nur die halbe Miete, denn scheinbar ist die CRL nicht erreichbar. Laß doch einmal den folgenden Befehl gegen das TS-Zertifikat laufen: C:\> certutil -v -verify -urlfetch Zertifikat.cer Dort wird sicherlich zu sehen sein, daß die CRL ("CDP") entweder abgelaufen oder nicht erreichbar ist. Das muß dann von Dir geändert werden. Viele Grüße olc

Hi, was passiert, wenn Du es mit $field.text = Invoke-Command { Get-Service } versuchst? Viele Grüße olc

Hi Sascha, willkommen an Board, :) es sieht eher so aus, als ob ein Hard-Quota verwendet wird. Ansonsten wäre das (Soft-)Quota ja kein Problem. Prüf das doch noch einmal auf dem Problemserver. Schau einmal in die folgende F.A.Q. - unter Umständen hast Du das DfsrPrivate Verzeichnis nicht ausgeschlossen? Denn im Normalfall ist SYSTEM ja nicht der Besitzer der Dateien im Share: Distributed File System Replication: Frequently Asked Questions Viele Grüße olc

Hi pastors, die Fehlermeldung gibt doch eigentlich recht genau Aufschluß darüber, was im Request fehlt. ;) Du hast scheinbar nicht angegeben, welches Zertifikattemplate Du nutzen möchtest, um das Zertifikat auszustellen (Schalter "CertificateTemplate). Ich vermute, Du wirst "WebServer" oder "Server Authentication" benötigen. Falls Dir das nicht weiter hilft, poste doch einmal die Certreq-Datei. Viele Grüße olc

Hi Andi, laß doch einmal die Ausgaben der Befehle in eine Textdatei schreiben. Vielleicht wird ja ein Fehler geloggt. net use x: \\meinserver\Daten /persistent:no > NUL: 2>&1 x:\Archiv\Software\robocopy x:\Archiv\Software\Beispiel\Unterordner C:\Beispiel\Unterordner > gut.txt 2> fehler.txt Viele Grüße olc

Hi Andi, interessant, konnte es bei DFSR Eventlogs nachvollziehen... Ich checke das nochmal etwas genauer, wenn ich Zeit habe. :) In der Zwischenzeit kannst Du Dir mit der PowerShell und "Get-EventLog" helfen. ;) Viele Grüße olc

Hi, Ich hatte den DN oben schon aufgeführt: CN=Certificate Templates,CN=Public Key Services,CN=Services,CN=Configuration,DC=domain,DC=tld Je nach Umgebung vielleicht eine Replikationsverzögerung nach Installation der CA? Ist schwierig / unmöglich mit den vorliegenden Daten zu sagen. Viele Grüße olc

Hi, hast Du (nur zur Sicherheit) mal den Server oder DCOM Dienst neu gestartet? Viele Grüße olc

Hi Karl, der angegebene Weg ist doch recht umständlich. Schau doch einmal auf den problematischen DCs, ob überhaupt ein Domain Controller Authentication / Server authentication Zertifikat vorhanden ist. Am einfachsten über MMC --> Snap-In hinzufügen --> Zertifikate --> lokaler Computer --> Eigene --> Zertifikate. Falls nicht (oder abgelaufen), wäre hier der Ansatz das zu ändern. ;) Viele Grüße olc

Hi, am Administrator-Konto dürfte es nicht liegen, denn es funktioniert ja auf anderen Systemen lokal. Scheinbar hat der SBS immer noch nicht die Information, daß es einen korrekten DRA gibt. Daher scheitert die Verschlüsselung SBS-lokal als auch Remote. Ich würde also - auch wenn es erst einmal überflüssig scheint - noch einmal ganz genau auf dem SBS prüfen, ob das aktuelle DRA-Zertifikat wirklich angekommen ist. war der RSOP Export oben vom SBS oder vom Client? Falls vom Client, mach noch einmal einen RSOP Report vom SBS. Viele Grüße olc

Hi, es ist ein neuer KB-Artikel dazu veröffentlicht worden, schaut einmal hier hinein: You receive an error message that contains the event ID 11 error code when you try to update your Windows Vista-based computer by using Windows Update or Microsoft Update Viele Grüße olc

hi zahni, ich nutze das Tool sehr oft, auch auf Vista / 2008 und W7 / 2008 R2 Hosts. Hat bisher immer geklappt - auch wenn es nicht in der Liste der offiziell unterstützten Systeme zu finden ist. :) Und da die CMD oben lokal ausgeführt wird und nicht remote, würde ich das eher ausschließen (also von XP zu 2008). Es sei denn, Andi hat das unterschlagen. ;) Viele Grüße olc

Hi Andi, wenn Du andere Eventlogs abfragst (ggf. auch auf anderen Servern), tritt das Problem dann ebenfalls auf? Gleicher Befehl, auf einem anderen Client ausgeführt oder auf dem DFSR-System selbst ausgeführt, ebenso? Viele Grüße olc

Hi Ninu, builtin gibt es keine solche Funktion, aber Du kannst das im Prinzip ja scripten. Das Script reicht ja einmal am Tag, es muß nicht permanent gegen die AD laufen. Schließlich wird die GAL ja auch nicht sofort auf den Clients aktualisiert - die Verzögerung sollte also eigentlich kein Problem darstellen. Ansonsten gibt es Provisioningsysteme, die das leisten können. Aber die kosten meist richtig Geld. Viele Grüße olc