• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 719
  • Last Modified:

Share Permission Issue on Windows Server 2003 Appliance Edt, How can I fix the access to the \\computername\ADMIN$ share?

good day everyone,

i have a DELL power vault 745n that has windows server 2003 appliance edition installed on it. i made this server an app server, one of the application i installed is BitDefender SBS Edition. When i go to deploy the agent to workstations i get a message that is similar to the pic attached. to that end when i test the access permissions on the server i am met with the "No Network provider accepted the given network path" message.

I'm gathering my AV issue is due to some policy or permission issue on this box, hopefully someone has seen this before and can help point me in the right direction to solving this matter. any help on this would be deeply appreciated. thank you all. (see attached screenshot) Screenshot of admin$ share message
0
GridLock137
Asked:
GridLock137
  • 8
  • 3
  • 2
  • +1
1 Solution
 
vaska94Commented:
I hade same thing... this is client side problem, run “sfc /scannow” may be able to solve the problem.
0
 
BDoellefeldCommented:
My understanding is that edition is meant to be a NAS. It might not have a admin$ share, have you verified it exists by looking at the shares?

You could attempt to create (recreate) the admin$ share: http://support.microsoft.com/kb/816113
0
 
GridLock137Author Commented:
I will attempt to recreate it, i definitely verified that the shares exists and the path is there as well which leads to c:\Windows. I'll recreate and post results.
0
Fill in the form and get your FREE NFR key NOW!

Veeam is happy to provide a FREE NFR server license to certified engineers, trainers, and bloggers.  It allows for the non‑production use of Veeam Agent for Microsoft Windows. This license is valid for five workstations and two servers.

 
GridLock137Author Commented:
hey guys, the recreation of the share did not work, i'm still getting the same message, this is everything i have verified so far:


* Check DNS settings
Incorrect DNS settings are the most common cause of this problem. Use the ping -a command to confirm name resolution and to confirm the accuracy of the DNS suffix.

* Check environmental variables
Confirm that the correct shares are set up on the target computer.

To confirm and set up shares
At a command prompt, type the following command:

net share

If you do not see the ADMIN$ and <OS Drive>$ shares, create them.
To create the shares, type the following commands:

net share ADMIN$
net share C$=C:\

* Check Distributed COM properties
Incorrect Distributed COM properties can cause this problem.

To confirm Distributed COM properties
On the Windows taskbar, click Start > Run.
In the Open box, type the following text:

dcomcnfg

Click OK.

Do one of the following, depending on your version of Windows:

In Windows XP/2003, click Component Services > Computers > My Computer. Then right-click My Computer and click Properties.
In all other versions of Windows, go on to the next step.
On the Default Security or Default COM Security tab, under Default Access Permissions, click Edit Default.
The resultant window is normally blank. If it is not blank, then confirm that Administrators, Interactive, and System accounts are set to Allow Access, and then click OK.
Under Default Launch Permissions, click Edit Default.
Confirm that the Administrators, Interactive, and System accounts are set to Allow Launch, and click OK.
Do one of the following, depending on your version of Windows:
In Windows XP/2003, skip the two following steps.
In all other versions of Windows, go on to the next step.
In the Default Configuration Permissions section, click Edit Default.
In the Registry Key Permissions window, confirm that the following are set to Full Control, and then click OK:

CREATOR OWNER
...\Administrators
SYSTEM
0
 
joerghermannsCommented:
Can you check the following registry key on the target machines:

Hive: HKEY_LOCAL_MACHINE Key: SYSTEM\CurrentControlSet\Services\LanManServer\Parameters Name: AutoShareWks Data

if it is a server OS

Hive: HKEY_LOCAL_MACHINE Key: SYSTEM\CurrentControlSet\Services\LanManServer\Parameters Name: AutoShareServer Data

The value should be 1 - if not change it - and reboot
0
 
GridLock137Author Commented:
joerghermanns:


I navigated to that location on the server via regedit and I do not have an AutoShareServer Data entry. Laso, the LanManServer folder is in all lower case, does it matter?
0
 
GridLock137Author Commented:
sorry about the typo up top I meant to type Also, not Laso.
0
 
joerghermannsCommented:
Strange ... what entries do you have under "Lanmanserver\Parameters" ?
0
 
joerghermannsCommented:
just to make sure: the problem occurs on the clients, right?
so you will have to lookup the entry on the clients!
also check if any type of client firewall ist active!
0
 
GridLock137Author Commented:
No only on the server, the problem is the AV application accessing the ADMIN$ share or c:\windows directory. i will check the parameters and post asap.
0
 
GridLock137Author Commented:
currently i have on the server:

adjustednullsessionpipes
autodisconnect
disabledownleveltimewarp
enableforcedlogoff
enablesecuritysignature
guid
irpstacksize
lmannounce
nullsessionpipes
nullsessionshares
requiresecuritysignatures
restrictnullsessaccess
servicedll
size

these are the only one in there, the one mentioned ealier is not in that folder.
0
 
GridLock137Author Commented:
This qiestion is being closed, the problem resided in the version of OS i was using on the NAS server. the NAS server is not meant to be used for aplications but as a storage device. thank you all for your help.
0
 
BDoellefeldCommented:
Hello, my reply to this question matches the final conclusion.

That this edition was intended to be used as a NAS, but that you could attempt a unsupported method to get the result.
0
 
GridLock137Author Commented:
agreed, i did not look at previous post by you. thank you, you are absolutely correct about that version
0

Featured Post

Threat Trends for MSPs to Watch

See the findings.
Despite its humble beginnings, phishing has come a long way since those first crudely constructed emails. Today, phishing sites can appear and disappear in the length of a coffee break, and it takes more than a little know-how to keep your clients secure.

  • 8
  • 3
  • 2
  • +1
Tackle projects and never again get stuck behind a technical roadblock.
Join Now