Windows app deployments show random UAC prompts and native enrollment asks for Microsoft accountSolved

Hello @im_dany ,

The difference in behavior usually comes down to how Windows handles installer privileges, the type of installer being deployed, and the installation scope configured in Hexnode.

For app deployments that install silently without prompting for admin rights, one of the following is usually true:

• The app is being installed in system context. If the package is configured for All User Accounts, the Hexnode agent runs the installer using the local system account, which has the required privileges.
• The application is a per-user installer. Some apps install only inside the logged-in user’s profile, such as under AppData, and do not need admin rights.

UAC prompts are commonly seen when:

• The EXE is configured to run in the current user context, and the logged-in user is a standard user.
• The installer tries to write to protected locations such as Program Files or HKLM registry keys.
• The EXE package does not include the correct silent installation arguments, causing Windows to launch an interactive setup wizard.

For EXE deployments, make sure the package is configured with the correct installation scope and the vendor-supported silent switches, such as /S, /silent, /VERYSILENT, or other parameters specific to that installer. MSI packages are usually more predictable and commonly support silent options such as /qn.

For the Windows native enrollment issue, standard users do not have the required privileges to complete enrollment through the built-in Access work or school flow. This can result in a message similar to: “You don’t have the right privileges to perform this operation.”

The recommended approach is to use the Hexnode Windows installer instead of the native Windows enrollment screen. Download the Hexnode installer from the enrollment page and run it with local administrator rights. This installs the Hexnode agent and completes enrollment without relying on the Microsoft account-style native enrollment prompt.

Regrads,
Simon Scott
Hexnode UEM

Got it. For app deployment prompts, we’ll check the install scope and silent arguments for each EXE. For the native enrollment method, temporarily making the user a local admin would work, but most of our devices are remote. Standard users also cannot open tools like netplwiz to change their own account type, so that method is hard to use at scale.

For remote devices that are not yet enrolled, Hexnode UEM cannot elevate the local user account because the device is not under management yet.

Self-service or policy-based temporary admin elevation can be useful after the device is enrolled, but it cannot solve the initial enrollment privilege requirement on an unmanaged device.

For remote Windows enrollment, the practical options are:

• Use the Hexnode installer and run it with local administrator credentials.
• Use another supported Windows enrollment method that fits your deployment workflow.
• Temporarily provide or coordinate admin access only for enrollment, then revert the account to standard user after enrollment is complete.

Once the device is enrolled, Hexnode UEM can continue managing it even if the user account is changed back to standard user.