ErrorNoRespondingCASInDestinationSite when using FullAccess
Hi!
I am using MailStore to archive incoming mail. I am facing a problem with a customer that always receives “ErrorNoRespondingCASInDestinationSite” in MailStore when it checks for FullAccess (instead of Impersonate). If I access OWA and switch the user, it works well.
This works well for all current customers but with this one I am unable to archive mails.
The customer who is receiving the error, is one of our first on this infrastructure (thus created with a very old version of CloudPanel).
Are there any AD attributes that are set during the creation of a new company or user that cause this problem?
I am using EX 2013/2019, the affected mailboxes are hosted on 2013.
Thank you.
Usually archiving happens on the server side and doesn’t actually check the individual mailboxes. CloudPanel does remove “Authenticated Users” from having read access on the organizational unit for the company and adds the AllUsers@<companycode> to it in it’s place. What you could do as a test is enable read permission on a company OU and see if your account can access the user object at that point.
I’ve tried that but had no luck.
In the meantime I noticed that MailStore uses “MacOutlook/14.2.0.101115+(Intel+Mac+OS+X+10.6.2)” as UA.
Also, it seems that some accounts have OutlookMac on it’s allow list while some are unconfigured.
Has there been a change in behaviour?
This did not help:
Get-CASMailbox *example.com | set-casmailbox -EWSEnabled:$True -EWSAllowOutlook:$True -EWSAllowEntourage:$True -EWSAllowMacOutlook:$True
Mac does use EWS and on the mailbox plans in CloudPanel you need to make sure EWS (and ECP) are enabled. It could be they were. It looks like you set it manually on Exchange and that didn’t fix it. It sounds like the Mailstore is just having issues communicating with your Exchange period and may not be related to permissions. I assume you checked the connectivity?
It’s no connection problem. MailStore also runs in Multi-Tenancy from it’s own VM and connects just fine to to other CloudPanel tenants on the same MBX/CAS.
I’ve checked inheritance in AD but it’s fine / identical compared to working tenants.
IIS shows Error 500 while archive jobs for other tenants show 200 for EWS. This must be some kind of broken permission oder missing AD flag.
I’ve now tried to save the Mailbox plan (without changing it) but I receive this error:
Unable to bind to type: CloudPanel.Base.Models.Database.Plans_ExchangeMailbox
Make sure you are entering the cost/price currently according to your system locale. Updating the mailbox plan’s don’t push the new updated settings back down to the mailboxes.
Ok, you were right, adjusting the price indeed worked. Is there some way to “re-sync” the MBX plan without switching over to another and back?
There isn’t a way to “propagate” the settings down to the mailboxes using it unfortunately. We went back and forth on that for a while and decided not to make it do that in case there were any custom settings set especially on the backend. You would have to edit the mailboxes and save again which you can use the bulk edit feature but you would have to do that per company
- 5 Forums
- 714 Topics
- 3,630 Posts
- 0 Online
- 253 Members