NilsK

Moin, also, ganz wesentlich: Ein Trust löst die Aufgabe gar nicht. Durch einen Trust vertrauen die Domänen einander, mehr nicht. Die Objekte des einen AD werden dadurch nicht in das andere übertragen. Ein User aus Domäne A kann dann mit AD-Mechanismen User aus Domäne B finden, aber in Outlook stehen sie ihm nicht zur Verfügung. Was du eigentlich willst, ist eine Übertragung der Mailobjekte der einen Domäne als Mailkontakte in die andere. Dafür brauchst du einen separaten Mechanismus, der aber seinerseits keinen Trust benötigt. Gruß, Nils

Moin, warum meinst du die zu benötigen? Ich höre sowas bei Kunden oft, und nur selten besteht wirklich ein Grund für mehrere Instanzen. Gruß, Nils PS: ... wie mein Vorredner schon richtig sagt. Hatte ich nicht zuende gelesen. :D

Moin, wie immer gilt auch hier: Man plant vom Restore her, jedes Szenario ist separat zu betrachten, und ebenso ist jede Applikation separat zu betrachten. Was für eine Applikation passt, muss für die nächste noch lange nicht gelten. Exchange-Umgebungen baut man völlig anders als etwa einen Dateiserver. Und man baut Exchange heute auch völlig anders als vor ein paar Jahren. Die Redundanzen, die Exchange mitbringt, decken bereits viele Standardsituationen ab. Für das Recovery muss man also genau planen, welche Szenarien überhaupt relevant sind und welche Methoden sich dafür eignen. Es gibt Leute, die beraten sowas. :D Gruß, Nils PS. und wie immer, stimme ich Norbert zu. ;)

Moin, wenn du den Befehl manuell ausführst, machst du das ja sicher in einem Admin-CMD. Funktioniert es, wenn du dein Batch von diesem Admin-CMD-Fenster aus ausführst? (Würde mich wundern, wenn nicht.) Dann ist dein Fehler auf UAC zurückzuführen. In einem Task würde das nicht passieren, wenn du dort ein Adminkonto zur Ausführung angibst und anhakst, dass erhöhte Rechte verwendet werden sollen. Gruß, Nils

Moin, also, für mich sprichst du immer noch in Rätseln. Ich verstehe nicht, was du damit meinst. Mit "Exchange-Vorbereitung" meinst du die ersten Schritte der Installation? Das macht man aber doch nur einmal, oder? Deine Formulierung klingt, als würdet ihr da irgendwas ein- und ausschalten und schauen, was passiert. Macht ihr da am Ende mit VM-Snapshots rum oder sowas? Was meinst du mit "unbekannte Konten"? Solche, bei denen nur ein SID angezeigt wird statt des Namens? Was meinst du in dem Zusammenhang mit ? Gruß, Nils

Moin, also ... mag ja sein, dass das bei euch anders ist, aber derart hoch aufgelöste Datensicherungen (zwei Stunden ... 30 Minuten ... was kommt denn da noch?!) kenne ich nur von ERP-Systemen und sowas, aber nicht von Mailsystemen. Seid ihr wirklich sicher, dass das passt? (Und wie soll das mit einer aktiven Umlaufprotokollierung zusammengehen? Irgendwie fühle ich mich gerade etwas verlassen ...) Meistens, wenn Kunden sowas äußern, sind das "Bauchwerte", aber es gibt keine belastbaren Anforderungen dazu. Gruß, Nils

Moin, gibt es wirklich noch Leute, die vor einem Schema-Update die Replikation abschalten? Das ist nicht nur gestrig, es ist auch unsupported. Was genau meinst du mit Folgendem? Und was meinst du mit "den Stamm vorbereiten"? Auch dies verstehe ich nicht: Bitte mal genau beschreiben, sonst kommen wir hier nicht weiter. Gruß, Nils

Moin, ich würde in keinen USB-Stick höheres Vertrauen setzen als in einen (namhaften) Cloud-Provider. Gruß, Nils

Moin, an der Stelle ist ein IT-Dienstleister nicht der richtige Ansprechpartner. Es braucht juristische Beratung. Die IT ist dann wieder dran, wenn es um die Umsetzung geht. Gruß, Nils

Moin, kann man machen, ist aber nur "Security by obscurity" und verhindert nicht wirksam, dass die Daten jemand sieht, wenn er ein passendes Tool für den Zugriff hat. Nur um das betont zu haben. Handelt es sich um Privatnummern oder um Firmennummern? Falls ersteres, könnten zusätzliche juristische Fragen auftauchen, die ihr mit einem Anwalt klären solltet. Gruß, Nils

Moin, genau. Ich füge noch einen Hintergrund hinzu: Zwar ist es im Active Directory möglich, Berechtigungen auch auf einzelne Datenfelder zu legen. So könnte man durchaus erreichen, dass Benutzer die Mobilnummern im AD nicht sehen, Admins aber schon. Aber: Erstens ist das sehr aufwändig und fehlerträchtig, schon im AD. Und zweitens: Sobald Exchange im Spiel ist, ist das wirkungslos, denn leider hält Exchange sich seit zehn Jahren nicht mehr an die Berechtigungen im AD, sondern arbeitet daran vorbei. Man müsste es also innerhalb der Exchange-Logik nochmal einrichten - sofern das überhaupt geht. Und spätestens da sind Aufwand und Fehlerquellen so groß, dass es kaum sinnvoll ist. Man bewegt sich dann auch schnell außerhalb des offiziellen Supports. Gruß, Nils

Moin, cool, danke für den Tipp! Gruß, Nils

Moin, die DSGVO und ISO 27001 haben zunächst einmal wenig miteinander zu tun. Allgemein ist aber sehr zu empfehlen, das Thema mit Fachjuristen zu besprechen. Gruß, Nils

Moin, vielleicht ist die Zeit nicht synchron? Gruß, Nils

Moin, dein Verständnis ist nicht korrekt. Es werden keine Objekte transformiert, sondern Daten von einem in ein anderes Format gebracht. Insgesamt scheinen es mir drei Regeln zu sein, und jede nimmt ein Datum an (incoming) und gibt es in einem bestimmten Format aus (outgoing). Gruß, Nils

Moin, da wird sich sicher mal eine Gelegenheit ergeben. :) Gruß, Nils

Moin, das Adobe-Beispiel macht genau, was ich vermutet habe: Es sendet die Mailadresse einmal als Mailadresse und einmal als Name ID. Die Besonderheit an Name ID ist, dass es eine ganze Reihe von Subformaten gibt, von denen bisweilen nur eine ganz bestimmte funktioniert, und zwar dann meist eine, die ADFS von sich aus nicht sendet. Da muss man dann manchmal ziemlich rumfuhrwerken, damit es klappt. Gruß, Nils

Moin, Jesper Johannson und Steve Riley haben mal sowas gebaut für ihr Buch "Protect Your Windows Network". Die Seite scheint aber nicht mehr zu existieren. Gruß, Nils

Moin, ja, die schlechte Doku zu ADFS ist ein Problem. Spaß macht das nicht. Die Name ID ist auch so eine Sache für sich. Manchmal muss man da enorme Klimmzüge aufwenden, um die so zu bauen, dass beide Seiten sich verstehen. Das Beispiel, was du meinst, müsste man sich evtl. mal ansehen. Vielleicht lässt es sich wirklich durch eine einzige Regel abbilden. Vielleicht soll es aber auch die Mailadresse einmal als "E-Mailaddress" weitergeben und einmal als Name ID. Dann wären zwei Regeln schon okay. Gruß, Nils

Moin, ach ja ... da hast du natürlich Recht. :D https://en.wikipedia.org/wiki/Write-only_memory_(joke) Gruß, Nils

Moin, dafür brauchst du eine eigene Zertifikatsvorlage und musst den Prozess dann manuell durchführen. Der vordefinierte Prozess geht nur mit AD-Mitgliedern. [Windows-PKI: Computerzertifikat manuell anfordern | faq-o-matic.net] https://www.faq-o-matic.net/2017/09/13/windows-pki-computerzertifikat-manuell-anfordern/ Gruß, Nils

Moin, sorry, aber ... fünf Jahre alte Platten für ein RAID in einem neu einzurichtenden Backupserver? Da geht was ganz derb in die falsche Richtung. Dass man einen Backupserver aus Altmetall zusammenbauen könne, glauben Kunden nur so lange, bis sie das Backup mal brauchen. Gruß, Nils

Moin, je breiter ein RAID-Set, desto höher die Wahrscheinlichkeit, dass ein Ausfall Probleme bereitet. Bei zwölf Platten im RAID-5 wäre "eine Platte" Parity bei elf Datenplatten. Mit gebrauchten Platten wäre mir das Risiko zu hoch. Wie wichtig sind denn die Daten? So unwichtig, dass ein neues Storage teurer ist als der Verlust? Gruß, Nils

Moin, ein Notebook sollte ohnehin verschlüsselt sein. Ohne Verschlüsselung braucht man überhaupt keine aufwändigen Angriffe, sondern kommt in der Praxis sehr leicht in die Domäne. Gruß, Nils

Moin, wieso das denn nicht? Ansonsten wäre es in dem Szenario sicher sinnvoll, sich jemanden dazuzuholen, der sich mit der Technik und den Zusammenhängen auskennt. Gruß, Nils