Access Shared Folder Troubleshooting

When adding Windows remote hosts to an Agentless Data Collector, you may encounter the error: Failed to access the shared folder on Agentless Data Collector from the remote host. This article outlines the key troubleshooting steps to resolve this error.

Shared Folder Access Error

When the remote Windows host cannot access the shared folder in the Agentless Data Collector machine, the following message will appear in the following format in Cloudamize ADC output:

Failed to access the shared folder on Agentless Data Collector from the remote host

Troubleshooting steps-

Step 1: Authentication & Manual Connectivity

Before diving into protocol configurations, verify that the basic network path and credentials are functional.

• Credential Matching: You must log in to the target machine using the same User ID and Password that you provided in the ADC configuration to add that machine.

• Manual Access Test: From the target machine, open File Explorer and attempt to browse to the ADC share manually: \\<ADC_IP_Address>\C\\ProgramData\CloudamizeAgentlessDc\HOST_SHARE

• Identify the Error Type: * Access Denied: Usually indicates a credential mismatch, a locked account, or insufficient NTFS/Share permissions.

  • Network Related Error (e.g., "Network Path Not Found"): Usually indicates a firewall blockage, the "Client for Microsoft Networks" being disabled, or an SMB protocol mismatch.

Note: If you encounter either of these errors during the manual test, you must resolve them using before the ADC can successfully scan the host.

Step 2: Share Permissions:

1. Navigate to C:\ProgramData\CloudamizeAgentlessDc\HOST_SHARE.

2. Right-click > Properties > Sharing tab > Advanced Sharing > Permissions.

3. Add Everyone and ensure they have appropriate access.

Step 3: Phase 3: SMB Protocol Alignment

If the network path is not found, there is likely an SMB version mismatch.

Scenario A: Enable SMBv2 on Remote Host (Best Practice)

Use these commands if the remote host is outdated but supports SMBv2.

Scenario B: Enable SMBv1 on ADC Machine (Legacy Support)

Use these only if the remote host is very old (e.g., Windows Server 2003) and cannot use SMBv2.

• Win Server 2012+: Set-SmbServerConfiguration -EnableSMB1Protocol $true

• Win Server 2008 R2 & Below: Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters" SMB1 -Type DWORD -Value 1 -Force
  

Step 4: NTLM & Security Policies

If credentials are correct but access is still denied, NTLM traffic may be restricted.

1. On the Remote Host (Outgoing):

   • Go to Local Security Policy > Local Policies > Security Options.

   • Set Network Security: Restrict NTLM: Outgoing NTLM traffic to remote servers to Allow all.

2. On the ADC Machine (Incoming):

   • Go to Local Security Policy > Local Policies > Security Options.

   • Set Network Security: Restrict NTLM: Incoming NTLM traffic to Allow all.
     

Step 5: From the ADC machine, run the following in PowerShell:

1. Get-WmiObject -Class Win32_OperatingSystem -ComputerName <IP address> -Credential (Get-Credential)

   1. Note: When prompted for credentials, please ensure that you include the domain when specifying the user.

   2. This command should succeed and print out some information about the remote machine. Please take a screenshot of the output and provide it to us.

2. Invoke-WmiMethod -Class Win32_Process -Name Create -ArgumentList "cmd.exe /c echo hello" -ComputerName <Ip address> -Credential (Get-Credential)
   If the command is executed successfully, it should print out information like the process ID and return value (which would be 0 on success, 2 would be AccessDenied). Please take a screenshot of the output and provide it to us.

Step 6: Review DCOM Permissions.

The user account used by the Cloudamize ADC to connect to the remote server needs specific DCOM permissions.

1. On the remote host, run dcomcnfg to open Component Services.

2. Navigate to Computers -> My Computer, right-click, and select Properties.

3. Go to the COM Security tab.

4. Under "Access Permissions" and "Launch and Activation Permissions," ensure the account has "Remote Access" and "Remote Launch and Activation" rights.

Step 7: Review WMI security permissions.

a. On the remote host, run wmimgmt.msc
b. Right-click “WMI Control” and select “Properties”
c. Navigate to “Security Tab”
d. Select CIMV2 and Click Security
e. Ensure the account (or its group) has all the permissions (Except Special Permissions may be unchecked)

It may also be helpful to check the EventViewer on the target machine for any entries related to WMI, DCOM, or logon failures. In addition, under Microsoft->Windows->WMI-Activity, there is an “Operational” log that can be utilised to check for errors around the execution time. The log might need to be enabled to collect events.

Step 8: Review Group Policy Objects (GPOs).

If you apply the manual fixes and they do not work or if they revert back, it is likely a Domain GPO overriding your changes.

Check for Overriding Policies:

1. On the target machine, run rsop.msc (Resultant Set of Policy) or gpresult /h report.html to see which policies are actually being applied by the Domain Controller.

2. Verify SMB Restrictions: Ensure no GPO is disabling SMBv2 or forcing "Digitally sign communications (always)" which can interfere with older agents.

3. Verify NTLM Restrictions: Check Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options. Ensure no GPO is set to "Deny all" for NTLM traffic.

4. Verify Firewall GPOs: Ensure a Domain-level firewall policy isn't blocking Inbound Port 445, even if the local firewall shows it as open.

Step 9: Review Server Hardening.

Hardening benchmarks (like CIS or NIST) often disable legacy communication methods. Check these specific settings if the manual access test fails.

1. SMB Packet Signing: Hardened environments often require SMB Packet Signing. If the ADC and target machine have mismatched signing requirements (e.g., one requires it, the other has it disabled), the connection will drop.

   • Check: Local Security Policy > Local Policies > Security Options > Microsoft network server: Digitally sign communications (always).

2. LAN Manager Authentication Level: If the hardening policy is set to "Send NTLMv2 response only. Refuse LM & NTLM," it may block the ADC if it uses an older authentication handshake.

   • Check: Local Security Policy > Local Policies > Security Options > Network security: LAN Manager authentication level.

3. UAC Restrictions (Remote Restrictions): By default, Windows restricts local administrative accounts from connecting via SMB. If the target machine is being accessed via a hostname and you are not using the built-in "Administrator" account (but rather another account that belongs to the Administrators group), remote access will be denied due to Remote UAC.
   

   Note: Disabling Remote UAC is not recommended for security reasons. However, if it is necessary for the ADC to function, you must set the following registry entry to 1. If the entry does not exist, you must create it:
   

   • Fix: Ensure the LocalAccountTokenFilterPolicy registry key is set to 1 if using a local admin account.

Step 10: Additional key instructions for the shared folder access issue:

• Go to the remote host via Remote Desktop Connection using the account provided by the customer in ADC UI.

• Run Command Prompt. Don’t run it as Administrator.

• Run the following command

• NET USE \\ADC_ip_address\Cloudamize_HOST_SHARE /user:ADC_host_name\CloudamizeAgentless "Password for the account CloudamizeAgentless"

  • E.g., NET USE \\10.0.0.10\Cloudamize_HOST_SHARE /user:MYADC\CloudamizeAgentless "myPassword"

• Please send us the output of the command above.

• To retrieve the password for the CloudamizeAgentless account, run CloudamizeRetrieval.exe as Administrator on Command Prompt in the ADC machine. The customer needs both files (CloudamizeRetrieval.exe and Utility.dll).
  

CloudamizeRetrieval.exe Utility.dll

If the issue persists, please capture a screenshot of the error outputs requested and collect the log_backup.txt file from the following directory on the Cloudamize Agentless DC:

C:\Program Files (x86)\CloudamizeAgentlessDc\log_backup.txt

Please attach both the screenshot and the log file in an email to helpdesk@cloudamize.com for further investigation.