Tags

About Me

I'm Rolf Kaiser. I've ridden the wave from 3-guys-in-a-garage, to an acquisition by a big software company, and have built a string of startups since. This blog is a little compendium of tips and tricks so hopefully the next guy doesn't have to reinvent the wheel.

Did another email migration, about 50K emails, to Google Apps last week, this time from a very ancient mail system on Verio. A few more notes to add from this time around:

First step was to lower the TTL to 600 on the MX records.

Verio offers both an IMAP and POP interface, with ports documented here.

The Verio username to authenticate the email account is the person’s mailbox name (e.g., “joe”). It is not the username used to log into the Verio control panel. This wasn’t documented anywhere. If you use the latter, you can actually set up an IMAP account in Outlook with it, send and receive mails successfully (from joe’s account no less!), but no mail is synced. So once I figured this out, I could set up an IMAP account and downloaded all 50K emails, 3GB worth, over the course of a day.

However none of the official migration tools from Google worked for various reasons:

The Data Migration Service was the first option, but failed since the Verio server lacks a valid SSL certification. Verio also uses usernames (not email addresses) to authenticate IMAP, which the tool doesn’t allow.

Then tried GAMME, but never could configure it to authenticate with this ancient mail server. Looks like it was using Dovecot but kept returning garbage.

Next option was Mail Fetcher – but that doesn’t work since in this case we’re fetching from the same address, which isn’t allowed. If the MX records still point to the old server I don’t see why they’d prevent this since that seems like a perfect scenario for this feature.

Then went to Google Apps Migration for Microsoft Outlook – however, this only works on PSTs (generated by a POP account) and not the OSTs used by IMAP accounts. This too, wasn’t documented. So I had to spend another day syncing to Outlook via a new POP account. So I then launched the tool but unfortunately, I could only get ~ 100 mails to sync at a time before it errored out. So I gave up on this.

This left me with only the “Outlook copy-paste” option. So I set up an IMAP account in Outlook for Google Apps, created a new folder in it, unsubscribed all other folders I could, disabled scheduled Send/Receive, copied all 50K emails from the Verio POP account to this, and then let it Synchronize.

Unfortunately Outlook throws an ugly error dialog and halts the synchronization when it tries to sync a message that’s bigger than 25MB so I had to keep manually restarting it. Hopefully this is fixed in the next version of Outlook so it can continue in the background.

But a few days of this and everything finally made it up to the Google Apps folder. I then logged into the webmail interface, and moved all the mails to the Inbox and deleted the temporary label.

Last, I switched the MX records to point to Google’s and raised the TTL to a more normal 3600.

Looks like it was all successful, and the email is in a much better, more reliable, and more secure system now.

In the Plesk dashboard (tested in v9.5.4), go to Home->Domains->yourdomain.com->SSL Certificates, and add a new one. Paste in, or upload your certificate file for “Certificate” and the bundle file for “CA Certificate”. I think the first time through, you may have to add in the private key file as well.

Go up a level to Web Hosting Settings and select the new certificate you just made.

Go to Home->Services Management, and stop Apache and then start it. This step may be extraneous.

You’re not done yet! Now put the bundle file, certificate, and private key somewhere safe on the server filesystem. The first two may now be in /usr/local/psa/var/certificates/ but it’s not clear they are ever used – at any rate we’ll ignore them.

By default Outlook sticks your data files on your C: drive, and makes it very difficult to change that. This can present a problem if your C: drive is getting full, or if you simply want to keep them elsewhere. Today my entire Outlook setup crashed and got corrupted – and none of my 4 accounts could be opened. Fortunately I use IMAP so recovering them from the servers would be possible, but I needed to get Outlook running again.

It looks like things changed in Outlook 2013 (specifically now there are OST and PST files separately, the OST’s being the big ones as they have the email), so the procedure to move a data file from before, didn’t work for me. After Googling extensively and trying various things, including a ForcePST registry setting, I settled on using a directory symbolic link – which was the only thing that worked. So do the following (this was tested on Windows 8.1):

Your data files should now be in the new place, since Outlook is fooled into still thinking they’re in the old location. Resyncing should work now. If it doesn’t you may need to delete your accounts and recreate them, but the important part is the new OST’s will be in the desired location.

See the download link in this post. I expected to see it in the Windows Store, since that is how it’s deployed, but it wasn’t there (I looked under Productivity too). It might be there by now. Once you get it started, it installs fine; took maybe an hour to download the 3GB update, and rebooted a few times.

When you get it installed you need to go through the first-time configuration. I selected “Customize” on the settings so I could see what Microsoft wanted to do. Check each one carefully. In my case I did not want to use a Microsoft account for the PC (I want to use a local account only), so I followed the “bogus address” advice in this link. What’s interesting is they really hid this workaround even in the final release – pretty aggressive.

I needed to improve the Start Button, and make it boot to the desktop automatically via the steps at the above link. It’s still not ideal; see below.

It looks like it dropped a few of my settings:

The desktop background changed. I don’t know if I had a custom one before; maybe this is the default for 8.1 which is different from the default for 8.

My “special” folders (Documents, Music, Pictures, etc.) are in non-default locations. Windows kept the setting for Documents but for some reason lost the settings for the others so I had to reset the paths (right-click on the folder and go to Properties/Location). I think this happened since they apparently dropped the concept of Libraries in 8.1.

Cisco AnyConnect VPN was incompatible and needed to be reinstalled.

I re-ran the anyconnect-win-3.1.01065-web-deploy-k9.exe installer, and it picked up my old settings.

WAMPServer needs a few changes to get working again:

Reinstall the Apache and MySQL services using the tray icon.

Win 8.1 might run it as a different user, so I had to re-grant write permission to the log paths. This error will show up in the Apache error log. In my case I ran httpd from the command line to see where it choked.

Netbeans 7.4RC2 seemed very slow to open PHP projects. I reinstalled it. I don’t know if this was necessary but it seems OK now.

The most time consuming repair was TortoiseGit. It would not run, nor could it be reinstalled, repaired, or even uninstalled due to this error:

See my other blog post for the fix – other folks have since reported other workarounds (in the Google Code issue linked in my post).

So what changed?

I don’t see a lot of differences, but in the first 24 hours I noticed these:

The Start button is back but it doesn’t do what you want – it just pulls up Metro. So really no improvement. This review has some 3rd party options but I haven’t tried them.

Search is more useful on desktop; it now displays a list of programs matching the term, rather than a tile view.

This is indicative of, I think, a wider Windows 8.1 problem, but I ran into this pretty serious problem with TortoiseGit when upgrading to 8.1. TortoiseGit won’t start, so when you try to repair it, you end up with an error dialog. Worse, it could not be reinstalled, repaired, or even uninstalled!

You get this in the event log:

Product: TortoiseGit 1.8.5.0 (64 bit) -- Error 1723. There is a problem with this Windows Installer package. A DLL required for this install to complete could not be run. Contact your support personnel or package vendor. Action KillCache, entry: TerminateCache, library: C:\WINDOWS\Installer\MSI1CC.tmp

After much trial and error I finally fixed it via:

Export your entire registry key via:

c:\Windows\Installer>regedit /E:A c:\Users\MyName\Desktop\reg.txt

Then grep through this big file (about 11 MB in my case) and find every key or value that looks related to the MSI, e.g.,

Now you should be able to re-download and install the MSI, overwriting the proper registry settings your deleted, as well as the files. For good measure, I did this via the command line as an administrator: