Compellent Disk Management with PowerShell: Windows Server 2008 Disks

I was provisioning some Compellent storage today for a a series of tests that I am working on that required 62 volumes per server on two different servers.  These volumes are multi-pathed and although using the Compellent Storage Center GUI is easy and straightforward, completing this process would take a long time doing by hand and seemed fit to be automated using the Compellent Storage Center Command Set for Windows PowerShell.

I wrote a script a while back that handles my provisioning for me; in this case a couple of mount point root volumes followed by data volumes that would be accessed by mount point instead of drive letter.  The script is flexible enough to handle different volume counts and whether or not drive letters would be used, but the catch was I had only used it with Windows Server 2003. 

I tried to run the script this morning and found a flaw pretty quickly.  The volume was created on the Storage Center, mapped properly across the available paths, but when the script tried to initialize the volume in Windows, it would come back as “failed to initialize” with VDS error code 80070013.  This VDS error code indicates that the “media is write-protected”.  How could that be on a new volume?

Windows 2008 changed the way disk management is handled especially around delivery of the disk to the server.  By default, a disk mapped to a Windows 2008 server via VDS will be delivered in offline mode and also read-only.  In Windows Server 2008 there is a policy new to Windows related to SAN disks. This "SAN policy" determines whether a newly discovered disk is brought online or remains offline, and whether it is made read/write or remains read-only.  By default, the “Offline All” policy is set.  This means All newly discovered disks remain offline and read-only.  You can change this default policy in DISKPART by running the SAN POLICY=<POLICY NAME> from a DISKPART command prompt.

changing the default SAN policy in DISKPART

You can read more here, but in the meantime, the fix for this from a scripting perspective is quite simple.  The inability to initialize the disk because it was read-only was due to the SAN policy which presented the volume in a read-only fashion (and offline too).  We can change the disk attribute  of the volume so it is not read-only and then we can bring the disk online so it is usable.  Here is a sample of how to use the Command Set to change the read-only attribute and the state of the drive:

Write-Output "Bringing Disk Online..."

Set-DiskDevice -SerialNumber $scvolume.SerialNumber -Online

Set-DiskDevice -SerialNumber $scvolume.SerialNumber -ReadOnly:$false

$scvolume is a variable that refers to the volume object that is created when we create a new volume using New-SCVolume.  The serial number is used to identify the disk mapped to the Windows Server.  It is also important to note that although the “Online” and “ReadOnly” switches come from the same cmdlet, these must be executed separately as they are in the sample. (Thanks for that important tidbit, Sean!)