locked
Have to change Site share permissions to allow client push? RRS feed

  • Question

  • I've been experiencing a tremendous number of issues with client push, most of which seem to be resolved now (for anyone else reading this: using ccmsetup.exe flags in the Client Push properties under Client Installation Methods in the Admin console doesn't work - this is only documented in a footnote on a technet page.  Use the MSI flags instead.).  But one of the main problems I had was that unmodified site share permissions wouldn't allow the client setup app to download.  My logs were filled with client push install jobs that were failing.

    I found this thread - http://social.technet.microsoft.com/Forums/en-US/configmgrsetup/thread/78345405-4e92-4f25-820d-32df8b37307d - where the poster reported success after setting the Everyone share permission to read, and the NTFS permissions to read/execute under the site directory (c:\program files\Microsoft Configuration Manager\).  I did the same out of curiosity, and sure enough every client was installing with *zero* failures.

    I saw Wally's response that this shouldn't be necessary, and I agree.  It's far too open.  However I'm curious what the recommendation would be to achieve the same without such open permissions?  He mentioned using the /noservice flag, but that's only for ccmsetup.exe .  My client can't push the exe by GPO or script (and they can't install manually), they have to use the SCCM console which only accepts the MSI flags.  So how does one go about accomplishing the same here, or perhaps a better question would be what permissions can/should be assigned to the directories (even just the client directory) to allow a successful install?

    Thanks & Cheers -

    Tuesday, May 12, 2009 11:40 PM

Answers

  • From what I understand, the CCM_Client IIS virtual directory should give IUSR (Anonymous Authentication) read access to the share, so a domain joined machine should have access to it, unless the IIS account(s) were changed. I am not an IIS pro, but my guess is something in IIS may be causing the issue and a work around is just to change the share permissions to everyone, but if IIS is configured corretly than that permission level should not be needed.
    Wil
    Friday, July 10, 2009 9:23 PM

All replies

  • Bump?  Anyone have any suggestions about this?
    Wednesday, May 20, 2009 7:37 PM
  • I have just been reading that previous thread and i too find it confusing as to what the "Official Reccomendation" is to solve this issue without giving too much permission out.
    Wednesday, May 20, 2009 7:44 PM
  • Bump again - Any ideas? 

    Pete - What are your default site share permissions?  Ours are:

    LocalSvr\Administrators - Full
    LocalSvr\SMS_SiteSystemToSiteServerConnection_(sitecode) - Change/Read
    LocalSvr\SMS_SiteToSiteConnection_(Sitecode) - Change/Read

    Thats it from a fresh install - and I confirmed this in a lab deployment for a third time.  We had to add Domain Users, Domain Admins, and Domain Computers.  DA's have full control, Domain Computers and Domain Users have read only.  But we had to apply this to the Program Files\Microsoft Configuration Manager directory (aka the \\SCCMSERVER\SMS_(Sitecode share).  Otherwise clients tried to open the \\SCCMSERVER\SMS_(sitecode)\Client share, and if we had only changed permissions on the client share, they couldn't reach it.

    Happy holidays -
    Friday, May 22, 2009 11:00 PM
  • post holiday bump.
    Wednesday, May 27, 2009 12:42 AM
  • From what I understand, the CCM_Client IIS virtual directory should give IUSR (Anonymous Authentication) read access to the share, so a domain joined machine should have access to it, unless the IIS account(s) were changed. I am not an IIS pro, but my guess is something in IIS may be causing the issue and a work around is just to change the share permissions to everyone, but if IIS is configured corretly than that permission level should not be needed.
    Wil
    Friday, July 10, 2009 9:23 PM