olc

Hallo, soweit ich mich entsinnen kann wird bei einem "failed to impersonate...." schlichtweg versucht, bestimmte Aktionen durchzuführen, die beispielsweise erhöhte Rechter erfordern (würden). Klingt erstmal beunruhigend - ist aber im Normalfall kein Problem. Wenn es mit der gewünschten Aktion nicht klappt wird ein anderer Weg gewählt bzw. die Aktion nicht weiter verfolgt. Da sind interne Prozesse im Spiel, die ich Dir jedoch auch leider nicht genauer auseinandernehmen kann. Man muß sich beim Userenv halt vor Augen führen, daß es ein erweitertes Logging ist. Somit werden unter Umständen auch Events geloggt, die für Deine Analyse nur untergeordnete Bedeutung haben. Interessant sind nicht nur die beiden von Dir geposteten Zeiten / Aktionen, sondern das, was dazwischen passiert... Überprüfe nach Möglichkeit einmal meinen Hinweis oben (cmd.exe Aufrufe), überprüfe das Ereignisprotokoll und logge ggf. den Netzwerktraffic und die Netlogon Geschichten... [EDIT] Schau einmal hier hinein - dort sind ein paar Informationen zur Interpretation des Userenv Logs zu finden: Microsoft Corporation [/EDIT] Viele Grüße olc

Hi, trägst Du den FQDN der CA in die vertrauenswürdigen Seiten des anfragenden IE ein, klappt es auch ohne Authentifizierung. ;) Hintergrund ist, daß der FQDN vom IE nicht als "Intranet" Zone eingeordnet wird sondern in die "Internet" Zone und daher keine Kerberos / NTLM Daten mit der Anfrage an die certsrv Webseite gesendet werden. Aus diesem Grund mußt Du Dich erst authentifizieren. Intranet site is identified as an Internet site when you use an FQDN or an IP address Viele Grüße olc

Hi, wie viel hast Du für das Board SLA bezahlt, daß Du 1 1/2 Stunden Reaktionszeit verlangst? Dein erster Post war nicht wirklich aufschlußreich, der zweite schiebt den Sinn dann zumindest ansatzweise nach. Was möchtest Du denn gern testen? Bei einem Fileserver ist nicht nur HDD I/O relevant. Von daher mußt Du schon ein wenig genauer spezifizieren, was dein Anliegen ist. Als kurzen Einstieg ohne Anspruch auf Vollständigkeit kannst Du Dir die folgenden Tolls einmal anschauen: CPU Burn-in Homepage Iometer project MSXFAQ.DE - DiskTest Gruß olc

Hi, wenn es sicherheitstechnisch möglich ist poste hier einmal die Userenv Ausgabe. Die "impersonate" Geschichten brauchst Du meist nicht zu beachten. Wird vor der Zeitverzögerung unter Umständen ein, zwei Mal die cmd.exe aufgerufen oder ähnliches? Oftmals sind Scripts für solche Verzögerungen verantwortlich oder auch Virenscanner / Firewalls. Ggf. macht auch ein Netlogon Log bzw. ein Netzwerktrace Sinn. Gruß olc

Hi, ist ein wenig Off Topic... aber herausfordern lasse ich mich immer gern. ;) Ich kenne mich speziellen Treibern oder Software wirklich nicht aus, von daher ist mal wieder ins Blaue raten angesagt. :D Wo stellst Du ein, welches Zertifikat verwendet werden soll? Direkt über die Verbindungssoftware oder verwendet die Software den "Netzwerkkartendialog" des Windows Clients? Im Kern machst Du Netzwerk-Einstellungen - und das ist per se erst einmal nur Administratoren erlaubt. Du kannst versuchen per GPO die benötigten Rechte zu vergeben - aber das greift nur bei den Windows-Einstellungen. Wenn die Treiber der Karte das selbst verwaltet wird das schwierig. Hier würde eine Nachfrage beim Hersteller Sinn machen. Quick & Dirty ist natürlich, den Benutzer kurzzeitig für die Einrichtung der Verbindung Administrator-Rechte zu geben. Aber das ist in größeren Umgebungen weder gangbar noch empfehlenswert. Wie gesagt, kenne mich mit solch spezieller Software nicht aus, aber vielleicht jemand anderes hier? Gruß olc

Arrrggghhhh, das Problem kenne ich. Es hörte sich nach Deiner Beschreibung nur nicht gleich danach an... Sorry. Hintergrund ist, daß für die Authentifizierung Deines Clients immer der SPN als Prinzipalnamen vom Windows Client gesendet wird. Dein Access Point gleicht offensichtlich anstatt des DNS Namens im Subject Name Feld des Zertifikats ausschließlich den mitgesendeten SPN ab --> schon kommt es zu dem Problem. Scheinbar ist das auch bei einigen Cisco 802.1x Radius Produkten der Fall, wenn man eine bestimmte Option setzt, die diesen Wert (also HOST/host.domain.tld) zusätzlich zum DNS Namen prüft. Dieser steht jedoch nicht in der Form im Zertifikat. Müßte man mal im entsprechenden 802.1x RFC nachprüfen, ob dieses Verhalten korrekt ist. Aber wahrscheinlich wird es das sein... Vielen Dank für Deine Rückmeldung! Gruß olc

Hallo, Die klappt bei richtiger Planung und Einrichtung z.B. mit DFS-R wirklich gut. :) Warum bist Du "vorsichtig" geworden. Im HowTo ist das nur in aller Deutlichkeit dargestellt, da es in der Praxis oft zu Problemen führt. Diese Eigenschaft ist derzeit wenig bekannt, daher der Hinweis. Unter Windows Server 2008 ändert sich dieses Verhalten insofern, daß mehr Threads zur Verfügung stehen und daher ein solcher Effekt weit weniger bzw. gar nicht mehr auftreten sollte. Totalausfall heißt weiterhin auch nicht, daß die Replikation "nie wieder" funktioniert. Es bedeutet lediglich, daß innerhalb des Zeitraums, während dessen die betreffende zu große Datei repliziert wird, keine weiteren Daten übertragen werden können. Ist die Datei repliziert, läuft die Replikation im besten Fall langsam wieder an... Im Grunde ist die Aussage wie folgt zu deuten: Plane die Quotas gut und ausreichend groß. ;) Es gibt diverse andere Möglichkeiten, Daten zu replizieren: Angefangen beim guten alten Robocopy oder Rsync bis hin zu ausgewachsenen Lösungen wie DFS-R oder WAFS Boxen. DFS-R ist jedoch wirklich leistungsstark - Du solltest es in deinen Überlegungen auf keinen Fall "beiseite" schieben. Du hast Dir das HowTo durchgelesen - dann müßtest Du es wissen. ;) Die Staging Folder liegen immer unterhalb des Ordners, der repliziert wird (Stichwort DfsrPrivate). D.h. also, daß Du das Staging Folder immer dort finden wirst, wo auch der zu replizierende Ordner liegt (bzw. in diesem Ordner). Die Frage stellt sich also nicht wirklich. Das ist so eine Sache: Mach das Staging Quota so groß wie möglich. Wenn also schon 500GB an Daten auf der 1 TB Partition liegen, wird es mittelfristig Probleme geben. Auch wenn das manchmal sehr schwierig bzw. teuer ist und bei Kunden nicht gut ankommt: Am sichersten fährt man, wenn man das Quota genauso groß oder größer wählt, als die zu replizierenden Daten groß sind. Auch wenn das sehr hart ist. ;) Cool, das habe ich ja auch noch nie hier gelesen. :D Ich war aber mal so frei, Dir ein paar Fragen kostenlos zu beantworten. Hoffentlich jedoch nicht umsonst. ;) Wenn Du weitere Fragen hast leg los. Solange man sie Dir hier beantworten kann, haben alle etwas davon. Gruß olc

...nur mal ein Einwurf nebenbei --> Ihr wißt schon, was man unter dem Begriff "hochverfügbar" versteht? In dem genannten Zusammenhang bzw. den zur Verfügung stehenden Mitteln ist der Begriff wohl eher fehl am Platz oder? ;) Gruß olc

Hallo, ich habe nicht geschrieben, daß sich diese Kombination "empfiehlt". Deine Frage war, ob es funktioniert. Grundsätzlich ist es immer ein Anspruchsfrage und eine Frage der Größenordnung - nach Möglichkeit solltest Du verschiedene Dienste immer trennen. Gerade bei DCs ist dies empfehlenswert. Nur gelingt dies je nach Budet und administrativen Möglichkeiten leider nicht immer. Ob die Last zu hoch ist, läßt sich mit den vorhandenen Informationen kaum sagen. Es gibt dabei so viele Variablen, die dieses Thema schneiden. Wenn Deine DCs beispelsweise derzeit schon mit 50% CPU Last laufen, empfiehlt sich ein weiterer Dienst eher nicht. ;) Die Clients fragen periodisch die Namespaces ab - je anch Anzahl der Namespaces und der Netzwerkstruktur kann hier natürlich ein sehr starkes Anfragevolumen zusammenkommen - hier helfen nur gute Planung und vorausgehende Tests für eine konkrete Aussage. Pauschal kann man das also nicht sagen. Gruß olc

Hallo, vielen Dank für Deine Rückmeldung. Ging also in eine gänzlich andere Richtung... Danke und Gruß olc

Hallo, es gibt ein, zwei Punkte, die ich nicht so ganz verstanden habe. Aber ich versuche mal die zu beantworten, die mir verständlich erscheinen: Vorweg: Über welche Windows Server 2003 Version reden wir hier? Erstes Release oder R2? 1.) DFS ist (zwangsweise) auf den DCs dabei (Stichwort SYSVOL), auf weiteren Memberservern kannst Du DFS ebenfalls problemlos laufen lassen. 2.) Vom DFS-Namespace Server bekommt ein Client nur die Referrals, also die Verweise auf die Freigaben. D.h. der Client greift immer direkt auf die Freigaben zu. Der Traffic wird niemals "über" den / die Namespaceserver "geleitet". 3.) Die Freigabe lag also auf einem NAS, den Namespace hattest Du auf einem Windows Server gehostet, korrekt? Daß Du in diesem Fall weiterhin auf die Freigabe zugreifen konntest, ist korrekt. Auf dem Client werden (für einen definierbaren Zeitraum) die Referrals / Links gecached. D.h. auch bei einem Ausfall der Namespaceserver kann der Client auf die Daten zugreifen - solange diese auf einem anderen System liegen und nicht auf dem Namespaceserver selbst. Die Ausgabe von "dfsutil /pktinfo" zeigt Dir beispielsweise u.a. die Referrals an und auch die Lifetime für diesen Eintrag. Ist diese Lifetime abgelaufen, bekommst Du Probleme, sollte der / die Namespaceserver nicht wieder oben sein. Beantwortet das erst einmal Deine Fragen? Gruß olc

Hallo, leider nein - ist nicht so mein Gebiet der IAS. Mit Store ist gemeint, ob das Root Zertifikat im Trusted Root Store liegt. Du kannst weiterhin mit Rechtsklick auf den Computerstore oder Benutzerstore über "View" / "Ansicht" --> Custom / Optionen (bin mir bei den Bezeichnungen nicht sicher) den "physical view" anzeigen lassen. Liegen die Certs alle im Enterprise Store oder gibt es da Unterschiede? Wenn die Zertifikate aus dem AD kommen, müßten sie alle im Enterprise Store liegen. Hast Du am IAS vielleicht irgend ein Setting gesetzt, welches bestimmte Felder im Zertifikat verlangt? Aber das ist alles nur "ins Blaue". Vielleicht kennt sich hier jemand besser mit IAS aus? Gruß olc

Hallo, das sollte mit der Edition eigentlich nichts zu tun haben (siehe Editionenvergleich unter Wie Sie eine Zertifizierungsstelle einrichten - Microsoft für kleine Unternehmen) - bin aber kein IAS Profi... In welchen Stores liegen die Zertifikate auf dem Client (Userstore, Computerstore, physical view)? Ist im Clientzertifikat als Subject Alternative Name (SAN) der DNS-Name des Clients korrekt eingetragen? Gruß olc

Nachtrag: Das "Profile" Objekt hat folgendes Problem: Replication Collisions in Windows 2000 Ist mir eben erst beim "Durchstöbern" des "ntfrsutl" Logs aufgefallen... :rolleyes: Aber wenn Du es löschst, sollte sich das erledigt haben... Gruß olc

Hallo, Du benötigst mehrere Zertifikate im Store des Clients, damit die Authentifizierung korrekt verläuft: Das Clientzertifikat, das Root Zertifikat der Organisation und ggf. alle Intermediate CAs. Der IAS sendet - soweit ich weiß - sein eigenes Zertifikat beim Request mit zum Client. Wenn man es manuell einstellt glaube ich sogar die ganze Zertifikatkette - bin mir jedoch nicht sicher. In diesem Fall würde der Clientstore die Root und Intermediate CA Zertifikate nicht benötigen. Wie konfigurierst Du die Verbindung? Gibst Du auf dem Client explizit das Root Zertifikat an, welches zur Authentifizierung bzw. Certificate-Chain Validierung verwendet werden soll? Gruß olc

Hallo, Imaging gefolgt von Systemstate Rücksicherung sollte funktionieren, ist aber sicherlich grenzwertig. Wirklich sauber ist bei DCs nur ein Systemstatebackup, kein Image. So, nu' aber wieder zurück zum Thema, sollte es noch etwas dazu geben. ;) Gruß olc

Hi, nur mal so als Einwurf: Es ist durchaus sinnvoll, die Root CA Offline zu nehmen. Damit verringerst Du Diene Angriffsläche auf die CA Struktur und das Risiko, daß diese kompomittiert wird etc. Ist glaube ich auch bei vielen CA Software Herstellern "Best Practice" aber auch irgendwo eine "Glaubensfrage". Wichtig im Zusammenhang mit Windows Server 2003 CAs ist natürlich, daß die Stand-Alone Root CA dann weder Domänenmenber noch DC ist. Letzteres ist auch sonst nicht unbedingt zu empfehlen. Viele Grüße olc

Hi 1982, entschuldige - ich hatte Deine letzte Antwort übersehen... Es ist vollkommen richtig, was Du gemacht hast. In Deinem Fall reicht ein D2. Ich hatte den Artikel verlinkt, da dort auf die Ursachen und auf beide Wiederherstellungsverfahren eingegangen wird. Schön, daß es wieder in Ordnung ist. Viele Grüße olc

Argh, ich hatte extra das NICHT noch fett geschrieben. ;) Bitte DCs NIE über Images sichern bzw. danach rücksichern (Stichwort USN Rollback). Aber das ist ein anderes Thema - ist sicherlich hier im Board schon des öfteren besprochen worden. :) Also, bis dahin erstmal. Gruß olc

Hallo, vielleicht kannst Du zusätzlich zur Systemzeit des Hostsystems einmal prüfen, ob Du die "Shared Folders" auf dem VMWare Host aktiviert hast bzw. ob Du diese Funktion mit den VMWare Tools mit auf dem Gast installiert hast. Meiner Erfahrung nach gibt es ab und an die wildesten und kaum nachvolllziehbare Fehler, wenn die Shared Folder aktiv sind. Gruß olc

Sicher ist nur der Tod. :D Nein, mal im Ernst: Wenn Du von den Servern für den Notfall ein geprüftes Backup hast ( Backup heißt nicht Image bei DCs ! ), sollte das machbar sein. Wichtig ist nur, daß die Rücksicherung ggf. auch funktioniert. ;) Zu beachten ist, daß nach dem Löschen des FRS Sets über ADSIEdit diese Änderung auf die anderen DCs repliziert wird. Wenn Du es gar nicht anders wagen willst, kannst Du den DC, auf den Du Dich für die Löschung verbindest, temporär vom Netz nehmen oder die OUTBOUND Replication abschalten. Aber das nützt Dir wahrschenlich recht wenig, weil Du dann nicht verifizieren kannst, ob die Änderung auf dem FRS Server "S2" (?) Erfolg hatte. Weiterhin mußt Du direkt auf dem Computerobjekt des betroffenen Servers (ich glaube "S2"?, habe es grad nicht mehr im Kopf) die NTFRS Subscription löschen. Navigiere dazu mit ADSIEdit zum Computerobjekt, erweitere es, öffne die NTFRS Subscription und lösche den entsprechenden "Profile" Eintrag. Ich denke nicht, daß etwas beim Löschen des Profile Objekt schief geht - aber an der Stolle trotzdem noch einmal eingeschoben, daß alle Angaben wie immer ohne Gewähr sind. ;) Viel Erfolg und viele Grüße olc

Guten Abend, Soweit "so gut". Ich wollte durch das Überprüfen des Dfs-Configuration Containers noch einmal prüfen, ob Du nicht doch über die GUI herankommen könntest. Aber das ist dann leider nicht möglich. Du hast vollkommen Recht, im Container File Replication Service liegt die entsprechende Konfiguration. Die Frage, die man sich an dieser Stelle stellen sollte ist, was diesen "inkonsistenten" Zustand hervorgerufen hat. Auf welchem Betriebssystem laufen Deine DCs? Du solltest nach Möglichkeit einmal nach "lingering objects" suchen: Microsoft Corporation Du kannst Dir die Daten bei allen CMD Ausgaben (losgelöst von dieser speziellen also auch bei allen anderen) entweder seitenweise ausgeben lassen, indem Du die Ausgabe an "more" übergibst, also z.B. ntfrsutl sets | more oder indem Du die Ausgabe in eine Datei umleitest, die Du dann auch bequem durchsuchen kannst etc. (in diesem Fall die bevorzugte Variante): ntfrsutl stes > C:\ntfrsutl.txt . ;) Daß das Replikaset dort angezeigt wird ist in Ordnung und war zu erwarten, also soweit klar. Das mit den Fehlern sollte "in Ordnung" gehen, also kein großes Problem darstellen. So wie ich das im Moment sehe, hast Du ja keine Namespaces auf dem Server, die angezeigt werden sollten... Du mußt DFS (also die Bereitstellungsräume / Namensräume) von FRS (dem Replikationsdienst) im Geiste trennen. Es sind zwei verschiedene Techniken. Siehe meine Bemerkung von oben - es sind zwei verschiedene Techniken. Wenn Du den alten Namespace nicht mehr hast (Dfs-Configuration Container im Configuration NC), dann kann dieser auch nicht mehr angezeigt werden. Doch, genau das wäre der nächste Schritt. ;) Wenn Du damit durch bist und Dir sicher bist, daß es keine Probleme mit dem FRS Set "Profile" geben wird, kannst Du den Container "Profile CNF:3f3cdb7b-50c0-4c81-bd6b-c5fb133ab39a" löschen. Bitte überprüfe dann, ob der Container auf den anderen DCs nach erfolgter Replikation ebenfalls gelöscht ist (falls er überhaupt überall vorhanden ist - siehe "lingering objects" oben). Es ist mir kein Tool bekannt, mit dem man ansonsten FRS Sets löschen könnte. Falls jemand anderes einen Tipp hat - immer raus damit. ;)

Hallo, zu Deiner Frage 1): Das Prinzip der asymmetrischen Verschlüsselung ist, daß der Antragsteller die privaten Schlüssel hält. Diese lassen sich zwar auch exportieren oder archivieren - erzeugen wird (und muß) der Antragsteller diese Schlüssel jedoch selbst. zu Frage 2): Das ist der Fall, wenn Du Deine untergeordnete Zertifizierungsstelle als Sub CA konfiguriert hast. Wenn Du das nicht getan hast, ist sie auch nicht Sub CA. ;) Bei der Installation mußt Du angeben, ob es sich um eine untergeordnete Zertifizierungsstelle handelt. Falls ja, übergibst Du den Zertifikatrequest an die Root CA, die das Zertifikat dann ausstellt. Am einfachsten bzw. wahrscheinlich am schnellsten kannst Du prüfen, ob das Zertifikat der Root CA "untergeordnet" ist, indem Du das ausgestellte Sub CA Zertifikat öffnest, die Details auswählst und die Hierarchie überprüfst. Weiterhin siehst Du in den Zertifikatdetails auch den Ausstellernamen. Dieser müßte Deiner Root CA entsprechen, sowie ebenfalls auch AIA und CDP auf die Zertifikate bzw. Sperrlisten der Root CA verweisen sollten. Anbei noch ein Link zum Thema mit vielen relevanten Details: Checklist: Creating a certification hierarchy with an offline root certification authority Microsoft Corporation Viele Grüße olc

Hallo, im Text steht nur etwas von einem "S1", in der Fehlermeldung steht jedoch, daß die Replikation zum "S2" nicht funktioniert. Ist das ein Schreibfehler oder gibt es noch einen "S2" in der Konstellation? Schau doch einmal auf dem Server "S5", der die Meldungen loggt, mittels ADSIEdit unter "CN=Dfs-Configuration,CN=System,DC=<domain>,DC=<tld>" an, welche DFS Roots dort definiert sind. Wird Dir dort unter Umständen der alte Link angezeigt? Sollte eigentlich nicht der Fall sein, da es sonst auch in der DFS Konsole angezeigt werden müßte. Zeigt Dir ein NTFRSUTL SETS das alte Replica Set an? Mittels DFSUTIL.EXE sollten sich die Targets eigentlich löschen lassen. Aber das geht natürlich nur wenn Du weißt wie sie heißen. Eine Übersicht der möglichen Befehle bekommst Du mit angehangenem "/?". Ich empfehle Dir vor allen weiteren Aktionen ein Backup Deiner Daten anzulegen und nur mit Bedacht etwaige Löschaktionen durchzuführen... Gruß olc

@Daim: Danke, daß Du das noch einmal herausgestellt hast. Ich habe den ersten Post des TO so interpretiert, daß der Replikationsdienst bereits auf einem der beiden Server läuft. Das setzt das Schema Update voraus. Vielleicht war meine Vermutung nicht korrekt - also vollkommen richtig Dein Einwand. Danke und Gruß olc