Jump to content

Peterzz

Members
  • Gesamte Inhalte

    343
  • Registriert seit

  • Letzter Besuch

Alle erstellten Inhalte von Peterzz

  1. Das habe ich im Ausganspost geschrieben: "Die E-Mail wurde vom Applikationsserver an ein Postfach gesendet, welches sich auf dem Exchange 2019 befindet." Dann ist ja alles gut Für mich trotzdem komisch, dass die E-Mail einen solchen Weg einschlägt.
  2. Der 2013 soll ja irgendwann abgeschaltet werden. Danke für die Info. Das hole ich nach.
  3. Hallo, ich befinde mich gerade in einer Migration von Exchange 2013 zu Exchange 2019. Der Mailfluss sollte komplett auf den Exchange 2019 umgestellt sein. Nun habe ich eine Applikation auf den neuen Exchange Server umgestellt (SMTP Sever geändert) und habe mir den E-Mail Header einer von der Applikation gesendeten Angesehen und werde daraus nicht ganz schlau. Die E-Mail wurde vom Applikationsserver an ein Postfach gesendet, welches sich auf dem Exchange 2019 befindet. Received: from Exchange2013 (xxx.xxx.xxx.xxx) by Exchange2019 (xxx.xxx.xxx.xxx) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.2.1118.20 via Mailbox Transport; Wed, 14 Dec 2022 12:47:53 +0100 Received: from Exchange2019 (xxx.xxx.xxx.xxx) by Exchange2013 (xxx.xxx.xxx.xxx) with Microsoft SMTP Server (TLS) id 15.0.1497.42; Wed, 14 Dec 2022 12:47:51 +0100 Received: from ApplikationsServername (xxx.xxx.xxx.xxx) by Exchange2019 (xxx.xxx.xxx.xxx) with Microsoft SMTP Server id 15.2.1118.20 via Frontend Transport; Wed, 14 Dec 2022 12:47:51 +0100 Wenn ich das richtig sehe, dann sendet der Applikationsserver die Nachricht an den Exchange Server 2019. Dieser sendet dann die E-Mail an den Exchange Server 2013, welcher wiederum die E-Mail an den Exchange Server 2019 sendet. Woran könnte es liegen, dass die E-Mail noch über den Exchange Server 2013 läuft? Gruß Peter
  4. Danke. Wer weiß, was der bei DigiCert in seinem Labor getestet hat....
  5. Hast du bei dir als Serveradresse eine IP-Adresse angegeben? Das funktioniert nämlich lau DigiCert nicht.
  6. Ich habe bei dem Hersteller nachgefragt und er meinte, dass TLS 1.2 und TLS 1.3 unterstützt wird. Das komische ist, rufe ich das Tool auf dem EX2013-Server auf mit name.domain.de (name.domain.de steht im Zertifikat) kommt es zu keiner Fehlermeldung, bei dem 2019er schon. Der Name im Zertifikat zeigt per Split-DNS auf den Exchange Server 2019.
  7. Hallo, nachdem ich (s.u.) ein paar Problem mit meinem Zertifikat lösen konnte, habe ich nun folgendes Problem. Kurze Ausgangslage: EX2013 soll durch EDX2019 abgelöst werden. Installation EX2019 fertig, beide Exchange Server laufen parallel, auf dem Exchange Server 2019 befinden sich noch keine Postfächer, Sendeconnector läuft noch auf dem EX2013. Zertifikat ist Nun habe ich mit dem Tool Certificate Installation Checker von DigiCert den neune Exchange Server 2019 überprüft und erhalte folgende Fehlermeldung. Gegen den Exchange Server 2013 erscheinen die Fehlermeldungen nicht. Das Tool habe ich von Exchange 2019 aus gestartet. Woran kann das liegen?
  8. Die Positiv-Meldung, dass das Zertifikat an dem SMTP-Dienst gebunden ist, muss ich leider zurück nehmen. da waren meine Augen wohl betrübt von allem. Auch nach erneutem Entfernen und Hinzufügen bekommen icgh den Dienst nicht an das Protokoll gebunden :-( Gibt es sonst noch Ideen, wie ich das Zertifikat an den Dienst bekomme? Wie kann ich das Zertifikat explizit an den Sende - und Empfangsconnector binden und hat das ansonsten noch irgendwelche Auswirkungen? OK, ich habe es jetzt doch l hinbekommen. - Zertifikat über die MMC löschen - Zertifikat mit Exchange Management Shell importieren Import-ExchangeCertificate -FileData ([Byte[]]$(Get-Content -Path C:\Install\Zertifikat.pfx -Encoding byte -ReadCount 0)) -Password (convertto-securestring -string "Kennwort" -asplaintext -force) - Im EAC kann SMTP an das Zertifikat gebunden werden.
  9. Die Replikation bei nur 2 DCs dauert nicht so lange und den Key austauschen ging bei mir rein technisch nicht, da eine Fehlermeldung auftrat. Und später habe ich dann diesen Artikel von MS gefunden.
  10. Kannst du mir helfen, wo ich da überall suchen muss? Werden die alten Reste dann einfach gelöscht?
  11. Was meinst du damit? Deinstallation von Exchange 2019 und Neuinstallation des Windows Servers anstelle von umbenennen?
  12. Da im AD wahrscheinlich u.a. die "falschen Datenbanken GUIDs des "alten" Exchange Servers stecken und auch der Exchange Standard Schlüssel nicht akzeptiert wird, werde ich wohl um ein erneutes Deinstallieren des Exchange Servers 2019 nicht herumkommen. Ein Suchen und löschen/ändern mit ADSI Edit bringt wohl keinen Erfolg und es bleibt ein Restrisiko, das immer noch was weiteres auftaucht. Wahrscheinlich ist es auch nicht supported. Ich habe vor den Windows Server umzubenennen und anschließend den Exchange Server 2019 neu zu installieren. Könnte das eine Lösung sein?
  13. Ich habe jetzt alle DBs bis auf die erste gelöscht. Bei einer Neuanlange einer DB mit der EAC kommt die Fehlermeldung "Fehler Ihre Anforderung konnte nicht abgeschlossen werden. Versuchen Sie es in einigen Minuten noch mal." Im Eventlog steht jetzt die Fehlermeldung ID: 5011 Quelle WAS Schwerwiegender Kommunikationsfehler im Windows-Prozessaktivierungsdienst bei einem Prozess für den Anwendungspool "MSExchangeRestAppPool". Die Prozess-ID ist "2320". Das Datenfeld enthält die Fehlernummer. Nach kurzer Zeit kommen folgenden Warnungen hinzu: 1006 MSExchange Mailbox Replication The Microsoft Exchange Mailbox Replication service was unable to process jobs in a mailbox database. Database: Fehlende Datenbank (5eb3aab5-5c7f-4c1a-a6cd-5baab1bc0737) Error: Die Datenbank '5eb3aab5-5c7f-4c1a-a6cd-5baab1bc0737' ist nicht vorhanden. 1039 MSExchangeHMHost Worker process manager timed out after 30 seconds while waiting for a retired process handles to close (process id : 18792 ). 2937 MSExchange ADAccess Process MSExchangeHMWorker.exe (ExHMWorker) (PID=20960). Object [CN=DB2,CN=Databases,CN=Exchange Administrative Group (FYDIBOHF23SPDLT),CN=Administrative Groups,CN=DOMAINmx,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=Domain,DC=XXX]. Property [PublicFolderDatabase] is set to value [Doamin/Configuration/Deleted Objects/DB-OeffentlicheOrdner DEL:3ed27eb4-9d58-48cd-9726-4fd8d47b0c68], it is pointing to the Deleted Objects container in Active Directory. This property should be fixed as soon as possible.
  14. Da ich die Installation zum Teil gescriptet habe, sind die DBs mit gleichem Namen angelegt worden. Ohne Recovery. Ich habe schon eine DB gelöscht (siehe Eingangstext) und habe sie über die EAC neu angelegt. Auch hier kommt der gleich Fehler.
  15. Hallo, ich habe ein paar Probleme nach einer Exchange 2019 Installation. Ich werde mein Doing bis jetzt mal kurz in Stichpunkten erläutern. - Installation eines neuen Exchange Server 2019 neben einen bestehenden Exchange Server 2013. - Konfiguration des neuen Exchange Server 2019 fertig – Postfächer und Mailfluss noch über EX2013 - Feststellung das falscher Produktschlüssel (Enterprise anstelle von Standard) eingeben wurde - Deinstallation von Exchange Server 2019 - Neuinstallation von Exchange Server 2019 Jetzt kommt es zu folgenden Problemen. Datenbanken, welche mit Powershell angelegt worden sind bringen im EAC und in Eventlog Fehlermeldungen. Im Eventlog steht: The Microsoft Exchange Mailbox Replication service was unable to process jobs in a mailbox database. Database: Fehlende Datenbank (9e41e9d3-6330-420e-a255-074fcbe6319d) Error: Die Datenbank '9e41e9d3-6330-420e-a255-074fcbe6319d' ist nicht vorhanden. Die Fehler in der EAC sieht man in den Bildern. DB0x sind die neuen Datenbanken Ein Löschen und neu Anlagen über EAC einer Datenbank hat auch keinen Erfolg gebracht. Die Eingabe des diesmal richtigen Standard Produktkeys wird mit „Ungültiger Product Key“ abgelehnt. Get-ExchangeServer -identity EX2019 | Format-List Name,Edition,AdminDisplayVersion Name : EX2019 Edition : StandardEvaluation AdminDisplayVersion : Version 15.2 (Build 1118.7) Kann jemand helfen?
  16. Mit dem Entfernen und neu Importieren des Zertifikats hat es jetzt funktioniert. Get-ExchangeCertificate zeigt mir jetzt die Bindung zum SMTP Dienst an. Danke NobertFe
  17. Die Proxy Frage hat mich einen Schritt weiter gebracht. Nachdem ich mit Netsh Winhttp den Proxy eingetragen und einen Reboot gemacht habe, wird das Zertifikat als gültig gekennzeichnet. Der SMTP Dienst lässt sich aber weiterhin nicht an das Zertifikat binden. Der Powershell Befehl wird ohne Fehlermeldung ausgeführt aber der Dienst wird nichtt gebunden
  18. Hallo zusammen, ich will meinen Exchange Server 2013 (aktueller Patchstand) durch einen Exchange Server 2019 ersetzen. Der Exchange Server 2019 ist installiert und ich habe das Exchange Zertifikat vom Exchange Server 2013 über das EAC exportiert und auf dem neuen Exchange Server 2019 über die MMC (Zertifikate) in Computerkonto - Eigenen Zertifikate importiert. Anschließend war das Zertifikat in dem EAC des 2019er Servers zu sehen. Ich habe dann die Dienste IIS, POP, IMAP und SMTP an das Zertifikat gebunden. Nun muss ich feststellen, dass das Zertifikat die Fehlermeldung bring, dass die Sperrungsüberprüfung fehlgeschlagen ist und dass der Dienst SMTP nicht an das Zertifikat gebunden worden ist. Woran kann es liegen, dass die Sperrungsüberprüfung fehlgeschlagen ist? Eine Internetverbindung besteht.
  19. Peterzz

    Zertifikatsfehler

    Ok. danke schon mal. Es scheint jetzt ohne Fehler zu laufen - hoffe ich. Warten ist wohl immer nötig...
  20. Peterzz

    Zertifikatsfehler

    Den Befehl habe ich ausgeführt [PS] C:\>Set-ClientAccessService Exchange2013 WARNUNG: Der Befehl wurde erfolgreich abgeschlossen, jedoch ohne dass Einstellungen geändert wurden. Get-ClientAccessService bringt aber immer noch beide Servernamen Ich habe die virtuellen Verzeichnisse angepasst. In beiden (alter und neuer Server) steht AutoDiscoverServiceInternalUri : https://exchange.domain.de/Autodiscover/Autodiscover.xml exchange.domain.de.de ist der Split DNS Name, welcher auch im Zertifikat steht. Im DNS sind beider Server unter exchange.domain.de eingetragen, Die virtuellen Verzeichnisse sehen so bei den Servern aus: [PS] C:\>Get-ExchangeServer | Get-ActiveSyncVirtualDirectory | fl Identity, *ternalurl* Identity : Exchange2013\Microsoft-Server-ActiveSync (Default Web Site) InternalUrl : https://exchange.Domain.de/Microsoft-Server-ActiveSync ExternalUrl : https://exchange.Domain.de/Microsoft-Server-ActiveSync Identity : Exchange2019\Microsoft-Server-ActiveSync (Default Web Site) InternalUrl : https://exchange.Domain.de/Microsoft-Server-ActiveSync ExternalUrl : https://exchange.Domain.de/Microsoft-Server-ActiveSync [PS] C:\>Get-ExchangeServer | Get-ClientAccessService | fl Identity, *ternaluri* Identity : Exchange2013 AutoDiscoverServiceInternalUri : https://exchange.Domain.de/Autodiscover/Autodiscover.xml Identity : Exchange2019 AutoDiscoverServiceInternalUri : https://exchange.Domain.de/Autodiscover/Autodiscover.xml [PS] C:\>Get-ExchangeServer | Get-EcpVirtualDirectory | fl Identity, *ternalurl* Identity : Exchange2013\ecp (Default Web Site) InternalUrl : https://exchange.Domain.de/ecp ExternalUrl : https://exchange.Domain.de/ecp Identity : Exchange2019\ecp (Default Web Site) InternalUrl : https://exchange.Domain.de/ecp ExternalUrl : https://exchange.Domain.de/ecp [PS] C:\>Get-ExchangeServer | Get-WebServicesVirtualDirectory | fl Identity, *ternalurl* Identity : Exchange2013\EWS (Default Web Site) InternalUrl : https://exchange.Domain.de/EWS/Exchange.asmx ExternalUrl : https://exchange.Domain.de/EWS/Exchange.asmx Identity : Exchange2019\EWS (Default Web Site) InternalUrl : https://exchange.Domain.de/EWS/Exchange.asmx ExternalUrl : https://exchange.Domain.de/EWS/Exchange.asmx [PS] C:\>Get-ExchangeServer | Get-MapiVirtualDirectory | fl Identity, *ternalurl* Identity : Exchange2013\mapi (Default Web Site) InternalUrl : https://exchange.Domain.de/mapi ExternalUrl : https://exchange.Domain.de/mapi Identity : Exchange2019\mapi (Default Web Site) InternalUrl : https://exchange.Domain.de/mapi ExternalUrl : https://exchange.Domain.de/mapi [PS] C:\>Get-ExchangeServer | Get-OabVirtualDirectory | fl Identity, *ternalurl* Identity : Exchange2013\OAB (Default Web Site) InternalUrl : https://exchange.Domain.de/OAB ExternalUrl : Identity : Exchange2019\OAB (Default Web Site) InternalUrl : https://exchange.Domain.de/OAB ExternalUrl : [PS] C:\>Get-ExchangeServer | Get-OutlookAnywhere | fl Identity, *ternalhost*, *ticationmeth* Identity : Exchange2013\Rpc (Default Web Site) ExternalHostname : InternalHostname : exchange.Domain.de ExternalClientAuthenticationMethod : Ntlm InternalClientAuthenticationMethod : Ntlm IISAuthenticationMethods : {Basic, Ntlm, Negotiate} Identity : Exchange2019\Rpc (Default Web Site) ExternalHostname : InternalHostname : exchange.Domain.de ExternalClientAuthenticationMethod : Negotiate InternalClientAuthenticationMethod : Ntlm IISAuthenticationMethods : {Basic, Ntlm, Negotiate} [PS] C:\>Get-ExchangeServer | Get-OwaVirtualDirectory | fl Identity, *ternalurl* Identity : Exchange2013\owa (Default Web Site) InternalUrl : https://exchange.Domain.de/owa ExternalUrl : https://exchange.Domain.de/owa Identity : Exchange2019\owa (Default Web Site) InternalUrl : https://exchange.Domain.de/owa ExternalUrl : https://exchange.Domain.de/owa
  21. Peterzz

    Zertifikatsfehler

    Nach frankysweb.de Get-ClientAccessService bringt mir beide Servernamen: Exchange2013.Domain.de Exchange2019.Domain.de Sollte ich Set-ClientAccessService Exchange2019.Domain.de oder erstmal den alten Servernamen nehmen?
×
×
  • Neu erstellen...