Detecting SSD Drives in Your Task Sequence
The introduction of SSD drives have become a problem for those of us who deploy software and operating systems. Especially if we are deploying software such as Diskeeper which is a defragmentation tool.
The Problem: Windows 7 disabled defragging on disks which “present” themselves as solid state Performing defrag on a solid state drive will only achieve wear and tear on the drive. The fact the data is stored sequentially makes them so fast and removes the need for defragmentation. A customer on a recent engagement has Diskeeper 2011 on their standard build but some of the new hardware they will be deploying on contains solid state disks and some do not.
The problem is how to determine that a disk is solid state when the properties of a disk do not expose the fact that a disk is solid state. The other thing which came to mind is how does Windows know about a solid state drive, is it something on a kernel level that cannot be exposed to us in the OS level or something else? I asked colleagues for some assistance and my colleague Steve came back with a brilliant article from the Engineering Windows 7 team.
What interested me on this page was a bit on the FAQ section which goes like this.
Will disk defragmentation be disabled by default on SSDs?
Yes. The automatic scheduling of defragmentation will exclude partitions on devices that declare themselves as SSDs. Additionally, if the system disk has random read performance characteristics above the threshold of 8 MB/sec, then it too will be excluded. The threshold was determined by internal analysis.
The random read threshold test was added to the final product to address the fact that few SSDs on the market today properly identify themselves as SSDs. 8 MB/sec is a relatively conservative rate. While none of our tested HDDs could approach 8 MB/sec, all of our tested SSDs exceeded that threshold. SSD performance ranged between 11 MB/sec and 130 MB/sec. Of the 182 HDDs tested, only 6 configurations managed to exceed 2 MB/sec on our random read test. The other 176 ranged between 0.8 MB/sec and 1.6 MB/sec.
Interesting eh? This means that from testing we know that a pretty good baseline is to say anything which has random reads of over 8 MB/sec was 99.9% likely to be a SSD. This was the information I was looking for!
The Solution: The solution to my problem was to expose the information from a WMI performance class. Now I knew what I was looking for I quickly went onto developing a script to get the information I needed. At your disposal is a WMI class which exposes raw performance data. I am talking about the Win32_PerfRawData_PerfDisk_PhysicalDisk class.
In here we have the properties DiskWriteBytesPerSec and DiskReadBytesPerSec. All to do now is to run a script for a short amount of time, say 15 seconds to get a average of these values, convert them from bytes into MB/sec and then expose Microsoft.SMS.TSEnvironment in my script to set a task sequence variable which can then be used later in the script to determine if the disk is SSD. For example, the task sequence variable IsSolidState could be set if the MB/sec is over 8.0 then return true, then we can use this as validation on the Install Software part of our task sequence to determine if we want to run the installation or not.
The Code: Once I have finished the script and I have it working then I am happy to release it for general use, I’m a busy person but stay with me and when I am happy with it I will post the script.
Hope you all find this helpful!