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.

Deploying Visual Studio 2017 Using Configuration Manager

Previous versions of Visual Studio were typically delivered via ISO files that we could import into Configuration Manager for deployment to workstations. Visual Studio 2017 arrives as a web installer only (although you can create installation media using the –layout option from the command line if you still want to go down that route).

The command-line parameters of the Visual Studio 2017 installer are also different to previous versions as well, requiring a different approach. See https://docs.microsoft.com/en-us/visualstudio/install/use-command-line-parameters-to-install-visual-studio for information on the available command-line parameters.

In the past I’ve tried using an AdminDeployment.xml file to control which components of Visual Studio are installed. With Visual Studio 2013 this worked fine for me. With Visual Studio 2015 I could not make this approach work at all, and ended up specifying the components to be installed by using the ‘/InstallSelectableItems’ command-line parameter, which worked a treat.

Visual Studio uses this latter approach to selecting the components that will be installed with the product, but the system has been extended to provide more control over the component installation, with an ‘IncludeRecommended’ and ‘IncludeOptional’ flag available for each component, or globally, as required. A list of the Visual Studio 2017 workload and component IDs can be found at https://docs.microsoft.com/en-us/visualstudio/install/workload-and-component-ids (click through to the product you’re installing, for us this was Visual Studio Enterprise 2017, workload and component IDs for which are found at https://docs.microsoft.com/en-us/visualstudio/install/workload-component-id-vs-enterprise)

For example, to add the Azure development workload, with all optional and recommended components, you’d add the following to the command-line that you issue to the installer:

–add Microsoft.VisualStudio.Workload.Azure;includeOptional;includeRecommended

As you can see, this means that the command-line has the potential to get long very quickly!

For the workloads and components I was asked to deploy with Visual Studio Enterprise 2017, our command-line became

mu_visual_studio_enterprise_2017_x86_x64_10049783.exe –add Microsoft.VisualStudio.Workload.Azure;includeOptional;includeRecommended –add Microsoft.VisualStudio.Workload.Data;includeOptional;includeRecommended –add Microsoft.VisualStudio.Workload.ManagedDesktop;includeOptional;includeRecommended –add Microsoft.VisualStudio.Workload.ManagedGame;includeOptional;includeRecommended –add Microsoft.VisualStudio.Workload.NativeCrossPlat –add Microsoft.VisualStudio.Workload.NativeDesktop –add Microsoft.VisualStudio.Workload.NativeGame –add Microsoft.VisualStudio.Workload.NativeMobile –add Microsoft.VisualStudio.Workload.NetCoreTools;includeOptional;includeRecommended –add Microsoft.VisualStudio.Workload.NetCrossPlat;includeOptional;includeRecommended –add Microsoft.VisualStudio.Workload.NetWeb;includeOptional;includeRecommended –add Microsoft.VisualStudio.Workload.Node;includeOptional;includeRecommended –add Microsoft.VisualStudio.Workload.Office;includeOptional;includeRecommended –add Microsoft.VisualStudio.Workload.Universal;includeOptional;includeRecommended –add Microsoft.VisualStudio.Workload.VisualStudioExtension –add Microsoft.VisualStudio.Workload.WebCrossPlat;includeOptional;includeRecommended –add Component.GitHub.VisualStudio –add Microsoft.Component.Blend.SDK.WPF –add Microsoft.Component.HelpViewer –add Microsoft.Net.Component.3.5.DeveloperTools –add Microsoft.VisualStudio.Component.LinqToSql –add Microsoft.VisualStudio.Component.TestTools.CodedUITest –add Microsoft.VisualStudio.Component.TestTools.Core –add Microsoft.VisualStudio.Component.TestTools.FeedbackClient –add Microsoft.VisualStudio.Component.TestTools.MicrosoftTestManager –add Microsoft.VisualStudio.Component.TestTools.WebLoadTest –add Microsoft.VisualStudio.Component.TypeScript.2.0 –quiet –norestart –wait

Which, frankly, is huge!

The length of the command-line poses an immediate issue as it’s longer than that allowed in the text box for the installation program for an application. Here’s the approach I took:

  1. Once you’ve determined the workloads and components that are to be installed, create a batch file containing the command line. Prefix the command line with %~dp0 (no backslash or anything; this is to run the command-line from the current directory).
  2. (Optional) Create a batch file to uninstall Visual Studio 2017. My batch file contains the following command:
    %~dp0mu_visual_studio_enterprise_2017_x86_x64_10049783.exe uninstall –quiet –wait
  3. Copy the two batch files created, along with the web installer to a suitable location on the Configuration Manager server, the configure the application as follows:
    1. Create a new application and select ‘manually specify the application information’.
    2. Specify the name for the application, publisher, version and any other information required by your organisation:
      General Application Settings
    3. Specify the appearance of the application in the Application Catalog. Specify the icon by browsing to the web installer and selecting this. One icon is available:
      Application Icon
    4. On the ‘Deployment Type’ page of the wizard, click ‘Add’ and again specify ‘manually specify the deployment type information’.
    5. Provide a name for the deployment type, e.g. ‘Visual Studio Enterprise 2017’ and any required comments.
    6. Specify the content location. This should be the network path where the web installer and two batch files are located, e.g. ‘\\SCCM\Applications\VisualStudioEnterprise2017’.
    7. For the installation program, specify the name (and extension) of the installation batch file you created earlier.
    8. For the uninstall program, specify the uninstallation batch file you created earlier, or the following command-line if you chose not to create a batch file:
      mu_visual_studio_enterprise_2017_x86_x64_10049783.exe -uninstall –quiet –wait
      Content Location and Programs
    9. Specify the detection method that you want to use. I opted for a simple ‘devenv.exe’ version greater than or equal to ‘15.0.26228.4’ which was the version of the file deployed during testing of the installer:
      App Deployment Detection
    10. Specify the user experience settings. Our installation takes approximately 60 minutes. I chose also to allow the maximum run time to be longer than the default 2 hours.
    11. Specify any requirements for the installation. I didn’t have anything to add here.
    12. Specify any dependencies for the installation. Again I didn’t have anything to add here.
    13. Complete the creation of the application by clicking ‘Next’ at the subsequent screens.
  4. Distribute the content by right-clicking the application and selecting ‘Distribute Content’.
  5. Deploy the application and select appropriate collections to deploy it to.
  6. Test!

Note: Installation takes approximately an hour on our workstations, and fails if any other Visual Studio product is running on the workstation during the installation process.

Offline Domain Join with Direct Access

I was recently in the position that I needed to rebuild a workstation at a remote location, but wanted to end up with it joined to the domain, and able to install software via the SCCM Software Center. Enter Offline Domain Join (djoin.exe)!

Offline Domain Join allows the creation of a machine account and the establishment of a trust relationship between a computer running Windows and a Domain. As part of the process, group policy information can also be transferred to the machine that will be joined to the domain.

Assuming Direct Access is available, the appropriate group policy information for Direct Access can be transferred as part of the process, and this should then allow the remote machine to establish a connection to the domain and from there all remaining group policy information can be transferred, the Configuration Manager client installed etc.

Information on ‘djoin.exe’ including examples for use can be found at https://technet.microsoft.com/en-us/library/offline-domain-join-djoin-step-by-step

My scenario was:

  • The machine account already existed in the correct OU and was a member of the appropriate groups for Direct Access (the machine name had already been used; this was a rebuild) and therefore I needed to use the ‘/reuse’ parameter.
  • The only group policy information I wanted to transfer to the remote machine was for Direct Access. I anticipated that all other group policy information would be transferred automatically once a Direct Access connection had been established.

In my case, the command I used on the provisioning server were:

djoin /provision /domain domain.com /machine MyWorkstation /savefile MyWorkstation-blob.txt /reuse /policynames “Direct Access Client”

The resultant blob should be transferred securely – take note of what the TechNet page says on the matter:

The base64-encoded metadata blob that is created by the provisioning command contains very sensitive data. It should be treated just as securely as a plaintext password. The blob contains the machine account password and other information about the domain, including the domain name, the name of a domain controller, the security ID (SID) of the domain, and so on. If the blob is being transported physically or over the network, care must be taken to transport it securely.

On the remote workstation, the command I used was:

djoin /requestODJ /loadfile MyWorkstation-blob.txt /windowspath %SystemRoot% /localos

At this point you’re prompted to reboot the workstation. Once the reboot was complete, I left the machine for a few minutes to allow it to establish a connection, then signed in. Everything worked as anticipated and I could log in as a domain user and a Direct Access connection was established. Following a group policy update, the Configuration Manager client was transferred and installed, and a short time later the Software Center became available and I could add software made available from SCCM.

Deploying FileZilla with Configuration Manager 2012 R2

Some time ago I created an System Center Configuration Manager (SCCM) application to deploy FileZilla for users. Recently I created an updated application that upgraded FileZilla (using the usual ‘uninstall the old version, then install the new version’ method), which gave me an error when the application was upgraded:

Application Upgrade Filaed

Unable to make changes to your software

with the reported error being ‘The software change returned error code 0x87D00325 (-2016410843).

In addition, attempting to uninstall the application using the SCCM Software Center on the client machine gave a ‘Removal Failed’ with the same error details:

FileZilla Removal Failed

Digging through the AppEnforce log file on the client, an error was reported when attempting to uninstall the application as part of the change:

Prepared command line: “C:\Program Files (x86)\FileZilla FTP Client\uninstall.exe” /S
Post install behavior is BasedOnExitCode
Waiting for process 1616 to finish.  Timeout = 120 minutes.
Process 1616 terminated with exitcode: 0
Looking for exit code 0 in exit codes table…
Matched exit code 0 to a Success entry in exit codes table.
Performing detection of app deployment type FileZilla 3.13.0 x86
Discovered application
App enforcement completed (0 seconds) for App DT “FileZilla 3.13.0 x86”

This indicates that the uninstall process completed, but the application was detected as still being installed immediately afterwards. This is due to the way that uninstallation is performed, with the uninstall process triggered by SCCM spawning another process to actually perform the uninstallation, while the original process terminates. This means that the process that SCCM is waiting on to complete, does so almost immediately, while the actual work to perform the uninstallation is on-going, hence the reason that SCCM then detects the application as still present on the client system.

To get around the issue, we need to wait a period of time after the uninstallation is triggered to allow for completion before allowing SCCM to perform its detection. In order to do this, I’m using the ‘sleep.exe’ program that comes with the Windows 2003 Resource Kit Tools (available at http://www.microsoft.com/en-us/download/details.aspx?id=17657) to achieve this.

The items we’ll need to be copied to an appropriate location for deployment are:

  • The FileZilla installer
  • The sleep.exe program
  • A batch file to perform the uninstallation
  • An SCCM application that uses the batch file

The batch file should contain two lines:

“%ProgramFiles%\FileZilla FTP Client\uninstall.exe” /S
Sleep 20

This runs the uninstaller as before, then pauses for 20 seconds to allow the system to catch up. 20 seconds is long enough for our client machines, YMMV.

The SCCM application should then be created as normal:

Manually specify the application information:

Manually specify the application information

Provide a name for the application and optionally a publisher, version etc.:

Provide a name for the application and optionally a publisher, version etc.

Provide appropriate information for the Application Catalog:

Provide appropriate information for the Application Catalog

Click ‘Add…’ to add a Deployment Type to the application:

Click ‘Add…’ to add a Deployment Type to the application

Select ‘Manually specify the deployment type information’:

Select ‘Manually specify the deployment type information’

Provide a deployment type name and optionally administrator comments:

Provide a deployment type name and optionally administrator comments

For the content page of the wizard, specify the content location, for the installation program, specify ‘FileZilla_X.XX.X_win32-setup.exe /S’ and for the uninstall program, specify the batch file that was created previously:

For the content page of the wizard, specify the content location, installation program and uninsatll program

For the detection rules, we used the file version of the ‘filezilla.exe’ program file that gets installed, which seemed to work well:

For the detection rules, use the version of the 'filezilla.exe' file

In addition, if required, supersedence information can be added to the application.

The procedure above provided a robust SCCM application that can be installed and uninstalled without issue and can also be upgraded to a later version without issue. It should be noted that this method works for other applications with the same sort of uninstallation routine, e.g. Notepad++.