Some supporting software from hardware vendors prompts the end users to install when as supported hardware is connected to the device. An example is Dell Display and Peripheral Manager. Which prompts the end user to launch an installer that in turn requires the end user to be local admin or the installation fails. It could of course be allowed using EPM which would elevate it automatically. There are many more examples out there.
Event if we set the policy to prevent installation of supporting software to be installed from the store, this software is not installed from the store. Instead it is pulled from Windows Update and launched as a driver installation. When we manage Windows updates from Intune we want drivers from Windows Updates to keep our devices up to date so we cannot block drivers from Windows Update.
If we look at the driver we can see that the driver oem.inf in my case is Oem35.inf
In that file we can see that the only thing this “driver” is doing is downloading “DDPMDownloader.exe” and starting the installation of Dell Display and Peripheral manager. It would be nice if this was not allowed by Microsoft as it is not a driver and requires local administrative permissions to install or in the best of worlds only prompt if the user is logged with local administrator permissions. But we can block it at least, but there are mote hardware out there where the drivers do the same.
If we go back and look at the driver in Device Manager we can grab the Hardware ID from the driver properties.
Then we block that device ID from being installed using Device Installation Restriction policy in Intune.
That solves the problem, the prompt to install the Dell Display and Peripheral Manager is never displayed to the end user, but it is still possible to deploy Dell Display and Peripheral Manager using Intune in combination with your 3rd party patching solution if you want it installed.
This is awesome, however to throw a greasy pig into the works. The oemXX.inf number is different depending on the device, so it isn’t always going to be oem35.inf.
We had this issue with the inbuilt XPS and PDF print driver not being signed and preventing in place upgrades to Windows 11. We had to use a powershell script to detect the read the inf to determine the file name for devices which failed the compat scan due to unsigned drivers.
At least this gives me a direction to keep working on to kill what I consider to be corporate malware.