Exchange Archiving

T

twwabw

Gawd
Joined
Apr 21, 2001
Messages
716
Found a few threads here, but wondering what everyone's using. I have been looking at GFI Archiver, but it looks like the hardware and server requirements are going to be pretty steep, once you get a new SQL server, etc. About 35 users, and huge mailboxes. Owners refuse to accept quotas, and want indefinite retention. Looked at the Barracuda solution, but I see they use stubs, which I've heard can cause problems, and are not recommended by MS.

I've already increased their exchange store capacity several times, and now they are almost at the 75GB limit. Some user's mailboxes are in excess of 7GB- some with 40-50k messages. Ugh.
 
GFI is nice and can archive to file system instead of SQL database, but for 35 users, thats a lot of space.

Maybe look at symantec archiving options?
 
You should remind them that any recovery of email (should the server go down) is going to be a huge nightmare.

You might want to look at an upgrade to Exchange 2010, which has archiving features included with it.
 
k1pp3r said:
GFI is nice and can archive to file system instead of SQL database, but for 35 users, thats a lot of space.

Maybe look at symantec archiving options?
Click to expand...

Symantec Enterprise Vault BLOWS for a large user-base.

may be worth looking in to though.

I'm sure it would work better if it was actually implemented correctly.
 
j-sta said:
Symantec Enterprise Vault BLOWS for a large user-base.

may be worth looking in to though.

I'm sure it would work better if it was actually implemented correctly.
Click to expand...

Symantec blows lol
 
I think I have determined that, well... Symantec blows :D. I saw that GFI can export to file, but they say for less than 25 users, and my guess some of their (ugh) 7GB users' mailboxes would be a problem. really don't want to invest in a new SQL server either. Also, I can't really determine from their documentation, but it looks like if you port to SQL, SQL needs to be on its own server, and then GFI on another, and IIS on a 3rd??? Ouch.

No chance on a 2010 upgrade yet- they are on SBS03.
 
k1pp3r said:
Symantec blows lol
Click to expand...

eh.. I gotta be hopeful.
Since they bought out GuardianEdge, which we're using. :(
and down the road will probably end up using PGP too, which Symantec also bought out.

can't say I've ever had any issues with the Corporate version of SAV!
 
We just bought a software called "viewwise" It works with exchange and novell groupwise. We demoed it and it looked really nice. Has amazing search features, can restore single emails. And will even create a mini searchable database if you export emails (for instance giving a lawyer all email from person x within timeframe y)
 
Symantec EV for 35 users? LOL.

Exchange 2010 Archiving requires Enterprise Edition + Enterprise CALs, also kind of a LOL for 35 users.

The biggest players in archiving at for such a small user base tend to be GFI, Barracuda, and Sunbelt Software, due to the low cost. Nothing at this price point is ideal. The best product out there, IMO, is Mimosa NearPoint (now owned by Iron Mountain). They don't even sell it under 200 seats though.

GFI just purchased Sunbelt, and from what info has been let out, the Sunbelt archiving product will be sold as a higher level/enterprise product, while GFI's product will be an entry level product. Eventually they will probably merge. So maybe check into Sunbelt Enterprise Archiver
 
I use GFI for our small user base (25 users) and I'm happy with it.

We bought the mail archiver for different reasons, our users don't go into it too much (usually come to me to find an email they are looking for) we used it for our CRM integration to track contact with our customers.
 
RiDDLeRThC said:
I use GFI for our small user base (25 users) and I'm happy with it.

We bought the mail archiver for different reasons, our users don't go into it too much (usually come to me to find an email they are looking for) we used it for our CRM integration to track contact with our customers.
Click to expand...

Are you using it with SQL, or its own internal save to file function?
 
twwabw said:
No chance on a 2010 upgrade yet- they are on SBS03.
Click to expand...

It sounds like they are outgrowing their SBS infrastructure. To be honest, I'd recommend going to a full 2003/2008 infrastructure. One box for PDC functions, and second box as BDC running Exchange 2007/2010. That way you don't run into the database limitations. Microsoft makes a transition pack that allows you to keep your existing SBS licenses and converts them to the stand alone product keys. I'm not sure if you can still get the 2003 transition pack licenses though. Your customer should start thinking about upgrading to 2008 anyway.

http://download.microsoft.com/downl...5C76A/SBS2003TransitionPack_to_standalone.pdf
 
The SBS2003 R2 transition pack is LONG dead. It was discontinued when SBS2008 came out.

I don't think he's outgrowing SBS itself, but he's outgrowing SBS2003. He'd be fine with Exchange 2007 with SBS has no database limit. SP1 imposed a 250gb default limit, but you change it. Exchange 2007 in SBS2008 allows for 5 storage group with 1 databases per group.

MS had (may still be going) a different promo to convert from SBS to standalone product,but when I price dit out last year, it was cheaper to just buy licenses outright due to typical licensing discounts from places like CDW.

Costs to go from SBS to standalone are substancial, no matter how you slice it, from a licensing standpoint alone, then hardware has to be considered. They are particularly gnarly if SQL is involved.

Lastly, keep in mind that Exchange 2007 standalone, or SBS2008 means you need 64bit hardware.
 
Migrating to Exch 07/10 may adress the issue of the exchange store size limit, but it doesn't address the issue of oversize mailboxes. Outlook becomes glacial with mailboxes that are 5,6, or 7 GB in size. The root solution (to me) is reducing mailbox sizes across the board. They simply refuse to spend time cleaning out old mail (which is truthfully very time consuming) and the Principals and Project Managers insist they need to have access to these old messages. So, an archiving solution where we can automatically strip these messages of a certain age seems to be in order. The 75Gb limit just makes it that much more urgent.

It appears that GFI uses journaling, which seems better than stub files, at least to me. I understand it doesn't make old message viewing or retrieval as seamless, but it would still be workable.
 
Can you cite where you read that stub files are bad? We've been running EV since the KVS days and overall been very happy with it. Yes, its enterprise grade and it requires additional resources, but I don't think there are too many options at that level.

The only issue I see with Ex2010 and its archiving is that it forces you to keep the archives in the same DB as the regular mailbox. I've heard that in the future, they would allow the archives to be kept in a different DB, which could be placed on lower cost disk for access.
 
Darthkim said:
Can you cite where you read that stub files are bad?
Click to expand...

Technet:
Eliminated third-party archiving stub files The primary end-user benefit of eliminating stub files when using third-party archiving solutions is providing a consistent mailbox experience from multiple clients. The deployment and management of additional third-party Outlook add-ins are required to make the use of stub solutions work with Outlook. Although some solutions offer access to the archive through Outlook Web Access, none of those solutions offer Windows Mobile device access. In most cases, stub file item size is from 10 to15 kilobytes (KB). The amount of usable data contained in a stub file of that size is minimal, usually a few paragraphs or less. Some of the archival solution providers recommend a stub file size from 1 to 2 KB, which only contains the message header information. Typically, the data accessed in the archive by using a stub solution decreases as the message lifespan increases. If the majority of mail that the user accesses is between current time and two years old, make the mailbox size capable of supporting the messages in that timeframe. For example, if the user mailbox increases by 1 GB per year, the user needs a 3-GB mailbox. If you define your large mailbox design so that the majority of historical data that is required by users remains in their mailboxes, stubs are not required. You still may require a third-party archive for legal requirements and the occasional user access request. If you are retaining a few months of stub files, the number of search hits to review them is relatively low. Therefore, locating the desired message without having to make too many searches through the archive is realistic. However, if several hundred thousand messages are retained, the probability of successfully locating a specific message is challenging when you do not have a significant portion of the message body available. As a result, users probably need to go to the archive multiple times and retrieve many messages to find the desired message. Third-party archiving solutions solve the problem of supporting mailboxes that cannot be bound by size limits and regulatory compliance requirements for archival of all e-mail traffic. However, when deployed, these solutions should be configured to move the e-mail content out of the mailbox without retaining stub files in the mailbox.
Click to expand...

Only can go by what I read. Not sure if it would apply in my scenario, but we do have users with 80,000+ messages in a single mailbox.
 
That's an interesting white paper, but would hardly call it authoritative.

I'm wondering what the paper for 2010 would look like since they have archiving built in.

Alot of the points that they raise in that white paper has been mitigated (since even before the e2k7 rollout). For one, Enterprise vault has always worked in OWA, going back to E2K.
The stub size is customizeable, but we leave enough for the user to find what they are looking for. If not, the archive solution has its own search engine, from where you can find information.

I've always used whichever desktop search solution built into the OS (now win7 64 bit) and haven't had any issues with finding any info. (even archived stuff).
 
The best archiving solutions don't use stubs or journaling, but they make EXACT re-productions of the live store using the exchange log files. This is what Mimosa (now Iron Mountain) NearPoint does. This is the only way to retain 100% of meta data (any other solution looses some small amount, wether or not that is important is up to each enviroment to decide)., but as I said, they don't sell anything under 200, and it's expensive. 500 users is close to $45k with a decent discount. They where also almost to the point where they had things worked out with MS that their live stores could be used as DR stores. They would mount directly in Exchange. Not sure if this has made it to the live product.

Now that you know about that method, you can probably come up with a few reasons as to why any other method isn't as good for a variety of reasons. When it comes to stubs or no stubs, I wouldn't worry about it. IMO, stubs mean a more end-user friendly experience, as they do not ALWAYS have to go to the archive folder set within the mailbox.
 
You must log in or register to reply here.
Back
Top