Upgrading from Shared Hosting – Part 4 – Considering Google Apps

by Pat Heyman | Oct 4, 2012 | Essays, Pat

Major Update

Although Google seems to be determined to hide it, you can migrate much of your existing account using the methods documented here. For example:

1. Log in to google with the account you want to transfer data from.
2. Now go to this link. You’ll need to change the e-mail addresses to match your source and destination accounts.
   https://www.google.com/dashboard/migration/?srcAccount=source@gmail.com&dstAccount=detination@yourdomain.com
3. Choose the accounts that you want to transfer (it is irreversible) and hit go. This works for youtube, picasa, and groups, but most significantly not google play.
4. Moving e-mail, contacts, and calendars is pretty easy, so I’m not covering it here.

Considering Google Apps

The decision to use Google Apps as an e-mail provider is a big one, because you’re getting much more than an e-mail provider. The ramifications can be extremely annoying. First, we’ll deal with reasons to use Google Apps:

• Great spam filtering
• Top notch network and redundancy. If Google’s network fails, the world ends (or something like that).
• Good web user interface
• POP3 and IMAP compliant
• Shareable calendars
• Integrates well with Android. Works natively with iPhone
• Generous storage space
• Free for up to ten “users”
• Access to other Google Apps services
• Customizable landing pages and urls, e.g. mail.yourdomain.com

Downsides:

• Concerns over privacy and use of your data to target marketing to you.
• Practically impossible to reconcile personal Google accounts with Google Apps account.
• Organization approach is not conducive to a single person with a domain name for a personal site/e-mail/blog.
• Confusing login pages.
• No traditional e-mail aliases.

That doesn’t sound like much of a downside, but the second one is HUGE!!!!!!!!.

If you already have a Google account for services like Picasa, Youtube, and Play store, you will find it practically impossible to migrate your data to the new account. If you have an Android, you will not be able to transfer your app purchases to your new account. This means that you will have to sync at least two accounts on your phone. Moreover, you’ll have to decide which account you want to put new purchases on. If you want your Youtube channel to be under your own domain name instead of your original account, you basically have to re-upload every single video. And if you have a popular channel or a lot of comments, you lose all of that history. If you have a lot of contacts in Google+, huge pain there too (although I can’t imagine anyone actually using Google+.)

Google Apps users have been complaining about these issues for more than five years with very little progress in resolving them. Part of the problem stems from the assumption that only “organizations” will use Google Apps. The whole thing is geared toward businesses that need e-mail, calendars, and a word processor/spreadsheet. Google seems completely oblivious to the idea that there are people who own their own domain name and just want to move their existing Google accounts over to Google Apps. I mean, really, unless I divorce myself or fire myself, I’m never going to leave the patheyman.com organization. And if I do decide that I like heymanator.com better, then I don’t want to have to create a new heymanator Google Apps account. I want to simply transfer my account from one domain to another.

An additional problem is the Google sign on pages. To log in to Google Apps, you have to go to google.com/a/yourdomain.com. Then you set up a user, you@yourdomain.com. You log in to Google Apps and play around. When you log out, you’ll be taken to a generic Google log in page. If you try to log in to with your e-mail address and password, instead of logging in to Google Apps, it will create a personal account with that e-mail and then tell you that you have a conflicting accounts because you have a Google Apps account and a personal Google account with the same e-mail address. I don’t know what idiot at Google thought this was a good idea, but it’s the stupidest thing in the whole world!

While we’re talking about sign on pages, you can also “customize” the sign on page and apps with your own logo and colors, but the image size can be no bigger than 143×59 pixels, and they’ll stretch it if it’s smaller. It’s just silly. Moreover, the main account sign on page is not customized—only the gmail, calendar, contacts, and documents apps are customized. Seriously, Google. You need to hire me to tell you how to run this aspect of your business.

Google Apps does not let you create traditional e-mail aliases. Instead they suggest that you add a dot or plus to your e-mail address, because me+dumboffer@yourdomain.com will go to me@yourdomain.com. Stupid, right? Especially if you’ve already got all your bills going to banking@yourdomain.com. A much better workaround is to create a “user” (account) and then tell Google Apps to send all e-mail that does not belong to an actual account to that e-mail. You can use e-mail forwarding rules to send the mail to the appropriate person. Of course, even here, Google apps has to be stupid. It makes you confirm the ability to forward e-mail to your own domain when you only have up to ten users in the first place.

I know the stupidity at work in Google Apps, but I want to use them as my e-mail provider anyway.

Okay, but I warned you. The first thing to do is open your Google Apps account. If you have 10 or fewer “users” (accounts) then the Standard (free) edition should work just fine for you. The problem is that Google likes to hide it. There is no direct link to it, and most of the guides from a year or more ago are outdated. As of October 3, 2012, the way to get to the Standard (Free) Google Apps is to go to the Google Apps page and then click the pricing link at the top. You’ll see the Standard, Business, and Premier plans, with Standard being free…YAY!!!!!

Fill out the boxes with the appropriate information, and then you will have to prove that you own the domain that you are registering for. The easy way to do this is to upload a file to your website.

1. Download the file
2. Upload the file to your webserver
3. Tell it that you did it.

Now you get to choose between Express Setup and Custom Setup. I chose Custom setup which is a huge pain in the—well—something. If you’re setting this up for just yourself or you and your wife and kid, I’d say choose the Express setup. I can’t really describe it too much, because I didn’t do it, but hey, there you go.

Tip: Throughout the set up process, keep an eye on the top center of the screen when you hit save or submit changes. Status messages will flash up there. If you get an error message, it will flash red just long enough to see that there was an error, and not quite long enough to read it, so pay attention.

As part of the set up process, you’ll need to set up one or more e-mail addresses (users). Here’s where the dashboard will lead you astray. It implies that the set up process has four steps, with the last step being “Direct email to Google Apps Mail.” You would think that this would walk you through changing your DNS settings, but you’d be wrong. It actually takes you to a screen on how to set up your mobile device with your Google Apps account.

The real fourth step is to set your DNS records so that the MX records are pointing to Google’s e-mail servers.

1. Log in to your DNS host.
2. Change your TTL (time to live) on your mx records to 300 seconds (5 minutes). If you screw up, it will only take 5 minutes for changes to take effect.
3. Change your mx records to point to Google’s servers. Namecheap.com is particularly nice in this regard, because they have an option “Google Apps” that will automagically configure your mx records correctly. If your DNS host does not provide this useful service, then you should enter the following:
   

   Hostname	Target	Type	Priority	TTL
   @	ASPMX.L.GOOGLE.com	MX	1	300
   @	ALT1.ASPMX.L.GOOGLE.com	MX	5	300
   @	ALT2.ASPMX.L.GOOGLE.com	MX	5	300
   @	ASPMX2.GOOGLEMAIL.com	MX	10	300
   @	ASPMX3.GOOGLEMAIL.com	MX	10	300

4. Once your DNS records have propagated, you can set the TTL back to whatever it was before.
5. You can now access your e-mail by going to mail.google.com/a/yourdomain.com, but you probably would prefer to go to mail.yourdomain.com. You can customize your mail, calendar, contacts, and documents (GoogleDocs) in the same way.
6. Log in to your Google Apps dashboard and in the center of the screen under “Your Google Apps” click on the settings link to gmail.
7. Under web address, click change link, and choose the url you want to use, such as mail.domain.com, and click continue.
8. It will direct you to create a CNAME pointing mail to ghs.googlehosted.com. (some DNS hosts require the ending period for CNAMES)
9. Then click done. Now rinse and repeat for calendar, contacts, and documents.
10. Now you just need to set up your mail clients and mobile devices to check Google’s servers instead of your own.

Note: Google has pretty extensive help online, but it’s organized in an obtuse way that makes finding what you need almost impossible. They also have help records for specific DNS hosts, but in the case of NameCheap.com, they didn’t mention the automagic way of doing it.
http://support.google.com/a/bin/answer.py?hl=en&answer=87127

Google’s directions for setting up custom urls for mail, et al with a fancy video and everything.

Unfortunately, I have not been able to figure out how to set up a custom URL for the main login page—only the individual apps mentioned above.

Now enjoy and regret the fruits of your labor. I had been getting 200+ spam messages a day despite training spam filters, and now I get less than five.

In future installments, I’ll talk about:

• Setting up a Linux VPS
• Making the move

Upgrading from Shared Hosting – Part 3 – Preparing to move

by Pat Heyman | Oct 3, 2012 | Essays, Pat

The essential steps in moving are:

1. Move your domain name to an alternative registrar (if your web host registered your domain name for you.
2. Move your nameservers/Edit your DNS as appropriate
3. Consider your e-mail provider
4. Choose a new account
5. Set up the account and migrate data
6. Test the site
7. Point your DNS records to your new account
8. Cancel your old account

This article will deal with steps 1 – 3.

Move your domain name to an alternative registrar

If your domain is registered by your web host, transfer it to a Registrar. There are several very inexpensive companies to choose from, and transferring extends your domain’s subscription for a year with most registrars.

All registrars ultimately send your information to ICANN. It costs them about $6.50/year to do so…so you should expect to pay at least that much. Many registrar’s make most of their money by upselling you on other services, such as private registration and webhosting (just say no to web hosting).

The basic steps are:

1. Find out from your web host how log in to their domain management module.
2. Once logged in, make sure that your domain is not locked.
3. If it is locked, you will need to request an EPP code, which will be sent to the e-mail on file. (This is designed to prevent someone from hacking your password and stealing your domain name.
4. Create an account on your new registrar, and provide them with your EPP code.
5. Done

One thing to be aware of is that some registrars also provide DNS services which will help to simplify the next step, but is certainly not necessary.

Some registrars that have gotten multiple positive reviews on webhostingtalk.com are listed below. This is neither a recommendation nor a complete list—just a convenience listing. Like the phone company, some companies hide fees in their quotes to make them appear lower.

1. namecheap.com (includes DNS services)
2. namesilo.com
3. netearthone.com
4. dynadot.com
5. moniker.com

Here are some registrars that are recommended against:

1. Godaddy (unreliable as of late)
2. Network Solutions (expensive)
3. Your current or future webhost

DNS Hosting

When/if you changed Registrars whatever name servers you were using were automatically put into the new registrar. If you are currently using your web host’s name servers, I recommend using alternative name servers (DNS hosting). DNS stands for Domain Name Server, and works like a phone directory for the internet.

When you type a website into your web browser, the request is directed to a DNS (name server). The name server tells your browser what IP address to go to. Most websites have multiple name servers in different geographical regions so that if the first one fails, the second (and third, etc.) act as a back up. You can host your own name servers, but unless you have multiple VPS or dedicated servers throughout the country, you’re better off using a DNS hosting service.

The directions below should work for most simple websites. If your needs are more complicated, then it should at least point you in the right direction.

Before we begin, there are some definitions we need to cover:

• A record: These are the “main records” and are directed at an IP address.
• CNAME: These can be thought of as a redirect to a website (or other server). For example, www is usually a CNAME that redirects back to your domain so that domain.com and www.domain.com will both go to the same place.
• MX: The MX record is the mail record that tells mail servers where to direct e-mail sent to your domain. Ideally you should have several mx records with multiple mail servers.
• Redirects: allow you to redirect a server name to almost anywhere. For example, you could point support.domain.com to www.domain.com/support/contact.html. A records and CNAMEs cannot point to a website folder or page—only servers.
• TTL: Time to Live. Your name servers are communicated to other name servers throughout the internet, and they are all sharing their records with one another. The TTL tells the other servers how long they should wait before refreshing the information. The TTL is set in seconds.

Setting up your DNS hosting

1. Find out what your current DNS records are.
2. Create an account with a DNS hosting service if your domain registrar does not provide it.
3. Re-create your DNS records in the new DNS host
4. Double check your DNS entries.
5. Change the name servers listed by your domain registrar to your new DNS host.
6. Test and make sure they work.

Choosing a DNS host

There are many reliable DNS hosts and many domain registrars provide free DNS services to customers. Namecheap.com even provides them for free to non-customers. Most of the free DNS hosts have a limit on the number of domains they will host. Some host as few as 1 for free, while others will host as many as 50.

Some free hosts that have received good feedback on webhostingtalk are listed below. Same caveats as with the registrars above.

• Namecheap.com
• clouddns.com
• pointhq.com
• Lowendbox.com has a page with a list of more free DNS hosts

Testing your new DNS:
Once you change your name servers with your registrar, you will need to wait a little while for the changes to “propagate” throughout the internet. It’s like a rumor spreading through a crowd. It can supposedly take as long as 48 hours to fully propagate, although I have noticed that changes begin to be reflected within 5-15 minutes and within a two hours, it seemed like for all practical purposes, they were propagated enough.

So with the above in mind, be aware that different testing services may have different results based on how propagated your nameservers have become. And even then, sometimes one DNS testing service comes up with weird errors when the others are reporting just fine. So if you’re receiving e-mail, and you can visit your websites, and there are no security issues, I wouldn’t worry too much about one weird DNS report.

The following sites provide free DNS testing:

• intodns.com
• dnssy.com
• thednsreport.com
• dnscolos.com

Choosing a mail server

The next step in preparing for a move is choosing an e-mail provider. There are basically four choices:

1. Use your web host provided mail server (usually only for shared hosting and managed accounts).
2. Administer your own mail server. Not recommended for newbies. Yes, it can be simple to set up with tutorials and scripts, but learning how to manage and secure it as well as deal with spam is not simple. Moreover, running your own mail server may decrease the performance of your
3. A third party mail service. There are free and paid e-mail services. List of known free services here.
4. Google Apps: Yes, I know this belongs to number 3, but it’s really deserves it’s own section, because the choice to use it is so complicated. I’ll cover it in some detail in the next installment.

I would personally recommend going with either option 1, 3, or 4 unless you really know what you’re doing. If you go with option 1, there’s nothing you need to do at this point. If you go with option 3 or 4, you’ll need to create your account and then point your mx DNS records to the mail servers they provide you with. I’ll cover how to do this with Google Apps in some detail in the next installment.

At this point you are completely mobile. It should be a smooth transition to whatever web host you choose.

In future installments, I’ll talk about

1. Considering Google Apps
2. Setting up a Linux VPS
3. Making the move

Upgrading from Shared Hosting – Part 2 – Best practices

by Pat Heyman | Oct 3, 2012 | Essays, Pat

These best practices apply no matter whether you keep your current account, upgrade your shared account, or move to a VPS or Dedicated Server. (Many of these were gleaned from readings on webhostingtalk.com and lowendbox.com.)

Pay Monthly

It can be very attractive to pay annually or even prepay several years in advance because hosting companies often provide deep discounts or “freebies” such as a free domain registration. This can be a mistake for a number of reasons:

1. You may be happy with your host now, but service or performance may deteriorate over time
2. The company may go bankrupt taking your prepaid money with it.
3. The company may be bought out, and you may not like the new management.

Make your own automated backups

Many web hosts make tout their automated back ups, but relying solely on them is not a good idea unless you like Russian Roulette. See points 2 and 3 above.

Use a host that allows shell access

Even if you use a shared account, you should still choose a host that allows shell access. This greatly facilitates making your own automated back ups.

Do not register your domain with your webhost…even if they offer free registration

It is slightly less convenient, but it tremendously adds to your mobility. If you leave web hosts, but your host registered your domain, it adds another barrier to leaving. If there is a dispute with your host, or if your host goes out of business, you still have access to your domain name, and since you made your own back ups it’s fairly easy to get back up and running without losing too much in time or content.

I’ll go over the steps in how to do this in the next installment.

Consider an alternative DNS host (nameservers)

Some web hosts, such as Lunar Pages, make it very difficult to customize your DNS records. Managing your own is slightly more complicated, but it is vastly more flexible.

I’ll go over how to do this in the next installment.

In future installments, I’ll talk about:

• Steps to take in preparing to change webhosts
• Considering Google Apps
• Setting up a Linux VPS
• Making the move