Alle Aktivitäten

Den richtigen DC finden sie ja schon. Kannst sogar einen "preferred" einstellen, falls der PDC hinter einem WAN-Link hängen sollte. Das Problem steckt in GPMC/DFSR. Und um das zu lösen, müssten sie das Anlegen und Importieren komplett nachbauen. Ich kann schon verstehen, daß man das nicht unbedingt will, wenn es doch "offizielle" APIs gibt. "Timing verändern" ist so ein zweischneidiges Schwert - wie lange willst denn warten, bis DFSR auf dem von Dir grad genutzten Referral das Verzeichnis erstellt hat?

Moin, Ja, schon, aber der Witz bei den Quest-Tools ist ja gerade, dass sie das leisten, was man von den Bordmitteln erwartet, aber nicht bekommt. Da wundert es mich dann immer wieder, dass sie selbst solche Lücken lassen. Zumal es für Quest, wenn ich es richtig verstanden habe, recht einfach sein müsste, das Problem zu umschiffen. Das Timing verändern oder mit ein paar Zeilen Code den richtigen DC ausfindig machen, dürfte ja so schwer nicht sein. Gruß, Nils

Quest behandelt das nicht selbst, warum auch - sie nutzen das GPMC-API, das für das Anlegen von GPH und GPT verantwortlich ist. Da müßte das gefixt werden...

Lag die Mailbox von dem User in ExO oder On-Premises? https://learn.microsoft.com/en-us/exchange/recipients/disconnected-mailboxes/disconnected-mailboxes?view=exchserver-2019 und je nach dem wie lange das her ist, kann die Mailbox weg sein Dann aus dem Backup wiederherstellen (und ja, auch ExO muss man ein Backup machen, MS garantiert nur den Service nicht die Daten…) Schönen Samstag 😎

Schau mal ob der User noch ne Exchange online Lizenz hat… wenn nicht zuweisen und warten bis das gelöschte Postfach wieder verbunden wird…. mikro

Hallo zusammen, beschäftige mich seit kurzem intensiv mit Exchange. Mir ist folgendes aufgefallen: Es handelt sich um einen Hybrid Konstrukt. Den User gibt es nur um AD (deaktiviert) und besitzt „vermutlich“ kein Postfach Onprem bzw. Kann es nicht finden. Wenn ich mir die Attribute anschaue finde ich auch komischerweise keine eindeutige E-Mail als SMTP. Onprem finde ich keinen User der im Postfach verbinden werden kann (also der User) in der Exchange Online Umgebung kann ich zumindest den User als gelöschter Benutzer sehen. Nun wie kann ich problemlos den User wiederherstellen? Der User sollte eigentlich davor eine Mailbox gehabt haben. Kann ja schlecht Enable Mailbox mir einer Email Adresse setzten? Weil ein neues Mailpostfach erstellt wird. Wie gehe ich da am besten um? Danke

Falls du eben das Logging aktiviert hast, könntest du jetzt evtl. was im SMTP Log sehen, wenn du das Log einmal auf die Disk schreibst: Restart-Service -Name MSExchangeTransport, MSExchangeFrontEndTransport

Bislang gehts halt "nur" mit MAPIoverHTTP und Outlook auf Windows. Outlook for iOS, Android, Mac ist noch nicht möglich und würde AFAIK auch EWS benötigen(?). Ebenfalls geht es noch nicht - wie @NorbertFe schreibt - für EAS. Mir würde EAS ja schon reichen. Den Rest braucht kein Mensch, außer evtl. hat die nervigen, hippen Kunden. Die Infos zu welche Protokolle auf welchen Devices mit welcher Software findet sich AFAIK auch auf mehreren Seiten verteilt, dass man sich das bloß zusammensuchen muss.

Es geht konkret um modern auch für active Sync. ;)

Hier wäre etwas für 2019. Kam wohl mit dem SU vom April, wenn ich das richtig interpretiere. Hotfixupdate für Exchange Server 2019 und 2016: 23. April 2024 (KB5037224) - Microsoft-Support How to configure Exchange Server on-premises to use Hybrid Modern Authentication - Microsoft 365 Enterprise | Microsoft Learn

Das sollte man aber mal ändern ;) und sauber konfigurieren. Aber wie siehts jetzt mit tls 1.2 aus?

Fqdn auch nix

Dann ergänzen wir um: Get-SendConnector | fl Name, Fqdn, TlsCertificateName, CertificateSubject ;)

Und was steht im ehlo String? Und das was da steht, steht das auch im Zertifikat?

sagt nix - also: TlsCertificateName : CertificateSubject :

Nichts hält länger als das Provisorium. Ein Jahr nach Ankündigung des Produkts soll’s immer noch dauern? ;)

Was sagt denn Get-SendConnector | fl Name, TlsCertificateName, CertificateSubject Ggfs. kannst du auch schonmal Get-SendConnector | Set-SendConnector -ProtocolLoggingLevel Verbose ausführen.

an welcher Stelle? im Exchange Admin ist nichts - da macht nur noch die Bedienung Probleme mit einigen Popups, die nicht öffnen. könnte aber auch sein, dass die Provider eigentlich schon länger kein Smarthost mehr erlauben - wobei es bis jetzt funktioniert hat.. der Server soll eh sterben - aber nicht grad jetzt :) hab zur Not aber ein Workaround in Petto auch das wäre zeitlich ein riesen-Zufall - hat bis Mi alles funktioniert, bis vor dem Neustart

Ach ich lass mich da überraschen. Und wenn man sieht, was für Ausnahmen wieder für die ecc Zertifikate gelten, so is das dann vermutlich auch wieder mit dem anderen Thema. Auf dem Papier erfüllt in der Praxis eher so: najaaaa

Der Server 2012 R2 inkl. Exchange sprechen auch definitiv TLS 1.2 und der SmartHost Anbieter hat nicht zufälligerweise alles kleiner TLS 1.2 abgedreht? Ich meine irgendwo eine Mail überflogen zu haben, dass Host Europe gerade Testläufe in diese Richtung macht.

War grob im Mai 2023 nicht die Rede von "Later this year". Aber auch das ist ja nicht unbedingt was Neues.

Eigentlich nur, wenn dort explizit ein bestimmtes tls Zertifikat gebunden ist. Schau mal nach.

Naja bis cu2 würd ich da mal nix erwarten. 😑

HI - sorry, doch noch nicht alles. Mails gehen über einen Smarthost raus - da scheint es noch irgendwo zu haken. Muss man zum Sendeconnector nochwas zuordnen? lg

Mich wundert es, dass nichts vom Thema Modern Auth erwähnt wird. In den Kommentaren wird ja auch auf vieles eingegangen, außer auf die Rückfragen in Richtung Modern Auth.. Hmmm....