There is a lot of information that we have disseminated regarding UAC applying to applications, but not nearly as much regarding control panel applets. They are, indeed, quite similar. Just like a standard .exe, a .cpl file could have one of many possible execution levels. It may be perfectly fine to run as the user. For example, personalization options to change your desktop background don’t require elevated rights because you aren’t modifying machine state. However, modifying the configuration of the Windows Firewall does change machine-wide state and, consequently, does require elevated rights.
So, much like executable files, a control panel applet should contain a manifest specifying UAC run level.
But, what happens if you have a control panel applet that was installed by an application created before Windows Vista (and its manifest schema) existed? Well, since we can’t determine which run level it requires, the principle of least privilege demands that we run it with restricted privileges. However, since this can break some control panel applets, we monitor this with the Program Compatibility Assistant. If we detect that you have launched a control panel applet that is not manifested, after you close the applet PCA will ask you if it worked correctly. If you say that it didn’t, then we set a registry key to apply the RunAsAdmin shim to the applet on future invocations and then relaunch the applet.
This approach works perfectly well at the individual user level, but once you start seeing this from the perspective of an enterprise, you may be wondering why you would ever want every one of your users to have to make the same decision. And, indeed, you don’t. You can apply the appropriate shim for a legacy control panel applet in a custom shim database that you deploy across your organization. Because it’s a bit different than shimming a standard application, I figured I would walk through this procedure.
Using Compatibility Administrator, select your custom database, and press the toolbar button to create a new Fix. After filling out the name and vendor of the applet, you can either type the path to the executable (it will auto-complete), or else you can hit the browse button. If you hit the browse button, here you will notice the first difference from a standard executable. The file dialog is limited to .exe files, so you don’t see the .cpl files while browsing around. However, you can go to the File name text box and type in *.cpl, and you will be able to see the applets in that directory.
So, find the applet that you want and click next. Take no compatibility modes, and click next again. From the Compatibility Fixes list (shims), select the RunAs* shim that works best for the applet (RunAsAdmin, RunAsHighest, or RunAsInvoker). However, now you’ll find the other difference – if you try to click the Test Run button, you’ll just get an error message. No point in trying that. Click next, and specify the properties you want to use for file matching, and click on Finish.
If you now save and install this custom shim database, you can go to the Control Panel, launch the applet, and it will be launched with the appropriate run level, and you will no longer be prompted by UAC to verify that it worked correctly. Now, you can specify the run level for legacy control panel applets across your organization without relying on each of your users to independently discover the best execution level and make that selection on their own.