In a recent upgrade for our computer pool, we also wanted to install SSDs in every computer. While SSDs are great, they usually don’t work that well with huge amounts of data. Some of our users store 100+ GB of data on the computers. Even though SSDs are becoming cheaper and cheaper, it wouldn’t make sense to put a 1 TB SSD in every computer: it is just too expensive.

Because of that we decided to take another approach: Every computer gets a relatively large 250 GB SSD and a 1+ TB HDD. We install the OS and Apps onto the SSD. First, I thought we could move the C:\Users directory to the HDD. Well, it turns out that this is actually possible, but not really a recommended thing to do. I didn’t test it, so I can’t really say anything about it, but this KB describes known issues with the FolderLocation setting. Despite being not-really-supported by Microsoft, users won’t profit too much from the SSD performance. Their user profile which usually contains lots of small files that are read often will still be on the slow HDD.

So we took another approach. Because compiling software from a network share is painfully slow, our users usually store their sources on the local drive and then copy it to the server in the evening before they leave. Our MDT does the following on OS installation:

• Remove Permisison for “Authenticated Users” to create new directories/files on the root of SSD and HDD drive. Previously, we didn’t do this so users started creating directories all over the C: drive, which was quite chaotic…
• Create a scheduled task triggered by user login that creates a directory on the HDD to which the user has exclusive access to.
• Share that folder on the network so users can copy their files from the computer if they ever need them on a different computer.
• I am currently developing a script that copies the local data from the HDD to the server and shuts the computer down afterwards. Our users can then start this script when they leave and don’t have to wait for the copy process to finish.

We will be deploying this to our computers in the next weeks. I set it up on a test computer a few days ago and will see how it works.

At first, the unattended deployment of VirtualBox might sound quite complicated, because the installer needs to set up drivers and do quite a bit of complicated stuff. Additionally, the installer of VirtualBox offered on the website is an EXE file and not a convenient MSI file.

But overall, it is quite simple to do an unattended installation of virtualbox. With a little bit of googling you can find this excellent guide on the VirtualBox website. Then, the steps are simple:

1. Download the latest version from the VirtualBox website.
2. Fortunately, the EXE file is just a wrapper for a MSI. Just run:

   VirtualBox.exe -extract

   (adjust the filename as needed). After a short time, a dialog box will tell you where the MSIs (for x64 and x86) has been extracted to.
3. Now comes the tricky part. VirtualBox will install some drivers that are signed with a certificate that Windows does not trust by default. Thus, a prompt will apear during the installation. The trick is to import the certificates into the certificate store before installation:
   1. Install VirtualBox on your computer. When a driver prompt appears, be sure to check the box "Always trust Content" and click "Install".
   2. After the installation has finished, start

      certmgr.msc

      and navigate to "Trusted Publishers". Export every certificate that has "Oracle" or "Sun" in its name to a path of your choice.
   3. Distribute the exported certificates with the MSI files from above.
4. For the installation, run the following command for each of the certificates you have exported above:

   certutil -addstore "TrustedPublisher" oracle.cer

5. Then, run the installation like a normal MSI:

   msiexec /i Virtualbox.msi /passive

In my case, I created a small batch file that installed the certificates and then imported it into MDT. Works like a charm!