exchange 2016 + 5.4.1 RSS Back to forum
Hello Christopher,
Whenever you uninstall a transport agent, the Microsoft Exchange Transport service must be restarted as well in order to apply the new settings. To do this, start the Exchange Management Shell (EMS) and run the following command: "Restart-Service MSExchangeTransport"
Furthermore, please verify that the removal of the "Vamsoft ORF SMTP Receive Agent" and the "Vamsoft ORF Routing Agent" was successful by checking the list of installed Transport Agents: Issue the following command from the EMS: "Get-TransportAgent".
Should the issue persist after restarting the Exchange Transport service, try restarting the affected Exchange server.
In addition to the above, I would recommend reviewing the SMTP Protocol Logs of Exchange to see where the email transmission fails (If protocol logging is not enabled on your mail server, you will need to enable it first: https://technet.microsoft.com/en-us/library/bb124531). There is an excellent article on exchangeserverpro.com on how to utilize protocol logging for troubleshooting email delivery issues, in case you need instructions: http://exchangeserverpro.com/exchange-server-protocol-logging/
Please let me know if this has helped.
[PS] C:\Windows\system32>Get-TransportAgent
Identity Enabled Priority
-------- ------- --------
Transport Rule Agent True 1
DLP Policy Agent True 2
Retention Policy Agent True 3
Malware Agent True 4
Text Messaging Routing Agent True 5
Text Messaging Delivery Agent True 6
System Probe Drop Smtp Agent True 7
System Probe Drop Routing Agent True 8
---
[PS] C:\Windows\system32>Test-Mailflow
RunspaceId : 52d6eb52-6b67-4eee-b58c-ccd88c77750e
TestMailflowResult : Success
MessageLatencyTime : 00:00:01.2740305
IsRemoteTest : False
Identity :
IsValid : True
ObjectState : New
[PS] C:\Windows\system32>Test-Mailflow -TargetEmailAddress
RunspaceId : 52d6eb52-6b67-4eee-b58c-ccd88c77750e
TestMailflowResult : *FAILURE*
MessageLatencyTime : 00:00:00
IsRemoteTest : True
Identity :
IsValid : True
ObjectState : New
test2 exists on the exchange2016 server itself
[PS] C:\Windows\system32>Get-ReceiveConnector | select MaxAcknowledgementDelay,tarpitinterval , name, bindings
MaxAcknowledgementDelay TarpitInterval Name Bindings
----------------------- -------------- ---- --------
00:00:00 00:00:00 Default EXCHANGE2010 {0.0.0.0:25}
00:00:00 00:00:00 Client EXCHANGE2010 {0.0.0.0:587}
00:00:30 00:00:00 From Internal Devices {0.0.0.0:25}
00:00:30 00:00:05 Hi Track Copier netbotz {0.0.0.0:25}
00:00:30 00:00:05 Default INSIGHT-EXC-01 {0.0.0.0:2525, [::]:2525}
00:00:30 00:00:05 Client Proxy INSIGHT-EXC-01 {[::]:465, 0.0.0.0:465}
00:00:30 00:00:05 Default Frontend INSIGHT-EXC-01 {[::]:25, 0.0.0.0:25}
00:00:30 00:00:00 Outbound Proxy Frontend INSIGHT-EXC-01 {[::]:717, 0.0.0.0:717}
00:00:30 00:00:05 Client Frontend INSIGHT-EXC-01 {[::]:587, 0.0.0.0:587}
00:00:30 00:00:05 Hi Track Copier netbotz {0.0.0.0:25}
00:00:30 00:00:05 From Internal Devices {0.0.0.0:25}
If the ORF Tranport Agents are uninstalled and you have restarted the Exchange Transport service as well, ORF has no way to affect the delivery of incoming emails on your Exchange server. It should be also noted that ORF does not filter outbound emails, and it does not act as a proxy (it does not have its own SMTP engine), which means it cannot actually receive or send any emails. Instead, it hooks specific SMTP events during the mail transmission, tests the incoming emails and instructs the underlying Exchange (or IIS SMTP) server to reject or allow them to pass. The actual relaying, queuing and delivery of emails is performed by Exchange, ORF has no control over that.
Have you tried to restart your Exchange server already?
To investigate this issue, I suggest you analyze the Exchange message tracking and protocol logs. The following articles might prove helpful to you:
https://technet.microsoft.com/en-us/library/bb124375
https://social.technet.microsoft.com/wiki/contents/articles/23182.analyzing-the-protocol-logs-and-message-tracking-logs-in-exchange-2013.aspx
http://practical365.com/exchange-server/exchange-server-protocol-logging
During the Orf uninstall doesn't it stop and restart the Exchange Transport service automatically?
@mike.galbicka: No, it doesn't. The Exchange Transport Service (and the Exchange Front-End Transport service) must be stopped manually before uninstalling ORF. In fact, when you launch the uninstall wizard, the very first thing you see is a notification about this. If you skip this step, you will see a prompt at the end of the uninstall process stating that the transport agent binaries (orftagent15.dll) could not be removed - and should be deleted manually after stopping the Exchange Transport and Front-End Transport services.
@mike.galbicka:
ok sorry for the false alarm.
no , its not vamsoft problem.
apparently its a confluence of issues.
dns cache, mx settings, send or receive connectors. anyway the vendor got it fixed. i've reinstalled vamsoft ORF with no issue.
now i'm figuring out how to copy my filter definitions from the old install to the new one
@mike.galbicka: As far as I know, this is due to technical limitations Mike. However, the technical details are way over my head, I am afraid (I am not a developer).
@christopher.low:
Thank you for the update Christopher. For step-by-step instruction on how to migrate the ORF settings, please consult our Migration Guide at https://vamsoft.com/support/docs/how-tos/migration-5.4.1
Let me know if you have any questions.
I installed 5.4.1 on exchange server 2016 and migrated my settings from exchange 2010's ORF installation.
now the exchange 2016 no longer receives/sends mail and i uninstalled ORF and the transport agents and it still doesn't receive mail.