Unable to push the Symantec Management Agent to Windows 10: Admin$ is denied
search cancel

Unable to push the Symantec Management Agent to Windows 10: Admin$ is denied


Article ID: 172842


Updated On:


IT Management Suite


The customer is unable to push the Symantec Management Agent (SMA) to computers in his environment.

Here is the process that they normally use to push the agent.

  1. Action>Agents/Plug-Ins>Push Symantec Management Agent
  2. Enter hostname of system
  3. Highlight the system and choose ‘Install’ accepting defaults (push is set to use the app identity service account)
  4. Lightning bolt appears over the ‘computer’ icon on the far-left column
  5. Process runs for about 10-15 seconds before failing. 

NS Log entry on the SMP indicates access to \\\Admin$ is denied.

You can duplicate the authentication failure when connecting via UNC to the path above (using the IP Address) but not when replacing with the hostname, like \\laptop-5488234\admin$


ITMS 8.x

Windows 10 systems that have been patched for the vulnerability noted in bulletin MS17-010 and received the accompanying GPO setting.


The issue is that the install process is dependent on access to Admin$ which is disallowed with the introduction to the fixes noted in MS17-010.

The customer found a Windows STIG/GPO setting that is being applied to Windows 10 systems. The STIG setting is a security requirement and will likely not be changed by the customer as it would introduce a vulnerability into their environment.

Network Security: Allow local system to use computer identity for NTLM. When configured, the agent push fails. If set to ‘not configured’ the agent push is able to copy the installer to Admin$ via IP address.

The customer found the specific setting in the client registry that allows the enum of Admin$:

System\CurrentControlSet\Services\LanmanServer\Parameters\smbservernamehardeninglevel (changed it from 1 to 0 and now works)

More information can be found here:  


The Symantec Management Agent push process depends on the ability to open remote admin share (Admin$) and open remote Service Control Manager. The Push process needs to copy the file to the remote machine and install the SMA installation service, which will pull the main binaries from the NS according to the transfer settings.
Since we do not change any security settings on the remote clients - any system setting or combination of settings/GPO's which are blocking abilities described above will also block the SMA push.

We can't do anything with the current design, all work as implemented.

For an alternative, another approach for pushing agents with SMB disabled we have NO solution at the moment. This requires a design change and hence an enhancement that needs to be prioritized by Product Management.