23
Exchange 2013 nach Umzug nicht erreichbar
Hallo,
die Lösung für mein Problem mag einfach sein. Nur stehe ich irgendwie auf dem Schlauch. ich habe einen Exchange 2013 auf einem Win2008r2 als VM auf VMWare Workstation v15 am Laufen. Es funktionierte alles sehr gut bis ich beschlossen habe, einen neuen ESXi-Server aufzusetzen und die VM dorthin zu verfrachten. Auch das ging reibungslos über die Bühne. Die IP und der Servername blieben gleich, der Server ist in der Domaine und ist durch Ping erreichbar. Er fährt auch hoch, nur die meisten Exchange-Dienste wollen nicht automatisch starten. Nach manuellem Start ist der Exchange weder über PS noch über Browser erreichbar: die Anmeldedaten werden zwar akzeptiert, das Fenster bleibt jedoch leer. IIS läuft, Zertifikate in den Bindungen für Default Web Site und Exchange Back End habe ich überprüft: sind alle gültig.
Hätte jemand einen Tipp?
Danke
die Lösung für mein Problem mag einfach sein. Nur stehe ich irgendwie auf dem Schlauch. ich habe einen Exchange 2013 auf einem Win2008r2 als VM auf VMWare Workstation v15 am Laufen. Es funktionierte alles sehr gut bis ich beschlossen habe, einen neuen ESXi-Server aufzusetzen und die VM dorthin zu verfrachten. Auch das ging reibungslos über die Bühne. Die IP und der Servername blieben gleich, der Server ist in der Domaine und ist durch Ping erreichbar. Er fährt auch hoch, nur die meisten Exchange-Dienste wollen nicht automatisch starten. Nach manuellem Start ist der Exchange weder über PS noch über Browser erreichbar: die Anmeldedaten werden zwar akzeptiert, das Fenster bleibt jedoch leer. IIS läuft, Zertifikate in den Bindungen für Default Web Site und Exchange Back End habe ich überprüft: sind alle gültig.
Hätte jemand einen Tipp?
Danke
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 494579
Url: https://administrator.de/contentid/494579
Printed on: April 19, 2024 at 21:04 o'clock
23 Comments
Latest comment
Zitat von @dbox3:
Hallo,
die Lösung für mein Problem mag einfach sein. Nur stehe ich irgendwie auf dem Schlauch. ich habe einen Exchange 2013 auf einem Win2008r2 als VM auf VMWare Workstation v15 am Laufen. Es funktionierte alles sehr gut bis ich beschlossen habe, einen neuen ESXi-Server aufzusetzen und die VM dorthin zu verfrachten. Auch das ging reibungslos über die Bühne. Die IP und der Servername blieben gleich, der Server ist in der Domaine und ist durch Ping erreichbar. Er fährt auch hoch, nur die meisten Exchange-Dienste wollen nicht automatisch starten. Nach manuellem Start ist der Exchange weder über PS noch über Browser erreichbar: die Anmeldedaten werden zwar akzeptiert, das Fenster bleibt jedoch leer. IIS läuft, Zertifikate in den Bindungen für Default Web Site und Exchange Back End habe ich überprüft: sind alle gültig.
Hätte jemand einen Tipp?
Danke
wie wäre es mal mit einem Blick ins ereignisprotokoll, und wenn du mit uns die fehler teilst, wissen wir alle mehr...Hallo,
die Lösung für mein Problem mag einfach sein. Nur stehe ich irgendwie auf dem Schlauch. ich habe einen Exchange 2013 auf einem Win2008r2 als VM auf VMWare Workstation v15 am Laufen. Es funktionierte alles sehr gut bis ich beschlossen habe, einen neuen ESXi-Server aufzusetzen und die VM dorthin zu verfrachten. Auch das ging reibungslos über die Bühne. Die IP und der Servername blieben gleich, der Server ist in der Domaine und ist durch Ping erreichbar. Er fährt auch hoch, nur die meisten Exchange-Dienste wollen nicht automatisch starten. Nach manuellem Start ist der Exchange weder über PS noch über Browser erreichbar: die Anmeldedaten werden zwar akzeptiert, das Fenster bleibt jedoch leer. IIS läuft, Zertifikate in den Bindungen für Default Web Site und Exchange Back End habe ich überprüft: sind alle gültig.
Hätte jemand einen Tipp?
Danke
Frank
Hallo,
Gruß,
Peter
Zitat von @dbox3:
ich habe einen Exchange 2013 auf einem Win2008r2 als VM auf VMWare Workstation v15 am Laufen. Es funktionierte alles sehr gut bis ich beschlossen habe, einen neuen ESXi-Server aufzusetzen und die VM dorthin zu verfrachten. Auch das ging reibungslos über die Bühne. Die IP und der Servername blieben gleich,
Nur die MAC hat sich geändert, Netzwerk/Firewall angepasst? Was sagt das Ereignisprotokoll?ich habe einen Exchange 2013 auf einem Win2008r2 als VM auf VMWare Workstation v15 am Laufen. Es funktionierte alles sehr gut bis ich beschlossen habe, einen neuen ESXi-Server aufzusetzen und die VM dorthin zu verfrachten. Auch das ging reibungslos über die Bühne. Die IP und der Servername blieben gleich,
nur die meisten Exchange-Dienste wollen nicht automatisch starten.
Welche und warum nicht? Ereignisprotokoll?Hätte jemand einen Tipp?
Was steht so an Fehlern im Ereignisprotokoll?Gruß,
Peter
Danke für die Tipps. Im Ereignisprotokoll stehen lauter Zertifikatfehler. Das Problem war, die Zeiteinstellungen auf dem Server waren falsch Nach Korrektur läuft der Exchange 
Hi,
Bei komplett manueller Konfiguration der Zeit läufst Du Gefahr, dass das Problem in x Stunden/Tagen/Wochen wieder auftritt. Beobachte auch das Ereignisprotokoll in den nächsten Tagen, ob vielleicht Verbindungsfehler zum AD auftreten.
Zitat von @dbox3:
[...] Das Problem war, die Zeiteinstellungen auf dem Server waren falsch Nach Korrektur läuft der Exchange
Wie hast Du das korrigiert: manuell, Zeitserver oder Domänenzeit? Sind die VMWare-Tools vom ESXi in der VM installiert/aktualisiert? Ist ein Zeitserver im ESXi-Host konfiguriert und funktioniert der korrekt?[...] Das Problem war, die Zeiteinstellungen auf dem Server waren falsch Nach Korrektur läuft der Exchange
Bei komplett manueller Konfiguration der Zeit läufst Du Gefahr, dass das Problem in x Stunden/Tagen/Wochen wieder auftritt. Beobachte auch das Ereignisprotokoll in den nächsten Tagen, ob vielleicht Verbindungsfehler zum AD auftreten.
Habe die Zeit zuerst manuell eingestellt und im Anschluss den W32Time-Dienst über die Registry auf NT5DS konfiguriert. Der ESXi war tatsächlich für den NTP nicht konfiguriert. Das Problem mit den Diensten nach einem Neustart bleibt jedoch bestehen. Ich habe vorerst einen PS-Script für den schnelleren Start aufgesetzt, der Grund dafür bleibt unklar. Exchange ist auf der VM die einzige Rolle und der DC ist problemlos erreichbar. VMWare-Tools sind installiert.
Zitat von @dbox3:
Habe die Zeit zuerst manuell eingestellt und im Anschluss den W32Time-Dienst über die Registry auf NT5DS konfiguriert.
Kontrollier auch mal das Ereignisprotokoll (und nicht nur Fehler, auch Warnungen oder Informationen) direkt nach dem Neustart Quelle W32Time o.ä. - bekommt der Exchange auch seine Zeit von der Domäne? Was ist als qualifizierte Zeitquelle angegeben?Habe die Zeit zuerst manuell eingestellt und im Anschluss den W32Time-Dienst über die Registry auf NT5DS konfiguriert.
Sind die passenden VMWare-Tools installiert, was ich oben bereits gefragt hatte?
Der ESXi war tatsächlich für den NTP nicht konfiguriert.
Auch hier kontrollieren, ob der ESXi die korrekte Zeit hat.Das Problem mit den Diensten nach einem Neustart bleibt jedoch bestehen. Ich habe vorerst einen PS-Script für den schnelleren Start aufgesetzt, der Grund dafür bleibt unklar.
Wiederum müssen dann Ereignisse die Exchange Dienste betreffen im Log stehen, nur dort kommst Du dem ursächlichen Problem auf die Spur.Exchange ist auf der VM die einzige Rolle und der DC ist problemlos erreichbar. VMWare-Tools sind installiert.
"DC ist problemlos erreichbar" hast Du wie getestet? Ein ping ist bspw. nur die halbe Miete, wird außerdem das AD erreicht/angesprochen und kommt es eventuell dort zu Fehlern oder keine Rückmeldung oder er kann mit den Antworten nichts mehr anfangen. Der manuelle nachträgliche Start der Dienste hilft so nicht weiter, irgendwas passt da nicht und so läufst Du Gefahr, dass der Exchange irgendwann kaputt ist. Oder er schmiert Dir irgendwann im laufenden Betrieb ab. Gibt da viele mögliche Szenarien. Das muss - wie oben bereits geschrieben - auch nicht gleich und sofort passieren, über einen längeren Zeitraum häufen sich die Fehler und irgendwann ist dann Schluss.Wieviel RAM hast Du der VM denn spendiert und wieviele Postfächer hostet der Exchange?
Es gibt tatsächlich einige Fehlermeldungen im Ereignisprotokoll beim Start.
Die meisten sind MSExchange ADAccess ID 4027 und MSExchande Frontend Proxy ID 3002.
Außerdem WMI ID 10, MSExchange ADTopology ID 2805 und 1092, MSExchange Diagnostics ID 1012 und 1039.
Bin dabei, den DC zu testen, melde mich dann wieder.
Die meisten sind MSExchange ADAccess ID 4027 und MSExchande Frontend Proxy ID 3002.
Außerdem WMI ID 10, MSExchange ADTopology ID 2805 und 1092, MSExchange Diagnostics ID 1012 und 1039.
Bin dabei, den DC zu testen, melde mich dann wieder.
Der Exchange hostet ca. 30 Postfächer und hat 32 GB RAM.
Das sollte eher unkritisch sein, hätte ja sein können, dass er an der unteren Grenze konfiguriert ist.
In der Folge können dann die weiteren Dienste nicht starten und werfen weitere Fehler/Warnungen.
Als Gegenprobe kannst Du mal versuchen, ob Du Dich mit einem Benutzer am OWA anmelden kannst und auch sein Postfach geöffnet werden kann. Und auf jeden Fall auch mal ins Eventlog des DC schauen, was da vom Exchange aufläuft.
Die meisten sind MSExchange ADAccess ID 4027 und MSExchange Frontend Proxy ID 3002. [...] MSExchange ADTopology ID 2805 und 1092, MSExchange Diagnostics ID 1012 und 1039.
Die dürften alle miteinander zu tun haben. Im Event 4027 dürfte er in den Details sinngemäß bereits erwähnen "Kein geeigeneter Domänencontroller für Domäne <Deine Domäne> gefunden."In der Folge können dann die weiteren Dienste nicht starten und werfen weitere Fehler/Warnungen.
Als Gegenprobe kannst Du mal versuchen, ob Du Dich mit einem Benutzer am OWA anmelden kannst und auch sein Postfach geöffnet werden kann. Und auf jeden Fall auch mal ins Eventlog des DC schauen, was da vom Exchange aufläuft.
Auf dem DC scheint alles i.O. zu sein. DCDIAG problemlos, im Ereignisprotokoll keine Fehler. Gleich nach Start des Exchange wird der MSExchange Topology-Dienst automatisch beendet. Wenn ich den dann manuell starte, läuft die Kiste ohne Probleme. Was kann der Grund dafür sein?
Nach dem manuellen Start reagiert der Exchange wie gewohnt. Auch OWA und Outlook-Zugriffe ohne Fehlermeldungen.
Nach dem manuellen Start reagiert der Exchange wie gewohnt. Auch OWA und Outlook-Zugriffe ohne Fehlermeldungen.
Zitat von @dbox3:
Auf dem DC scheint alles i.O. zu sein. DCDIAG problemlos, im Ereignisprotokoll keine Fehler.
Die können sich auch durchaus auf dem DC nicht als Fehler/Warnung außern, sondern der DC nur eine Infromation liefern, dass da bspw. wer versucht hat, auf's AD zuzugreifen.Auf dem DC scheint alles i.O. zu sein. DCDIAG problemlos, im Ereignisprotokoll keine Fehler.
Gleich nach Start des Exchange wird der MSExchange Topology-Dienst automatisch beendet. Wenn ich den dann manuell starte, läuft die Kiste ohne Probleme. Was kann der Grund dafür sein?
Erneut: Schau in die Details des Fehlers und auch die vorher und nachher auflaufenden Fehler, Warnungen und Informationen. Alles durchforsten, nur so kommst Du auf eine stabile Lösung.Ggf. den Topology-Dienst mal auf verzögerten Start setzen. Oder schmieren nach Neustart noch mehr Dienste ab, die eigentlich auomatsich gestartet werden.
Welcher DNS ist in der Exchange-VM konfiguriert und ebenfalls nicht ganz unwichtig: Welcher Netzwerkkarten-Typ ist für die VM konfiguriert (vmxnet3 oder e1000)?
DNS ist nur der DC. Alle anderen Exchange-Dienste sind vom Topology-Dienst abhängig. Werde versuchen den DC neu zu starten. Geht aber erst heute Abend. Melde mich dann wieder. Vielen Dank!
Moin,
was gibt ein nslookup auf dem Exchange bezüglich des DCs aus?
Gruß
Maxblank
was gibt ein nslookup auf dem Exchange bezüglich des DCs aus?
Gruß
Maxblank
nslookup liefert die korrekte IP des DC zurück. Freigaben auf dem DC sind ebenfalls alle erreichbar. Auch der Neustart des DC hat nichts verändert. Der MSExchange Topology-Dienst will nicht automatisch starten bzw. wird nach dem Start automatisch beendet (EInstellung auf Verzögert automatisch hat nichts gebracht). Andere von ihm abhängige Dienste starten logischerweise auch nicht. Sonst keine Probleme bei automatisch startenden Diensten. In der Ereignisanzeige des DC sind keine suspekten Meldungen betr. Exchange zu finden. Vor dem Umzug lief alles auf VMWare Workstation ohne Probleme. Noch Ideen?
Moin...
das ist schon mal murks....
du musst zusehen das erst das AD geladen ist, dann die exchange dienste....
mein rat an dich, erstelle eine neue VM, ziehe den DC um, mit all seinen rollen, und dann den exchange ...
so wirst du dann auch den 2008er los...
Frank
Der MSExchange Topology-Dienst will nicht automatisch starten bzw. wird nach dem Start automatisch beendet (EInstellung auf Verzögert automatisch hat nichts gebracht).
der DC und der Exchange sind auf der gleichen VM?das ist schon mal murks....
du musst zusehen das erst das AD geladen ist, dann die exchange dienste....
mein rat an dich, erstelle eine neue VM, ziehe den DC um, mit all seinen rollen, und dann den exchange ...
so wirst du dann auch den 2008er los...
Frank
Jede Menge, wie oben bereits mehrfach angefragt:
- Details der Fehler im Eventlog von den Exchange Diensten bitte mal hier reinkopieren. Dort steht häufig bereits ein Lösungsansatz drin. Zumindest sieht man dann, was genau nicht funktioniert hat.
- Welcher virtuelle Adaptertyp ist in der Exchange-VM definiert (ebenfalls oben bereits angefragt)? Zusatz: gibt es eventuelle ausgeblendete Netzwerkadapter?
- VMWare-Tools vom ESXi installiert (mehrfach angefragt ...)?
- Events bezüglich Win32 Time
usw. usf.
Wir sehen nicht, was Du siehst und ohne weitere Infos kann man wenig weitere Tipps geben. Für deratige Probleme gibt es viele Ursachen und nicht nur eine pauschale Lösung. Häufig gibt es auch mehrere Baustellen, wo man nachsehen muss. Es könnte bspw. auch noch der Fall sein, dass der Exchange direkt nach Neustart immer noch eine falsche Uhrzeit hat, deswegen die Dienste nicht starten können und erst wenn er die korrekte Uhrzeit des DC hat, sich die Dienste starten lassen. Da spielen dann auch die Konfiguration der VMWare Tools in der VM eine Rolle, die ggf. Deine manuelle Konfig. überschreiben.
Hier gibt es u.a. weitere Informationen dazu: https://www.windowspro.de/thomas-drilling/ntp-zeitsynchronisation-vmware ...
- Details der Fehler im Eventlog von den Exchange Diensten bitte mal hier reinkopieren. Dort steht häufig bereits ein Lösungsansatz drin. Zumindest sieht man dann, was genau nicht funktioniert hat.
- Welcher virtuelle Adaptertyp ist in der Exchange-VM definiert (ebenfalls oben bereits angefragt)? Zusatz: gibt es eventuelle ausgeblendete Netzwerkadapter?
- VMWare-Tools vom ESXi installiert (mehrfach angefragt ...)?
- Events bezüglich Win32 Time
usw. usf.
Wir sehen nicht, was Du siehst und ohne weitere Infos kann man wenig weitere Tipps geben. Für deratige Probleme gibt es viele Ursachen und nicht nur eine pauschale Lösung. Häufig gibt es auch mehrere Baustellen, wo man nachsehen muss. Es könnte bspw. auch noch der Fall sein, dass der Exchange direkt nach Neustart immer noch eine falsche Uhrzeit hat, deswegen die Dienste nicht starten können und erst wenn er die korrekte Uhrzeit des DC hat, sich die Dienste starten lassen. Da spielen dann auch die Konfiguration der VMWare Tools in der VM eine Rolle, die ggf. Deine manuelle Konfig. überschreiben.
Hier gibt es u.a. weitere Informationen dazu: https://www.windowspro.de/thomas-drilling/ntp-zeitsynchronisation-vmware ...
Hallo,
Durch dein Wiederholen von "es geht nicht", wird dein Exchange nicht wieder heile, das ist nur ein Märchen.
Und wenn wir dir helfen sollen bzw können, brauchen wir hier als Blinde und Taube nutzer einfach Information, und die kann nur von dir kommen.
Gruß,
Peter
Zitat von @dbox3:
In der Ereignisanzeige des DC sind keine suspekten Meldungen betr. Exchange zu finden.
Dort findest du nur etwas wenn dein Exchange auf deinen DC läuft und das wäre nicht gut. Schau also im ereignisprotokoll des Exchange Servers rein. Da wirst du fündig.In der Ereignisanzeige des DC sind keine suspekten Meldungen betr. Exchange zu finden.
Vor dem Umzug lief alles auf VMWare Workstation ohne Probleme.
Dann hast du beim Umzug etwas geändert oder falsch gemacht.Noch Ideen?
Du etwa nicht?Durch dein Wiederholen von "es geht nicht", wird dein Exchange nicht wieder heile, das ist nur ein Märchen.
Und wenn wir dir helfen sollen bzw können, brauchen wir hier als Blinde und Taube nutzer einfach Information, und die kann nur von dir kommen.
Gruß,
Peter
Hallo nochmal. Bin gerade wieder zurückgekommen und die Kommentare gelesen. Hier die Details zu den beiden Fehlern bei Neustart des Exchange:
MSExchange ADAccess Ereignis-ID 4027:
Prozess w3wp.exe (FE_RpcHttp) (PID=4072). Fehler bei der WCF-Anforderung (Get Servers for firma.local) an den Microsoft Exchange Active Directory-Topologiedienst auf Server (TopologyClientTcpEndpoint (localhost)). Stellen Sie sicher, dass der Dienst ausgeführt wird. Stellen Sie außerdem sicher, dass die vom Microsoft Exchange Active Directory-Topologiedienst verwendeten Netzwerkports nicht durch eine Firewall blockiert werden. Der WCF-Aufruf wurde 3 Mal wiederholt. Fehlerdetails
System.ServiceModel.EndpointNotFoundException: Es konnte keine Verbindung mit "net.tcp://localhost:890/Microsoft.Exchange.Directory.TopologyService" hergestellt werden. Der Verbindungsversuch hat für einen Zeitraum von 00:00:02.0280130 angedauert. TCP-Fehlercode 10061: Es konnte keine Verbindung hergestellt werden, da der Zielcomputer die Verbindung verweigerte 127.0.0.1:890. ---> System.Net.Sockets.SocketException: Es konnte keine Verbindung hergestellt werden, da der Zielcomputer die Verbindung verweigerte 127.0.0.1:890
bei System.Net.Sockets.Socket.DoConnect(EndPoint endPointSnapshot, SocketAddress socketAddress)
bei System.Net.Sockets.Socket.Connect(EndPoint remoteEP)
bei System.ServiceModel.Channels.SocketConnectionInitiator.Connect(Uri uri, TimeSpan timeout)
--- Ende der internen Ausnahmestapelüberwachung ---
Server stack trace:
bei System.ServiceModel.Channels.SocketConnectionInitiator.Connect(Uri uri, TimeSpan timeout)
bei System.ServiceModel.Channels.BufferedConnectionInitiator.Connect(Uri uri, TimeSpan timeout)
bei System.ServiceModel.Channels.ConnectionPoolHelper.EstablishConnection(TimeSpan timeout)
bei System.ServiceModel.Channels.ClientFramingDuplexSessionChannel.OnOpen(TimeSpan timeout)
bei System.ServiceModel.Channels.CommunicationObject.Open(TimeSpan timeout)
bei System.ServiceModel.Channels.ServiceChannel.OnOpen(TimeSpan timeout)
bei System.ServiceModel.Channels.CommunicationObject.Open(TimeSpan timeout)
Exception rethrown at :
bei System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage reqMsg, IMessage retMsg)
bei System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type)
bei System.ServiceModel.ICommunicationObject.Open()
bei Microsoft.Exchange.Net.ServiceProxyPool`1.GetClient(Int32 retry, Boolean& doNotReturnProxyAfterRetry, Boolean useCache)
bei Microsoft.Exchange.Net.ServiceProxyPool`1.TryCallServiceWithRetry(Action`1 action, String debugMessage, WCFConnectionStateTuple proxyToUse, Int32 numberOfRetries, Boolean doNotReturnProxyOnSuccess, Exception& exception)
MSExchange Front End HTTP-Proxy Ereignis-ID 3002:
[Autodiscover] Failed to refresh ClientAccess 2010 server map. The exception was: Microsoft.Exchange.Data.Directory.ADTopologyEndpointNotFoundException: Der Microsoft Exchange Active Directory-Topologiedienst wurde vom Topologieanbieter nicht auf dem Endpunkt 'TopologyClientTcpEndpoint (localhost)' gefunden.
bei Microsoft.Exchange.Data.Directory.ServiceTopologyProvider.GetConfigDCInfo(String partitionFqdn, Boolean throwOnFailure)
bei Microsoft.Exchange.Data.Directory.TopologyProvider.PopulateConfigNamingContexts(String partitionFqdn)
bei Microsoft.Exchange.Data.Directory.TopologyProvider.GetConfigurationNamingContext(String partitionFqdn)
bei Microsoft.Exchange.Data.Directory.ADDataSession.GetNamingContext(ADNamingContext adNamingContext)
bei Microsoft.Exchange.Data.Directory.ADDataSession.GetConnection(String preferredServer, Boolean isWriteOperation, String optionalBaseDN, ADObjectId& rootId, ADScope scope)
bei Microsoft.Exchange.Data.Directory.ADDataSession.GetReadConnection(String preferredServer, String optionalBaseDN, ADObjectId& rootId, ADRawEntry scopeDeteriminingObject)
bei Microsoft.Exchange.Data.Directory.ADGenericReader.GetNextResultCollection(Type controlType, DirectoryControl& responseControl)
bei Microsoft.Exchange.Data.Directory.ADPagedReader`1.GetNextResultCollection()
bei Microsoft.Exchange.Data.Directory.ADGenericPagedReader`1.GetNextPage()
bei Microsoft.Exchange.Data.Directory.ADGenericPagedReader`1.<GetEnumerator>d__0.MoveNext()
bei Microsoft.Exchange.Data.Directory.ADGenericPagedReader`1.ReadAllPages()
bei Microsoft.Exchange.HttpProxy.DownLevelServerManager.InternalRefresh()
- Exchange läuft nicht auf dem DC (lief ursprünglich auf der VMWare Workstation v15 auf dem DC als VM) und der DC ist auch online während Exchange startet.
- VMWare-Tools sind installiert und auf dem neuesten Stand
- Der Umzug habe ich direkt von der Workstation den Punkt aus dem Kontextmenü Manage -> Upload durchgeführt: lief ohne Fehlermeldungen.
- Bzgl. W32Time gab es zu Beginn eine Fehlermeldung zu der großen Zeitdifferenz. Nach der manuellen Anpassung und anschließender Änderung in der Registry auf NT5DS keine Fehlermeldungen mehr.
- Die Zeiteinstellung auf dem ESXi habe ich ebenfalls überprüft. Die Zeitzone lässt sich über den Web-Client nicht ändern, die angezeigte UTC-Zeit ist korrekt.
- Adaptertyp auf der VM ist E1000
Gruß
Arkadi
MSExchange ADAccess Ereignis-ID 4027:
Prozess w3wp.exe (FE_RpcHttp) (PID=4072). Fehler bei der WCF-Anforderung (Get Servers for firma.local) an den Microsoft Exchange Active Directory-Topologiedienst auf Server (TopologyClientTcpEndpoint (localhost)). Stellen Sie sicher, dass der Dienst ausgeführt wird. Stellen Sie außerdem sicher, dass die vom Microsoft Exchange Active Directory-Topologiedienst verwendeten Netzwerkports nicht durch eine Firewall blockiert werden. Der WCF-Aufruf wurde 3 Mal wiederholt. Fehlerdetails
System.ServiceModel.EndpointNotFoundException: Es konnte keine Verbindung mit "net.tcp://localhost:890/Microsoft.Exchange.Directory.TopologyService" hergestellt werden. Der Verbindungsversuch hat für einen Zeitraum von 00:00:02.0280130 angedauert. TCP-Fehlercode 10061: Es konnte keine Verbindung hergestellt werden, da der Zielcomputer die Verbindung verweigerte 127.0.0.1:890. ---> System.Net.Sockets.SocketException: Es konnte keine Verbindung hergestellt werden, da der Zielcomputer die Verbindung verweigerte 127.0.0.1:890
bei System.Net.Sockets.Socket.DoConnect(EndPoint endPointSnapshot, SocketAddress socketAddress)
bei System.Net.Sockets.Socket.Connect(EndPoint remoteEP)
bei System.ServiceModel.Channels.SocketConnectionInitiator.Connect(Uri uri, TimeSpan timeout)
--- Ende der internen Ausnahmestapelüberwachung ---
Server stack trace:
bei System.ServiceModel.Channels.SocketConnectionInitiator.Connect(Uri uri, TimeSpan timeout)
bei System.ServiceModel.Channels.BufferedConnectionInitiator.Connect(Uri uri, TimeSpan timeout)
bei System.ServiceModel.Channels.ConnectionPoolHelper.EstablishConnection(TimeSpan timeout)
bei System.ServiceModel.Channels.ClientFramingDuplexSessionChannel.OnOpen(TimeSpan timeout)
bei System.ServiceModel.Channels.CommunicationObject.Open(TimeSpan timeout)
bei System.ServiceModel.Channels.ServiceChannel.OnOpen(TimeSpan timeout)
bei System.ServiceModel.Channels.CommunicationObject.Open(TimeSpan timeout)
Exception rethrown at :
bei System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage reqMsg, IMessage retMsg)
bei System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type)
bei System.ServiceModel.ICommunicationObject.Open()
bei Microsoft.Exchange.Net.ServiceProxyPool`1.GetClient(Int32 retry, Boolean& doNotReturnProxyAfterRetry, Boolean useCache)
bei Microsoft.Exchange.Net.ServiceProxyPool`1.TryCallServiceWithRetry(Action`1 action, String debugMessage, WCFConnectionStateTuple proxyToUse, Int32 numberOfRetries, Boolean doNotReturnProxyOnSuccess, Exception& exception)
MSExchange Front End HTTP-Proxy Ereignis-ID 3002:
[Autodiscover] Failed to refresh ClientAccess 2010 server map. The exception was: Microsoft.Exchange.Data.Directory.ADTopologyEndpointNotFoundException: Der Microsoft Exchange Active Directory-Topologiedienst wurde vom Topologieanbieter nicht auf dem Endpunkt 'TopologyClientTcpEndpoint (localhost)' gefunden.
bei Microsoft.Exchange.Data.Directory.ServiceTopologyProvider.GetConfigDCInfo(String partitionFqdn, Boolean throwOnFailure)
bei Microsoft.Exchange.Data.Directory.TopologyProvider.PopulateConfigNamingContexts(String partitionFqdn)
bei Microsoft.Exchange.Data.Directory.TopologyProvider.GetConfigurationNamingContext(String partitionFqdn)
bei Microsoft.Exchange.Data.Directory.ADDataSession.GetNamingContext(ADNamingContext adNamingContext)
bei Microsoft.Exchange.Data.Directory.ADDataSession.GetConnection(String preferredServer, Boolean isWriteOperation, String optionalBaseDN, ADObjectId& rootId, ADScope scope)
bei Microsoft.Exchange.Data.Directory.ADDataSession.GetReadConnection(String preferredServer, String optionalBaseDN, ADObjectId& rootId, ADRawEntry scopeDeteriminingObject)
bei Microsoft.Exchange.Data.Directory.ADGenericReader.GetNextResultCollection(Type controlType, DirectoryControl& responseControl)
bei Microsoft.Exchange.Data.Directory.ADPagedReader`1.GetNextResultCollection()
bei Microsoft.Exchange.Data.Directory.ADGenericPagedReader`1.GetNextPage()
bei Microsoft.Exchange.Data.Directory.ADGenericPagedReader`1.<GetEnumerator>d__0.MoveNext()
bei Microsoft.Exchange.Data.Directory.ADGenericPagedReader`1.ReadAllPages()
bei Microsoft.Exchange.HttpProxy.DownLevelServerManager.InternalRefresh()
- Exchange läuft nicht auf dem DC (lief ursprünglich auf der VMWare Workstation v15 auf dem DC als VM) und der DC ist auch online während Exchange startet.
- VMWare-Tools sind installiert und auf dem neuesten Stand
- Der Umzug habe ich direkt von der Workstation den Punkt aus dem Kontextmenü Manage -> Upload durchgeführt: lief ohne Fehlermeldungen.
- Bzgl. W32Time gab es zu Beginn eine Fehlermeldung zu der großen Zeitdifferenz. Nach der manuellen Anpassung und anschließender Änderung in der Registry auf NT5DS keine Fehlermeldungen mehr.
- Die Zeiteinstellung auf dem ESXi habe ich ebenfalls überprüft. Die Zeitzone lässt sich über den Web-Client nicht ändern, die angezeigte UTC-Zeit ist korrekt.
- Adaptertyp auf der VM ist E1000
Gruß
Arkadi
Hi,
Frage vorab: Wie war das Netzwerk konfiguriert, als die VM noch auf dem DC lief? Bridged, NAT oder 'Host only'?
(Mal ein wenig gekürzt) Überprüf mal auf dem DC in Active Directory Standorte und Dienste (Sites and Services), ob dort alles korrekt ist. Existiert das Subnetz des Exchange.
Zusätzlich mal schauen, ob im IIS auf dem Exchnage alles in Ordnung ist, insbesondere in Bezug auf die Zertifikate.
MSExchange Front End HTTP-Proxy Ereignis-ID 3002:
[Autodiscover] Failed to refresh ClientAccess 2010 server map. The exception was: Microsoft.Exchange.Data.Directory.ADTopologyEndpointNotFoundException: Der Microsoft Exchange Active Directory-Topologiedienst wurde vom Topologieanbieter nicht auf dem Endpunkt 'TopologyClientTcpEndpoint (localhost)' gefunden.
(Ebenfalls gekürzt) Teste mal auf dem Exchange in einer Admin-Kommandozeile die Ausgabe von:
Da müsste der DC zurückgeliefert werden inkl. ein paar Zusatzinformationen. Ggf. ist die Vetrauensstellung beim Umzug verlorengegangen.
Welche ESXi-Version setzt Du überhaupt ein?
Gruß
cykes
Frage vorab: Wie war das Netzwerk konfiguriert, als die VM noch auf dem DC lief? Bridged, NAT oder 'Host only'?
Zitat von @dbox3:
MSExchange ADAccess Ereignis-ID 4027:
Prozess w3wp.exe (FE_RpcHttp) (PID=4072). Fehler bei der WCF-Anforderung (Get Servers for firma.local) an den Microsoft Exchange Active Directory-Topologiedienst auf Server (TopologyClientTcpEndpoint (localhost)). Stellen Sie sicher, dass der Dienst ausgeführt wird. Stellen Sie außerdem sicher, dass die vom Microsoft Exchange Active Directory-Topologiedienst verwendeten Netzwerkports nicht durch eine Firewall blockiert werden. Der WCF-Aufruf wurde 3 Mal wiederholt. Fehlerdetails
MSExchange ADAccess Ereignis-ID 4027:
Prozess w3wp.exe (FE_RpcHttp) (PID=4072). Fehler bei der WCF-Anforderung (Get Servers for firma.local) an den Microsoft Exchange Active Directory-Topologiedienst auf Server (TopologyClientTcpEndpoint (localhost)). Stellen Sie sicher, dass der Dienst ausgeführt wird. Stellen Sie außerdem sicher, dass die vom Microsoft Exchange Active Directory-Topologiedienst verwendeten Netzwerkports nicht durch eine Firewall blockiert werden. Der WCF-Aufruf wurde 3 Mal wiederholt. Fehlerdetails
(Mal ein wenig gekürzt) Überprüf mal auf dem DC in Active Directory Standorte und Dienste (Sites and Services), ob dort alles korrekt ist. Existiert das Subnetz des Exchange.
Zusätzlich mal schauen, ob im IIS auf dem Exchnage alles in Ordnung ist, insbesondere in Bezug auf die Zertifikate.
MSExchange Front End HTTP-Proxy Ereignis-ID 3002:
[Autodiscover] Failed to refresh ClientAccess 2010 server map. The exception was: Microsoft.Exchange.Data.Directory.ADTopologyEndpointNotFoundException: Der Microsoft Exchange Active Directory-Topologiedienst wurde vom Topologieanbieter nicht auf dem Endpunkt 'TopologyClientTcpEndpoint (localhost)' gefunden.
(Ebenfalls gekürzt) Teste mal auf dem Exchange in einer Admin-Kommandozeile die Ausgabe von:
nltest /dsgetsite- Bzgl. W32Time gab es zu Beginn eine Fehlermeldung zu der großen Zeitdifferenz. Nach der manuellen Anpassung und anschließender Änderung in der Registry auf NT5DS keine Fehlermeldungen mehr.
- Die Zeiteinstellung auf dem ESXi habe ich ebenfalls überprüft. Die Zeitzone lässt sich über den Web-Client nicht ändern, die angezeigte UTC-Zeit ist korrekt.
Trotzdem auch mal auf Informatioen und Warnungen und nicht nur Fehler-Ereignisse achten direkt nach dem Neustart. Es wäre durchaus möglich, dass (kurzzeitig) via der VMware-Tools die Zeit mit dem ESXi-Host synchronisiert wird.- Die Zeiteinstellung auf dem ESXi habe ich ebenfalls überprüft. Die Zeitzone lässt sich über den Web-Client nicht ändern, die angezeigte UTC-Zeit ist korrekt.
Welche ESXi-Version setzt Du überhaupt ein?
- VMWare-Tools sind installiert und auf dem neuesten Stand
- Adaptertyp auf der VM ist E1000
E1000 oder E1000e? Trotzdem ggf. mal probieren, auf VMXNET3 umzustellen, aber die einschlägigen Hinweise dabei beachten. Nicht einfach so umstellen!- Adaptertyp auf der VM ist E1000
Gruß
cykes
Hallo cykes, zu der Vorabfrage:
- das Netzwerk der VM vor dem Umzug auf dem DC war als Bridged konfiguriert.
- der Order Subnets im AD Standorte und Dienste ist leer. Soll ich dort etwas eintragen?
- Zertifikate im IIS sind alle gültig. Gelegentlich erhalte ich Fehlermeldungen vom Outlook wegen fehlendem Zertifikat für den lokalen Server. Zertifikat ist von Let's Encrypt für die externe URL und ich habe Split-DNS eingerichtet. In der Ereignisanzeige des Exchange habe ich noch den Fehler ID 12014:
Microsoft Exchange konnte ein Zertifikat nicht finden, das den Domänennamen "srv.firma.local" im persönlichen Informationsspeicher auf dem lokalen Computer enthält.
- nltest /dsgetsite auf dem Exchange liefert nur den Standortnamen und keine weiteren Informationen.
- ESXi-Version ist 6.7U2
- Adapter der VM ist E1000. Habe jetzt auf VMXNET3 geändert: nach dem Neustart war der Server zunächst nicht anpingbar, da die EInstellungen auf automatisch geändert wurden. Habe die Einstellungen wieder angepasst: läuft, Dienste starten trotzdem nicht automatisch.
Gruß
dbox3
- das Netzwerk der VM vor dem Umzug auf dem DC war als Bridged konfiguriert.
- der Order Subnets im AD Standorte und Dienste ist leer. Soll ich dort etwas eintragen?
- Zertifikate im IIS sind alle gültig. Gelegentlich erhalte ich Fehlermeldungen vom Outlook wegen fehlendem Zertifikat für den lokalen Server. Zertifikat ist von Let's Encrypt für die externe URL und ich habe Split-DNS eingerichtet. In der Ereignisanzeige des Exchange habe ich noch den Fehler ID 12014:
Microsoft Exchange konnte ein Zertifikat nicht finden, das den Domänennamen "srv.firma.local" im persönlichen Informationsspeicher auf dem lokalen Computer enthält.
- nltest /dsgetsite auf dem Exchange liefert nur den Standortnamen und keine weiteren Informationen.
- ESXi-Version ist 6.7U2
- Adapter der VM ist E1000. Habe jetzt auf VMXNET3 geändert: nach dem Neustart war der Server zunächst nicht anpingbar, da die EInstellungen auf automatisch geändert wurden. Habe die Einstellungen wieder angepasst: läuft, Dienste starten trotzdem nicht automatisch.
Gruß
dbox3
Den Fehler für Outlook-Meldungen habe ich anscheinend gefunden: die URL für autodiscover war nicht konfiguriert.
Hallo,
Was denn nun?
Gruß,
Peter
Zitat von @dbox3:
Den Fehler für Outlook-Meldungen habe ich anscheinend gefunden: die URL für autodiscover war nicht konfiguriert.
Ein nicht deklarierter Autodiscover schadet bzw. hindert keinen Exchange, und auch Outlook bis 2013 kommt sehr gut ohne einen Autodiscover aus. Nur einen falschen Wert für autodicover wird einen Outlook stören. Nur das Outlook kein Exchange ist und ein Exchange kein Outlook ist. außerdem sagtest du am 14.09.2018Den Fehler für Outlook-Meldungen habe ich anscheinend gefunden: die URL für autodiscover war nicht konfiguriert.
Auch OWA und Outlook-Zugriffe ohne Fehlermeldungen
Gruß,
Peter
Stimmt auch. Im Fehlerprotokoll sind keine Fehler vorhanden. Nur der Outlook 2013 von Zuhause (Verbindung über VPN zum Firmennetzwerk hat selten wiederholt Anfragen nach den Zugangsdaten angezeigt, die er anscheinend nicht speichern/akzeptieren wollte. Anch einem Neustart von Outlook mekkerte er aber meistens nicht mehr. Vllt. war auch Kaspersky an diesen Störungen beteiligt. Jedenfalls hat Outlook im internen Netz nicht gemeckert.
