NilsK

Moin, und daran denken, dass eine Replikation kein Backup ist. Was uns zu der wichtigsten Frage bringt: Zunächst wäre zu klären, welches Wiederherstellungs-Szenario denn erfüllt werden soll. Backup braucht schließlich kein Mensch, Restore ist die Kunst. Gruß, Nils

Moin, Windows Server Backup? (Oder gibt's das auch nicht mehr?) Gruß, Nils

Moin, Möglicherweise wird Evgenij behaupten, dass es Leute gibt, die das grenzenlose Überbuchen von CPUs für eine gute Idee halten. Falls er das tut, glaub ihm kein Wort. Gruß, Nils PS. Nein, das musst du nicht verstehen. Das ist ein Insider und komplett Off-Topic.

Moin @imebro, dein Forscherdrang in Ehren, aber die technischen Fragen, die du zuletzt gestellt hast, sind alle in diesem Thread schon beantwortet worden. Darüber hinaus tust du ja gerade das, was ich dir empfohlen habe, nämlich Know-how aufbauen. Das ist gut. Es ist aber nicht praktikabel, wenn du jetzt jedes Detail, das dir auffällt, hier nachfragst. Dazu ist ein Forum nicht geeignet. Du wirst da jetzt einfach ein wenig Zeit in die Grundlagen investieren müssen. Gruß, Nils

Moin, ich glaube nicht, dass das pauschal so ist. Da wäre jetzt wahrscheinlich noch zu klären, ob der SQL Server nur diese Webseite befeuert (so wie die Datenbank eines Web-CMS) oder ob es sich um eine datenbankgestützte Applikation handelt, die eben auch über das Web genutzt wird. Anderenfalls hätte Microsoft sich ja ein Vehikel geschaffen, um seine CALs komplett obsolet zu machen. Im übrigen wäre es nett gewesen, wenn @SPLA nicht nur ein unkommentiertes Zitat hier hingeworfen hätte. Gerade in Lizenzfragen ist sowas ja wenig hilfreich. Gruß, Nils EDIT: bezieht sich auf die Antwort von Dukel, die Antwort von SPLA kam erst, nachdem ich das geschrieben hatte.

Moin, und das heißt für die Frage des TO jetzt was? Dass der Webserver keine CALs braucht, ergibt sich ja schon daraus, dass er unter Ubuntu läuft. Gruß, Nils

Moin, gut, auch hier noch mal wiederholt: Wenn es denn wirklich so eine Berechtigungsstruktur sein, richtet man die auch nicht "mal eben" ein. Arbeite dich ein und nimm dir Zeit dafür. Bei eurem Konzept wird es vermutlich nicht funktionieren, alles zuzulassen und darunter einzuschränken. Das müsstet ihr andersrum tun. Eine ganz simple Skizze - ausdrücklich nicht zum Umsetzen 1:1 geeignet: nicht im "Root" (D:\) starten, sondern in einem Ordner (D:\Daten) Eine Datei-Admin-Gruppe definieren, die überall Vollzugriff bekommt (damit man nicht mit einem Administratorkonto arbeiten muss, sonst geht das mit dem Explorer nicht) Die Admin-Gruppe mit Vollzugriff berechtigen, nach unten vererben Weitere Zugriffsgruppen definieren, die überall rannkommen sollen. Diese berechtigen und vererben. Vordefinierte Berechtigungen entfernen, damit nur noch die eigenen drinstehen. Dazu muss man das erste Mal die Vererbung auf dem Startordner abschalten. Wenn es denn wirklich sein muss, dann erst jetzt die Vererbung auf einzelnen Ordnern abschalten und die vorhandenen Berechtigungen übernehmen. Nun auf den Ordnern die dedizierten Zugriffsgruppen berechtigen. Gruß, Nils

Moin, macht es nicht durch Schnellschüsse noch schlimmer. SharePoint ist kein DMS. Es war nie eins und wird auch keins werden. Es hat einzelne Funktionen, die man auch in DMS findet. Vor allem ist es erst mal eine Applikationsplattform. Und ein DMS führt man nicht "mal eben" ein. Wenn ihr schon kein Geld für einen Admin oder Beratung ausgeben wollt, müsst ihr über sowas gar nicht erst nachdenken. Wie schon gesagt: Wenn ihr der Meinung seid, dass euer Ablagekonzept euch hilft, dann probiert es aus. Aber verabschiedet euch von der Idee, dass ihr mit Technik eure organisatorischen Herausforderungen lösen könnt. Das funktioniert nicht, auch wenn ihr noch so viel Technik draufschmeißt. Ernsthaft: Ihr seid 15 Leute, vermutlich alle mit hohem Ausbildungsgrad. Löst eure Herausforderungen auf der organisatorischen Ebene und brecht euch nicht die Finger dabei, technische Hürden aufzubauen. Wäre ich Berater, würde ich ernsthaft noch mal die Frage stellen, ob ihr überhaupt gestaffelte Berechtigungen braucht. Gruß, Nils

Moin, Bezüglich SQL Server hatten wir so ein Konstrukt neulich bei der Distribution angefragt und dort die Auskunft bekommen, dass die Core-Lizenz auch externe Zugriffe abdeckt. Also nur der Connector für Windows "an sich", meiner Vermutung nach aber nur einmal. Gruß, Nils

Moin, du hattest oben erwogen, die Vererbung zu verändern. Das kann einer der Wege sein, das umzusetzen. Kann man machen, nur muss man dann halt wissen, dass die Vererbung nicht wirkt. Gerade bei der Datensicherung fallen manche dann auf die Nase. Beim Backup ist es vor allem wichtig, dass die Backupsoftware das Backup-Privileg nutzt und dass der zugehörige Dienst-User das zugehörige Privileg auch hat. Falls das böhmische Dörfer sind - siehe oben, externer Sachverstand. Gruß, Nils

Moin, jenseits aller akademischen und technischen Betrachtungen - am Ende ist wichtig, dass ihr mit der Struktur arbeiten könnt. Bei 15 Usern wird auch eine technisch nicht dem Lehrbuch entsprechende Konstellation machbar sein. Ob und wie du DL- oder G-Gruppen einsetzt und ob du mit verschachtelten Gruppen arbeitest, wird darüber hinaus bei eurer Konstellation mit der angestrebten statischen Struktur ziemlich egal sein. Aus Erfahrung zweifle ich, dass das mit der statischen Struktur in der Praxis funktionieren wird. Und ich bin ziemlich sicher, dass man bei so einer kleinen Anwenderschaft Fehler problemlos vor dem Ausbruch des Chaos korrigieren kann, ohne die Umgebung zu verrammeln. Aber probiert es aus, technisch machbar ist es, auf mehreren Wegen. Vor allem wichtig, gerade wenn ihr mit Berechtigungen arbeitet und die Vererbung manipuliert: Sorgt für eine Datensicherung, die so eingerichtet ist, dass sie auch alles sichert. (Ich verweise hier noch mal auf externen Sachverstand.) Gruß, Nils

Moin, nun ... was ihr euch zu den Berechtigungen ausgedacht habt, hat mich ja zu meiner Frage veranlasst, ob ihr euch das Leben nicht unnötig kompliziert macht. Wenn ich es richtig sehe, unterscheidet ihr für den ganzen Verzeichnisbaum nur zwei Zugriffsstufen: Die Chefin und die Leiterinnen sollen andere Rechte haben als alle anderen. Wobei mir völlig unklar ist, worin sich die Rechte unterscheiden - die eine Gruppe soll Ändern-Rechte haben, die andere solle Lesen und Schreiben dürfen, was in der Kombination effektiv dasselbe ist. Womöglich unterscheidet ihr, wer Ordner anlegen darf und wer nur Dateien - aber spätestens das halte ich für völlig unpraktikabel. Soll man jedes Mal, wenn es Bedarf für einen neuen Ordner gibt, die Chefin involvieren? Und was ist an Ordnern so schlimm, dass man es reglementieren muss? Ist es am Ende nicht einfacher, dann und wann mal Dateien an die richtige Stelle zu schieben als sich ein organisatorisch wie technisch komplexes und fehleranfälliges Konstrukt zu bauen? Wäre ich Chef, würde ich euch noch mal zum Denken zurückschicken. Man kriegt das zur Not hin, es per Vererbung so einzurichten. Aber das bekommt man in einem Forum nicht sinnvoll erklärt, weil es schon ziemlich komplex ist und man einiges über die Windows-Strukturen wissen muss. Wenn du es wirklich selbst machen willst, dann musst du dich da wohl einarbeiten, nimm dir dafür ein Spielsystem. Und bau es nicht mit dem Explorer, sondern mit einem spezialisierten Tool wie diesem hier: [SetACL Studio - Free & Intuitive Permission and ACL Management • Helge Klein] https://helgeklein.com/setacl-studio/ Gruß, Nils

Moin, wir können hier im Forum nicht dazu beitragen, eure Struktur aufzuräumen und geradezuziehen. Ich empfehle, dass ihr euch einen Dienstleister sucht. Auch bei einer 15-Mann-Firma ist es keine gute Idee, wenn jemand ohne Fachkenntnisse die IT so nebenbei mitmacht. Beides. Die Gruppentypen haben unterschiedliche Aufgaben. DL-Gruppen steuern die Berechtigungen. Eine Gruppe pro Berechtigung und Ordner. Beispiel: Ordner "Projekt", es sollen Lese- und Vollzugriffsrechte verwaltet werden. Also zwei DL-Gruppen: DL-Projekt-Lesen DL-Projekt-Vollzugriff Diese beiden Gruppen erhalten jeweils die Rechte, die ihrem Namen entsprechen. Danach muss man (prinzipiell) die Berechtigungen des Ordners nie wieder anfassen. G-Gruppen fassen die User logisch zusammen. Die G-Gruppe, die einen bestimmten Zugriff braucht, wird in die passende DL-Gruppe aufgenommen. Im Beispiel: Die Projektleiter sollen Vollzugriff haben, die Techniker sollen lesen. Gruppe "G-Projektleiter" wird Mitglied von DL-Projekt-Vollzugriff Gruppe "G-Techniker" wird Mitglied von DL-Projekt-Lesen Das gibt es so nicht. Das hat sich jemand ausgedacht. Edit: Ach, ich seh grad ... jaja, die Firma Migraven. Die haben sehr eigene Interpretationen der Materie. Und sie haben das Prinzip nicht verstanden. Es gibt einen Grund, warum man für die logische Gruppierung G-Gruppen verwendet und für Berechtigungen DL-Gruppen. Den Artikel würde ich ignorieren. Gruß, Nils

Moin, wie man die Gruppen anlegt, ist in dem oben verlinkten Artikel zu AGDLP dargestellt. Das Prinzip ist eigentlich einfach. Und wenn ihr meint, dass ihr das organisatorisch schon geklärt habt, dann sollte das damit auch leicht umsetzbar sein. Aus meiner Erfahrung ist sowas aber kein Selbstläufer, wie die Kollegen ja auch sagen. Stellt euch auf Aufwand in der Einführung ein und legt rechtzeitig fest, wie ihr mit konzeptionellen Änderungen umgehen wollt. Glaubt nicht, dass ihr mit der technischen Implementierung "fertig" seid, sowas ist ein echter Change, der begleitet gehört. Ich wünsche (ernsthaft) viel Erfolg. Gruß, Nils

Moin, das mit der Vorkasse finde ich nicht nett, aber plausibel. Immerhin ist die Mandantin mit gesperrtem Konto bei ihm angekommen. Gruß, Nils

Moin, Vor allem empfehle ich, es nicht unnötig kompliziert zu machen.. Dieses 7-Ordner-Prinzip etwa klingt für mich eher esoterisch als nützlich. Braucht ihr denn bei unter 15 Leuten wirklich so eine differenzierte Struktur mit Prinzipien und gestaffelten Berechtigungen? Ich würde mir eher ansehen, wie tatsächlich gearbeitet wird. Bei so einer kleinen Gruppe wird es sicher Ordnungskriterien geben, die sich quasi aufdrängen. Und falls nicht, könnte man mit so einer überschaubaren Gruppe sogar daran denken, die Ablage in einem gemeinsamen Workshop zu erzeugen. Gruß, Nils

Moin, deine Fragen kann man nicht beantworten, weil niemand hier eine Vorstellung hat, wie viele Daten da in welcher Zeit über die Leitung gehen könnten. Das wird man nur ausprobieren können. Aber wenn die vier Leute selten bis nie zeitgleich arbeiten, ist das aus Sicht der "Performance" ja auch eher positiv. Gruß, Nils

Moin, Nun, mit sehr spezifischen Tools kommt man da schon sehr weit, aber die kosten eben auch sehr spezifisch. Das dürfte für so eine Migration völlig unangemessen sein. Hier wären also noch mal die Anforderungen genau zu prüfen. Der Beschreibung nach scheint es ja noch eher eine spontane Idee zu sein, so vorzugehen. Gruß, Nils

Moin, für dieses Szenario ist ein RODC gar nicht gedacht. Bei so einem Angriff gibt es in aller Regel andere Möglichkeiten bzw. Einschränkungen. Und das wäre schon eine der Sachen, die man bei einem näheren Blick dann feststellt. Wahrscheinlich ist der Standort gar nicht so eine Insel, wie er mit einem RODC konzeptionell gemeint ist. Es wäre jetzt sehr oberflächlich, anhand der bisherigen Diskussion solch konkrete Empfehlungen auszusprechen. Aber wenn du gar nicht so richtig weißt, wozu du einen RODC brauchen könntest, dann ist das zumindest ein gewichtiges Argument, keinen zu haben. Gruß, Nils

Moin, weil es meist nicht zum Gesamtaufbau passt, wenn man es sich näher ansieht. Das würde ich jetzt aber nicht anhand deiner Umgebung in einem öffentlichen Forum diskutieren wollen, weil du damit zu viel preisgeben müsstest. Die Grundidee des RODC finde ich nachvollziehbar, aber sie passt eben in der echten Welt höchst selten, weil zu viel um den RODC drumrum ist, was seinen Einsatz unsinnig macht. Gruß, Nils PS. ... und ich will kein plattes Bashing betreiben, aber auf Artikeln von Thomas Joos würde ich keine Entscheidung aufbauen.

Moin, hm. Würde ich eher nicht so machen, kann aber vom Vorgehen her funktionieren, wenn man weiß, was man tut. Aber: Da meiner Erfahrung nach ein RODC "in echt" fast nie sinnvoll ist, würde ich das Konzept prüfen, ob ein RODC wirklich eine sinnvolle Lösung für das Problem (das ich ja nicht kenne) ist. Die Nummer wird in dem KB-Artikel nicht genannt, aber es klingt schon deutlich so, als wäre das dort beschriebene Update der Grund. Ich würde das mal durcharbeiten. Das meine ich nicht. Du schrobst: "Es kann schaden, bei dem Konto ein neues Kennwort zu setzen." Zwar ist das sicher auch nicht völlig falsch, aber ich vermute, dass du eigentlich das Gegenteil sagen wolltest. Daher meine Nachfrage. Gruß, Nils PS. hier noch das fehlende R: R.

Moin, hättest du Verwendung für ein "nicht"? Es bleibt aber die Frage, was der TO mit dem Setup bezweckt, das schon ... exotisch ist. Gruß, Nils

Moin, wozu das denn? Was wolltest du mit so einem Setup erreichen? Hast du auch eine Event-ID dazu? Gruß, Nils

Moin, Leider sehen das auch einige kommerzielle Zertifikats-Anbieter anders. Gruß, Nils

Moin, Da dieses Konstrukt mit Sicherheit keinen Support von SAP bekommt, wird dir niemand hier auf diese Fragen eine sinnvolle Antwort geben können. Es wäre gebastelt, kann funktionieren, kann scheitern. Ich halte Letzteres für wahrscheinlicher. Ob der Aufwand, den man in so einen technischen Umstieg investieren müsste, sich irgendwie lohnt, würde ich bezweifeln. Ich würde vorschlagen, in andere Richtungen zu überlegen. Gruß, Nils