olc

Hi, neben den Tipps von Nils gibt es auch einige Programme, die die Daten problemlos (und teils kostenlos) liefern, so etwa Network Documentation Made Easy with SYDI . Diese greifen im Normalfall auf die genannten Schnittstellen zu. Viele Grüße olc

Hi, beim Aufruf des NetBIOS Namens werden Deine Anmeldedaten mitgesendet. Dies ist standardmäßig bei "externen" Zonen wie der "Internet" Zone nicht der Fall, wozu standardmäßig FQDNs gezählt werden. Du kannst den FQDN jedoch wenn gewünscht in die lokale bzw. sichere Zone des Internet Explorers aufnehmen. Dann werden auch Deine NTLM- oder Kerberos-Anmeldedaten gesendet. Siehe Intranet site is identified as an Internet site when you use an FQDN or an IP address Viele Grüße olc

Hallo, schau Dir einmal die Group Policy Preferences an, mit denen solltest Du die Drucker auch einfacher verteilen können als mit Logon Scripts. Download details: Group Policy Preferences Overview Viele Grüße olc

Hi Andreas, interessant - vielen Dank für Deine Zusammenfassung! :) Viele Grüße olc

Hi, ist denn überhaupt ein Domänenkonto für das Computerobjekt erstellt worden? Soll heißen - ist der Client überhaupt korrekt in die Domäne aufgenommen worden? Das kannst Du prüfen, ohne Dich auf den Client zu verbinden. Viele Grüße olc

Hi, Sollte dem so sein enttäuscht Du mich nicht. ;) Ich bin immer froh, etwas dazu zu lernen. Ok, dann werde ich das auch noch einmal testen. Das wäre auf der einen Seite natürlich nicht schlecht, da man sich einige VBScripts sparen könnte, auf der anderen Seite jedoch nicht sehr konsistent. Ich schaue mir das in den genannten Konstellationen noch einmal an. Danke für den Hinweis. Viele Grüße olc

Hi Stephan, Ich habe geschrieben, daß die Aussage nicht zu 100% korrekt ist. Man hätte auch schreiben können, daß diese nur zu 50% korrekt ist, denn Du schriebst: Da das Update zumindest für domänenbasierte Namespaces diese Beschränkung für Windows Server Standard 2003 Systeme aufhebt, ist also nicht in jedem Fall die Enterprise Version notwendig. Viele Grüße olc

Hi Danny, Dein Kommando würde den Benutzeraccount "aktivieren" (enable), jedoch nicht den Account Lockout aufheben. Es schwirren im Internet jedoch auch einige (VB)Scripts herum, die eine Entsperrung übernehmen. Diese dann jedoch automatisch laufen zu lassen, sollte man sich dann jedoch gut überlegen (wie oben und von Danny schon angesprochen). Viele Grüße olc

Hi, Das ist soweit ich weiß nicht 100% korrekt. grizzly999 wies mich vor einiger Zeit auf folgenden Hotfix hin, der im Windows Server 2003 SP2 enthalten ist: You cannot create more than one domain-based DFS namespace on a computer that is running Windows Server 2003, Standard Edition Nach der Installation (oder SP2) ist es zumindest für domänenbasierte Namespaces möglich, mehrere Namespaces anzulegen: Viele Grüße olc

Hi, versuch es testweise einmal mit: robocopy D:\whk\aan\Verwaltung\vorlagenvonkunden Z:/altevorlagen *.* /MIR /LOG:C:/copylog.log /TEE /L Vielleicht war der Backup Modus (/B) ein Problem. Dabei ist zu beachten, daß am Ziel vorhandene Dateien ggf. gelöscht werden, sollten diese an der Quelle nicht vorhanden sein. Viele Grüße olc

Hi, Ergänzend vielleicht noch der Hinweis, daß man hier ggf. vorsichtig sein sollte, wenn es sich um Laptops handelt oder aber vielleicht um Rechner von länger nicht im Büro weilenden Mitarbeitern, die während der Abwesenheit nicht genutzt werden. Da sich das Kennwort nicht automatisch nach (standardmäßig) 30 Tagen ändern, sondern erst wenn ein Client es selbständig ändert bzw. eine Änderung anfordert, kannst Du hier ggf. Accounts löschen, die im Grunde noch aktiv sind, auch wenn seit mehr als 30 Tagen keine Anmeldung erfolgte. Daß Clients / DCs nach 30 Tagen ohne Domänenanmeldung der Clients automatisch das Kennwort ändern ist nicht korrekt. Ein Client kann theoretisch einen beliebig langen Zeitraum ohne Netzwerkzugriff sein und sich dann wieder an der Domäne anmelden. Problematisch wird es meist erst durch o.g. Script-Aktionen oder Backup / Image Prozesse (oder natürlich auch manuelle Eingriffe). Viele Grüße olc

Hi, Du meinst mit Specops? Ich habe das Programm nicht im Einsatz - aber soweit ich weiß ist das auf Benutzer oder Gruppenbasis (bzw. GPO-Filterung) möglich. http://www.specopssoft.com/wiki/uploads/SpecopsPasswordPolicy2/Configuration/GpoePasswordPolicyEdit3.jpg Viele Grüße olc

Hi, erster Treffer bei google.de :wink2: : .: Daniel Melanchthon :. : Servergespeicherte Profile mit Windows XP vs. Windows Vista Viele Grüße olc

Hi, blub meinte sicherlich das Problem, daß in den Security Policies bis zur genannten Service Pack Version in eingen Einstellungen direkt die Benutzer- bzw. Gruppennamen gelandet sind anstatt der SID oder der Variablen, Stichwort SDDL in der GptTmpl.inf. Das ist auch jetzt bei einigen wenigen Richtlinien soweit ich weiß noch möglich (so können etwa die "Hauptbenutzer" bei einigen Policies noch direkt eingetragen werden, obwohl diese keine Domänenkonten sind). Das macht dann bei unterschiedlichen Sprachversionen Probleme. Ich weiß, Du bezogst Dich auf die Annahme, die Builtin-Accounts seien gemeint. ;) Das ist tatsächlich auch weiterhin unter Windows Server 2008 der Fall. Trotzdem der Vollständigkeit halber der Hinweis, daß MS angekündigt hat, dieses von blub gemeinte "direkte Eintragen" von Benutzern oder Gruppen zukünftig überall in den entsprechenden Policies einstellen bzw. besser gesagt unterbinden zu wollen. Schauen wir mal... ;) Viele Grüße olc

Hallo Revi, nein, das ist nicht möglich (siehe Aktives Verzeichnis Blog : Schutz vor Account Lockouts auch für andere Konten als "Administrator"?). Dort findest Du auch ggf. zwei Alternativen (Fine Grained Password Policies unter Windows Server 2008 oder die Domäne als Sicherheitsgrenze). Es gibt es ein paar Hersteller, die unter Windows Server 2003 diese Lücke schließen, so etwa Password Policy / Password Filter for stronger Windows Passwords . Grundsätzlich solltet Ihr vielleicht einfach prüfen, wer den Account Lockout verursacht und seid das Problem dann grundsätzlich los. ;) Viele Grüße olc

Hi, im Normalfall ja. Ich hatte bisher noch nie Probleme mit diesem Vorgehen - was nicht heißt, daß es keine Probleme geben kann. Wenn Du ganz sicher gehen willst, zieh Dir vorher ein (funktionierendes) Image des Systems. Viele Grüße olc

Hi, liegen denn im Zielverzeichnis unter Umständen schon gleiche oder neuere Dateien der gleichen Struktur / des Quellverzeichnisses? Robocopy würde diese überspringen, da mittels Robocopy im Standard-Modus mit Deinen Parametern nur die geänderten bzw. neueren Dateien übertragen werden würden. Viele Grüße olc

Hi, Vielen Dank für den Hinweis. Man lernt nie aus. Viele Grüße olc

Hi Death, na ja, also ich würde einmal davon ausgehen, daß es paßt. Denn wenn ich mir etwa oder anschaue, dann scheint das mit den von Dir oben geposteten Meldungen wie z.B. recht gut überein zu kommen oder? ;) Viele Grüße olc

Hi Andreas, klasse, vielen Dank für Deine Rückmeldung. :) Konntest Du den Bearbeitern entlocken was an den XML-Dateien fehlerhaft war? Da diese sich nicht in jeder Situation wiederherstellen lassen würde mich interessieren, was genau defekt war. Viele Grüße olc

Hi Albert, Du könntest versuchen den Ordner "%SYSTEMROOT%\GroupPolicy" (versteckter Ordner) zu löschen und ebenfalls die "secedit.sdb" nebst Logdateien unterhalb von "C:\Windows\Security". Danach einen Neustart durchführen und schauen, ob die Richtlinien immer noch greifen. Viele Grüße olc

Hi Andreas, olc. :) Ok, dies macht nur "Sinn", wenn der komplette ConflictAndDeleted Mechanismus nicht korrekt läuft. Sonst wären die Daten durch die Quota-Beschränkung gelöscht worden. DFS-R "weiß" immer, welche Daten es replizieren muß. Daher wurden ja auch Daten in den C&D Ordner verschoben. Daß es nicht Deiner Erwartungshaltung entsprach, ist ein anderes Thema. ;) Das klingt eher danach, als ob Du die Initialreplikation in die falsche Richtung hast laufen lassen. Aber gut, mit den vorhandenen Informationen ist das schwer zu sagen... Kann viele Gründe geben - aber was das Quota damit zu tun haben soll, wäre mir hier schleierhaft. Das glaube ich eher nicht - aber siehe oben; das ist im Moment schwer zu sagen. Ok, dann sollten sich die Probleme ja hoffentlich gelöst haben. Je nachdem, wie beschädigt die Datei ist, kann man da manuell noch etwas versuchen. Es gibt jedoch auch einen Grad der "Zerstörung", wo nichts mehr geht. Ab diesem Zeitpunkt ist dann spätestens das Backup gefragt... Ok, Du hattest vergessen zu erwähnen, daß Du das als Test durchgeführt hast, ob die Datei als solches in Ordnung ist. So gesehen hast Du natürlich Recht. "Bestens". Das beste Backup nützt nichts ohne regelmäßige Rücksicherungstests. Aber das weiß nun auch diese Firma. :D Würde mich interessieren, ob das geklappt hat. Es wäre klasse, wenn Du dazu einmal eine Rückmeldung geben könntest. Diese Wiederherstellung der XML Manifest-Datei könnte ja im Normalfall nur manuell erfolgen... Wenn man das Pre-Staging / Pre-Seeding korrekt angeht, dann klappt das auch ohne die von Dir beschriebenen Probleme, siehe Ask the Directory Services Team : Get out and push! Getting the most out of DFSR pre-staging Viele Grüße olc

Hi, dann liegen diese übersprungenen Dateien wahrscheinlich nicht in dem von Dir angegebenen Änderungszeitraum. Hast Du einmal versucht die Daten im Robocopy Befehl zu ändern und dann geprüft, wie sich der Kopiervorgang verhalten würde? Viele Grüße olc

Hi bulliboy, schau einmal hier hinein, ob die Rechte korrekt gesetzt wurden: Ask the Directory Services Team : Automatic creation of user folders for home, roaming profile and redirected folders. Viele Grüße olc

...und es ist sicher die "Default Domain Controllers" Policy und nicht die "Default Domain Policy"? Es würde dann natürlich im Normalfall für alle Clients greifen und nicht nur für die Vista Clients. Wie hast Du die Verlinkung gegengeprüft? Über die GPMC? Um kurzfristige Probleme zu vermeiden könntest Du theoretisch eine weitere Policy erstellen, das entsprechende Setting setzen und diesem dann eine höhere Priorität geben als allen anderen Policies. Aber das wäre natürlich nur eine Notlösung. Viele Grüße olc