MHeiss2003

Ja liegt es. Danke, dann muss ich mir die E-Mail nochmals genauer ansehen. Eventuell ist doch am Empfänger oder Absender aus Outlook heraus irgendwie noch etwas veraltetes im Cache.

Benutzer von DomainB sendet über EX2019 onPrem an externen Empfänger.

Guten Abend liebe IT-Gemeinde, welchen Weg schlagt Ihr ein, wenn Ihr es ermöglichen wollt, vom EX2019 onPrem über die DomainB versandte E-Mails an einen Relayconnector auf eben diesem zu übergeben, wenn gleich der Connector von M365 E-Mails zu EXO installiert ist und brav die E-Mails transportiert? Aktuell ist es so, dass wenn ich E-Mails über die DomainB versende, ein NDR von EXO mit 554 5.4.0 zurückkommt. Die DomainB ist in EXO nicht eingerichtet, auf dem EX2019 allerdings Autoritativ. Danke und Grüße Mario

Hallo, ich habe einen Windows Server 2016 mit IIS und Webdav. Die Einrichtung habe ich gemäß der Anleitung bei Microsoft vorgenommen: https://learn.microsoft.com/de-de/iis/install/installing-publishing-technologies/installing-and-configuring-webdav-on-iis Nun zu meinem Problem: Die Nutzung des virtuellen Verzeichnisses, dessen physikalischer Pfad einen UNC Pfad auf die Freigabe eines Domänen Mitgliedservers enthält, ist nur solange möglich, bis ich die Pfadanmeldinformationen von "Bestimmter Benutzer" auf "Anwendungsbenutzer (Pass-Through-Authentifizierung)" ändere. Danach erhalte ich beim Zugriff über den Windows Client die Meldung: "Der eingegebene Ordner ist ungültig. Wählen Sie einen anderen Ordner". Ergänzt habe ich die Freigabe- und Sicherheitsberechtigungen des Shares auf dem Mitgliedsserver um den Eintrag SERVERNAME$ mit den Rechten Lesen, Ausführen, Ordnerinhalte anzeigen und Lesen. Der DefaultAppPool auf dem IIS läuft mit der Identität "LocalSystem". Sobald ich einen lokalen Pfad nutze, funktioniert der Zugriff auch mit "Anwendungsbenutzer (Pass-Through-Authentifizierung)". Habt Ihr eine Idee, was ich übersehe? Danke Mario

Hallo zusammen, folgende Meldung erhalte ich, wenn ich die Anmeldung aus einem der Office 365 Programme starte: Zurzeit kann keine Verbindung hergestellt werden. Überprüfen Sie bitte das Netzwerk, und versuchen es später erneut. Der Fehler tritt an zwei Servern auf. Den Support Assistenten habe ich laufen lassen, dieser findet keine Probleme. Die Firewall ausgeschaltet, den Content-Filter überprüft. Fehlerbehebung laut Microsoft durchgearbeitet. Alle Lösungen haben bisher nicht. Auch eine erneute Deinstallation und Installation inkl. dem jeweiligen Neustart, brachte keine Veränderung. Leider weiß ich nicht, wo ich noch nachsehen könnte. Habt Ihr eine Idee? Dank und Grüße Mario

Guten Morgen Jan, generell gebe ich Dir recht, was den Stressfaktor angeht. Nachdem ich selber als Händler, sowohl beratend als auch verkaufend, tätig bin, schockieren mich solche Praktiken. Das schadet der Branche, in der ich tätig bin, und macht auch den Wettbewerb schwieriger. Ganz zu schweigen von der Möglichkeit, sich durch die Anwendung solcher Praktiken auf Kosten anderer zu bereichern. Gruß Mario

Danke Franz für Deine Ausführungen. Es handelt sich auf jeden Fall um gebrauchte Lizenzen aus einem EA. Es liegt ein Transfer Dokument von "einem großen Händler aus dem Kreis Stormarn in Schleswig Holstein" auf den IT-Dienstleister vor. Dann existieren Rechnungen und Lieferscheine an den Endkunden von diesem Dienstleister. Weiterhin liegen geschwärzte Dokumente des Ersterwerbs vor, die dem "großen Händler" vorliegen und ausgehändigt wurden. Ein Transfer Dokument auf den Endkunden existiert nicht. Laut Aussage des "großen Händler" ist dieses Dokument nicht notwendig. Hat der Kunde Deiner Meinung nach Lizenzen oder nicht?

Das habe ich schon sehr intensiv getan! Der Kunde hat diese Lizenzen für ca. 15.000 EUR gekauft. Nun ist er natürlich verunsichert. Danke, das ist eine gute Idee.

Schönen guten Morgen, Kann mir jemand sagen, ob und wie es möglich ist, eine entsprechende Prüfung bei Microsoft zu veranlassen, wenn ich der Meinung bin, dass die Lizenzierung eines Kunden nicht auditsicher ist. Hintergrund meiner Frage ist, dass ich einen Kunden habe, der außer Rechnungen keinerlei Lizenzdokumente von Microsoft nachweisen kann. Die Dokumente, die er erhalten hat, zeigen einen Lizenznehmer, der nicht der Kunde ist, sondern ein Dienstleister. Der Dienstleister legt ein Dokument vor, das seine Beschaffung bei wiederum einem Händler für wiedervermarktete Lizenzen belegen soll. Grüße Mario Heiß

Ich danke Euch allen für Eure Meinung. Danke Norbert für den Tipp in Bezug auf die Vergangenheitsbewältigung!

Also, wenn ich CN=schema-root oder auch CN=OAB Version 4 lese...

Hallo zusammen, ich arbeite gerade diesen Artikel durch: Konfigurieren öffentlicher Exchange Server-Ordner für eine Hybridbereitstellung Das Skript Sync-ModernMailPublicFolders.ps1, wie in Schritt zwei beschrieben, habe ich laufen lassen. In der Datei "MailPublicFolderOrphans.txt" werden mir insgesamt 14 Ordner aufgelistet, die als "orphaned" ausgegeben werden. Nun frage ich mich, ob ich diese einfach löschen sollte, wie empfohlen. Es befinden sich doch einige Ordner darunter, bei denen ich mir nicht sicher bin, ob das ratsam wäre. Hier die Liste: CN=Default,CN=Microsoft Exchange System Objects,DC=COMTOSO,DC=local CN=exchangeV1,CN=Microsoft Exchange System Objects,DC=COMTOSO,DC=local CN=globalevents,CN=Microsoft Exchange System Objects,DC=COMTOSO,DC=local CN=internal,CN=Microsoft Exchange System Objects,DC=COMTOSO,DC=local CN=microsoft,CN=Microsoft Exchange System Objects,DC=COMTOSO,DC=local CN=OWAScratchPad{BFFDCA85-D484-47CC-B1B2-FBABA618B009},CN=Microsoft Exchange System Objects,DC=COMTOSO,DC=local CN=StoreEvents{BFFDCA85-D484-47CC-B1B2-FBABA618B009},CN=Microsoft Exchange System Objects,DC=COMTOSO,DC=local CN=schema-root,CN=Microsoft Exchange System Objects,DC=COMTOSO,DC=local CN=OAB Version 2,CN=Microsoft Exchange System Objects,DC=COMTOSO,DC=local CN=OAB Version 3a,CN=Microsoft Exchange System Objects,DC=COMTOSO,DC=local CN=OAB Version 4,CN=Microsoft Exchange System Objects,DC=COMTOSO,DC=local CN=Offlineadressbuch - \/o\=COMTOSO\/cn\=addrlists\/cn\=oabs\/cn\=Standard-Of,CN=Microsoft Exchange System Objects,DC=COMTOSO,DC=local CN=Offlineadressbuch - first administrative group,CN=Microsoft Exchange System Objects,DC=COMTOSO,DC=local CN=Schedule\+ Zeitplaninformationen - first administrative group,CN=Microsoft Exchange System Objects,DC=COMTOSO,DC=local OnPremise ist installiert ein Exchange Server 2019, der bereits zwei Migrationen erfahren hatte. Die erste von Version 2010 auf 2013, die zweite von 2013 auf 2019. Danke vorab für Eure Meinungen. Grüße aus dem bewölkten Frankenland. Mario

Mit dem Tool Fiddler konnte ich herausfinden, dass beim Start von Outlook ein Server "mail.[domainname].de" kontaktiert wurde, den es aber gar nicht mehr gibt. Es kam somit zu einem Timeout. Zu allem Übel war dieser auch noch auf dem verwendeten DNS-Server eingetragen. Den Eintrag habe ich gelöscht und nun startet Outlook 2019 wieder normal. Vielleicht kann mich doch noch jemand aufklären, wie es zu diesem Aufruf kommt?

Hallo, was war das Problem? Bei mir dasselbe. Danke und Grüße Mario

Hallo liebe community, in einem meiner Netzwerke ist auf einem Windows Server 2019 ein Exchange Server 2019 Standard installiert. Sowohl Exchange, wie Windows sind aktuell. Folgendes Verhalten beobachte ich auf allen betroffenen Rechnern im Netzwerk: Outlook wird gestartet und es erscheint der Hinweistext "Profil wird geladen". Hier entsteht eine Wartezeit von teilweise über 1 Minute, bis der Text erscheint "Wird verarbeitet...". Zuerst hatte ich Autodiscover im Verdacht, allerdings erhalte ich keine Fehlermeldung diesbezüglich. Die Prüfung in Outlook selber ist erfolgreich abgeschlossen. Jetzt habe ich Office 2019 Standard (Version 16.0.10386.20017) einmal deinstalliert und testhalber 365 Apps for Business (16.0.15225.20204) installiert. Und siehe da, der Start von Outlook ist schnell wie gewohnt. Hat jemand hierfür eine Erklärung? Grüße aus dem sonnigen Frankenland. Mario

//abgetrennt von: https://www.mcseboard.de/topic/216361-office-2019-outlook-profil-wird-geladen/ Hi floho, wie hattest Du das Problem lösen können? Bei mir ist es haargenau dasselbe. Grüße Mario

Nun zu meiner Lösung, vielen Dank für die sehr hilfreichen Ansätze und Anregungen! 1. Erstellen eines neuen selbst signierten Zertifikates über die EMS und Ersetzen des vorhandenen SMTP-Zertifikates: New-ExchangeCertificate -IncludeServerFQDN -IncludeServerNetBIOSName 2. Die Frage, ob das vorhandene SMTP-Standardzertifikat überschrieben werden soll, mit JA also J beantworten. 3. Löschen des Wildcard Zertifikates über den EAC jetzt möglich, da das Standard Transportzertifikat jetzt das selbst signierte ist 4. Import über den EAC des gleichen Wildcard Zertifikates als PFX-Datei 5. Zuweisen des Dienstes IIS, bei Bedarf POP und IMAP, über den EAC 6. Exchange Hybrid Zertifikat getauscht: #Alle vorhandenen Exchange Zertifikate anzeigen Get-ExchangeCertificate #Das neue Zertifikat mit dem korrekten Thumbprint auswählen $cert = Get-ExchangeCertificate -Thumbprint <thumbprint> #String für den Aussteller zusammenfügen $TLSCert = (‘<I>’+$cert.issuer+'<S>’+$cert.subject) Set-SendConnector "Outbound to Office 365" -TlsCertificateName $TLSCert Set-ReceiveConnector "Default Frontend SERVERNAME" -TlsCertificateName $TLSCert (Quelle: https://frankeisel.de/exchange-hybrid-zertifikate-tauschen/) 7. Start des Office 365 Hybrid Configuration Wizards und Durchführung der Aktualisierung 6. Neustart des Servers Schönen Abend.

Entfernen geht noch, allerdings das zuweisen nicht mehr. Gleicher Fehler: " Das angegebene Zertifikat ist nicht für das SMTP-Protokoll aktiviert..." Jetzt bleibt mir nur das Zertifikat nochmals neu einzuspielen. Muss ich exportieren bevor ich neu importiere oder kann ich einfach entfernen?

Kurzes Update. Nach einem HealthChecker Durchlauf habe ich tatsächlich etwas zu dem alten Zertifikat finden können. Einem Sendeconnector ist das alte SSL Zertifikat zugewiesen. Wie würdet Ihr jetzt vorgehen? Entfernen, neu zuweisen, fertig!

Aber auf der Suche nach einem alten zugewiesenen Zertifikat irrelevant, oder?

Danke. Das Ergebnis ist, dass 3 der 7 Empfangs-Connectoren das korrekte Zertifikat zugewiesen haben. Die anderen haben keine Zuweisung.

Und wie prüfe ich das am besten?

Und hast Du den Fehler beheben können? Mir ist das Ganze auf den Fuß gefallen bei der Konfiguration der Exchange Hybrid Umgebung über den Assistenten und die daraufhin erfolgte Kontrolle der Ereignislogs.

Wie mache ich das am besten? Leider ebenfalls nichts. SMTP lässt sich anwählen und die Auswahl speichern. Eine Zuweisung erfolgt aber nicht.

Hallo Mikro, danke für Deine Nachricht. Es ist aktuell überhaupt kein Zertifikat an den SMTP-Dienst gebunden, siehe Screenshot. Es wird angezeigt, ja. Und ja, es hat einen Schlüssel in der MMC. Mein Gedanke war, dass es vielleicht beim Import über die MMC ein Problem gegeben haben könnte und deshalb die Zuweisung an IIS und SMTP einfach durch einen Reimport nochmals sauber durchgeführt werden könnte.