Peterzz

Stimmt, ich werde wohl alles neu machen.

Was meinst du damit? Deinstallation von Exchange 2019 und Neuinstallation des Windows Servers anstelle von umbenennen?

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?

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.

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.

Mit gleichem Namen und ohne Recovery.

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?

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

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

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.

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

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

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?

Spit-DNS ist eingerichtet. Die virtuellen Verzeichnisse sind noch nicht auf dem neuen Server angepasst. Liegt es daran? Wie mache ich das ?

Hallo, ich habe einen Exchange Server 2013 aktuelle CU den ich durch einen Exchange Server aktualisieren möchte. Dazu habe ich einen neuen Exchange Server 2019 neben dem Exchange Server 2013 installiert. Sonst ist noch nichts konfiguriert. Ab diesen Zeitpunkt, gibt es beim Öffnen von Outlook ein Zertifikatsfehler, indem der Servername des neuen Exchange Servers angemeckert wird. Warum wird das angemeckert und wie kann ich das abstellen?

Ich kann mich leider erst jetzt wieder melden, war leider mit 'nem Virus beschäftigt. Das Problem konnte ich jetzt auf die Endpoint Security von trellix (McAfee) einschränken, obwohl es nicht, wie im oben erwähnten Artikel genannt, die AMSI Integration ist. Deaktiviere ich die AMSI Integration auf dem Server, hat das keine positive Auswirkung auf den Mailflow. Deaktiviere ich alle Optionen (Zugriffsschutz, Exploit-Schutz, On-Access-Schutz) innerhalb von der Endpoint Protection, hat das keine positive Auswirkung auf den Mailflow. Deinstalliere ich die Endpoint Protection funktioniert die Mailzustellung einwandfrei.

Im Eventlog finde ich nichts. Auf dem Client ist kein Virenscanner installiert, auf dem Server ist McAfee Endpoint Security und McAfee Security for Exchange installiert. Der McAfee besitzt die gleichen Einstellungen die der Exchange 2013 hatte.

Nein, im Sendeconnector ist nur der neue Server drinnen. Ich habe jetzt 2 weitere neuen Postfächer angelegt. Der Mailversand zwischen den beiden funktioniert auch nicht. Die E-Mails bleiben im Postausgang hängen. Nach einem Neustart des Exchange Server und anschließender Wartezeit sind die E-Mails aus dem Postausgang raus und befinden sich in der Warteschleife, und nach einem Restart des Exchange Transportdienstes werden die E-Mails auch zugestellt.

Ich sende nur interne E-Mails, die Postfächer liegen auf dem selben Server. Die Postfächer sind migrierte Postfächer und es findet alles in einer Testumgebung statt. Manchmal gehen die E-Mails auch direkt raus. Mir fällt gerade ein, dass ich mal ein neues Postfach anlege und schaue, ob es sich anders verhält.

Der Outlook Client ist nicht im Cache Mode und bei OWA ist das gleiche.

Hallo, ich teste gerade eine Exchange Migration von Ex2013 zu Ex2019 CU12 Ich bin mit allen Migrationsschritten eigentlich fertig, der Exchange Server 2013 ist schon deinstalliert (siehe älteres Posting dazu). Nun habe ich das Problem, das E-Mails innerhalb des Servers nicht richtig versendet werden. Manchmal bleiben die E-Mails im Postausgang (Outlook 2016) hängen (hier hilft anscheinend das Starten des Postfachtranportübergabe-Dienstes, manchmal anscheinend auch längere Zeit warten), manchmal aber auch in der Exchange Warteschleife. Wird hilft das Neustarten des MSExchange Transport Dienstes weiter. Hat vielleicht jemand eine Idee woran das liegen kann?

D Ja, das mit der Deinstallation hat funktioniert. Ich musste den Pfad zum CU12 und zum CU23 angeben, dann ist die Deinstallation durchgelaufen.

Ich habe es mit einem neuen CU probiert, die Datei (\Exchange 2013 CU23\setup\serverroles\unifiedmessaging\) ist auch vorhanden, die Installation bricht aber trotzdem ab. Hier komme ich nicht mit meine Microsoft Account rein. Die Installation des UM Paketes kann nicht ausgefüher werden, da es die Datei "MSSpeech_SR_TELE.de-DE.msi" sucht und nicht findet. Im ExchangeSetup.Log steht: Hat noch jemand eine Idee?

Hallo, ich will eine Exchange Server 2013 CU 23 deinstallieren und der Windows Installer verlangt nun das CU12 (D:\Install\cu12\Setup\ServerRoles\UnifiedMessaging\) Da ich das CU12 nicht mehr besitze, nun die Frage, wo ich das herbekommen kann? Hat jemand eine Idee? Mit einem neueren CU habe ich es probiert, das funktioniert nicht.

Mit einem ausgepackten CU23 und dem Verweis auf dieses Verzeichnis läuft die Installation weiter. Das habe ich so noch nicht erlebt ...