Archive for the ‘Migration’ Category

HowTo: Move WordPress/MySQL from a local server to a GoDaddy hosted environment

November 15th, 2011 by Paul Sterley | No Comments | Filed in Hosting, Migration

I just moved a couple of blogs from a local server to a GoDaddy hosted environment. Here are the steps I went through.

First, find out what version of WordPress GoDaddy’s hosting center is currently using. Upgrade your local blog to that version before you start, and verify that your plug-ins work. Update the plug-ins if necessary before you move the blog.

When you’re ready to move it, the first thing to do is back up your MySQL database. Use something like MySQL Administrator to back it up to a .sql file.

Log into your GoDaddy environment and use the hosting center to install a WordPress application with MySQL database. Open your new hosted WordPress blog (empty at this point) to make sure it works. Then proceed.

Now it’s time to import your MySQL database. But first we have a choice to make:

Do you want direct access to manage your database using your own admin tools, or are you content with the web-based one GoDaddy provides?
Is your database VERY LARGE? So large that it would be exceeding difficult for you to edit the .sql file with a text editor?

If you answered NO to both of these questions, use “Option A: Edit your .sql file to reflect the new database name.”
If you answered YES to either of these questions, skip down to “Option B: Create the database and reconnect WordPress to the new one”.

Option A: Edit your .sql file to reflect the new database name:

The next step is to import your .sql backup file into the new GoDaddy MySQL database. But first you have to edit the .sql file and change the database name in three places, to match the database name the GoDaddy created for you.

You’re looking for three lines near the top of your SQL file. They start with “Create schema”, “CREATE DATABASE IF NOT EXISTS”, and “USE”.
Replace the database name on each of these lines with the one that GoDaddy created.

Option B: Create the database and reconnect WordPress to the new one
Note: Skip this section if you chose to use Option A.

Go to the DATABASES section of the hosting center, and choose to create a new database.
Note: The dialog for database creation has two very important features.
1. A radio button that allows you to choose whether your database will be externally directly accessible or not (see image below.)

 

2. The ability to choose the name of your database, instead of the random name that the WordPress installer chooses. The database name will be the same as the user name. The dialog does not make this clear, so when it asks for a username, that’s where you put the database name.

If your database is very large, and it would be difficult to edit the .sql file, you can create the new database using the same database name as it had on the local server. Then you do not need to edit the .sql file.

Now that you have created a fresh database, use either your local admin tools, or the web-based tools that GoDaddy provides, to import the .sql file into your new database.

Delete the database that GoDaddy created while installing WordPress.

Now that you have your database populated, edit your wp-config.php file to point at it.
To do this, fire up an FTP client and point it at your new hosted environment.

The wp-config.php file is in the folder where you installed WordPress. This might be the root folder, or it might not, if you chose to install it into a folder. Find your WordPress installation, and find your wp-admin.php file. Download it to your workstation for editing.

When editing the wp-admin.php file, be careful. I used Notepad.exe built into Windows, and it corrupted the file. It took several tries before I figured out what was happening. You might want to try another text editor, or an HTML editor. make backup copies, and when you’ve saved the file, open it again to verify that it didn’t get scrambled.

In the wp-config.php file, you’re looking for your database name. It should exist in three places: DN_NAME, DB_USER, and DB_HOST. GoDaddy creates the username the same as the database name. Edit this file to point at the correct database, and upload it back to your WordPress folder.

Upload your WordPress content.

I recommend that you create a “new blog backup” folder on your admin workstation, and use your FTP software to download the empty WordPress installation to your admin station, so that if something goes wrong with uploading the content, you can put the old files back in, or at least fish files out of that backup folder if you are troubleshooting. Since the new installation has no content, it will only take a few seconds to make a backup of it, and it might save you a lot of time.

Use your FTP software to upload your wp-content folder from your local installation. I believe that you do not want to upload any other folders – just wp-content and all of its subfolders. My suggestion is to NOT overwrite any files.

That being said, I had some difficulty with my migration at this point, and what I ended up doing was creating the folder first, uploading my content into it, and THEN installing WordPress using the GoDaddy wizard. I am not sure this was necessary. It may be that my fumbling around with which folders to upload created my problem.

Now you’re ready to try out your blog! If all went well, it should work as expected at this point.

Good luck!

 

Change the MAC address in an ESXi VM

April 8th, 2010 by Paul Sterley | No Comments | Filed in ESXi, Hardware, Migration, Not in the Windows Box, Virtualization, Windows Server

 

Last year, I messed around with changing the MAC address in an ESXi VM to avoid some problems with a license manager app that binds to the MAC address of the NIC when you install and license it. I was unsuccessful in my attempt to change the MAC address then. The MAC address in the VM Settings window refuses to allow you to set the first six digits, requiring you to keep the vendor code of a VMware NIC.

 

The NIC driver inside Windows, however, has an option to set the MAC address. Go to the NIC adapter properties, Advanced tab, and select NetworkAddress.

 

nicpropertiesmacaddress 

The server now thinks it has the MAC address you specified.

It works for IPCONFIG /ALL, it works for workstations that ping the server and then check their ARP cache, and it works for FlexLM, the aforementioned license manager software.

 

NOTE: I tested this in Windows 2003 SP2 on ESXi 3.5 and 4.0, and Windows 2008 SBS Edition on ESXi 4.0.

 

Further note: If you do this, it is critical that you NEVER light up the network card in your old server, which has the same MAC address, on the same physical segment of your network. It will bring down connectivity to your new server.

It is possible that you can avoid this problem and continue to use your old server in some other capacity if you change its MAC address, or if you install a different NIC. If the NIC with the matching MAC adddress is onboard though, you may still have trouble connecting to your new server from your old one. This bears testing at some future date when I have way too much time on my hands.

Tags: ,

Operating System Discussion: Windows 2003 vs 2008? Windows XP vs 7?

October 22nd, 2009 by Paul Sterley | No Comments | Filed in Antivirus Software, Migration, Security, Virtualization, Windows Server, Workstation OS

Server Operating Systems:

At this time, I see little reason to upgrade to Windows 2008. For what most servers do, Windows 2003 does the job just fine, and is still being supported (with hot-fixes, but not Service Packs) by Microsoft. The software you run on it likes 2003 just fine. Before long, new hardware will be built with Windows 2008 in mind, and Windows 2003 drivers for your hardware might get harder to find. However, I recommend moving to virtual servers at that time, and it will then not be necessary to have Windows drivers for your new server. The virtualization layer (hypervisor) will handle that, and the “virtual hardware” assigned to your server will work fine with Windows 2003 for many years to come.

Exchange 2007? Let’s just not talk about that right now. This is an OS discussion, and I will just say that I intend to resist that one as long as possible too, until Microsoft remembers that if we wanted to manage everything with command lines and scripts, we’d be using Linux with Sendmail or some open-source, command-line driven equivalent.

Terminal Servers, however, could benefit from a Windows 2008 upgrade. Terminal Services (now called Remote Desktop Services) functions have been greatly improved in 2008, specifically in the area of publishing applications seamlessly without giving the users access to the entire desktop – and in the area of remote printing. Remote printing has been a major thorn in your side, and Windows 2008 can help you with that. I believe the new Terminal Services is web-accessible, making it very easy to set up new workstations to use it.

Here is another, more detailed discussion of those improvements.

Is it worth the cost to upgrade? Your customer will have to decide.
Workstation Operating Systems:

I am happy to say that most of my customers have managed to skip right over Windows Vista.

I have not had much experience yet with Windows 7, but my limited experience suggests that Microsoft learned a lot from their Vista flop, and worked to smooth out the rough edges that made people despise Vista. My limited experience also suggests that Windows 7 is still too new for widespread adoption, with pitfalls lurking due to software applications and drivers not being fully compatible with Windows 7 yet.

That being said, we are entering a more sophisticated age of malware and viruses, and it may be time to leave behind the less intrusive security measures we have been enjoying with Windows XP, which is now allowing more and more PCs to become infected – just as it happened with Windows 2000. It will be a rocky time, when we try to balance having appropriate access to our own computers against making them wide open to attacks. Some software will work OK when installed with an administrative account and then used by someone else. Some will not. We’ll have to work out which software requires which installation method, and perhaps sometimes temporarily give a user administrative access to their machine to get something installed and configured, then take it away to help protect them. We can do this with Windows XP for now, and then later with Windows 7.

For the time being, I will recommend that my customers continue to purchase workstations that come with Windows 7 licenses, but have a downgrade to XP installed on them. This will continue for as long as possible, until we start seeing the rate of virus infection become too high, or other factors necessitate a change. The age-old cycle of viruses and antivirus software one-upping each other continues, and maybe we’ll see a comeback of the antivirus software.

For now, Dell is offering workstations with Windows 7 licenses, with Windows XP installed – but only in the Business section.

So, am I just being resistant to change? There is some of that, but I do not embrace change for its own sake. there has to be some benefit, other than the many hours of billable work I could get from pushing customers into unfamilair operating systems just because Microsoft wants to keep their money machine rolling. Let me just say that I was determined to be open-minded abot Vista. I gave it a solid try. When asked whether I wanted Vista or XP on my company-supplied laptop, I chose Vista. I suffered it for 6 months, before finally deciding that enough was enough. I had passed the learning curve and the pain continued. I went back to XP. So no, it is not just resistance to change. There are good reasons for me to hold back. They are related to deficiencies of the new OSes, financial reasons, and the general difficulty of being among the first to move to new technology.

Unless there are specific, compelling benefits to be gained in each scenario, then you won’t see me jumping first to new versions of the OS. Not me, not this time.

Tags: , , , , , , ,

New Whiz-bangs in VMware Converter 4 Standalone

March 28th, 2009 by Paul Sterley | No Comments | Filed in Migration, P2V

 

 

There are some cool things about the new version:

 

1.    Supports 64-bit Windows 2008/Vista.

 

2.    No longer requires licensed version to convert a physical source to an ESXi VM from a management station without installing Converter on the source machine (still installs agent of course).

 

3.    Has options for telling individual services to stop/start or change startup state. This will be VERY helpful for converting a machine and settings services which are known to cause problems to “Disabled” on the target VM, without changing the source machine. Then we can boot the VM, fix stuff, and do what we want with those services. Very handy.

 

4.    Synchronize source and destination. This will synchronize changes that happen to the source machine during the cloning process.

 

5.    Power off source machine after cloning (not sure if this is new, but it’s cool).

 

6.    Status window now includes transfer rate as well as percentage and estimated running time.

  

 

I am currently running a conversion of an SBS2008 VM from Hyper-V to ESXi. Both hosts are Quad-Core white-boxes with SATA ICH8 controllers on a gigabit network with a high quality HP switch. I’m getting about 10.8 MB/s. Not great, but at least it tells me how it is doing.

 

VMware Converter 4 Download link (requires login)

 

vc4progress 

 

 

 

Tags: , ,

Why Virtualize a Perfectly Good Working SBS2003 Server?

March 15th, 2009 by Paul Sterley | No Comments | Filed in Exchange Server, Hardware, Migration, Virtualization, Windows Server

I am a network consultant. I specialize in migration projects such as upgrading NT4 to Windows 2003/2008, migrating from Exchange 5.5 to 2003/2007, retiring domain controllers and promoting new ones, etc.   I also do my fair share of emptying temp folders, removing malware, and fiddling with backup systems. I tell you this so you will understand that the idea of performing migration projects and reconfiguring networks does not intimidate me. However, I also know that there are always more details and time-sinks involved in such an endeavor than you remember.

Not long ago, my business was running on an HP Proliant DL380 server with Small Business Server 2003 on it. My server was running fine. It was not a brand new server, but was not showing any signs of instability or failure either. I had spare hard disks available, ready to hot-swap, and I had reliable backups.

When I became familiar with virtualization, the idea of virtualizing my server entered my head and percolated there for a while. Virtualization is cool, I thought, but my current server is working fine. Why go to the trouble?

Then I advanced my thinking a couple of years ahead. Then my server would be long since out of warranty, parts would be difficult to find, and I might find myself at the mercy of used hard disk resellers on eBay. Worse than that, if I had to replace a motherboard or hard disk controller, I might find that my server was not so happy with that idea.

Backup software has been claiming for some time now to be able to do “bare metal”, “hardware-independent” restore operations – but if you’ve ever tried one of those, you find out quickly that if there aren’t lots of asterisks and disclaimers in those feature lists, there should be. It’s never as easy as they claim, and the more different the new hardware is, the less likely it is to succeed. If it does succeed, the result is usually somewhat slower, and prone to quirks for the rest of its life.

Then I thought about how a restore works for a virtualized server. The underlying hardware can be totally different, but the hypervisor presents the same hardware layer to the operating system of the VM – so in the event my server failed, I could load up the hypervisor on a completely new, different server (a much faster one), and restore without a hitch.

Failures aside, I also thought about what would happen if I wanted to continue using SBS2003 and do a planned migration from one server to another. I’d have to load up a fresh SBS2003 instance, use ADMT, or manually migrate my user accounts and workstations. Then I would need to install my LOB apps, and migrate databases, files, printers, etc. If I wasn’t using ADMT, or if for some reason ADMT failed on my workstations (you and I know how reliable ADMT is for workstation migration), I’d be manually migrating them. That’s always at least a full weekend worth of work, with another couple of weeks of minor adjustments – a little detail here, a missed setting there. That’s no fun.

With a virtual server, I’d just copy it from one server to the other and be done with it. Then I could spend the rest of my weekend with friends and family, riding my ATV in the woods.

Finally, I thought about upgrades of software on my server. The last upgrade of my accounting software was done with my heart in my throat. If it didn’t work, how well would my backups protect me? How much time and effort would I spend rolling back? The antivirus software upgrade was even more of a concern. You never know when that’s going to backfire on you, and what the cleanup will be like.

With a virtual server, I would simply take a snapshot before beginning the upgrade, and when I was satisfied that it was working properly, remove the snapshot. If it went sideways on me, I’d just revert to the snapshot. If there was changed data after the snapshot, that’s not too difficult to back up and restore to the server after reverting. I’d certainly rather do that than sweat it out trying to repair the damage.

In the end, I decided to go ahead with virtualizing my SBS2003 server. I’m glad I did, and I haven’t looked back.

Tags: