Just trying to pass the message along.  Apple’s recent move to remove all matte displays from its notebook line has left me with a sour taste.  I was looking forward to updating my notebook but I guess I’ll be waiting for a new Mac Pro instead.  If you’re interested in signing a petition for Apple to offer matte displays, check this one out (6000 strong so far…).

For the past few weeks, during the transition from Exchange 2000 to Exchange 2007, we’ve experienced a number of complaints of slowness in Outlook.  Although the symptoms could be attributed to literally almost anything, we evaluated every possible option:

1. Exchange 2007 server issues: does it have adequate RAM, hard drive space, processing power, etc.?
2. Client issues: what version of Outlook are they using?  Is an add-in causing the perceived slowness?
3. Is it a result of a recent update to a file server, which was made public, and thus the slowness is not real but just a result of information the end user is applying to a different situation?

Today we learned something about our friend, C2C, which has been actively archiving nightly.  As it turns out, C2C is eating gigantic holes in our mailbox databases which cannot be fixed with online defragmentation.  It would have been nice to know this going into the whole upgrade, alas, the information was not available to me.

I moved myself to a mail storage group that contained only one mailbox database.  Its function is to hold accounts until we have backed up all of their personal files to portable media.  At any rate, it once contained mailboxes but they have since been purged from Exchange.  After I added my little mailbox (~1.3GB) the total size of the mailbox database was 20.4 GB (22,004,252,672 bytes).  I made a quick backup using NTBackup and then dismounted the database.  Using the Exchange Shell I ran an offline defrag (eseutil /d %database_name%) and it took a little over two mins to complete.  It’s recommended to perform a backup immediately following defragmentation, so I performed another NTBackup.  After the process was complete, I found that the newly defragmented database was only 1.32 GB (1,423,548,416 bytes)!  That’s a 65% reduction (if my math is correct, haha)!

I plan on performing the same defragmentation on all of our mailbox databases in an attempt to eliminate all complaints of Outlook slowness.

I know I’m just a simple computer science major, but does every database seriously operate in such an inefficient manner?  Why couldn’t online defragmentation take care of the 19GB of whitespace?

At any rate, we’re almost there.  I’m still migrating public folders nightly but their numbers are dwindling.

My first attempt at using the Exchange Power Shell scripts for migrating public folders did not go so well.  Thankfully, this was performed on a secondary Exchange server and not the primary legacy server.  For reasons still unknown, public folder instances on the legacy Exchange server persisted even after running the somewhat scary ReplaceReplicaOnPFRecursive.ps1 power shell script for all of the public folder hierarchy.  To work around this problem, I simply migrated using the old-fashioned (and tedious) method of adding the 2007 server as a replica to every public folder listed on the legacy server’s public folder database.  After my end-users were satisfied that all of their data had replicated (again, this required an “update” for every public folder my 2007 server could see in the SP1 public folder tool), I removed the legacy server from the replication list using PFDAVAdmin.

This evening, I discovered an undocumented quirk in the RepliceReplica script that may have led to the problems I experienced with the first legacy server — though it requires a path for the top-level public folder, if the path has a space in it, you must use an additional set of apostrophes.  I don’t know why I didn’t think of this the first time around, but the process seems to be running smoothly at the moment.  I’m still very skeptical of running the script against the entire public folders folder, so I’m running it against each subfolder individually so I can literally watch the public folder instance disappear from the legacy server.

So it’s clear, to move the top-level folder entitled “A/P Staff” from my legacy server to the 2007 server, I had to issue the command as follows: 

[PS] C:\Program Files\Microsoft\Exchange Server\Scripts>.\ReplaceReplicaOnPFRecursive.ps1 -TopPublicFolder “‘\A/P Staff’” -ServerToAdd %2007Server% -ServerToRemove %LegacyServer%

Luckily the Event Log, with almost verbose logging enabled for the Exchange 2007 server, still reports Replication Incoming/Outgoing 3028/3027 messages.  The legacy server eventually removes the public folder instances once the replication is complete.

With one legacy server completely off and zero complaints thus far, I will be removing it from Active Directory tomorrow, fingers crossed!

Of the 2 legacy Exhange (2000) servers in my organization, I believe one is ready to be completely removed. Public Folder migration was completed and verified earlier this week after refreshing (updating as the 2007 Console refers to it) the public folder hierarchy on the new 2007 server. Luckily, this particular legacy server did not host an offline address book or any other auxilary services.

As a test run, I dismounted the public folder store and the lone mailbox store and so far haven’t received any complaints. The next step will be powering it off before completely uninstalling Exchange 2000. Wish me luck!

Migrating from Exchange 2000 to Exchange 2007 has not been the easiest task I’ve ever had to do; in fact, it may be one of the most challenging.  I prepared, researched, studied, produced reports, created a presentation, and put all of the pieces in place to make the transition as easy as humanly possible so as to minimally impact end users.  Backups?  Not so easy.  Brick-level backups are a thing of the past so right now I’m humming along with NTBackup until I can remove all of my legacy Exchange (2000) servers and begin using C2C and Asempra services, replacing NetVault’s BakBone client.  

Don’t get me wrong, migrating users was extremely easy and the built-in scheduler made it easy to queue up a bunch of transfers during the workday so that they would run at night. 

On the other hand, public folder migration continues to be an utter mystery.  The system itself seems incredibly flawed and unnecessarily complicated.  I’ve run the appropriate scripts and still I have blank public folders from the client perspective…back to work…

The perfect home NAS, as far as I know, has yet to see the light of day.  It’s frustrating to read performance reviews of the new Drobo, which utilizes FireWire 800, and discover that it barely pushes the read/write limit of FireWire 400.  

How hard is it to make a good NAS that’s not $1000?!  NetGear’s ReadyNAS NV+ is a nice device, but I cannot justify spending nearly a grand to get a box with no drives.  It’s really frustrating to be a multi-dimensional computer user that needs a robust, redundant, reasonably-priced device to store photos, stream audio/video, and backup home PCs.  

Here’s my wish list for the perfect NAS:

• Minimum 4 drive capacity
• Multiple connection types: GigE (hence the “N” part of NAS), FireWire 800, USB 2.0, and optionally eSATA
• Web management interface
• Support for multiple file systems
• Reasonably fast read/write speeds such that files can be copied while streaming HD videos or audio
• Reasonable price tag of ~$500
• Bulletproof OS which does not require fancy or advanced configuration, but can be tweaked by power users

I don’t think it’s too much to ask.  Families need a device like this to keep all of their children’s photos and videos safe and also to provide a backbone for home entertainment and productivity.

Someone make it happen!!

Update 1: Maybe we just need to save our stuff in a cloud.