Last night, Exchange 2016 CU9 was applied to my Exchange 2016 server. After the update completed, all new incoming email was being sent to the VIPRE "unprocessed" folder. Review of the PIM logs found the following error which I believe is preventing the PIM from processing the incoming email.
Error 1656 12 2018-03-30T08:18:54 497683316753 Error occurred during Process - sending RETRY back to the shim. Error: System.IO.FileNotFoundException: Could not load file or assembly 'Microsoft.Exchange.Transport.Flighting, Version=18.104.22.168, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its dependencies. The system cannot find the file specified. File name: 'Microsoft.Exchange.Transport.Flighting, Version=22.214.171.124, Culture=neutral, PublicKeyToken=31bf3856ad364e35' at Microsoft.Exchange.Data.Transport.Email.PureMimeMessage.DetectRightsProtectedMessage(String contentType) at Microsoft.Exchange.Data.Transport.Email.PureMimeMessage.DetectMessageType() at Microsoft.Exchange.Data.Transport.Email.PureMimeMessage.Synchronize() at Microsoft.Exchange.Data.Transport.Email.MimeTnefMessage.Synchronize() at Microsoft.Exchange.Data.Transport.Email.EmailMessage.Synchronize() at Microsoft.Exchange.Data.Transport.Email.EmailMessage..ctor(MessageImplementation message) at Microsoft.Exchange.Data.Transport.Email.EmailMessage.Clone(Stream source, Boolean skipHeaderBytesLimitCheck) at Ninja.Core.Messaging.NinjaMessage.LoadMessageFromStream(Stream data) at Ninja.Services.PluginManager.MessageManager.Process(WorkItemState workItemState) WRN: Assembly binding logging is turned OFF. To enable assembly bind failure logging, set the registry value [HKLM\Software\Microsoft\Fusion!EnableLog] (DWORD) to 1. Note: There is some performance penalty associated with assembly bind failure logging. To turn this feature off, remove the registry value [HKLM\Software\Microsoft\Fusion!EnableLog].
Mike what was the fix?
The fix was to copy the "Microsoft.Exchange.Transport.Flighting.dll" from the Exchange BIN subfolder into the root of the VIPRE Email Security install location. At that point, VIPRE Email Security is able to locate the file and function normally.
Thanks Michael. I called support this morning as I experienced this same issue and moving the DLL file you described was indeed the fix.
Glad I could help... Exchange 2013 has a similar issue, but it required moving a different DLL file to the VPX install folder.
I am intending to upgrade VPX 126.96.36.199 running on EX2013 to 10.0.0.9.
Forewarned is forearmed and all that...
Do you remember what DDL you needed to move?
I believe it was Microsoft.Exchange.Data.Transport.dll and was located in the "C:\Program Files\Microsoft\Exchange Server\V15\Public" folder.
I ignored the previous release having seen the feedback on the forums, but am having all scan engines failed so often on 188.8.131.52 that I have to move on.
Wish me luck!
The current build has been working pretty well for me except for a couple of minor issues... The first being the CU update issue which is resolved by copying the correct DLL file into the VIPRE install folder. The only other issue I have currently is a problem with the antivirus module reporting scan failures on certain types of attachments. I have had to adjust the antivirus policy to deliver attachments where the scan fails instead of sending them all to quarantine.
That's already sounding a lot better than the feedback on the previous release!
Are TT working on patching to fix the attachment issues?
I opened a support ticket for the issue and have been told it was sent to development for a resolution.
Great. Hopefully a timely resolution as that issue must pretty much impact all VPX users.
Thanks for the feedback Michael, most helpful! None of us like walking into problems, especially when these works happen generally out of hours eh?
@Michael I've had a successful upgrade - no issues (so far) with any of my test messages in / out going into unprocessed. Would you mind sharing further details of the attachment issue so I can keep an eye out... If you are feeling particularly generous (and it isn't sensitive), maybe even share what rules you have created so I can pre-empt any trouble by creating same.
@Matthew The issue with attachments is not caused by any rules applied in the attachment policy. The problem is in the Antivirus module and I have found that certain types of attachments, the antivirus module is unable to scan the file resulting in a "scan failed" message. The default action for failed antivirus scans is to place the attachment into quarantine. The most common type of attachment I have seen failing are PDF documents, however, it does not fail for all PDF's and I haven't been able to identify anything specific that causes the antivirus scans to fail. Therefore, I have just changed the action to "deliver" for attachments with failed scans.
But since you asked, the only attachment rule I have configured is a SMART rule to block executable file types.
@Michael Thanks for the feedback. Everything seems fine, just had a few funnies where people had left mailboxes open - restarting Outlook sorted those. Noted re PDF. Given that is such a popular attachment type I have also made the change to the AV policy to deliver on fail. Hopefully TT get a fix sorted soon.
I've not previously paid much attention to attachment rules - maybe I should have! In fact I'd never stopped to work out what a SMART rule is. Our firewall is pretty hot on such things but belt 'n' braces and all that. I think I'll also add a rule to quarantine Inbound External executables...
Thanks for the support.