NilsK

Moin, und davor stellen sie die Exchange-Datenbank auf SQL um und entfernen die Public Folders. Gruß, Nils ... ach, und Terminal Server stellen sie auch ein.

Moin, ja, aber nur zur Selbstbeschwerde. Das nennt sich "Beichtwesen". Auch die Whistleblower-Meldestellen entsprechen noch nicht ganz den hiesigen Vorschriften. Gruß, Nils

Moin, kurz ist die Woche ja nur in den Landesteilen, die sich noch nicht vom Joch des Katholizismus befreit haben. Gruß, Ni"Neid? Niemals!"ls

Moin, ich frag mal so: Wenn das erst so spät aufgefallen ist, dass die Daten auch schon aus dem Backup rausgealtert sind, ist das doch ein Indiz dafür, dass die Öffentlichen Ordner in Wirklichkeit nicht mehr gebraucht werden. Wäre das nicht ein Grund, den anscheinend nur sporadischen Bedarf mit einer anderen Technik zu decken? Gruß, Nils

Moin, ja, das ist schon richtig, aber da ich mich erinnere, von welcher Umgebung wir hier konkret sprechen, halte ich den simplen Weg hier (wie so oft) für den besten. Gruß, Nils

Moin, da es in dem Use Case ja vermutlich nur um den Zugriff auf historische Daten geht ... bringe ich noch mal den Export ins Spiel. Das vermeidet Konfigurationen im Backend, an die sich später niemand erinnert. Gruß, Nils

Moin, Mailbox exportieren? Gruß, Nils

Moin, 1/3 mal 1/4 gibt 1/12. Also ist praktisch schon Weihnachten. Gruß, Nils

Moin, da man den Hypervisor ohne Zusatzkosten mitliefert, war der Versuch, aus dem Ökosystem Umsatz zu ziehen, eben das Management. Und wenn man das separat verkaufen will, darf die eingebaute Verwaltung nicht zu viele Wünsche erfüllen. Wenn das hätte aufgehen sollen, hätte man von Anfang an was Brauchbares bauen müssen. Wie so oft bei MS, hatte aber niemand den Auftrag, das zu tun. Die SC-Leute haben sich dem Thema vom oberen Enterprise-Rand her genähert und sich dabei völlig verrannt. Von der anderen Seite her, z.B. aus dem WAC, fehlte offenkundig die Freigabe, da was Richtiges zu machen, und nachdem MS da auch jahrelang mit der Plattform rumgeeiert war, konnten sie die auch nicht mehr kostenpflichtig machen. Gruß, Ni"nur meine 0,02 EUR"ls

Moin, ça y est. Gruß, Nils

Moin, öhem, sorry, das klang, als wollte ich dich bloßstellen. Wollte ich nicht, das war eher ein allgemeiner Punkt. Was du an Aufklärung des Kunden beschreibst, ist angemessen. Gruß, Nils

Moin, das ist ja ein häufiger Effekt, auch bei vielen anderen Themen. Am Ende ist es "hamwa schon imma so jemacht, hamwa noch nie so jemacht, könnte jajeder komm". Das ist quasi das Gegenstück dazu. Was heißt das denn in dem Fall? Ihr inspiziert, und wenn etwas drin ist, was nach personenbezogenen Daten aussieht, dann schaut ihr schnell weg? Eher nicht, oder? Gruß, Nils

Moin, ah, verstehe. Dann könnte SetACL tatsächlich einen Blick wert sein, das hat (meiner Erinnerung nach) auch gute Reporting-Funktionen. Vielleicht auch das Schwestertool SetACL Studio. https://helgeklein.com/setacl/ Gruß, Nils PS. @Nobbyaushb danke für den Hinweis.

Moin, dann ist es SetACL. Das macht aber im Kern was anderes, als ich aus Zahnis Frage rauslese. Gruß, Nils

Moin, was brauchst du genau? Einen Report? Oder etwas, wo du "live" durchklicken kannst? Oder noch was anderes? Ach, und: Was genau hat es mit der SID History auf sich? Besteht die in der Quelldomäne, und in der Zieldomäne soll es einheitlich neue Berechtigungen geben? Oder sollen die alten Berechtigungen per SID History in die neue Domäne übertragen werden? Sprich: Was soll das Tool oder der Report genau anzeigen? Gruß, Nils

Moin, eben, das ist maximal für Enterprise-Kunden interessant. Man hätte am anderen Ende arbeiten und die Alternative für mittelgroße Kunden sein können, die von Broadcom vor den Kopf gestoßen werden. Hat man aber nicht. Gruß, Nils

Moin, das Spiel haben sie ca. 2018 durch Lieblosigkeit verloren und setzen das Trauerspiel mit einem neuen halbgaren Versuch fort. Dabei liegt der Ball seit über zwei Jahren auf dem Elfmeterpunkt vor einem leeren Tor. Sie hätten nur treten müssen. Hyper-V ist die Technik, deren Kern Microsoft für Azure braucht. Auf dem sonstigen Markt wollen sie damit gar nicht mehr bestehen. Gruß, Nils

Moin, nslookup ist nicht das richtige Tool, um die clientseitige Namensauflösung zu testen. Da ist ping aussagekräftiger, wenn wir bei Bordmitteln bleiben. EDIT: ich illustriere meine These noch mal. Der allgemeine Teil findet sich in der Mitte des Artikels, der Rest beschreibt bemerkenswerte Folgen aus der Tatsache, dass nslookup nicht zu dem taugt, wozu man es oft einsetzt. [Wenn (und warum) nslookup unerwartete Ergebnisse zeigt | faq-o-matic.net] https://www.faq-o-matic.net/2014/02/12/wenn-und-warum-nslookup-unerwartete-ergebnisse-zeigt/ Gruß, Nils

Moin, Exchange Server APE (Abandoned Product Edition) Gruß, Nils

Moin, hui, ist noch Platz in der Chauvi-Kasse? Gruß, Nils

Moin, zusätzlich zu dem, was @mwiederkehr sagt: genau das ist der Use Case, der nur in der Theorie auf der Datenbankebene funktioniert. In der Praxis wird man die Applikation mit einbinden müssen, damit es robust wird. Simpel gesagt, die Applikation muss davon wissen, dass repliziert wird. Das geht bei so simplen Dingen los wie Datensatz-Kennungen, die pro Replikat eindeutig sein müssen, aber ggf. auch eine Sortierung/Auswahl/was auch immer über den ganzen Bestand zulassen. Weiter geht es bei der Frage, was mit Löschungen und nachträglichen Änderugen passiert. Lustiger wird es dann bei der Frage, was passiert, wenn an Standort A die Daten bearbeitet werden, die von Standort B kommen - und was das für abgeleitete Funktionen bedeutet. Und, noch wichtiger: die Applikation sollte Mechanismen vorsehen, um Fehler zu korrigieren oder auszugleichen. Wenn ihr ohnehin gerade Developer da dran habt, dann sprecht mit denen darüber. Gruß, Nils

Moin, um es jetzt noch mal sehr deutlich zu sagen: Die Art, wie ihr das deinen Aussagen nach gebaut habt, ist weit jenseits dessen, wie man sowas macht. Ihr habt eine hochgradig angreifbare Umgebung in Betrieb, die mindestens sämtliche personenbezogenen Daten einem sehr hohen Risiko aussetzt (Ausspähung und Missbrauch). Da ihr eine Schule seid, handelt es sich dabei sehr wahrscheinlich um hochsensible Daten. Aus Sicht der IT-Sicherheit muss dieser Zugang sofort abgeschaltet werden und darf so nicht wieder in Betrieb gehen. Gruß, Nils

Moin, wie wollt ihr das bauen? Soll es mit der SQL-Server-Replikation laufen, oder gibt es eine Applikation, die den Abgleich steuert? SQL-Replikation war ein großes Thema in den Neunzigern, und auf ziemlich genau dem Stand ist die Technik auch. Heute will man sowas nicht mehr bauen, weil es in der Breite nicht ausreichend zuverlässig funktioniert, wenn es keine Applikationsschicht gibt, die sich darum kümmert. Gruß, Nils

Moin, Das führt irgendwie zu den Fragen: wer hat denn da überhaupt was beauftragt und was würde wie geprüft? Gruß, Nils

Moin, Ein sehr schönes Beispiel, warum ich das Konzept "Pentest" kritisch sehe. Erstaunlich viele "Pentester" werfen dem Kunden Reports mit solchen Schlagworten hin, und das war es dann. Keine Erklärung, was das heißt, keine Erklärung, was da genau geprüft wurde, keine Erklärung, wie man das behebt. Was soll sowas? Gruß, Nils