Migrating vCenter 4.0 to 4.1 (part 1)

When vSphere 4.1 was released earlier this year, I was mildly excited. Our ESX servers are still running 4.0.0 and I had been planning to upgrade to 4.0u1 for a while. When 4.1 came out it seemed to have vindicated my procrastination: now I could just upgrade to 4.1 and take advantage of whatever new features there were (I read something about memory compression… whatever).
Continue reading “Migrating vCenter 4.0 to 4.1 (part 1)”

We gon’ party tonight

I use Akismet to filter out spam comments here, and I’ve seen a few different strategies the spammers employ. There’s the “Cool post! You should Digg it” (in both English and Spanish – tengo que Digg), there’s the “this post helped me on my class project,” there’s the pure jibberish – “xajdjhesbjsb sjhsjhrhjshwru skjskjrijsjs.” But this is a new one I’ve seen over the past couple of weeks:

We gon party tonight
We gon party tonight

Stupid things like this crack me up, not sure why.

We gon' party tonight

I use Akismet to filter out spam comments here, and I’ve seen a few different strategies the spammers employ. There’s the “Cool post! You should Digg it” (in both English and Spanish – tengo que Digg), there’s the “this post helped me on my class project,” there’s the pure jibberish – “xajdjhesbjsb sjhsjhrhjshwru skjskjrijsjs.” But this is a new one I’ve seen over the past couple of weeks:

We gon party tonight
We gon party tonight

Stupid things like this crack me up, not sure why.

Compellent Doesn’t Suck

I noticed a bunch of people landing on this site by searching for “compellent sucks.” I just want to avoid any confusion: Compellent doesn’t suck. Now that the pain of spending the money to expand our Compellent SAN is in the past, I am back to being in love with the product. The only gripe I’ve really ever had with Compellent is the price, and as Ben Franklin said:

The bitterness of poor quality remains long after the sweetness of low price is forgotten.

Compellent Doesn't Suck

I noticed a bunch of people landing on this site by searching for “compellent sucks.” I just want to avoid any confusion: Compellent doesn’t suck. Now that the pain of spending the money to expand our Compellent SAN is in the past, I am back to being in love with the product. The only gripe I’ve really ever had with Compellent is the price, and as Ben Franklin said:

The bitterness of poor quality remains long after the sweetness of low price is forgotten.

Changing all Exchange mailboxes to use database defaults for quota limits with PowerShell

Here’s an example of why I’ve come to love PowerShell. Under Exchange 2003, we set users’ mailbox quota limits per-user, since we initially set them ridiculously high (around 20 GB). The reason we did that was that prior to this year we actually didn’t have any quotas on user mailboxes and the average mailbox was about 9 GB. In preparation for moving Exchange to the datacenter (over our measly 5Mbps upload line) we introduced quotas and over the course of about 2 months gradually lowered the limits as people whittled away their old email until they were under the quota we had established (about 2.25 GB for the no-send limit — I forgot the rationale for that number — and 1.75 GB for the warning limit [the no-receive limit was set to about 40GB since I never wanted users to hit that limit]).

I think the quota limits Exchange 2003 would allow you to set through the UI were capped at around 2.0 GB so to set quota limits above this we used ADModify to update the mDBQuota* settings for each user directly in their AD entries.

However, now all those users have been moved to Exchange 2010 which let me easily set the quota limits on the Exchange DB to 2000 MB (warning) and 3000 MB (no-send). The problem with this was that all the users were set to override the database setting. How could I quickly set them all to use the database default once again? With PowerShell, this was simple:

First, get the list of all users not using the database defaults:
[PS] C:\Windows\system32>get-mailbox -filter { usedatabasequotadefaults -eq $false -AND recipientTypeDetails -eq 'usermailbox' }

When doing any bulk operation, always verify the list of objects you’re going to be modifying before actually doing the modification. 🙂 The first filter I created didn’t have the RecipientTypeDetails in it and included a DiscoveryMailbox, which I didn’t want to touch. The above command affects only UserMailboxes. If the list looks ok, set them all back to defaults:

[PS] C:\Windows\system32>get-mailbox -filter { usedatabasequotadefaults -eq $false -AND recipientTypeDetails -eq 'usermailbox' } | set-mailbox -UseDatabaseQuotaDefaults $true

And voilà, everyone’s back to using DB defaults (which I increased to 3000MB to celebrate not having to do any more mailbox moves any time soon).

Finally, all users moved from Exchange 2003 to Exchange 2010.

I’ve been working on migrating our Exchange environment from 2003 to 2010 for several months. My first post about this is from April 14th, when I was just trying to virtualize our existing Exchange 2003 system. Once that was complete, I started playing around with Exchange 2010 around June or July, and had most of the users moved over to 2010 by the end of August. The last holdouts were Blackberry users. I couldn’t move their mailboxes because our BES was hosted on our original Exchange 2003 server.

BES is another product that I inherited that I had no experience with. It’s BES 4.1.x and while I wasn’t a fan of the UI it seemed to do its job. However, when I started moving people to Exchange 2010 I learned that BES 4.1 doesn’t support Exchange 2010. So, to cut the (absurdly long) story short, I setup BES Express on a new VM, pointed it at our Exchange 2010 server, tested it out (and it worked), and just last week was able (finally) to move the last few users over to Exchange 2010. BES users had to have their phones wiped to join them to the BES Express server, which was the major sticking point.

I can’t believe it actually took that long to complete, but we managed to move all user mailboxes twice (Ex2003 physical -> Ex2003 VM, then Ex2003 VM -> Ex2010 VM) with no noticeable interruption to users (we did the moves at night). OWA 2010 alone would make it worth the upgrade, but I’m actually loving the Exchange Management Shell too.

Anyway… nice to have it completed.

Putting up a “down for maintenance” message using mod_rewrite

Putting this here for safekeeping so my future self can find it. Mod_rewrite is one of my favorite tools, but it’s easy to spend 30 minutes crafting a 2-line directive that actually does what you want. I put this in a .htaccess file in the DocumentRoot of the server, put a “We’re down” message in maintenance.html (or whatever), and all requests will get a 302 redirect to /maintenance.html, except requests for /maintenance.html (for obvious reasons). It appends the original request in case you want to do something with it but that’s not really important. It also doesn’t do the redirect for images/js/css so those can actually be used in the maintenance message.

RewriteEngine on
RewriteRule ^maintenance.html	-	[PT,L]

RewriteCond %{REQUEST_URI}	!(gif|jpg|css|js)$
RewriteRule (.*) /maintenance.html?redir=true&originalRequest=%{REQUEST_URI} [R=302]

Putting up a "down for maintenance" message using mod_rewrite

Putting this here for safekeeping so my future self can find it. Mod_rewrite is one of my favorite tools, but it’s easy to spend 30 minutes crafting a 2-line directive that actually does what you want. I put this in a .htaccess file in the DocumentRoot of the server, put a “We’re down” message in maintenance.html (or whatever), and all requests will get a 302 redirect to /maintenance.html, except requests for /maintenance.html (for obvious reasons). It appends the original request in case you want to do something with it but that’s not really important. It also doesn’t do the redirect for images/js/css so those can actually be used in the maintenance message.

RewriteEngine on
RewriteRule ^maintenance.html	-	[PT,L]

RewriteCond %{REQUEST_URI}	!(gif|jpg|css|js)$
RewriteRule (.*) /maintenance.html?redir=true&originalRequest=%{REQUEST_URI} [R=302]

Ruby/Sinatra part 2

Following up on my previous post, I decided to go the easier route and just install an older version of Ruby that didn’t have the problem with Sinatra, since I wanted a setup I could replicate easily, and editing the server.rb each time I installed wasn’t what I was going for. I downloaded 1.9.2-rc2 from http://ftp.ruby-lang.org//pub/ruby/1.9/, compiled it and it works:

[evan@evanfc12 ~]$ ruby --version
ruby 1.9.2dev (2010-07-11 revision 28618) [x86_64-linux]
[evan@evanfc12 ~]$ ruby hi.rb ^C
[evan@evanfc12 ~]$ cat hi.rb

require 'sinatra'

get '/' do
	"Hello World!"
end
[evan@evanfc12 ~]$ ruby hi.rb
== Sinatra/1.0 has taken the stage on 4567 for development with backup from WEBrick
[2010-10-08 15:32:23] INFO  WEBrick 1.3.1
[2010-10-08 15:32:23] INFO  ruby 1.9.2 (2010-07-11) [x86_64-linux]
[2010-10-08 15:32:23] INFO  WEBrick::HTTPServer#start: pid=21758 port=4567

Speed bumps like this are so much fun!