I made a mistake of not having a backup of my base virtual image for testing and back in the old days, I used the NewSID tool from Sysinternals. Unfortunately, I am not back in the good old days as the tool is only supported to run on Windows XP and Windows Server 2003 whereas I am working on Windows Server 2008. Although there are claims that it would work on both 32- and 64-bit Windows Server 2008, I am not going to spend another minute trying something that I have not validated myself (thanks to a new paradigm in business models) just for this project. My next best bet - SYSPREP. Unlike the days of pre-Windows Server 2008 where you had to find the Windows installation media, find and extract the Deploy.CAB file to you hard drive and then execute the SYSPREP.EXE tool. Not anymore! Widows Vista and Windows Server 2008 has it out-of-the-box (and you wonder why you needed all that hard drive space to install them) on
%WINDIR%\System32\Sysprep
One thing to note is that you need to check the Generalize checkbox to create a new SID for a cloned system
Saturday, February 7, 2009
Reconfiguring your SQL Server disks - 2008 edition
This was from my old blog entry from way back November 2006 and remembered how easy it was to fool SQL Server when trying to replace disks. I was configuring a clustered SQL Server 2008 on a Windows Server 2008 and testing the disk resources for failover. I tried failing over one of the disks and it went out pretty well. The next disk resource that I failed over happened to be the one containing the system databases. To my surprise, it did not failover to the other node causing the SQL Server resource to fail as well. It took me quite a while figuring out that the disk subsystem is somehow corrupted (good thing it was just a test environment) so what I ended up doing was recreating a new disk subsystem and redefining it on my cluster using Failover Cluster Management. I made it available on my SQL Server 2008 resource. I knew I would definitely have downtime as I need to bring down the SQL Server cluster resource. Here's what I did - I brought the SQL Server resource offline, copied the contents of the original disks that contain my system databases to the new disk resource, changed the drive letter of the original disk to something else and rebooted the node that originally hosted the disk resource that is failing. Once it is up, I can reuse the same drive letter to the new disk resource which now has the original system databases. When I brought te SQL Server resource back online, it's as if nothing had happened (except, of course, for some errors in the Clustering error log).
Note that this is definitely not a substitute to a valid backup and restore process for your SQL Server databases. All I'm saying is it just works
Note that this is definitely not a substitute to a valid backup and restore process for your SQL Server databases. All I'm saying is it just works
Tuesday, February 3, 2009
Building a Windows Server 2008 Cluster Part 1
And so I was asked to blog about it. I have posted the details in here. This is part 1 of a 3 part series on building a Windows Server 2008 Cluster. Feel free to post comments and questions regarding this blog post as I am still working on the full details based on this TechNet article. If you are looking for step-by-step procedures on building a Windows Server 2008 cluster specifically for SQL Server 2008, check out this first in the series of articles I've written on how to go thru it from start to finish
Teredo what?
I bet you've encountered this error when running your Validate Cluster Configuration wizard in Windows Server 2008.
Verifying that there are no duplicate IP addresses between any pair of nodes. Found duplicate IP address fe80::100:7f:fffe%13 on node node1.domain.local adapter Local Area Connection* X and node node2.domain.local adapter Local Area Connection* X.
I've spent a bit of time trying to find out why the cluster validation report is displaying a duplicate IP address on my network when I only have like 2 static IP addresses for each cluster node. After digging thru a few blog and forum posts, I've found out that this was caused by the Teredo IPv6 Tunneling Protocol. This allows IPv6 communications to pass through IPv4 NATs and IPv4 servers. but gives an identical IPv6 address to its network interfaces. This is the one getting flagged by Failover Clustering as an error since it require unique IP addresses.
This blog post describes how to disable the Teredo Tunneling Protocol although when I tried the first option, I still get the error in the cluster validation report. After doing that, I tried disabling it in the Device Manager console as well. It did work after that
Verifying that there are no duplicate IP addresses between any pair of nodes.
I've spent a bit of time trying to find out why the cluster validation report is displaying a duplicate IP address on my network when I only have like 2 static IP addresses for each cluster node. After digging thru a few blog and forum posts, I've found out that this was caused by the Teredo IPv6 Tunneling Protocol. This allows IPv6 communications to pass through IPv4 NATs and IPv4 servers. but gives an identical IPv6 address to its network interfaces. This is the one getting flagged by Failover Clustering as an error since it require unique IP addresses.
This blog post describes how to disable the Teredo Tunneling Protocol although when I tried the first option, I still get the error in the cluster validation report. After doing that, I tried disabling it in the Device Manager console as well. It did work after that
Subscribe to:
Posts (Atom)