Network access of C$
Accessing C$ on the network:
I have various reasons for needing to do this.
One has to do with testing / confirming / troubleshooting access from monitoring "server workstations" using things like EventLog Analyzer and GFI Languard.
Here is the situation:
Each computer is on a peer-to-peer network and has a common Admin1 User/Password. The server workstation is logged in with that User.
Using UAC \\[target_ipaddress]\C$ from the server workstation generally works.
But, on some target workstations it does not.
So, the task is to resolve the failures and turn them into successes.
Since all of these workstations have been treated fairly equally regarding file sharing, firewall settings, services, etc. it's surprising when failures occur. and I'm hard pressed to find a solution.
I keep asking myself "what's different?" and, while willing, end up searching rather involved descriptions of things that I probably don't need to investigate in such detail.
There are other aspects but to be fair to the Experts, I'll ask them separately.
But, in this case I'll add that the workstations are in 3 subnets each in workgroups named identically WORKGROUP - routed together with no NetBIOS traffic allowed; there is no inter-subnet name service.
Yet, the services I'm trying to troubleshoot DO work across all 3 subnets - just not in every target computer.
(In some cases I'm sure that the checklist of things to "fix" to get the monitoring to work is bigger than it needs to be. So, I may be tilting at windmills in some cases...).
I can confirm using UAC in RUN: \\target-ipaddress\C$ that targets in all 3 subnets CAN have C$ accessed from the server workstation without having to provide credentials
And, I can confirm that SOME targets pop up a security login dialog (which would prevent automated remote monitoring). With these, I can gain access using: Administrator as the User but that would not be the intent - just a demo of what seems to be expected.
And, I can confirm that SOME targets pop up a message that says \\target-ipaddress\C$ is not accessible.
I can also confirm that while RUN \\target-ipaddress\C$ will sometimes say "path not found" and yet, \\target-ipaddress will work. Once that works, if the Windows Explorer address is changed to append \C$, then it works. And, it appears it will work thereafter.... but that's another demo.
I have various reasons for needing to do this.
One has to do with testing / confirming / troubleshooting access from monitoring "server workstations" using things like EventLog Analyzer and GFI Languard.
Here is the situation:
Each computer is on a peer-to-peer network and has a common Admin1 User/Password. The server workstation is logged in with that User.
Using UAC \\[target_ipaddress]\C$ from the server workstation generally works.
But, on some target workstations it does not.
So, the task is to resolve the failures and turn them into successes.
Since all of these workstations have been treated fairly equally regarding file sharing, firewall settings, services, etc. it's surprising when failures occur. and I'm hard pressed to find a solution.
I keep asking myself "what's different?" and, while willing, end up searching rather involved descriptions of things that I probably don't need to investigate in such detail.
There are other aspects but to be fair to the Experts, I'll ask them separately.
But, in this case I'll add that the workstations are in 3 subnets each in workgroups named identically WORKGROUP - routed together with no NetBIOS traffic allowed; there is no inter-subnet name service.
Yet, the services I'm trying to troubleshoot DO work across all 3 subnets - just not in every target computer.
(In some cases I'm sure that the checklist of things to "fix" to get the monitoring to work is bigger than it needs to be. So, I may be tilting at windmills in some cases...).
I can confirm using UAC in RUN: \\target-ipaddress\C$ that targets in all 3 subnets CAN have C$ accessed from the server workstation without having to provide credentials
And, I can confirm that SOME targets pop up a security login dialog (which would prevent automated remote monitoring). With these, I can gain access using: Administrator as the User but that would not be the intent - just a demo of what seems to be expected.
And, I can confirm that SOME targets pop up a message that says \\target-ipaddress\C$ is not accessible.
I can also confirm that while RUN \\target-ipaddress\C$ will sometimes say "path not found" and yet, \\target-ipaddress will work. Once that works, if the Windows Explorer address is changed to append \C$, then it works. And, it appears it will work thereafter.... but that's another demo.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Ron Malmsead:
I'm not sure what state that puts the client computer in and I should know that much at least.
And, I'm not sure this is a permanent solution because it would not appear to survive a reboot, right?
I'm needing to change the permanent state of the targets because the access is needed for an automated processes from EventLog Analyzer and GFI Languard.
If successful...every command thereafter ...will include that authenticated user context.
I'm not sure what state that puts the client computer in and I should know that much at least.
And, I'm not sure this is a permanent solution because it would not appear to survive a reboot, right?
I'm needing to change the permanent state of the targets because the access is needed for an automated processes from EventLog Analyzer and GFI Languard.
Hi Fred!
This is just one of the reasons why trying to manage a large group group instead of a domain is a PITA.
This is just one of the reasons why trying to manage a large group group instead of a domain is a PITA.
Two possibilities:
1: Firewall is on the PUBLIC profile instead of the PRIVATE
2: Network Location Awareness has not been enabled.
On the machines that are being difficult open File Explorer and click on the Network node in the left hand column then click YES to enable Network Location Awareness.
1: Firewall is on the PUBLIC profile instead of the PRIVATE
2: Network Location Awareness has not been enabled.
On the machines that are being difficult open File Explorer and click on the Network node in the left hand column then click YES to enable Network Location Awareness.
ASKER
Hi Kevin! Yes, it may be. But might that suggest that using a DC is a panacea? :-) I'm still working on it slowly.
Philip Elder: The issue is C$, not just any file folder... and THAT is just as a test to see if monitoring is supposed to work.
Philip Elder: The issue is C$, not just any file folder... and THAT is just as a test to see if monitoring is supposed to work.
.
you have to set in the credential manager under windows credentials
computername\username and password for each computer in the workgroup
you have to set in the credential manager under windows credentials
computername\username and password for each computer in the workgroup
Yes, just domain joining all of the workstations, and connecting to the workstations via a domain admin account will make these troubles go away. Transitioning from local accounts to domain accounts for users can happen later.
ASKER
David Johnson:
you have to set in the credential manager under windows credentialsYes, that has been done.
computername\username and password for each computer in the workgroup
ASKER
Thank you all!
basically you need to allow below
TCP 445 (File sharing)
NetBIOS resolution
Network discovery
administrative $ shares must not be disabled for any reason on clients
clients should have correct AD DNS server specified in network card properties so that there won't be any secure channel errors