Win 10: Changing the default app for PDF files

Microsoft have apparently modified the handling of file associations in Windows 10, adding additional layers of protection for some file types in an effort to prevent file association hijacking.

A number of clients I work with have encountered issues with Edge as the default PDF viewer, namely with printing. Unfortunately, existing GPOs to modify these default app associations appear to be broken by the additional protections. Some hasty troubleshooting revealed that when the registry changes are made, a desktop notification appears to the user informing them that “An app default was reset”, and Edge is promptly reverted back to the the default app for PDF files.

It seems that Microsoft’s official method to set app associations is by generating an “AppAssociations.xml” file on a reference computer, and then applying this by group policy or directly with dism.exe. This works fine for any new users created on the system, but those with existing profiles are not affected – making this pretty useless for devices already deployed.

After some searching, I managed to piece the following together from a few different articles, which is resolving the problem when applied to our 10586 clients. I have received feedback that this doesn’t work on build 10240 though, probably because the ProgID for that build differs.

New-ItemProperty -LiteralPath 'HKCU:\SOFTWARE\Classes\AppXd4nrz8ff68srnhf9t5a8sbjyar1cr723' -Name 'NoOpenWith' -Value '' -PropertyType String -Force -ea SilentlyContinue;
New-ItemProperty -LiteralPath 'HKCU:\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.pdf\OpenWithList' -Name 'a' -Value 'Acrobat.exe' -PropertyType String -Force -ea SilentlyContinue;
New-ItemProperty -LiteralPath 'HKCU:\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.pdf\OpenWithList' -Name 'MRUList' -Value 'a' -PropertyType String -Force -ea SilentlyContinue;
New-ItemProperty -LiteralPath 'HKCU:\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.pdf\OpenWithProgids' -Name 'Acrobat.Document.2015' -Value (New-Object Byte[] 0) -PropertyType None -Force -ea SilentlyContinue;

I found the ProgID for the current version of Edge here:

It is the first registry change above that appears to do the magic of preventing Edge from muscling back in when the other changes are made.

This is a frustrating limitation given the supposed design goals of Windows 10. File associations ought to be trivial to update by group policy, and I am sceptical of the rationale behind Microsoft’s decision to cripple this functionality.

Installing the Novell Client from a SCCM Task Sequence

Last week I was asked to install the cancer that is the Novell Client (Version 2 SP4 IR1) as part of an SCCM task sequence for a Windows 10 deployment.

Assuming you’ve already got an install.ini and a novellclientproperties file, you will find that your install is mostly hands free, aside from a prompt asking you to install some Novell drivers, as they are not signed with a trusted cert.

Obviously I didn’t want this prompt in the task sequence, so I needed to add Novell’s certificate to the trusted certificates store on the machine prior to the client installation.

Microsoft distribute a utility called certmgr.exe inside the Windows SDK which can be given command line arguments to achieve this. I simply copied the utility into the installation directory of my Novell Client SCCM Package, along with the certificate file.

I then created a command line install script in the same directory, as follows:

START "Cert Install" /WAIT "%~dp0certmgr.exe" -add -c %~dp0Novell.cer -s -r localMachine trustedpublisher
START "Client Install" /WAIT "%~dp0setup.exe"

Finally, I created a “Run Command Line” task sequence step, pointing it at my install script and Novell Client package.


Now, when deploying my task sequence, I see Novell’s shitty installer open and obligingly install the client with no user input required. It’s not elegant, but no environment still using Novell puts any emphasis on elegance anyway.

Suppressing download dialog with Awesomium.NET

Recently I wanted to automatically trigger and extract some backup files from a web application. Their smug support guy told me this wasn’t possible, so I started to throw together a little scraper to prove them wrong.

This particular web app does some funky stuff with javascript when authenticating users, so I couldn’t use the HttpWebRequest or WebClient classes. Given that the built-in Web Browser control is a pile of shit, I installed the Awesomium SDK which turned out to be very pleasant to work with. You can just inject your own JS which gives you a lot of flexibility.

I ran across an issue when triggering the actual download of my backup file. A download file dialog displays by default, which is less than ideal. The documentation doesn’t do a great job of explaining how to override this behavior, so here’s a quick overview of what I did in VB.NET:

Pop this in with your import statements:

Imports Awesomium.Core

Add an event handler:

AddHandler WebCore.Download, AddressOf SkipDLPath

And then put something like this in your handler method:

Private Sub SkipDLPath(sender As Object, e As DownloadEventArgs)
Dim DLPath as String = "C:\Backups\"
e.Handled = True
e.SelectedFile = DLPath
End Sub

The file chooser prompt should be suppressed and Awesomium will happily start downloading the file. I monitored the progress and completion using the DownloadItem class.