locked
DP deployment requires Admin$ access - any workaround? RRS feed

  • Question

  • hi, i am trying to deploy the standard DP to windows 7 machines but found out it requires admin$ access for DP installation and also package distribution. Anyone has experienced how to overcome this? As there is IT security policy restriction don't allow admin$ access on the client machines.

    I have tested to deploy Pull DP but it still requires admin$ access during the installation. Any possible way to perform manual installation rather than push from SCCM console?

    Really appreciate your help here.

    regards,

    ytlaw

    Friday, February 9, 2018 12:54 AM

Answers

  • That's what Nick was telling. You just need an account that is local admin on the remote DP. Either the account of the site server or an user account. There is no alternative.

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

    • Marked as answer by ytlaw Monday, February 12, 2018 11:55 PM
    Friday, February 9, 2018 6:51 AM
  • Currently, the Admin$ is required. The site uses that for checking permissions and for staging files (in the case of roles other than the DP).

    There is also currently no "supported" way to install roles offline. The roles would have to be installed by the site.

    If this is really blocking the deployment of SCCM roles in your environment, I suggest that you contact support. I believe that the fix is not trivial and will not happen quickly. So, you should instead get an exception from your security group and have them allow the Admin$ on SCCM remote roles.

    • Marked as answer by ytlaw Monday, February 12, 2018 11:54 PM
    Monday, February 12, 2018 9:58 PM

All replies

  • Your IT Security Policy won't allow you to add the site server computer account to local admins of the remote dp?
    Friday, February 9, 2018 3:47 AM
  • sorry, I am referring to admin$ share on the remote DP. not issue with the local admin rights.
    Friday, February 9, 2018 6:37 AM
  • That's what Nick was telling. You just need an account that is local admin on the remote DP. Either the account of the site server or an user account. There is no alternative.

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

    • Marked as answer by ytlaw Monday, February 12, 2018 11:55 PM
    Friday, February 9, 2018 6:51 AM
  • yes. it's already part of the local admin group but when deploy the DP via admin console, system trying to copy some installation files via admin$ share of the remote DP and this also happen when distribute the package. 

    Correction : as IT security policy, the admin$ share have been removed for all the windows 7 client machines.

    Friday, February 9, 2018 7:53 AM
  • Ultimately, it doesn't matter how or why.

    How exactly have you determined this to be a problem though?

    Have you reviewed the distmgr.log and pkhxfermgr.log?


    Jason | https://home.configmgrftw.com | @jasonsandys

    Saturday, February 10, 2018 3:17 PM
  • I think still the folder structure and component setup execution has to be done by the initial distmgr.log and pkhxfermgr.log copy, but you can install the DP manually using MSI file available during the content copy.. not sure whether the robo copy would work for you... it may be unsupported but if you get the content copied you can still run the install manually...

    Kamala kannan.c| Please remember to click “Mark as Answer” or Vote as Helpful if its helpful for you. |Disclaimer: This posting is provided with no warranties and confers no rights

    Sunday, February 11, 2018 3:34 AM
  • Yes. Based on the distmgr.log logs. Once removed the admin$ share it failed to install and also failed to dsitribute the packages.
    Sunday, February 11, 2018 8:12 AM
  • Currently, the Admin$ is required. The site uses that for checking permissions and for staging files (in the case of roles other than the DP).

    There is also currently no "supported" way to install roles offline. The roles would have to be installed by the site.

    If this is really blocking the deployment of SCCM roles in your environment, I suggest that you contact support. I believe that the fix is not trivial and will not happen quickly. So, you should instead get an exception from your security group and have them allow the Admin$ on SCCM remote roles.

    • Marked as answer by ytlaw Monday, February 12, 2018 11:54 PM
    Monday, February 12, 2018 9:58 PM
  • Microsoft should flag this in the technet website so that we didn't overlook this especially on deploying the role to client machines as most corporate blocking admin$ share due to recent ransomware, etc..

    Thank you for everyone contribute this post and I am now clear on this topic.

    Monday, February 12, 2018 11:54 PM
  • > "as most corporate blocking admin$ share due to recent ransomware, etc.."

    This is not correct and not preventative for ransomware. All admin shares like admin$ are restricted to use by local admins and only local admins -- this is not configurable either. If a user is a local admin on a system and is exposed to ransomware, then you've got bigger problems and the non-existence of an admin share is irrelevant. It also begs the question why any users would have local admin permissions on any servers? If that's the case, then you've got even larger issues ransomware or no ransomware.

    As for managed systems, this is not required. It is only required for client push. The admin$ is not required for normal client operations. If you choose to disable the admin shares on your managed systems, you'll simply need to choose an alternate method for deploying your client agents.


    Jason | https://home.configmgrftw.com | @jasonsandys


    Tuesday, February 13, 2018 12:34 AM