NilsK

Moin, mangels eigenem Bedarf habe ich leider keine Lösung dafür. Aber vielleicht wäre ein zentralisiertes Log-Management eine bessere Lösung für euch? Das muss nicht automatisch riesige Summen kosten, ich habe sowas mal mit freien Tools für einen Kunden gebaut. Kommt halt auf die Anforderungen an. Gruß, Nils

Moin, generell schon, nur ist ein RODC eben aus gutem Grund eingeschränkt. Das ist ja das Prinzip eines RODC. Und deshalb fragte Evgenij, ob ihr denn wirklich einen solchen braucht. Dass ein RODC per se für mehr Sicherheit sorge, ist ein Missverständnis. Das tut er nur in einem sehr engen Feld von Anwendungsfällen (also genau genommen nur in einem). Was genau meinst du denn eigentlich mit: ? Gruß, Nils

Moin, direkt kann ich deine Frage nicht beantworten, aber: die Mitgliedschaft in der Gruppe "Event Log Readers" reicht nicht aus? Gruß, Nils

Moin, Interessant. Gruß, Nils

Moin, na, das liest man aber auch nur noch selten. Gruß, Nils

Moin, Beides lässt sich verbinden. Richte allen Usern Mailboxen in Exchange ein. Stelle dann das Mail-Routing um und verbinde die User. So ist der Empfang durchgehend möglich. Dann exportierte die alten Mailboxen und importiere sie in Exchange. Wahrscheinlich wird das sehr schnell gehen. Und wenn nicht, informierst du eben die User, die erst etwas später an der Reihe sind, dass es einen Tag länger braucht, bis sie ihre historischen Inhalte sehen. Gruß, Nils

Moin, Die Anzahl der Anwender und deren geografische Verteilung spricht für mich ebenfalls nicht gegen, sondern für eine Remote-Lösung. Genau wie Evgenij kenne ich Beispiele, in denen auch CAD über eine Citrix-Verbindung gut funktioniert hat - die richtige Ausstattung vorausgesetzt. Alles, was mit Replikation oder Datenbanken "im Internet" zu tun hat, will man nicht, weil es einem schneller auf die Füße fällt, als man "WTF?!" sagen kann. Gruß, Nils PS. ja, ein reiner "Finde-ich-auch"-Post, schien mir hier aber angebracht.

Moin, First things first - ich würde "etwas aus den Lot" erst mal bei den naheliegenden Dingen suchen. Updates, die nicht abgeschlossen sind. Virenscanner mit falscher Konfiguration. Kaputte Treiber. Software, die sich nicht benimmt. In der beschrieben Situation wird sich sicher im Event Log und im Process Monitor was finden. Es geht mir ja nicht darum, deine Erfahrung in Zweifel zu ziehen oder dich bloßzustellen - aber in kleinen und mittleren Umgebungen sind es typischerweise nun mal sehr "irdische" Probleme, mit denen man zu tun hat. Der Verdacht, dass "das AD" zu viel Last verursache, lässt sich so gut wie nie erhärten. Gruß, Nils

Moin, Ja, ich wusste auch, dass Martin sich nicht zurückhalten kann. Und dass wir ihn (bzw. alle anderen Lesenden dieses Threads) dann darauf hinweisen müssen, dass seine AD-Umgebung mit weitem Abstand ein Ausreißer ist. Martin weiß so gut wie wir, dass jemand, dessen Umgebung so groß ist, die hier diskutierten Fragen gar nicht stellen würde, weil er über Personal und Prozesse verfügt, die das unnötig machen. Anderen hier ist das möglicherweise nicht bewusst, daher weisen wir gern erneut darauf hin. Und natürlich weiß Martin auch, dass ein DC mit 16 GB auch in so einer großen Umgebung nicht derart langsam sein würde wie beschrieben, sodass der Kern meiner Aussage eben doch zutrifft. Auch hier sei das aber für alle anderen noch mal erwähnt. Gruß, Nils

Moin, Ein DC braucht weder viel RAM noch viel CPU. Wenn das also was lahm ist, dann ist das ein deutliches Zeichen, dass irgendwas aus dem Lot ist. Gruß, Nils

Moin, Evtl. falsche Einträge im DNS-Cache auf dem Server oder im Resolver-Cache auf dem Client. Außerdem machen, wenn ich es richtig verstanden habe, mache Browser die DNS-Auflösung selbst, da könnte es also auch falsche Daten im Cache geben. Gruß, Nils

Moin, dann würde ich darüber nachdenken, ihn abzuschaffen und durch Cloud-Dienste zu ersetzen. Gruß, Nils

Moin, man definiere "Mittelstand" ... aber gerade da stellt man oft fest, dass die Aufregung wegen der VMware-Lizenzen nicht gerechtfertigt ist. Wir betreuen eher kleine VMware-Umgebungen, da gibt es nicht nur keinen Exodus, sondern auch keine ernsthafte Aufregung. Und so mancher Enterprise-Plus-Kunde stellt jetzt fest, dass er die teuren Funktionen in Wirklichkeit noch nie gebraucht hat. Insofern sind wir als Dienstleister da ziemlich entspannt, hätten aber auch gleich mehrere Alternativen, wenn sie nötig wären. Was Cloud-Projekte angeht - auch da definiere man "Mittelstand". Was eher vorbei ist, ist blindes "Lift-and-Shift", was in Wirklichkeit darauf hinauslief, VMs übertrieben teuer bei Azure laufen zu lassen. Migrationen nach SaaS gibt es vorrangig da, wo es bewährte und einfache Use Cases gibt. Da berät dann aber auch eher der SaaS-Anbieter als der Infrastruktur- oder Cloud-Dienstleister. Services neu entwickeln, das findet schon seit Jahren viel eher in der Cloud statt als auf eigener Hardware, aber das ist dann auch selten ein Mittelstandsthema. Gruß, Nils

Moin, prima, danke für das Feedback. Gruß, Nils

Moin, das war das, was ich mit meinem Vorschlag meinte, dem du widersprochen hast. Und wer bin ich, dass ich dann beharre ... Gruß, Nils

Moin, weil das deine Formulierung am Anfang war: Du bist dann mehrfach gefragt worden, was denn eigentlich das zu lösende Problem sei. Dass die Mailbox aufgrund der Duplikate für den User nicht gut nutzbar ist, hast du erst viel später gesagt. Also haben wir zunächst vermutet, dass du das Größenproblem zu lösen versuchst. Daher wäre es nett, wenn du einfach mal ein bisschen weniger robust auftrittst. Wir wollten dir nämlich tatsächlich helfen. Gruß, Nils

Moin, Wenn man denn tatsächlich die Umgebungsvariable bräuchte, wäre das ja trotzdem lösbar. So exotisch wird der Wert ja nicht sein, dass man ihn nicht mit etwas Skriptlogik rekonstruieren könnte. Gruß, Nils

Moin, und: Gruß, Nils

Moin, und was ist das Problem, das du zu lösen versuchst? Wie die anderen schon sagen, sind große Mailboxen schon lange nicht mehr per se ein Problem. Gruß, Nils

Moin, dann nimm nur die GPO-Variante und mach den Rest halt selbst über ein Skript: Ordner anlegen, Berechtigung setzen usw. Die Umgebungsvariable könnte per GPP oder per Logonskript gesetzt werden. Mir wäre das viel zu viel Aufwand und Fehlerquelle für eine Kosmetik, die ein normaler User ohnehin nicht wahrnimmt, aber das muss ich ja nicht entscheiden. Gruß, Nils

Moin, Ja, die Anforderung als solche ist nachvollziehbar und auch nicht exotisch. Die Umsetzung ist aber, wie wir ja schon andeuteten, falsch. Das sollte man korrigieren. Wird auch nicht wild sein, aber man sollte es jetzt schon koordiniert tun. Gruß, Nils

Moin, was Jan sagt. Aber schon mal vorab als Einschätzung: So, wie ihr das gemacht habt, geht das nicht. Gruß, Nils

Moin, das bewirkt zweierlei: Fragt man den Computer nach seinem Hostnamen, dann gibt er sich als Teil der Domäne aus, die durch das Präfix angegeben wird. Und versucht der Computer selbst eine DNS-Namensauflösung, dann fragt er zuerst nach der Präfix-Domäne. Was ist denn der Grund für deine Frage? Gruß, Nils

Moin, Aber du brauchst doch kein Okta, um für 50-100 User OwnCloud bereitzustellen. Gruß, Nils

Moin, du hast dir angesehen, was allein die External Connector License kostet? Ansonsten das, was Norbert sagt. Gruß, Nils