Introduction: How to migrate a SQL cluster to a new SAN ?

Environment: Server 2008 r2 (failover cluster – aka MSCS) and SQL 2008 sp3

Reference about Failover clustering:


I selected for your this article  – how to move a SQL 2008 cluster to a new SAN:


Notes from the field:


Note regarding the Quorum:

The Cluster service recognizes and identifies disks by their disk signatures (stored on the Quorum). Disk signatures are stored on the physical disk in the master boot record (MBR)

Failover Clustering error codes:


Note regarding Disk Signatures:
Disk Signatures
A disk signature is four-byte identifier offset 0x1B8 in a disk’s Master Boot Record, which is written to the first sector of a disk. This screenshot of a disk editor shows that the signature of my development system’s disk is 0xE9EB3AA5 (the value is stored in little-endian format, so the bytes are stored in reverse order).
Windows uses disk signatures internally to map objects like volumes to their underlying disks and starting with Windows Vista, Windows uses disk signatures in its Boot Configuration Database (BCD), which is where it stores the information the boot process uses to find boot files and settings.
Disk Signature Collisions
Windows requires the signatures to be unique, so when you attach a disk that has a signature equal to one already attached, Windows keeps the disk in “offline” mode and doesn’t read its partition table or mount its volumes. This screenshot shows how the Windows Disk Management administrative utility presents an offline disk that I caused when I attached the VHD Disk2vhd created for my development system to that system:
If you right-click on the disk, the utility offers an “Online” command that will cause Windows to analyze the disk’s partition table and mount its volumes:
When you chose the Online menu option, Windows will without warning generate a new random disk signature and assign it to the disk by writing it to the MBR. It will then be able to process the MBR and mount the volumes present, but when Windows updates the disk signature, the BCD entries become orphaned, linked with the previous disk signature, not the new one.
The BIOS may or may not enumerate disks in a specific order. There is no direct relationship between the BIOS order, and the order in which Windows numbers the disks. During startup, Windows switches from using the BIOS INT13 support to native Windows drivers to access disks. Windows waits for several seconds for the system disk to enumerate through Plug and Play. When there is a match within the time-out period, normal startup will proceed. Otherwise, the system will trigger a bug check with Stop error code of 0x7B. Windows uses other mechanisms to differentiate disks, as Windows has no control over the disk-numbering process before startup. Windows has no information about any changes to hardware when the computer is turned off. Therefore, Windows initiates its own query for device enumeration.  
The disk numbers that are assigned by Windows after it switches to native Windows storage controller drivers during startup are dependent solely on the order in which the disks are enumerated and processed by Plug and Play. Windows will enumerate available fixed disks, followed by removable disks, assuming that the correct native Windows drivers are already present and installed on the system. Various uncontrollable timing factors may affect the enumeration order.