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?
LVL 58
Who is Participating?
Rant32Connect With a Mentor Commented:
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".
>  It's no permission problem, because permissions are bound to users, not OS' or computers.
That depends.

MsiExec can run as an another user, or elevated user (or maybe in this case, LocalSystem) and then msiexec will authenticate itself using the local computer account, not the user running the msi. The process is then not a member of the domain-local Administrators. IIRC, the Administrators group alone has write access to NETLOGON.

Maybe this behaviour for MsiExec is different in XP than Vista/7, but I don't know off the top of my head.

Did you get a look at what user the MsiExec process was running as on different systems?
McKnifeAuthor Commented:
Before we start discussing that - what should write permissions be good for here? An msi never extracts to its origin.
But anyway, it is the same user. I can even take a new share and use the same permissions for NTFS and share permissions - it will work. Netlogon however won't.
Easily Design & Build Your Next Website

Squarespace’s all-in-one platform gives you everything you need to express yourself creatively online, whether it is with a domain, website, or online store. Get started with your free trial today, and when ready, take 10% off your first purchase with offer code 'EXPERTS'.

McKnifeAuthor Commented:
Excellent, one step further. But - how can vista or 7 circumvent that SHI1005_FLAGS_RESTRICT_EXCLUSIVE_OPENS attribute? Shouldn't it be restricted for all OS'?
"Does not support" was a bit strong, the article says "by default".

And also, there is still the difference between the client OS. Are there different versions of Windows Installer involved? The most recent downloadable version of Installer is 4.5 for XP/2003 (Vista?), but my Win7 pc has version 5.0. Maybe Win7 doesn't need that exclusive access.
I actually hadn't read your response yet, obviously :)
McKnifeAuthor Commented:
Vista has 4.5 installed, just like xp. Win7 started with v5, right. So the installers on xp and vista are the same - at least the versions...
There is exactly the same discussion going on here (but it's in German)

I couldn't find anything else related, but it seems like behaviour by design if someone else has noticed.

It's interesting, but nevertheless... The KB article explicitly states "We recommend that you do not use the Sysvol folder as an installation point for programs."

Regardless of sheer curiosity... A separate share is a better solution than fixing this error. Do you agree?
McKnifeAuthor Commented:
I do agree. By the way, that german thread inspired me to start this one.
Too bad we cannot win insight on what xp needs this exclusive access for and vista/7 don't.

I will leave this open for a day or so. Thank you.

PS: first hit. Normally I would have googled.
On your WIndows 2008 Domain controller
Edit your Default Domain Controllers Policy
Expand Computer Configuration\Windows Settings\Administrative Templates\System\Netlogon
Change the Netlogon and Sysvol Compatibility to enabled (2 seperate settings)
McKnifeAuthor Commented:
Hi Rbln773.

The (2-year-old) problem has been explained and solved, what's your intent?
The resolution I posted was intended for 2 purposes.

1) when someone searches they can look at this thread and see that there is an actual resolution, and not a Microsoft Recommendation that you not use the Sysvol Folder.

2) Having worked for Microsoft for 10 years, I know that Sysvol and Netlogon are actually supposed to be used for software installation.  Which is why there is an application folder under each section of the group policy under sysvol.

Windows 2008 R2 blocks XP from installing from Sysvol or Netlogon by default.   There is a policy that allows it to function like Windows 2003.   The company that I am working with now is just now converting from Windows 2003 and Windows XP.  We have new builds of XP that can no longer get software distribution policies.  So I searched.  I found this article and wasn't satisfied the answer, because I really didn't want to move my install files that had been working with XP and 2003 and work with 2008 R2 and Windows 7.  Low an behold I found the answer the the problem, and posted it.  

Now my XP boxes get their software just the way they always did.  

McKnifeAuthor Commented:
I see and fully acknowledge your reasons. But what's still missing is: what drawback has this compatibility mode you are suggesting? There has to be one.

Ok lets see

1) Sysvol itself was designed at least in part to deploy software through group policy. (on stop shop since Windows 2000)
2) Windows 2008 broke XP but works fine with Windows 7 and Vista (per design?)
3) Setting the GP allows both to work.

Now Microsoft wants to sell it's latest O/S which is fully compatible with Windows vista/7 so if they tie in a couple of little things (annoyances) that break functionality in XP well you can draw your own conclusion.  But rather than lose sales of their Servers theyadded a switch to allow backwards compatibility.  

I have yet to experience a drawback to making this operational for Windows XP, as a matter of fact, it actually processes faster than 2003 systems.   No errors in any of the event logs, and when I am ready and fully converted to Windows 7 I can turn it back off, and go on with life.
McKnifeAuthor Commented:
Nevermind, I'll name it myself.
See the description of the sysvol share policy:
Note: the sysvol share is a share created by the net logon service for use by group policy clients in the domain. The default behavior of the sysvol share ensures that no application with only read permission to files on the sysvol share can lock the files by requesting exclusive read access, which might prevent group policy settings from being updated on clients in the domain. When this setting is enabled, an application that relies on the ability to lock files on the sysvol share with only read permission will be able to deny group policy clients from reading the files, and in general the availability of the sysvol share on the domain will be decreased.

if you enable this policy setting, domain administrators should ensure that the only applications using the exclusive read capability in the domain are those approved by the administrator.

They don't change the behavior for better selling their OS, you can't be serious. They adjusted this to improve the availability of that shares because those cannot be changed, while the source for MSIs can be any other share.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.