olc

Hi, je nachdem, ob Du eine interne Windows CA einsetzt oder es sich ausschließlich um lokale Zertifikate handelt, kann ergänzend zu Dirks Beitrag auch folgendes für Dich interessant sein: Windows PKI blog : How to determine all certificates that will expire within 30 days (Beitrag als auch Kommentar unten). Viele Grüße olc

Hi Matthias, der folgende Fehler zeigt Dir wahrscheinlich die Ursche für die Verbindungsabbrüche: Wie oft tritt der Fehler denn auf? Wenn das 1x am Tag passiert, dann wird es sich sicherlich um das Backup der Daten handeln. Wenn es öfter auftritt, könnte es sich beispielsweise um ausgeführte Volume Shadow Copies o.ä. handeln. Andere Fehler werden nicht geloggt? Viele Grüße olc

Hi, vom Ansatz her macht es vielleicht eher Sinn zu posten, was Du schon zusammengetragen hast. Dann kann man drüberschauen, was man kennt und ggf. Hinweise geben. Ein komplettes Konzept oder eine vollständige Liste wird hier wahrscheinlich niemand posten. ;) Viele Grüße olc

Hallo Tristan und willkommen an Bo(a)rd, :) es ist meist sehr schwierig, das mit einem simplen "reicht" oder "reicht nicht" zu beantworten. Das hängt von zu vielen Faktoren ab. Anbei daher als Auszug nur einige wenige Punkte dazu: Wenn ich lese, daß der Exchange Server als auch der Fileserver am zentralen Standort stehen soll und die anderen Benutzer ggf. Remote auf dem Exchange Server und dem Fileserver arbeiten sollen, dann scheinen mir 2MBit erst einmal etwas wenig zu sein. Das kommt natürlich darauf an, ob etwa bei Exchange Attachments weg von dem Zentralserver "lokal" gespeichert werden sollen oder was genau für Daten auf dem Fileserver geöffnet, bearbeitet und abgelegt werden sollen. Ist hingegen irgend eine Art von Replikation geplant, die z.B. die nachts Datenbestände abgleicht oder Exchange nicht "hardcore" ausgelastet wird, dann _kann_ das reichen. Ich denke, daß Du einmal das Nutzerverhalten analysieren solltest, um einen Ansatz zu haben, wie viel Daten eigentlich im LAN anfallen. Dann weißt Du ungefähr, was Du für das WAN einplanen mußt. Viele Grüße olc

Hi, jede Frage nacheinander ist meist übersichtlicher, als alles in einem Thread abzufackeln. ;) Ja, je nach Datenmenge, Serverleistung und Netzwerkverbindung kann das der Fall sein. Das ist aus vielerlei Gründen kontraproduktiv - das macht den Vorgang noch langsamer. Laß die DFSR Dienste am besten immer laufen, umso besser läuft DFSR. Das ist bei der Initialreplikation eigentlich "normal", es sei denn Du hast das Staging Quota sehr, sehr hoch gewählt. Wenn es jedoch massiv auftritt, dann sollte das Staging Quota erhöht werden (siehe unten). Wie oft werden die Meldungen geloggt? Ja, das ist kein Problem. Es dauert halt je nach Umgebung etwas länger. :) Man könnte über sogenanntes "Pre-Seeding" eine schnellere Fertigstellung erreichen bzw. CPU / HDD / NIC Last einsparen - aber da die Initialreplikation ja jetzt schon läuft, würde ich das auch nicht mehr angehen. Zu den Staging Quotas wäre zu fragen, wie groß Du die Quotas gewählt hast? Wenn diese bei den standardmäßigen 4096MB liegen, ist das in den meisten Fällen zu wenig (insbesondere bei der Initialreplikation). Ggf. macht es hier also Sinn, das Quota zu erhöhen. Wahrscheinlich geht die Initialreplikation dann auch schneller durch. Viele Grüße olc

Hi, besteht das Problem auch im Moment noch oder hat es sich erledigt? Ich vermute, daß schlichtweg die Konfiguration noch nicht repliziert bzw. vom Dienst angewendet wurde. Viele Grüße olc

Hi caputo, wenn Du noch dazusagst, was denn genau nicht so ist, wie Du es Dir vorstellst, können wir vielleicht Lösungsansätze bieten. ;) Grundsätzlich kannst Du ABE auch mit DFSN nutzen, siehe Distributed File System: Frequently Asked Questions Viele Grüße olc

Hi, sicher erzeugt das folgende PowerShell Script temporär eine erhöhte Last auf dem System, aber Du könntest es einmal testen (ggf. nicht während des Hauptbetriebs ;) ): $a = Get-ChildItem C:\ -recurse foreach ($value in $a) { if ($value.fullname.length -gt 253) { write-host $value.fullname `t $value.fullname.length } } Viele Grüße olc

Hi, vielleicht noch ergänzend der Hinweis, daß Du auch prüfen könntest, warum sich die Clients auf das "falsche" Target verbinden. Ggf. nicht ganz korrekte Site-Konfiguration oder Netzwerkprobleme? Ist irgend ein Muster erkennbar? Viele Grüße olc

Hi Khaindar, OUs sind keine FRS Objekte, kommen also nicht über die Dateireplikation, sondern über die AD-Replikation. Wenn die nicht korrekt läuft, gibt es Probleme. Es sieht für mich eher so aus, als ob Du mehr als ein Problem hast. Ich würde vom ersten Ansatz her erst einmal die Eventlogs beider DCs prüfen danach ein DCDIAG und NETDIAG durchführen und auch Fehler überprüfen manuell die DNS einstellungen prüfen - sind beide DCs korrekt mit Ihren Host A und SRV Einträgen registriert? zusätzlich zum Beispiel mittels repadmin /replsum auf beiden DCs prüfen, ob die AD-Replikation wirklich korrekt läuft (sollte durch die beiden Punkte oben eigentlich schon geklärt sein). Danach kann man schauen, wo genau die Probleme liegen. Viele Grüße olc

Hi, was genau hast Du gemacht? Gehörte dazu auch eine Websuche? ;) Event ID 1000 and event ID 1202 are logged to the event log every five minutes in Windows 2000 Server --> Bekommst Du unter Umständen auch die im KB-Artikel genannten "Zugriff verweigert" Events? Viele Grüße olc

Hi, schaut Euch mit dem WMI Code Creator einmal die verschiedenen WMI Klassen (BIOS etc.) an, ich denke da solltet Ihr fündig werden: Download details: WMI Code Creator v1.0 WMI kann dann auch remote abgefragt werden, sofern die Rechte dazu vorhanden sind. Viele Grüße olc

Hi Freeed und herzlich willkommen, ein sagt dazu Hilft Dir das weiter? Ansonsten ist Dein Vorhaben mit der PowerShell recht einfach möglich, dazu gibt es einige Beiträge über die Boardsuche. :) [EDIT] Dukel war schneller... [/EDIT] Viele Grüße olc

Hi, wenn die Zertifikate über die Webseite angefordert werden, dann muß der Client die entsprechenden Rechte für das Template haben. Nicht-Domänenclients haben standardmäßig nicht die Rechte, ein Zertifikat zu beantragen. Ich meine mich zu erinnern, daß später in dem von Dir genannten Guide von MS auch darauf eingegangen wird. Zusätzlicher Hinweis: Eine Enterprise-CA in die Produktionsumgebung zu installieren, kann Probleme machen - unter Umständen werden im Moment munter Zertifikate von den Domänenclients und -servern angefordert. Du solltest das ganze also eher in einer abgeschotteten Testumgebung ausprobieren. Wenn Du die CA entfernst, sollte dies ebenfalls "sauber" passieren, nicht einfach "abschalten", siehe dazu auch How to decommission a Windows enterprise certification authority and how to remove all related objects from Windows Server 2003 and from Windows 2000 Server Viele Grüße olc

Hi Blobby, schön, daß es Dir weiterhilft und danke für Deine Rückmeldung. :) Die Grundsatzfrage ist oftmals, ob eine Stand-Alone oder eher eine Enterprise-CA Sinn macht. Der Vorteil einer Enterprise-CA in Windows Netzwerken ist natürlich enorm. Also macht es Sinn, mit "denen von oben" ;) noch einmal zu sprechen. Aber klar, da zählen viele Faktoren mit hinein, das entscheidet man im Normalfall nicht "einfach mal so". Certreq ist beim Einstieg erst einmal "kompliziert" - hat man dann aber ein funktionierendes "Template", gehen Änderungen schnell von der Hand. :) Viele Grüße olc

Hi, versuch es einmal über die MMC, indem Du Dir die "Zertifikate" als MMC SnapIn hinzufügst, den Bereich "Computer" auswählst und dann im "Eigene Zertifikate" Speicher per Rechtsklick einen Zertifikatantrag stellst. Bekommst Du dann das Template angezeigt? Die Berechtigungen für die angesprochene Gruppe (Read + Enroll) hast Du auf dem Template vergeben? Viele Grüße olc

Hi, das Thema wird nicht nur hier im Board heiß gehandelt und ich denke, daß das Problem schon bei einigen SP3 Nutzern aufgefallen ist. Von daher gehe ich davon aus, daß das Problem definitiv bekannt ist. Na ja, der nächste Patchday ist nicht mehr weit, dann folgen sicher (hoffentlich) auch die Hotfixes für dieses Problem. :) Viele Grüße olc

Hi, mal abgesehen davon, daß ein Virus / eine Schadsoftware nie ausgeschlossen werden kann ;), könntest Du einmal das WMI Logging einschalten und schauen, ob sich etwas aus den Logs ergibt: Turn WMI error logging on or off: Windows Management Instrumentation (WMI) Viele Grüße olc

Hi, na bestens - dann ist ja alles optimal. :) Danke für Deine Rückmeldung und Gruß olc

Hi, wie oben schon geschrieben müßte man genau schauen, welche Einstellungen gesetzt werden. Dann ergibt sich, ob es Möglichkeiten gibt oder nicht. Ein konkretes Tool für alle Einstellungen kenne ich persönlich wie schon erwähnt nicht, scheinbar die anderen Kollegen auch nicht. Haben die Rechner alle die selben Einstellungen (mal abgesehen von den Anpassungen, also sind grundsätzlich die lokalen GPOs gleich)? Falls ja kannst Du ggf. auch den gesamten Group Policy Ordner von einem "Template-System" auf die Zielclients kopieren. Viele Grüße olc

Hi, 127.0.0.1 als primärer DNS Server ist in diesem Fall nicht korrekt, trag da einmal die IP-Adresse des Zweigstellen DNS Servers ein (bzw. laß die Adresse per DHCP verteilen). Deine zweite Antwort in Bezug auf die Bearbeitung der GPOs habe ich nicht verstanden. Viele Grüße olc

Hi, ok - und was war nun die Ursache für die Probleme? Viele Grüße olc

Hi, Das heißt, wenn Du nur den 1. DNS Eintrag auf den "lokalen" DNS Server zeigen läßt, dann nehmen die Clients diesen? Ich würde eher vermuten, daß es ein Problem mit dem Zweigstellen DNS Server gibt, so daß die Client immer den Hauptstellen DNS Server nehmen, obwohl dieser in der Reihenfolge später eingetragen ist. Hast Du einmal probiert ob die Namensauflösung korrekt läuft, wenn Du nur den "lokalen" Zweigestellen DNS Server eingetragen hast? Oder meinst Du, daß die Clients als LOGONSERVER immer den DC des Hauptstandorts nutzen (und nicht, wie oben von Dir geschrieben, den DNS Server)? Standardmäßig verbindet sich die GPMC als auch der Gruppenrichtlinieneditor "gpedit.msc" immer auf den PDCe der Domäne. Dieses Verhalten kann man jedoch ändern. Wo genau hast Du es geändert? In der GPMC (falls Du diese einsetzt) oder im sich bei der Bearbeitung einer GPO öffnenden gpedit.msc Fenster? Zusätzlich ist es noch problematisch, daß die GPC Einstellungen (also der AD-Teil der Policy) nicht unbedingt auf den selben DC geschrieben werden, wie die GPT (also SYSVOL-Informationen). Hier greiften die SYSVOL Referrals, nicht die Einstellungen des Gruppenrichtlinieneditors. Was also wird genau auf den Hauptstellen DC geschrieben (der sicherlich PDCe ist): Die AD-Einstellungen oder die SYSVOL Daten? Viele Grüße olc

Hi, mir persönlich wäre da kein (MS builtin) Tool oder Script bekannt. Vielleicht gibt es da aber andere Hersteller, die etwas dazu programmiert haben. Mal abwarten, ob hier jemand eine Idee dazu hat. Um welche Einstellungen geht es denn genau? Unter Umständen kann man die Einstellungen auch über andere Wege setzen (etwa die Registry). Viele Grüße olc

Ok, mach das. Laß Dich nicht unterkriegen. Jede Scherbe spiegelt das Licht. :wink2: Viele Grüße olc