NAV Team: E-Mail Logging: error member Count and E_FAIL

[Blog bot]

Recently our support service received support requests where out of the blue the E-mail logging stopped functioning. The reported error was:

This message is for C/AL programmers:

The call to member Count failed. Collaboration Data Objects returned the following message:
[Collaboration Data Objects - [E_FAIL(80004005)]]

NOTE: sometimes the same error pops up E_FAIL with member Update

The failure appears to be caused by some or specific security patches for Office 2007 that were applied on the application server and / or patches that were applied to the Exchange Server.

Let’s assume the following scenario where we have Office 2007 RTM installed on the server hosting the application server. This is our starting point. The ultimate goal is to update Office 2007 with SP3 and later cumulative security patches. E-mail logging does work fine here. In his scenario, transport logging rules are  running on the Exchange Server. That means, if you update the server hosting the application server  with Office 2007 SP3 and cumulative updates, E-mails are still sent to the QUEUE folder. Now, after updating the Office 2007 with the latest patches, the scenario is as follows:

1. There are pre-SP3 messages in the queue; these ones will generate the E_FAIL error
2. There are post-SP3 messages in the queue; these ones will be processed by the E-mail dispatcher

The post-SP3 messages will be logged to the STORAGE folder. The pre-SP3 messages will generate an error. We have seen errors like The member Update or The member Count. They all end with E_FAIL which is something like “Access Denied”. Exchange Server is not able to handle them and we do not really know why. This is because security is more strict thus the Access Denied error message.

WORKAROUND:
1. Remove Office 2007 SP3 from the server hosting the application server
2. Install Office 2007 RTM / SP2 (whatever the original scenario was) on the server hosting the application server
3. Ensure QUEUE folder is empty before updating Office 2007 SP3 plus cumulative updates
a. In this scenario, Transport Rules should be stopped which is not an ideal scenario since your end user may be a 24x7 company
b. The update should be done after business hours which is not an ideal scenario as well; at least the number of pre-SP3 messages could be decreased in numbers
c. Transport Rules should be reconfigured and point to a different E-mail address for a different Public Folder, then we have one pre-SP3 Public Folder and the original post-SP3 Public Folder (QUEUE)
4. Update Office 2007 SP3 plus cumulative updates
5. For any E-mail that does still come in to the QUEUE folder, these cannot be logged though you could use the suggestion below

For any pre-SP3 messages that are stuck in the QUEUE:
For the ones that fail with the E_FAIL error message, move these messages from the QUEUE folder, open the message one by one, select Actions and select Resend this message. With Transport Rules enabled, the message will be sent to the QUEUE folder again where the message can be reprocessed by the E-mail dispatcher.

The above mentioned workaround should only be applied if there are hundreds of messages that are stuck in the QUEUE. If there are not that many messages stuck in the QUEUE, then resending the message may be a better idea to prevent the work to be done here.

Now we do have this blog in place, Administrators that are about to do some maintenance can be pre-warned this issue does exist when E-mail logging is configured and running in the company.

Regards,

Marco Mels
CSS EMEA

This posting is provided "AS IS" with no warranties, and confers no rights



Источник: http://feedproxy.google.com/~r/Micro...nd-e-fail.aspx