ContributionsMost RecentMost LikesSolutionsRe: 64-bit supportFor those of you that are still curious, the was an e-mail push from the Symantec Protection Network team that I just received saying support for 64-bit and Windows 2008 operating systems will arrive in September.Re: 64-bit supportI too would LOVE an update on this. Perhaps a quick explanation of what is taking so long and of course another best estimate for it's date of arrival. Thanks.Re: 64-bit supportAre we on target for a May or June release?Re: Migrate from GFI MailArchiver 5 Iwish I had more to report. Although we do plan on doing this in the future, it's probably at least 6 months away if not longer, soI haven't done any testing. If you do end up doing this procedure before I do, I'd appreciate any input that you have. Good luck! Migrate from GFI MailArchiver 5 We are currently evaluating the possibility of migrating old archive stores from GFI MailArchiver 5 to Symantec Enterprise Vault. As far as I can tell, it's not going to be a simple process, but we're determined to make it work. Has anyone had experience with this? Is it feasible at all for 30 users? The best route would probably be to export all e-mails a user received (To:, CC;, and BCC:) to a PST and then import them into Enterprise Vault from there. That way the permissions would be correct. We'd likely see duplicates if they were archived and still exist in the user's current mailbox, but that we can live with. I haven't figured out if it's possible to export from GFI to anything but individual .eml files, so if anyone has experience, please speak up. Thanks. SolvedRe: 64-bit support Thanks Richard. I can stop pestering you about that for a few months now. Phil 64-bit support I'll keep this simple. Approximate time frame for 64-bit support: a) End of year b) First half of 2009 c) Second half of 2009 d) 2010 and beyond SolvedAmazon S3 Backup Services I couldn't help but notice the useS3BackupSvc XML key in the "C:\Program Files\Symantec Protection Network\BackupAgent\.state\balocalsettings.xml" file. Is this going to be a feature somewhere down the line? I'm tempering my enthusiasm for the time being, but I think that would be quite neat. simc-pk SolvedRe: Sorely needed improvements Thanks Richard, I appreciate the time that went into that post. I'm not usually this pushy, but I've just reached my limit with remote backup products over the past few months. My frustration is a culmination of interactions with several online backup companies. I would like to make clear that it hasnever been an issue with the people behind the product, it's always purely business related. I do appreciate the calm explanations I receive from people like yourself. I headed over to Speakeasy to test my upstream bandwidth on our T-1. As I expected, it was close to the theoretical limit coming in at 1415 kbps. This is during our peak business hours as well. The disk activity for theparticular server with the large initial backup isn'theavily taxed by any means. They are small files, and I understand the overhead with that, but the actual effect I'm seeing seems quite absurd. I checked the latency between my server and the particular Symantec server[204.132.59.80] that I'm currentlyuploading to and it was a reasonable 40-50ms. A few traceroutes didn't reveal anything particularly useful either. I have dealt with tech support a few times on a number of issues. Occasionally they're helpful, although more often they're not, but it's through no fault of their own. The questions/compaints that I have simply don't have fixes for the time being. If you really think that tech support will be helpful in the case of speeding up the uploads, I will give it a shot, but I don't really hold out much hope. Is there a beta test program that I can sign up forto testSPNRemote Backup? Thanks again. simc-pk Update: I spoke with tech support and they basically surmised that it was my smaller file sizes that created the overhead that is grinding the process to a near halt. Average file size for the first 11GB is 100KB. They said they'd look into any possible hacks to force the server to handle more small files at a time to increase performance, but they weren't very hopeful. Message Edited by simc-pk on 11-04-2008 01:14 PM Re: Sorely needed improvements I'd like to touch on one more issue that I think is of utmost importance. The speed of the backup is quite poor. I have a 70 GB seed backup that I started on Oct. 30th. It is now Nov. 4th and it's 11% finished. At this rate, it will take me a month and a half to finish the initial backup. There needs to be an option to send a CD in for the initial backup or the speeds need to improve. My back of the napkin calculation tells me we're transferring around 150 kbps or 18 KB/s (slightly faster than ISDN speed). That would have been awesome in 1995. Is this issue being dealt with? What needs to be done from Symantec's side to improve this? How long can something like that take? I understand that speed is less of an issue after the initial backup, but getting to that point is a long way off.