cj_berlin

Schön war's, trotz allem. Das Publikum hat natürlich schmerzlich gefehlt. Die potentiellen Speaker, die ohne Publikum nicht wollten, haben auch gefehlt (ich nenne jetzt bewusst keine Namen). Die Q&As zwischen den Sessions waren viel zu dünn besucht. Da man aber die Wahl zwischen dem Q&A und der nächsten Session treffen musste, kann ich das verstehen. Nächstes Jahr kann nur besser werden - und wird es ganz bestimmt!

Naja, die Clients müssen doch irgendwann Mitglied in der neuen Domain werden? Spätestens in diesem Moment müssen sie diese robust inklusive aller SRV-Records auflösen können... War sie eigentlich noch nie, denn die Security Boundary ist die Forest- und nicht die Domain-Grenze. Wenn ihr sicherheitstechnisch trennen wollt, macht zwei Forests mit einer selektiven einseitigen Vertrauensstellung dazwischen, oder halt auch ohne Vertrauensstellung, je nachdem. Alles, was innerhalb eines Forests passiert, ist sicherheitstechnisch nicht getrennt.

Moin, wenn Du genug IP-Adressen für das alles hast, spricht nichts dagegen. Wenn Du DHCP verwendest, um Clients z.B. die DNS-Server mitzuteilen, musst Du sicherstellen, dass die Conditional Forwarder sauber funktionieren, damit der Domänenwechsel klappt. Darf man fragen, wofür Du in 2021 noch eine Struktur mit eine Root- und einer Child-Domain benötigst?

Moin, der zweite Befehl existiert ja nur für On-Prem AD. Der -Path müsste demnach heißen 'CN=Users,DC=gsr,DC=nuernberg,DC=de' (der Standard-Container Users ist KEINE OU!), Und wer dieser Server sein soll, wo es doch eher eine Subdomain ist, das kannst wohl nur DU beurteilen. Du solltest ferner den -UserPrincipalName setzen, wenn er so nach AzureAD synchronisiert werden soll. Das -Password musst Du als SecureString übergeben, nicht im Klartext.

Das "R" in "SMTP" steht für "Realtime". Es ist nie beabsichtigt worden, dass Mails sofort ankommen oder dass der Absender sofort benachrichtigt wird, dass sie nicht zugestellt werden konnten. Dafür gibt es ursprünglich Telex, dann Fax und SMS, und mittlerweile Instant Messaging. Und natürlich Telefon.

Der Administrator hätte dann keinen Zugriff mehr auf die Inhalte in diesen Datenbanken Hätte er bei einem frisch installierten System auch nicht.

Moin, wenn Postfachinhalte mit 3rd-Party-Tools migriert wurden, könnte das ein Überbleibsel davon sein. Definitiv so nicht vorgesehen. Ganz zu schweigen davon, dass man mit dem RID500-Administrator grundsätzlich nicht arbeiten sollte.

Moin, AutoVervollständigung muss jeder User selbst löschen. Du kannst sie administrativ nur komplett ausleeren, aber da wären die User vermutlich traurig. Wenn wirklich gelöschte User in der GAL (also im OWA oder Outlook im Online-Modus) auftauchen, musst Du klären und die GAL evtl. updaten. Was Du aber vermutlich siehst, ist das Offline-Adressbuch. Dieses kann der User jederzeit forcieren, ansonsten schaut Outlook alle 24h nach, ob sich das OAB auf dem Server geändert hat. Auch die OAB-Generierung kannst Du serverseitig explizit anstoßen.

Moin, meinst Du wirklich das Adressbuch (GAL), die AutoVervollständigung oder die persönlichen kontakte?

Moin, da die gängigen Produkte nicht "Laufwerke", sondern Dateien verschlüsseln, wird es wohl darauf ankommen, wieviele Versionen in SharePoint für diese konkrete Website eingestellt sind, und ob die Ransomware für diesen Fall vorgesehen hat, die Dateien so oft zu verändern, dass alle verfügbaren Revisionen durch verschlüsselte Kopien "aufgefressen" werden. Insofern kann SharePoint Online durchaus einen gewissen Schutz gegen etwas dümmere Ransomware bieten. Besser ist es jedoch, die Synchronisierung nicht zu verwenden und sich auf die Programme zu beschränken, die den "

Moin, wenn ich das noch richtig im Kopf habe, ist GroupID nur für eine Custom Group relevant, und da wird eine GUID erwartet. Source muss dann auf 0 stehen. Bei Source=2 ist die Domain praktisch die Gruppe. Wenn die Filialen als AD Sites abgebildet sind, könntest Du mit Source=1 arbeiten, das wäre wohl am einfachsten und würde auch funktionieren, wenn ein Rechner die Filiale wechselt.

Eigentlich nicht, sonst würde O365 ja nicht funktionieren - oder? Das ist der Unterschied zwischen CNAME und A auf die IP des Exchange... Ich meine so etwas:

Moin, wenn nur AD-Member und darauf nur Outlook-Clients zu versorgen sind, kannst Du den Autodiscover-SCP in den zweiten Forest schreiben lassen (Export-AutodiscoverConfig). Wenn Du DNS zwingend brauchst --> siehe Norberts Vorschlag oder alternativ einen Alias (CNAME-Record). Den Alias könntest Du theoretisch sogar in der öffentlichen Zone von BBB setzen und bräuchtest zumindest dafür kein Split-DNS.

Moin, ist der Remote Registry Service aktiviert und wird er tatsächlich ausgeführt? Ich habe in letzter Zeit Situationen gesehen, wo er zwar per GPP auf Automatic gestellt wurde, aber nach einem Reboot tatsächlich nicht lief. Per GPO hat es besser funktioniert, aber auch nicht 100%... Die zweite Ursache wäre die Firewall auf der Zielmaschine (und vielleicht auch auf der Quellmaschine, obwohl das Blocken ausgehender Verbindungen leider seltener ist).

Ganz sicher? Ich meine, seit es nicht mehr Backup ist, sondern Backup & Replication, geht das... Aber in so kleinen Umgebungen, wo die Free Edition ausreicht, sieht man so selten LTO-Laufwerke...