How to Configure Elevation for .bat and .msc Files in Application Control Plus?
Key Points
Configuration steps
End-user implementation
A .bat (Batch) file is a Windows command script that automates tasks using command-line instructions. These files are commonly used for software installation, system configuration, cleanup operations, and administrative automation. An .msc file is a Microsoft Management Console (MMC) file that opens administrative snap-ins such as Services, Device Manager, or Event Viewer. These files are typically used to access and manage system-level configurations. Examples of .msc files include:
- Services (services.msc): Manage Windows services (start, stop, configure).
- Device Manager (devmgmt.msc): View and manage hardware devices.
- Event Viewer (eventvwr.msc): Monitor system and application logs.
Application Control Plus supports elevation of both .bat and .msc files through policy-based controls. This enables approved scripts and management consoles to run with administrative privileges without granting users full local administrator rights. Only explicitly authorized files in the policy are permitted to run with elevated privileges. All others remain restricted under standard user permissions.
The goal is controlled privilege delegation — enabling necessary administrative execution without expanding the user's privilege boundary.
Enable secure .bat & .msc file elevation with Application Control Plus!
Elevate Now
Configuration Steps
The .bat and .msc file elevation can be configured only through the following rules:
- Folder Path Rule
- File Hash Rule
Folder-Based Elevation
You can make use of the Folder Path rule when the files are stored in a controlled directory, or if multiple files need elevation. Follow the steps below:
- Navigate in Application Control Plus console ->Privilege Management. Click on Create Policy/Modify.
- Enable the toggle for 'Configure specific application to run with elevated privileges'. The option 'Allow users to elevate all applications' can also be enabled for end-users to self-elevate applications by providing a justification. Refer here to learn more about configuring the Privileged Application List.
- Choose to add specific applications for elevation. Under selecting specific applications, select the rule type Folder Path.
- Specify the folder path containing the approved file(s). The elevation of the child processes created by the folder files can be blocked by enabling 'Restrict Child Elevation'.

- Save the list and deploy it to the target devices that should receive this elevated access. All eligible files, including .bat and .msc files, inside that folder will inherit elevation based on policy.
Hash-Based Elevation
You can make use of the File Hash rule when only a specific .bat or .msc file has to be elevated. First, finding the hash value of a .bat or .msc file can be done through either Command Prompt or PowerShell.
- Using Command Prompt (CMD):
- Using Powershell:
Now that the file hash is retrieved, follow the steps below for configuring the policy for elevating the file:
- Create the Privileged Application List as mentioned in the steps above.
- In the Select Specific Applications section, select the File Hash rule type.
- The .bat and .msc files can be added using the custom rule. Click Add under the rule type and specify the executable name and hash value of the file.
- The elevation of its child processes can be blocked by enabling 'Restrict Child Elevation' against the file.

- Save the list and deploy it to the target devices that should receive this elevated access. This is more secure as the elevation will be tied to file's unique hash and the hash changes if the file is modified. The modified version will not be elevated.
End-user Implementation
Once the policy is deployed, it will take effect immediately or in the next refresh cycle. After policy deployment, the end-user can navigate to the file, right-click, and select 'Run as Administrator'. The file will run with elevated privileges.
Recommended Best Practices
- Prefer Hash Rule for high-security environments.
- Store elevated scripts in secured, non-user-writable directories.
- Regularly audit elevated scripts.
- Avoid broad folder-based elevation unless operationally required.
- Limit elevation to necessary administrative tasks.