Gerber

Hey NorbertFe, danke dir. Dann werde ich das vorhandene nutzen und über : Set-AuthConfig -NewCertificateThumbprint <ThumbprintFromStep1> -NewCertificateEffectiveDate (Get-Date) Set-AuthConfig -PublishCertificate Set-AuthConfig -ClearPreviousCertificate einfügen, korrekt? Danach noch die Pools wiederverwenden und es sollte passen. Grüße Phil

Hi zusammen, eine kurze Frage in die Runde, zwecks den Erfahrungen des KB5004779 Sicherheitspatch von Juli und dem "Microsoft Exchange Server Auth Certificate". Microsoft beschreibt ja den Issues unter Punkt 5, dass es sporadisch zu Fehlern in OWA und ECP nach der Installation vom Sicherheitspatch kommen kann. Jetzt habe ich natürlich schon einige Server gepatcht und habe ehrlich gesagt nie den Befehl: (Get-AuthConfig).CurrentCertificateThumbprint | Get-ExchangeCertificate | Format-List zuvor ausgeführt und nachgesehen, was zurückgegeben wird. (Schande über mein Haupt). Hat jemand Erkenntnisse was genau passiert, wenn z.B. das Zertifikat nicht abgelaufen ist, aber der Befehl einen Fehler zurück bringt? Hier wird mir ein anderer Fingerabdruck als vom "Microsoft Exchange Server Auth Certificate" ausgegeben. Sollte hier im voraus ein neues Zertifikat erstellt werden und dann erst das Sicherheitsupdate eingespielt werden? Wie sind hier eure Erfahrungen? Danke euch Grüße Phil

Hi Kipferl, Puuuh, klingt nicht so geil 😅🙄. Wie hast du die Kalender freigegeben? Zugriff für jeder oder die Seks als Name einzeln berechtigt? Falls jeder, kannst du einmal versuchen sek1 und sek2 einzeln zu berechtigen. Danach sollte eine Email ankommen, über welche die Seks direkt den Kalender mappen können. Solch ein Problem hatte ich einmal mit '' jeder aus der Organisation ''. Cache Mode hast du sicher schon kontrolliert? Grüße Phil

Hi, du hast also 2 Welten erschaffen? Einmal die Benutzer in der Cloud und einmal die Benutzer im lokalen AD? Für alle Benutzer, welche vom lokalen AD nach M365 synchronisiert wurden, müssen die Einstellungen im lokalen AD konfiguriert werden. Das lokale AD ist führend und aus diesem Grund die Einstellungen im lokalen AD. Für Benutzer welche Cloud Only sind, also nicht im Sync, können die Einstellungen in Azure AD, bzw Exchange Online oder was auch immer vorgenommen werden. Wichtig, die Benutzer Cloud Only sind dem lokalen AD nicht bekannt und in einer Hybrid Konstellation kann es aus diesem Grund zu Fehler kommen. Ich würde an deiner Stelle alles über das lokale AD oder über Azure AD steuern und nicht zwei Welten mixen. Grüße Phil

Ok. Wie greifen die Remote User auf das Netzwerk, bzw. den Exchange Server zu? Outlook Annywhere oder wird eine VPN Verbindung aufgebaut?

Eeeehm, Was hast du denn jetzt genau bei dir? Einen Exchange Inhouse oder Exchange Online? Wie ich lese, besteht kein Hybrid zwischen den Welten? Wo genau sollen die Remote User sich jetzt verbinden? Grüße Phil

Na aber sicher darfst du das

Na klar, mit Scripten bekommt man so ziemlich alles hin. Aber einfach Gruppen hinzufügen funktioniert halt nicht. Und diese Frage wurde vom TO gestellt. Grüße Phil

Es gibt viele doofe Dinge... Aber auch viele gute Dinge... .

Hey Uli, das Automapping funktioniert nicht, wenn Gruppen als Berechtigung gesetzt werden. Es funktioniert nur wie du bereits geschrieben hast, wenn einzelne Benutzer hinterlegt werden. Grüße Phil

Mhh, Überprüfe nochmal genau das Zertifikat. Ich meine mich zu erinnern, dass ich solch einen Fehler mal nach einer Migration hatte und das falsche Zertifikat gebunden war. Edit: Mal ein Autodiscover Test über Outlook und nicht Testconnect... durchführen. Was wird dort ausgespuckt. Grüße Phil

Hey Chris, besteht der Fehler bei mehreren Personen? Was sagt der Autodiscover Test von Outlook? Was passiert, wenn du ein neues Profil über SSL anlegst, funktioniert das oder fliegt er hier bereits auf die Nase? DNS Auflösung funktioniert korrekt? Grüße Phil

Mhh Okay. Ohne dich anzugreifen sollte in diesem Fall vermutlich eine EDV Firma mit ins Boot genommen werden, damit der Exchange Server korrekt aufgesetzt wird. Naja sowas gehört zu den Basics eines Exchange Servers und sollte von Grund auf korrekt konfiguriert werden. Autodiscover ist einer der wichtigsten Bestandteile beim Exchange. Hierzu gehört auch ein sauberes SplitDNS. Leider immer wieder sehr verwirrende Infos, welch einen nicht weiterbringen.

Ehhhhhhm. Ich denke / hoffe es handelt sich hier um eine Testumgebung, richtig? Du hast den SMTP von Strato in Outlook eingebunden und somit das Outlook Profil Manuell konfiguriert, nicht per Autodiscover? Ich glaube du solltest dir die Grundlagen nochmals genauer anschauen und dann mal Schritt für Schritt Tests mit Erkenntnissen durchführen. Frankysweb ist eine gute Anlaufstelle mit guten Dokumentationen. Grüße Phil

Wird über ein Smarthost oder über den MX versendet?

Kann ich auch nur bestätigen. Schon immer mit dem Exclaimer gearbeitet und auch bei Kunden in Betrieb. Sehr zufrieden damit (auch mit M365).

Da war was, stimmt sry.

Hi Armin, ich muss ehrlich sagen, dass mir sowas noch nie unterkommen ist. Wie spiegelt es sich bei dir wieder, dass die Gruppen ins AD geschrieben werden. Im Normalfall schreibt AD Connect keine Gruppen aus der Cloud nach OnPremise zurück. Ich habe soeben nochmals nachgesehen, alle Teams Gruppen und selbst die Verteilergruppe welche Cloud Only ist wird lokal nicht im GAL angezeigt. Was auch logisch ist, da der lokale Exchange diese Gruppen nicht kennt. Grüße Phil

Irgendwie habe ich das Gefühl du willst nur nicht zu viele Informationen loswerden 🙄🙄

Da hast Du Recht 😁. Genau aus diesem Grund hatte ich gefragt, ob die Mails nur von M365 zu M365 nicht mehr angekommen sind oder auch von anderen Providern. Dies hatte ich nämlich tatsächlich in der Anfangszeit von M365 bereits ein paar Mal erlebt👍

Was heißt er hat ein M365 Konto erstellt? Wurde ein Tenant erstellt? Sowas höre ich zum ersten Mal, dass die Mails danach nicht mehr angekommen sind. Sind die Mails bei anderen Exchange Konten eingegangen? Von wo wurde getestet? Aus M365 zu M365 oder auch anderen? Ansonsten wie Norbert geschrieben hat, sind mehr Infos hilfreich. Grüße Phil

Naja oder halt einfach den Alias entfernen 😅. Wie gesagt, der upn anmeldename wird mir der primären domain erstellt. Diesen auf die zweite domain ändern und dann den alias entfernen. Falls die alte mail noch Primär ist, diese zuvor ändern. Grüße Phil

Hi, Hast du den Benutzeranmeldename kontrolliert? Wenn du diesen auf die Zweite Domain umstellst, kannst du den Alias entfernen. Grüße Phil

Mhh. Hier kann ich dir leider nicht helfen . Aber ein kleinen Trick kann ich dir verraten, wenn es um die Microsoft Dokumente, bzw. Anleitungen geht. Tausche das "en-us" gegen "de-de" aus. Danach hast du die Seite auf Deutsch. Auf der linken Seite gibts die Punkte: Auswählen einer VMware-Migrationsoption mit der Azure Migrate-Servermigration - Azure Migrate | Microsoft Docs Dort gibts Wissensmaterial zu HyperV und VmWare. Die Frage ist wo setzt man hier jetzt an? Grüße Phil

Schau dir mal Azure Migrate an . About Azure Migrate - Azure Migrate | Microsoft Docs Grüße Phil