β08-22-2013 01:20 AM
Hi Folks,
I've seen this issue in a couple of environments now. Fax devices send faxes via e-mail with the original fax as an attached pdf. There is a known issue with the PR_BODY is missing.
Article:TECH137282 | | | Created: 2010-08-04 | | | Updated: 2011-05-24 | | | Article URL http://www.symantec.com/docs/TECH137282 |
In my cases this it has not worked to use a customized shortcut content.
So we troubleshootet this further. DTrace of the StorageArchive process when performing a store in vault operation from the client shows this:
{CMAPIMsgTraverser::GetMsgProperty} (Exit) Status: [Unspecified error (0x80004005)]
{CMAPIMsgTraverser::GetMsgProperty} (Exit) Status: [Unspecified error (0x80004005)]
{CMAPIMsgTraverser::ProcessMessage} (Exit) Status: [Unspecified error (0x80004005)]
{CMAPIMsgTraverser::Traverse} (Exit) Status: [Unspecified error (0x80004005)]
{CMAPIMsgTraverser::LiberateMessage} (Entry)
{CMAPIMsgTraverser::LiberateMessage} (Exit) Status: [Exception]
{CMsgTraverserControl::Traverse} (Exit) Status: [Unspecified error (0x80004005)]
CFileSavesetAsMapiSavesetHelper::TraverseMessageOrSaveset - An error occurred 0x80004005
and so on.
In Outlook the icon changes back from pending archiving to normal.
We found out that after changing the subject line and saving the item it could be archived. So we compared the MAPI Properies before and after.
MFCMAPI shows this:
<property tag = "0x00710102" type = "PT_BINARY">
<ExactNames>PR_CONVERSATION_INDEX, PidTagConversationIndex, ptagConversationIndex</ExactNames>
<Value>cb: 0 lpb: NULL</Value>
<SmartView><![CDATA[Conversation Index: Unnamed byte = 0x00 = 0 Current FILETIME: (Low = 0x00000000, High = 0x00000000) = 12:00:00 01.01.1601 GUID = {00000000-0000-0000-0000-000000000000}]]>
</SmartView>
</property>
After changing the subject of the e-mail and saving it changes to:
<property tag = "0x00710102" type = "PT_BINARY">
<ExactNames>PR_CONVERSATION_INDEX, PidTagConversationIndex, ptagConversationIndex</ExactNames>
<Value>cb: 22 lpb: 01CE9E4AB0D0205D2E5B9FCF490BAA6AB15CE2AF70C8</Value>
<AltValue><![CDATA[...J.. ].[..I..j.\..p.]]>
</AltValue>
<SmartView><![CDATA[Conversation Index: Unnamed byte = 0x01 = 1 Current FILETIME: (Low = 0xB0D00000, High = 0x00CE9E4A) = 08:54:43 18.04.1785 GUID = {205D2E5B-9FCF-490B-AA6A-B15CE2AF70C8}]]>
</SmartView>
</property>
We noticed that after deletion of the PR_CONVERSATION_INDEX, the items could be archived.
I had once a case where a Symantec TSE stated that:
When EV traverse through the MAPI Property it reads its value and proceed further. Normal scenario it has a value or it can be blank and in your case the affected item have NULL value which is not good. So EV finds it's a problematic MAPI property and it fails.
So the cause would be the NULL value of the PR_CONVERSATION_INDEX property.
Now there are two questions:
Firstly, how to prevent the items to have that NULL value in the first place?
Secondly, how to change that property to all affected e-mails in the mailboxes. Any ideas?
Thanks in advance!
Sebaha
Solved! Go to Solution.
β11-01-2013 04:38 AM
This issue seems to be caused by PR_CONVERSATION_INDEX MAPI Property having a NULL value. This only shows in an Exchange 2007 environment. EV cannot read it from Exchange when it tries to archive the item. It's recognised as corrupt, hence not archived. Exchange 2010 seems to fix that property before handing the item over to EV.
So there are two possible fixes:
Firstly, upgrade to Exchange 2010.
Secondly, make sure no item that is to be archived has this property set with a NULL value.
β08-22-2013 04:13 AM
β08-30-2013 12:11 PM
I kinda agree with the weeper above... but as you stated ... this is a known issue with teh Fax Solution being used. I would suggest that the root cause is in the fax solution .... and that you may be able to get it addressed at that level and have them create a proper message.
With that staetd... I dont think EV should puke when it has a missing property... and should be resiliant enough to handle it. I would run it on both ends, at the fax solution provider and with EV support as I think both have some improvements they could make.
β08-31-2013 01:00 PM
Are you able to reproduce this on 'hand made' messages, not sent via the fax solution?
You might also want to take a look at this:
http://msdn.microsoft.com/en-us/library/cc842470.aspx
β09-02-2013 02:45 AM
Do you mean whether we can reproduce it when the message is edited to have a PR_CONVERSATION_INDEX value of NULL? I will try that in my lab.
β09-02-2013 05:47 AM
Unfortunately I cannot reproduce this at all in my lab. But I have Exchange 2010. The customer is on 2007 SP1 RU9.
He can reproduce the behaviour by setting the PR_CONVERSATION_INDEX to NULL for an ordinary mail item.
Update:
I can reproduce it in another production environment with Exchange 2007.
I'm pretty convinced now that it's about the PR_CONVERSATION_INDEX having a NULL value.
In Exchange 2010 it seems to be automatically repaired by Exchange before it's beeing archived.
β09-06-2013 05:56 AM
In review of the Technote you supplied (that looks a little too familiar) . Have you tried the suggested workaround?
You could change the shortcut content and it may work arround the issue. THe TN implies that it is either not planning to be fixed or shoudl have been fixed in later versions of EV 8.
β09-06-2013 06:10 AM
Yes and I mentioned it.
In my case it has not worked to use a customized shortcut content.
Thanks anyway!
I don't think this is an EV issue.
β10-19-2013 07:10 AM
Are you all set then with this issue? Did one or more of the forum posts help? You could maybe mark them as the soluton....
β10-22-2013 06:37 AM
Hi,
sorry for the late reply. Currently I'm up to here with work. I handed this case over to a colleague. I will research the result when I have time this week.
Thanks for reminding.
β10-22-2013 06:43 AM
Okay great.
β11-01-2013 04:38 AM
This issue seems to be caused by PR_CONVERSATION_INDEX MAPI Property having a NULL value. This only shows in an Exchange 2007 environment. EV cannot read it from Exchange when it tries to archive the item. It's recognised as corrupt, hence not archived. Exchange 2010 seems to fix that property before handing the item over to EV.
So there are two possible fixes:
Firstly, upgrade to Exchange 2010.
Secondly, make sure no item that is to be archived has this property set with a NULL value.