NorbertFe

Schonmal gesehen, wieviel ein Standard Nutzer im AD "keinerlei" Rechte hat? ;) Ich würds jedenfalls nicht tun. Ich würde keinem externen einen Account in meinem internen System geben (und schon gar nicht, in dieser Anzahl).

Diesen Kollegen frage ich immer, ob ihre Mailadresse auch so geschrieben werden muss. ;)

Wer macht denn sowas? :)

Üblichweise Domainvalidiert, denn mal vom Preis abgesehen, kennst du irgendeinen User der den Unterschied sehen würde? ;) Wenn man also nicht aus irgendeinem Grund genötigt wird Org-Validierte Zertifikate nutzen zu müssen -> Domain Validiert.

Wollte ich grad sagen, Owncloud kann SAML Authentifizierung und da würde ich eher an ein zweites ggf. sogar Cloud IDP gehen, in dem die Konten der Kunden hinterlegt sind. Du willst doch nicht potentizell allen externen Partner Zugriffsrechte über einen AD Account geben. Sowas will man wirklich nicht.

Schön, dass die Lösung so gut markiert wurde. ;)

In der Default Domain Controllers Policy steht da per Default die Gruppe "Administratoren" drin.

Stimmt, war ich wohl irgendwie in Gedanken auf dem falschen Dampfer (unterstützt von der obigen Fehlermeldung). Die ich übrigens auch schon gesehen habe, wenn man keine Subnet Definition im AD konfiguriert hatte.

Ich hab das mal für dich korrigiert. Also egal was du meinst da zu tun, das MUSST du tun.

Hat er ja. Der obere Teil ist die Fehlermeldung aus dem exchange Setup.

Und den Forest- und Domain Functional Level solltest du auch anheben. Dann sind einige Fehler schon mal weg. Hmm, warum heißen die Dinger nur Cumulative Update? ;)

Ja mit einem abgelaufenen Zertifikat kann man ein Paket nicht mehr bearbeiten. ;) Aber Hauptsache es geht jetzt wieder alles.

Na wenn du das alte Zertifikat entfernt hast auf den Clients wär das nicht verwunderlich. ;)

Die alte Version hatte vermutlich kein timestamping und somit ist das Paket eben ungültig. Wenn du jetzt nen timestamp drin hast, sollte das zukünftig nicht mehr passieren.

Neu signieren kannst du doch mit wpp erledigen. Warum der Aufwand?

War ziemlich lustig, wobei die ersten 2 folgen nicht gehalten wurden. Ich hab aber auf jeden Fall gut gelacht. auch „the gentlemen“ fand ich ziemlich unterhaltsam.

Gestern Teil 8 geschaut und nu? ;) sc*** cliffhanger. ;)

War auch nur ne Vermutung, dass man manchmal gar nicht so d...f denken kann. ;)

Nutzt ihr tls für rdp? Ich meine mich zu erinnern, dass wir mal so ein Problem hatten, nachdem das Zertifizierungsstellenzertifikat erneuert wurde und die AIA stelleninformationen nicht mehr zum Zertifikat passten, weil der Name hart in den Zertifikaten drin stand, anstatt variablen zu verwenden.

Nö, das geht nur im pilotbetrieb. Ist also für den Normalbereich nicht empfohlen. hinsichtlich centralized mailflow sollte man aber auch sagen, dass das deutlich komplexer werden kann und man ggf. noch einiges an Bedingungen umsetzen sollte.

Nö, damit wird RPC over https bezeichnet und das bekam dann irgendwann den Namen Outlook Anywhere (weil irgendwie alles Outlook heißen musste). Andererseits schreibst du ja, dass der Online Modus von extern funktioniert. Insofern kanns daran also nicht liegen. Hätte spontan erstmal keine Idee. Bye Norbert

Reden wir hier wirklich über Outlook Anywhere (/rpc) oder über Mapi/Http (/mapi)? Und ist das jeweilis im Kemp auch verfügbar?

Die internen nicht? Wie regelst du das? Ist SSL Bridging konfiguriert und Extended Protection aktiv? Hat es schon mal funktioniert? Seit wann nicht mehr?

Ja, das Archiv sieht man dann auch. Voraussetzung ist ein entsprechendes Outlook https://support.microsoft.com/en-us/office/outlook-license-requirements-for-exchange-features-46b6b7c5-c3ca-43e5-8424-1e2807917c99