Questions

Domain admin cannot map drive to client's c$ or browse it via Win Explorer.

+
0 Votes
Locked

Domain admin cannot map drive to client's c$ or browse it via Win Explorer.

Dear all,

I wonder if someone can please help, the problem is as above, here are some details.

Background: The network is smallish and all Win XP SP2 PCs, one file server (Win2003 NOT a DC) and a network printer are getting their IP addresses dynamically from a 3COM ADSL switch/router (192.168.1.1) with DHCP server enabled, everyone is connecting to the file share on the W2K3 server and is printing happily on the network printer. Every PC/server is on a the same workgroup, aptly named 'WORKGROUP', and is getting all network settings assigned by the 3COM.
(on the PCs - 'ipconfig /all' shows the Def. Gateway, DHCP server and DNS server all having 192.168.1.1, the subnet is 255.255.255.0 and the IP address is within the range 192.168.1.100-200, obviously varies. DHCP leases expire after two weeks)
The network cabling ran from each PC to a hub/cheap switch in every room, from where it uplinked to the ADSL router. Certainly everyone can access the internet.

Enter the big idea (why, oh why?) to setup a domain and get everyone on it with all the benefits that it has - central administration, access rights management, roaming profiles, backup etc.

So I thought that I'll do a bit of testing first:

I did the following:

1. Promoted the Win 2003 server (SRV2) to a DC for a new domain with AD and DNS. Named the domain (aptly?) 'DOM1' (just that, not qualified further like dom1.company.com). The process required me to give the server a static IP address. I chose BELOW the DHCP range - 192.168.1.12. Changed Def. Gateway to 192.168.1.1 (the 3COM router). The DNS entry changed itself (wow?) to 127.0.0.1. In DNS console, right-clicked SRV2, selected 'Forwarders' tab and added 192.168.1.1.

2. Joined one Win XP SP2 client to the domain with Firewall switched off. Left it with a dynamically assigned IP address, BUT changed the DNS server to point first to the new DC (192.168.1.12, preferred) and then to the ADSL router (192.168.1.1, alternate). There aren't any DNS suffixes. The gateway stays 192.168.1.1 - as automatically assigned by the DHCP server (3COM). The computer account (named PC1) was created automatically on the AD upon joining.

3. Created a test user in AD and assigned it a homefolder and a profile folder (all folders created previously on the server, with the appropriate rights etc.. that bit works...)

4. Logged on the client PC (PC1) with the test user account - worked fine. Logged off, and back again - observed the creation of the profile files in the assigned profile folder on the server. The home folder drive (I:) connects exactly as it should. The client can browse the Internet happily without any settings whatsoever in IE.

5. Stuck a bottle of champers in the canteen's fridge. Went back and started thinking as far ahead as login scripts. Tried to browse to the client PC1 from the DC via Network Neighbourhood. Nope. Tried manually typing \\PC1\c$ in Windows Explorer - nope, won't have it, comes up with an error (below). Tried pinging it - that was OK, both by name and IP address. Hmmm.

6. Onto the Client XP. Tried pinging the DC from the XP client PC - 'twas all fine. Tried browsing the DC - yep fine, opened available shares (netlogon, sysvol) and stuff, fine too. The client PC's C$, IPC$ and ADMIN$ shares and all exists as they should. If I click on its own name PC1 in Network Neighbourhood, it does open its own 'Scheduled Tasks' and 'Printers and Faxes', as it should.

7. Back to the DC - still pings the XP client, still doesn't browse. Upon clicking the client it comes up with "\\PC1 is not accessible. You may not have permissions to use this network resource". What I was expecting to see is at least the 'Scheduled Tasks' and 'Printers and Faxes'.

8. Went to the DNS console on the DC. PC1 is not listed there under 'DOM1' in Forward Lookup Zones. Only the srv2 is listed.

9. Took the PC1 out of the domain. Deleted the computer account in AD. Joined PC1 to the domain again, the computer account was created automatically.

10. Went to PC1, logged as the domain admin. In a command prompt typed ipconfig /registerdns. Came up with "Registration of the DNS resource records for all adapters of this computer has been initiated. Any errors will be reported in the Event Viewer in 15 minutes..". No errors were found in Event Viewer. The PC1 still doesn't appear in the DNS console. should it actually? Still can't browse the PC1, can ping though.

Can someone please point me to the [obvious] stupid mistake that I'm making and put me out of my misery (not by shooting me hopefully).

Thank you all very much in advance.
MB
  • +
    0 Votes
    Dumphrey

    Make sure the firewalls are turned off on the client (if this fixes the problem, then go and set them up with the right access rules).
    Note: single name domains (DOM1) are not recomended by MS, appending a .local (DOM1.local)is fairly usual in private domains.
    Also, go into the dns server config screen and delete the "." domain if there is one, it will be in forward lookups, and will only be labeled as "." no other text. This domain says you are a root server. Double check you are logging into the domain on the local computer (i know i know) with a valid domain user. And that the computer is showing up in the domain computers OU. After turning off the firewall, remove the computer from the domain and add it back...
    Try accessing the remote computer from the RUN box by IP address instead of DNS; \\192.168.1.29\c$. By default, admin shares are hidden in network neighborhood (as well as share browsing in general), but should still be accessible. If this works, your problem is definitely DNS. Another thought is to run dcdiag /test:DNS on the domain controller and see if it throws up any errors (dcdiag is part of the win2k3 support tools download from MS). Also dnslint /ad /s localhost /v can give useful information. (dnslint is also in support tools).
    Sounds like a lot I know, but if its not firewall issues, its most likely DNS. DNS is the root of AD. Hope this will get you started, and sorry I was not more concise..

    +
    0 Votes

    Hi Dumphrey,

    Thanks for the reply. Certainly, trying to access the PC1 from a Run box didn't work, as I was unable to ping its IP address, let alone see the hidden c$ share.

    Yes, I had done remove/re-join after disabling the Win Firewall.

    Don't have a "." entry in the DNS on SRV2, my Forward zones are only DOM1 and _msdcs.DOM1

    Anyhuu, I noticed the following two errors in Eventvwr - Event ID 1030 and 11165, dealing with domains with single-label DNS names.

    Once I applied the following:
    http://support.microsoft.com/kb/842804
    http://support.microsoft.com/kb/300684

    everything worked. However I don't know which bit actually fixed it, because I literally went through ALL methods as described out of desperation. It could've been the group policy fix, or the regedit fix, or the dfsutil.exe from the Support Tools, simply dunno.

    But if anyone meets similar problems to mine, at least they'll know what exactly to look up - the above two KB articles.

    Now, if only I could convince the client PC1 to run the login script as applied to Global Policy. The script contains the incredibly complicated command - Wscript.Echo "Oh my God, the login script works!"

    I did the GP change in:
    Computer Configuration\Administrative Templates\System\Logon\"Run these programs at user logon" and added the item "\\srv2\netlogon\login.vbs" which is exactly where this script resides. And I can run it manually from a run box on the target PC.

    But not as a login script.

    If someone can help with that bit, great, if not, I'll be busting my head trying to work it out and I'll report here later on.

    Again, thanks for your reply.

    Much obliged
    MB

    +
    0 Votes

    Should be done under User configuration, not System. At least that's what made it work for me.

    Does anyone have any insight what is correct one?

    I read on the net that it should be under Computer...

    Thanks again!

  • +
    0 Votes
    Dumphrey

    Make sure the firewalls are turned off on the client (if this fixes the problem, then go and set them up with the right access rules).
    Note: single name domains (DOM1) are not recomended by MS, appending a .local (DOM1.local)is fairly usual in private domains.
    Also, go into the dns server config screen and delete the "." domain if there is one, it will be in forward lookups, and will only be labeled as "." no other text. This domain says you are a root server. Double check you are logging into the domain on the local computer (i know i know) with a valid domain user. And that the computer is showing up in the domain computers OU. After turning off the firewall, remove the computer from the domain and add it back...
    Try accessing the remote computer from the RUN box by IP address instead of DNS; \\192.168.1.29\c$. By default, admin shares are hidden in network neighborhood (as well as share browsing in general), but should still be accessible. If this works, your problem is definitely DNS. Another thought is to run dcdiag /test:DNS on the domain controller and see if it throws up any errors (dcdiag is part of the win2k3 support tools download from MS). Also dnslint /ad /s localhost /v can give useful information. (dnslint is also in support tools).
    Sounds like a lot I know, but if its not firewall issues, its most likely DNS. DNS is the root of AD. Hope this will get you started, and sorry I was not more concise..

    +
    0 Votes

    Hi Dumphrey,

    Thanks for the reply. Certainly, trying to access the PC1 from a Run box didn't work, as I was unable to ping its IP address, let alone see the hidden c$ share.

    Yes, I had done remove/re-join after disabling the Win Firewall.

    Don't have a "." entry in the DNS on SRV2, my Forward zones are only DOM1 and _msdcs.DOM1

    Anyhuu, I noticed the following two errors in Eventvwr - Event ID 1030 and 11165, dealing with domains with single-label DNS names.

    Once I applied the following:
    http://support.microsoft.com/kb/842804
    http://support.microsoft.com/kb/300684

    everything worked. However I don't know which bit actually fixed it, because I literally went through ALL methods as described out of desperation. It could've been the group policy fix, or the regedit fix, or the dfsutil.exe from the Support Tools, simply dunno.

    But if anyone meets similar problems to mine, at least they'll know what exactly to look up - the above two KB articles.

    Now, if only I could convince the client PC1 to run the login script as applied to Global Policy. The script contains the incredibly complicated command - Wscript.Echo "Oh my God, the login script works!"

    I did the GP change in:
    Computer Configuration\Administrative Templates\System\Logon\"Run these programs at user logon" and added the item "\\srv2\netlogon\login.vbs" which is exactly where this script resides. And I can run it manually from a run box on the target PC.

    But not as a login script.

    If someone can help with that bit, great, if not, I'll be busting my head trying to work it out and I'll report here later on.

    Again, thanks for your reply.

    Much obliged
    MB

    +
    0 Votes

    Should be done under User configuration, not System. At least that's what made it work for me.

    Does anyone have any insight what is correct one?

    I read on the net that it should be under Computer...

    Thanks again!