olc

...da konntest Du jetzt aber nicht widerstehen, oder? ;) :D Kommt auf die Größe des Unternehmens an - einige sind da sicher bereit. Aber die melden sich dann auch nicht lokal an einem Domänenclient an. :p Ok, back to topic. :) Viele Grüße olc

...da hast Du Recht. ;) Ich habe immer so argumentiert: bei den meisten Gesellschaftsformen (etwa GbR, GmbH etc.) haftet mittlerweile direkt der Geschäftsführer bzw. die Geschäftsleitung bei fahrlässigem IT-Sicherheitsverhalten, wenn dadurch Dritte geschädigt werden. Nach einer zwei Sätze umfassenden Erläuterung, wie schnell eine solche "Fahrlässigkeit" mit schlechten Kennwörtern nachzuweisen ist, waren bisher alle Führungspersönlichkeiten sehr schnell bereit, das Kennwort im Tausch gegen Ihre persönlich "Straffreiheit" möglichst komplex zu wählen. :D Viele Grüße olc

Hallo, das Verhalten war auch schon in Windows Server 2003 Domänen so. Die Kennwortrichtlinie ist standardmäßig in der Default Domain Policy vergeben, daher greift Sie für alle Systeme, die in der jeweiligen Domäne liegen. Bei AD-Benutzerkonten wird die Richtlinie auf den DCs (bzw. dem PDC) angewendet, für die Clients greift sie bei lokalen Benutzerkonten. Ich denke nicht, daß das "schlecht" ist, so wie Du es beschreibst. Das Sicherheitslevel in einer Domäne würde heruntergesetzt werden, wenn lokale Benutzer (insbesondere in XP Hauptbenutzer und Administratoren) schwache Kennwörter hätten. Damit ist es nach dem Knacken eines Kennwortes schnell möglich, sich mehr Rechte (auch in der Domäne) zu erschleichen. Du hast meiner Meinung nach zwei (saubere) Möglichkeiten: 1. Entweder Du definierst auf Ebene des betroffenen Clients eine zusätzliche GPO mit Kennwort Komplexitätseinstellungen. Diese überschreiben dann zumindest standardmäßig die Default Domain Policy Einstellungen auf dem Client und ermöglichen den lokalen Benutzerkonten andere Richtlinien. 2. Du läßt es so, wie es derzeit ist. Komplexe Kennwörter sollten im Normalfall doch eher kein Problem sein. Wenn man sich die Kennwörter nicht merken kann, dann sollte man den Client vielleicht auch lieber nicht einer Domäne hinzufügen. ;) Ich würde von Variante 1. aus den genannten Gründen abraten und bei Variante 2 bleiben. BTW: Warum verwendest Du überhaupt noch lokale Konten, wenn Du einen Domänenclient nutzt? Viele Grüße olc

Hi Jürgen, es ist auf den ersten Blick erst einmal anzunehmen, daß irgend eine Applikation zyklisch ein falsches Kennwort sendet. Von daher könntest Du einmal prüfen a) von welchem Client die Kontosperrung ausgelöst wird b) falls es der Client ist, an dem die Benutzer zum Zeitpunkt der Sperrung arbeiten, beispielsweise einmal die Einträge des Credential Managers löschen (control keymgr.dll) oder die eingerichteten Dienste / geplanten Tasks überprüfen. Ansonsten leistet unter XP / 2003 die ALockout.dll oft ganz gute Dienste: Account Lockout Tools Viele Grüße olc

Hi, schau doch einmal direkt in die boot.ini (die von msconfig auch angepaßt wird), was bei nach einem Start in den abgesicherten Modus dort zu finden ist. Ist der entsprechende OS Eintrag unter Umständen noch mit "/safeboot" Option aktiv? Viele Grüße olc

Hi, ergänzend zu Daim's Hinweisen und der Vermutung, daß Ihr auch die FSMO Rollen auf den "Testserver" verschoben habt (und das die beschriebenen Probleme nach sich ziehen könnte) an dieser Stelle explizit der Hinweis, saß Ihr Euch mit dem "Test-DC" mit hoher Wahrcheinlichkeit Probleme einhandelt. Spätestens, wenn dieser "aus Versehen" zurück ins produktive Netz kommt, werden unter Umständen die ungewollten Änderungen repliziert. Und bevor jetzt eine Aussage kommt wie "nein,auf gar keinen Fall kommt der zurück ins Produktivnetz" gleich die Anmerkung meinerseits, daß das schon ganz andere Admins gesagt haben und dann in massive Problem gelaufen sind, weil es doch passiert ist. Baut Euch lieber gleich eine korrekte Testumgebung. Viele Grüße olc

Hi Torsten und willkommen an Bo(a)rd, :) ich vermute, daß das in der Form nicht möglich sein wird. Eine "normale" Anmeldung unterscheidet sich in vielen Dingen von einer Netzwerkanmeldung oder einem schlichten "runas". So wird meines Wissens eben kein RSOP Datensatz erstellt, weshalb Dein Vorhaben nicht gelingt. Was genau ist der Hintergrund für die Fragestellung? Ist ggf. der RSOP Planning Mode eine Alternative? Viele Grüße olc

Hi, der entsprechende Hotfix ist am 30.04.2009 veröffentlicht worden: When you try to log on to a Windows XP SP3-based computer by using a roaming profile, the roaming profile cannot load. Viele Grüße olc

Hi, manchmal kommt man nicht auf das Naheliegendste, ;) Vielen Dank für die Rückmeldung und Gruß olc

Hallo, scheinbar funktioniert es, wenn Du die Pfade im Format "\\?\" angibst. Siehe dazu File Names, Paths, and Namespaces (Windows) Viele Grüße olc

Hi, Soweit ich weiß nein. Das ganze irgendwie zu scripten ist meiner Meinung nach nicht wirklich empfehlenswert, da schlichtweg zu fehleranfällig. Alternativ bieten einige andere Hersteller Lösungen dafür an, so etwa PGP oder Ultimaco. Viele Grüße olc

Hi, seid Ihr neben dem Link von zahni auch einmal die oben verlinkten Suchergebnisse durchgegangen? Wie geschrieben kann es so einige Fehlerursachen dafür geben. Viele Grüße olc

Hi, Du könntest in die Batch-Datei, die Du zum Aufrufen von Blat benutzt, noch eine Zeile einbauen, in der Du das Event in eine Textdatei schreibst. Diese könntest Du dann mit Blat verschicken (oder deren Inhalt), Mal abgesehen von PowerShell, VBS etc. läßt sich das recht einfach mit PsLogList erreichen, indem Du zum Beispiel nur die Events der letzten Stunde / der letzten Minuten exortieren läßt. PsLogList Viele Grüße olc

Hi, ist die PowerShell oder ggf. VBS auch eine Alternative? PowerShell: Get-WmiObject Win32_NetworkAdapterConfiguration -filter "IPenabled=true" | % {$_.IPAddress} Viele Grüße olc

Hallo dreiling, schau doch einmal, ob unter Umständen eine Gruppenrichtlinie den anonymen Netzwerkzugriff verweigert oder dem Gast dieses Recht verwehrt ist. Vielleicht liegt es daran. Ansonsten nimm einmal die Windows Authentifizierung dazu - erscheint dann ein Logon-Prompt oder ebenso ein "Zugriff verweigert"? Viele Grüße olc

Hi, aktualisiere einmal den Netzwerkkartentreiber oder nutze den Builtin-Treiber, sollte dieser die Karte erkennen. Viele Grüße olc

Hi, ich habe doch oben geschrieben, daß man das grundsätzlich ermöglichen kann. Die Frage ist jedoch immer noch, warum das erreicht werden soll. Die Frage ist m.E. nicht wirklich beantwortet. ;) Letztendlich muß man abwegen, ob man den Aufwand und ggf. die Unübersichtlichkeit in Kauf nimmt, weil das Vorhaben unbedingt notwendig ist oder nur, weil es auf den ersten Blick als einfachster Weg erscheint, den man jedoch auch anders lösen könnte. Viele Grüße olc

Hi, eränzend noch der Hinweis, daß man Policies grundsätzlich auch auf Standorte verlinken kann. Ist meist nicht zu empfehlen, könnte in dem Fall in Verbindung mit der Option "Interaktive Anmeldung zulassen" bzw. "verweigern" bei einer solchen Anforderung Sinn machen. Aber ich schließe mich an: Weshalb sollte man das tun? Was soll genau erreicht werden? Viele Grüße olc

Hi, ja - grundsätzlich schon. Daher solltest Ihr mehere Namespaceserver einsetzen, die sinnvoll in der Umgebung verteilt sind. Das ist auch für die Ausfallsicherheit sinnvoll. Schau auch einmal hier hinein: 1. Designing a DFS Namespace: Storage Services; Remote File Systems; Local File Systems 2. Planning the Number of DFS Namespaces: Storage Services; Remote File Systems 3. Choosing an Availability Method for DFS Roots: Storage Services; Remote File Systems 4. Overview of the Distributed File System Solution in Microsoft Windows Server 2003 R2 Viele Grüße olc

Hi Kerstin, witzige Geschichte. Paß nur auf, daß Dein Chef nicht durch Zufall etwa per Suchmaschine auf solche Threads stößt. Unter Umständen ändert sich Euer "zwischenmenschliches Verhältnis" danach massiv. Ich würde daher solche Geschichten wenn überhaupt eher mit Bedacht öffentlich anbringen. Na ja - und zu dem Netzwerkverkehr: Da hat wohl Siegmund Freud Pate gestanden. Ggf. solltest Du auf weitere "Gesten" Deines Vorgesetzten achten... :wink2: Viele Grüße olc

Hi, also ich habe die Kommandozeile, die ich oben gepostet hatte, gerade getestet (inkl. der Anführungszeichen, die darin auch angegeben waren) - sie funktioniert zumindest bei mir einwandfrei. Viele Grüße olc

Hi, grundsätzlich ist der Hinweis natürlich korrekt - jedoch hat DFSN im Kern nichts mit DFSR zu tun. Du mußt keine Daten replizieren, weil Du DFS-Namespaces einsetzt. Daher ist es auch immer wichtig, zwischen den beiden Technologien zu unterscheiden. Viele Grüße olc

Hi Thomas, soweit ich da richtig informiert bin unterstützen neuere BackupExec Versionen DFSR auch offiziell, HP Dataprotector meines Wissens ebenso (beide Aussagen von mir ohne Gewähr ;)). Den Data Protection Manager von MS hattest Du ja schon genannt. Ich würde einfach mal bei den Herstellern direkt anfragen, wie es mit der offiziellen DFSR Unterstützung aussieht. Wenn die etwas verkaufen können sind sie meist auch gewillt, Dich mit Informationen zu versorgen. :D ;) Viele Grüße olc

Hi, ein "Best Practice" ist da sicher schwierig, bei DFSN kommt es ja oft auf die zusätzlichen Möglichkeiten an, also neben der "Servernamen-unabhängigen" Datendarstellung auch auf die Netzwerkkosten und Zielauswahl eines Clients. Grundsätzlich kann man DFSN Stämme verschachteln, meiner persönlichen Erfahrung nach und dem "Leidklagen" einiger Bekannter von mir, die das so einsetzen, würde ich eher davon abraten. Das ist sehr komplex und man muß auf unglaublich viele Dinge achten. Wenn es also die Struktur erlaubt, eine übersichtliche Anzahl an Stämmen pro "Land" zur Verfügung zu stellen, würde ich zumindest eher diese Variante bevorzugen. Viele Grüße olc

Hi, ich gehe nun (da keine Antwort dazu kam) einmal davon aus, daß wir über DFSR (und nicht FRS bzw. DFSN) sprechen. Doch, nur riskiert man dabei Sharing Violations, so daß die Shadow Copies in jedem Fall genutzt werden sollten. Das ist so nicht korrekt. Das Problem hat Deine Backup Applikation, nicht DFSR. Wenn Backup Exec nicht mit DFSR umgehen kann (und ggf. auch keine alternative Lokation als Ziel einer Rücksicherung ermöglicht), solltest Du Dich nach einem Update oder einen alternativen Anbieter umschauen, der seine Produkte für DFSR zertifiziert hat. Das Deaktivieren der Dienste ist absolut kontraproduktiv und sollte im Normalfall vermieden werden. Wie gesagt, daß ist Aufgabe der Backup Applikation. Siehe oben, nicht empfehlenswert. Du benötigst eine Backup Applikation, die DFSR offiziell unterstützt. Ansonsten kommt Du wahrscheinlich um diese "Verrenkungen" nicht herum. Viele Grüße olc