olc

Hi smileyman, ich denke, daß Du da schlechte Karten hast. Du kannst pro Server nur 1x Credentials nutzen, d.h. 2 Freigaben auf dem gleichen Server mit unterschiedlichen Credentials vom Client aus sind nicht möglich. Im Normalfall solltest Du übrigend eine andere Fehlermeldung bekommen - so etwas wie "the connection already exist" oder irgendwie in der Art. "Netzwerkpfad nicht gefunden" deutet eher auf ein anderes Problem hin. Was mir aus Deiner Beschreibung nicht ganz klar geworden ist: Warum kann auf der 2. Freigabe nicht der selbe Benutzer bzw. die selbe Benutzergruppe berechtigt sein? Damit würde sich das Problem ja erübrigen. Und warum hat jeder Benutzer ein eigenes Share mit eigenen Berechtigungen - das ließe sich mit einer Freigabe und NTFS Berechtigungen pro Benutzer sicher besser lösen. :) Viele Grüße olc

Hi DL, das freut mich, danke für die Rückmeldung. :) Viele Grüße olc

Hi pc_NK, ergänzend der Hinweis, daß natürlich wie immer bei solchen Änderungen ein valides Systemstate Backup vorliegen sollte und ggf.auch die Applikationen, die eventuell auf dem DC installiert sind, abgeklopft werden sollten. :) Aber das scheinst Du ja (ausgehend von Deinem ersten Post oben) auf dem Schirm zu haben. :) Aber meiner Erfahrung nach ist eher der Schritt RTM zu SP1 beim Windows Server 2003 problematisch gewesen - außer dem von Gadget erwähnten SNP machte SP2 wenige Probleme. Viele Grüße olc

Hi DL, hast Du unter Umständen die NTFS ACLs des replizierten Ordners verändert und dabei auch die "versteckten Ordner und Dateien" eingeblendet? Falls ja, kann es sein, daß die erforderlichen Rechte auf den Ordner E:\daten\DfsrPrivate bzw. auf SYSTEM VOLUME INFORMATION entfernt wurden, das würde jedoch solche Probleme erklären. Der Ordner ist unter Windows Server 2008 im Normalfall ein Junction Point auf den Ordner E:\SYSTEM VOLUME INFORMATION\DFSR\<GUID>. Bei SBS 2008 weiß ich es nicht genau (bei 2003 R2 gab es hier "Versions"-Unterschiede zwischen 2003 und SBS 2003 - also FRS und DFSR, ich vermute bei 2008 sollte das nicht mehr verschieden sein) - auf welchem der beiden Systeme wird der Fehler denn geloggt? Wie lauten die NTFS Rechte auf diesem Ordner? SYSTEM muß Vollzugriff haben, ggf. auch die Administratoren (nicht zwangsweise notwendig, aber empfehlenswert). Alternativ würde ich einem den Virenscanner überprüfen: Hast Du das Verzeichnis "E:\daten\DfsrPrivate" aus dem Real-Time und Scheduled Scan ausgenommen? Das wäre in jedem Fall empfehlenswert. Viele Grüße olc

Hi jensmg, unter Windows Server 2008 bekommst Du DFSR standardmäßig mitgeliefert, das sollte Deine Anforderungen mehr als erfüllen: Jose Barreto's Blog : The Basics of the Windows Server 2008 Distributed File System (DFS) . Viele Grüße olc

Hi pc_NK, es werden keine neueren "Patches", sprich Dateien, überschrieben. Du kannst also auch ein Service Pack installieren, wenn Du Hotfixes installiert hast, die erst nach diesem Service Pack herausgegeben wurden. Dafür gibt es verschiedene "Versionszweige" im System - mach Dir also keine Gedanken. :) Viele Grüße olc

Hi, Du solltest Deine Antwort-Zeit Vorstellungen in einem kostenlosen Forum noch einmal überdenken. :wink2: Die Datenbank scheint in Ordnung zu sein - zumindest zeigt der Test erst einmal auf den ersten Blick keine Fehler. Was genau heißt denn ? Was hast Du für eine Fehlermeldung bekommen, wann ist die Installation abgebrochen? Viele Grüße olc

Hi, ergänzend zu blubs Hinweisen noch die Anmerkung, daß die Group Policy Preferences das ganze elegant lösen können: Set Default Printer with Windows 2008 Server Group Policy Preferences - Set the Default Printer via Group Policy | Windows Server Administration Viele Grüße olc

Hallo Heiner, kannst Du noch ein WHOAMI /ALL (siehe oben) eines betroffenen Benutzers posten (ggf. sensible Daten entfernen). Falls sich die Benutzer am DC anmelden können, bitte auch dort ein WHOAMI /ALL des selben Benutzers. Danke und Gruß olc

Hi Smigi, schau einmal hier hinein, dort sind einige relevante Punkte zusammengefaßt: Yusufs Directory Blog - Einen Domnencontroller an einen anderen Standort verschieben. Wenn es um das reine Umkonfigurieren des IP-Adressbereiches geht und nicht um das Verschieben innerhalb von Sites, dann ist das Vorgehen im Kern einfacher: DNS-Einträge des DCs deregistrieren, die Adresseinstellungen des DCs ändern (inkl. Subnetz, Gateway und ggf. auch DNS und WINS Servern), Neustart des NETLOGON Dienstes oder besser des DCs. Ggf. sind auf Replikationslatenzen zu achten, da die DNS Einträge bei AD-integrierten Zonen nicht sofort überall verfügbar sind. Das ist aber meist ein riesiges Problem, da die Clients bei "nicht erreichen" eines DCs den nächsten Versuchen. Ggf. kannst Du das Vorgehen also "off hours" durchführen, nicht unbedingt zur Hauptanmeldezeit. :) Change the static IP address of a domain controller: Active Directory Viele Grüße olc

Hallo und willkommen, :) hast Du denn das gesamte Vorgehen des von Daim geposteten KB-Artikels durchgearbeitet? Der von Dir genannte Befehl "repadmin /kcc" tut nicht mehr, als den KCC zu triggern. Das sagt also im Kern nichts über den aktuellen Status aus. Von daher wäre es sinnvoll, wenn Du die gesamte Palette des KB-Artikels einmal durchgehst und ggf. die Ergebnisse hier postest. :) Viele Grüße olc

Hi, wenn der Fehler nicht nach einem Neustart aufgetreten ist, ist der Hinweis von Nils nicht verkehrt. Dein Hinweis auf den Fehler auf dem DNS Server resultiert eher in einem Henne - Ei Problem. Davon zeugt die DCDIAG Fehlermeldung. Meiner persönlichen Erfahrung nach haben DNS 4015 Fehler diverse Ursachen - Du solltest also noch einmal die gesamte Konfiguration prüfen, etwa: - Bindungsreihenfolge der Netzwerkkarten - primäre DNS Einträge der Netzwerkkarten - ForestDNSZones und DomainDNSZones (sind diese vorhanden? Sind Daten enthalten?) - generell die Einstellungen des DNS Servers (lädt er die Daten nur aus der AD oder auch aus der Registrierung?) - ggf. auch wie von Dir vorgeschlagen Neuinstallation des DNS Dienstes, danach Neustart des NETLOGON Dienstes auf dem DC Viele Grüße olc

Hi, ist das nicht eher ein Fall für einen "conditional forwarder" bzw. eine Delegierung oder verstehe ich das Anliegen falsch? :) Viele Grüße olc

Hi Jau, cool -kannte ich noch nicht: FileSystemWatcher-Klasse (System.IO) Schau ich mir bei Gelegenheit mal an, danke für den Tipp. Viele Grüße olc

Hi, aktiviere einmal das UserEnv Debug Logging auf den Clients und schau im Fehlerfall, ob Du im UserEnv.log etwas auffälliges finden kannst: How to enable user environment debug logging in retail builds of Windows . Viele Grüße olc

Hi, ich habe gerade mal kurz geschaut, was es da so an .NET Klassen gibt. Aber auf die Schnelle habe ich keine passende für "Dauerüberwachung" gefunden. Letztendlich kannst Du es neben der Methode von Nils auch über das USN Journal regeln / filtern (sofern aktiviert). Ab Windows Server 2008 sollten die mitgelieferten Trigger des Taskplaners reichen, wenn ich mich nicht irre - das müßte man ggf. noch einmal genauer überprüfen. Viele Grüße olc

Hi, wenn Du DFSN einsetzt, könntest Du mit Prioritäten arbeiten. Siehe dazu You experience issues with DFS replication in a Windows Server 2003 R2-based AD environment . Viele Grüße olc

Hi und willkommen im Forum, :) ich hoffe die Problematik korrekt verstanden zu haben, daher zwei erste Fragen an dieser Stelle: Sind die betroffenen Benutzer unter Umständen Mitglied der lokalen Administratoren-Gruppe? Siehe System objects: Default owner for objects created by members of the Administrators group . Was steht in der Ausgabe eines "whoami /all", ausgeführt als betroffener Benutzer? Welche Sicherheitsgruppen werden aufgeführt? Viele Grüße olc

Hi, wie genau bist Du vorgegangen? Hast Du Dir die o.g. Links in der FAQ angeschaut? Windows Server 2003 Access-based Enumeration How to implement Windows Server 2003 Access-based Enumeration in a DFS environment Download details: Windows Server 2003 Access-based Enumeration Viele Grüße olc

Hi, was genau ist denn nun eigentlich Deine Frage... ;) Viele Grüße olc

Hi, das habe ich oben schon geschrieben. ;) Allein lange Kennwörter helfen jedoch nicht, das ist heutztage nur ein kleiner Stolperstein - LM-Hash hat kein "salt", wenn ich mich recht entsinne. Daher ist ein Angriff keine "große Sache" - Stichwort "rainbow tables" etc. Zusätzlich helfen Dir längere Kennwörter bei LM-Hash auch recht wenig, da diese in mehrere Teile gesplittet werden, die wiederum "unabhängig" voneinander angegriffen werden können. Lediglich Kennwörter größer 16-Zeichen helfen da, jedoch wären dann Applikationen, die LM-Hash nutzen wollen, eh außen vor. Von daher kann man es also gleich Deaktivieren. Eine Einzelmaßnahme ist jedoch nicht viel Wert, es muß immer ein Gesamtkonzept erarbeitet werden. Das Deaktivieren eines "schwachen Hashes" wie dem LM-Hash ist da nur eine Komponente. Das Deaktivieren macht etwa wenig Sinn, wenn man danach nicht alle Kennwörter vom Computer- und Benutzerkonten ändert. Das vergessen meiner Erfahrung nach viele Unternehmen. Gerade bei Service-Accounts verzichten viele Firmen darauf - und genau diese Accounts sind recht gefährdet, denn der alte Hash ist demnach immer noch gültig, bis irgendwann vielleicht doch einmal eine Kennwortänderung erfolgt. Viele Grüße olc

Hi, da möchte ich mich Nils anschließen - als kleiner Querverweis dazu sei noch die Datenschleuder #93 genannt, die auf Seite 34 auf das Problem (bei lokalen Konten) eingeht. Im Grunde ist es aber das gleiche Problem in AD Umgebungen - dort muß der Zugriff auf die AD-Objekte bzw. konkret die jeweiligen Attribute / die Datenbank oder den LSASS-Prozess entsprechend möglich sein, was jedoch mit etwas Arbeit eines "Profis" theoretisch möglich ist. Die Registirerung ist auf DCs auch ein Thema, da dort das Konto des Wiederherstellungskontos gespeichert ist (lokale SAM). Den LM-Hash zu deaktivieren ist also schon einmal eine gute Sache, das steigert die Sicherheit, selbst wenn der NTLM-Hash dann immer noch "gebrochen" werden kann - hier ist jedoch mehr Rechenpower bzw. Aufwand notwendig als beim LM-Hash. Starke Kennwörter bieten dann bei NTLM noch eine Sicherheitssteigerung, das Verschlüsseln der HDD bei DCs ist eine weitere Schutzmaßnahme (falls diese entwendet werden). Gleiches gilt natürlich auch für die Backups der Systeme. Viele Grüße olc

Hi, Wie schon vermutet gibt es Probleme beim Re-Keying. Von daher nochmals der Hinweis, beide Logs vom gleichen Problemfall zu überprüfen. Viele Grüße olc

Hi, ja - das könnte mit dem Problem zusammenhängen bzw. die Ursache dafür sein. Schau doch einmal in den folgenden KB-Artikel, unter Umständen betrifft das Deine Umgebung? The Volume Shadow Copy Service cannot create shadow copies on a computer that is running an x64-based version of Windows Server 2003 and a 32-bit version of SQL Server 2000 Viele Grüße olc

Hi, Gern. :) Das ist absolut in Ordnung, da würde ich also kein Problem sehen. Genau - umso "voller", umso besser. Schau doch einmal in die folgende "DFSR Serie", ich denke der Hintergrund wird damit klar ;) : Windows Server How-To Guides: Planung, Installation und Konfiguration des Distributed File System (DFS) unter Windows Server 2003 R2 - ServerHowTo.de Windows Server How-To Guides: Weiterführende DFS-R Konfiguration unter Windows Server 2003 R2 - ServerHowTo.de Windows Server How-To Guides: Grundlegende DFS-R Überwachung mit Hausmitteln - ServerHowTo.de Ausnahmsweise kann man bei dieser Technik generell sagen: "Viel hilft viel." :D Ist also in Ordnung so. Das bringt Dir nichts, denn das ist eine FRS Einstellung, keine DFSR Einstellung. Die Replikationsengine ist eine komplett neue und hat nichts mehr mit FRS zu tun. Ok, mit den vorliegenden Informationen lassen sich möglich Probleme schwer eingrenzen, zumal Du ja in der Zwischenzeit ein paar Dinge manuell "angepaßt" hast. Ich persönlich würde die Replikationsgruppe noch einmal komplett löschen, danach neu einrichten, als "Primary Member den Fileserver definieren, der die "autorisierenden Daten" enthält (also die, die "gewinnen" sollen bei der Initialreplikation). Danach warte einfach ab, mach keinerlei weitere Aktionen, lies Dir lieber in Ruhe die HowTos durch ;) und ich vermute, daß dann die Replikation früher oder später durch sein wird. Viele Grüße olc