I owe a lot to this little, £130, underpowered (even at the time) machine. Sat in my car refining and sending off my CV for numerous jobs whilst waiting for my hateful call centre job to begin helped me break into a technical role.

The end of Windows 10 support in October 2025 could be considered a full stop on this laptop’s usefulness, however Windows claimed this as a victim long ago. The 32GB eMMC storage was entirely consumed by just the operating system and its pending updates, which relegated this system to version 18.09.

One point of the X205TA that really impressed was the battery life, with an OS estimated 10 hours at full charge it was something 2016 me had never seen before.

The thought occurred that I’d like a lounge terminal, something with a proper keyboard and screen that I could use to SSH into other machines, with a web browser for reference.

Could I breathe new life into the X205TA with the introduction of a Linux Desktop?

Specifications

All that is required is a terminal and a web browser.

This could be achieved with a simple window manager but due to the laptop’s svelte specs (Intel Atom Z3735F, 2GB RAM, 32GB eMMC storage), I don’t think a barebones setup is going to give much of a performance boost.

Debian is my preference, naturally the system will be built on this. Luckily, and something that needs consideration these days, is this is a 32-bit processor.

Secure boot, enabled by default, will need to be disabled in BIOS in order to install a Linux system.

Desktop Environments

Debian’s wiki has a page for the X205TA , but the referenced kernel versions suggest this may not be the most up to date.

Attempting a fully fledged environment in the first instance…

KDE Plasma

For this I opted for a minimal install of Debian 12, followed by a minimal install of KDE Plasma on first login:

apt install kde-plasma-desktop plasma-nm

This give the KDE desktop, with a couple of issues. Firstly and immediately obvious, despite WiFi working for the net-install ISO and on first boot, post KDE install the WiFi would not connect to my network.

This was resolved by commenting out ALL of the /etc/network/interfaces file, then, through the GUI, forcing the wireless to connect over 2.4Ghz to my SSID that is active of both 2.4 and 5Ghz.

Following this, audio was not detected, not a dealbreaker but something worth noting.

The touchpad controls (tap to click) though not enabled, was easily configured. However, its was quite sluggish, with RAM at 1.4GB at idle, and a browser (Firefox or Chromium) exacerbated this.

Next was a renowned lightweight desktop…

LXDE

Similar to KDE, install via a net-install ISO went seamlessly, but on first boot to the desktop no signs of WiFi or networking was to be seen.

This could of prompted a troubleshooting session, but the lack of touchpad customisation was to be a dealbreaker.

On to the next…

XFCE

Like LXDE, this has the same goal of being a lightweight desktop, but seems to be under more active and continuous development.

Installation was via the same net-install ISO, but on first boot, everything just worked!

With all installation, Debian advised that propriety firmware was recommended prior to installation, yet I’m not seeing any detriment to skipping this step.

RAM usage at idle sits at ~800MB, yet I feel offers the same customisation offered in KDE at 1.4GB, especially with tap to click on the trackpad.

With this level of simplicity of install, XFCE is the one for me.

Summary

Also offered with XFCE are the same comforts of a modern UI, such battery life status and estimates. It’s amazing that this cheap is still able to offer 9 hours of battery life at 10 years old, this was after a charge cycle and booting the system off-grid.

It’s over optimistic to think that this could be a serious workhorse, now or even back then. But to have a simple terminal machine to hand when lounging on the sofa as a more convenient option to a frustrating mobile experience still gives this little cheap laptop some value.

So why not, nearly 16 years after the show started, try and get one of these working on an Asterisk PBX? At work we had a number of similar 7940 models that hadn’t be used for years, so why not give it a try…

History

When the show started in 2005, these phones would need an entire Cisco ecosystem to support it, as it was essentially locked to Cisco’s propriety SCCP system. It was later and when the models were approaching end of life that a firmware update allowed it to communicate over SIP, therefore making it compatible with many more systems.

Before going further, I should note that I the telephony world, these things are ancient and have fallen way behind the capability that modern phones can offer. I would recommend these as a novelty and not be considered for deployment as it requires a lot of manual setup for little return, as we’ll go into….

Requirements

PBX: SIP based, for this example I’ll be using FreePBX, based on Asterisk.

Firmware: Dependent on what’s already loaded on the phone, you may need to source the P0S3-8-12-00 firmware that enables SIP. It can still be found with enough searching online.

TFTP Server: The 7940 can only be configured via TFTP and cannot be setup manually on the phone, so this is essential. In this example I’ll be using Windows Server 2019 and repurposing the TFTP element of Windows Deployment Services.

DHCP Options: The phones are pointed to the TFTP server via DHCP Options, a router or DHCP server capable of these is required. I’ll be setting this up on a Draytek 2862.

HTTP Server: Should you wish to add Services and a Directory, the phone pulls this information via HTTP.

Setup

TFTP Server

In Windows Server 2019, open Server Manager and start the Add Roles and Features Wizard.

In Server Roles, tick Windows Deployment Services

Then in Role Services, select just Transport Server to enable TFTP.

By default, Windows uses TFTP exclusively to deploy Windows images on client machines, so we’ll need to make a registry edit to allow the server to provide all files.

Open RegEdit, and navigate to:

Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WDSServer\Providers\WDSTFTP

TFTP files are served from C:\RemoteInstall by default, this can be changed by editing RootFolder value.

Edit ReadFilter value to add \* to allow all files to be read in the root folder.

To re load these changes, restart Windows Deployment Services Server from the Services folder.

DHCP Options

To allow the phone to know where the TFTP server is on boot, DHCP Option 150 is used to direct the phone.

Logged into the Draytek 2862, navigate to LAN –> General Setup –> DHCP Server Option button.

Enter Option Number 150, and enter the server IP address in the Data field:

To check its working, plug the phone into the network, after initial loading it will start looking for files at the server’s IP address.

Config Files

All of the phone’s functionality is provided by the config files. As a minimum the phone requires the following for use with SIP:

SIPDefault.cnf – Common configuration for all phones on the network, containing info such as SIP server.

SIP<MAC Address>.cnf – Phone’s individual config, such as extension registration info. File is named SIP001D45000000.cnf where 001D45000000 is the MAC address of the phone.

If your phone is loaded with SCCP firmware, for instance if it was pulled from a Cisco infrastructure environment, the phone will attempt to pull a different set of files from the TFTP server.

To identify SCCP firmware, when loading the top black bar will lack the “SIP” logo on the right.

If it is the older firmware, additional files are needed to instruct the phone to update its firmware:

XMLDefault.cnf.xml – First file served, specifies the firmware to load.

OS79XX.TXT – An alternative firmware pointer file.

Then you will need the firmware files, for reference / search purposes, these are the files needed:

P0S3-8-12-00.loads
P0S3-8-12-00.sb2
P0S3-8-12-00.tar
P0S3-8-12-00.bin
P0S3-8-12-00.sbin

Factory Reset

If the phone already loads and gives an extension, it will need to be factory reset:

With the phone unpowered, hold the # key. While holding, connect power to the phone and release the # key when the Headset, Mute and Speaker buttons start lighting in sequence.

Next whiles lights are still in sequence, press 123456789*0#.

When reset menu appears, press 2 to say no to keep network settings.

Phone will reboot and is ready to provision.

Provisioning

DHCP Option, TFTP Server, files in place, the phone can now be provisioned.

Dependant on firmware level it will take up to 5mins to upgrade and provision, during which and if all goes well will get some comforting references to the files served by the TFTP server.

You now have a Dunder Mifflin issued extension.

I thought my established home setup was great, however I didn’t envisage words like Teams and Zoom to become the buzzwords of companies the world over.

This posed an issue for myself. Even though my 2017 Dell XPS has a webcam ready to go, it spends its home office days docked with the lid closed. When opening the 4K screen combined with the Full HD monitors, Windows implementation of scaling rears is appalling head and just looks terrible. Combined with the Dell’s decision to locate the webcam below the screen to give maximum nostril-cam angle, its not something I like to use.

Buying a USB webcam didn’t seem worth it for what is (hopefully at time of writing) a temporary solution.

So in comes another Pi project, this time using a spare Raspberry Pi Camera module connected to an aptly placed Pi, that can be used on a Windows machine for the software likes of Zoom, Skype and Teams…

Pi Setup

Enable Camera

Using a fresh install of Raspbian Buster, locate and login to SSH of the Pi and run the configuration utility:

sudo raspi-config

In the menu, navigate to 5. Interfacing Options, then P1 Camera, and enable.

Navigate back to the main menu and Enter on Finish, select Yes if prompted to reboot.

Set Static IP

The camera will be accessed over the network, so makes life easier and more reliable for it to always be found on the network in the same location. In an SSH session, enter:

sudo nano /etc/dhcpcd.conf

Scroll to the bottom of the page and enter the following:

static ip_address={IP ADDRESS}/24
static routers={ROUTER ADDRESS}
static domain_name_servers={ROUTER ADDRESS}

Install Software

The software I’d prefer for this task is MJPEG Streamer, a lightweight camera image generator that has come to my aid when setting up a CCTV system.

Start with installing the dependencies:

sudo apt-get install build-essential imagemagick libv4l-dev
libjpeg-dev cmake

Download the MJPEG Streamer files from git:

git clone https://github.com/jacksonliam/mjpg-streamer.git

Navigate the folder in order to compile:

cd mjpg-streamer/mjpg-streamer-experimental

Then compile:

make

No errors? Go and install it:

sudo make install

This will install the program, and leave you at the command line with little fanfare…

Testing

Sanity check, and time to see if the software will work, from the command line run the following:

/usr/local/bin/mjpg_streamer -i "input_uvc.so -r
1280x720 -d /dev/video0 -f 30" -o "output_http.so -p 8080 -w
/usr/local/share/mjpg-streamer/www"

These are the common variables should you need to adjust anything to get started:

-r 1280x720 – Set stream output resolution
-f 30 – Framerate
-p 8080 – Port the stream binds to

From another PC, open a browser and navigate to http://{IP ADDRESS}:8080/?action=stream where {IP ADDRESS} is that of the Raspberry Pi.

Launch at Startup

You may notice when testing the above test command that it occupies the command line whilst running, and doesn’t allow any other tasks, exiting the program by using Ctrl + C also stops the video stream.

Therefore its more convenient to have the camera stream start when the Pi starts, and have it run unhindered in the background to give easy access to the Windows machine.

Script File

Before it can start automatically, the command needs to be wrapped in a script file and executed:

Open a new text file with nano, located in the Pi (Default user) home directory:

sudo nano /home/pi/camstart.sh

Paste the command tested above into the file, then save and exit with Ctrl+O and Ctrl+X

This file needs to be executed, so give it execute permissions:

sudo Chmod +x /home/pi/camstart.sh

Script made, it needs to be run at boot, this can be done with cron:

sudo crontab -e

Enter the following on a new line at the bottom of the file:

@reboot /home/pi/camstart.sh

Use Ctrl+O and Ctrl+X to save and exit.

Now to see if it worked, restart the Pi gracefully with:

sudo shutdown -r now

When it re-appears, visit http://{IP ADDRESS}:8080/?action=stream again and see if you have a live stream.

Windows Setup

Now the camera is setup and broadcasting the image over the local network, we need something on the windows machine to capture and convert it and make it recognisable by video conferencing software.

There are a number of applications that can achieve this, but often it is an addon to a much larger software suite and would be considered to be bloatware to what we want to achieve.

Cue IP Camera Adapter 3.1 https://ip-webcam.appspot.com/ as a lightweight application that has just does the conversion process and nothing else.

Run the setup wizard and upon installation, run the “Configure IP Camera Adapter” from the start menu:

Enter http://{IP ADDRESS}:8080/?action=stream into the URL field.

And test the link by pressing Autodetect, the message with tell you if it was successful:

Final Testing

From here the camera should be available on most video software, you will just have to update it to use the newly added camera, this will be labelled as MJPEG Camera:

Not knowing at the time, and thinking it was a one off, formatted the hard drive and completed the whole setup again. A day passed before the virus was back. Now with the knowledge of what was happening and wary of it happening again. I rebuilt the server and this time put the website behind port 8080, this time the virus never returned.

I thought to myself that this was security through obscurity, and with the victory over Code Red, was something I held onto for many years.

I applied this method when it came to opening RDP access to the outside world, choosing a seemingly obscure port 8021 on each network setup. However, I’ve been dealt a wakeup call following what I’ve just seen…

In my small flat I have the advantage / disadvantage dependant on opinion of having my network switch located below my TV in the living room, allowing me to glance at network activity quite easily. Paying attention, the port to the server and router uplink had been constantly transferring data, this is not unusual as the is a webserver on it and with all WordPress based websites has many an attack attempts each day.

What was different the last few days is that the transfer was constant, instead of an organic flashing pattern, where you can almost visualise each web request and response, it was a steady stream, and lasted well beyond the reason of any process I could think of.

Curiosity overwhelming me, I remoted on to the server and looked at the network tab of the resource monitor, only to be greeted by this:

Around 50 unknown address all connecting to terminal services. After the initial shock I read more into and based on the network throughput of each IP compared to my active RDP connection (Here is 192.168.1.17) believe they were still at the brute force stage of logging in.

Looking further this looked to be more of a botnet of compromised machines, as hostnames comprise of generic consumer connections, Amazon EC2 and even a mail server.

The forwarding port on the router was quickly closed and the connections soon reduced

This is my self-lesson, security by obscurity is no longer an option. With exponentially more bandwidth and processing power available to the world, not to mention the amount of devices online compared to my beginnings in 2001, you can hide, but they will find you.

My method is to use VMware Standalone Convertor Wizard to convert physical machines to an ESXI 6.5 host. All previous conversions have been seamless however the latest conversion of a Fujitsu U904 laptop didn’t go as so, the conversion process completed without a hitch, but when starting the newly created VM I found that keyboard input was unresponsive.

ESXI 6.5 has a mainly web only administration console, with the ability to console via the VMware Remote Console program. However, keyboard input was unavailable via this along with experimenting on the web console with other browsers, with Chrome being the default choice.

Luckily this has been discovered before but is not widely documented, and the issue seems to be with Fujitsu’s use of the Synaptics drivers that provides Windows with the access to the keyboard and its extra features via the function keys. This is how to get the VM machine with a working keyboard.

For those lucky enough to be migrating a Windows 10 install, use the on-screen keyboard in the accessibility menu to log in to Windows.

Open a File Explorer window, right click on This PC and click Manage.

Choose Device Manager on the left and pane. Then in the right-hand pane, right click in a void space and click Show Hidden Devices.

Expand the Keyboards section and delete each entry.

Next open the Registry Editor by opening the Start menu and typing regedit.exe

Navigate to and select HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Class\{4D36E96B-E325-11CE-BFC1-08002BE10318}

On the right-hand pane, double click the UpperFilters entry.

In remove all lines of text except kbdclass, click OK, close regedit and restart the virtual machine.

After the reboot you should have regained control on the keyboard.

Source: https://communities.vmware.com/thread/448048?start=0&tstart=0

Update

Another quirk found with this virtualisation is that I could not initially set the display to 1920×1080 resolution.

When using the Standalone Convertor, the graphics settings for the VM are set by default to Automatically Detect, however by the time it reached the host the Video Memory (VRAM) was set to 4MB, not enough to power a full HD display.

In ESXI, shut down the virtual machine and click edit the settings, expand the Video Card section and change the Total Video Memory entry from 4 to 16MB. On the next boot the full HD resolution will be available.

On first inspection it was indeed booting to the recovery console, and displaying recovery choices including 4 restore points. These were the first port of call but were all unsuccessful. This machine has been in use by the user for many years, and so had many years of settings and obscure software installed, so there was a lot to gain from repairing the issue instead of a full Windows re-install.

A corrupt Windows install could be the result of a failing hard drive, S.M.A.R.T reporting on boot was giving a pass, so it may be worth rebuilding the Master Boot Record.

Repairing the MBR

So how to work on an operating system that refuses to load? The recovery DVD (Remember them) that came with this aging Fujitsu contains a heavily stripped down version of the Windows 7 operating system, giving you the basic tools to make changes to the system stored on the hard drive.

Boot the PC from the DVD and you are greeted with the Windows 7 installation menu, click Repair Your Computer to load the recovery console.

Select the OS on the drive, and click Next

This will attempt to repair the PC again, and ultimately fail, next it will show you the System Recovery Options

Click to open Command Prompt. In this window we can execute the commands to rebuild the MBR:

1. bootrec /rebuildbcd
2. bootrec /fixmbr
3. bootrec /fixboot

Restart the PC from the main menu and cross your fingers.

Looking Further

Unfortunately, this did not fix the issue, and it loaded the Startup Repair again. Looking deeper into the details of the failed repair, I find this:

What stands of here is the word Rapport, this may refer to a piece of security software by the same name. Whereas I don’t use this software, I am familiar with this due to the well documented problems it causes many users, and have dealt with these many times.

As it is a 3^rd party program to Windows, it’s likely that this is installed as a system service and set to start on boot. The next step is to disable this service, and get Windows to start.

Disabling a Service

As above, get the PC to boot from the Recovery DVD, and navigate to the System Recovery Options, and open the DOS window.

Enter regedit to load the registry editor

As the PC has booted from the DVD, the registry details displayed refer to the operating system loaded from the DVD, so we need to connect to the registry of the system’s hard drive.

Highlight HKEY_LOCAL_MACHINE on the left hand tree.

Click File on the menu bar and then Load Hive

Navigate to C:\Windows\System32\Config on the hard drive (Note the drive letter may be different from normal operation) and choose the SYSTEM file.

Give this registry an identifiable name, and click OK

In this tree, navigate to the Services folder at HKLM\SYSTEM\CurrentControlSet\Services

In this folder, each subsequent folder refers to a system installed on the system, in this example I looked for anything that relates to the Rapport software.

Navigate to the folder of a service, then double click the Start entry

The way the service starts depends on the following number in this field:

• 0 – Boot
• 1 – System
• 2 – Automatic
• 3 – Manual
• 4 – Disabled

Change the Value Data to 4, and click OK

Repeat this for every service you wish to disable,

When done with the registry, navigate to the identifiable name you give earlier, right click it and choose Unload Hive

Close regedit, then restart the PC from the min Recovery menu, another cross of the fingers will also help.

Windows Recovered

For me this was a success and a great relief.

The whole process took a lot of time to diagnose and resolve, but only a fraction of the time compared to a full system rebuild, restoring the software and files from its last known state, and not to mention the ongoing support to the user in re-creating the configuration they were originally happy with.

One remnant of its hard life was the temperamental touchpad, that would work on a level flat surface but moving it to a lap or similar and the “pinch to zoom” would kick in when trying to move the mouse.

Usual troubleshooting commenced with the latest drivers being installed, as this issue co-incised with a fresh install of Windows 10. Suspecting a grounding issue of the capacitive touchpad, off came the underside cover and checked to see any missing covers/captain tape that could have caused a short, without success.

A final look at the drivers and it was where I stumbled on the issue. Using the pressure sensor and mood pad applications that came with the drivers, I could see what the trackpad was registering:

The pressure graph indicated it could sense a touch even when the pad was left alone, with the mood pad showing pressed along the far-right hand side. This meant the touchpad was touching the aluminium laptop chassis in this area. Time to open it back up and take a closer look.

The U904 internals are very accessible for modern standards, 8 screws and the entire base lifts off, from there a plug and two screws release the battery allow access to the touchpad.

Loosening the two screws holding the touchpad revealed there was a bit of lateral play in the eyelets holding it to the chassis, so moving the touchpad to left before tightening to secure it creates a larger gap on the problem side and less chance of a short.

Put back together and tested, the issue is resolved! It could be due to the age and use that the right-hand side developed that fault, it’s possible that an insulating coating on the chassis had worn away allowing the connection. Plus, I surmised that sitting knees folding, laptop on top and resting my hands on the keyboard would cause the unit to bow in the middle, essentially folding the chassis into the trackpad.

Back in its prime, I still couldn’t avoid the “pinch to zoom” activating while using the two-finger scroll at times. So saving a lot of frustration, it was turned off in the touchpad drivers.

From the experiences I’ve had with this error there have been a few constants. All machines are running Windows 7 Pro 64bit with Office 2013 or later installed. Also a factor is the use of Konica Minolta Bizhub printers as the default device but after research this is less of a contributing factor.

Troubleshooting

Normally when getting a call about this, it’s down to there being unsaved work in peril from being lost as a result of the Not Responding message. Luckily with this issue the program can be resurrected in order to save work.

Open up task manager and look in Processes for WOWspl64, right click and choose End Task. Now the office application will spring back into life, to allow saving of the file and a happier user.

Restarting the Print Spooler service will reload the program and the issue will go away, only to return later.

The Issue

The actual problem related to print drivers, WOWspl64 is the middle man that gets caught up in the crossfire. The real issue is seemingly down to the use of PCL 6 printer drivers that do not sit well with the Windows & Office combination. Finding this issue is compounded in the case if the Bizhub printers by the drivers labelling as being just PCL.

Solution

Microsoft has identified and issued a fix for this, however this did not work for me. A more permanent solution is to downgrade to PCL 5 drivers, this so far has resolved this issue and retained the functionality for the user.

For Konica Minolta printers, the driver download pages have options to choose PCL 5 and the installer is easy to run and configure, with a new printer appearing in the Devices and Printers page. Just remember to delete to PCL6 associated printer to stop this issue repeating in the future.

Despair set in after investing a whole £3 on a dedicated set of headphones that turned out to exhibit the same issue. This narrowed it down to 2 main issues, hardware or drivers.

I found a hardware issue hard to justify, as audio through the working channel was fine, and considering how integrated a sound card is on a modern motherboard these days sound would be all or nothing. Moving on to drivers, the simple trouble shooting was fine, with the balance centred on both the Realtek software and the Windows sound manager.

Getting frustrated I methodically went through every obscure setting on the Realtek manager, choosing that as its usually undeveloped manufacturer software rather than the OS at fault. Then finally I found it:

My machine is updated with the latest Realtek drivers installed including the Audio device manager. This can be accessed from the notification icon or by plugging a peripheral into an audio jack.

On the Realtek Device Manger, click advanced settings.

Under Playback Device, simply click “Make front and rear output devices playback two different audio streams simultaneously.”

And it’s fixed! Any audio currently playing may need to be restarted, but now I can get both channels through my headphones.

“There is not enough disk space to create the volume shadow copy on the storage location. Make sure that, for all volumes to be backed up, the minimum required disk space for shadow copy creation is available. This applies to both the backup storage destination and the volumes included in the backup.

Minimum Requirement: For volumes less than 500 megabytes, the minimum is 50 megabytes of free space. For volumes more than 500 megabytes, the minimum is 320 megabytes of free space.

Recommended: At least 1 gigabyte of free disk space on each volume if volume size is more than 1 gigabyte.

Detailed error: Insufficient storage available to create either the shadow copy storage file or other shadow copy data.”

This doesn’t really explain the issue, as setting up a schedule with Windows Server Backup in 2012 involves the utility checking available storage before creating the backup task, and a manual check showed there was ample storage on the destination volume, with the source volume having 86% free space.

Delving into the Event Viewer for more detailed error message, I get this:

“The backup operation that started at ‘‎2016‎-‎12‎-‎09T06:00:14.502000000Z’ has failed because the Volume Shadow Copy Service operation to create a shadow copy of the volumes being backed up failed with following error code ‘0x80780119’. Please review the event details for a solution, and then rerun the backup operation once the issue is resolved.”

The internet has a lot of theories and solutions, with the most common workaround being disabling security to perform a backup. This can be incorporated into a batch file and triggered by task scheduler, but its fiddly and leaves the system open while backups take place, lucky I discovered a simpler and more secure solution.

It seems the error is being generated due to Volume Shadow Copy service (VSS) being assigned a drive volume that does not have enough free space, on a default install of Server 2012, that volume is the System Reserved partition.

To complicate matters, the Disk Management utility does not report the amount of free space.

To find out, open a PowerShell window and enter Get-Volumes to see the below:

Here the Recovery partition only has 30MB of free space, below the required amount specified in the original error message.

To fix, go to the drive properties in My PC, and choose the Shadow Copy tab, then in the Select Volume box, choose a volume that has enough free space, in this example the C drive.

Once applied, the backup will complete: