VMWare Server Build

Well with the snow came the abuse of the company VPN (will post more about that later) and some sofa / server time.

The least shocking element was the amount of work I could get down with a 3 year old and 6 week old in the house, easier to work from the sofa (no office yet) and less distractions than being the office…

So it was time to build some servers, I’ve got SonicWalls Global Management System and ManageSoft all requiring servers, also as we change things around the way we build and use servers will be changing, so I had three servers to build, (well four when we take into account the new development server for the in house digital team)

1) Windows 2K3 (64Bit) and SQL 2K5 Server for ManageSoft and SGMS usage
2) 2 x Windows 2K3 (32Bit) for ManageSoft ECM and SGMS
3) RHEL 5.4 Server for dev.

The windows servers were pretty simple. Build a new server, fully patch, then clone to a template, then join the server to AD with it’s new name and carry on with the specific requirements for the server.

Next server.
Use the fully patched template you’ve just created for your shiny new server, join to AD and you’re done, new server in under 10 minutes, sit back and rejoice at your new power…. repeat.

Three servers created in the time it would take you to create one new server.

Did the same with RHEL, so now I have my four new servers and three templates to enable me to deploy a new instance in under 10 minutes.

Nice having uninterrupted time to get stuff done – also printed out the manuals for the NSA2400 / SGMS / SSL-VPN, time to get reading…. and shortly re-configuring the NSA to make the most of the new power (before deploying to the other new NSA units via SGMS…)

“I have a cunning plan m’lord…”

OSX Migration

So it was time to replace the home Mac Mini, it had done sterling work as the main home machine serving as a home for all of our photos, music and used for general surfing, but it was certainly slowing down, the upgrade to Snow Leopard had gone well and helped prolong its life but the signs were there, time for something new and shiny.

The Mini was sitting on top of 2 x 1Tb Iomega Minimax drives which gave a useful number of extra USB boots and made for a neat tower / shrine. One drive was data the other was the time machine backup, but things had moved on, I now had a QNAP TS-439 with 4 x 2Tb (1863Gb Actual) drives installed and configured as RAID 6 (3664Gb usable) so there was plenty of storage to be had and the potential ability to recover from two drives failing.

I configured a number of iSCSI targets and using the Studio Solutions GlobalSAN iSCSI initiator connected up. This was a very simple, one minutes process and having done the same under Windows using the MicroSoft iSCSI initiator I know which I’d prefer to use in future.

I copied the data across into the relevant targets, music, photos and then setup backup using time machine to do the applications, user account and everything else other than the music and pics. To ensure everything worked I quickly re-opened iTunes and iPhoto and changed the library to the iSCSI targets, all was working lovely. Time taken to setup, 10 minutes, time to copy the data about 4 hours in total.

Now the migration, shut down the mac mini, spend an hour moving all the kit around and tidying up the wires and then for the moment of truth. Fire up the new mac, register and ignore the migration assistant for now. Once the mac is running I downloaded the initiator and installed, setup the connections to the iSCSI targets, open iPhoto and iTunes and point the applications to the iSCSI data and all was good. Just the application migration to go.

I opened up the ever so handy OSX Migration Assistant, pointed it at the time machine backup and recovered the old account data and applications on to the machine as a new account, logged out, logged in as the recovered account and the migration was done.

Work done, about 10 minutes, time taken 5 hours of data transfer backwards and forwards.

Job done, no problems and no fuss, technology as it should be.

Zimbra upgrade

Note: I originally posted this on a different website, but have since re-purposed that site, and having had this post help me out twice I figure it was worth keeping ;-)

Update: Bug 41683 is now showing as fixed in 6.0.4

So last night was the chosen time to upgrade the Zimbra install at work, all offices were shut, most people shouldn’t be working and if they were then an hour without email shouldn’t be too much to have to cope with.

With offices in San Francsico and also Dubai the time when server changes that impact everyone can be made is from midnight Friday through to 05:00 on Sunday morning (Dubai has Friday and Saturday as its weekend)

All seemed to go fine with the upgrade until I checked the installed certificate, this had reverted to an earlier, now expired cert.  Using the admin interface to attempt a reinstall with newer server certificate failed with:

Invalid Request
Message: invalid request: missing required attribute: server Error code: service.INVALID_REQUEST Method: GetCertRequest Details:soap:Sender

So a quick hunt around the support forums, a bit of googling later and with no obvious answer found (and an impending deadline) it was time to log a support ticket.

Shortly the landline rang and it was time to give over access of the mail server to Zimbra support to have a look and fix the problem. 10 Minutes later and all was sorted.  It was a known bug (42216 / 41683) which is due to be fixed in 6.0.4

However the interim solution is to redeploy the commercial cert.
cd /opt/zimbra/ssl/zimbra/commercial
/opt/zimbra/bin/zmcertmgr verifycrt comm ./commercial.key ./commercial.crt ./commercial_ca.crt

Then if all looks good:
/opt/zimbra/bin/zmcertmgr deploycrt comm ./commercial.crt ./commercial_ca.crt

And you’re back up and running with the correctly installed commercial certificate.

Hopefully this is useful to someone, will probably need this again for the 6.0.3 upgrade

VMWare-tastic

So I finally managed to spend some time over the last few days on sorting out the 7 VMWare servers we have in the London (Main) office and more specifically get a free server available so that I could retire a VMWare server that couldn’t be upgraded to the latest version of VSPhere.

Course of action was simple.

– Install a new management server as a physical machine
– Move all existing VMWare servers under the control of the new management server
– Profit.

Not quite that simple, until I had upgraded a server to VSPhere it couldn’t be managed by the new VCenter Server as it didn’t have the old 3.5x license server running.

So it took a bit of moving instances around the various servers and gradually upgrading all servers to VSPhere.

Once I’d worked out the correct order to move all of the servers around without killing anything it was time to get started, I moved all of the already upgraded servers under the control of the new VCenter Server, and then migrated the BDC and PDC from VMWare servers that needed upgrading, this meant I was left with two 3.5x boxes to upgrade one of which was running the old VCenter Server with the 3.5 license manager.

I shut down the old VCenter Server and migrated into on to an already upgraded VMWare Server then set to work upgrading the last two servers.

All very simple, just required a bit of planning to ensure I didn’t end up with a 3.5x server that I couldn’t do anything with as the license server wasn’t available (I’ve got around this issue before using an emergency local license but it is a problem best avoided.)

So I now have 7 VMWare servers all running the latest version of VSPhere (well 3 of them will be auto updating using the update manager over the weekend) and a physical install of the Virtual Center Server.

I’m happier that the main management machine is a physical box as it makes life easier doing updates.

Now to set about getting in the extra kit to go HA ;-)