olc

Hi Stephan, was genau ist Deine Frage, eine komplette Anleitung wird wahrscheinlich kaum jemand posten wollen? ;) Als Startpunkt kannst Du die Whitepaper / Technet Dokumente von MS durchstöbern, so etwa: Network access authentication and certificates: Virtual Private Network (VPN) Computer certificates for certificate-based authentication: Internet Authentication Service (IAS) Ansonsten hatte grizzly999 vor einiger Zeit einmal ein HowTo dazu fertig gemacht - aufgrund der fehlenden Informationen Deines Eröffnungsthreads bin ich mir nicht sicher, ob es zu Deiner Fragestellung paßt: Windows Server How-To Guides: Einrichten einer L2TP/IPSec Verbindung mit Zertifikaten - ServerHowTo.de Viele Grüße olc

Hi, wie genau lautet denn der Fehler? Welche Tools möchtest Du installieren? Viele Grüße olc

Hi D., schau einmal mittels Start --> Ausführen --> "control keymgr.dll" --> Enter, ob unter Umständen die Credentials des Administrator Accounts für die SharePoint Ressource im Credential Manager hinterlegt wurden (bei einem früheren Zugriff). Falls ja lösche diesen Eintrag, danach sollte es funktionieren. Viele Grüße olc

Hi, was passiert, wenn Du direkt auf das Share zugreifst und nicht über den DFS-Namespace gehst? Unter Umständen ist hier auf dem Namespace ein fehlendes Recht Schuld an dem Problem. Wie genau lautet die Fehlermeldung beim Zugriff / Synchronisationsversuch des XP Clients? Soweit ich weiß gab es unter SMB 2.0 auch Änderungen was die Offline Files betrifft, von daher läßt sich XP und Vista als Client auf einem 2008er Server schwer vergleichen. Viele Grüße olc

Hi tux_domi, ich persönlich finde es recht sinnvoll, daß man komplexe Kennwörter verwendet. Warum vergibst Du also nicht einfach eines? ;) Dann klappt auch die Kennwort-Vergabe. Danach kannst Du ggf. die entsprechende Policy auch noch ändern. Siehe auch Strong Passwords and Password Security | Microsoft Security [EDIT] Sunny61 war schneller... [/EDIT] Viele Grüße olc

Hi Jochen, ganz so einfach ist das nicht... :wink2: Vielleicht beschreibst Du noch einmal den Hintergrund für Dein Anliegen. Im Kern kannst Du einige Verfahren des Forest Recovery fahren, aber sicherlich gibt es bessere Möglichkeiten. Download details: Forest Recovery Download details: Best Practices: Active Directory Forest Recovery Auch das autorative Wiederherstellen des Domain und Config NC sollte gut überlegt und im besten Fall vermieden werden. Geht es unter Umständen "nur" um einige Benutzer- oder Gruppenobjekte oder ist da mehr im Argen? Viele Grüße olc

Hallo Reinhard. :) Ggf. lohnt je nach Kenntnisstand auch ein Blick in den ersten Teil der HowTos: Windows Server How-To Guides: Planung, Installation und Konfiguration des Distributed File System (DFS) unter Windows Server 2003 R2 - ServerHowTo.de Die Frage ist nicht so einfach zu beantworten - von daher nur ein paar grundlegende Punkte dazu, man muß das immer im Einzelfall entscheiden: Wenn es tatsächlich um Ausfallsicherheit geht, wäre in den meisten Fällen je nach Budget ein Cluster mit gespiegeltem SAN dahinter (oder ähnliches) sinnvoll. DFSR ist (wie im HowTo kurz angesprochen) nur ein "Cluster für Arme" und meist nicht empfehlenswert. Der Anwendungszweck geht eher in Richtung Datenverteilung (data distribution), etwa von Read-Only Dokumenten aus der Zentrale zu den Außenstandorten, oder aber der Datensammlung (data collection), etwa für Backups in einer zentralen Lokation. Das Problem besteht bei DFSR meist darin, daß bei gleichberechtigten Servern Benutzer auf beiden Servern arbeiten können - somit entstehen Konflikte, wird am gleichen Dokument gearbeitet. Es gibt derzeit kein "Sperren" (file locking) der Dateien auf verschiedenen DFSR Servern. Spätestes, wenn bei einem Ausfall die Benutzer mittels DFSN auf den zweiten Server umschwenken und der erste Server irgendwann wieder online geht, kommt es fast zwangsweise zu Problemen. Also kurz zusammengefaßt: Im Normalfall ist für die Ausfallsicherheit eher ein Cluster geeignet. Willst Du hingegen beispielsweise Daten für ein Backup auf ein zweites System replizieren, ist DFSR goldrichtig. Viele Grüße olc

Hi, du bist doch aber (hoffentlich) kein Chamäleon. ;) Deutsch: 9783860639733 Englisch: 9780735620216 Ich würde Dir das englische Buch empfehlen - die deutsche Übersetzung enthält meiner Erfahrung nach einige schlechte Übersetzungen bzw. üble Übersetzungsfehler und bringt einige Zusammenhänge nicht so gut rüber wie das Original. Viele Grüße olc

Hi, das Buch ist eine Überarbeitung des 2003er Buchs, von daher solltest Du darin auch alles zu 2003 finden. Der Autor trennt zwischen 2003er und 2008er CAs. Das reine 2003er Buch ist außerdem teilweise immer noch erhältlich. Jede Beschreibung in einem Buch ist im Grunde eine Übung: Stell es nach, teste damit herum und Du übst besser als beim typischen "klicken Sie hier und klicken Sie da". ;) P.S.: Wie viele Benutzeraccounts willst Du noch anlegen, bevor Du bei einem allgemeinen Profil bleibst? :wink2: Viele Grüße olc

Hi, das PKI Buch für Administratoren und Planer ist meines Erachtens das folgende: Microsoft Windows Server 2008 - PKI- und Zertifikat-Sicherheit von Brian Komar erschienen bei Microsoft-Press Darin sollten all Deine Fragen beantwortet werden. Ansonsten online bei MS beispielsweise unter: Bereitstellen und Unterstützen einer PKI bei Microsoft Implementing and Administering Certificate Templates in Windows Server 2003 Best Practices for Implementing a Microsoft Windows Server 2003 Public Key Infrastructure Viele Grüße olc

Hi, also bei mir war es das erste Ergebnis in zwei Suchmaschinen: Active Directory Replication over Firewalls Zu beachten ist dabei, daß sich unter Windows Server 2008 die Dynamic RPC Ports zumindest standardmäßig geändert haben, ggf. muß hier auch noch geschraubt werden, wenn vorher nur 2003 im Einsatz war: The default dynamic port range for TCP/IP has changed in Windows Vista and in Windows Server 2008 . Grundsätzlich kann (und sollte) man immer überlegen, ob es nicht Sinn macht, zumindest die Kommunikation zwischen DCs ungehindert laufen zu lassen und die Firewall zwischen DCs komplett zu öffnen. Viele Grüße olc

Hi, schaue doch einmal auf einem DC mit der AD User & Computer MMC oder mittels "dsquery user USERNAME", wo der Benutzer liegt. Das sollte Dich weiterbringen. :) [EDIT] Ok, da warst Du selbst schon schneller. ;) [/EDIT] Viele Grüße olc

Hi, Du kannst in der Ursprungspolicy mit einem Rechtsklick auf den Internet Maintenance Knoten die Einstellungen wieder zurücksetzen. Dabei wäre zu brachten, daß dabei ggf. auch andere Einstellungen der Policy, die in der IE Maintenance gemacht wurden, wieder verloren gehen. Ggf. kannst Du meines Wissens auch einzelne Einstellungen zurücksetzen, in dem Du auf dem entsprechenden "Unterknoten" mittels Rechtsklick den "reset" durchführst. Bin mir mit letzterem jedoch nicht 100% sicher und habe gerade leider kein Testsystem. Schau doch zusätzlich einmal hier hinein: How to use Reset Internet Explorer Settings (RIES) . Viele Grüße olc

Hi, Hi, würde ich auch vermuten. Siehe Aktives Verzeichnis Blog : ADPREP "multi-language" ;-) Viele Grüße olc

Hi, ehrlich gesagt verstehe ich das Problem noch nicht ganz richtig: Du überprüfst den Replikationsstatus "manuell" mittels dem Explorer und vergleichst die Ordnergrößen? Das ist in den meisten Fällen nicht sinnvoll, da a) in den Ordnern (falls nicht manuell re-lokalisiert) das DfsrPrivate Verzeichnis liegt und mitgezählt wird und b) bestimmte Dateitypen von Hause aus erst einmal nicht repliziert werden (z.B. temporäre Dateien). Von daher ist diese Art der Überprüfung fehleranfällig. Was sagt denn ein DFSR Health Report, bei dem Du die Option mit anwählst, daß die Dateien gezählt werden sollen? Achtung: Das kann lange dauern und einiges an Systemressourcen kosten... Viele Grüße olc

Hi Mattes, ergänzend der Hinweis, daß die Standalone Root CA rein technisch gesehen auch niemals ans Netzwerk angeschlossen sein muß. Du überträgst das ausgestellte Sub CA Zetifikat als auch die notwendigen CRLs einfach über einen USB Stick o.ä. in das Produktivnetz. Damit verhinderst Du, daß ein Zugriff / Angriff auf die Stamm CA über das Netzwerk zu irgend einem Zeitpunkt möglich ist. Insofern ist der von Dir zitierte Text richtig. Das schien mir Deine "Verständnisfrage" zu sein, korrekt? Viele Grüße olc

Hi, wenn es tatsächlich die Systemzeit ist, hast Du _eigentlich_ nicht viel zu tun, außer den Zeitdienst korrekt zu konfigurieren: Konfigurieren des Windows-Zeitdiensts Viele Grüße olc

Hi Musli, ist vielleicht eine Policy "zu viel" konfiguriert, siehe Using Group Policy to delete cached copies of roaming profiles ? Oder heißt das jeweilige Profil tatsächlich "TEMP" im Dateisystem? Dann wäre das ein anderes Fehlerbild. Viele Grüße olc

Hi bitwicht, vielen Dank für den Trace. Es ist also tatsächlich so, wie zu vermuten war: Wird die Option "AuthLDAPGroupAttribute member" nicht angegeben, macht das System direkt eine Suche auf den Accountnamen, nicht auf die Gruppenzugehörigkeit. Erst mit dieser Option werden per "ldap compare" die Member der Gruppe als Ergebnisliste mit dem übergebenen Benutzernamen verglichen. Interessant, daß man das tatsächlich kaum im Internet findet. Sollten doch schon mehr Nutzer darüber gestolpert sein. Vielleicht magst Du ja ein kleines HowTo für Windows Server How-To Guides: Home - ServerHowTo.de fertig machen? :) P.S.: Bitte das Kennwort für den LDAP-Bind Benutzer ändern. ;) Vielen Dank und viele Grüße olc

Hi, wenn Du es nicht mit der Checksumme machen möchtest, dann mach es wenigstens richtig mit dem Dateivergleich. ;) Schau Dir einmal "fc.exe" an - müßte in XP / Vista direkt mit dabei sein. Damit kannst Du die Dateien z.B. Binär oder ASCII vergleichen und dann in Deiner Batch-Datei das Errorlevel auslesen: fc.exe /b Datei1.txt Datei2.txt IF %ERRORLEVEL% == 0 GOTO :ende REM # Deine Aktionen, z.B. Auslesen des Datums etc. # :ende Viele Grüße olc

Hi, schließe mich Cyberquest an - die wahrscheinlich beste Möglichkeit, eine Datei "sicher" auf Änderungen zu prüfen, ist neben der Überwachung des NTFS Journals eine Hash / Checksumme. http://downloads.activestate.com/contrib/md5sum/Windows/ Kann je nach Umsetzung jedoch sehr rechenaufwendig sein. Viele Grüße olc

Hi, neben den von Nils genannten Startup-Scripts kannst Du auch die Group Policy Preferences nutzen, siehe Files Extension . Dazu müssen die Betriebssysteme XP / 2003 aufwärts sein und die GPP CSEs installiert sein. Viele Grüße olc

Hi Frederik, das von Dir genannte Szenario mag in bestimmten Konstellationen funktionieren oder sinnvoll sein, nicht jedoch bei der Anforderung des TO. Wenn Du Kennwortrichtlinien auf OUs verlinkst, greifen diese nur für lokale Benutzerkonten auf den Client PCs, die unterhalb dieser Richtlinien liegen - jedoch nicht für Domänenbenutzer. [EDIT] Nils war schneller. [/EDIT] Viele Grüße olc

Hi, wie lange die Replikation dauert läßt sich pauschal nicht sagen. Das hängt natürlich von der Größe der Dateien ab, von der Leistungsfähigkeit der Systeme, des Netzwerks, ob die Server in der selben AD-Site stehen etc. Wenn die Ordner leer sind und Du eine neue, leere Textdatei ablegst, sollte FRS die Datei recht schnell replizieren. Voraussetzung ist hierbei, daß der Schedule der Verbindung offen ist. Der Ordner des Stammes ist ein "Junction Point" bzw. enthält Meta-Informationen zu den Ordnerzielen. - es ist also korrekt, daß Du nicht mehr direkt den Ordner im Filesystem öffnen kannst. Im Gegensatz dazu kannst du weiterhin auch die Ordnerziele direkt im Filesystem öffnen, das sind normale Freigaben. Viele Grüße olc

Hi, hast Du einen konkreten Anhaltspunkt, daß die Fehler an den SPNs liegen? Falls nicht, mußt Du sie auch erst einmal nicht löschen. ;) Vielleicht kannst Du ja vor dem Löschen der SPNs noch einmal prüfen, inwiefern vielleicht anderen Ursachen für die Probleme existieren, ohne "wild" Einträge zu entfernen. ;) Viele Grüße olc