System Center Configuration Manager Feedback

Suggestion box powered by UserVoice

How can we improve Configuration Manager?

Manage access accounts globally for the remote content library feature to work - 1806

With the new feature of having a remote content library for the primary site (a prerequisite for HA ability), there is an issue with the access permissions set on the remote content library.

During the process of adding a new application/package/driver/bootimage/etc, configmgr creates all the necessary files and folders in its own content library, however on one particular file structure for each package, it takes off inheritance of permissions and adds only the storage servers: 'users' and 'administrators' group.

This causes issues when the storage is hosted remotely and the primary site computer account is not a member of the storage local groups (in the case of using Linux boxes hosting NetApp storage, they don't even have groups).

This is currently controlled PER app/package/driver etc, by using the ribbon and selecting 'Manage Access Accounts' and then you can add in an AD group containing your primary site computer account. But this cannot be set globally for SCCM. This essentially renders the remote content library useless on a large scale.

Suggestion is to fix the access accounts to automatically include the primary site server, or allow the setting globally for all objects somewhere in security.

61 votes
Sign in
Sign in with: Facebook Google
Signed in as (Sign out)
You have left! (?) (thinking…)
Mitch Tamsett shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →


Sign in
Sign in with: Facebook Google
Signed in as (Sign out)
  • Doug Varner commented  ·   ·  Flag as inappropriate

    This requirement also creates a potential security risk. If the site server is granted administrator rights to the network storage resource, and the organization is using that network storage resource for multiple shares, an individual that is an admin on the site server could elevate to the system account and then have access to other data on the shared network storage device.

  • Robert Spinelli commented  ·   ·  Flag as inappropriate

    We saw this issue in our lab this week and now we are full halt for our PROD deployment.

    We're going to take a beating from upper management about this since they have been wanting this years, and we told them its finally available, We now need to go back to them and tell them, yeah sorry it's not.

    I only had 1 vote left, if I could take all my other votes back I would throw them at this. I got to say MS, you don't make it easy for us.

  • Gary Cassidy commented  ·   ·  Flag as inappropriate

    I have come across this situation today after moving the content library in 1810 to a Windows SMB file share. Luckily I can set the permissions as required on the Windows box, but this will be an issue for some SANs. I have implemented this only in a DEV environment so far, but I may have to modify my design for production which will use a SAN.

    When adding content or updating DPs with updated content the Distribution Manager log lit up in red when trying to remove old folders from the previous source version. Lots of log entries that began with 'RemoveDirectoryW failed (0x80070005)' appear as the site server no longer have permissions on its own remote content library.

    I agree with Mitch that setting the 'Manage Access Accounts' for each content type would be an unworkable approach to this problem.

    Please can this be looked at?

    I have also submitted feedback from the SCCM console.

Feedback and Knowledge Base