Software Deployment

As far as i know (but i didnt't test this) the access to the share is dont in SYSTEM context, which means you need to give the computer access to it.
the installer get the user AND the system token if you trigger a repair, but the share access is done with the SYSTEM user.

i think there is still something wrong with your share access rights,
try to give the computer account all rights, but revoke (not explict deny) the access to the users.
if that doesnt work, explicitly deny the user LIST FOLDER.

btw you only need msiexec /fpu for user keys and missing files

Anyone?

I'm sure this is a common problem, since I guess distribution via GPO installs MSI-files from a network share?

/Mathias

is it possible to deny file listing on our network shareI *think* you might be able to remove the permission to list folder contents but retain read access. Try it out on a dummy folder first.

If your users have the rights to install applications, that implies that they have local administrator privileges. I *really* hope that's not the case.

As for users stealing apps, you could use one of the many device-disabling tools around to disabled USB and/or CD (or disable them manually and take away their admin rights!), or maybe have some sort of file access auditing going on.

there is an NTFS permission called "List Folder Contents", maybe you can disable that for the users.
by the description it shouldnt affect MSIs, but try at own risk!

Thank you for your replies, VBScab and weberik!

No, our users don't have local administrator privileges, although our PC-technicians have it, which is a part of the problem.
Instead of uninstalling/installing applications from our software deployment system, they simply use our SOURCELIST software repository to "quickly" fix problems with applications for our users, which in turn leads to the fact that we (MSI-packagers) never hear a thing about eventual problems with our packages and therefor never get the chance to fix them.

As for the stealing software part, I'm pretty sure our users wouldn't accept the solution of disabling USB/CD, although it seems like a nice feature [;)]

I found a post on Experts-Exchange regarding this;
"Well, for the users that you don't want to be able to see the contents of that share, all you need to do is add a "DENY LIST FOLDER/READ DATA" permission on the Advanced Security tab for that particular group of users. That won't stop programs from being installed because the SYSTEM profile is the one used to actually install the program" "Just make sure to also select "This Folder, Sub-Folders and Objects" "

but we couldn't get it to work. We created two groups, one for admin/management personnel, and one for our users with the "DENY LIST FOLDER/READ DATA" permission set. We also gave the computer we tested this things on permissions to the network share, but it didn't help.

I guess the problem is that I don't fully understand how MSI repairs is done, I thought MSI repairs was running under the Local System account, and not with the logged on users rights.
If I log the MSI repair using voicewarmup (in this case in a Active Setup scenario, StubPath=[SystemFolder]msiexec.exe /fvomus [ProductCode] /qb, for setting HKCU registry keys and put some files to the users AppDataFolder), I get the following information;
MSI (s) (48:94) [15:44:08:126]: SOURCEMGMT: Source is invalid due to missing/inaccessible package.
MSI (s) (48:94) [15:44:08:126]: SOURCEMGMT: Trying source \\FILESERVER\MSI$\PackageName.
MSI (s) (48:94) [15:44:08:236]: Note: 1: 2203 2: \\FILESERVER\MSI$\PackageName\MSI_File_Name.msi 3: -2147287035
MSI (s) (48:94) [15:44:08:236]: Note: 1: 1706 2: -2147483646 3: MSI_File_Name.msi
MSI (s) (48:94) [15:44:08:236]: SOURCEMGMT: Media Disabled for this package.
MSI (s) (48:94) [15:44:08:236]: SOURCEMGMT: Processing URL source list.
MSI (s) (48:94) [15:44:08:236]: Note: 1: 1402 2: UNKNOWN\URL 3: 2
MSI (s) (48:94) [15:44:08:236]: Note: 1: 1706 2: -2147483647 3: MSI_File_Name.msi
MSI (s) (48:94) [15:44:08:236]: Note: 1: 1706 2: 3: MSI_File_Name.msi
MSI (c) (20:C8) [15:44:08:236]: User policy value 'SearchOrder' is 'nmu'
MSI (c) (20:C8) [15:44:08:236]: User policy value 'DisableMedia' is 0
MSI (c) (20:C8) [15:44:08:236]: Machine policy value 'AllowLockdownMedia' is 0
MSI (c) (20:C8) [15:44:08:236]: SOURCEMGMT: Media enabled only if package is safe.
MSI (c) (20:C8) [15:44:08:236]: SOURCEMGMT: Prompting user for a valid source.

As far as I can see it tries to locate the \\FILESERVER\MSI$\PackageName as SYSTEM, and then switches to user, prompting for a valid source.
I thought that giving the computer permissions to a network share would also give the SYSTEM user permissions to it?

Any ideas?

Hi, and thanks for your replies!

We managed to solve it by denying the user LIST FOLDER.
The problem was that we didn't realize that Authenticated Users also includes computers, so one of the first things we did was to remove Authenticated Users from the NTFS file permissions to prevent them from seing the contents.
As soon as we realized that, it all worked!