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.

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:

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.

Windows 95 Special Edition; front

Windows 95 Special Edition; back

Windows 95 Special Edition; top

Windows 95 Special Edition; side 1

Windows 95 Special Edition; side 2

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.

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.

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):

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.

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.

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.

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.

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.

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.

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.

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:

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.

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

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.

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

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.

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.

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).

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.

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.

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.

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.

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:

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.

When you click Next SpinRite will launch!

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.

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.

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:

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.

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

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.

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

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.

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.

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).

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.

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.

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.

Start the SpinRite process and let it do its magic!

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!

On October 22nd 2009 Microsoft launched Windows 7 and one of their ideas to promote it was to ask some of their, uh, more loyal fans to host a launch party. People signed up and those who where selected received a party pack in the mail. I happen to have one of those party packs, so let’s have a look at what you got for your rad Windows party:

The box it all came in (sadly mine is a bit battered)

Opening the box

A deck of playing cards

A puzzle

A poster

Ten gift bags

A table top piece

A pack of napkins

A copy of Windows 7 Ultimate (dubbed Signature Edition as it has a print of Steve Ballmer’s signature on it)

It seems all of the items were designed to show off some of the wacky strange creatures art that was included as wallpapers in Windows 7.

The poster

The gift bags

The deck of cards

The puzzle

The tabletop piece

The napkins

Personally I think the poster and gift bags are really quite nice! People in the US who received this pack also got some balloons, some streamers and some coupons and offers for other products like Kaspersky AV and Zune.

Of course the most exciting reason to receive this party pack was the free copy of Windows 7 Ultimate you got which comes in a nice sleeve with Steve Ballmer’s signature printed on it.

Windows 7 Signature Edition front

Windows 7 Signature Edition back

Windows 7 Signature Edition inside

Windows 7 Signature Edition disks

Inside was a full retail edition of Windows 7 Ultimate and both 32bit and 64bit installer disks. There’s nothing special about the version of Windows, it’s just plain old Windows 7 Ultimate. The only special thing is the sleeve it comes in.

In the second part of this guide I will be migrating my online issuing CA to Windows Server 2016. As before this guide is written as a guide to upgrade from a Windows Server 2012 R2 CA to a Windows Server 2016 CA, however it is equally valid for moving a CA from any older version of Windows server to Windows Server 2016.

The majority of the steps in this guide are identical to the steps for the offline root CA, however there are a few differences as this is a domain joined system and at the end of the guide you will need to re-register any certificate templates you have.

Preparation

Start by building your new Windows Server 2016 server. I recommend again that you give it the same name as your current issuing CA, although it is possible to change it if you are willing to modify some registry keys later on in the process. If you do give this server the same name do not join it to the domain yet. This will be done later in the guide once the existing issuing CA has been removed from the domain. You should also patch the new server with the latest Microsoft patches at this time.

Migration – Backing up your existing issuing CA server

The first step is to back up the CA using the command certutil -backup C:\SubCABackup KeepLog. If you do not care about keeping the logs then you can omit the KeepLog part and instead the logs will be truncated.

You will need to enter a password, remember it and make it complex as this backup contains your issuing CA private key.

The next thing to backup is the CA configuration, which is stored in the registry in the following location: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc. Back it up by typing reg export "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc" C:\SubCABackup\CertSvcRegBackup.reg

You now also need to make a record of what certificate templates you have created as these will need to be re-registered on the new CA. The easiest way to do this is to run the command Certutil -catemplates > "C:\SubCABackup\Catemplates.txt". This pipes the output to a file called Catemplates.txt which you can open later to see the names of the templates.

It is also worth backing up your CAPolicy.inf file which you can do easily enough by copying it into the backup folder by typing copy C:\Windows\CAPolicy.inf C:\SubCABackup.

Once you have done the work to backup your existing issuing CA it is time to uninstall the CA role. Before doing this run Get-WindowsFeature in Powershell and have a look at what additional CA features you currently have installed (for example you may have the Web Enrolment service and/or Online Responder roles installed). Make a note of these so that you know what features to install on the new issuing CA server.

To uninstall the certificate authority role use the Powershell command Remove-WindowsFeature Adcs-Cert-Authority and press enter. If you did have any additional CA roles installed you may need to remove those first; in my case I had to remove the Web Enrollment service (this was done by running Uninstall-AdcsWebEnrollment).

You will need to restart the server to complete the role uninstall.

It is now important that you copy the SubCABackup folder to your new issuing CA as the next step is to remove the existing issuing CA from the domain and power it down.

To remove the old issuing CA from the domain using Powershell type Remove-Computer HOSTNAME replacing HOSTNAME with the name of your issuing CA. Restart the server to complete the domain removal and then power down the old issuing CA.

Load Active Directory Users and Computer from a management workstation and delete the computer account for the old issuing CA.

Migration – Configuring your new issuing CA and restoring from the backup

Power on your new issuing CA and join it to the domain. You can do this from Powershell by typing in Add-Computer –DomainName yourdomain.com -Credential YOURDOMAIN\Administrator replacing the domain with your domain and the admin account with your admin account. Restart the server to complete the domain join.

Once the reboot has completed you must install the CA role. Do this using Powershell by typing in Add-WindowsFeature ADCS-Cert-Authority and pressing enter. As with the root CA this now needs to be configured using the backup from the old issuing CA, which you do with the following Powershell command:

Replace the value after -CertFile with the path and name of the .p12 file from your issuing CA backup. When you press enter you will be prompted for the password you used to back up your original issuing CA.

If this step is successful you will receive ErrorID 0 as your return code.

Next you need to restore the database and logs. Before you do this the CA service must be stopped. Do that by typing in net stop certsvc and pressing enter. Once it has stopped restore the database and logs using the command certutil -f -restore C:\SubCABackup. The -f forces an overwrite of the data that was configured in the barebones CA setup. Once again you must enter the password you used to backup your original issuing CA.

Before starting the CA service you must import the registry configuration. If you opted to change the name of your issuing CA server you need to go through the C:\SubCABackup\CertSvcRegBackup.reg file and replace and reference to the old server name with your new server name. Once this is done you can import the configuration by typing reg import "C:\SubCABackup\CertSvcRegBackup.reg".

Finish up the restoration process by copying the CAPolicy.inf file back into the Windows directory by using the command copy C:\SubCABackup\CAPolicy.inf C:\Windows

One final thing

There may be one other thing you need to consider before you can start your new issuing CA and that is the location of the web CRL. This is a website that is likely hosted inside your network that contains an up to date certificate revocation list which your issuing CA needs to have access to before it will start. This may not be a problem for you at all if your web CRL is hosted on an separate web server that you did not touch during this migration. However, if like me your web CRL is hosted on your issuing CA, this will have been lost when you decommissioned your previous issuing CA.

To resolve this you will need to install IIS on your new issuing CA and configure a new site to host your CRL. The URL to the CRL must match the previously configured CRL location, so if it used to be accessible via http://PKI.yourdomain.com then it must still be accessible there now. You can find the URL for your CRL by looking at any certificate issued by your CA, going to the Details pane and looking at the CRL Distribution Points field.

Restoring your certificate templates

With everything else done you can now start your new issuing CA by typing in net start certsrv. Now you will need to re-register each of the certificate templates you had on your previous issuing CA. Open the Catemplates.txt file you saved by typing notepad Catemplates.txt and use it as a reference for the names for each of your templates. You will need to run the following command for each one:

certutil -setcatemplates +TEMPLATENAME

Replace TEMPLATENAME with the name of your certificate template. Note that + before the template name.

Do this for each of your templates. Once completed all of your templates will be available again and all issuing permissions will be retained.

That completes the process of migrating your issuing CA to a new server. If you have multiple issuing CA servers you will need to repeat this process for each of them. You may also need to reinstall any additional certificate service roles such as Web Enrollment1, which you can do either in Powershell or by using a management workstation with Server Manager. You should make sure you delete the C:\SubCABackup folder so that you don’t leave your issuing CA private key laying around.