Surface Pro 3 Type Cover Not Working After Windows 10 1903 Image Applied

Symptoms:

  • Following imaging with Windows 10 1903 using Configuration Manager OSD, the Type Cover doesn’t work at all (keyboard, trackpad).
  • When rebooting the machine, the keyboard and trackpad both work when in the BIOS.
  • When imaging the machine, both the keyboard and trackpad work in Windows PE.

The Surface Pro 3 was imaged and then patched up-to-date and the most recent Surface Pro 3 drivers available from Microsoft were applied, however the issue persisted.

To correct this issue, complete the following steps:

  1. Open Control Panel and navigate to ‘Hardware and Sound’ and then ‘Devices and Printers’.
  2. Select the Surface Type Cover and open the properties for this device. Select the ‘Hardware’ tab on the dialog:
    Surface Pro 3 Type Cover properties
  3. In turn, select each of the device functions shown in the list and click the ‘Properties’ button:
    Surface Pro 3 Type Cover devie function properties
  4. Click the ‘Change Settings’ button, then from the dialog that is shown select ‘Uninstall Device’. If offered the option to delete the driver software for this device, ensure that the checkbox to do so is selected (not all devices offer this option) and click ‘Uninstall’:
    Surface Pro 3 Type Cover uninstall device including driver
  5. Ensure this has been completed for all device functions shown in the list, then close the main properties dialog.
  6. Open the Device Manager for the computer, right-click the computer name at the top and select ‘Scan for Hardware Changes’.
  7. Expand the firmware section within Device Manager. For each of the items shown, right click the item and select ‘Update Driver’. Click ‘Search automatically for updated driver software’ from the dialog that is shown:
    Surface Pro 3 Type Cover update dirmware
    Note that if you’ve installed the latest Surface Pro 3 drivers, none of the firmware items shown are likely to be updated, but attempt to update each item. If you’ve not installed the latest drivers, the firmware list may have more generic titles which will be updated as the appropriate firmware is applied.
  8. Repeat the process of updating the driver for each item under the Keyboards section of the Device Manager. Note that even with the most recent driver pack installed, all of these entries on the device I was working on were the generic ‘HID Keyboard Device’. We don’t know which one of the keyboard devices listed is the Type Cover, however when you get to the correct one you’ll that the driver that is installed is listed as ‘Surface Type Cover Filter Device’:
    Surface Pro 3 Type Cover driver updated
  9. As soon as this driver is installed, the Type Cover should start working again. In my case no reboot was required.

SCCM OSD on Surface Pro 6

Today we attempted to re-image Rik’s new Surface Pro 6 using the usual set of task sequences that we have configured for all of the PCs that are in use, and hit an issue.

The task sequence failed (very quickly) with error 0x80070490. Looking at what was going on onscreen, it was obvious that the partitioning of the disk within the device was failing.

Initially I assumed that it was driver related and so pulled down the Surface Pro 6 driver pack from Microsoft, added it to SCCM and updated the boot media to include appropriate drivers. This didn’t solve the issue however.

Looking at the disk configuration, it became apparent that the disk number associated with the SSD within the Pro 6 was not the ‘0’ that I expected, but ‘2’ instead! It appears, following some reading that the ‘disk’ in this device, which is a 1TB drive, is actually two SSDs configured as a RAID 0 set, hence the disk number being ‘2’.

Copying the task sequence that Rik wanted to use to deploy the OS and software to the device allowed us to modify the disk number that would be used to ‘2’, which allowed the task sequence to complete successfully.

We have a couple of options available to us for deployment of these task sequences in the future:

  • Create an additional device collection and populate with the Surface Pro 6 devices to target the modified task sequence and keep a separate task sequence for deploying the OS to these devices, or
  • Use some conditional queries to determine whether we’re dealing with a Surface Pro which has two disks configured as RAID 0 and hence has a disk ‘2’.

The latter is the more elegant method and means that I won’t need to keep even more task sequences around.

To implement this, we can utilise a couple of WMI queries to determine whether we’re dealing with one of these devices:

SELECT * FROM Win32_ComputerSystemProduct WHERE name = “Surface Pro”

SELECT * FROM Win32_DiskDrive WHERE Index = 2 AND InterfaceType = “SCSI”

Both are in the standard root\cimv2 namespace.

Within the task sequence, the default UEFI partitioning step should target disk 0 and the options should look like this:

Surface Pro 6 disk configuration detection

The Surface Pro 6 1TB UEFI partitioning step should target disk 2 and the conditions should have ‘all’ rather than ‘none’ in the IF statement.

Configuring PowerChute Network Shutdown on Server Core

Everyone installing Hyper-V servers is installing them as Server Core servers, right? Smile

I recently hit an issue configuring APC’s PowerChute Network Shutdown (PCNS) software on a Server Core installation of Windows Server 1809 (the most recent release of the semi-annual channel) whereby while the installation appeared to complete successfully, I could not communicate with the service to configure it post-installation.

After a little digging, it turned out that the installer had created the firewall rule exemptions for to wrong profile (i.e. public rather than domain). The solution was to run the following PowerShell to update the profile for the PCNS firewall rules to match the network profile the server was operating on:

Get-NetFirewallRule | where {$_.DisplayName -like “PCNS*”} | Set-NetFirewallRule -Profile Domain

Once the firewall rules were updated, communication was restored and configuration could be completed from a browser running on another machine.

Cross Flashing a Dell PERC H200 BIOS to Support Larger SATA Disks

The latest firmware for the Dell PERC H200 still doesn’t support SATA disks of greater than 2.2TB. In fact the card cannot even detect SATA drives that are larger than this.  As the PERC H200 is essentially a rebadged LSI 9211-8i card however, the firmware and BIOS from that card can be flashed onto the PERC H200 to provide support for larger SATA hard drives.

The procedure is as follows:

  1. Download the latest 9211-8i firmware package from LSI. I got my copy from http://www.lsi.com/products/storagecomponents/Pages/LSISAS9211-8i.aspx (click on the ‘Support & Downloads’ tab, then expand the firmware section). I downloaded the ‘9211_8i_Package_P16_IR_IT_Firmware_BIOS_for_MSDOS_Windows’ package and extracted the contents.
  2. Copy the required files from the extracted archive onto bootable media. I created a Windows 98SE boot USB stick and copied the files onto it. The required files are: 
    sas2flsh.exe – this is the  flash application. Copy the version from the sas2flash_dos_rel folder if using a dos boot disk.
    2118ir.bin – this is the firmware for the 9211-8i.
    mptsas2.rom – this is the card’s BIOS.
  3. Boot the server containing the PERC H200 from the bootable media. I’d recommend disconnecting any drives from the RAID card before flashing the firmware and BIOS.
  4. Once booted, change to the folder containing the files copied to the media, above, and issue the following commands
    sas2flsh –o –f 2118ir.bin
    sas2flsh –o –b mptsas2.rom
    sas2flsh –o –reset
    Each command should report success before you move onto the next one. If any indicate a failure, double check that you copied the correct files onto the bootable media.
  5. Reboot the server and test the card.

The above procedure allowed the H200 I was using to  detect and use two 3TB disks.

Nokia Lumia 800 Battery Capacity Concerns After Update to build 1600.2483.8106.11500

I recently updated my Nokia Lumia 800 to the latest build, 1600.2483.8106.11500.

I’ve been keeping an eye on the battery capacity of my Lumia 800 following the reported battery charging issues using the phone diagnostics (which can be accessed by entering ##634# on the phone keypad, then from the list of applications afterwards) and noticed that following the update to the latest build, the reported full charge capacity started dropping. Initially it was around the 1350 mAh mark, following one full charge it dropped to about 1250 mAh, following the next it dropped to about 1140 mAh. Over the next couple of days it rallied a little, settling eventually at about 1180 mAh.

In reality I wasn’t too worried by the apparent drop in charge capacity, especially as the runtime following a charge was a good step up on what it had been before the update, but was concerned enough to drop Nokia a quick e-mail to ask them about the issue in case it was something they’d not come across before. My phone’s reported runtime was also lower than others in the office were reporting for theirs and I’ve seen some experiencing similar issues with their Lumia 800s on the Nokia forums.

Nokia’s support has been excellent. Following my initial e-mail to them, I had two very quick responses by e-mail asking for a few more details, followed by a call offering to collect the phone to run some diagnostics on it. Following a quick conversation with Robert however, it looks like I won’t need to take them up on their offer…

The solution in my case was to stop the tasks running in the background on my phone. After stopping the background tasks (go to settings, then slide one screen over to applications, then select background tasks and stop anything that is showing as running), RAC Traffic and one other in my case, I rechecked the battery diagnostics, and not only showed that the current being used had dropped by about half, but the reported battery full charge capacity had returned to it’s original state of over 1400 mAh.

Quite why a couple of running background tasks were influencing the reported full charge capacity of the battery, I’m not quite sure, but the method seems to be a reliable way to return the reported capacity of the battery to its full value.

Changing the interface mode of a StarTech InfoSafe 4-bay external hard drive enclosure

We’ve seen a couple of issues with a StarTech InfoSave 4-bay external hard drive enclosure (model SAT3540U2E) when trying to change the connection mode from USB to eSATA. Specifically, when following the instructions (which appear to state for example that when an eSATA connection is detected, the eSATA LED will light) to change the connection mode, pressing the interface button appeared to do absolutely nothing…

A quick live chat with one of StarTech’s support engineers provided the answer, which is to push and hold the interface button to change between USB and eSATA connections and vice-versa.

To summarise our findings so far:

  • The default connection interface seems to be USB. Plugging the device into a computer using a USB cable allows the disks to be seen immediately.
  • Plugging in the device using a eSATA cable does not result in the eSATA LED lighting.
  • Pushing and holding the interface button for a couple of seconds allows the interface connection to be changed from USB to eSATA and back again.
  • Plugging the device in using an eSATA cable without plugging in a USB cable does not automatically switch to using the eSATA interface.
  • The sync button works in the same way as the interface button, i.e. push and hold for a couple of seconds to change the mode.

Running Hyper-V on an Acer 6593G

We’ve recently seen an issue running Windows Server 2008 R2 with the Hyper-V role installed on an Acer 6593G laptop. We’d updated the BIOS to the latest version available from the Acer site (1.16 at the time of writing) and Server 2008 R2 would no longer boot once the Hyper-V role was installed.

Rolling back the BIOS to the 1.11 version solved the problem.

We’ve also tested the 1.09 version, which seems to work okay, but have yet to try the 1.13 version which is also available. I’ll update this post when we’ve tried the 1.13 version.

Updating my ML115 G5

I have an HP ML115 G5 acting as a Home Server which started showing disk related issues as the disks approached being full. Following a tip from Rik, I updated the BIOS to the latest version available from the HP site. While this seems to have fixed the disk related issues, updating the BIOS seemed to cause some BMC related issues; the fans in the system would spin up to full speed when the system was started, but then instead of returning to their normal whisper quiet speed for normal operation, they stayed running at full speed even after the OS had booted.

Following a bit of research, it appears that even if the lights-out 100 remote management card is not installed in the ML100 series servers, the firmware for the card actually runs on the system board and hence needs an update as well. Installing the latest version of the management firmware available on the HP site fixed the fan speed issue and my Home Server has returned to its normal unobtrusive self.

It seems a little odd that HP doesn’t mention that the firmware update is needed at the same time as the BIOS update, I’m sure that it would save a lot of support calls if they mentioned it!