I have for a little while wanted to put together a set of articles which attempt to explore the mindset of CCR clustering when being put to work in a production environment. Essentially my line of thinking (at least on the surface as this is a huge subject) is to go through some of the thought processes which might lead you (as an Exchange Admin) to the point where you are happy with the concepts of CCR clustering and are sure that it is for you within your Exchange Environment.

This article is along the same lines (although a little more detailed) as the article that I did on Hub Transport Specification which can be found here: http://www.telnetport25.com/component/content/article/31-exchange-2007--hub-transport-/122-suggested-hub-transport-hardware-config-for-exchange-2007-installations-of-5000-users.html

As mentioned this is a very large subject and contains quite a bit of varied theory as well as the usual technical staff that I like to throw in (for example I have a few CCR construction scripts that I would like to throw into a later part).

In the main the reasons for this series are:

1. I have been working on a large production roll out of Exchange CCR (I know I always seem to be working on a large deployment of CCR into production) – but I have been considering (almost cliché) what is it all about really – does CCR really have to be the overall option when your really consider your overall Infrastructure environment?
2. I totally trashed my CCR lab by accident and decided that it was not worth restoring from backup (I had made so many changes to the CCR configuration it was probably better to start from scratch) therefore I developed some scripts that make the process of deploying CCR on Windows 2008 much more straight forward
3. I have been comparing some of my earlier posts about CCR to Microsoft’s TechNet deployment guidelines to ensure that my own personal thoughts were inline with general best practices

For information (and I include them as they are a darn good read) – the Microsoft articles are now the basis for much of my meanderings on CCR (as well as some good ole life experiences)

• http://technet.microsoft.com/en-us/library/dd425009.aspx – the Installation check list for Windows 2008 CCR Clustering
• http://technet.microsoft.com/en-us/library/bb124521.aspx – Introduction to CCR deployment and an overview of the technology
• http://technet.microsoft.com/en-us/library/bb629714.aspx – Introduction to CCR deployment on Windows 2008 this topic contains the meat and potatoes of CCR deployment on Windows 2008

Technically I have been taking a (small) break from Exchange shenanigans recently with a shift in focus to SQL server 2008. Now I personally classify myself as a “SQL hobbyist” rather than expert, where I fill in within my organisation for an absent SQL Server DBA post.

Therefore this post might seem a little elementary to some of the SQL guru’s out there, but I decided to write about it - as given the amount of time that I have spent on this today I would not wish for someone else to lose 7 hours of their life to the same fate!

On a separate note – I think that SQL is an excellent product – and the tomfoolery that this article is based upon is more about a problem with the vendor of one particular item of software – rather than an issue with SQL server.

Essentially the scenario was as such:

My company had (operative word there) a number of SQL 2000 installations, 4 of which where were clustered instances (Active / Passive), between all of the instances there were (are) around 112 SQL databases of varying degrees of importance to the organisation (ranging from REALLY Important – to “Snooze”). The view was (and is) to consolidate those installations down into fewer SQL instances – and replace the clusters with Database Replication / Mirroring.

Of course another mitigating factor of the project was to get my company off of SQL 2000 and onto a non extended support platform, we decided to skip SQL 2005 and take the jump to SQL 2008 (much to the disgust of many of our SQL application suppliers – whom seem to display amazing levels of ineptitude when asked if they support the latest platform – but this is a rant that is worthy of a post in its own right).

The first set of SQL servers were moved very simply, I have been using a process where I clone the Security Logins and then Backup and Restore the databases to the new destination server, and then give the new server the same IP address as the previous instance (this was a precedent set prior to my arrival – personally I would have used FQDN) which has worked quite nicely.