olc

Hi viper, Gutes Buch. Deutsche oder englische Ausgabe? ;) Klingt gut. :) Aber warum zwei Issuing CAs? Denke nicht, daß Du bei der Mitarbeitergröße zwei ausstellende CAs brauchst oder? Willst Du das Management damit regeln? Also auf die Schnelle kann ich in diesem Script keinen Fehler erkennen. Aber das ist ja schon das modifizierte, nicht das Ursprungsscript oder? Was heißt, daß Du beide Varianten getestet hast? Das von Dir gerade gepostete Script sollte gut sein. Sollten zum jetzigen Zeitpunkt schon Zertifikate ausgestellt sein, solltest Du diese dann erneuern - sonst sind die CRL-Pfade darin nicht korrekt. Ok, wie oben geschrieben - es liegt nicht daran, daß kein DC erreichbar ist, sondern am falschen Configuration NC. Aber das sollte ja jetzt geklärt sein. :) Meld Dich einmal, ob es geklappt hat. Viele Grüße olc

Hallo pairosilva, es geht ausschließlich um Dateien, die von einem FIleserver zum anderen repliziert werden sollen, oder auch um andere Dienste, die "Ausfallsicherheit" gewährleisten sollen? Grundsätzlich ließe sich das Szenario sicherlich mit DFS + FRS lösen, jedoch ist FRS meiner Meinung nach recht fehleranfällig und zeigt im Produktionsbetrieb eine Menge Punkte, die für ein solches Szenario nicht optimal sind. Wir denn auf beiden Seiten gleichzeitig an den gleichen Daten gearbeitet? In diesem Fall ist die Replikation sowieso immer ein Problem, da es fast zwangsweise früher oder später zu Kollisionen kommen wird. Handelt es sich bei den Systemen um Windows Server 2003 "R1" (nicht SP1 ;) ) oder Windows Server 2003 R2 Installationen? Viele Grüße olc

Hallo viper999, Na ja - funktionieren ist relativ. Damit erzwingst Du das Schreiben eines falschen Veröffentlichungspunkts; Du hast nun wahrscheinlich einen nichtssagenden Container mehr im AD - die Clients bekommen davon nichts mit, denn sie schauen nur auf den korrekten Store, nicht auf den falschen von Dir "erzwungenen". Soll heißen: Deine CRL ist auch nach dem Erzwingen nicht wirklich veröffentlicht. Das können wir hier so nicht beurteilen - Du hast nichts weiter zu Deiner Umgebung geschrieben. Bisher ging es nur um den Veröffentlichungspunkt der CRL. ;) Um welche Bücher handelte es sich denn? Auf welcher Seite der Bücher hast Du die oben von Dir aufgeführte Kommandozeile gefunden? Wenn es so in einem Buch stehen würde, wäre das ein grober Schnitzer. Ich vermute eher, daß es beim Übertrag nicht ganz korrekt gelaufen ist oder? Siehe oben - bisher war nur von der Root-CA die Rede. Ja, ich denke schon. Es kann durchaus Szenarien geben, wo dies nicht unbedingt gewünscht ist. Ist z.B. eine CRL sehr groß, kannst Du neben Performanceproblemen der AD auch Timeouts beim Abrufen der CRLs über LDAP bekommen. Dann müßte auch hier etwas "umkonfiguriert" werden. In den meisten Fällen ist es jedoch keine schlechte Idee, die CRLs über die AD zu verteilen. Zusätzlich sollten natürlich auch weitere Verteilungspunkte vorhanden sein, so z.B. per HTTP oder FTP (was bei Dir ja der Fall ist). Nein, im Grunde gibst Du ja den vollkommen falschen Pfad zum Configuration NC an - damit kann dieser auch nicht gefunden werden. Führst Du denn das certutil -dspublish auf der Root-CA selbst aus? Falls ja solltest Du natürlich (neben der Anpassung der Kommandozeile - siehe oben) die CRL über ein System in die AD schieben, welches Zugriff auf dieselbige hat und Du auch die entsprechenden Benutzerrechte zur Veröffentlichung verfügst. Daß Die Root-CA in einer Arbeitsgruppe ist, ist grundsätzlich erst einmal kein Problem und in vielen Umgebungen so gewünscht. Das kommt ganz auf die gewünschte Konfiguration / Umgebung an. Viele Grüße olc

Hallo viper999, Ich denke, daß hier der Fehler liegt: 79:ldap:///CN=<CATruncatedName><CRLNameSuffix>,<ServerShortName>,CN=CDP,CN=Public Key Services,CN=Services,CN=Configuration,DC=Domänenname,DC=local<CDPObjectClass> Wenn Du tatsächlich im Script z.B. <CATruncatedName> und die weiteren Platzhalter aufgenommen hast anstatt der entsprechenden Variablen, kann es hier zu Problemen kommen. Versuche es einmal mit: certutil -setreg CA\CRLPublicationURLs "65:%windir%\system32\CertSrv\CertEnroll\%%3%%8%%9.crl\n79:ldap:///CN=%%7%%8,CN=%%2,CN=CDP,CN=Public Key Services,CN=Services,%%6%%10\n6:http://192.168.0.214/CertData/%%3%%8%%9.crl\n0:file://\\%%1\CertEnroll\%%3%%8%%9.crl" Bei der "file://" Angabe solltest Du den Pfad noch einmal gegenprüfen, scheinbar hast Du ihn anders gewählt als den Standard. Weiterhin würde ich mir überlegen, ob ich tatsächlich eine IP-Adresse als Webserver URL angeben würde. Ein CNAME ist schnell im DNS angelegt und unter Umständen langlebiger als eine IP-Adresse. :) Viele Grüße olc

Hi, Microsoft hat es sich bestimmt nicht "leicht gemacht" mit diesem Vorgehen. Vielmehr hat Vista / Windows Server 2008 schlichtweg ein in vielen Bereich komplett umgestaltetes Sicherheitsmodell, welches in einigen Bereichen die alten Vorlagen sicherlich obsolet werden läßt. Ich wäre wahrscheinlich eher vorsichtig, einfach die alten Vorlagen zu verwenden. Unter Umständen verbiegst Du damit Einstellungen, die besser so bleiben sollten, wie sie standardmäßig sind. Viele Grüße olc

Hi, weiß nicht, ob das Problem noch aktuell ist; falls ja prüft doch bitte einmal folgenden Artikel: Event ID 53258 is logged in Event Viewer after you install or remove Active Directory in Windows Server 2003 . Viele Grüße olc

Hallo Edgar, ich weiß nicht genau ob ich das richtig verstehe - falls ja könntest Du z.b. ein "sleep 30" einbauen anstatt der Sprungmarke. Viele Grüße olc

Hi, ja, das ist korrekt. Der KCC sorgt für die Vererbung des Schedules - es sei denn, das Connection Object wurde manuell verändert oder komplett manuell angelegt. Das steht auch im oben genannten Artikel. ;) Da Du oben jedoch <automatically generated> angegeben hast, kommt z.B. die manuelle Bearbeitung des Connection Objects in Frage: Denn wenn Du über die Sites & Services GUI eine Änderung vornimmst, wird die Verbindung nicht mehr vom KCC verwaltet, sondern gilt als manuell angepaßt. Habt Ihr denn die automatisch generierten Objekte angepaßt? Normalerweise ändert sich in diesem Fall auch der Name des Connection Objects - es sei denn, die Änderung erfolgte z.B. direkt über ADSIEdit (wie oben oder im Artikel angegeben). Möchtest Du das ändern, kannst Du die entsprechenden Verbindungsobjekte einfach löschen - der KCC legt dann wieder automatisch generierte Objekte an, die nun wiederum den IP Site-Link Schedule erben. Viele Grüße olc

Hallo, ich nutze es zwar nicht, jedoch war in der c't 9/2007 vom 14.04.2008 auf Seite 196 ein Artikel zu diesem Thema. Es wurde dort vom Autor eine Projekt(zeit)erfassung mittels Outlook 2007 und Access gebaut. Vielleicht kannst Du ja damit auch etwas anfagen. Viele Grüße olc

Hi Errazzor, im Normalfall zieht bei der standortübergreifenden Replikation das Setting auf dem IP Site-Link, solange a) das Connection Object automatisch generiert wurde und damit diese Einstellung vererbt bekommt (was bei Dir offensichtlich der Fall ist) b) die Einstellung nicht auf dem Connection Object selbst manuell geändert wurde (CN=<GUID_des_Connection_Objects>,CN=NTDS Settings,CN=<Servername>,CN=Servers,CN=<Site-Name>,CN=Sites, CN=Configuration,DC=<domain>,DC=<tld>). Wurde unter Umständen die Change Notification für Inter-Site Replikation manuell eingestellt? Siehe Appendix B - Procedures Reference . Viele Grüße olc

Hallo Errazzor, bei der Intersite Replikation ist der Site-Link soetwas wie ein Container. Dieser bestimmt, wann der Schedule überhaupt geöffnet wird. In Deinem Fall also alle 180 Minuten. Wenn der Schedule nicht offen ist, kann auch nicht repliziert werden. Diese Settings vererben sich auf die entsprechenden Connection Objects der per Intersite Replikation verbundenen DCs. Bei der Intrasite Replikation werden die Schedules der Connection Objects dann über die NTDS Setting Objekte der entsprechenden Site vererbt. Das war die "Kurzfassung". ;) Schau mal hier, vielleicht hilft das folgende HowTo Deinem Verständnis weiter? Es ist ein wenig ausführlicher geschrieben: Windows Server How-To Guides: Replication Schedules unter Windows Server 2003 - ServerHowTo.de Viele Grüße olc

Hi, allzu viel gibt es ja nicht mehr zu sagen, viele Punkte wurden ja schon angesprochen. Grundsätzlich würde ich auch noch einmal bekräftigen wollen, daß Ihr vielleicht weniger in Richtung vieler 32bit Systeme gehen solltet, sondern eher in Richtung "weniger" x64 Systeme. Bei der genannten Benutzeranzahl ist grundsätzlich erst einmal - je nach Umgebung - eine größere NTDS.DIT zu erwarten. Je größer der RAM in diesem Fall, umso besser (die alte Daumenregel, daß die NTDS.DIT in den RAM passen sollte, zählt nämlich immer noch ;) ). Außerdem wird der Global Catalog auch währscheinlich eine gute Größe haben, die in der Datenbank und damit im RAM untergebracht sein will. Mann kann sich hier überlegen, ob man nur einige DCs zu Global Catalogs hochstuft und nicht alle. Müßte man einmal genauer betrachten... Letztendlich ist wie schon gesagt die supportete Obergrenze unter Windows Server 2003 1.200 DCs (wie angesprochen begrenzt durch die FRS Thematik) - aber mal ehrlich: Solche Umgebungen benötigen einen unglaublichen Aufwand, um allein die Rollenkonzepte, das Monitoring, Staging, Updates etc. in den Griff zu bekommen. In vielen Fällen fahren die Firmen also auch wieder die DC Anzahl herunter, weil der administrative Overhead einfach extrem wird. Und außerdem: x64 ist die eierlegende Wollmilchsau und löst all unsere Probleme, oder? ;) :D Viel Erfolg und halt uns auf dem Laufenden. :) Viele Grüße olc

Hi Bengah, in Bezug auf "beidseitige" Synchronisation / Replikation ist RSync leider keine Option. Das hatten wir jedoch oben schon "abgehakt". ;) Unison nutzt das RSync Protokoll, kann jedoch beide Seiten abgleichen und nicht nur in eine Richtung (gleichzeitig) synchronisieren / replizieren. Problem bei Unison ist der Zeichensatz, was in einigen Umgebungen zu unschönen Effekten führen kann. Viele Grüße olc

Hi Apex, solange Deine Benutzerrechte dies ermöglichen, kannst Du bei icacls soweit ich weiß auch mit UNC-Pfaden arbeiten. D.h. Du gibst das remote System bzw. den Pfad zu den Ordnern als UNC Namen mit. Einen bestimmten Benutzer kannst Du mittels "/remove" Schalter entfernen, gefolt von der SID des Benutzers (und einem weiteren Parameter). Schau dazu einmal in die icacls Hilfe. Grundsätzliche Frage: Muß es icacls sein oder hast Du das nur "spontan" gewählt? Sicherlich gibt es auch andere Tools / Scripts / Möglichkeiten Dein Ziel zu erreichen. Viele Grüße olc

Hi, hast Du die Seite in den Zoneneinstellungen (Intranet, Trusted Sites) in die vertrauenswürdigen Seiten mit aufgenommen? Falls nicht, versuche das bitte einmal. Viele Grüße olc

Hi, schön, daß es funktioniert. Der Lsa-Fehler im NetSetup.log hat auch in Richtung Netzwerk gezeigt. Aber im Grunde auch umso ärgerlicher, denn Sam hatte das mit der Firewall schon vor einiger Zeit eingeworfen. Ich dachte, das hättest Du gegengeprüft - hätte Dir (und uns ;) ) einiges an Arbeit und Zeit erspart... Aber man gönnt sich ja sonst nichts. :D Viele Grüße olc

Du, sei mir jetzt nicht böse, aber liest Du unsere Beiträge überhaupt? Hast Du nicht in den oben von mir geposteten Link hineingeschaut? Gruß olc

Hallo, Du hast die Antwort schon bekommen. Hast Du Dir denn einmal die Syntax z.B. für icacls angeschaut? Microsoft Corporation Entweder Du scriptest Dir das ganze noch ein wenig schöner oder Du nutzt z.B. /findSID . Ansonsten fällt mir spontan noch die PowerShell ein, mittels Get-Acl kannst Du Dir auch recht einfach einen bestimmten Benutzer heraussuchen. Viele Grüße olc

Hi, ergänzend: https://www.mcseboard.de/windows-forum-ms-backoffice-31/fileserver-auswerten-133297.html Oder halt mit xcacls oder icacls. Viele Grüße olc

Hi lefg, klar, da hast Du Recht. Aber dieses Problem hast Du immer, nicht nur bei Robocopy. Und die bisher genannten Techniken sperren alle nicht. Und da es eher kostenlos / kostengünstig sein soll, wird kaum eine andere Lösung in Frage kommen. [EDIT] Zweiter... ;) [/EDIT] Viele Grüße olc

Hi ela, nein, das heißt es nicht. Wie angedeutet könntest Du theoretisch FRS nutzen, davon würde ich persönlich jedoch eher abraten. Es gibt auch andere (kostenpflichtige) Software auf dem Markt - aber dann könntest Du auch den R2 kaufen. Wenn Du beidseitig "replizieren" möchtest, kannst Du robocopy nicht wirklich gut nutzen. Warum also eine GUI? Für alle Fälle trotzdem der Link zu einem kurzen Artikel zur GUI für Robocopy Utility Spotlight: Robocopy GUI - aber im Grunde läßt sich das alles auch selbst recht schnell zusammenschreiben (mit den Kommandozeilenparametern). Wie oben angesprochen solltest Du Dir unter Umständen einmal UNISON anschauen - das kann "beidseitig" kopieren. Viele Grüße olc

... auch diese Frage wurde schon geschätzte 12x beantwortet. ;) Gruß olc

Hi Sam, wieso verzeihen - ist doch ein guter Einwand. :) Ich würde das jedoch eigentlich ausschließen, da a) laut TO keine Events geloggt werden b) auch Clients nicht zurück in die Domäne geholt werden können, die gerade noch drin waren - die sollten im Normalfall synchron mit dem PDCe sein Aber checken kann man es ja trotzdem mal (neben den anderen Themen). :) Viele Grüße olc – ...habe das gerade noch einmal getestet - die Zeit wird automatisch nach Abgleich der Credentials bzw. bei größeren Differenzen beim Neustart beim Domänenbeitritt auf die Zeit des DCs gesetzt, mit dem man gerade verbunden ist (in diesem konkreten Fall ist ja nur einer da). W32TM machts möglich. Wußte ich bisher auch nicht. Coole Sache. ;) Daran sollte es also nicht liegen - aber Du kannst es ja trotz alledem noch einmal prüfen. Sind ja erst einmal ein paar Schritt durchzuführen, bis wir hier weitermachen können. ;) Viele Grüße olc

Hallo, zum konkreten Problem kann ich leider nicht viel sagen - würde mich jedoch wundern, wenn es ein Kerberos Problem wäre (Kerberos hat erst einmal nichts mit dem Browsing durch Ordner im Explorer zu tun - oder bekommst Du ein "Access denied"?) Was heißt in diesem Zusammenhang "klemmt beim Durchsuchen"? Aber wenn Du mit der MTU "herumspielst", solltest Du folgende Änderung in Betracht ziehen: How to force Kerberos to use TCP instead of UDP in Windows Server 2003, in Windows XP, and in Windows 2000 Gerade bei VPNs gibt es immer mal wieder Probleme mit Kerberos über UDP. Daher ist der Wert auch bei Windows Server 2008 standardmäßig kleiner, so daß im Normalfall TCP verwendet wird, nicht wie "früher" UDP. Viele Grüße olc

...ja, im Idealfall schon. Da hast Du / habt Ihr Recht. ;) Wenn man dann aber konsequent sein will, sollte man auch gleich noch die Security DB zurücksetzen. :) Gruß olc