2
Exchange 2010 Trasnportdienst wird nicht gestartet bzw. deaktiviert sich nach Start wieder
Auf einem SBS 2011 (2008R2) kann der Exchange Transportdienst nicht gestartet werden, da Exchange noch Teile von Trendmicro erkennt die nicht mehr da sind.
TrendMicro wurde komplett deinstalliert und es bleiben wohl noch Einstellungsresistenten in Exchange.
So kommt es zu folgenden Fehlermedungen:
- System
- Provider
[ Name] MSExchange Extensibility
- EventID 1052
[ Qualifiers] 49156
Level 2
Task 1
Keywords 0x80000000000000
- TimeCreated
[ SystemTime] 2020-04-24T18:24:20.000000000Z
EventRecordID 9483008
Channel Application
Computer W2K11SV1.hpp.local
Security
- EventData
ScanMail SMTP Receive Agent
Fehler beim Erstellen des Typs 'TrendMicro.SMEX.hookE12TransportAgent.hookE12SmtpReceiveAgentFactory' aus Assembly 'C:\Program Files\Trend Micro\Messaging Security Agent\hookE12TransportAgent.dll' aufgrund von Fehler 'Ungültiger Agent-Assemblypfad.'.
und
- System
- Provider
[ Name] MSExchangeTransport
- EventID 16023
[ Qualifiers] 49156
Level 2
Task 16
Keywords 0x80000000000000
- TimeCreated
[ SystemTime] 2020-04-24T18:24:20.000000000Z
EventRecordID 9483009
Channel Application
Computer W2K11SV1.hpp.local
Security
- EventData
Fehler beim Erstellen des Typs 'TrendMicro.SMEX.hookE12TransportAgent.hookE12SmtpReceiveAgentFactory' aus Assembly 'C:\Program Files\Trend Micro\Messaging Security Agent\hookE12TransportAgent.dll' aufgrund von Fehler 'Ungültiger Agent-Assemblypfad.'.
Microsoft.Exchange.Data.ExchangeConfigurationException: Fehler beim Erstellen des Typs 'TrendMicro.SMEX.hookE12TransportAgent.hookE12SmtpReceiveAgentFactory' aus Assembly 'C:\Program Files\Trend Micro\Messaging Security Agent\hookE12TransportAgent.dll' aufgrund von Fehler 'Ungültiger Agent-Assemblypfad.'. ---> System.ArgumentException: Ungültiger Agent-Assemblypfad. --- Ende der internen Ausnahmestapelüberwachung --- bei Microsoft.Exchange.Data.Transport.Internal.MExRuntime.FactoryTable.CreateAgentFactory(AgentInfo agentInfo) bei Microsoft.Exchange.Data.Transport.Internal.MExRuntime.FactoryTable..ctor(IEnumerable agents) bei Microsoft.Exchange.Data.Transport.Internal.MExRuntime.RuntimeSettings..ctor(MExConfiguration config, String agentGroup) bei Microsoft.Exchange.Data.Transport.Internal.MExRuntime.MExRuntime.Initialize(String configFile, String agentGroup, Boolean isBridgeHead, String installPath) bei Microsoft.Exchange.Transport.Extensibility.AgentComponent.Load()
Der folgende Link brachte mich nicht weiter, das zumindest die Ordner und Inhalte nicht mehr auf der Festplatte vorhanden sind, auch die Registry schon bereinigt wurde:
success.trendmicro.com/solution/1097474-unable-to-start-exchange-transport-service-after-uninstalling-scanmail-for-exchange-smex-or-messag
Kennt jemand das Problem oder hat einen Lösungsansatz?
LG.
Dirk Müller
TrendMicro wurde komplett deinstalliert und es bleiben wohl noch Einstellungsresistenten in Exchange.
So kommt es zu folgenden Fehlermedungen:
- System
- Provider
[ Name] MSExchange Extensibility
- EventID 1052
[ Qualifiers] 49156
Level 2
Task 1
Keywords 0x80000000000000
- TimeCreated
[ SystemTime] 2020-04-24T18:24:20.000000000Z
EventRecordID 9483008
Channel Application
Computer W2K11SV1.hpp.local
Security
- EventData
ScanMail SMTP Receive Agent
Fehler beim Erstellen des Typs 'TrendMicro.SMEX.hookE12TransportAgent.hookE12SmtpReceiveAgentFactory' aus Assembly 'C:\Program Files\Trend Micro\Messaging Security Agent\hookE12TransportAgent.dll' aufgrund von Fehler 'Ungültiger Agent-Assemblypfad.'.
und
- System
- Provider
[ Name] MSExchangeTransport
- EventID 16023
[ Qualifiers] 49156
Level 2
Task 16
Keywords 0x80000000000000
- TimeCreated
[ SystemTime] 2020-04-24T18:24:20.000000000Z
EventRecordID 9483009
Channel Application
Computer W2K11SV1.hpp.local
Security
- EventData
Fehler beim Erstellen des Typs 'TrendMicro.SMEX.hookE12TransportAgent.hookE12SmtpReceiveAgentFactory' aus Assembly 'C:\Program Files\Trend Micro\Messaging Security Agent\hookE12TransportAgent.dll' aufgrund von Fehler 'Ungültiger Agent-Assemblypfad.'.
Microsoft.Exchange.Data.ExchangeConfigurationException: Fehler beim Erstellen des Typs 'TrendMicro.SMEX.hookE12TransportAgent.hookE12SmtpReceiveAgentFactory' aus Assembly 'C:\Program Files\Trend Micro\Messaging Security Agent\hookE12TransportAgent.dll' aufgrund von Fehler 'Ungültiger Agent-Assemblypfad.'. ---> System.ArgumentException: Ungültiger Agent-Assemblypfad. --- Ende der internen Ausnahmestapelüberwachung --- bei Microsoft.Exchange.Data.Transport.Internal.MExRuntime.FactoryTable.CreateAgentFactory(AgentInfo agentInfo) bei Microsoft.Exchange.Data.Transport.Internal.MExRuntime.FactoryTable..ctor(IEnumerable agents) bei Microsoft.Exchange.Data.Transport.Internal.MExRuntime.RuntimeSettings..ctor(MExConfiguration config, String agentGroup) bei Microsoft.Exchange.Data.Transport.Internal.MExRuntime.MExRuntime.Initialize(String configFile, String agentGroup, Boolean isBridgeHead, String installPath) bei Microsoft.Exchange.Transport.Extensibility.AgentComponent.Load()
Der folgende Link brachte mich nicht weiter, das zumindest die Ordner und Inhalte nicht mehr auf der Festplatte vorhanden sind, auch die Registry schon bereinigt wurde:
success.trendmicro.com/solution/1097474-unable-to-start-exchange-transport-service-after-uninstalling-scanmail-for-exchange-smex-or-messag
Kennt jemand das Problem oder hat einen Lösungsansatz?
LG.
Dirk Müller
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 567257
Url: https://administrator.de/contentid/567257
Ausgedruckt am: 22.11.2024 um 05:11 Uhr
2 Kommentare
Neuester Kommentar
Hi
deaktiviere die Transportagents mal. Der versucht die noch zu starten findet aber deren dlls nicht.
Get-TransportAgent &
Disable-TransportAgent
deaktiviere die Transportagents mal. Der versucht die noch zu starten findet aber deren dlls nicht.
Get-TransportAgent &
Disable-TransportAgent
Der obige von mir gepostete Link hat doch noch funktioniert.
Da ich übernächtigt war mit Datenbankreperatur, Updates und mehr, hatte ich nicht gelesen, dass die Exchange-Powershell zu öffnen ist um die Befehle auszuschießen und habe die normale Powershell verwendet, die natürlich nichts gefunden hat.
Nun nach dem ich der Anweisung aus dem Link gefolgt bin, startet der einst wieder und es läuft besser als je zuvor.
Seit Wochen kam es zu Fehlern, Mails gingen verzögert raus und nur nach Beendigung von Outlook oder über "Senden und Empfange" bzw. über F9, rein bzw. raus. Auf einigen Clients ging es Teils noch recht gut und auf anderen ging oft gar nichts.
So war ich etwas fehlgeleitet und hatte vielseits nach Fehlern gesucht, bis ich die Datenbank des Server getestet habe und diese als Fehlerhaft angezeigt wurde. So habe ich eine Naht bis eben verbracht. Es wurden Updates installiert, die Viren- / Sicherheitslösung deinstalliert und erneuert und die Datenbank repariert.
Die Reparatur dauerte schon ein paar Stunden, da die Datenbank rund 300 GB groß ist.
Nun stellt sich die Frage, warum eine Datenbank die mit "eseutil /p" repariert wurde, nicht wieder in Einsatz gebracht werden sollte, wieso diese schnellstens ersetzt werden soll.
Das Problem scheint nun aber gelöst.
Da ich übernächtigt war mit Datenbankreperatur, Updates und mehr, hatte ich nicht gelesen, dass die Exchange-Powershell zu öffnen ist um die Befehle auszuschießen und habe die normale Powershell verwendet, die natürlich nichts gefunden hat.
Nun nach dem ich der Anweisung aus dem Link gefolgt bin, startet der einst wieder und es läuft besser als je zuvor.
Seit Wochen kam es zu Fehlern, Mails gingen verzögert raus und nur nach Beendigung von Outlook oder über "Senden und Empfange" bzw. über F9, rein bzw. raus. Auf einigen Clients ging es Teils noch recht gut und auf anderen ging oft gar nichts.
So war ich etwas fehlgeleitet und hatte vielseits nach Fehlern gesucht, bis ich die Datenbank des Server getestet habe und diese als Fehlerhaft angezeigt wurde. So habe ich eine Naht bis eben verbracht. Es wurden Updates installiert, die Viren- / Sicherheitslösung deinstalliert und erneuert und die Datenbank repariert.
Die Reparatur dauerte schon ein paar Stunden, da die Datenbank rund 300 GB groß ist.
Nun stellt sich die Frage, warum eine Datenbank die mit "eseutil /p" repariert wurde, nicht wieder in Einsatz gebracht werden sollte, wieso diese schnellstens ersetzt werden soll.
Das Problem scheint nun aber gelöst.
