I would have expected there to be no problems with most of them. I started out with a dinky little site that uses a small Microsoft Access Database.  This site uses a standard DSN to access the .mdb. I proceed to go to the Administrative Tools and open the ODBC Data Source Administrator window and add a new DSN for the .mdb and lo and behold I see the following nearly empty window:

<– This of course is no good! Where are all the other data drivers? Apparently all the regular ones we are used to seeing in 32bit Windows no longer exist as 64bit drivers.  The trick is to execute %windir%\SysWOW64\odbcad32.exe.

<– This will give you the ability to add the rest of the 32bit Data Sources such as Microsoft Access (.mdb).

Luckily I run everything within VMware ESX Environment, so no data needed to be copied from one machine to another. I simply provisioned a new Windows Server 2003 guest and added the old server’s VMDK disk to the new machine.

• The first thing you need to do is backup your old IIS configuration. In IIS Manager, right click in IIS Manager > All Tasks > Backup/Restore Configuration.

• Probably the most imporant part of the whole process is to make sure you “Encrypt the backup using password”. This makes th e IIS config “portable”. If you don’t encrypt it, you won’t be able to import it on a different system as there are sessions keys stored withing the IIS metabase.

• By default the configuration backup goes to C:\WINDOWS\system32\inetsrv\MetaBack. So you will need to grab both files it has created and move them on over to the new server. Place them in the same location on the new server because IIS doesn’t give you a choice to browse for a backup – it looks in that directory each time.

• Now you’ll restore that configuration from within IIS Manager, right click in IIS Manager > All Tasks > Backup/Restore Configuration. Choose the one you want to restore and restore. It will ask for the encryptin password.
• Now we need to restart IIS. This will actually re-create the IUSR account in the Local User Manager, which kind of impressed me. The password will be wrong for this account so you need to set it to something manually by the normal Reset Password function.
• Now you need to need to tell the metabase about that new password. Microsoft has a nice article outlining how this is done.
  http://support.microsoft.com/kb/297989
• Restart IIS and for the most part you should be good to go.

I opted to simply reset the password for the IUSR account that the metabase created automatically for me. The name was wrong (hence IUSR_computer), however this meant I wouldnt need to change all of the special IUSR permissions set for special files such as MDB and other special case files. You can easily tell the metabase to use a new user account as the IUSR account using the metabase explorer, but I’m not going to go into that right now.

1. Ghost the Dell PowerEdge 2950 Windows Server 2003 C: and D: drives
2. Pull out the 3 old 36GB drive RAID 5 Array  and replace with 5 shiny new 146GB drives in a RAID 5 Array
3. Put the ghost image back on the new RAID 5 array
4. Go home and have a good night’s rest

My night can be summed up in two simple words:  MISERABLE FAILURE

Almost two hours into the project I finally realized that the PERC3/Di drivers are actually inserted into the PERC2/3 bundle of PERC drivers rather than the PERC 3/4 bundle of drivers.  There are PERC Di’s,, Si’s, DC’s, SC’s, and QC’s.  The Di and Si versions apparently are the bastard child of the PERC drivers.

Once I was able to boot into Bart PE Ghost kept crashing with Error 32000.  Symantec basically says this could mean anything, or nothing.  Thanks Symantec.

I was finally able to take an image of the machine, however it was useless.  It turns out the previous IT guy decided it would be a great idea to turn the RAID 5 Array into a dynamic partition.  Ghost, and from what I’ve read cannot clone RAID 5 volumes – only spanned, striped or mirrored volumes.

What upsets me more than the fact that this just a stupid decision by the last IT guy, and more the fact that several hours were wasted by me trying to get it to work is the fact that the last guy must have made a concerted, conscious effor to make this change in Windows. This was not a case of simply choosing the wrong choice – Door A or B. A colleague of mine reminded me this morning as I was venting that Microsoft suggest making all volumes Dynamic (or at least they did a while back).

I take full blame for not preparing for the w0rk I was embarking upon last night.  It just goes to show that you really can’t trust the work of others. Nothing is safe.

It would seem to me that the easiest way to get more users to install updates would be to actually make it easier for them to do! Could Microsoft not really want users to install updates?  Do they enjoy being lambasted in the blogosphere about how insecure their systems allegedly are?

Maybe the folks over at Microsoft have been misunderstood all along. Maybe they make these boneheaded decisions on purpose.  Maybe they are just masochists and they thrive on pain and torture.  They’d rather fight the big fight rather than do the little things that might make our lives easier.

I suppose on some level we all like the pain.  That’s why we still put up with it.