TL;DR Howto auto-configure domain workstations so PDFs open in Adobe Reader instead of Edge. Yes, this is simple. However many orgs still get it wrong. Also howto deploy Adobe Reader in the lab to domain workstations.
The issue:
There are common programs in use in Enterprises such as Adobe Reader DC that are not associated with their file extension. This is a bit of an arcane topic for the average computer user. They just want to double click on the icon and have it open correctly. This is doubly true when the file was sent to them in Outlook. The common complaint is “I cannot sign this form”, they call the service desk, and it is found that the PDF opened in Edge by default instead of Adobe. The service desk can help the user change the default, but that only fixes one system. Personally I do not expect users to know how to change file associations, nor should they have to.
The solution:
The answer is to centrally manage these file associations via GPOs of course! I know, I sound like a broken record by now. However the answer in a Windows domain is almost always Group Policy, PowerShell, or some combination of the two. This takes care of all domain workstations, saves the end users some confusion, and saves the service desk time. This allows them to focus on more important issues and ideally conduct some training and become more security aware.
Old method, no longer works in Win10:
The old method was to simply pull up the Group Policy Management Console (GPMC), create a new GPO and link it to the OU that contains the domain workstations, then navigate to
User Configuration\Preferences\Control Panel Settings\Folder Options
Then create a new ‘Open With’ policy, specify the file extension, and specify the program to use for it.
However this method is no longer valid in Windows 10. Instead one needs to setup a reference system and then export its settings.
New method, works in Win10:
This can be done by going in the new Windows Settings\Apps\Default Apps\Choose default apps by file type. Scroll down to *.pdf and set it accordingly. By default it is set to MS Edge, even after installing Adobe Reader.
Next export the settings from this reference system to XML.
Copy/paste the resulting XML file to somewhere convenient that all systems can access. The domain SYSVOL works nicely for this. (I put mine in \\test.local\SYSVOL\test.local\scripts.) Then simply set the applicable GPO to apply this configuration to all domain workstations. Navigate to
\Computer Configuration\Administrative Templates\Windows Components\File Explorer
Enable the policy ‘Set a default associations configuration file’ and set it to the location of the XML that you exported. (The default location for Windows 10 file associations is ‘c:\windows\system32\defaultassociations.xml’.)
That is it. The policy will take effect for all domain users at their next login.
Auto-installing Adobe Reader:
A large organization is probably already utilizing Microsoft SCCM to manage software, but if you are a smaller outfit or are doing this in a home lab then this can done via Group Policy.
The first step is to download the uncompressed executable from Adobe. Next extract the files it contains.
Then post the installer somewhere that domain workstations can reach it. I used the SYSVOL for simplicities sake. Additionally I put a script there to install Adobe Reader DC on any domain workstations that did not already have it.
Next create an install script. Performing a silent install can actually be rather tricky depending on the software in question. Luckily people like Jason Bergner at Silent Install HQ have published some really good guidance on this topic. Additionally Adam the Automator has written some great howtos on PowerShell scripting. Combining ideas from both one can quickly create a script to check if Adobe Reader is already installed and then install it if is not already.
# This function will return the logged-on status of a local or remote computer
# Written by BigTeddy 10 September 2012
# Version 1.0
# Sample usage:
# GetRemoteLogonStatus '<remoteComputerName>'
function GetRemoteLogonStatus ($computer = 'localhost') {
if (Test-Connection $computer -Count 2 -Quiet) {
try {
$user = $null
$user = gwmi -Class win32_computersystem -ComputerName $computer | select -ExpandProperty username -ErrorAction Stop
}
catch { "Not logged on"; return }
try {
if ((Get-Process logonui -ComputerName $computer -ErrorAction Stop) -and ($user)) {
"Workstation locked by $user"
}
}
catch { if ($user) { "$user logged on" } }
}
else { "$computer Offline" }
}
Then simply set a startup script via GPO and point it to where you saved the script. This method executes the script under the Local System account upon boot up, hence the user does not need to be a local admin on their workstation. It is generally horrible security hygiene to make Domain Users a local admin on their workstation, so this method of deployment maintains best practices.
Note that the default script behavior since Windows Vista is to run asynchronously. This means that the Domain User is not bothered by seeing the script run. Asynchronous scripts also do not wait for any prior scripts to finish before running.
Navigate to Computer Configuration\Windows Settings\Scripts
For simplicities sake, you can simply hit the button marked ‘Show Files…’. This will open Windows Explorer and show the GPO’s subfolder named ‘scripts’ located in SYSVOL. If one is feeling lazy like I was then simply place the install script and installation files there. This allows you to get away with putting “ .\ “ in the script rather than specifying a share name. Obviously if you work in a larger org then they will have a share drive specifically for software, however in that case they will probably be using SCCM anyway. This is the proverbial quick & dirty way to deploy software to all domain workstations in a small org or in a lab environment.
Sidenote:
It is tempting to use an ‘install.cmd’ file to point to a PowerShell script and bypass Execution Policy for only that one script. I have taken this approach before. However cmd.exe does not support Universal Naming Convention (UNC) paths, so this can lead to some headaches. PowerShell will happily accommodate them, even if it is a DFS namespace. Hence I simply used a PowerShell startup script to deploy Adobe Reader DC.
Conclusion:
Hopefully this is helpful to someone. I learned a bit about silent installs and got some practice with PowerShell scripting in the process of setting this up. I also had not known that the GPO changed for setting default file associations in Windows 10. I would imagine that the orgs that are getting PDFs wrong have probably just forgot to change their GPO.
References:
https://community.adobe.com/t5/acrobat-reader/extract-msi-from-reader-exe/m-p/10243361
https://silentinstallhq.com/adobe-reader-dc-silent-install-how-to-guide/
http://woshub.com/managing-default-file-associations-in-windows-10/
https://adamtheautomator.com/powershell-check-if-file-exists/
