SlimDrivers.exe is an executable file that runs the SlimDrivers program, a freeware driver management tool. This is not an essential Windows process and can be disabled if known to create problems. The SlimDrivers program scans the system and checks for missing drivers and automatically updates them to the latest version. Badvok wrote: I had a similar problem in a mixed processor architecture enviroment - the 64 machines would repeatedly ask for the driver to be installed, this was resolved by changing the driver to different version within the current available drivers - think we ended up using a PS driver, which immediately solved the problem without reoccurance. On the domain controller, select Start, select Administrative Tools, and then select Group Policy Management. Or, select Start, select Run, type GPMC.MSC, and then press Enter. Expand the forest and then domains. Under your domain, select the OU where you want to create this policy. If the software doesn’t appear, take a look at The Top 10 Ways to Troubleshoot Group Policy.One special note about software deployment. If you deploy the software to the user side (assigned or published), the GPO must be linked to an OU containing users (or you have to enable loopback).
By default, non-admin domain users do not have permissions to install the printer drivers on the domain computers. To install a driver, the user should have local admin privileges (for example, by adding to the local Administrators group). This is great from the point of security because the installation of an incorrect or fake device driver could compromise PC or degrade the system performance. However, this approach is extremely inconvenient in terms of the IT-department, because it requires Support-team intervention when a user tries to install a new printer driver.
You can allow non-administrator users to install printer drivers on their Windows 10 computers (without the need to grant local Admin permissions) using Active Directory Group Policies.
Configure GPO to Allow Non-Administrators to Install Printer Drivers
At first, create a new (or edit an existing) GPO object (policy) and link it to the
Expand the following branch in the Group Policy editor: Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > Security Options. Find the policy Devices: Prevent users from installing printer drivers.
Set the policy value to Disable. This policy allows non-administrators to install printer drivers when connecting a shared network printer (the printer’s driver downloaded from the print-server host). Then you can set the policy value to Disable, any unprivileged user can install a printer driver as a part of a shared printer connection to a computer. However, this policy does not allow downloading and installing an untrusted (not-signed) printer driver.
READ ALSORemoving Windows XP Printer DriverAdding Printer Device GUIDs Allowed to Install via GPO
The next step is to allow the user to install the printer drivers via GPO. In this case, we are interested in the policy Allow non-administrators to install drivers for these device setup classes in the GPO section Computer Configuration > Policies > Administrative Templates > System > Driver Installation.
Enable the policy and specify the device classes that users should be allowed to install. Click the Show button and in the appeared window add two lines with device class GUID corresponding to printers:
- Class = Printer {4658ee7e-f050-11d1-b6bd-00c04fa372a7};
- Class = PNPPrinters {4d36e979-e325-11ce-bfc1-08002be10318}.
You can find a full list of the device class GUIDs in Windows
When you enable this policy, members of the local Users group can install a new device driver for any device that matches the specified device classes.
Note. You can enable this policy through the registry using the command:
You can find the list of allowed to install device GUIDs under the registry key: HKEY_LOCAL_MACHINESoftwarePoliciesMicrosoftWindowsDriverInstallRestrictionsAllowUserDeviceClasses.
Now save the policy.
Configuring Point and Print Restrictions Policy
In Windows 10 there is another feature related to the UAC (User Account Control) settings, which occurs when you try to install a shared network printer. If the UAC is enabled, a message appears in which you want to specify the credentials of the Administrator. If UAC is disabled, then when you try to install the printer under the non-admin user—the system hangs for some time and finally displays an error message: “Windows cannot connect to the printer. Access is denied“.
READ ALSOWhy Some Websites Not Loading on Windows 10?To solve this problem, you need to disable the policy Point and Print Restrictions. This policy is located under the Computer and User Configuration section of the GPO editor. In order to enable compatibility with previous versions of the Windows operating system, it is recommended to disable both policies. They are located in the following sections:
- Computer Configuration > Policies > Administrative Templates > Printers;
- User Configuration > Policies > Administrative Templates > Control Panel > Printers.
Then you should disable this policy for Windows 10 computers, the security warnings, and elevated command prompts do not appear when the user tries to install the network printer or when printer driver is updating.
Note. You can disable Point and Print Restrictions via the registry. Use the following command:
If you want to restrict the list of print servers from which users are allowed to install print drivers without admin permissions, you need to set the Point and Print Restriction policy to Enabled.
Then enable the option “Users can only point and print to these servers”. In the
“Enter fully qualified server names separated by semicolons” specify a list of your trusted print servers (FQDN).
Under the “Security Prompts” section select the “Don’t show warning or elevation prompt” for the policy parameters “Then installing drivers for a new connection” and “Then updating drivers for an existing connection”.
READ ALSOConfigure Legal Notices on Domain Computers using Group PolicyTest the Policy to Allow Users to Install Printer Drivers
It remains to test the policy on client computers (requires restart). After rebooting and applying Group Policy settings, users will be allowed to install printer drivers without Admin permissions.
Time Domain 3.5
Tip. After installing the update KB3170455, released on July 12, 2016, in order to successfully install the printer, the printer driver must meet the following requirements:
The driver must be signed by a trusted digital signature;
The driver must be packed (Package-aware print drivers). Installing of the unpacked (non-package-aware) drivers through Point and Print Restrictions is impossible.
This means then when you try to install the non-package-aware v3, you will see the warning “Do you trust this printer?” with the Install driver UAC button, which requires printer drivers installation under the admin account.
You can check your driver type on the print server under the node Print Management > Print Servers > Server Name > Drivers. For package-aware print drivers, you can see the True value in the Packaged column.
AuthorRecent PostsCyril KardashevskyI enjoy technology and developing websites. Since 2012 I'm running a few of my own websites, and share useful content on gadgets, PC administration and website promotion.Latest posts by Cyril Kardashevsky (see all)- Top 5 Reasons Group Policy Software Installation Is Not Working
Group Policy Software Installation (GPSI) is an effective (and free) way to manage software deployment. After years of use, I have found these five common issues. Let’s walk through the top five issues and the solutions to a fix them! We will figure out why group policy software installation not working!
Problem 1: Does the GPO apply?
If the software isn’t installing on the computer, the first place to start is at the scope tab of your GPO. Basically, if the GPO can’t apply to the computer (or user) – the application won’t install. You can ensure the GPO is applying by running a GPResult on that computer and ensuring that the GPO applied and that the application appears under Software Installation.
If the software doesn’t appear, take a look at The Top 10 Ways to Troubleshoot Group Policy. One special note about software deployment. If you deploy the software to the user side (assigned or published), the GPO must be linked to an OU containing users (or you have to enable loopback).
Also remember that GPSI applies in the foreground. Installation can only happen on a reboot or logon (and only if the GPO was downloaded beforehand). In a default environment, it is easiest just to reboot twice. If you want to turn this into a single reboot, you can enable “Always Wait on the Network at Computer Startup or Logon”. Be aware that this will slow down startups/logons.
Problem 2: Does the software install quietly?
Time Domain And Frequency Domain
For an MSI to deploy through GPSI, it must be able to install silently. To test this, you only need MSIEXEC! To test quietly, here is your syntax:
msiexec /I “PATHTOYOURMSI” /QB /T “PATHTOMST”
and here is a practical example:
After the installation progress bar has completed (and MSIEXEC.exe has terminated in the Task Manager), you should be able to launch your application through any created shortcuts. If the application errors out during install, you most likely need to specify additional options in your MST file. An example of this would be Adobe Photoshop Elements. If you do not include the serial number in the install, it can’t be deployed through GPSI.
Problem 3: Where is the MSI?
As a best practice, do not store your MSIs in Sysvol. While it may look like a great way to create redundancy, it is going to be a management nightmare. Instead, set up a dedicated file server (or better yet – use DFS!) and organize your MSI structure. For our environment, we organize the MSIs by manufacturer – then product – then version. This vertical hierarchy allows us to easily find (or update) any piece of software.
The second point to consider is how you load the MSI into Group Policy. Whenever possible, use a DFS Namespace (first choice) or a UNC path (second choice) over an IP. IPs can change (though you should be using a reservation).
Domain Time Ii
Problem 4: Can X access the MSI?
So even though your software is compatible, your users/computers that need to install this software might not be able to reach it. Take a look at the share and file/folder permissions where the MSI is located. If you are deploying to a computer, that computer needs Read/Execute. The same thing applies to a user. In our environment, we actually grant authenticated users read/execute to the share and root folder. This ensures that every deployed MSI always have the correct permissions.
Problem 5: Where are the logs?
If you’ve made it this far, you likely have an installation issue. This can be caused by a misconfigured machine, an old piece of software breaking the upgrade, or a missing component. Lucky for us, GPSI does a decent job logging these kind of issues. Open up event viewer on the troublesome machine and selection the system log. Filter the log to show any issues by Application Management Group Policy (the source) and to only show Warnings and Errors.
As you can see from the error above, GPSI couldn’t install this software until another logon has occurred. If you receive any strange MSI errors – just do a quick search on Experts-Exchange or AppDeploy for that error (ex: 1204) plus MSI. Because these error codes are consistent across nearly all MSIs, you don’t really need to search for your specific product.