olc

Hi, Du könntest beispielsweise mittels Backlog prüfen, wie viele Dateien noch in der Queue hängen: C:>dfsrdiag backlog /RGName:test1 /RFName:test1 /SMem:DMW2K3R201 /RMem:DBW2K3R201 Siehe dazu auch Windows Server How-To Guides: Teil 2 - Die Health Reports, Propagation Tests und Backlogs - ServerHowTo.de Viele Grüße olc

Hi, ich habe im Hinterkopf, daß die per GPO vergebenen Einträge nicht in "ipconfig /all" angezeigt werden. Von daher kann es sein, daß diese greifen und nur nicht angezeigt werden. Mach doch einmal einen ping oder ein nslookup auf einen Client einer DNS-Domäne, die Du oben zusätzlich verteilst - wird der Client gefunden, d.h. greifen die Suffixe? Viele Grüße olc

Sorry, hatte oben vergessen, daß auf der Seite nicht alles angezeigt wird, wenn man den Link direkt setzt. Daher hier mal das Zitat: Viele Grüße olc

Hi, Nils hat Recht, für den Anfang sicher keine leichte Aufgabe. Obwohl Du dafür nicht die PowerShell v2 benötigst, WMI kann man direkt remote lesen, auch ohne PowerShell remote Funktionen. Alternativ ADSI, wie schon erwähnt wurde. Aber wenn Du Dir die Arbeit nicht selbst machen möchtest, dann schau mal hier: Query Members of local Administrators Group : Powershell WMI Die Serverliste dafür kannst Du entweder recht einfach mittels "dsquery computer" erstellen oder aber ebenfalls per PowerShell. Das sollte nicht schwer sein. :) Viele Grüße olc

Hi, der DFS-Dienst läuft auf den Systemen? Viele Grüße olc

Hi Oezkan, wird "WFFS" überhaupt über FRS repliziert oder ist es unter Umständen nur ein DFSN Link ohne Replikation? Ultrasound zeigt nur die replizierten Ordner an. Viele Grüße olc

Hi, wenn der Fehler nicht mehr auftritt, brauchst Du die Kennwörter auch nicht mehr ändern. :) Je nach System ist das vielleicht in der Zwischenzeit, in der die Kerberos eType Richtlinie verändert war, vielleicht automatisch schon passiert. Das könntest Du bei Interesse noch herausfinden, indem Du per "repadmin /showobjmeta DC_NAME DN=konto,OU=OU,DC=domain,DC=tld" das Attribut "pwdLastSet" prüfst. Wenn der Zeitraum der letzten Änderung im Zeitrahmen der Policy Änderung ist, hast Du die Erklärung. :) Viele Grüße olc

Hi Carsten, der PDC-Emulator der Domäne ist online und erreichbar (Firewall etc.)? Sind vielleicht noch alte, verwaiste Stämme vorhanden (in der Registry oder im AD)? Viele Grüße olc

Hi, den "password reset" hatte ich ja oben vorgeschlagen. Nur merkwürdig, daß es nach dem Entfernen der Policy ohne weitere Aktionen wieder klappt. :suspect: D.h. die Probleme sind damit verschwunden? Viele Grüße olc

Hi, der Hotfix paßt nur die Funktion der CertSrv Webseite für Windows Vista / Windows 7 Clients an, auf bestehende Zertifikate hat er keinen Einfluß. Viele Grüße olc

Hi, schau einmal hier hinein, unter Umständen kannst Du die Encryption Types verändern: Changes in Kerberos Authentication Alternativ ist es einen Versuch wert, den Computer- oder Useraccount Kennwort zurückzusetzen - das kann jedoch je nach System einen Domänen-Rejoin notwendig machen. Was sind denn das für Accounts, die die Anforderungen senden? Schlägt dann die Kerberos Authentifizierung fehl oder was passiert genau (außer den Fehlermeldungen)? Viele Grüße olc

Hi, es ist nachvollziehbar, daß die Einstellung auf dem Client erhalten bleibt: Du änderst die Einstellung in der *.inf Datei, nicht über die GPEDIT.MSC. Daher ändert sich die Versionsnummer der Gruppenrichtlinie nicht und der Client zieht die Einstellungen nicht erneut (da er standardmäßig nur die Versionsnummern prüft und die Richtlinie nicht jedes mal neu anwendet). Spätestens, wenn Du einen neuen Client in die Domäne hebst oder ein "GPUPDATE /FORCE" auf dem Client ausführst, wird die Einstellung meines Erachtens deaktiviert werden. ich möchte also nochmals anmerken, daß ich diese "Lösung" für fragwürdig halte und in der Form nicht umsetzen würde. Die Tests bisher sind (nett gesagt ;)) wenig repräsentativ. Viele Grüße olc

Hi, der Treffer Platz 1 meiner Suchmaschine zu "script primary group" ist folgender: http://www.microsoft.com/technet/scriptcenter/resources/qanda/aug05/hey0831.mspx :wink2: Viele Grüße olc

Hi, noch eindeutiger, als es der Blog Eintrag und der Dialog beim Einrichten des Loggings angibt, geht es kaum. :wink2: Es wird nicht im Ereignisprotokoll geloggt, sondern in den von Dir angegebenen Dateien. Viele Grüße olc

Hi Leute, ich werde wahrscheinlich mal vorbei kommen bzw. dabei sein. :) Viele Grüße olc

Hi, das muß Du bei den Templates entfernen, die zum Enrollment feigegeben sind. Das sollten im Normalfall jedoch nicht so viele sein. "Irgendwer" muß den Haken gesetzt haben (und hatte vielleicht einen Grund dafür?). Das "warum" würde ich also in dem Kontext auch noch einmal prüfen. ;) Viele Grüße olc

Hi, genau, das ist die Option. Man muß sich überlegen, ob ein Key Archival gewünscht ist oder nicht. Je nach dem Ergebnis gestalten sich dann die nächsten Aktionen. :) Viele Grüße olc

Hi Morro, danke für den Test und das Posten der Ergebnisse. Also lieber die Finger davon lassen und solche "Tipps" nicht ohne Tests umsetzen. Oder gleich die neue GPMC benutzen bzw. schlichtweg andere Wege als die IE Maintenance nutzen (etwa GPP). :) Viele Grüße olc

Hi, wie gesagt - das ist nur so mein Gedanke dazu. Bevor man die Einstellung also einfach ändert, sollte man das getestet haben. Bezüglich der GPMC: Das es gefixt wurde, ist "Fakt". :) Eine Quelle finde ich gerade nicht, aber ein kurzer Test zeigt Dir sicherlich, daß es mit der aktuellen Version klappt. ;) Viele Grüße olc

Hi Thomas, welche Berechtigungen hast Du denn = welcher Benutzer ist beim Webenrollment angemeldet? Wenn Du die MMC nutzt, müßtest Du das Computerzertifikate SnapIn verwenden, nicht "certmgr.msc", denn das ist standardmäßig im Benutzerkontext. Testweise könntest Du noch einmal versuchen, auf dem Template den Domänen-Admins als auch Domänen-Controllern Read, Enroll und Autoenroll Berechtigungen direkt zu geben. Nur um zu schauen, ob sich etwas an dem Verhalten ändert. Funktioniert das Enrollment anderer Zertifikate / Templates? Sind irgend welche Fehlermeldungen auf der CA oder den anfragenden Systemen in Bezug zu finden - z.B. zum secure channel, NETLOGON etc.? Viele Grüße olc

Hi zusammen, ich bin zwar nicht der IE Maintenance Profi - aber mein Gedanke dazu: Der Report funktioniert mit dem Workaround zwar wieder - aber die Security Zones werden nach der Änderung nicht mehr angewendet / importiert, korrekt? So zumindest mein Verständnis von der Option. [security Imports] Was nützt also ein "korrekter" Report, wenn die gewünschten Einstellungen nicht mehr geifen? Übrigens ist das Problem in der GPMC Version Vista / 2008 behoben. Viele Grüße olc

Hi, in einem der zum Enrollment / Autoenrollment veröffentlichten Templates der CA ist scheinbar die Option zur Zertifikat-Archivierung aktiviert worden. Das geht jedoch nur, wenn ein entsprechendes Konto / Zertifikat definiert wurde, welches ein Recovery durchführen darf. Das ist bei Euch scheinbar nicht der Fall. Also muß entweder ein Key Archival Konto bestimmt und ein Zertifikat dafür ausgestellt werden oder Ihr deaktiviert die Option auf dem / den Template/s. Siehe dazu Understanding Automatic Key Archival und Planning Considerations Viele Grüße olc

Hi, die GPP bieten ein Logging - ativiere dies doch einmal und schau darin nach Fehlermeldungen: Ask the Directory Services Team : Enabling Group Policy Preferences Debug Logging using the RSAT Viele Grüße olc

Hi, wenn Du einen Windows Server 2003 oder 2008 Server zur Verfügung hast, könntest Du die "eingebauten" CA-Dienste nutzen. Ansonsten geht das beispielsweise auch mit jedem Linux System: Generating X.509 Certificates Viele Grüße olc

Hi, wo genau erstellst Du die Ordner in den GPP Einstellungen? Im Benutzer oder im Computer Bereich? Computer Bereich kann mit den Variablen nicht funktionieren, es müßte also im Benutzer Bereich erfolgen. Viele Grüße olc