Question : Security phenomenon: xp clients cannot install .msi packages from \\2008r2\netlogon

Hi experts.

To say it with Microsoft:
Consider the following scenario: You are logged on to an xp sp3 client that is member of a 2008 R2 domain with a domain account that belongs to the local group administrators. You try to launch an .msi installation via network, the package is located at the netlogon share (or any folder below it) of your DC, a windows server 2008 R2. Immediately you get the error message "This installation package could not be opened. Verify that the package exists and that you can access it". To your surprise, using the same account on a windows 7 or vista domain member, you cannot reproduce this behavior. Any xp client is affected. Furthermore, ANY xp client CAN succesfully install the same package from ANY other share of that server.
Cause: ?
Resolution: ?

I read about this problem in another forum, and tried to figure it out after I made sure I could reproduce it with any xp client and any package I could find. I started procmon on xp and I found
msiexec.exe 4032 LockFile \\dc08r2\NETLOGON\test.msi ACCESS DENIED Exclusive: True, Offset: 2,147,483,538, Length: 1, Fail Immediately: True
So what do have here? It's no permission problem, because permissions are bound to users, not OS' or computers. Also there is no security software involved.

What is that netlogon share capable of that I never heard of before?

Answer : Security phenomenon: xp clients cannot install .msi packages from \\2008r2\netlogon

I was wrong about the write access, but after some more searching, this seems to be an explanation:

MsiExec doesn't require write access, but it does require exclusive access (as you can see from the logs). The NETLOGON share does not support exclusive access.

Are you trying to set up a distribution share for MSI packages? Why not create a separate DFSR group for it to have it replicate, and access your packages from there?

That was also the solution here:

I actually lol'd at "Consider the following scenario".
Random Solutions  
programming4us programming4us