NorbertFe

Kommt darauf an. Dir fehlen dann ggf. eben die Verteilergruppen, die du nutzen willst. Das muss aber nicht zwingend nachteilig sein. Definitiv NEIN! Was willst du denn mit deinen ganzen administrativen Konten und Service Konten in der Cloud? Man synct das, was notwendig ist und da auch nur die Infos die notwendig sind. Bye Norbert

Mal wie in deiner Anleitung per GUI versucht?

Falls "dort" deine Groupware meint, dann dürfte es sich um das ROOOOOOOT Zertifikat handeln. ;) Ansonsten müßtest du mal genauer werden und ggf. einen Screenshot schicken.

Nein es wird gesynct, was man konfiguriert. Man kann bspw. Auf ou Filtern oder diverse sonstige filterkriterien definieren. Das kann man einfach oder beliebig komplex machen. Für die Politikerin bietet der connector afair die Option auf groupmembership zu filtern. Das ist aber nicht für Dauer gedacht sondern für die Pilotierung.

Nein. Wie schon gesagt, dein Client (groupware System) muss halt die Verbindung über Port 636 herstellen und dem angebotenen Zertifikat vertrauen (= Root Zertifikat besitzen), oder dem angebotenen Zertifikat nicht vertrauen, das aber dann ignorieren.

Siehe nils‘ Antwort. Du installierst dir ja auch nicht jedes Webserverzertifikat in deinem Browser.

Welches Problem hast du jetzt eigentlich? ;) geht irgendwas nicht?

Das is doch logisch, denn das Postfach steht in der alten dB weiterhin als gelöschtes Postfach. Wenn du die bereinigst, dann sind sie weg. Wichtig ist nur, was bei get-Mailbox für eine Mailbox Datenbank angezeigt wird.

Normalerweise wird doch inzwischen alles gespeichert und sogar wieder nach einem Reboot geöffnet, oder?

Und wer sollte NTFS technisch deiner Meinung nach "System" sein? ;) Wir lassen das ins AD schreiben. Ohne Verbindung zum AD gibts kein Bitlocker.

Häh? Dein Groupwaresystem spricht also LDAPs mit den DCs. Also müssen deine DCs ein Zertifikat dafür anbieten (bspw. das erwähnte Kerberos-Auth Zert). Da mußt du auch nichts im externen System einbinden, sondern maximal entscheiden, ob du das Root-Zert an das externe System gibts, oder ob du Zertifikatsfehler ggf. ignorieren kannst/darfst/willst. Deine Formulierungen lassen ein wenig darauf schließen, dass dir das Prinzip nicht ganz geläufig ist. Falls mich das täuschen sollte, dann bitte nicht übel nehmen. :) Bye Norbert

eher nicht. ;)

Und alles nur, weil die Marketingabteilung meint sie wisse was sie tut. 8)

Manchmal gibts eben TECHNISCHE Notwendigkeiten. Ob den Entscheidern das nun gefällt oder nicht. Und MS stellt sich halt hin und sagt, sinnvoll und _supported_ ist es, einen on prem Exchange zu betreiben, bis sie eine TECHNISCHE Lösung für ihr Problem gefunden und umgesetzt haben. Mir mußt du sowas nicht erzählen. Es gibt für alles auch Lösungen. Man stolpert halt oft genug über Probleme, für die es erst später Lösungen gibt oder eben nicht. Edit: Bei Direct Send und SPF achtet man dann hoffentlich auch drauf, dass nur der Drucker per SMTP raus darf. ;)

Laut diverser Cloudüberzeugter (ich nenns mal Marketinggeblendeter Manager) gibt es ja keine local devices mehr. ;) Alles nur noch in der cloud.

Dann sei froh. ;) Zur Dokumentation: https://docs.microsoft.com/de-de/exchange/decommission-on-premises-exchange#can-third-party-management-tools-be-used Can third-party management tools be used? The question of whether a third-party management tool or ADSIEDIT can be used is often asked. The answer is you can use them, but they are not supported.

Kann ja niemand was dafür, wenn dir jemand was falsches erzählt. Es sei denn, es wurde inzwischen geändert. https://docs.microsoft.com/de-de/exchange/decommission-on-premises-exchange https://docs.microsoft.com/de-de/exchange/decommission-on-premises-exchange#why-you-may-not-want-to-decommission-exchange-servers-from-on-premises Customers with a hybrid configuration often find after a period of time that all of their mailboxes have been moved to Exchange Online. At this point, they may decide to remove the Exchange servers from on-premises. However, they discover that they can no longer manage their cloud mailboxes. When directory synchronization is enabled for a tenant and a user is synchronized from on-premises, most of the attributes cannot be managed from Exchange Online and must be managed from on-premises. https://www.msxfaq.de/cloud/identity/adsync_exchange.htm https://practical365.com/exchange-server/how-to-remove-the-last-exchange-server-dilemma/ Dass es auch anders _geht_, sagt nichts über MS Supportstatement. ;) Bye Norbert

Die kann man Matchen. Aber interessanter dürfte die Info sein, dass du dann per supportstatement von ms einen exchange on prem benötigst, der die Exchange Attribute/Schnittstelle bereitstellt, damit die dann zu o365 gesynct werden. ;)

Wahrscheinlich nicht. ;) und wie gesagt, wer keine Rechte braucht, sollte sie auch nicht bekommen. Verstecken hilft da nicht viel.

Verweigern geht nicht. Er darf ihn halt nicht allen erlauben. ;)

Hm warte mal bisschen ab. :) Merkst du schon. Dürfte sich nach einer Weile eigentlich auch in den Eventlogs der clients zeigen. Das ist keine Sache, die die Marketingabteilung zu entscheiden hat ;)

Das merkst du dann schon, was alles nicht mehr geht. :/ in einem ad setzt man den dc/DNS und nicht Google, den Router oder sowas.

Oh die Edit hab ich überlesen, hatte aus der Erinnerung geantwortet ;)

hilft vielleicht: https://techcommunity.microsoft.com/t5/exchange-team-blog/customizable-recipient-limits-in-office-365/ba-p/1183228

Notfalls kann man ja mittels netsh nen Portproxy konfigurieren. ;) Aber das is genauso ungünstig, weil sich dann niemand mehr dran erinnert.