I have a Computer GPO in a Windows Active Directory based network (with on-premises Domain Controllers) that currently installs an application from \\MYDOMAIN\NETLOGON\...\application.msi at startup. This works well for all my machines that are network connected at boot, but I have a growing number of Windows users connecting via VPN, which means that the machine is not network connected until some point after user login.

In the absence of any obvious best practice alternative my proposed solution is to copy the application.msi to a hidden dedicated folder C:\localapps and to install from there.

The top-level folder creation works well. Copying the configuration file works well. Inherited permissions on the folder tree work well. What doesn't work is that the application.msi file cannot be copied.

Frustratingly, if I rename application.msi to application.msi.zzz the same GPO can - and does - copy the file to the local machine quite happily.

Further research, psexec -i -s explorer.exe gives me an Explorer window running as the GPO's SYSTEM account. Indeed, I can navigate to the appropriate place on \\MYDOMAIN\NETLOGIN and I can copy files from there unless they are named as executables or installers. All files in the folder have inherited permissions and I have confirmed they are the same. All files are "unblocked". All files have the same owner (MYDOMAIN\Administrators). I'm not trying to execute the MSI from the network share, just to copy it.

Empirical conclusion: the SYSTEM account used by the GPO cannot copy *.msi or *.exe files from the \\MYDOMAIN\NETLOGON\ share.

This doesn't seem to be a reasonable state of affairs, so how do I get my GPO to copy the application.msi as is, so that at the next opportunity it can be installed from the local disk?

  • 2
    Can you try without the antivirus? What can you see if you procmon while copying manually ? access denied ? – Swisstone Oct 5 '20 at 17:37
  • @Swisstone copying manually failed as the SYSTEM user but succeeded as "me". However, your suggestion about the antivirus was spot on, thank you. If you would like to post an answer to get the points I'll happily upvote/accept yours and/or remove mine – roaima Oct 5 '20 at 21:03
  • Glad it helped! you can accept your own answer it's ok for me. – Swisstone Oct 6 '20 at 4:10

Embarassingly, it turned out to be the Intrusion Detection System in my client antivirus, ESET Endpoint Security, blocking any access to executables on what it thought was an untrusted SMB network connection.

I've modified the organisational policy to disable this particular test for files on the Domain Controllers (none of which is on the same LAN as any of the client computers) and all seems well.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.