Solved

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

Posted on 2010-08-26
15
2,727 Views
Last Modified: 2013-12-04
Hi experts.

To say it with Microsoft:
Symptoms
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?
0
Comment
Question by:McKnife
  • 7
  • 5
  • 3
15 Comments
 
LVL 12

Expert Comment

by:Rant32
Comment Utility
>  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?
0
 
LVL 53

Author Comment

by:McKnife
Comment Utility
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.
0
 
LVL 12

Accepted Solution

by:
Rant32 earned 500 total points
Comment Utility
I was wrong about the write access, but after some more searching, this seems to be an explanation: http://support.microsoft.com/kb/889710

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:
http://www.experts-exchange.com/OS/Microsoft_Operating_Systems/Server/Windows_Server_2008/Q_25085430.html


I actually lol'd at "Consider the following scenario".
Thanks.
0
 
LVL 53

Author Comment

by:McKnife
Comment Utility
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'?
0
 
LVL 12

Expert Comment

by:Rant32
Comment Utility
"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.
0
 
LVL 12

Expert Comment

by:Rant32
Comment Utility
I actually hadn't read your response yet, obviously :)
0
 
LVL 53

Author Comment

by:McKnife
Comment Utility
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...
0
Free Gift Card with Acronis Backup Purchase!

Backup any data in any location: local and remote systems, physical and virtual servers, private and public clouds, Macs and PCs, tablets and mobile devices, & more! For limited time only, buy any Acronis backup products and get a FREE Amazon/Best Buy gift card worth up to $200!

 
LVL 12

Expert Comment

by:Rant32
Comment Utility
There is exactly the same discussion going on here (but it's in German)
http://www.administrator.de/MSI_Paket_aus_Netlogon-Verzeichnis_nicht_ausf%C3%BChrbar.html

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?
0
 
LVL 53

Author Comment

by:McKnife
Comment Utility
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: http://www.google.de/search?hl=de&rls=com.microsoft%3Aen-us&q=%22This+installation+package+could+not+be+opened.+Verify+that+the+package+exists+and+that+you+can+access+it+site%3Amicrosoft.com+netlogon&aq=f&aqi=&aql=&oq=&gs_rfai= first hit. Normally I would have googled.
0
 

Expert Comment

by:Rbln773
Comment Utility
On your WIndows 2008 Domain controller
Open GPMC.MSC
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)
0
 
LVL 53

Author Comment

by:McKnife
Comment Utility
Hi Rbln773.

The (2-year-old) problem has been explained and solved, what's your intent?
0
 

Expert Comment

by:Rbln773
Comment Utility
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.  

Thanks
0
 
LVL 53

Author Comment

by:McKnife
Comment Utility
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.
0
 

Expert Comment

by:Rbln773
Comment Utility
Really?

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.
0
 
LVL 53

Author Comment

by:McKnife
Comment Utility
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.
0

Featured Post

IT, Stop Being Called Into Every Meeting

Highfive is so simple that setting up every meeting room takes just minutes and every employee will be able to start or join a call from any room with ease. Never be called into a meeting just to get it started again. This is how video conferencing should work!

Join & Write a Comment

SHARE your personal details only on a NEED to basis. Take CHARGE and SECURE your IDENTITY. How do I then PROTECT myself and stay in charge of my own Personal details (and) - MY own WAY...
No security measures warrant 100% as a "silver bullet". The truth is we also cannot assume anything but a defensive and vigilance posture. Adopt no trust by default and reveal in assumption. Only assume anonymity or invisibility in the reverse. Safe…
This tutorial will walk an individual through the process of transferring the five major, necessary Active Directory Roles, commonly referred to as the FSMO roles from a Windows Server 2008 domain controller to a Windows Server 2012 domain controlle…
This tutorial will walk an individual through the process of transferring the five major, necessary Active Directory Roles, commonly referred to as the FSMO roles to another domain controller. Log onto the new domain controller with a user account t…

772 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

14 Experts available now in Live!

Get 1:1 Help Now