Category: General Computing

After completing a fourth batch of SP-4 SCSI cards for some nice patient folks who still needed one, I wanted to find a new electronics project to keep me busy.  I’ve had an old TRS-80 Model III rotting at the bottom of a closet for about the last twenty years or so which I originally purchased secondhand from a guy at work.  Even though it was stored in dry conditions, I’ve read a fair number of horror stories about ancient electrolytic capacitors that go up in smoke when you actually power these things up after sitting idle for so long.  So my new project was to “re-cap”, or replace all the failure-prone capacitors, in the old grey box.

  • Find the Repair Manual. Several years ago I found a large online trove of TRS-80 book scans and virtually all of the interesting software images for the system, which I promptly robo-downloaded and now keep safe for posterity. You never know when sites like this are going to fold up shop unexpectedly, so my feeling is that it’s usually best to grab stuff while you can in such cases.  The archive includes the Model III Technical manual among many other goodies.
  • Take The Thing Apart.  The manual includes good disassembly instructions, which is nice to have because these things are a mass of hand-soldered wires, sheet metal shielding, and odd-sized screws.  They weren’t exactly designed for manufacturing efficiency and near-snap-together construction like most modern PCs.  There’s also a 12″ CRT tube for the screen in there, which is highly fragile and could easily be broken by whacking it against some other internal component.
  • Get All The PCBs out. (Printed circuit boards, not polychlorinated biphenyls.) To remove the old components and replace them requires being able to get at the undersides to desolder the leads.  Below are six of the seven boards in the Model III.  Clockwise from the top, these are:
    • The RS-232 port (a whole board!)
    • The CPU board, which includes three ROMs at lower left, 48K of DRAM at lower right, the Z80 CPU (bottom center), and the video generator (much of the upper section of the board, including 1K of SRAM and the character generator ROM (the largish chip top center.)
    • The floppy disk controller, with edge connectors at the top for internal drives and at the bottom for external ones. The large chip is the WD1793 controller.
    • Two identical power supplies putting out +12, -12, and +5V.  One powers the CPU board, the CRT control board (not shown), and the serial port.  The second powers the floppy controller and the internal floppy drives.  Each supply is rated for about 40W of output.
  • Figure Out Replacement Parts:  The caps in question are all those little blue or black round cans sprinkled across the boards, and a few others. The caps most prone to “sudden spontaneous disassembly” are the two rectangular green ones on the power supplies – the left most board and the identical one in the middle.  These filter RF noise from getting out of the computer and back into the power lines.Figuring out the right replacements was a fairly time consuming task. The Technical Manual actually includes complete schematics and part lists for the entire computer, something that’s completely unheard of today.  (It’s an enormously interesting and educational read to go through, as they explain the theory of operation behind all of the major sections of the design.)  However, the part lists are not 100% accurate and occasional board revisions resulted in changes to what’s actually populated.  So it was necessary to cross reference the listed parts with what was actually there, and note the changes.   Then it was a long session with the Digi-Key online part finder to choose appropriate replacements – the most important thing to ensure is that the approximate size of the part you’re choosing matches what was there previously so that it fits in the available space – very frequently, the same nominal capacitor (in uF capacity and rated voltage) will be available in a wide range of physical sizes, some of which might be far too small or too large to be a suitable replacement.  Furthermore, since many of these are in power supplies and being exposed to mains voltage and potential fluctuations, choosing a suitable replacement which can handle significant ripple current and is also rated for multiple-thousand hours of useful life is an important consideration. Ideally, I’d like the system to be able to go another twenty or thirty years (of light usage) before needing to consider repeating the exercise, sometime around my eightieth birthday. 🙂
  • Order Parts, and Install Them.  Big box o’ caps arrives in the mail, and then it’s just a long session with the solder wick and the iron, removing the old and reinstalling the new.

Interestingly, this turned out to be the easy part of the rehab, because several additional age-related issues (if not really wear per se) made themselves evident during the reassembly.

First, the floppy controller and the serial port board are connected to the CPU board via some very early examples of flat flex cables.  These are ubiquitous today and are ideal for interconnection of parts in mobile phones when space considerations require components to be split across multiple boards (or not part of a board at all, like iPhone camera modules, for example.)  However, these flex cables were really primitive – they amounted to flat strips of aluminum or tin (something shiny but not copper) adhered to a base plastic layer with some kind of adhesive and then sandwiched under another layer of plastic to protect the conductors, except at the ends where they connect to the circuit boards.  While it was necessary to remove these cables in order to take the boards out, putting them back in proved to be problematic.  The adhesive used to hold the conducting strips in place had completely disintegrated with age, and any attempt to reinsert them in their connecting terminals just resulted in the whole thing delaminating and leaving me with something like shredded tin foil. 😦IMG_0776Luckily, you can buy modern off-the-shelf replacements made from Kapton (polyimide) from Digi-Key with nice robust solder tabs on the ends, so this wasn’t too big a deal.

The other minor repair that turned out to be an unexpected pain was in the latch of one of the floppy drives.  As soon as I had the whole thing back together and working, the latch of floppy #2 IMMEDIATELY broke as soon as I opened the drive, and came off in my hand!  Ugh.  This turns out to be a known weak point of these Texas Peripherals drives. (TP was evidently a joint manufacturing venture between Tandy and Tandon.)  There is a little bracket that connects the floppy door to the internal mechanism that clamps down on the disk, and the whole thing relies on some tiny plastic pins that have to withstand what is likely several pounds of spring force from the latch trying to re-open itself.  The plastic of the latch obviously got brittle with age and gave way instantly.

Some folks on the VCFED.ORG (Vintage Computer Forum) site recommended epoxy to hold the weak piece back in place, but several tries at this proved that it was never going to withstand the stress.  This is where having a 3D printer and a micrometer comes in handy. I’m kinda proud of myself, because after giving up on the epoxy route, I whipped up a replacement piece in Fusion 360 by measuring the original, and printed it out.  Worked perfectly the first time.  The STL files are now posted on Thingiverse, but if you want a few printed and shipped just drop me a note in the comments.Pivot.png

It looks big in the screenshot, but it’s only about 3cm across, and the holes for the pins are only about 2.5mm.  Incidentally, the yellow plane cutting the thing down the middle is something I put there to allow me to export it in halves and print it in two pieces. This way, the outside edges would lay flat on the printer bed without having to print with “overhangs.” 3D printers don’t do so well printing parts hanging in empty space, which is what would’ve happened if I printed it all in one piece.  The two halves glue together with acrylic cement in just a few seconds. It’ll hold up just fine, since there are two big screws holding the flat part down through the oval holes, and there’s no stress at all placed on the glued seam.

Here are the pins, the original piece after the ill-fated epoxying, and the final 3D-printed replacement after installation, just visible toward the top of the interior behind the open door. It looks a little warped because of the funny angle and the close-up shot, it’s actually pretty straight in reality.  And yes, the glued gap between the two halves looks a little ugly, but it’s quite strong and invisible inside the drive, whereas the epoxied original didn’t withstand more than a few seconds in place before going Sproiinnggg.9BD32541-2BC8-40D8-A3E2-67A716F8EBBE


So, that’s it!  Model III refurbishment complete!


In my last post I discussed creating some low-cost Azure virtual infrastructure to handle failover duties for Active Directory domain controller roles using OpenVPN to create a site-to-site encrypted tunnel.

Managing some of these roles, including OpenVPN Access Server’s management website, and Remote Desktop Gateway, requires exposing a web site to the public internet and using SSL (https://…) to encrypt the traffic between the client and the server.  Out of the box, OpenVPN AS runs on Linux with a self-signed certificate from OpenVPN, but this inevitably causes security warnings from any web browser, since OpenVPN is not a recognized public CA and trust is therefore unverified.  In order to rid yourself of the warnings, but more importantly, to ensure that the web site you think you’re connecting to really is that site and not an impostor, you need to either add the OpenVPN CA to your Windows certificate store on every machine you might connect from, or alternatively, you can set up your own CA on Windows Server.

An Enterprise PKI in Windows Server creates a self-signed root certificate which can then easily be distributed to all machines in the domain with group policy, allowing any child certificates created by that root authority to be automatically trusted by web browsers.  Running your own CA also creates other benefits such as allowing a higher degree of security and trust between domain controllers and clients, limiting remote access to clients with a valid certificate, and so forth.

Unfortunately, it turned out to not be such a slam dunk to generate a web server certificate for the Linux VM running the OpenVPN Access Server due to a combination of tools and processes that weren’t really designed to work together seamlessly, and it becomes more complex if you want the cert to be valid for multiple names for the same site, e.g. “https://internalname” and “” and “”.  I ultimately found two ways to get the Windows CA to issue certs of this sort:

The All-Windows method:

  1. Using the Certificate Templates tool on the CA machine, make a duplicate of the stock Web Server template, give it a new name, and enable the checkbox that allows export of the private key.  This is a must, since we need to be able to extract the private key from a Windows certificate store later.  Under the Security tab, ensure that domain admins, or another suitably restricted user group, is able to read, write, and enroll this certificate type.  Auto-enrollment is not recommended here.
  2. In the CA management snap-in, add the new template you just created to the list of available templates, and restart the CA so that it will be available for issuance.
  3. Make an .INF file that acts as the template for the certificate request. This process is described here and here, the latter providing an example INF with multiple Subject Alternative Names. Also note that you can delete parts of the sample INF as mentioned in the comments if your CA is set up as an Enterprise CA rather than Standalone, and also assuming you are running on Windows Server 2016 rather than an older version.
  4. Run
    certreq.exe -new yourinf.inf output.req

    This step, critically, creates both the private and public keys that the certificate will use, and creates the signed request which we will next send to the CA to generate as a child of the CA’s root certificate.

  5. Obviously, replace the italicized portion below with the CA server’s network name, and CA_Name with the name visible in the Certificate Authority management snap-in.  If you omit this parameter, you should get a pop-up asking you to select the CA from a list, which also works just as well.
    certreq -submit -config "yourCAserver\CA_name" "output.req" "output.cer"
  6. You should get back a request ID (typically a number), and the message “Certificate retrieved(Issued) Issued” and the files output.cer and output.rsp (response) should have been created in the directory where you ran certreq.
  7. Another critical step: You must run
    certreq -accept output.rsp

    This step installs the certificate (temporarily) in the Local Machine’s “Personal” or “My” certificate store, with the private key. As I discovered the hard way, simply double clicking on the .cer file and attempting to import it or export it only results in the public key being available. In other words, the .cer file can be freely distributed (and will be, by the web server), but we need to have the private key as well in order to be able to use the certificate to decrypt the incoming traffic to the site later.  Running certreq with the -accept command is what causes the private key to be installed in a location where it can then be exported.

  8. Run “mmc” and use Ctrl-M to choose the Certificates snap-in.  At the prompt, select the Local Computer store rather than the user’s store.  Open up the “Personal” folder within the store and select Certificates. You should now be able to locate the newly-generate certificate issued by your CA within the list.  However, we’ve got it on the wrong machine – now we need to put it in a format where we can move it over to the Linux machine.
  9. Highlight the certificate than choose All tasks->Export from the right click menu.  Select “Yes” on the option to export the private key, choose the PFX file type, and select the box to export all extended properties.  Also, select the option to protect the exported certificate with a password, rather than a user/group.  For the filename, just choose a path and filename, but the .PFX will be added automatically.
  10. On completion of the wizard you will now have the cert, including its public key in a .pfx file in the selected directory.  At this point you can delete the certificate from the Certificates snap-in and close it, you won’t need to come back here.
  11. Now you need to have the Windows version of OpenSSL installed.  The latest, at the time of writing, is available here, although you may want to check if a newer version is available.
  12. From the command prompt, change to the location where you extracted the OpenSSL binaries and run the following command to extract the public key from the certificate:
    openssl pkcs12 -in yourcert.pfx -nocerts -out key.pem
  13. You will be asked for the password you created during the export step, and then you will prompted to create another password (twice) to encrypt the key.pem file as it’s created.
  14. Now run one more command:
    openssl rsa -in key.pem -out server.key
  15. You will prompted for the password of the key file, and the final result is the creation of the actual private key in a raw, unprotected format.  Take very good care of this file, and do not send it over unencrypted channels as you transfer it to the linux machine.  Delete it as soon as practical.

If you are using the Linux OpenVPN Access Server, you can now upload your certs and the private key through its admin web interface (Export your domain’s CA certificate from the Trusted Root Authorities of any machine that received it via group policy, or from the CA management snap-in, and also upload the .crt file and the server.key you just created.)  The admin web interface will show you the validation results of your certs and key to ensure that the chaining is correct and that the private key matches the public key provided in the certificate, plus the names of any alternate subject names you may have provided.  After installation, you should now be able to browse the admin interface without errors, and with the lock icons that signal that the https:// connection is using a trusted certificate (assuming that your browser trusts your local domain’s root certificate, which is a manual option in third party browsers like Firefox, and built-in to Microsoft’s browsers like Edge and IE.)

The second technique: Create the cert request on the Linux machine and issue it from the Windows CA.

This is actually the simpler technique overall, and also avoids ever having to transport the private key between a Windows machine where the issuance takes place and the server it’s ultimately used on.

In general, you want to follow the processes documented here.  The .cnf file you create in this process is the equivalent of the Windows .INF file we created in the previous procedure.  The private key is created locally to a .key file, and then a .CSR file is produced with the certificate request.

After creating the CSR, rather self-signing it on the Linux machine (which would still be untrusted by most browsers), you move the .CSR file to the Windows machine, and pick things up at step 5.  Move the .cer and .rsp files back to the Linux machine, and then you can install the .crt, the CA’s .crt, and the private key using the OpenVPN admin scripts per their documentation, or into whatever web server package you may be using.  For OpenVPN AS, specifically, the sudo commands are:

./sacli --key "cs.priv_key" --value_file "private.key" ConfigPut
./sacli --key "cs.cert" --value_file "" ConfigPut
./sacli --key "cs.ca_bundle" --value_file "intermediary_bundle.pem" ConfigPut
./sacli start

You may need to convert your private root CA certificate to PEM format as noted in the OpenVPN documentation, where they suggest some tools that can accomplish that.

I use the term “home” loosely.

My idea of a home network may be a little different from yours – back in 2003, when Microsoft released the first version of Windows Small Business Server, they handed out free CDs and licenses to anyone in the company who wanted one.


About as great an example of Microsoft product naming cliches as has ever existed.

In hindsight, it seems like a bit of a commitment – Server Management has, over the long haul, consumed a lot of hours that probably could have been spent more productively elsewhere.  However, I took the bait. Although the SBS edition is long gone, I’ve been steadily upgrading Windows Server over the years.  As a result, my home network is more like a small business, partially for the added security and control over system maintenance that kind of infrastructure can bring to the table, and also because it’s like “continuing ed” for Microsoft product familiarity. Perhaps most importantly, keeping it all running smoothly is, for me anyway, a slightly sick and twisted Business Simulator videogame.  I have domain controllers, a variety of group policies applied (which was actually a great way to keep my kids from doing really dumb things when they were small), a Remote Desktop gateway for access to home machines from offsite, and an OpenVPN server.

A lot of the roles in an Active Directory Domain will be more robust if you can have additional domain controllers to handle failover duty if the primary goes down.  Some of the typical server roles such as DNS, DHCP, etc, are usually handled by the router/wifi access point you get from your ISP, but once you go the domain route some of these jobs are better served with a more powerful computer and letting Windows Server do the job.  One slightly out-of-date server machine is about all I’m willing to invest in the way of physical computing infrastructure, though, so being able to deploy some of these backup and failover roles in the cloud offers a good opportunity to increase the reliability of the overall system with no additional outlay of space, electricity, or money on my part.

“Free Azure” you say? Well, with certain MSDN account types, you get $150 worth of monthly credit to play around with develop on Azure, which is actually enough to set up quite a bit of low-cost infrastructure. You won’t be running GPU workloads or 8-core virtual machines, but setting up a few low-memory, low-disk single-core virtual machines on a virtual network and keep them backed up for safety can easily be accomplished “for free” with that kind of allowance with change to spare.  However, the main trick is how to seamlessly connect the private home LAN with the Azure machines over the public internet and still maintain the security of your private information.

The answer is nothing new to network administrators:  This is the classic scenario for a site-to-site VPN (virtual private network), frequently used to connect a branch office to the “headquarters network” over the public internet, using an encrypted tunnel. The traffic in transit remains securely encrypted once it leaves the building, while the machines at either end see each other as residing on a (mildly laggy) transparent extension of the local network.

The standard Azure answer to this scenario is to set up an IPSEC/L2TP tunnel using Windows Server at the local end and a “network gateway” at the Azure end. However, setting up the required local server behind a typical home NAT appliance isn’t supported, although I hear it’s possible if you forward the right ports.  However, I didn’t really want to go this route for a different reason:  If the whole point of the exercise is to keep things on the network running smoothly if the onsite server machine (and any VMs it may host) go down, then the VPN would go with it unless it was running on yet another physical machine – which is exactly what I’m trying to avoid needing.  Luckily, my home router runs the third party ASUSWRT “Merlin” Linux firmware, which is powerful enough to run a variety of useful extra features, including both an OpenVPN server (for external connections inbound to my network when I’m not home) and a simultaneous OpenVPN client to connect the tunnel to a corresponding OpenVPN server sitting in my private network in Azure.

For the Azure end, instead of the standard Network Gateway, there is a very convenient alternative: the OpenVPN Access Server appliance that’s available for point-and-click setup in Azure.  It runs quite efficiently on a single core under Ubuntu Xenial Linux with only .75GB of memory and a small disk. Even better, there’s no charge for the software itself if you’re using only one or two simultaneous connections, and in the site-to-site case you’ll only ever be using one. The total cost to run this server in the cloud full time is only a few bucks a month.


The setup is fairly simple and wizard-driven, however afterwards you do need to create the right private subnets and Azure routing tables to direct the traffic from your Azure subnet to the tunnel (and thence to your home LAN), and the reverse is required as well to direct the outbound traffic correctly.  I found a nice article online that was of great help in walking through the process: Dinesh Sharma’s Blog. I followed most but not all of the recommendations, but this article was a big help.  Pinging each machine in the chain to ensure the packets were getting where they were supposed to helped with troubleshooting some early connectivity problems and figuring out where it was getting stuck.  The connection process between the OpenVPN endpoints was quite simple, but getting the traffic to flow turned out to be more difficult.

In truth, getting all the network settings right took me quite a while (needed to keep that “game” mentality I mentioned earlier to keep from defenestrating the laptop at a few points :-).  The main issue that took a while to find was that client-side OpenVPN settings on the ASUS router needed to be mucked with a bit to get the right routing to take place (i.e. “LAN” traffic should go to the VPN address, and “everything else” to the internet gateway, i.e. the router). The setting for this was a little bit buried and not super-well documented.

The highlighted setting here was not the default, nor does “Redirect Internet Traffic” necessarily describe the intent, in my opinion.  After all, it was “local” traffic I was looking to redirect.  Also “Policy Rules” is more than a little vague.  However, once you choose that setting, the rules list pops up below and then you can set up the right rules to say which source/destination networks should be routed via the VPN tunnel.  Any traffic not covered in the list is routed to the internet normally.azvpn3

I got it all sorted out in the end, so now I’m up and running with a backup domain controller/DNS server in the cloud visible full time to all machines on the home network via the OpenVPN server. In the next installment, I’ll talk about setting up a simple public-key infrastructure (PKI) using an Active Directory CA to issue certificates for security and authentication purposes.


Linux setup nightmares

So in that last post, I hinted that getting the user-programmable joystick working properly on Raspberry Pi’s Linux OS was, well, less than ideal.  Here’s just how non-ideal it was:


  1. Download and install tools.
  2. Run tools and play around to your heart’s content.
  3. Walk around with a silly glow on your face.


  1. Linux joystick configuration utility has a link on the manufacturer’s download page.
  2. Tool must be compiled on the Pi’s particular Linux release. (This is pretty common since Linux runs on all kinds of different processors, and this tool is not part of the “standard” OS.)
  3. Tool requires libhid library to compile.  Locate and download libhid library source.  Account must be created on a Debian archive site before download is possible.
  4. Libhid requires libusb and lib-usbcompat libraries to compile.  Locate and download libusb/lib-usbcompat sources.
  5. Libhid needs to be manually patched before it will compile properly.  Locate blog post from other unlucky user who, luckily for me, has already endured and documented all this pain, with the appropriate fixes.
  6. With libraries compiled and installed, now the joystick utility can be compiled.
  7. Discover another recommended manual patch, this one to the joystick utility’s source code, apply patch and compile again.
  8. Running the utility to reconfigure the joystick works successfully, except the joystick is dropped by the Linux kernel’s USB HID driver after reconfiguration, leaving it inoperative.
  9. Follow instructions from previous blogger to create manual scripts to allow manual re-binding of the stick to the HID driver after uploading revised configurations.
  10. Discover that the Linux kernel driver also filters out half of the valid joystick location values with any of the customized configurations.  Anonymous comment on previous blog indicates a line in the kernel HID driver that can be commented out to disable overzealous validation of stick’s output values.
  11. Download entire RPi Raspbian Linux kernel source.
  12. Modify 3 lines of code.
  13. Recompile entire Linux kernel with Adafruit’s virtual-machine kernel-o-matic. (A breath of fresh air, something easy in a tedious process).
  14. Install new kernel and cross fingers.  Luckily, it boots correctly and doesn’t brick the device. (If you’re attempting to reproduce my pain, make sure you choose the branch that matches your existing kernel!)
  15. Validate that joystick now functions properly.
  16. Discover that during some bootups, Joystick is detected as “second” joystick rather than first, causing failure to detect stick in rickety old emulator program.
  17. Research and create “udev rules” which allow particular devices to be forced to have specific names in the OS, so as not to make the rickety old emulator grumpy.

Linux:  It’s the way of the future, you know.

I’m late to the party, but I started building a retro arcade machine using a $35 Raspberry Pi as the computer. The various buttons, joysticks, and other bits of control hardware will likely cost at least 5-6x times that amount by the time the whole thing is done.

I’m doing the Linux setup and prototyping control layouts (more about that tomorrow) but I’m hoping my buddy Raman with the awesome wood shop will help build a real cabinet for it when we’re ready. The thing I want to do that’s different from most of the emulator builds people usually do is that I want the control panel to lift out like a fridge shelf and be replaceable. That way when you want to play a game like Tempest or Centipede that needed a spinner or trackball, you just replace the controls. The rest of the time you can have a typical one or two stick-and-buttons setup, but this way the cabinet doesn’t need to be a mile wide to accommodate all the controls at once.

At the moment, though, it looks more like, well, “3rdWorldCade.” But it works great. Thanks to Amazon for the flexible and sturdy “building materials framework!”



Today I received an antique in the mail.  A rather ancient SCSI CD-ROM drive, in an external enclosure, and an equally crusty 50-pin to DB-25 “Mac style” SCSI cable from  It takes me back to the good old days of somewhere around 1993-1995, when I had boatloads of external hard drives in cases a lot like this one. But the good news: After hooking it up to my Ensoniq keyboard with the SCSI board I described in the last post, success! I can load lots of different sounds from CD-ROMs now.  It’s nice when things work the first time. OK, there was one little glitch – the memory expansion I installed a month or so ago turned out to be faulty.  After loading up sampled sounds I was hearing pops and clicks where I was sure there weren’t supposed to be any.  I was a little panicky at first that somehow the SCSI interface was corrupting the data or there was a noisy signal, but then I remembered that I’d never really tested the sample RAM after installing it.  I popped the factory SIMMs back in and all the noise problems immediately went away.  So it’s just bad memory from eBay. Phew.  Time to go see if I can get the seller to exchange it for a different set.

I needed to add some new storage to my server at home, which I recently upgraded to Windows Server 2012. The chassis has no room for new drives but it had several open PCIe slots, so I thought I’d just add a USB3 controller and a couple of external drives, shouldn’t be too hard?

As with most things PC it’s never as easy as it’s supposed to be. I Newegg’d a controller from SIIG that claimed to have a TI chipset, and a few 2TB external drives from Fantom, who I have a nice ESata drive from already. Things went well until the second day, when I realized that the drives were failing to show up only after warm reboots. If I’d power cycle them after the system was already up, or if it was cold booted, everything would be fine, but warm boot no dice. This was clearly a deal breaker for a largely unattended and remote managed system.

I tried everything. Bios settings, obscure registry flags, nada.

Today I decided to try the cheapest potential fix, a different controller. I made a quick run to the local retail hardware place, and found a Vantec card that did the same thing but with a NEC/Renesas chip. Went home, made the swap, powered up, and……

New problem! Yellow bang on the controller in Device Manager. Seriously? Hit the interwebs… It turns out that there is firmware in the controller chip that’s upgradable and a quick download from some random French website (why doesn’t the manufacturer post this stuff?) and luckily the problem was solved rapidly.

Thankfully, this was the end of the story- the drives now work normally under all conditions. I’ll be RMA’ing the TI controller back to newegg.

Now I have them set up with the new Storage Spaces feature as multiple virtual drives- some mirrored for safety, some striped for speed, and one with the ReFS file system for ultimate reliability. And all thin-provisioned: when the space starts running out, you just add more physical space to the pool and the space seamlessly grows to take advantage of it. Now that’s cool!

%d bloggers like this: