You may get this behaviour due to a number of reasons. The simplest reason for this is, you are using the Email Router to process emails and you use Test & Enable function on the mailbox record.
The Test & Enable function on the mailbox record is for Server side Synchronization component not for Email router. If you use Email router, you do have Test access button on the router configuration wizard to test the access.
Other than that, the Test & Enable function may get stuck, if the mailbox goes to locked status for some reason.
When you do Test & Enable, the functionality is not instantaneous, it is updated to a new value only if a new job is not scheduled. If the incoming or outgoing result is failure for the Test Access and the retry attempts remain, the old Scheduled value remains, else it will reset. The value in the ‘Processstatecode’ column in the MailBoxBase table tells you if it is locked for processing or not.
So if the status of the Test & Enable function on the mailbox record is stuck on ‘The email configuration test is scheduled’, you may probably want to reset it so that you can troubleshoot it further, but it is always recommended to look at the Alert wall on the mailbox and in the LastSyncError column in the Mailboxbase table to get error occurred during the mailbox sync with Exchange.
The below SQL statement can be used for resetting the mailbox:
Note: A direct SQL update is not recommended or supported by Microsoft, a wrong SQL update may break the CRM functionality.
Once you reset the Mailbox, it is worth checking the processing statecode of the mailbox. We have seen that Async service sometimes locks the mailbox again even after you run the above query; it might be due to the pending retry count (TestEmailConfigurationRetryCount) so you can reset this value to 0 (DB Update) and a reset of Async service should bring back the mailbox for ready to go again stage.
Once this is done you can enable PF Trace and do the Test & Enable again and collect the PF trace while recreating the issue so that you get the right error stack causing the issue.
Known issues in this area:
You have configured server side sync only for Outgoing email and do Test & Enable, then you may witness the behaviour of the mailbox record is getting stuck on ‘The email configuration test is scheduled’. This is known issue and the workaround is to set either Incoming\ACT to user server-side sync rather than just setting outgoing alone.
The product team has identified this and will be fixed in future release.
If your mail server is not responsive, you may face the same behaviour. Try accessing the EWS URL from IE and check how responsive it is. You can also use EWS Editor to access the mailbox to isolate the problem as not related to Mail server.
Though the behaviour is not very consistent, if the ExchangeSyncStateXml is corrupted you may face the same behaviour. In this scenario you can set this value to NULL but since Direct DB update is not supported, it is always recommended to engage Dynamics CRM Support Team to assist you on this.
If you see the error in the Alert wall and in the LastSyncError but not able to relate it to the behaviour you see, or need technical assistance to resolve it, open a support ticket with Microsoft support.
EMEA Dynamics CRM Support Team
Share this Blog Article on Twitter
Follow Us on Twitter