<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: Exchange Storage Limits?</title>
	<atom:link href="http://jasonmlee.net/archives/153/feed" rel="self" type="application/rss+xml" />
	<link>http://jasonmlee.net/archives/153</link>
	<description>bytes about bits in church IT</description>
	<lastBuildDate>Mon, 20 Feb 2012 06:14:52 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=2.9.2</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: Tony Dye</title>
		<link>http://jasonmlee.net/archives/153/comment-page-1#comment-176</link>
		<dc:creator>Tony Dye</dc:creator>
		<pubDate>Fri, 18 Jul 2008 09:31:52 +0000</pubDate>
		<guid isPermaLink="false">http://jasonmlee.net/archives/246#comment-176</guid>
		<description>We&#039;re pretty much right in line with Drinnon, having actually been even tighter until about a year ago.  We expect to make this a lot more user friendly when we implement email Archiving sometime in the next year.</description>
		<content:encoded><![CDATA[<p>We&#8217;re pretty much right in line with Drinnon, having actually been even tighter until about a year ago.  We expect to make this a lot more user friendly when we implement email Archiving sometime in the next year.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Dave at Bitbud</title>
		<link>http://jasonmlee.net/archives/153/comment-page-1#comment-177</link>
		<dc:creator>Dave at Bitbud</dc:creator>
		<pubDate>Tue, 15 Jul 2008 17:14:37 +0000</pubDate>
		<guid isPermaLink="false">http://jasonmlee.net/archives/246#comment-177</guid>
		<description>That last sentance is mis-typed:

My point is that IT really should NOT dictate how much a user can store or how to store it.

IT should just make sure they meet whatever the user’s needs.

Phew...</description>
		<content:encoded><![CDATA[<p>That last sentance is mis-typed:</p>
<p>My point is that IT really should NOT dictate how much a user can store or how to store it.</p>
<p>IT should just make sure they meet whatever the user’s needs.</p>
<p>Phew&#8230;</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Dave at Bitbud</title>
		<link>http://jasonmlee.net/archives/153/comment-page-1#comment-178</link>
		<dc:creator>Dave at Bitbud</dc:creator>
		<pubDate>Tue, 15 Jul 2008 17:11:08 +0000</pubDate>
		<guid isPermaLink="false">http://jasonmlee.net/archives/246#comment-178</guid>
		<description>I think a new philosophy is needed regarding e-mail. The tools/ technology (Exchange in this case) should not dictate what the user&#039;s needs are/ what the business requires.  As such, we do not impose storage limits (today), although the PST Unicode format limit is 20GB.  Our Exchange DB is broken into 16 storage groups, between 20-50GB each.

Too much time is wasted by the user trying to manage e-mail, clean up e-mail, archive and move e-mail.  They have other things to do.  The world has changed, and e-mail is now a central personal repository for storing information.  A user should be able to store as much as they need to, and be able to easily search the data.

The real problem isn&#039;t the data stored in this case, its the architecture.  Exchange&#039;s single file database storage is archaic at best.  Microsoft needs to to move to a maildir type format (one file per message - which they won&#039;t do).  This would speed things up immensely, AND improve DR capabilities.

As such, we are working on implementing a Courier IMAP system for &quot;primary&quot; unlimited storage, and the Exchange mailbox will be pulled back to 100MB.  Exchange will remain in place for it&#039;s groupware features that the users are dependent on (read - Outlook).  The Courier based system is a rocket by comparison, on much less hardware.

My point is that IT really should dictate how much a user can store or how to store it, IT should just make sure they meet whatever the user&#039;s needs.</description>
		<content:encoded><![CDATA[<p>I think a new philosophy is needed regarding e-mail. The tools/ technology (Exchange in this case) should not dictate what the user&#8217;s needs are/ what the business requires.  As such, we do not impose storage limits (today), although the PST Unicode format limit is 20GB.  Our Exchange DB is broken into 16 storage groups, between 20-50GB each.</p>
<p>Too much time is wasted by the user trying to manage e-mail, clean up e-mail, archive and move e-mail.  They have other things to do.  The world has changed, and e-mail is now a central personal repository for storing information.  A user should be able to store as much as they need to, and be able to easily search the data.</p>
<p>The real problem isn&#8217;t the data stored in this case, its the architecture.  Exchange&#8217;s single file database storage is archaic at best.  Microsoft needs to to move to a maildir type format (one file per message &#8211; which they won&#8217;t do).  This would speed things up immensely, AND improve DR capabilities.</p>
<p>As such, we are working on implementing a Courier IMAP system for &#8220;primary&#8221; unlimited storage, and the Exchange mailbox will be pulled back to 100MB.  Exchange will remain in place for it&#8217;s groupware features that the users are dependent on (read &#8211; Outlook).  The Courier based system is a rocket by comparison, on much less hardware.</p>
<p>My point is that IT really should dictate how much a user can store or how to store it, IT should just make sure they meet whatever the user&#8217;s needs.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: David Drinnon</title>
		<link>http://jasonmlee.net/archives/153/comment-page-1#comment-180</link>
		<dc:creator>David Drinnon</dc:creator>
		<pubDate>Tue, 15 Jul 2008 16:22:05 +0000</pubDate>
		<guid isPermaLink="false">http://jasonmlee.net/archives/246#comment-180</guid>
		<description>Our limit is 90 MB, Warnings sent at 75 MB. Send ability stops at 85 MB. File attachments are limited to 5 MB (3 MB internally) We use FTP for the really big stuff and a file transfer service (http://files.second.org) for stuff between 5 MB and 200 MB.

It appears based on other comments, that we are pretty tight.</description>
		<content:encoded><![CDATA[<p>Our limit is 90 MB, Warnings sent at 75 MB. Send ability stops at 85 MB. File attachments are limited to 5 MB (3 MB internally) We use FTP for the really big stuff and a file transfer service (<a href="http://files.second.org" rel="nofollow">http://files.second.org</a>) for stuff between 5 MB and 200 MB.</p>
<p>It appears based on other comments, that we are pretty tight.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Michael Foster</title>
		<link>http://jasonmlee.net/archives/153/comment-page-1#comment-179</link>
		<dc:creator>Michael Foster</dc:creator>
		<pubDate>Tue, 15 Jul 2008 15:55:16 +0000</pubDate>
		<guid isPermaLink="false">http://jasonmlee.net/archives/246#comment-179</guid>
		<description>We impose very loose limits for our users.
Issue Warning: 2.0 GB
Prohibit Send: 2.5 GB
Prohibit Receive: 3.0 GB
If everyone was at the cusp of these limits we would be in some major trouble. Luckily there are only a couple out of the 100 or so users that have or will come close to having these limits on their mailboxes enforced. If I just a bunch of time to kill I would split our users into 3 different levels based on their reasonable storage needs. That is on the list of things to do but, unfortunately, it is pretty far down the list.</description>
		<content:encoded><![CDATA[<p>We impose very loose limits for our users.<br />
Issue Warning: 2.0 GB<br />
Prohibit Send: 2.5 GB<br />
Prohibit Receive: 3.0 GB<br />
If everyone was at the cusp of these limits we would be in some major trouble. Luckily there are only a couple out of the 100 or so users that have or will come close to having these limits on their mailboxes enforced. If I just a bunch of time to kill I would split our users into 3 different levels based on their reasonable storage needs. That is on the list of things to do but, unfortunately, it is pretty far down the list.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Mark Rock</title>
		<link>http://jasonmlee.net/archives/153/comment-page-1#comment-181</link>
		<dc:creator>Mark Rock</dc:creator>
		<pubDate>Tue, 15 Jul 2008 15:22:01 +0000</pubDate>
		<guid isPermaLink="false">http://jasonmlee.net/archives/246#comment-181</guid>
		<description>We have our warnings set at 300MB, but I don&#039;t have any prohibit levels set, the warnings have solved most of the problems and staff clean up their mailboxes when they get the warning.  I don&#039;t really have a good reason anymore for the limits other than faster backup speed and DR, I put them in back in the days of Exchanges 15GB store limits, but with Exchange 2003 SP2 and the higher store limits, backup speed would be the only reason to have them in place and to force staff to clean house once and awhile, maybe it&#039;s time for me to rethink this too.</description>
		<content:encoded><![CDATA[<p>We have our warnings set at 300MB, but I don&#8217;t have any prohibit levels set, the warnings have solved most of the problems and staff clean up their mailboxes when they get the warning.  I don&#8217;t really have a good reason anymore for the limits other than faster backup speed and DR, I put them in back in the days of Exchanges 15GB store limits, but with Exchange 2003 SP2 and the higher store limits, backup speed would be the only reason to have them in place and to force staff to clean house once and awhile, maybe it&#8217;s time for me to rethink this too.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Scott Reichling</title>
		<link>http://jasonmlee.net/archives/153/comment-page-1#comment-182</link>
		<dc:creator>Scott Reichling</dc:creator>
		<pubDate>Tue, 15 Jul 2008 14:40:01 +0000</pubDate>
		<guid isPermaLink="false">http://jasonmlee.net/archives/246#comment-182</guid>
		<description>Our warning level is 250MB, prohibit send 300MB and prohibit send and receive 350MB.  We also automatically cleanup Deleted Items that are older than 28 days.  Most mailboxes stay between 100 - 200MB so the limits help keep the pack rats from storing useless information.  Every 1-2 months we have to re-educate a user on how cleanup their mailbox.  This usually means showing them how to delete the 10-20 large email messages (usually forwards to their friends that are 5-10MB) sitting in their Sent Items folder.</description>
		<content:encoded><![CDATA[<p>Our warning level is 250MB, prohibit send 300MB and prohibit send and receive 350MB.  We also automatically cleanup Deleted Items that are older than 28 days.  Most mailboxes stay between 100 &#8211; 200MB so the limits help keep the pack rats from storing useless information.  Every 1-2 months we have to re-educate a user on how cleanup their mailbox.  This usually means showing them how to delete the 10-20 large email messages (usually forwards to their friends that are 5-10MB) sitting in their Sent Items folder.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

