Office 365 Error Message

I've been battling this error for the last couple of days, and haven't been able to make any headway. Most of the searching I've done seems to allude that it's an issue with clutter being enabled on the mailbox, but that is not the case. Any help would be greatly appreciated.

SMTP Exception: The server rejected the message: 554 5.2.0 STOREDRV.Submission.Exception:StoragePermanentExce ption.MapiExceptionDuplicateDelivery; Failed to process message due to a permanent exception with message Cannot get ID from name.

Thanks. We have recently received a few others reports on this. These are all related to a recent change in 365 implementation.
In any case, we have just released a patch to work around this issue. This patch is for the current latest version, 19. Please contact us to Support@ to receive it (we do not share it here because it might conflict with other versions and cause other problems, so please drop us an email).

Hope this helps.

Came here to post this! Really odd timing since we just implemented the email connector.

I thought clutter would have something to do with it, as it is describing a similar issue on this Microsoft help page. https://support.microsoft.com/en-us/...tion-mapiexcep

Glad commitcrm has a workaround.

Lexington, Kentucky IT Consultants

Guys, make sure you are checking in your CommitCRM outbox folder and reading each of the failed emails (it's ok to just move them to another temp folder and then open them with notepad). I have found a few that were replies to closed tickets that only I was on (as the account manager) and was able to catch and go look up the closed ticket and reply to the user.

I had the same or similar issue this week. Also found issues with MFP devices doing scan to email that could no longer send through O365. From what I found Microsoft made a change this week to Office 365 that was causing these issues.

If you are using O365 and have this problem in CommitCRM send an email to support at commitcrm.com. They have a patch that resolved the issue for me.

We have been seeing this today - using O365 also.
We see the messages trying to get out queued up in C:\CommitCRM\Server\QSysEDOutbox and eventually this error in C:\CommitCRM\Server\QSysEDOutboxErr

I tried recreating the support mailbox and a bunch of other things (turn off clutter) etc.
I figured it was Microsoft's SMTP server not liking the messages.

Glad there's a fix! I've just contacted support for it.
Tony

We are getting this error too. Can anyone report that Commit's fix works. What's the fix?

The fix is a patch to version 19 that luckily work-around this issue. As far as we know it has helped everyone that had applied it so far.

Hope this helps.

Anyone had any luck with this? I've been in touch with support, but they won't help me out. I'm not under maintenance and they want me to upgrade before helping.

It's a bit of a catch-22, I've stopped paying because I've almost never had any issue addressed that I have raised with support. I'm not interested in paying just to fix email. And even in their own correspondence they say "[they are] not sure but we've tried a few things to work around this issues until 365 stopped falsely reporting this problem" when I asked for what Microsoft changed in Office365. They also say, "We cannot say whether this will work forever". And they want pay for this performance?

Microsoft tell me that nothing about the SMTP service or protocols have changed. Ironically, I switched to Office365 because it was the first server I found that would work with the CommitCRM connector for longer than a week before failing.

I've setup a connection to Office365 with IISs smtp server, and then configured this smtp server in CommitCRM. This hasn't fixed the problem, but it has given me extra logs to diagnose and it stopped the pop-up errors within CommitCRM. It also allows the email queue to clear in CommitCRM and not cause cascading issues.

It looks like CommitCRM is doing something strange to internal email (email directed to staff members). Email generated by CommitCRM Alerts appears fine, the problem seems to just effect email correspondence to/from clients and staff. Emails are being logged in CommitCRM they are just not making it through to the staff members email. Emails appear to make it to clients okay.

At this stage being forced to choose between staying with Office 365 or staying with CommitCRM the choice is probably Office 365. It looks like I'll need to find another CRM if I can't find a solution to this.

If anyone has any ideas I'd love to hear them. I'll post extra info too if I figure out anything over the weekend.

A change occurred in 365 that causes this. We see waves of customers reporting just this - once that change is deployed to their 365 instances.

In any case, following the first report we found a work around and introduce a patch that works around this issue. To the best of our knowledge it has resolved this matter for everyone who applied it.

We cannot guarantee that it'll work forever. That's software and dealing with 3rd parties makes it more complex, and this is a great example of such a case. Anyway, if 365 will change other things too, we'll promptly adjust RangerMSP as needed. That's our job, this is what we do and this is what people pay us to do when signing to a maintenance plan. - True, in order to receive all updates, new version upgrades and be entitled for our support one need to be signed for an annual coverage plan, that is usually considered to be affordable and very reasonably priced.

Hope this helps.

supportedge,

I can confirm that something changed with Microsoft in regards to Office 365 and the way it handles email. We first noticed it last month when we were getting calls from different clients saying their scan to email stopped working from their large MFP machines.

I believe that the issue had something to do with MS stopping support of TLS but am not positive about that detail. There was never anything we were able to do on the MS side and had to make changes on the machines to get them to work again.

The few days later we noticed we had issues with Commit and outbound email so I reached out to Commit Support. They confirmed it was an issue similar to what we had with the scanners and they were able to provide a patch. We put the patch in place and everything has worked since.

I can't say for sure that you are experiencing the same thing but it sure sounds like it.

Good luck

Ascendnet,

Thanks, I don’t think it’s a TLS issue. Our server OS supports TLS 1.2 and I have checked it. But I’m not sure if the Commit email connector also needs to support TLS 1.2 or not? My understanding is TLS encryption is done at the OS. Also, Microsoft’s documentation says they aren’t providing technical support for TLS 1.0 and 1.1 from 31 Oct 2018 but functionality will continue for at least 6 months

CommitCRM Support,

I’m really sorry to say but I’ve never got this “we'll promptly adjust CommitCRM as needed. That's our job, this is what we do and this is what people pay us to do when signing to a maintenance plan” that you talk of. That was kind of the point in my post on the 26th. I’ve paid lots and lots in maintenance, upgrades and plugins over the years with no issues being fixed along the way. I’ll make you a deal, when you re-write the email connector I’ll upgrade. It’s always been problematic and it’s functionality and behaviour requires significant training when we get new staff. It’s functionality is such that I don’t even think you use it to provide your email support. Anyway I won’t bring it up again and I’ll come back to the topic.

Our workaround was to use a new STMP server (not connected to Office365). We authorised this server in our SPF record and all appears good again (it’s been about 4 days). So, in short the email connector still receives mail via Office365 but sends mail via the new server ‘as’ our configured support mailbox

Thank you for posting this.

The Email Connector works perfectly well with 365 despite their recent change, to which we've introduced a solution for.

Using another SMTP server than 365 is perfectly fine, especially when you SPF'd it so it'll be considered and legit mail server for your domain.

When it comes to TLS, version 20 of RangerMSP includes support for TLS 1.2.

Hope this helps!

I am having the same issue. Please provide the patch.

Please upgrade your system to the latest version and it should be solved for all future emails (we may need to help you clean up older items, but first upgrade). Hope this helps.

I upgraded to CommitCRM 21 and I still have the same problem.

OK, this was somewhat expected as the system still tries to connect for the the previous, before the upgrade, items. Please try this:

1. Stop 'RangerMSP Server' service on your server.

2. CAREFULLY delete only the TEXTUAL files found in folder:

<server>\RangerMSP\Server\QSysEDOutboxErr\

3. From folders -
<server>\RangerMSP\Server\QSysEDOutbox\
AND
<server>\RangerMSP\Server\QSysEDOutboxErr\

Look for an MOVE all files that ENDS with the .bak_cmt3 file extension.

To a backup folder outside of the RangerMSP folder tree.


4. Start 'RangerMSP Server' service only your server.

There's another variant though the above should help.

Hope this helps.