Disabling the beep/buzzer alerts on a Zanussi Lindo1000 Washing Machine

C:Amie/ / Hardware

Washing machines. Specifically in my case the ZWD81663NW by Zanussi.

If you are a fellow owner. You will know that everything associated with it has to be followed by a painfully shrill response from a piezo buzzer. The din is annoying enough during the day, but anyone making use of economy seven has to have the delight of it announcing itself at the top of its lungs in the small hours of the morning. It’s shrill, deftly cries calling out in the middle of the night, with all the decorum of a rabid blood hound incensed by the light of the full moon.

Disabling the Buzzer

I am sure that someone will likely point out that if I had bothered to look in the manual,I would have found it in black and white. I am however in IT. We do not do that.

I was moments away from attacking it with a screw driver, but decided to randomly splurge buttons to see if there was a ‘secret’ combination to get it to do what I wanted.

It turns out that there is.

  1. Turn the machine programme dial to any on setting (e.g. onto ‘Cotton‘)
  2. Simultaneously hold down the ‘AutoDry‘ and ‘Extra Rinse‘  buttons for 3 seconds. The machine will make a semi-depressed low pitch beep and fall silent.
  3. Turn the programme dial back to ‘off‘

Photo of the Zanussi Control Panel

The piezo buzzer is now disabled. This disables both the programme completion alarm and the auditory responses to the pressing of buttons.

If you wish to re-enable the buzzer, simply repeat the process.

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

C:Amie/ / Hardware

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.

 

Problems

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.

diskpart
sel disk 0
clean
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.

diskpart
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
exit

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

C:Amie/ / IIS, Microsoft, Programming, Software

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 'https://www.powershellgallery.com/api/v2/'.

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.

wget https://www.google.com/

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.
    wget http://www.google.com/
  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
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\<protocol>\Client

    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

C:Amie/ / Hyper-V, Microsoft, Windows Deployment, Windows Server

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

Pre-requisites

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:
Microsoft-Windows-Server-LanguagePack-Package~31bf3856ad364e35~amd64~en-GB~10.0.17763.1.cab

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 ‘lp.cab’
  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\lp.cab"
    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:
    C:\hvs\Sources\install.wim
  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] lp.cab 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"