Installing a 1TB Samsung 860 EVO mSATA SSD in a Toshiba Kira-102

A simple job, right? My friend was complaining that their Toshiba Kira-102 kept crashing. The diagnosis was a speedy affair. The ‘as shipped’ 250GB Toshiba SSD had only 200MB remaining on the OS partition and Windows just was not coping with this reality. Windows Update was trying to churn through this free space in an endless cycle of “try and fail”.

The Kira-102 has an older-style mSATA connector. Fortunately, as of February, Samsung had the foresight to continue to support mSATA with the release of the new 860 EVO range. This offers 250 GB , 500 GB and 1000 Gb (1 TB) options in the legacy mSATA format. My friend wanted to go all out on it, so it should have been simple.

If you have arrived here seeking a quick answer to whether or not the 500GB or 1TB mSATA 860 EVO is compatible with the Toshiba KIRA. The answer is yes! Please consider using my Amazon links above if you are looking to buy!


The Process

The method to do this should be tried and tested to any “IT guy” (or Gal).

  1. CloneZilla the original SSD to a SMB share
  2. Swap the 250GB mSATA drive with the 1TB one
  3. CloneZilla the image back from the SMB share onto the new SSD
  4. Boot Windows, resize the partition and hand the device back

It wasn’t.



If you are struggling with any of the same issues. Find a list of issues and (non)resolutions for this machine below.

1. I couldn’t get into the UEFI and the system wouldn’t respond to any of the override key combinations (F2 for setup, F12 for Boot Device Override)

Fix: In Windows Setting, Updates and Recovery, Recovery. Boot into Windows Recovery and follow through on the advanced options until you come across the boot into the UEFI setup option. Once in the UEFI. Disable Intel Fast Boot. The system will now respond to the F2/F12 keyboard shortcuts again.

2. None of my USB Ethernet Dongles allows the presentation of PXE Boot ROM (Network Boot)

Fix: I know that these dongle have OpROM on them. I therefore believe that the Kira-102 doesn’t have UEFI drivers for PXE boot.

3. External USB keyboard wouldn’t work

Fix: In the UEFI enable Legacy USB device support to fix this in everything apart from Windows Setup (where it still would not work).

4. After re-imaging from CloneZilla the 1000GB 860 EVO reported to Windows that it was a 238 GB drive.

Note: This isn’t the partition/volume size, the device itself would only show 238GB. Essentially CloneZilla had mirrored a 250GB SSD onto a 250GB SSD

Samsung Magician showed the SSD drive as functioning correctly, compatible with the system and running as a 1000GB drive with no problems. The firmware was also current. The UEFI did not seem to have any issues seeing the drive – although it has no capacity readout of its size or UEFI shell to root around in. Equally, there was no additional instability.

As a 2015 machine, it certainly shouldn’t be experiencing a software limitation – such as in the aviailable LBA (Logical Block Address) space. Something that historically has limited BIOS system from addressing hard drive space such as with the historic 2GB, 32GB, 146GB and 2TB limits.

Toshiba Service Station reported that there were no updates available for the machine. The BIOS version was 1.40, which reported as current. However, on accidental inspection of the Toshiba support site, I discovered that there was a 2018 revision 1.60 available. The changelog for the release indicates that the 1.50 version contained “improved SSD related system stability” with the 1.60 adding “Enhanced security & Microcode update” i.e. they patched the high profile IMEI exploit from last year and did something to mitigate Spectre/Meltdown.

View: Windows BIOS version 1.60 for KIRA KIRAbook

I patched the BIOS, ever hopeful… to find that nothing had changed in Windows.

Exiting CloneZilla into the shell, allowed me to elevate into the user account and run parted -l. Parted reported partition errors, however after fixing them, running ‘print free‘ didn’t show any free space either.

At this point assuming that there was an artificial hardware limit placed on the storage sub-system, I booted into a Windows 10 install UFD and using diskpart via the command prompt de-initialised the entire disk.

sel disk 0
create part pri
format fs=ntfs quick

Low and behold, the entire 930GB volume appeared in diskpart ‘list part‘.

I clean installed Windows 10 onto the empty drive to confirm this.

There was clearly a software corruption at work. This could be from the amount of crashing that the machine had endured over months of constant crashing. Alternatively, it could very likely be down to Toshiba’s partition schema and OEM imaging process.

5. Recovering the Data from CloneZilla without recovering the entire disk layout

Leaving the test install alone I booted back into CloneZilla. Due the way CloneZilla works, you cannot restore a partition into free space, only overwrite an existing partition. Instead of recovering the disk from image, I used recover partition from image. The intention is to leave the new Windows installation’s boot code, but overwrite its OS data volume with the one from the CloneZilla image.

There were 6 partitions in the repository, none of which had any size data against them. Windows had the main OS partition as the third partition on the drive, however this turned out to be a 138 MB partition of unknown origin (I suspect something hidden in the Toshiba OEM imaging process). Retrying, the large data partition was found in the image at partition 4.

50 minutes later, the partition had restored back onto the 860 EVO. It still showed as being 930 GB in diskpart, but would not boot. Windows blue screened with error code 0xc0000034.

6. Fixing the Boot Code

There was of course no expectation that the system would boot after this process. The system no longer had the correct boot code in place as the OEM install had additional partitions in-situ.

Boot into the Windows Install DVD or Recovery partition. Load the command prompt

Now mount the FAT32 EFI boot partition and repair the boot code.

sel disk 0
list vol

Note the volume number of the 100MB System partition. In my case this was “Volume 2”. If your EFI partition is something other than 2, replace the 2 on the next line with that number.

sel vol 2
assign letter=v

bcdboot C:\Windows /s V: /f UEFI

Reboot the computer


Validation Activities

After going through an ordeal such as this, the question of whether or not it is stable springs to mind. The Windows 10 version was 1803, so after running a chkdsk c: /f and ensuring that the OS volume was now using the entire 930 GB. I upgraded Windows 10 to version 1809. Something that gives the SSD some exercise and would highlight any serious problems.

The Windows 1809 upgrade went through without incident and I was able to write more than 250 GB of data onto the volume, proving that the SSD could correctly function over the 250 GB marker.

Unable to update NuGet or Packages in Powershell due to “WARNING: Unable to download the list of available providers. Check your internet connection.”

When attempting to install or update PowerShell Modules, NuGet or NuGet packages in PowerShell 5. You receive one or more of the following errors

WARNING: Unable to resolve package source ''.

The underlying connection was closed: An unexpected error occurred on a receive.

WARNING: Unable to download the list of available providers. Check your internet connection.

Equally, you may receive the same error when attempting to run a WGET or an Invoke-WebRequest command e.g.


You are unable to install/update the software component or make an outbound internet connection.

This issue may be especially prevalent on IIS installations serving HTTPS websites.

The Fix

Conventional troubleshooting is fairly well documented on-line

  1. Ensure that you are actually able to open a https webpage in a web browser
  2. Ensure that your DNS is working correctly.
  3. Check to see whether wget can connect to a non-https site e.g.
  4. Check to see whether or not you need to use a Proxy server. If so, you must configure PowerShell to use your Proxy Server before you proceed. This may require you to to configure PowerShell with your Proxy Server credentials.
    $webclient=New-Object System.Net.WebClient
    $webclient.Proxy.Credentials = [System.Net.CredentialCache]::DefaultNetworkCredentials

A less obvious issue to explore related to the default operating system security configuration for using SSL.

More Info

By default, Windows Server and Windows client will allow SSL3, TLS 1.0, TLS 1.1 and TLS 1.2. The .net Framework is also configured to allow these protocols, and, by default, any outbound request for a SSL site will attempt to use SSL3/TLS 1.0 as its default protocol.

In secure environments, where system administrators have enabled recommended best practice on Windows systems to disable the use of SSL1, 2,3 and TLS 1.0. PowerShell is not currently clever enough to internally compare its configuration to that of the operating system. consequently, when attempting to make an outbound https request in such an environment. PowerShell will attempt to use one of the older protocols which has been disabled by the operating system’s networking stack. Instead of re-attempting the request using a higher protocol. PowerShell will fail the request with one of the error messages listed at the beginning of the article.

As NuGet and Update-Module both attempt to make connections to Microsoft servers using HTTPS, they too will fail.

Encountering this issue on a SSL enabled IIS install will be more common, as it is more likely that system administrators will have applied best practice and disabled legacy encryption protocols on these servers. their public facing, high visibility should demand such a response.

To fix the issue there are two options:

  1. Reconfigure and reboot the system to re-enable client use of TLS 1.0 (and possibly SSL3) via

    DisabledByDefault = 0
    Enabled = ffffffff (hex)

  2. Alternatively, you must set-up each PowerShell environment so that the script itself knows not to use the legacy protocol versions. This is achieved via the following code which restricted PowerShell to only using TLS 1.1 and TLS 1.2.
    [System.Net.ServicePointManager]::SecurityProtocol = [System.Net.SecurityProtocolType]'Tls11,Tls12'

Create a Slipstreamed Hyper-V Server 2019 installation image with working Remote Desktop for Administration

If you have been following the saga of the non-working Hyper-V Server 2019 release from November. You may be aware that the most prominent issue – that of Remote Desktop Services for Administration not working – has now been resolved in the February 2019 patch release cycle.

This article outlines how to create updated media for Hyper-V Server 2019 using the original installation medium and patch it into a working state.

Note from the author

Please note that if you intend to use Hyper-V Server in a production environment, you should wait for Microsoft to re-issue the office ISO. Once it is released, it will be made available in the Microsoft Server Evaluation Centre.

View: Microsoft Evaluation Centre


You will need access to a Windows 10, Windows Server 2016 or Windows Server 2019 system in order to update the installer.

Obtain and install the Windows ADK 1809 (or later) selecting the Deployment Tools option (providing you with an updated version of DISM)
Download: Windows Assessment & Deployment Kit (ADK)

Retrieve the original Hyper-V Server 2019 ISO
Download: Hyper-V Server 2019 (1809)

Download following updates from the Microsoft Update Catalogue
Note: This is correct as of early March 2019. It is suggested that you apply newer cumulative and servicing updates as they are released in the future.

  1. KB4470788
  2. KB4482887
  3. KB4483452

View: Microsoft Update Catalogue

[Optional] If you wish to apply any language regionalisation (e.g. EN-GB), source the CAB file(s) for the language features that you require. For example:

Updating the Installation Image

To update the installation image:

  1. Create a folder on C:\ called ‘Mount’
  2. Add a second folder on C:\ called ‘hvs’
  3. In the hvs folder, create a subfolder called ‘Updates’
  4. Extract the entire contents of the ISO from the Hyper-V Server 2019 ISO into C:\hvs
  5. Place the three MSU files from the Microsoft Update Catalogue into the C:\hvs\Updates folder
  6. [Optionally] Place the CAB file for the language pack into the C:\hvs folder and for convenience rename it ‘’
  7. Open an elevated Command Prompt
  8. Issue:
    cd /d "C:\Program Files (x86)\Windows Kits\10\Assessment and Deployment Kit\Deployment Tools\amd64"
    To navigate into the working folder for the updated version of DISM.exe
  9. Issue:
    dism.exe /mount-image /ImageFile:"C:\hvs\Sources\install.wim" /Index:1 /MountDir:"C:\Mount"
    To unpack the installation image into the C:\Mount folder
    Note: Do not navigate into this folder with CMD, PowerShell or Windows Explorer. If you leave a handle open against this folder when you try to re-pack the install.wim, it will fail.
  10. Once the mounting is complete, patch the installation by issuing:
    dism.exe /Image:"C:\Mount" /Add-Package /PackagePath:"C:\hvs\Updates"
  11. [Optional] Apply the language pack by issuing (change en-GB to your language as applicable):
    dism.exe /Image:"C:\Mount" /ScratchDir:"C:\Windows\Temp" /Add-Package /PackagePath:"C:\hvs\"
    dism.exe /Image:"C:\Mount" /Set-SKUIntlDefaults:en-GB
    If you intend to use ImageX, DISM or WDS to deploy this image, you can skip the following command. If you intend to create a new bootable ISO or UFD, issue:
    dism.exe /image:"C:\Mount" /gen-langini /distribution:"C:\hvs"
    This will create a new Lang.ini file which must be included in the ISO/UFD media (but is not required for other deployment methods)
  12. Dismount and re-package the install.wim file by issuing:
    dism.exe /unmount-image /MountDir:"C:\Mount" /Commit
  13. Once DISM has processed the installation image, the new Install.wim file can be found at:
  14. At this point you will have a working installation image which you can use to create a new ISO, UFD or install via WDS. You should delete the Updates folder and [optional] from C:\hvs before creating a new ISO or bootable UFD.

If it goes wrong at any point, issue the following command to abort the process and go back and try again:
dism.exe /unmount-image /MountDir:"C:\Mount" /Discard

Delete the C:\Mount and C:\hvs folders once you have finished creating you new deployment media.

Final Word

If you follow the above, you will have not only a fixed RDP experience, but also a current patched version of Hyper-V Server. Eliminating a little time spent waiting for Windows Update to run.

If you are going to enable RDP for Administration. As ever, do not forget to enable the firewall rule in PowerShell. SConfig.cmd does not do this for you!

Enable-NetFirewallRule -DisplayGroup "Remote Desktop"

Where is Hyper-V Server 2019? Remote Desktop for Administration Bug & ISO Download Update

*Update* 6th March 2019. For a workaround to create your own fixed Hyper-V Server 2019 installation media, see Create a Slipstreamed Hyper-V Server 2019 installation image with working Remote Desktop for Administration

The release of the Windows Server 2019 family has not gone well for Microsoft. Hitting RTM in September 2018 (1809), the release became available through the different distribution channels (VL, MPN, Visual Studio) from late October 2018. It was promptly pulled from the public domain and re-packaged.


With Windows Server 2019, Microsoft chose to skip the RTM phase and sent the code directly to General Availability (GA). The mainstream Windows Server 1809 branch was blighted – a not necessarily fairly – by a widely publicised data-loss bug. Under some circumstances, Known Folder Redirects under upgrade installs of Windows 10 1809 would erase theĀ  contents of the target. As a precautionary measure, Microsoft withdrew Windows Server 2019 due to it sharing the same code base as Windows 10. Reissuing it, and Windows 10 with fixes on 13th November 2018.

Despite this, there have been a spate of other reported issues in the Windows Server 2019 release. Examples include

Microsoft were vocally chided by the user community for taking until 17th January 2019 to restore the evaluation ISO for the regular release of Windows Server 2019. As well as for failing to comment on the situation with Hyper-V Server 2019. This irked many IT professionals as they lost the Christmas testing period. Interfering with opportunities for initial product evaluation ahead of the New Year. The delay will cause a deferral of adoption in many organisations; being especially true for Exchange Server 2019, which requires Windows Server 2019 as a pre-requisite.

Unlike the Windows Server 2019 evaluation ISO, the Hyper-V Server 2019 did not return and to date (2nd March 2019) it remains unavailable.


Hyper-V Server 2019 1809

As with the full version of Windows Server 2019. Hyper-V Server 2019 was only released for a matter of days before its withdrawal.

ISO: 17763.1.180914-1434.rs5_release_SERVERHYPERCORE_OEM_x64FRE_en-us.iso
SHA1: 04B40E7E2FD14C964086C214D6409795908F6887

The availability of the ISO was fleeting for several key reasons.

  1. Hyper-V Server 2019’s shared codebase means that it is impacted by the redirected folders bug. However as a rule, you should not be upgrade installing Hyper-V Server. See my article on upgrade installing Hyper-V Server for reasons why this is not advised.
  2. Remote Desktop for Administration does not work at all in the release [1] [2]. This has been resolved via KB4482887 from 2019-02 Patch Tuesday.
    NB: Don’t forget to enable the firewall rule:
    Enable-NetFirewallRule -DisplayGroup "Remote Desktop"
  3. sconfig.cmd no-longer loads automatically after joining a domain (this is true on 2019 Server Core also).
  4. When installed in Hyper-V, the Virtual Machine Connection display fails to draw correctly, leading to frequent display corruption.


Windows Server 2019 has had a rough start. Many commentators are expressing concerns that Microsoft does not yet possess the experience to successfully navigate the SaaS landscape with Windows. Observationally, QA has been in decline at Microsoft for some years, but up until now we have not seen such deficits impact the mainstream Server ecosystem.

With Microsoft posting a resolution to the Remote Desktop for Administration issue via KB4482887. It is logical that Microsoft will seek to re-release Hyper-V Server 2019 in coming days and weeks. Microsoft for their part have made no comment on the issues with Hyper-V Server 2019, or any planning for its re-release. So this remains speculation, but the community may see it under a 1903 re-packaging hopefully as early as next week.

In the interim, you should continue to avoid using the original release ISO in your test labs.

View: Microsoft Evaluation Centre