PSTs? Seriously?
Even Microsoft is walking away from and disavowing PSTs.
We found migrating into Exchange using PSTs is really slow and inefficient.
But Zimbra wants to perpetuate this. See: How to use the new Zimbra Migration Tool: pst file to Zimbra Desktop.
Ok -- if you have a handful of users -- fine. If you have a hundred or so and are motivation-challenged or not very good at systems administration -- sure.
If you're an enterprise of any size use real tools. Pick imapsync for your email migration (follow our guide in reverse) and drop everything else if you have to.
Showing posts with label PST. Show all posts
Showing posts with label PST. Show all posts
Thursday, January 19, 2017
Tuesday, August 11, 2015
Au revoir #MSFTExchange PST
Our love/hate relationship with PSTs is well-documented in our postings.
It is therefore with an odd sense of both elation and dread that we see Redmond itself advocating Deep Sixing PST Files !
Elation is obvious. Dread because.... what proprietary data format horror will they come up with next?
Still, a good read with excellent references for how to handle your transition.
It is therefore with an odd sense of both elation and dread that we see Redmond itself advocating Deep Sixing PST Files !
Elation is obvious. Dread because.... what proprietary data format horror will they come up with next?
Still, a good read with excellent references for how to handle your transition.
Tuesday, February 25, 2014
imapsync vs PST: Tonnage and Speed
Our first lab test of volume for imapsync resulted in an average throughput of 11.8 message/second, or 830 kb/second transferring 3013 messages with 358 skipped messages (I think that had to do with headers and the way we treated them).
We then went into the real world with a Boston-based firm and compared moving PSTs to moving via imapsync.
One PST for a user took 15 minutes to export client-side. We did not even bother continuing to time after that.
Using imapsync (for email) and our mCalReader (calendars, tasks, contacts) we read that user AND TWO OTHERS and inserted all three in 8 minutes.
Or imapsync has at LEAST 6 times the throughput.
Our conclusion was that imapsync is MUCH faster. Our further conclusion is that for purposes of migration PSTs fall far short of ideal. PSTs really suck to tell you the truth.
In going through some of our previous posts, I discovered an interesting factoid that we published years ago when comparing client-side migration speed vs. server-side migration speed. Server-side was 2-3 time faster on insertion than a client side migration just for calendars.
We then went into the real world with a Boston-based firm and compared moving PSTs to moving via imapsync.
One PST for a user took 15 minutes to export client-side. We did not even bother continuing to time after that.
Using imapsync (for email) and our mCalReader (calendars, tasks, contacts) we read that user AND TWO OTHERS and inserted all three in 8 minutes.
Or imapsync has at LEAST 6 times the throughput.
Our conclusion was that imapsync is MUCH faster. Our further conclusion is that for purposes of migration PSTs fall far short of ideal. PSTs really suck to tell you the truth.
In going through some of our previous posts, I discovered an interesting factoid that we published years ago when comparing client-side migration speed vs. server-side migration speed. Server-side was 2-3 time faster on insertion than a client side migration just for calendars.
Thursday, October 23, 2008
Calendar migration into Zarafa
So we got a request over the transom to see if we could migrate Meeting Maker data into Zarafa.
Their online demo bears a really close resemblance to OWA. This part I do not get: If you want to choose to not be part of the Microsoft Global Co-Prosperity Sphere, why on earth do you want the interface to be exactly the same? It's like not wanting to watch Seinfeld itself, only a high school acting troupe doing the exact same gags and plots. If that's what you want in front of you the original is much better.
However, short answer is NO. Mainly their mechanism to put in data is via PSTs (using ExMerge), with some scripts to migrate contacts via CSV. We don't produce PSTs (it is a real pain and we do not get much call for it). We can go into Exchange via CDO and EWS, and we can produce ICS, but none of the mechanisms we see in their Wiki will let us put in calendar data with the fidelity we are known for.
Their online demo bears a really close resemblance to OWA. This part I do not get: If you want to choose to not be part of the Microsoft Global Co-Prosperity Sphere, why on earth do you want the interface to be exactly the same? It's like not wanting to watch Seinfeld itself, only a high school acting troupe doing the exact same gags and plots. If that's what you want in front of you the original is much better.
However, short answer is NO. Mainly their mechanism to put in data is via PSTs (using ExMerge), with some scripts to migrate contacts via CSV. We don't produce PSTs (it is a real pain and we do not get much call for it). We can go into Exchange via CDO and EWS, and we can produce ICS, but none of the mechanisms we see in their Wiki will let us put in calendar data with the fidelity we are known for.
Subscribe to:
Posts (Atom)