10-02-2011 07:03 AM
Hello,
can someone tell me when Symantec&Microsoft resolve the issuses
http://www.symantec.com/business/support/index?page=content&id=TECH164949
Many Thanks Ronen
Solved! Go to Solution.
10-02-2011 02:37 PM
10-02-2011 08:15 AM
Typically the Technote will be updated once it is solved. What I would recommend is for you to subscribe to the technote.
10-02-2011 11:22 AM
Wow, sounds like a major issue. This statement, "This issue is reproducible without Enterprise Vault.", leads me to believe that MS should be the ones to resolve the issue with a hotfix or service pack for Exchange since the situation is not limited to EV. I would recommend opening a case with them as well and also making sure your Microsoft TAM is involved.
10-02-2011 12:10 PM
Yeah, if you read a few of the blogs out there in regards to this it would seem this problem is present with other archive solutions and even for folks not using an archive product at all. I couldn't find an official post from them on it but here is a post where it is being discussed.
http://social.technet.microsoft.com/Forums/en-US/exchange2010/thread/a9632941-37a1-44e9-b4f2-0a7a1290f623/
As expected, some at MSFT blaming the shortcutting process but that doesn't account for folks that have the problem that don't use an archive solution.
10-02-2011 12:33 PM
Engineering is working closely with Microsoft on the issue, and no it's not a Symantec bug.
10-02-2011 12:34 PM
more info. really quite interesting.
10-02-2011 12:41 PM
Hello,
The only resolution is to move users to a new blank database until the size becomes too large once again and you have to repeat the moves.
For this reason, this can be added to the reasons to not utilize stubbing in your archive solution.
Do you have any time line when the issuses resolve ?
Ronen
10-02-2011 12:46 PM
No there is no currently communicable timeline. It is a work in progress.
10-02-2011 02:37 PM
10-02-2011 05:10 PM
yes absolutely with you, JW. from his posts, tony as well. and rob.. well, he's biased :)
10-03-2011 03:59 PM
If I archive a 30MB message with an attachment, will it be reduced to a 32kb shortcut?
10-03-2011 04:04 PM
it depends on how you configure your shortcut but most messages without shortcuts arent 32k anyway.
10-03-2011 07:31 PM
So when you archive a 30MB file it will take up 1000 or so 32k data pages.
When you archive the item, it will then turn in to a 4k shortcut and take up a single 32k page
So yes, the 4KB shortcut will take up 4KB in the mailbox but 32kb in the exchange database
However, the 999 data pages that were freed up will still be allocated until a defrag reclaims the whitespace
the issue is that the white space in the 32kb page (4kb used, 28kb free) will never be reclaimed.
10-03-2011 11:16 PM
yup that's how i understand it too. is anybody seeing something different?
10-04-2011 01:46 AM
Interesting, couldn't find the blog post above but found this one:
I guess another factor is PST migrations, I mean if start populating Exchange with 4+28kB shortcuts rather than 4kB shortcuts?
10-04-2011 06:38 AM
well that would be the same with regular messages and EV shortcuts.
If you have a 4kb shortcut, thats 1x32kb page
If you have a 34kb email, thats 2x32kb page
The line at the bottom of that article sums it up perfectly
"Let me clearly state: At this time, there is no known issue with archival stubs beyond the increased overhead ratio I described above."
10-04-2011 08:53 AM
Didn't mean that as critizism against EV or archiving stubs.
I meant it as in the context of the forum we are in, which is about EV.
So yes the same will apply for any mail message in Exchange, it's an Exchange issue.
But if you then take that a step further to what people do with Exchange in conjuction with e.g. EV.
Then you may do things like import PST files, the customer may decide to use shortcuts for the PST import which will generate alot of new mails/stubs in Exchange were each mail/stub is at least 32kB in size.
So again, not a issue with EV itself but something that you would need to think about when e.g. decided if you want to limit the shortcut creation of the PST import etc.