Upgrading My Desktop: Transferring the OS to the SSD

After preparing my new SSD, the hard part (or rather easy part) was transferring the current Windows 7 operating system and all its contents (users, documents, etc) off the old HD and into the new SSD. What I wanted to achieve was to mirror the contents of my C: drive onto the SSD and simply swap out the drives and re-use the old SATA cables. To create the C: image I used Acronis True Image Home (free trial) -- which according to the internet, is one of the better products to do this with. The paid version of Acronis comes bundles within a "Clone disk" tool that would of made this process far easier (in case you want to do that).

1) Creating the backup

Before creating the image, I ran the disk cleanup utility on my C: drive to clear out any unneeded or temp files. This is also a great thing to do, as you can lower the filesize of your drive so that it will fit on the new SSD (since they are much smaller in size; this can be a problem). Once the disk cleanup was done, I simply ran the Disk and partition backup command under Backup and Recovery within Acronis. This created a backup file that I will later use in the SSD.

2) Restoring the backup to the SSD

With my shiny new backup, it was now time to restore it to the SSD. This was rather simple, actually it was extremely simple to do. Within Acronis next to each backup is a Recover button that can be used to restore the backup. All I had to do was set the destination for the SSD, and presto, I now have a mirrored drive. A few things to note however: the SSD must be large enough to house the backup and the SSD must not have a drive letter assigned to it so that swapping can easily be done.

3) Swapping out the drives

Now that the drives are mirrored, the easiest step is swapping them. This can be done by shutting down the computer, taking out the old C: drive, plugging its SATA cable into the SSD and inserting the SSD into the computer. When swapped, fire up the computer and let it boot. When it reached the desktop it recognized the SSD and installed new hardware. It then asked to restart the computer to apply the new changes. Once restarted, I noticed that everything was multitudes faster, and is just too beautiful for words to explain.

Since I now had an extra 300GB HD, I decided to plug it back in and re-format it. This drive is now used to store all my Windows backups and restore points. I felt it could still be useful, and in the event that something happens, I have a backup to fix the problem.

Upgrading My Desktop: Migrating Programs and Hard Drives

The next step in my system upgrade was to install and format the new hard drives, migrate all program files over to the new drive, and setup symlink's for legacy paths. For my upgrade I was installing a 1TB internal HD that will house all my program and game installations, and a 128GB SSD that will house the Windows 7 OS. This process was pretty tedious, so bare with me and follow closely.

1) Installing and formatting the new hard drives

The first thing I had to do was physically install the hard drive into my computer (of course), connect any SATA and power cables and make sure it was fastened in the HD bay slot. Once installed and the computer turned on, I opened the Computer Management program; you can locate this program by searching for "computer" in your start menu search.

Selecting the Disk Management tab on the left should populate with all the installed drives. If your newly installed drive does not show up, shutdown your computer and diagnose the problem by checking that all cables are connected correctly. Otherwise, right clicking on the drive allows you to format and create a partition (or volume) by selecting the New Simple Volume Wizard.

When formatting my drives, I used the default volume size as I was only creating 1 partition per drive. When it gave me the option of selecting the drive letter, I chose E: for my 1TB HD and opted out of using a letter for my 128GB SSD, as I will be replacing my old C: with the SSD.

Lastly, in the format partition dialog, I chose NTFS as the file system (this is critical) and the non-quick format option. I didn't use the quick format as I wanted to stay on the safe side and ensure that everything was erased and cleaned (even though it was a new drive).

Restart the computer when the formatting is done (I restart a lot).

For a more in depth guide on this process, checkout the following articles:

2) Uninstalling current programs

The next big step was to uninstall all my programs. I am not too positive this is necessary compared to dragging the current Program Files folder over to the new drive, but I uninstalled and reinstalled all my programs to validate they all have the correct paths in the registry, startup, configuration, shortcuts, targets, etc.

Note: During the uninstallation process, be sure to keep all saved data and settings if the program gives you the option. Since I was not doing a clean install of the OS, the AppData and related folders will continue to persist all my program settings and cache once I reinstall it.

When all available programs were uninstalled, I restarted my computer.

3) Overriding the Windows registry

Now this is the first important piece. Changing the Windows registry that points to the Program Files path allows any program to automatically install to the new location (on the new drive) without me manually having to define it. However, some programs are just plain idiotic and will still set the path to C:/Program Files/ instead of the new path.

For reference, here are my old and new system paths:

C:\Program Files\		-> E:\Programs\
C:\Program Files (x86)\	-> E:\Programs (32)\

Additionally, I added the following folders on my E: drive:

E:\Backups\		Location of system restores and backups
E:\Data\		Temporary file and cache location for Programs
E:\Games\		Installation path for all games (separate from regular Programs)
E:\Installers\	Program installer executables (I like to save them)
E:\Tools\		System tools like Process Explorer and SIW

After the uninstallation process, I continued to find programs left over in the C:\Program Files and C:\Program Files (x86) folders. These leftovers are more than likely Windows related programs and should be left alone for now. Do not delete these programs nor delete the parent folder.

The next step was to edit the Windows registry. You can open the registry editor by typing "regedit" in your start menu search and pressing enter. In the editor, drill down into the following path: HKEY_LOCAL_MACHINE -> SOFTWARE -> Microsoft -> Windows -> CurrentVersion

Click on the CurrentVersion folder -- this is where we will edit the program files paths. I modified the registy by changing the following fields to the new paths (note the non-trailing slash):

CommonFilesDir			-> E:\Programs\Common Files
CommonFilesDir (x86)	-> E:\Programs (32)\Common Files
CommonW6432Dir			-> E:\Programs\Common Files
ProgramFilesDir			-> E:\Programs
ProgramFilesDir (x86)	-> E:\Programs (32)
ProgramW6432Dir			-> E:\Programs

After a compute restart, any new program installations should install to this new location.

4) Installing and migrating programs

This part is pretty easy, I simply re-installed all the programs back onto my computer. If the installer gives you the option to do a custom install (allowing you to choose the install location), select it. This allows you to verify the program is installing to the new path and is a required step as some programs will still attempt to install to C: -- if this happens, just change the path yourself.

When all program installations were complete, it was time to migrate the leftover programs. All I did was select and copy all the folders in C:\Program Files and paste them into E:\Programs. I also did the same by copying all folders in C:\Program Files (x86) and pasting them into E:\Programs (32).

Probably the easiest step in the process, but also the most time consuming.

5) Legacy folder cleanup

Before symlink's can be created, the origin folder must not exist. The next step I had to take was deleting the old C:\Program Files and C:\Program Files (x86) folders... which turned out to be quite difficult. Doing a delete or shift + delete didn't work as I would get basic access denied alerts. I then switched over to the command prompt to attempt some deletion magic... the following did not work.

"rd" - This command *should* remove a directory and all files within. Still received access denied errors.

rd /S "C:\Program Files"
rd /S "C:\Program Files (x86)"

"takeown" and "icacls" - These commands basically change the ACL (access control) of all files and folders, and give ownership to the Administrators group (This is basically the same as changing ownership in the right click properties dialog). This also did not work.

takeown /f "C:\Programs Files" /r /d n
icacls "C:/Programs Files" /grant Administrators:F /t
takeown /f "C:\Programs Files (x86)" /r /d n
icacls "C:\Programs Files (x86)" /grant Administrators:F /t

Now after many hours and much frustration, I was ready to give up. But after much Googling, I found the answer -- it was time to bring out the big guns. The following did work. This command enables the hidden Administrator account on all Windows Vista/7 systems. 

net user administrator /active:yes

Once enabled, I switched over and logged into the Administrator account. I was now able to shift + delete the folders with no problem. When deleted, I logged off the Administrator account. Running the following command disabled the account.

net user administrator /active:no

Easy right? I thought so as well.

6) Setting up symbolic links

The final step -- never thought I would get this far. Seeing as how I have successfully installed a new hard drive, migrated all programs over, modified the Windows registry and cleaned up legacy folders, it is now time to setup symbolic links. Like I stated before, symlink's are a way to have anything that points to the C: drive, reference the same files within the E: drive. The same goes for writing data -- anything written to C: is actually being written to E:.

Note: Since I named my programs folder E:\Programs instead of E:\Program Files, anything referencing C:\Program Files will not find a symlink match. However, I have yet to run into any problems after weeks of testing.

Setting up the symlink's was easy:

mklink /D "C:\Program Files" "E:\Programs"
mklink /D "C:\Program Files (x86)" "E:\Programs (32)"

Tada, magic! I now see a shortcut within C: that references E:.

Conclusion

It took me hours over the course of a couple days to do all of this. The hardest part was Googling around for solutions as many of them lead to dead ends. It also helped me figure out problems during the migration as I would run into weird cases where startup items would fail, or programs could not be located. Most of these problems disappeared once symlink's were created.

I've been using this new setup for a couple weeks now (at the time of writing this) with no problems. I have yet to switch over to the SSD however... so that should be interesting.

Upgrading My Desktop: Preparation

My desktop computer is almost 2 years old, but certain parts of it are way over 5 years. My C: and D: drives were taken from my last computer and re-used in my new custom built desktop (primarily to save money). I really wanted to upgrade my HD space and switch to the latest craze, an SSD. While doing this upgrade, I felt like I should blog about what I did and any problems I ran into. To start this off, here was my old system.

As you can see, my RAM and HD space was abysmal. My C: drive was 90% full of crap, mainly the OS and all installed programs. The plan was to install a new secondary internal drive and migrate all program files into this new drive, the E: drive. I also had to reduce the space used on the C: drive so that I can transfer my OS to the SSD (note: transfer, not a fresh install). Lastly, my F: drive is primarily used for media storage (which is connected to my iTunes): music, tv shows, videos, pictures, docs, etc. Before I continue, here is the new hotness (changes in italics):

Even though I was mainly going to upgrade my HD slots, I kind of splurged and upgraded my RAM, keyboard and monitors. The RAM was relatively cheap, only $40 for another 8GB. My keyboard was getting extremely outdated, so I upgraded to the Sidewinder gaming keyboard as I am always destroying face in Battlefield 3. Lastly, the only reason I bought 2 new monitors is because one of them died during this upgrade process (what are the chances)... so I decided to upgrade both at the same time.

The upgrade process for migrating all programs to another drive and for switching to a new SSD will come shortly. They are pretty in depth, so a full blog post about it should suffice. I hope to inform you all on this journey!

Codebase Upgrades: Upgrading Forum v2.x to v2.2

In the newest 2.2 version of the Forum plugin, a subscription system was added. This system allows for users to subscribe to topics and forums and then receive email notifications at specific intervals. This feature required minor database changes so a new upgrade shell was added to handle this. You will only need to run the upgrade shell if you are upgrading from 2.0 or 2.1. If you are doing a fresh install, you can ignore this post and the upgrade shell.

Begin by downloading the latest 2.2 tag and uploading and overwriting the older version. Your forum will be broken until you run the upgrade shell and the following command. Once the command is executed, simply follow the on-screen instructions.

cake -app /path/to/app upgrade
Setting up the subscription notification cron

For the subscription emails to be sent out, the subscription shell will need to be triggered. The best way to accomplish this is to setup a cron job to be triggered every 24 hours (or another time of your liking). If you are unable to setup a cron job, you will need to disable the subscription system via the forum admin settings.

0 0 * * * /path/to/cake/console/cake -app /path/to/app subscription

By default the shell will find all new activity within the past 24 hours via the database timestamp (which is separate from the cron interval time). You can change this using the timeframe parameter. For example, if you want to send emails every hour instead of every 24 hours (quotes are required).

0 * * * * /path/to/cake/console/cake -app /path/to/app subscription -timeframe "1 hour"

Hopefully this small guide helps you upgrade to 2.2, enjoy!

Codebase Upgrades: Upgrading Uploader v2.8 to v3

The Uploader plugin has upgraded major versions from 2.8 (CakePHP 1.3) to 3.0 (CakePHP 2). Since this is not a backwards compatible change, the 3.0 version can only be used in CakePHP 2.

No more UploaderComponent

During the conversion process, the primary change is that the UploaderComponent was removed and turned into a stand-alone vendor class. This was done to further encourage the use of the AttachmentBehavior. Because of this change, you will need to manually initialize the Uploader in your Controller::beforeFilter() (only if you were using the component). The property settings are now passed as an array through the constructor.

// Before
public function beforeFilter() {
	$this->Uploader->tempDir = TMP;
}
// After
public function beforeFilter() {
	$this->Uploader = new Uploader(array('tempDir' => TMP));
}

By instantiating the class to $this->Uploader, all of the old code should still work as normal. This change also allows the possibility to use the Uploader anywhere in the application.

No more S3TransferComponent

The S3TransferComponent was trying to do something it shouldn't have. The component was removed in favor of the Vendor/S3 class that provides far more functionality. The AttachmentBehavior has also been updated to use the S3 class instead of the component.

Certain methods are now static

The bytes(), addMimeType(), checkMimeType(), mimeType() and ext() methods are now static.

Those should be the only changes you would need to make to support the new version. There are quite a few other changes, so be sure to check out the changelog and to also check out the updated documentation.

Codebase Upgrades: Upgrading AutoLogin v2.2 to v3

The AutoLogin component has upgraded major versions from 2.2 (CakePHP 1.3) to 3.0 (CakePHP 2), now 3.1. Since this is not a backwards compatible change, the 2.0 version can only be used in CakePHP 2. During the conversion process, many things had to change to support the new AuthComponent.

No more automatic username/password field detection

Previously AutoLogin would detect the custom name of your username and password fields by accessing Auth::$fields. Since that property has been removed in favor of Auth::$authenticate, the AutoLogin component received a new property called $fields which mimicked what the Auth's version did. I didn't want to magically guess what the username and password is from Auth::$authenticate and be wrong, so I made it an optional property (you should only need to change it if you are using custom fields).

$this->AutoLogin->fields = array('username' => 'user', 'password' => 'pass');

Seeing as how that was the only major change that may require backwards support, the following minor changes have also occurred: CakeRequest has been implemented anywhere $params were being referenced, the user model is detected via Auth::$authenticate (all first, then Form) in place of the deprecated Auth::$userModel and cookie support has been implemented for localhost environments (may not work in all environments).

If you have any questions, or run into any problems, let me know!

Codebase Upgrades: Upgrading AjaxHandler v1.6 to v2

The AjaxHandlerComponent has upgraded major versions from 1.6 (CakePHP 1.3) to 2.0 (CakePHP 2). Since this is not a backwards compatible change, the 2.0 version can only be used in CakePHP 2. During the conversion process, many other features were refactored or removed, here is a quick round-up.

No more automatic data gathering

In the older versions, any request data was gathered and merged into the Controller::$data property within AjaxHandler::startup(). This is no longer the case as I highly suggest using the new CakeRequest class to manipulate data in your AJAX action. This class can be accessed at Controller::$request.

No more content type restrictions

Previously you could only respond() an action using JSON, HTML, XML or text. Now you can respond using any content type defined in CakeResponse. Automatic JSON/XML formatting is still enabled.

Removed the valid() method

The valid() method was a very abstract and useless method that simply checked that strings or integers were not empty. The AjaxHandler should not be dealing with any validation (low level ones even more so), so it was removed. Please integrate your own data validation.

Besides the major changes listed above, any private class properties were converted to protected visibility, to allow class extension and the RequestHandler was replaced with CakeRequest in most situations, ala is('ajax') compared to isAjax().

If you have any questions, let me know!

Upgrading the forum plugin to 1.8

I have been working on the new 1.8 version of the forum for almost 2 months, simply because version 1.7 was completely broken. It used PHP 5.3 constants which didn't work on 99% of the users machines. This problem has now been corrected in the new 1.8 version, but that's not all that changed. All topics, forums and forum categories now use the sluggable behavior for pretty URLs. Furthermore, the Installer has been rewritten completely for faster and easier usage. The main purpose of this post is to direct you in the 1.8 upgrade process as there are many things you need to do.

Overwriting an older version

You will need to overwrite ALL files within the plugin. Basically every view, every model, every controller, etc has been modified in some way; primarily to support the new slugs. Sorry to all those who have changed the HTML.

Patching your plugin

The new installer system creates a legacy config file to be used for future upgrades and to maintain the current installation. If you are doing a fresh install, you can skip this step. Once you have updated all the files, you will need to patch your installation to build that config file. You can do this from within the install controller.

yourdomain.com/forum/install/patch

The patch process will require 3 things: the database config you want to use, the table prefix value (if you have one) and a checkbox that determines if you used the plugins native user table or a pre-existing one.

Upgrading the database

With the new slug changes, it requires you to upgrade your database tables with the new column and all rows to be populated with their slug equivalent. This process takes 2 steps to achieve, the first having you run an SQL command from within the installer. You can access this process at the URL below.

yourdomain.com/forum/install/upgrade_1_8

The second step requires you to use the Cake console and to run the slugify shell. This shell will populate all the empty slug rows (it can be used any time, not just the upgrade process). Your shell command may look like the following.

cake -app /path/to/app slugify
Fresh install

If you are running a fresh install, the process is extremely simply. Just go to the install controller, hit the "Begin Installation" button and follow the steps. The process will check your database for conflicts, create the tables, patch the install and create the admin user. I tried to make it as simply and straight forward as possible.

See if it's working!

Whether you did a fresh install, or patched an old one, the last thing to do is actually use the forum. You should be checking to make sure all the slugs were generated, the pages work, the links link correctly, so on and so forth. If you find a bug or problem, PLEASE report it to me so I can fix it.

Enjoy! (Sorry for the long wait time)

The flawless upgrade to Cake 1.3

Cake 1.3 has been around for quite some time now, but I never had the desire to upgrade with it being in such a beginning stage. Well seeing as how its now in Alpha and many users are testing it with no problems, I thought it would be a good idea. The project I was going to upgrade is quite large, heres a quick rundown of just how large:

19 controllers, 8 components, 15 locales, 64 models, 2 plugins, 6 vendors, 8 stylesheets, 14 javascripts, 7 helpers, 159 views

This isn't counting the admin panel, which is a whole separate app, and which I have not upgraded yet. Now lets get onto the upgrade, its probably the easiest thing to do. All I did was follow the migration guide. First off was checking to see if I used any deprecated methods, which was simple, all I did was search the whole app folder for words like del(. I was surprised to find I used it like 5 times, when I always preferred the full delete().

Next in the list was upgrading to the new Router conventions, which lucky for me didn't apply. I never used any non basic conventions, I mean why would you! One thing that bugged me though is the new page title implementation. It took me quite a while to go through all those controllers, and all the actions within them. Another nuisance was adding "echo" to all the flash() calls in the views, and removing the "inline" parameter from all meta() and css() calls, but wasn't too time consuming.

One of my most favorite updates was the new pagination support with passedArgs. I had to hack all my paging before, but in the new update I removed it all and it worked wonderfully! Thanks Cake team :]

All in all, the upgrade went smooth. If you follow Cake conventions all the way through, you don't need to do much alterations. I for one am looking forward to the future versions.