locked
UNC Share for Packages, OS files, etc: what share permissions? RRS feed

  • Question

  • We have created a folder on our primary site to store OS files, applications, drivers, etc. It needs to be made a share, but what permissions do we add to it? This is one of 2 primary sites in our hierarchy (which also obviously has a CAS). The files on it only apply to the clients reporting to it.

    Should I even be making my own folder or should I use SMSPKGD$?

    I had read elsewhere to give this share read access to everyone but that seems too liberal to me. Any pointers?

    Cheers,

    Bryan

    Friday, June 1, 2012 12:57 PM

Answers

  • No, SMSPKGx$ is *not* created for your use. You should always create your own source repository. Note that this does not have to be on any of your site servers, it is just a UNC afterall.

    As for permissions, don't confuse Share permissions with NTFS permissions. In general, it is a best practice to set the share permissions to either Everyone-Full or Everyone-Read only and allow NTFS to hande the granular control (pretty much what Jorgen pointed out).

    Thus, for the share, I always do as Jorgen did, Everyone-Full. For NTFS, I typically grant the server group Full because it needs to write for updates (alos pointed out by Jorgen) and drivers. Depending upon how you populate the application and package source directories, I also grant certain users permissions also to enable them to copy the source files in. I use this single share for other things also like captured images and MDT log files so aso typically grant the network access account permissions with full control opn a few select sub-directories.

    Finally, organize, organize, organize. Don't just dump everything in the directory. Use a well thought folder structure to maintain good control and knowlede of what everything is. I always have a "Content" directory that contains three levels of directories below it: Vendor, Product, Version. This eliminates ambiguity and allows for easy verification and cleanup.


    Jason | http://blog.configmgrftw.com | Twitter @JasonSandys

    • Marked as answer by BryanCP Friday, June 1, 2012 8:29 PM
    Friday, June 1, 2012 2:11 PM
  • You cannot create a share without assigning permissions too (well you can, but then it cannot be accessed at all). See http://msmvps.com/blogs/acefekay/archive/2011/02/04/share-permissions-and-ntfs-permissions-folder-access-control-amp-folder-permissions.aspx for details.
    The "effective permissions" are always a result of share AND NTFS permissions.


    Torsten Meringer | http://www.mssccmfaq.de

    • Marked as answer by BryanCP Tuesday, June 5, 2012 2:13 PM
    Tuesday, June 5, 2012 11:42 AM

All replies

  • Hi,

    For share permission I always grant everyone full control, then I use NTFS Security permissions to controll access.. I would create a n AD-group called ALL SCCM Servers, add you three SCCM Servers computer accounts (Primary+CAS) to that group and grant that group Full Controll or Modify permission in the direcotry, if you are going to use for instance Automatic Software Update rules the site server will need permissions to write to that directory as welll.

    Regards,
    Jörgen 


    -- My System Center blog ccmexec.com -- Twitter @ccmexec

    Friday, June 1, 2012 1:03 PM
  • Thanks for the info. Is SMSPKGD$ created for this purpose or do most people typically create their own share?
    Friday, June 1, 2012 1:31 PM
  • No, SMSPKGx$ is *not* created for your use. You should always create your own source repository. Note that this does not have to be on any of your site servers, it is just a UNC afterall.

    As for permissions, don't confuse Share permissions with NTFS permissions. In general, it is a best practice to set the share permissions to either Everyone-Full or Everyone-Read only and allow NTFS to hande the granular control (pretty much what Jorgen pointed out).

    Thus, for the share, I always do as Jorgen did, Everyone-Full. For NTFS, I typically grant the server group Full because it needs to write for updates (alos pointed out by Jorgen) and drivers. Depending upon how you populate the application and package source directories, I also grant certain users permissions also to enable them to copy the source files in. I use this single share for other things also like captured images and MDT log files so aso typically grant the network access account permissions with full control opn a few select sub-directories.

    Finally, organize, organize, organize. Don't just dump everything in the directory. Use a well thought folder structure to maintain good control and knowlede of what everything is. I always have a "Content" directory that contains three levels of directories below it: Vendor, Product, Version. This eliminates ambiguity and allows for easy verification and cleanup.


    Jason | http://blog.configmgrftw.com | Twitter @JasonSandys

    • Marked as answer by BryanCP Friday, June 1, 2012 8:29 PM
    Friday, June 1, 2012 2:11 PM
  • Jason, thanks for the great answer and clearing this up, and you too Jorgen!.
    Monday, June 4, 2012 11:25 AM
  • Oee other question that I am unclear on. If I am uncomfortable with actually giving all domain users read access to this share, is there a way around that? I don't want anybody to simply be able to copy some of these image and application files back to their local machine.
    Monday, June 4, 2012 5:55 PM
  • Clients will never see or touch the files that are stored in the source directory. The site server uses that directory to copy the files (packages, applications, etc) to the distribution points and clients will access or download them there.

    Torsten Meringer | http://www.mssccmfaq.de

    Monday, June 4, 2012 6:09 PM
  • I should have added more info about our scenario. I know clients won't access that. We have a lot of distributed IT folks at our University, who are not central IT. We are giving them the ability to add software and images as needed so I suppose it is unavoidable.

    Why is it needed in the first place to add the read privilege to everyone on the share? Why not just NTFS permissions to the servers and users who need to actually put or remove files in the share?


    • Edited by BryanCP Monday, June 4, 2012 6:16 PM
    Monday, June 4, 2012 6:15 PM
  • That's exactly what you do. Share permissions are a fact of life -- they are a separate and distinct set of permissions on the share itself. Without permissions to the share, you don't get to any files fronted by the share. Setting it to Everyone Full or Everyone Read keeps share permissions simple though. They don't override the NTFS permissions in any way so using the NTFS permissions to provide the "real" and granular permissions is the best practice.

    Jason | http://blog.configmgrftw.com | Twitter @JasonSandys

    Monday, June 4, 2012 6:30 PM
  • So it would be ok to create the share permission of everybody-read and then restrict some of the subfolders specifically if I don't want anyone getting to them?

    PS: Thanks everyone for their feedback! I am a client engineer guy mainly guy and not a Windows Server guy, hence the questions.


    • Edited by BryanCP Monday, June 4, 2012 6:34 PM
    Monday, June 4, 2012 6:33 PM
  • Only if no one will ever need to write to the "share". If anyone needs to write to the share, then set it to everyone-full.

    Just to reiterate, unless the user also has NTFS permissions, they won't be able to do anything to the files and folders fronted by the share.


    Jason | http://blog.configmgrftw.com | Twitter @JasonSandys

    Monday, June 4, 2012 6:35 PM
  • Last question (I hope): I think my hangup is why even bother with the share permissions? If we only need a subset of people to access some of the subfolders, why not just use NTFS to assign those rights in addition to the machine group having full control of the parent folder?

    My testing is not showing what you said (and user error is a possible cause). I gave everyone full share rights and could copy files with another account up despite there being no specific NTFS permissions to do so.

    Is this the correct way to do this? In the example everyone is set to read only...


    • Edited by BryanCP Tuesday, June 5, 2012 11:43 AM
    Tuesday, June 5, 2012 11:21 AM
  • You cannot create a share without assigning permissions too (well you can, but then it cannot be accessed at all). See http://msmvps.com/blogs/acefekay/archive/2011/02/04/share-permissions-and-ntfs-permissions-folder-access-control-amp-folder-permissions.aspx for details.
    The "effective permissions" are always a result of share AND NTFS permissions.


    Torsten Meringer | http://www.mssccmfaq.de

    • Marked as answer by BryanCP Tuesday, June 5, 2012 2:13 PM
    Tuesday, June 5, 2012 11:42 AM
  • One of out Sysadmins helped me get our share set up correctly. I understand the concept but the implementation was hard for me to wrap my head around. It made me feel better when he told me I would not get this in one day. :)

    Thanks everyone for your help.

    Cheers,

    Bryan

    Tuesday, June 5, 2012 2:14 PM