olc

Hi, das kann DFS-R natürlich auch - schließlich wird neben Zeitstempeln etc. das NTFS-Jounal zur Änderungsüberwachung genutzt. Das ist jetzt nicht böse gemeint - aber ich werde das Gefühl nicht los, daß bei Euch auf Teufel komm raus DFS-R nicht eingesetzt werden soll - auch ohne sich wirklich tiefer damit befaßt zu haben. Nach dem Motto: Es kann nicht sein, was nicht sein darf. Aus diesem Grund steige ich an dieser Stelle mal aus. ;) Gruß olc

Ja, nee. Is klar, ne? :D Nein, vielen Dank für Deine Antwort. Ich werde mir das noch einmal näher anschauen. Danke und Gruß olc

Hallo, danke für Eure Antworten - aber meine Fragen sind damit nicht beantwortet. :p Es geht mir konkret - wie geschrieben - um IPSec VPNs. OpenSWAN (?) muß nachinstalliert werden oder? Was nutzt Ihr für Features der *-WRT Firmware? Nutzt Ihr zusätzliche AddOns? Wie ist es eigentlich mit der Sicherheit der Firmware? Gab es in der VErgangenheit größere Sicherheitslücken? Lassen sich die Geräte ggf. problemlos updaten / upgraden? Danke nochmal und Gruß olc

Hallo, was macht rsync in Bezug auf Konflikte anders? Gruß olc

Hi, sorry, daß ich den Thread "kapere". Aber ich habe auch schon oft hin und her überlegt, ob ich mir ein solches Gerätchen einrichten sollte. Nutze derzeit IPCop, aber 99% der Online-Zeit ist das unnütz für meine Ansprüche zu Hause. Open- oder DD-WRT bringen standardmäßig keine (IPSec-) VPN Möglichkeiten mit oder irre ich mich da? Der Durchsatz für (IPSec-) VPNs nach Installation ist auch nicht sehr hoch. Was nutzt Ihr so für Funktionen damit? Nutzt Ihr nur die "Standards" oder installiert Ihr Euch AddOns? Danke und Gruß olc

N'Abend, Du kannst das gewünschte z.B. erreichen, indem Du USB-Kopfhörer verwendest. Beispielsweise Microsofts Livechat oder Sennheiser USB-Kopfhörer werden dann als separate Devices erkannt und Du kannst dann getrennt festlegen, welches Device angesprochen wird. Dazu muß jedoch die jeweils verwendete Applikation unterscheiden können - aber das können mittlerweile die meisten neueren Applikationen. Gruß olc

Hallo, um Zertifikat-Templates zu erstellen / bearbeiten / veröffentlichen muß der Benutzer kein Enterprise-Admin sein, auch wenn die Templates in der Organisation / dem Forest verteilt werden. Du kannst die benötigten Rechte zum Anlegen neuer Zertifikat Templates auf dem Container CN=Certificate Templates,CN=Public Key Services,CN=Services,CN=Configuration,DC=<domain>,DC=<tld> vergeben, so z.B. in den ADUC oder mittels ADSIEdit. Nutzt Du ADUC (Active Directory Users & Computers) kannst Du die Rechte delegieren, in dem Du auf dem o.g. Container als "Custom Task" im Delegation Wizard beispielsweise "Full Control" wählst. Somit hab en die angegeben Benutzer bzw. besser Gruppen auch das Recht, Zertifikat-Templates zu erstellen. Um ausschließlich bestehende Zertifikate zu verwalten und keine neuen anzulegen, kannst Du den gewünschten Zertifikat Managern (Benutzer oder Gruppen) die Berechtigung "Issue and Manage Certificates" in den Security Settings der CA geben. Als weitere Möglichkeit (sollte mehr als nur die Delegierung der Verwaltung von Zertifikat-Templates nötig sein) wäre es denkbar, daß Du die CAs nach Zuständigkeit splittest. Daß heißt mehrere Issuing CAs installierst, auf die dann nur bestimmte Benutzer bzw. Gruppen administrativen Zugriff haben. Dies ist jedoch meist erst dann notwendig, wenn die Umgebung etwas größer ist und hat wie gesagt nur marginal etwas mit den Templates zu tun. http://technet2.microsoft.com/WindowsServer/en/library/091cda67-79ec-481d-8a96-03e0be7374ed1033.mspx Viele Grüße olc

Hi lefg, die Einstellung Always wait for the network at computer startup and logon ändert wie von Dir geschrieben den Startpunkt zur Arbarbeitung der Policies- und verlängert damit den Vorgang vor der Anmeldung. Das ist richtig. Da jedoch mit dem Aktivieren dieser Policy auch - wie oben erwähnt - das asynchrone Abarbeiten der Policies abgeschaltet wird (wenn ich mich recht entsinne), verlängert sich ebenfalls der Anmeldevorgang nach Eingabe der Credentials. Halten wir also fest: Der gesamte Boot-Vorgang inkl. der Benutzeranmeldung verlängert sich. Gruß olc

Hallo, versuche einmal testweise, ob Du nach dem Setzen der Policy Computer Configuration\Administrative Templates\System\Logon\Always wait for the network at computer startup and logon --> Enabled noch immer die selben Probleme hast. Das asynchrone Abarbeiten von Policies wird mit dieser Einstellung ebenfalls abgeschaltet. Unter Umständen löst das Dein Problem. Bitte beachte dabei, daß die Anmeldedauer nach dem Aktivieren der Einstellung länger dauert, so wie früher bei Windows 2000. Also im besten Fall erst einmal nur auf einer OU verlinken, in der ein paar betroffene Testclients liegen. Viele Grüße olc

... dann kannst Du es mit PsExec versuchen ;) : psexec -i -s cmd.exe PsExec kannst Du hier herunterladen: PsExec 1.82 Viele Grüße olc

Hallo, dafür gibt es so einige Möglichkeiten. Die schnellste Variante (quick and dirty) bezüglich Deiner Beschreibung wäre wahrscheinlich, die Daten im "SYSTEM" Kontext zu kopieren. "SYSTEM" sollte im Normalfall immer Zugriff haben, sonst bekämest Du ganz andere Probleme... In den "SYSTEM" Kontext kommst Du unter XP / 2003 beispielsweise mittels: at 05:00PM /interactive cmd Die Zeit muß wie gewünscht angepaßt werden. Es öffnet sich zur geplanten Zeit eine CMD im entsprechenden Kontext, innerhalb Du dann den XCOPY Befehl erneut ausführen kannst. Viele Grüße olc

N'Abend, <Haarspalterei>Na ja, nicht ganz - genau genommen scheint ja ein WMI Query das Problem zu verursachen. Der WUAU initiiert zwar vermutlich die WMI Abfrage, ist jedoch eher das Opfer des Prozesses oder?</Haarspalterei> Nö. :D Mal im Ernst: Kenne mich mit WMI nicht so gut aus. Aber ich würde versuchen das WMI Logging auf einem Testclient zu aktivieren und dann schauen, ob ich etwas daraus erkennen kann. Schau mal hier hinein: WMI Troubleshooting (Windows) Viele Grüße olc

Hi, also wie oben schon vermutet die WMI Abfrage...? War noch etwas im Eventlog eines betroffenen Clients zu sehen oder ist das Thema für Dich damit "erledigt"? Gruß olc

Hi, ja, das Deaktivieren des wuauclt und bits ist nach den Beobachtungen oben eine gute Idee. Danach wäre interessant, ob die WMI-Abfrage weiterhin hängt. In Richtung "GPO-Verarbeitung" geht es - denke ich zum jetzigen Zeitpunkt - eher nicht: Die GPOs sind ja als solches schon abgearbeitet. Jedoch können natürlich die Settings, die in den GPOs gesetzt wurden, durchaus auch einen Fehler nach sich ziehen. ;) Warten wir einmal die WSUS / WMI Geschichte ab und schauen dann weiter. Gruß olc

Hallo, das ist oftmals das Problem mit den "nicht-englischen" Systemen. Die Übersetzungen sind teilweise grauenhaft. Daher mein Verweis auf die MS-Seite: Dort findest Du den korrekten Fehlertext. Falls Du mit den Hinweisen nicht weiter kommst, melde Dich einfach. ;) Gruß olc

Hi, also das ist schon wirklich "komisch". Hier sind die Policies durch: USERENV(3b0.218) 08:13:38:968 PolicyChangedThread: Leaving Nur wenige Sekunden danach werden diverse userinit-Prozesse gestartet, die sehr, sehr lange laufen. Das ist sehr verwunderlich - warum werden die userinit-Prozesse mehrmals angestoßen? Meiner Meinung sollte das pro Benutzer nur ein Mal passieren... Interessant ist auch, daß der WMI-Prozess so lange braucht. Es sieht so aus, als wenn der Windows Update Dienst dort etwas anfragt oder initiiert, womit der Client eine Weile lang beschäftigt ist. Es gibt doch auch ein WMI-Logging. Vielleicht kann man da einmal hineinschauen? Ebenfalls wäre ein Blick in den Gerätemanager interessant, ob da alle Geräte mit den richtigen Treibern versorgt sind. Ggf. kannst Du auch einmal prüfen, ob Du manuell WMI -Abfragen problemlos durchführen kannst. USERENV(830.834) 08:13:41:109 LibMain: Process Name: C:\WINDOWS\system32\net.exe USERENV(948.94c) 08:13:48:031 LibMain: Process Name: C:\WINDOWS\system32\wuauclt.exe USERENV(a2c.a30) 08:13:55:625 LibMain: Process Name: C:\WINDOWS\system32\wbem\wmiprvse.exe USERENV(b4c.b50) 08:14:11:937 LibMain: Process Name: C:\WINDOWS\system32\userinit.exe USERENV(f64.f68) 08:19:09:093 LibMain: Process Name: C:\WINDOWS\system32\userinit.exe USERENV(fa4.fa8) 08:20:27:765 LibMain: Process Name: C:\WINDOWS\system32\wuauclt.exe USERENV(fe8.fec) 08:20:28:546 LibMain: Process Name: C:\WINDOWS\system32\wbem\wmiprvse.exe USERENV(3b0.3b4) 08:25:41:062 InitializePolicyProcessing: Initialised Machine Mutex/Events Der Desktop sollte dann hier zu sehen sein: USERENV(b6c.b70) 08:27:26:437 LibMain: Process Name: C:\WINDOWS\Explorer.EXE Falls der WMI-Ansatz keine Ergebnisse bringt: Was läuft auf den Clients für ein Virenscanner / Firewall (habe keinen entsprechenden Prozess finden können)? Falls dort soetwas installiert ist: Habt Ihr die testweise schon einmal abgeschaltet? Wenn Ihr den Client in eine OU ohne jegliche Policies / Scripts verschiebt, treten die Fehler dann ebenfalls auf? Waren in den Eventlogs Fehler zu finden? Kannst Du einmal einen Netzwerktrace ziehen damit man prüfen kann, was in der Zwischenzeit so über die Leitung geht? Ist wirklich schwierig einzugrenzen... Gruß olc

Hi, scheinbar ist ein DC (bzw. KCC) der entsprechenden Site nicht in der Lage, eine bestimmten Naming Context von einem anderen DC (meist auch einer anderen Site) abzurufen bzw. ein Connection Objekt dafür einzurichten. Normalerweise wird Dir in weiteren Events (mit anderen IDs wie 1865 oder 1565 wenn ich mich recht entsinne) auch angezeigt, um welche NCs und welche DCs es sich dabei handelt. Überprüfe doch einmal in den Eventlogs der DCs der betroffenen Sites, ob weitere Fehler geloggt werden. Unter Umständen loggt der betroffene DC die 1311er Fehlermedungen nur, weil er ISTG der Site ist. Das Problem kann also auf einem anderen DC vorliegen. Typische Fehlerursache sind beispielsweise Netzwerkprobleme zwischen zwei Sites (z.B. Firewall, keine korrekten Site-Links o.ä.). Schau mal hier hinein: http://technet2.microsoft.com/windowsserver/en/library/062e8eaa-27e0-4c5e-bc2b-2913ecce24b81033.mspx Viele Grüße olc

Damit hast Du allerdings vollkommen Recht. :D Sorry, habe es nur quergelesen und den Registry Key dabei wohl übersehen. Aber was solls, irgendwie muß ich meine klägliche Existenz hier im Forum ja auch rechtfertigen. :D Danke und Gruß olc

Hi, unter Umständen wurde schlichtweg das Intervall des AdminSDHolders geändert? Siehe Windows Server How-To Guides: Teil 2 - Die Auswirkungen - ServerHowTo.de im unteren Drittel. Gruß olc

Hi, kein Problem, freut mich, wenn es Dir weitergeholfen hat. Solltest Du die Registry EInträge anfassen, lösche nur die entsprechenden Keys für den "Profile" Ordner, nicht den ganzen Schlüssel. BTW: Weder unter FRS noch unter DFS-R ist das replizieren von Profilen von Microsoft offiziell supportet. Für den Fall der Fälle solltest Du das im Hinterkopf behalten. ;) Viele Grüße olc

Guten Abend, Hast Du wie oben besprochen auch auf dem entsprechenden Computerobjekt die NTFRS Subscription gelöscht? Sollte das nichts bringen, schau mal auf den MS Supportseiten zu dem Fehler nach. Der sagt mir jetzt im Moment nichts. Öhm - bisher war nicht von DFS-R die Rede. Aber offensichtlich setzt Du beides (DFS und FRS / DFS-R) ein? Oder habe ich jetzt nur nicht mehr den gesamten Thread im Kopf? :suspect: Du hast jedoch vollkommen Recht, wenn Du DFS-R nutzt: Ohne Replikationspartner und damit verbunden keinen Replikationsverbindungen, kommt es zu diesen Meldungen. Wobei sich mir der Sinn einer Konfiguration nicht ganz erschließt, die eine Replikationsgruppe eingerichtet, jedoch keine Replikationspartner definiert hat. ;) Ggf. sollte hier also noch einmal nachgeartbeitet werden - oder halt nur mit DFS-N (DFS Namespaces) gearbeitet werden. Replikationsgruppen sind dann nicht notwendig. Alles klar soweit, vielen Dank für die Rückmeldung. Gruß olc

Hallo, zieh doch einmal ein paar Testclients in eine OU und verlinke auf die OU eine GPO mit folgendem Setting: Computer Configuration\Administrative Templates\System\Logon\Always wait for the network at computer startup and logon --> Enabled Zwar sind Deine Policies bzw. deren Anwendung dann wieder "so schnell" wie unter Windows 2000, jedoch löst es unter Umständen Dein Problem. Viele Grüße olc

Hallo, das kommt auf die Version von DFS an: In Windows Server 2003 R2 wurde der alte FRS Dienst durch DFS-R ersetzt. DFS-R kann einiges mehr (siehe Link von XP-Fan) als es DFS / FRS in der Vergangenheit konnte, so z.B. auch Komprimierung der zu übertragenden Daten als auch die Übertragung von Deltas anstatt kompletter Dateien, sollten Änderungen stattgefunden haben. Viele Grüße olc

Hallo, zieh doch einmal einen Netzwerktrace vom Client aus, während Du ein ipconfig /release und danach ein ipconfig /renew eingibst. Was sagt der DHCP Traffic? Die Frage von lefg war auch sehr wichtig: Hat der Client eine APIPA Adresse oder ist gar keine IP vergeben? Das ist quasi der Unterschied zwischen "DHCP Adresse nicht bekommen" und "IP Stack / Treiber / Netzwerkkartenproblem". Gruß olc

N'Abend, Ich will jetzt nichts ausschließen, dazu sind es bisher zu wenige Informationen. Aber da die Group Policies laut Miguel schon gezogen haben wenn es zu dem Delay kommt, denke ich, daß Deine Vermutung wahrscheinlich eher nicht die Ursache ist. DNS ist meist ein guter Ansatz, aber in diesem Fall auch nicht unbedingt die Lösung. Die Policies sind ja offensichtlich da, also muß die Namensauflösung erst einmal funktioniert haben. Unter Umständne können jedoch Daten aus anderen DNS Domänen gezogen werden, dann würde es Sinn machen. Geschichten wie "GetUserNameAndDomain" können auch auftreten, wenn z.B. in Logonscripts Usernamen verwendet werden, ohne die Domäne anzugeben. In diesem Fall werden im schlimmsten Fall mehrere verfügbare Domänen nach dem Account durchsucht. Dann kann es durchaus zu Timeouts kommen. Wie eingangs schon gesagt: Es kann alles sein und nichts. Eine weitere Analyse macht m.E. erst nach einem Blick in die o.g. Daten Sinn. Gruß olc