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!


Tags: , , , , ,

About Martyn

Martyn is one of the Senior Cloud Architects and DevOps Team Leader at one of the worlds leading Cloud Transformation Specialists Inframon. Martyn is responsible for the architecture of some of the largest Azure deployments in EMEA and is a advisor to a many businesses on their strategies. Martyn is a regular speaker at Microsoft events and community events on Azure and DevOps, giving his insight to a growing number of audiences.

13 responses to “Detecting SSD Drives in Your Task Sequence”

  1. Marc Jolley says :

    I’ve found that “objDisk.AvgDiskBytesPerRead” is recorded in the array as a string, and as such when performing the “If arrValues(x) > intBytes” logic, this sometimes evaluates as false when in fact it is true.

    I amended my copy slightly to record the value as a Long Integer, simply by amending the line;

    arrValues(i) = objDisk.AvgDiskBytesPerRead


    arrValues(i) = CLng(objDisk.AvgDiskBytesPerRead)

    I have a further issue, however, where if running against a relatively idle disk, every row in the array is zero (0). It seems the disk has to be made to do some work to get any results. Initial thoughts are to call a FindStr at the top of the script, without waiting for it to finish, run through the script as normal, then terminate Findstr.exe at the bottom. Early results show a fairly low disk usage still, so some method of maxing out the disk reads for the during of the script is needed. Ideas welcome!

  2. Carsten says :

    This is NOT not working.
    The “Sec” in DiskReadBytesPerSec stands for Sector and not Seconds.

  3. ringo says :

    is the logic flawed? granted I’m not running this in PE, but rather logged into Win7 machines (one of them with bit-locker on) but i’m not getting anything remotely close to your HDD ranges of .8 to 1.66 mb/s.
    I modified the last few lines in your script to read:
    msgbox intBytes & ” > 8388608?: ” & (intBytes > 8388608)

    results (both systems with a wd800bjkt drive with the raid driver loaded) :
    dell e6400 (bitlocker on): 7509 < 8388608
    dell e4300 (bitlocker off): 30156 < 8388608

    that makes my hdd ranges of .0075-.0288 mb/s well below yours. am i suffering that much performance not running this in a task sequence?

    • ringo says :

      correction to my previous post

      dell e6400 (bitlocker on): 7509 > 8388608: false
      dell e4300 (bitlocker off): 30156 > 8388608: false

      • Martyn says :

        Seems fine for me, like regular HHD’s SSD’s perform to different speeds, just adjust the speed to your environment.

  4. Bill Dunn says :

    Is the Script available yet?

  5. jimc84 says :

    Hi Martyn, just what i’m looking for! Looking forward to seeing the script

Trackbacks / Pingbacks

  1. SSD Drive Script - Martyn Coupland - January 14, 2014
  2. Detect SSD Drives via Script - March 1, 2012
  3. SSD Drive Script « All Things ConfigMgr - February 29, 2012

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: