olc

Hi Leute, Ach na ja - wie man es nimmt. Kommt immer drauf an, was man sonst so macht. :D :D :D Bestens, vielen Dank! Ok, also eher im Client-Bereich. Klingt ja soweit erstmal vernünftig. Vielen Dank und viele Grüße olc

:D Das ist mir klar. ;) Zum Thema: Was heißt "recht gute Erfahrungen"? Die Katze im Sack möchte ich nicht kaufen. ;) Gruß olc

Hi, Sehr gut, das klingt optimal. :) Mach Dir keine Arbeit - Suchmaschinen benutzen kann ich auch, da mußt Du keine Zeit investieren. :) Ok, also schon etwas mehr Daten als "private Dokumentensammlung". Das freut mich zu hören. Wie gesagt, ich möchte einfach mal die Erfahrungswerte hören, um mich da geistig nicht zu früh einzugrenzen. Ja, die Frage ist berechtigt. Es geht im Grunde um normale Windows Clients, bei denen ein Dualboot-System genutzt werden soll, als auch um ein paar Fileserver, die mehr oder minder unter Last stehen. Mittlere Zugriffsrate, also so von 100 - 500 zugreifende Benutzer, die die Dateiserver nutzen. Das heißt nicht notwendigerweise gleichzeitig, in Spitzenzeiten ist das jedoch durchaus möglich. Ist nur so ein "nebenbei" Projekt, hat nichts mit meiner normalen Arbeit zu tun. :) Daher möchte ich einfach ein paar Erfahrungen lesen, um mir darüber Gedanken zu machen. Vielen Dank nochmals und viele Grüße olc

Hi Johannes, vielen Dank für Deine Rückmeldung. Das klingt ja soweit ganz gut. Hast Du bei den Aktionen auch das Schreiben auf die NTFS Partitionen stärker genutzt? Lesend war es ja schon vor den 3G Treibern problemlos möglich auf die Partitionen zuzugreifen. Im Grunde wäre also interessant, ob jemand schon einmal "hardcore" Schreibaktionen durchgeführt hat. Stichpunkte wie was passiert, wenn das System beim Schreiben abstürtzt - ist das Journal beschädigt oder arbeitet die 3G Treiber korrekt? wurden Junction Points oder ähnliche "Spezialitäten" von NTFS genutzt? wenn größere Datenmassen geschrieben werden, gibt es Performance Probleme? wie groß waren die einzelnen Dateien, die Ihr geschrieben habt; wie hoch die gesamte Datenmasse (GB, TB) insegesamt? etc. würden mich da interessieren. Ich möchte jedoch bewußt nicht zu viele Stichpunkte nennen, um ein wenig Erfahrzungen zu bekommen und nicht ausschließlich ganz konkrete Antworten auf die Stichpunkte. ;) Danke nochmals und Gruß olc

Hi, vielen Dank für Deine Antwort. Wie genau hast Du die Treiber genutzt, d.h. was war der Hintergrund, welche Aktionen wurden während der Nutzung durchgeführt? Ich habe nichts anderes behauptet oder? Weiterhin ist openSuSE ebenfalls "Open Source Software". Aber bitte jetzt hier keinen Flamewar bezüglich GPL und Distributionen anzetteln. Ich möchte lediglich Erfahrungsberichte zur Thread-Frage. ;) Viele Grüße olc

Hallo, da es seit einiger Zeit möglich ist auch unter Linux NTFS lesend und schreibend zu nutzen würde mich interessieren, ob jemand von Euch schon Erfahrungen damit gesammelt hat. Laufen die NTFS-3G Treiber stabil, gibt es Dinge zu beachten (etwa Performance, Berechtigungen etc.) oder hattet Ihr Probleme (im schlimmsten Fall Datenverlust)? Siehe beispielsweise NTFS - openSUSE . Vielen Dank und viele Grüße olc

Hi Lord, warum soll das Zertifikat der Zwischenzertifizierungsstelle im Benutzerstore importiert werden? Gibt es dafür einen konkreten (unter Umständen applikationsspezifischen) Hintergrund? Da Benutzer auf die Root bzw. Intermediate Zertifikate im Computerstore zugreifen können (müssen), sollte es doch eigentlich kein Problem sein, das Zertifikat der Intermediate CA auch in den Computerstore zu importieren. Viele Grüße olc

Hi Arsimael, wo genau hast Du die Berechtigungen vergeben? Nur auf NFS Basis oder auch auf NTFS Basis? Ich bin im Moment nicht so vertraut mit den NFS Einstellungen - aber ich meine mich zu erinnern, daß auch hier wie bei normalen Windows Freigaben mit Rechten gearbeitet wird, die dann jedoch zusätzlich über die NTFS Rechte weitere Einschränkungen bringen können. Viele Grüße olc

Hi Pumpkin, ok, dann scheint es nicht an der IP / Subnetz Sitezuordnung zu liegen. Schau Dir einmal die folgenden Punkte an, die häufig Ursache für Zugriffsprobleme darstellen: Distributed File System: Frequently Asked Questions --> "What can cause clients to be referred to unexpected targets?" Sollte sich dabei nichts finden, prüfe einmal die Sitezuordnung des Clients in der Registry. Ist die Site, die Du in der Registry findest, die korrekte? HKLM\System\CurrentControlSet\Services\Netlogon\Parameters --> SiteName. Viele Grüße olc

Hi swizz, kein Problem - freut mich, wenn es Dir weitergeholfen hat. :) Die AD gibt wie angesprochen nur die Verweise auf die Namespaceserver, hält jedoch nicht die Namespace-Informationen / Metadaten selbst vor. Von daher am besten den Namespace auf mehrere Server verteilen. :) Viele Grüße olc

Hi, wie ist die IP-Konfiguration des Clients? Hat der Client, der sich auf den falschen Standort verbindet, die gleiche IP- / Subnetzkonfiguration wie die Clients, die sich korrekt verbinden? Da der Client die Verbindungsversuche über seine IP / sein Subnetz und die IP / das Subnetz des DFS-Servers "abgleicht", könntest Du hier prüfen, ob unter umständen eine falsche IP-Konfiguration vorliegt. Viele Grüße olc

Hi, lassen denn die Router am Standort 2 die entsprechenden (Broadcast) Pakete durch? Bekommen andere Clients IP-Adressen über DHCP? Falls nicht könntest Du Dir einmal die Routerkonfiguration oder DHCP Relay Agents anschauen. Viele Grüße olc

Hi, wie oben schon geschrieben, hast Du vielleicht Zertifikate ausgestellt, die die vorhandenen V1 Templates genutzt haben. Aber das ist nur eine Vermutung, da wir derzeit keine genaueren Angaben haben. Wenn Du die Zertifizierungsstelle neu installierst, dann wird zumindest standardmäßig ein neues CA-Zertifikat (für die Zertifizierungsstelle) erzeugt. Somit sind auch die Signaturen in den CRLs etc. andere. Weiterhin hat die CA bei einer Neuinstallation auch die ausgestellten bzw. zurückgerufenen Zertifikate etc. nicht mehr in der Datenbank. Das bedeutet, daß (solange das CA Zertifikat der alten CA noch im lokalen Store der Clients vorhanden ist und die CRL nicht abgelaufen) im Grunde noch etwas mit den ausgestellten Zertifikaten gearbeitet werden kann. Spätestens ab dem Zeitpunkt, ab dem die CRLs jedoch abgelaufen sind, wirst Du wahrscheinlich in Probleme laufen, da die Applikationen selbst bestimmen, was sie in einer solchen Situation tun. Eine große Anzahl an Anwendungen wird dann etwa den Zugriff verweigern bzw. die Zertifikate nicht mehr als gültig anerkennen. Die Empfehlung wäre also in einem solchen Fall eher, die Zertifikate mit der neuen CA noch einmal neu austellen zu lassen. Mittels Autoenrollment bei einer Enterprise CA ist das jedoch meist "schnell erledigt"... P.S.: Eine CA nützt nur dann wirklich etwas, wenn die Konfiguration etc. gut geplant ist. Es ist immer empfehlenswert, sich die Leitfäden von MS dazu anzuschauen, bevor man mit der Installation und Konfiguration loslegt, siehe etwa Best Practices for Implementing a Microsoft Windows Server 2003 Public Key Infrastructure Viele Grüße olc

Hi, hast Du die Windows Server 2003 CA als "Enterprise CA" oder als "Stand Alone CA" installiert? Sollte sie als "Stand Alone CA" installiert worden sein, kann dieses AD-Objekt (und weitere) nicht existieren, da nur "Enterprise CAs" AD-integriert sind. In diesem Fall kannst Du weiterhin auch nur die V1 Standard Templates nutzen, da "Stand Alone CAs" keine angepaßten V2 Templates unterstützen. Viele Grüße olc

Hi, hast Du denn schon einen Ansatz bzw. ein erstes Script? Bitte poste dieses doch einmal als "CODE" hier, so daß man ggf. Anpassungen vornehmen kann. Viele Grüße olc

Hi swizz, ja, das beobachtete Verhalten ist "normal". Das bedeutet, daß der Namespace nur auf dem Server vorhanden ist, auf dem er angelegt wurde (oder eben auf den Servern, wenn der Namespace manuell auf andere Server gehostet wurde). Siehe auch Windows Server How-To Guides: Teil 1 - Verteilung von Namespaces auf verschiedene Server - ServerHowTo.de . Es ist im Normalfall zu empfehlen, den Namespace daher auf mehr als einem Server zu hosten, da bei einem Ausfall des hostenden Servers ansonsten der Namespace nicht mehr erreichbar ist, nachdem der Cache-Timeout auf den Clients abgelaufen ist oder Clients sich (etwa nach einem Neustart) neu mit dem Namespace bzw. den darunter liegenden Zielen verbinden wollen. Viele Grüße olc

Hi Mario, Du könntest beispielsweise mittels "certreq.exe" oder sicherlich auch über das Webenrollment der CA ein Zertifikat für das Zyxel Gerät erzeugen und dann das Zertifikat vom Client exportieren, von dem aus Du es beantragt hast, um es danach auf dem Gerät zu importieren. Certreq ist recht umfangreich: Appendix 3: Certreq.exe Syntax Webenrollment ist "einfacher". In beiden Fällen mußt Du vorher ein entsprechendes Template konfigurieren oder ein vorhandenes verwenden. Nutzt Du eine Windows Server 2003 Standard Edition CA, bleiben nur die standardmäßig vorhandenen V1 Templates. Viele Grüße olc

Hi, als "Idee auf die Schnelle" ist mir Tante Google eingefallen... Dort habe ich nämlich ganz schnell als erstes Suchergebnis die folgende Seite gefunden Webregistrierung für Zertifikatsdienste unter Windows*2000 und Windows*Server*2003 - Konfiguration und Problembehandlung , auf der im Unterpunkt "Es wurden keine Zertifikatsvorlagen gefunden. Sie verfügen nicht über ausreichend Rechte, um ... anzufordern." einige Hinweise zur Fehlersuche gegeben sind. :wink2: Wenn Du nach dem Prüfen dieser Punkte noch immer den gleichen Fehler hast, beschreibe hier doch einmal ein wenig genauer Deine Umgebung, so daß man etwas dazu sagen kann. Viele Grüße olc

Hallo, was ist (neben der AD Authentifizierung) Dein Anforderungskatalog? Wie soll die Wiki denn "Aussehen", was ist Ziel, wer wird daran arbeiten, wie soll der Zugriff möglich sein, wie wird mit Änderungen umgegangen etc. pp.? Wiki-Systeme gibt es ja wie Sand am Meer - zuallererst steht also die Frage, wie Dein Wiki aussehen soll. Danach kann man anhand dieses Katalogs prüfen, welche der infrage kommenden Systeme AD-Auth. Module mitbringen. Viele Grüße olc

Hi, Entweder das Backup Programm bietet an "versteckter Stelle" entsprechende Optionen an oder es gibt ein Problem mit dieser Version. Vielleicht kannst Du ja einmal die Supportdatenbank von Symantec bemühen. Aus den von Dir genannten Gründen macht ein Rücksicherungstest nicht erst im Fehlerfall Sinn... Viele Grüße olc

Hi, bist Du auf dem System lokaler Administrator? Viele Grüße olc

Hi, jeder, der sich an einem DC anmelden kann, hat potentiell auch irgend eine Möglichkeit, Daten der AD zu verändern oder grundsätzliche Änderungen am System vorzunehmen. Das ist also grundsätzlich ein Sicherheitsrisiko. Von daher ist im Normalfall eher davon abzuraten, außer Domänen-Administratoren auch noch andere Benutzer auf einem DC arbeiten zu lassen. Was genau ist denn der Hintergrund für Deine Frage? Was soll erreicht werden? Unter Umständen gibt es ja noch andere Wege zum Ziel. So wie ich das aus Deinen Gruppennamen sehe, kannst Du einige Aufgaben ggf. über Delegierungen auf den Diensten selbst und der Remote-Verwaltung mittels MMC erreichen. Viele Grüße olc

Hallo ...was man in einer Produktionsumgebung im Normalfall nicht macht. ;) Was genau meinst Du mit "jetzt fehlen Daten des Laufwerks"? Eine Änderung des Staging Quotas ändert nichts an den replizierten Daten. Wozu möchtest Du das Staging Folder manuell zurücksichern? Dort liegen "nur" die Arbeitsdaten von DFS-R, die bei Bedarf wieder neu erzeugt werden. Vielleicht kannst Du noch einmal ein wenig genauer und ausführlicher beschreiben, was Ihr genau getan habt und was genau das Problem ist. Viele Grüße olc

Hi Benny, bestens - vielen Dank für Deine Rückmeldung. Viele Grüße olc

Hallo Benny, welche Ports sind denn zwischen den Standorten freigegeben? Hast Du einen Fehler beim Posten gemacht oder gibst Du tatsächlich "\\DOMAIN.SUBDOMAIN\files\public" ein? Im Normalfall sollte es im Prinzip von subdomain.domain.tld\files\public angegeben werden. Wenn Du ein "nslookup subdomain.domain.tld" eingibst, bekommst Du eine korrekte Antwort für die DNS Server? Viele Grüße olc