Deploying a Windows Update with SCCM without rebooting using a Powershell script detection method

Occasionally when deploying software one of the prerequisites might be to install one or more Windows Updates. These are fairly easy to package up and deploy by simply using the command wusa.exe "KB12345678.msu" /quiet and setting the detection method to check the version of one of the files that the update effects. This information is published by Microsoft for each KB article. Once the computer reboots the file will be the newer version and the detection method will properly detect that update is installed.

But what if you don’t want to reboot immediately? It’s quite feasible that if you’re installing an update as a prerequisite to another software installation you want to install the update with the reboot suppressed and then install the software. You’d probably be using the Dependancies feature of SCCM to ensure the update gets installed whenever someone tries to install the software. In this scenario you can’t use the file version detection method as the file version will not change until after a reboot, but as you’re suppressing that reboot until after the software has been installed, the detection will fail. And that will cause the whole software deployment to fail.

The solution to this is to use a Powershell script as your deployment method. This script will do two things:

  1. Check for a particular event in the Windows Setup log that will exist when the update has been installed.
  2. Check if the file version of one of the files the update effects has been updated.

Why do you need to do both the event log check and the file version check? Because you cannot rely on the Setup log to continue to contain the log entry in the future. The Setup log may be cleared or set to roll over when it reaches a certain size and when that happens the detection will fail and incorrectly show as uninstalled in Software Center. The point of this detection method is to make the installation show as successful in the short time between the update installation and the software installation after which you will presumably reboot the machine, or in the worst case wait for the user to turn off their machine at the end of the day. Once the reboot is complete the second detection method will kick in and continue to correctly detect the installed update going forward.

So let’s take an example update and see what the package would look like in SCCM. For this example I am using KB2921916.

KB2921916 Program Properties

This part is nice and simple. Notice the uninstall program is specified as well, I consider it best practise to always include the uninstall program just in case the update causes a problem and the user needs to remove it quickly. These programs are:

wusa.exe "Windows6.1-KB2921916-x64.msu" /quiet /norestart

wusa.exe /kb:2921916 /uninstall /quiet /norestart

Hop over to the Detection Method tab and change it to Use a custom script to detect the presence of this deployment type.

KB2921916 Detection Method

Click Edit and get writing some Powershell!1

KB2921916 Detection Method Properties

That script is:

$KBToDetect = "KB2921916"
$FileToDetect = "$Env:WinDir\System32\setupapi.dll"
$VersionToDetect = "6.1.7601.18361"

Start-Sleep "5"

$GetFileVersionInfo = (Get-Item $FileToDetect).VersionInfo
$FileVersion = $GetFileVersionInfo.FileMajorPart.ToString() + "." + $GetFileVersionInfo.FileMinorPart.ToString() + "." + $GetFileVersionInfo.FileBuildPart.ToString() + "." + $GetFileVersionInfo.FilePrivatePart.ToString()

if ([Version] $FileVersion -ge [Version] $VersionToDetect) {return $true}

if (Get-WinEvent -ErrorAction "SilentlyContinue" -MaxEvents 3 -FilterHashtable @{logname = 'setup'} | select message | Select-String -SimpleMatch "A reboot is necessary before package $KBToDetect can be changed to the Installed state.") {return $true}

There’s quite a lot going on here so let’s briefly run through it. The first three variables define what we are looking for and you will have to update these based on the KB you are installing. Having another look the KB2921916 article and expanding the File information section you can see that one of the files that updates is Setupapi.dll. This file can be found in %SystemDrive%\System32\Setupapi.dll and will bring its version number to 6.1.7601.18361. These details have been added to the $KBToDetect, $FileToDetect and $VersionToDetect variables.

The next part is a simple 5 second sleep. I added this because in my testing I found that sometimes the detection script runs before the Setup log entry is added which causes the detection to fail. By waiting 5 seconds before running the detection we ensure the log entry is in place when the detection runs.

The next part is the needlessly complicated (in my opinion) code needed to find the version of Setupapi.dll. If you just try (Get-Item $FileToDetect).VersionInfo.ProduectVersion you will not get the current version of the file, you will get the version the file was when it shipped! This weirdness is known and has been blogged about. So this code gathers the individual parts of the file’s true version (the FileMajorPart, FileMinorPart, FileBuildPart and FilePrivatePart) and constructs a full version string out of it.

The next two lines are the only ones that really matter for the detection. The first if statement checks the file version and returns $true if the installed version of Setupapi.dll is either equal to or greater than 6.1.7601.18361. This will ensure that post reboot the detection method will still work and ensures that it will also continue to detect correctly if the file version increases again in the future.

The second if statement checks the last 3 events in the Setup log and searches for the string “A reboot is necessary before package $KBToDetect can be changed to the Installed state.” If this string is found then it returns $true.

Note that nothing at all is returned if neither of these if statements is true. That is by design because when you use Powershell as a detection method practically any output from the script is taken to be success so if it fails it must return nothing.

Only one thing left to do now. Click on the User Experience tab and change the enforced behaviour from the default (Determine behaviour based on return codes) to No specific action.

KB2921916 User Experience Properties

This is important because if you don’t do this the return code will be 3010 (soft reboot) and the user will be prompted to reboot regardless of your /noreboot switch. If this happens any further components of the deployment will wait until the reboot has been completed which is probably what you’re trying to avoid!

1In order to use a Powershell script detection method you will need to ensure that you have the Powershell execution policy set to Bypass on your clients. That is unless you’re doing things very properly and have a code signing script that your clients trust that you can sign your Powershell detection scripts with. You can set the execution policy in the Client settings in SCCM or via GPO.

Outlook 2016 slow loading issue

If there is one splash screen I have become sick of staring at over the past few weeks it is the one for Outlook 2016, with those irritating little dots sliding across the screen while Outlook is supposedly “Loading Profile” or “Processing”.

Urghhhhhhhhh

If you, like me, have spent quite a lot of time researching the cause of this problem you will probably have found that quite a lot of things can cause it. You’ve probably scanned and repaired your Outlook Data Files with SCANSPST.exe, created a new profile, repaired your Office 2016 install, opened Outlook in safe mode (or otherwise disabled all of the add-ins), removed any additional mailboxes or shared calendars and any number of other solutions you will find online.

These things probably do help to fix the issue if it is affecting only certain individuals, but what if the problem is affecting everyone in the office who upgrades to Outlook 2016? I had users who had previously been running Outlook 2010 or 2013 and were not seeing any problem with Outlook loading times, with it typically only taking between 10 to 15 seconds to load. But as soon as they were upgraded to Outlook 2016 it would take anywhere from 5 minutes to 15 minutes to load and some people reported times even longer than that.

A small curiosity about this problem was that it only affected the first launch of Outlook after turning on or restarting the machine. A user could close and reopen Outlook as many times as they liked once it had started the first time and it would load within a few seconds. Even more curious was that if a user did not launch Outlook immediately after logging in, but instead waited between 5 to 10 minutes before doing so, it would launch fine. I also found that if the machine was not connected to any network when Outlook was launched it would launch in just a few seconds. Obviously this meant Outlook was in offline mode and wasn’t very useful, but it did suggest that something was going on over the network that was causing Outlook to hang while loading.

To figure out the cause of this issue I started with a vanilla build of Windows 7 installed on a laptop with Office 2016 and connected it to the corporate network. I went through the steps of launching Outlook for the first time and setting up my profile and then proceeded to restart the laptop for the first proper test. The result? Outlook launched in 10 seconds. So it appeared the network on its own was not the cause.

Next I joined the laptop to the domain and left it in the Computers container. I also moved my user account into an OU with blocked inheritance. This meant that I could test with a minimal set of GPOs applied (the ones at the domain level only). I expected that I would have to apply one GPO at a time and test until I identified the GPO that was causing the problem (assuming that it even was a GPO causing the problem). However I did not have to go through that laborious process at all as the problem returned the first time I opened Outlook after adding the machine to the domain. This told me that one of the GPOs applied at the domain level was causing the problem.

That just left identifying which specific setting was causing the problem. Let’s see… a logon legal notice, some Internet Explorer site zoning and… hmm… the DNS suffix search list. Perhaps Outlook is taking ages looking for autodiscover on each of these domains? (Purely hypothesising; it wasn’t that).

As I was fairly sure the cause of the issue wouldn’t be the legal notice or the IE zoning I gave my attention on the DNS suffixes. There where quite a few of them so I thought it would be a good idea to first remove them all to see if the problem persists, and if it didn’t, add them back one at a time until the problem came back. To do this I navigated to the registry key HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows NT\DNSClient, made a note of what was in the SearchList value and then deleted it, leaving the SearchList value empty. I then amended the permissions on the DNSClient key to prevent Windows simply adding the values back in the next time GPOs where processed. To do this I right clicked on the DNSClient key and selected Permissions, clicked on Advanced and unticked Include inheritable permissions from this object’s parent and then in the security notice that comes up I clicked Add. This allowed me to freely change the permission I needed to change. I clicked OK to dismiss the advanced security settings box and in the simple permissions box, clicked on SYSTEM and removed the Full Control permission (leaving it with just Read). Following that I restarted the laptop and opened Outlook to see how long it would take; it took 10 seconds. Bingo.

Next I proceeded to add back one domain at a time to the SearchList registry value, each time restarting the laptop and opening Outlook until I struck on the one domain that was causing Outlook to take an age to load. I then confirmed that was the only domain causing the problem by adding them all back except that one, and once that was proven I added back the troublesome domain to prove that by adding it back, the problem returned. With about 50% of the root cause determined it was time to get Wireshark out and find out exactly why having that domain in the DNS search list was causing Outlook to load slowly.

After restarting the laptop I immediately opened Wireshark to began a trace and then opened Outlook. Once Outlook had finished opening I stopped the trace and started looking through. I noticed at the start of the trace that there where several DNS lookups being made for WPAD on each domain in the DNS search list.

Windows WPAD DNS Lookups

WPAD is the Web Proxy Auto-Discovery Protocol and is used by the WinHTTP Web Proxy Auto-Discovery Service and Internet Explorer to automatically find a proxy server on your network to route Internet traffic through. Windows checks for WPAD entries in each domain on your DNS search list even if you don’t use WPAD to assign a proxy. You may even believe you had WPAD turned off by having Automatically detect settings unticked in your Internet options, however this only turns it off for Internet Explorer. The WinHTTP Web Proxy Auto-Discovery Service still goes looking for them.

Most of the domains did not have a record for WPAD, however legacydomain.com did have a record and therefore wpad.legacydomain.com returned an IP address. This IP address was not assigned to any device (the device having been decommissioned at some point in the past) and this seems to be the key issue here. If no IP address is returned from DNS Windows moves straight on to the next domain, but if an IP address is returned Windows will attempt to route traffic through that IP address for several minutes before it gives up, and it is during this time that your Outlook client is hanging on the splash screen.

In this image you can see that my client attempted to send packets to 192.168.0.10 (the IP returned by wpad.legacydomain.com) several times with approximately 20 seconds between each attempt. The first packet was sent at 09:03:51 and the last packet (which is cropped out of the image below) was sent at 09:08:34 – 4 minutes and 45 seconds later!

Outlook Opening Wireshark Trace

As the network device that was originally assigned to 192.168.0.10 was no longer around I removed the DNS record for WPAD in the legacydomain.com DNS zone and the slow Outlook loading problem went away.

This explains some of the observations made at the beginning of this post regarding Outlook only being slow to load the first time you launch it and Outlook loading quickly if you wait a few minutes after logging on. The issue is not being caused by Outlook, Outlook is merely a victim of Windows’ HTTP proxy service latching on to the IP addresses returned by DNS and spending time trying to route traffic through them. If you wait a few minutes before launching Outlook or close and reopen it during the day the WPAD process has already happened so Outlook hasn’t got to wait for anything.

So if you are experiencing issues with Outlook starting slowly and have already tried everything you can find on the Internet, I would suggest making sure you haven’t got any stale WPAD entries in DNS! It could be a very quick fix for a very frustrating issue.

 

Windows 95 Special Edition

On August 24th 1995 Microsoft hosted a Windows 95 launch event at their campus in Redmond, Washington. At this event journalists and other attendees were gifted a copy of Windows 95 in a special commemorative box: Windows 95 Special Edition.

IMG_8300

Only 3,000 copies where handed out making this a fairly rare item to have (especially now, 22 years later).

The inside cover opens up and inside the following text can be found:

Screen Shot 2017-11-28 at 18.38.34

In the box you get a CD copy of Windows 95 – upgrade! Apparently Microsoft couldn’t bring themselves to give away free copies with a full license. You also get the owners manual, a leaflet introducing you to The Microsoft Network and a little Launch95: Introducing the world of Windows 95 insert.

And that’s it! The copy of Windows 95 is no different to the version you could buy in the shops, so the only thing about that this is special is the box.

Issue downloading Office 365 Click-to-run – Error code 30125-1007 (502)

When trying to download Office 365 Click-to-run one of the steps you have to follow is to configure an XML file with your source path, client edition, channel etc. You also have to specify the language you want to download.

<Configuration>
<Add OfficeClientEdition="32" Channel="Monthly" OfficeMgmtCOM="TRUE">
<Product ID="O365ProPlusRetail">
<Language ID="en-us"/>
</Product>
</Add>
<Display Level="None" AcceptEULA="TRUE"/>
</Configuration>

If you try to use a language ID that is not supported in Office 2016 you will get the error 30125-1007 (502):

OfficeCouldntInstall

The fix is to make sure you use one of the supported language IDs from the list at the following link:

https://technet.microsoft.com/en-us/library/cc179219(v=office.16).aspx

Bonus cool stuff: You can create your Office download and configuration XML file using this handy GitHub tool: https://officedev.github.io/Office-IT-Pro-Deployment-Scripts/XmlEditor.html

BITS throttling causing slow SCCM client install and policy download

SCCM extensively uses Background Intelligent Transfer Service (BITS) to transfer data between a client and the SCCM server. This also affects downloading client policy! One of the first things that SCCM uses BITS for is to download the client to the machine when you initiate a client push. If BITS is heavily throttled you may find the following entries in your ccmsetup.log file (typically found in C:\Windows\ccmsetup):

Starting BITS download for client deployment files.
Download update: Copy job has been queued.
Download update: Copy job has been queued.
Download update: Copy job has been queued.

There may be some entries showing the progress of the client download, however if BITS is throttled this may be proceeding very slowly.

If you want to check whether BITS is being throttled on a particular machine open a command prompt window and type RSoP to perform a Resultant Set of Policy. Once the RSoP window opens navigate to Computer Configuration —> Administrative Template —> Network —> Background Intelligent Transfer Service (BITS) —> Limit the maximum network bandwidth for BITS background transfers and check if it is enabled and what limitations are in place.

In my case it was limited to 10 KBs at all times! Far too slow to get anything done in a reasonable time.

The next thing you can do before you start talking with your fellow sysadmins and the  network team about removing the throttling is to prove that it is the BITS throttling causing the issue. As long as you are a local administrator on one of the clients this can be done quickly by editing one registry key and restarting the Background Intelligent Transfer Service. Open regedit and navigate to HKLM\SOFTWARE\Policies\Microsoft\Windows\BITS and change EnableBitsMaxBandwidth from 1 to 0. Then open services.msc and restart Background Intelligent Transfer Service. This will remove the BITS throttling on that machine until group policy is reapplied and sets EnableBitsMaxBandwidth back to 1. Before that happens however you should have time to re-deploy the SCCM agent or push a new client policy and observe whether or not it happens in a much more timely fashion than it did before.

Running SpinRite 6.0 on MacOS (Part 2)

Running SpinRite 6.0 on MacOS (Part 1)
Running SpinRite 6.0 on MacOS (Part 2)

The first part of this guide focused on running SpinRite on your Mac to scan an external drive. However, what if you want to run SpinRite on your Mac’s internal drive? If you’re running a fairly modern Mac your storage will be soldered to the motherboard making it impossible to remove. So much for removing the drive so that you can run SpinRite on another computer! This post will guide you through the process of running SpinRite on your Mac’s internal storage using your Mac!

In order to proceed with this you will need an external hard drive or USB drive with at least 20 GB of space available on it. This is because you will be installing MacOS onto an external drive and booting your Mac from it. The faster this storage, the better! USB 3.1 (and USB C) and Thunderbolt drives will work best.

As with Part 1 this guide is aimed at more advanced users. I highly recommend making a backup of your system before starting (assuming your hard drive isn’t so far gone you can’t do that). I also recommend reading Part 1 to familiarise yourself with the process that will be followed here, though it is not identical it is similar.

I would also like to thank Miguel from the comments section of Part 1 for the inspiration for Part 2.

Installing MacOS on an external drive

The first part of this guide is to install MacOS onto an external drive. Start by opening the App Store and searching for MacOS High Sierra and proceeding to download it.

While that is downloading plug in your external drive and open Disk Utility. In the View menu make sure Show All Devices is selected.

DiskUtilityShowAllDevices

When selecting your external storage make sure you select the top level item (in my example below this is JetFlash Transc… rather than Transcent below it) and click Erase. Give it any name you wish and make sure the format is Mac OS Extended (Journaled) and the Scheme is set to GUID Partition Map.

DiskUtilityErase

Once that is done wait for the MacOS High Sierra download to complete. Once it has the installer will launch automatically. On the first screen of the installer click Next and then accept the EULA. On the disk selection screen click Show All Disks… and then select your external drive.

MacOSDiskSelect

Click Install and you will be prompted to enter your password in order to install a helper. Enter your password and click Add Helper and the installation will begin. Once the first part of the install is done your Mac will reboot and continue installing. Allow this process to complete.

MacOSInstalling

When this is done you will need to run through the first startup process, setting your language and keyboard options. Go through it as minimally as possible (for example you don’t need to sign in with your Apple ID). You should connect to WiFi or ethernet as you will need to install VirtualBox and will need a way to transfer your SpinRite.ISO to this install of MacOS.

Running SpinRite on your Mac’s internal storage

All steps in this part of the guide need to be done from your new MacOS install running from your external storage. If you need to return to your regular MacOS install simply restart your Mac and remove the external storage from your Mac.

The first step is to download and install VirtualBox. There is nothing special about the installation so just follow the wizard through without changing any of the options. You also need to transfer your copy of SpinRite to the new MacOS install (you need the ISO, read the first section in Part 1 of this series for details on getting that).

If your internal Mac storage is encrypted with FileVault MacOS will prompt you for the password to unlock it every time the drive mounts. You can click Cancel any time this prompt appears as it is not necessary to unlock the drive to run SpinRite on it.

With VirtualBox installed and your SpinRite.ISO at the ready, let’s begin!

Start by opening Terminal and running diskutil list. A list of disks attached to your Mac will be returned and the one we are looking for is your internal disk. Look for the one with a type of Apple_HFS or Apple_APFS. In my example this is /dev/disk0.

DiskUtilList

The next thing to do is unmount this drive. This is done by typing in diskutil unmountdisk /dev/disk0. Remember to change this disk to the one that is correct for you.

UnMountDisk

Now you need to create a vmdk file that will be attached to the virtual machine. This vmdk will direct all input and output to your Mac’s internal drive. This is done using the following command:

sudo /usr/local/bin/VBoxManage internalcommands createrawvmdk -filename RawDisk.vmdk -rawdisk /dev/disk0

If you get an error stating VERR_RESOURCE_BUSY make sure /dev/disk0 is not mounted (rerun the command diskutil unmountdisk /dev/disk0 if necessary). When you run the command you will be prompted for your password, enter it and press enter.

CreateVMDK

This will create a file RawDisk.vmdk in the root of your home directory. This will also re-mount the disk. Unmount it again using diskutil unmountdisk /dev/disk0.

Now you need to launch VirtualBox as root which can also be done using Terminal. This is required to allow read and write access to a raw device. Launch VirtualBox using the following command:

sudo /Applications/VirtualBox.app/Contents/MacOS/VirtualBox

launchVirtualBox

Do not close this Terminal window. As VirtualBox was launched through Terminal you must keep Terminal open throughout the rest of the process and while using SpinRite.

Create a new VM by clicking New, give it a name, select Other under Type and under version select DOS, then click Continue.

NewVM

Under Memory size the default of 32 MB is more than enough so accept that and click Continue.

VMmemory

Under Hard disk select Use an existing virtual hard disk file and click on the little folder icon next to it to bring up the file selection prompt.

SelectexistingHD

As you are running VirtualBox under root you will be taken to the folder structure for the root user account. However the RawDisk.vmdk file is saved in your user area. At the top of the file selection window click on the drop down box and select Macintosh HD (or whatever your Mac’s hard drive is called). From there select Users > your username.

SelectMacHD

In this folder you should find RawDisk.vmdk. Click on Open.

If you get an error VERR_RESOURCE_BUSY when trying to open RawDisk.vmdk make sure that /dev/disk0 haven’t been mounted again (check using diskutil list and fix using the same diskutil unmountdisk command as before).

SelectRawDisk

As soon as you click Open MacOS will remount the disk. This must be rectified again by using the command the same way as before. In my case it is  diskutil unmountdisk /dev/disk0. You will have to do this in a new Terminal window as you can no longer interact with the one you launched VirtualBox from until you close VirtualBox.

Once that is done click Create.

NewVMHDSelected

Open Settings for the VM and go to Storage and select the CD icon underneath RawDisk.vmdk. Next to Optical Drive click on the small CD icon and use the file explorer that pops up to select your SpinRite.iso file. Once that is done click on OK.

SelectSpinRiteISO

Power on the VM and it should automatically boot from the CD and launch SpinRite! Assuming you already know how to use SpinRite make your way through the menu and select the disk you have attached to your Mac. It is recommended that you only run SpinRite on Level 2 for SSD storage.

SpinRiteRunning

And that’s it! You may wish to hold on to your external MacOS install for future use as it is quite a hassle getting one of those set up and it is good practise to run SpinRite on your drive on a fairly regular basis.

 

Running SpinRite 6.0 on MacOS (Part 1)

Running SpinRite 6.0 on MacOS (Part 1)
Running SpinRite 6.0 on MacOS (Part 2)

SpinRite is an excellent disk maintenance and recovery tool provided by Steve Gibson over at https://www.grc.com. There are many success stories from its use provided by Steve frequently on his Security Now! podcast.

There are various guides online for running SpinRite on a Mac but none that I found worked exactly as described, so this is my guide based on how I got SpinRite to work on my Mac. The basic principle is to set up a virtual machine on your Mac and give it raw block access to the disk and then run SpinRite as normal within the VM.

This guide is written using the following versions of software so your experience may differ if you are using different versions:

MacOS Sierra 10.12.6 (also works with MacOS High Sierra 10.13)
SpinRite 6.0
VirtualBox 5.1.26 r117224
PlayOnMac 4.2.12

This guide is designed for more advanced users as granting anything raw block access to a disk can be dangerous, especially if you select the wrong disk! Please be careful while following these steps.

This guide does rely on you connecting the hard disk up to your Mac via USB using a caddy. It may be that the disk is so far gone that it will not mount in MacOS and if that is the case you will not be able to use this guide. However it may still be possible to run SpinRite on it by connecting it directly to the motherboard of another computer via SATA or IDE.

Creating an ISO from the SpinRite.exe provided

When you first purchase and download SpinRite you are given the file SpinRite.exe to run which you can use to install locally or create an ISO to boot from. The easiest way to get the ISO is to run SpinRite.exe on any Windows system you have available, or even a Windows VM running on your Mac and copy the SpinRite.iso file across to your Mac. However if that simply is not possible for you an alternative way is to run SpinRite.exe in Wine on your Mac. I prefer the implementation provide by PlayOnMac so I will be using that in this guide. If you can create the ISO in Windows skip ahead to the next section.

The first step is to download and install PlayOnMac. Once you have it, launch it and select Install a program. In the new window that comes up click on Install a non-listed program.

Click Next on both “Please read this” windows then Next again when the Manual Installation wizard comes up. Select Install a program in a new virtual drive and click Next. Give it a name (SpinRite will do) and click Next. Do not tick any of the before installation options and click Next. Select 32 bits windows installation and click Next. Click Cancel on any additional installations that Wine prompts you about (such as Wine Gecko) until you reach the select set-up file to run screen.

Click Browse and select your SpinRite.exe file.

SpinRiteonPlayOnMac

When you click Next SpinRite will launch!

SpinRiteonPlayOnMac2

Click Create ISO or IMG File and then Save a Boot Image File. When the folder structure appears select Users > your username > Desktop to save the SpinRite.iso file to the desktop on your Mac. Once that has been successfully created exit SpinRite and PlayOnMac.

Running SpinRite on your Mac in a VirtualBox VM

The first step here is to download and install VirtualBox. There is nothing special about the installation so just follow the wizard through without changing any of the options.

Attach the hard disk you want to run SpinRite on by connecting it to a USB caddy and plugging the USB into your Mac. Unplug any other external drive you may have connected. Next, open Terminal and enter the command diskutil list to see the disks attached to your Mac. The disks prefixed with external will be the one you have connected up, followed by physical or virtual. In my example these are /dev/disk4 (physical) and /dev/disk5 (virtual). You may have multiple virtual entries depending on how many partitions are on the disk. You can also use the size of the disk to verify it is the correct one. Write down each of the disk identifiers that relate to the external drive.

diskutildisks

The next step is to unmount the virtual disk partitions, but not the physical disk. In my case that means unmounting /dev/disk5. To do this type diskutil unmountdisk /dev/disk5. Repeat this for any other virtual disk partitions your drive has.

UnmountDisk

Now you need to create a vmdk file that will be attached to the virtual machine. This vmdk will direct all input and output to the physical disk you have connected. This is done using the following command:

sudo /usr/local/bin/VBoxManage internalcommands createrawvmdk -filename RawDisk.vmdk -rawdisk /dev/disk4

Note that for this command you must use the disk identifier for the physical disk and not any of the virtual disks. In my case this is /dev/disk4. If you get an error stating VERR_RESOURCE_BUSY make sure have you have unmounted every virtual disk. When you run the command you will be prompted for your password, enter it and press enter.

Createvmdk

This will create a file RawDisk.vmdk in the root of your home directory. This will also re-mount the disk. Unmount it again using diskutil unmountdisk /dev/disk5 (virtual ones again).

Now you need to launch VirtualBox as root which can also be done using Terminal. This is required to allow read and write access to a raw device. Launch VirtualBox using the following command:

sudo /Applications/VirtualBox.app/Contents/MacOS/VirtualBox

launchVirtualBox

Do not close this Terminal window. As VirtualBox was launched through Terminal you must keep Terminal open throughout the rest of the process and while using SpinRite.

Create a new VM by clicking New, give it a name, select Other under Type and under version select DOS, then click Continue.

NewVM

Under Memory size the default of 32 MB is more than enough so accept that and click Continue.

VMmemory

Under Hard disk select Use an existing virtual hard disk file and click on the little folder icon next to it to bring up the file selection prompt.

SelectexistingHD

As you are running VirtualBox under root you will be taken to the folder structure for the root user account. However the RawDisk.vmdk file is saved in your user area. At the top of the file selection window click on the drop down box and select Macintosh HD (or whatever your Mac’s hard drive is called). From there select Users > your username.

SelectMacHD

In this folder you should find RawDisk.vmdk. Click on Open.

If you get an error VERR_RESOURCE_BUSY when trying to open RawDisk.vmdk make sure that the external virtual disks haven’t been mounted again (check using diskutil list and fix using the same diskutil unmountdisk command as before).

SelectRawDisk

As soon as you click Open Mac OS will actually remount the disk – how annoying! This must be rectified again by using the command the same way as before. In my case it is  diskutil unmountdisk /dev/disk5. You will have to do this in a new Terminal window as you can no longer interact with the one you launched VirtualBox from until you close VirtualBox.

Once that is done click Create.

NewVMHDSelected

Open Settings for the VM and go to Storage and select the CD icon underneath RawDisk.vmdk. Next to Optical Drive click on the small CD icon and use the file explorer that pops up to select your SpinRite.iso file. Once that is done click on OK.

SelectSpinRiteISO

Power on the VM and it should automatically boot from the CD and launch SpinRite! Assuming you already know how to use SpinRite make your way through the menu and select the disk you have attached to your Mac.

SpinRiteStarted

Start the SpinRite process and let it do its magic!

SpinRiteRunning

That’s it for running SpinRite on your Mac. Phew! … Bring on the future releases of SpinRite 6.x and 7.0 for better Mac compatibility!