Setup cannot set correct folder permission for %Pr

There is my BasicMsi setup that installs an application (32bit) MyApp per-machine. The installer requires admin rights at startup. The application MyApp is installed into the INSTALLDIR-folder selected by the Operator (by UI/CommadLine) and a %ProgramData%\<MyFirm>\<MyApp> structure is created with subfolders and files. In the msi-table LockPermissions, permissions are set to modify (read/write/delete...) for folder <MyApp> for LOCAL user groups 'Administrators' and 'Users' (located by SID). Files in <MyApp> and subfolders are used and modified by the application MyApp at runtime. The setup installs the application on systems from Win7 to Win10 and from WinServer2003 to WinServer2016 (32/64; UAC on/off). The application is launched by the Operator(s) with account in the local user groups 'Administrators' or 'Users' (NOT 'Run as admin').

Problem: after installation on WinServer2012 and WinServer2016 ONLY (WinServer2008 is not checked; and WinServer2003 - IS OK) an Operator with account in the local group Administrators or Users does not have permissions to write/delete/create files in the folder <MyApp> and subfolders. The result - the application does not work correctly (ONLY for WinServer2012 and WinServer2016).

Help me, please, with Questions:

what is the difference in folders permissions under %ProgramData%, or what is the difference of rights of local built-in user groups ('Administrators' or 'Users') for Win10 (or WinServer2003) versus (WinServer2012 and WinServer2016) ?
what else should be changed in the system (WinServer2012 and WinServer2016) by the installer so that accounts from the local groups Administrators or Users have write/delete rights in the folder %ProgramData%\<MyFirm>\<MyApp> without 'Run as Administrator' (UAC on/off) ?

Thanks in advance.

UPDATE: Setting Permissions in Windows Installer: MSILockPermissionsEX and ISLockPermissions (using Installshield).

Permission Inspection: What are the actual permissions showing on the folder? You can use Windows Explorer => Properties => Security => Advanced => Double click user / group to see detailed access. Check for differences between the systems that work and don't work.

If that is not good enough maybe try SysInternals' AccessEnum or AccessChk tools to show details about the permissions defined for the object in question.

Privilege Inspection: I would also use Process Explorer to check what NT Privileges your process runs with - just to check for any differences ("torpedoes full spread" in sci-fi terms - as in "what the heck are we doing" - can't hurt). I don't really think this should affect things - privileges and permissions are different (privileges apply system-wide - such as changing system-time, log on as a service, etc... - permissions are defined for securable objects such as files and folders).

Launch Process Explorer
Double click your application process (if it launches)
Go to "Security" tab and look at lower box:

Logging: Did you do proper logging? If not, install and create a verbose log file. And maybe check my answer here. And a more elaborate version with more hints on understanding the log entries.