Jump to content

Gerber

Members
  • Content Count

    199
  • Joined

  • Last visited

Community Reputation

13 Neutral

About Gerber

  • Rank
    Member

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Alles klar, perfekt. Genau, sonst würde die Migration sowieso fehlschlagen, wenn die Routing Adresse bei der Migration im Postfach (Benutzer) fehlt. Korrekt. So muss es auch sein. Der Autodiscover muss auf den lokalen Exchange zeigen (public IP vom Anschluss). Über die Routing Adresse wird dann das Postfach nach M365 aufgelöst. Wie sieht es mit der Frage von "mirko" aus? Hast du den Autodiscover nach M365 evlt zuvor verboten? Hast du es mit einem neuen Profil getestet? Ist dies ein Test Benutzer oder hast du mehrere Benutzer nach M365 migriert? Grüß
  2. Hi Mario, hast du ein neues Postfach über den lokalen Exchange in M365 erstellt oder hast du ein Postfach nach M365 migriert? Hat dieser Benutzer eine Routingadresse hinterlegt bekommen "Adressrichtlinie durch Hybrid" xxx.xx.mail.onimicrosoft.com. Wie ist der lokale Server eingerichtet, zwecks Zertifikaten und Split DNS? Grüße Phil
  3. Hallo, ich konnte es bisher bei uns selbst und bei unseren Kunden nicht feststellen. Grüße Phil
  4. Naja, dafür hast du dann einen korrekt konfigurierten Exchange Server... Ich besitze zwar kein IPhone, bilde mir aber durchaus auch ein, dass Mails/Kalender/Kontakte auf dem Handy doch auch wichtig sind .
  5. Du kannst keine öffentlichen Zertifikate für interne Namen ausstellen. Also z.B. exch-01.domain.local kann nicht ausgestellt werden. Im Standard hören die Exchange Server allerdings auf interne Namen und SPLIT DNS muss zunächst von dir konfiguriert werden. Nach dem du dies korrekt konfiguriert hast, kannst du die Zertifikate binden. In der Regel werden 2 SANs ins Zertifikat aufgenommen. autodiscover.domain.de mail.domain.de oder outlook.domain.de oder was auch immer du willst. Eventuell sollte dir hier jemand unter die Arme greifen, der bereits etwas mehr Erfahrun
  6. Für diese Zeit hättest du bereits mindestens 3 Zertifikate kaufen können 😅. Ich würde an dieser Stelle nicht lange rummachen und wie @mikro bereits geschrieben hat, ein öffentliches Zertifikat kaufen. Edit: Da war jemand schneller 🙉😅
  7. Moin, wie du schon sagst, musst du hierfür 3td Party Tools nutzen. Hierzu einfach einmal die Suchmaschine bemühen und du findest einige. Grüße Phil
  8. Genau. Aber dann kann ich das Zertifikat gleich zuweisen und später den Patch einspielen. Danke dir 👍
  9. Yes. 👍 Wenn ich das Zertifikat zuweise sollte nichts mit den Clients passieren, richtig? Lediglich wenn ich ein IISReset durchführe?
  10. 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
  11. 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ückgege
  12. 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
  13. 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 H
×
×
  • Create New...