Installing Intune software in the system context with Folder sharing (software that is questionable.)

Question

Hello everyone,

I’m facing a dilemma here and hope someone can help me.

If I have an on-premises infrastructure, the share must be readable by “domain computers.”

But what if I don’t have an on-premises infrastructure, only Entra (Intune)?

The customer has software that is installed via a file share, and the user doesn’t have permission and isn’t supposed to have it, but the system user can’t perform the installation because the system doesn’t have rights to the SMB share.

Best regards, and thanks in advance for any tips or a solution :-O

Translated with DeepL.com (free version)

Answer 1

Hi Markus Richter,

Just a quick follow-up to see if you managed to get your software deployed successfully using the Win32 App packaging method (.intunewin) we discussed.

Were you able to wrap the installer and push it through Intune in the System context, or are you still running into any hurdles moving away from that SMB share?

Let me know if you hit any packaging errors or need help configuring the install/uninstall commands in the Intune portal. I'm happy to help!

Tracy.

Answer 2

Hi Markus Richter,

The AI answer is technically correct about the limitation, but it misses the actual modern solution. You are trying to apply a legacy on-prem mindset (SMB shares) to a cloud-native tool (Intune). In a pure Entra environment, NT AUTHORITY\SYSTEM has no network identity. Trying to force it to authenticate to an on-prem SMB share is a dead end.

The Solution: Use Win32 App Packaging (.intunewin)

Stop using the file share for this deployment.

Use the Microsoft Win32 Content Prep Tool to wrap your installation files into a single .intunewin package.

Upload that package directly into Intune as a Win32 App.

Configure the app to install in the System context.

Intune will securely download the installation payload from Microsoft's CDN directly to the local cache of the endpoint. The Intune Management Extension (running as SYSTEM) will then execute the installation locally.

No SMB shares, no network authentication issues, and the end-user needs absolutely zero permissions. Cut the cord with the on-prem share!

Tracy Le

Answer 3

For cloud-native, Entra-joined/Intune-managed devices, using “machine account” (computer account) permissions on SMB shares is not supported and will fail. The scenario where the SYSTEM/machine identity reads from a file share (as in classic on-prem domain-joined environments with “Domain Computers” on the share ACL) does not work without on-prem AD.

Key points from the documented behavior:

1. Cloud-native endpoints don’t support on-premises AD machine authentication
   • When devices are joined only to Microsoft Entra and not to on-prem AD, they have no usable on-prem computer account.
   • Any access model that relies on machine accounts (e.g., ACLs that grant access only to computer accounts or groups of computer accounts) will fail.
   • This includes network storage access where file shares are secured using only machine accounts.
2. Recommendation: switch to user-based authentication
   • Update file share permissions to use user accounts or user groups instead of machine accounts.
   • Use Microsoft Entra-based SSO for user access to on-prem resources where applicable.
   • For applications that currently rely on machine authentication, update them to use Microsoft Entra authentication or user/service accounts.
3. Implication for installing software from a share in SYSTEM context
   • In a pure Entra/Intune environment, SYSTEM cannot authenticate to an on-prem SMB share via an on-prem machine account, because such an account does not exist.
   • Therefore, the classic pattern “software share readable by Domain Computers, install in system context” is not supported.
4. Practical options based on the documented guidance
   • Stop relying on machine-account-only ACLs for the software share. Instead:
     • Grant access to user identities (for user-context installs), or
     • Use a service account or another supported identity mechanism that the installer can use.
   • Where possible, move the content off SMB and into cloud storage (for example, SharePoint Online or OneDrive) and adjust the deployment method accordingly.

If the customer insists on keeping SMB-based deployment with no user permissions and only “system” access, that pattern is tied to on-prem AD machine authentication and is not supported for cloud-native Entra-joined/Intune-only devices.

---

References:

• Known issues and limitations with cloud-native endpoints