Demented Clown

Ich setze die Freigabeberechtigungen grundsätzlich auf "Jeder" und konfiguriere nötige Einschränkungen auf NTFS Seite. Damit hast du ein überschaubares Konzept und bist trotzdem auf der sicheren Seite, was die Zugriffe angeht. Der Server muß dazu nicht unbedingt DC sein, aber ist doch Mitglied in einer Domäne, oder? Edit: Ah, eine Arbeitsgruppe. Hier bin ich raus.

Dann schuldest du mir jetzt nur noch die Antwort auf die Frage, wie denn die Berechtigungen deiner Freigaben aussehen. ;)

Mehr Info's bitte. Ist der Server ein DC? Wie sind die Berechtigungen der Freigaben? Ist eine HW-Firewall im Einsatz?

Wurde die HDD bereits auf Fehler geprüft? Evtl. Fragmentierung?

Ich denke mal was du da gehört hast war die "Tombstone-Lifetime". Lesenswert zum Thema ist das hier LDAP://Yusufs.Directory.Blog/ - Die Tombstone Lifetime Sollte dir Gewissheit verschaffen :) Edit: Deine Acronis-Vollbackups beinhalten auch den Systemstate, falls das noch unklar sein sollte.

Das würde so funktionieren, auch über einen längeren Zeitraum. Und Verfallsdatum? Nö. Wie kommst du darauf? Willst du den Server abschießen und dann in Urlaub fahren? ;)

Da es ja dein einziger DC ist, schließe ich mich hiermit der Meinung von RanCyyD an. Images sollten IMO ausreichen. (Andere Meinungen mit Begründungen sind natürlich ausdrücklich erwünscht!) Ob das ganze nun allerdings von MS supported wird oder nicht steht auf einem anderen Blatt. Ich konnte zwar auf die schnelle keine halbwegs aktuellen Quellen dazu finden, denke aber Nils weiß wovon er redet. Allerdings solltest du dir sowieso einen zweiten DC besorgen (und selbst wenn er nur irgendwo als VM oder auf "Billigblech" läuft, und damit sieht das Thema schon wieder ganz anders aus (Stickwort USN-Rollback) und die Image-Backups sind hinfällig.

Hi, ist der genannte Server dein einziger DC?

Hab das hier: Formatieren mit Fat16 statt Fat12 unter Windows? - Mikrocontroller.net ergoogelt. Sieht aufwendig aus, der TO dieses Threads hatte aber offensichtlich Erfolg damit.

In der Regel ja, aber was würdest du in diesem Fall tun? Die SID's von Servern in einer Domäne ändern? :confused: Ich halte es in diesem Fall für das kleinere Risiko es NICHT zu tun.

Mit weitergehenden praktischen Erfahrungswerten kann ich leider nicht dienen. Aber das Netz scheint ja nun schon ne Zeit lang so zu laufen und im Zweifelsfall würde ich an deiner Stelle "nichts reparieren das funktioniert." Also, falls keine Fehler auftreten würd ich es in diesem Fall mit "never change a running system" halten, auch wenn der Spruch schon so'n Bart hat.

:D Ich hatte mit mehr Anteilnahme gerechnet. Mir persönlich ist es den Aufwand durchaus wert, meine Klone mit sysprep zu behandeln. Ich hatte zwar noch nie den Fall, daß ich Probleme mit doppelten SID's gehabt hätte, aber das Risiko ist mir zu hoch. Vor allem ist das "Totschlag-Argument" für mich, daß ungesysprepte (Ich sollte weniger Kaffee trinken) Klone nicht von Microsoft supportet werden.

Hi, :D Das wird ne rege Diskussion. Als Einstieg solltest du das hier The Machine SID Duplication Myth - Mark's Blog - Site Home - TechNet Blogs sowie das hier faq-o-matic.net Eindeutige Computer-SIDs unwichtig? lesen.

Guten Morgen, @Nils: Erstmal oute ich mich hiermit als überzeugter Leser von faq-o-matic, dein Video der "Natural Shell" ist Kult in meiner Gegend. (Das sage ich nicht nur, weil ich Angst habe, mir deinen Zorn zuzuziehen :) ) Topic: Natürlich hat Nils Recht was meine Formulierung angeht, eine "Glaubensfrage" ist es nicht. Meiner Meinung nach ist gerade das Thema "SID" kein Thema, das man pauschal mit ja oder nein beantworten kann. Jeder verantwortungsvolle Admin sollte für sich selbst entscheiden, ob ihm die Zeitersparnis die möglichen Risiken (siehe Link v. Nils) wert sind. Ich persönlich nutze sysprep, würde aber niemanden verteufeln, wenn er's (grade in kleineren Umgebungen) nicht tut. Mein erster Post zum Thema war hektisch hingekritzelt und könnte so interpertiert werden daß man Mark's Meinung für Fakten halten MUSS, was ich so nicht ausdrücken wollte. Falls ich für Irritationen gesorgt haben sollte entschuldige ich mich hiermit. Demented Clown

Ganz ehrlich? Ich verstehe nicht ganz worauf du hinaus willst. Du installierst deinen Server, fügst ihn der (vorbereiteten) Domäne hinzu, stufst ihn mit dcpromo zum zusätzlichen DC hoch und gehst halt exakt so vor, wie Yusuf es in dem Link beschreibt. Falls du zusätzliche Fragen hast, dann gerne, aber bitte etwas spezifischer...

Ist wohl ne Glaubensfrage :D Lies dazu mal das hier: The Machine SID Duplication Myth - Mark's Blog - Site Home - TechNet Blogs Vielleicht beantwortet das deine Fragen.

Hi, Hilfe gibt's hier: LDAP://Yusufs.Directory.Blog/ - Den einzigen Domänencontroller austauschen Viel Spaß.

Gegenfrage: Warum willst du das tun?

Hi, als erstes würde ich mal einen Blick in die Konfig der RDP Sicherheit auf deinem Zielserver werfen. Evtl. verwenden deine ThinClients eine ältere RDP Version...

Ich habe hier ein How-To einer ähnlichen Situation gefunden: HOW TO: SBS2008 in eine Windows 2003 Domäne integrieren Hab aber mangels Erfahrung diesbezüglich keine Ahnung ob es so funktioniert. Vielleicht könnte ja einer der SBS Spezialisten was dazu sagen, würde mich auch interessieren.

Falls auch mal jemand das Problem haben sollte: Meine Rechner haben alle statische TCP/IP V4 Adressen, die WIN7 Kisten haben (zwecks Heimnetzgruppe) parallel dazu V6 aktiviert. Seitdem ich V6 auch auf den XP Kisten installiert und aktiviert habe ist kein Fehler mehr aufgetreten. Frohes Schaffen, Demented Clown

Dessen bin ich mir bewusst. Aber es muss doch trotzdem möglich sein, andere Betriebssysteme, wie z.B. XP, ein Share aus so einer Heimnetz-Gruppe lesen zu lassen. Laut der Anleitung waren meine Schritte korrekt. Aber wieso habe ich dann die oben geschilderten Probleme? Vielleicht noch jemand eine Idee? Vielen Dank.

*Zensiert*

Hi, ehrlich gesagt weiß ich nicht ob ich dein Problem richtig verstanden habe, wenn ja hilft dir vielleicht der Artikel von Nils hier: faq-o-matic.net Windows-Druckserver: Treiber fr 32- und 64-Bit-Clients weiter. Viele Grüße, Demented Clown

Hast du auch die Harddisk Boot Priority überprüft? Hatte grade den gleichen Fehler. Bei mir stand Harddisk als erstes in der Bootreihenfolge, allerdings stand in der Harddisk Boot Priority die USB HDD vor der Systemfestplatte.