Networks

Ask something
Question Locked

Windows 2003 R2 Server, clients cannot access shared folders

0 helpful
11 replies

by taiclet

Closed to new repliesThis discussion is closed. It stays readable, but it takes no new replies.

First -- somewhat newbie alert!

Here's the issue: I just starting working at a school that has a Windows 2003 R2 Server. Simple filesharing used to work from this server. Then, I tried to install Active Directory, which I had previously managed at another school but not actually ever installed. Well, of course, that was not so smart, and the clients could not find the domain controller. Also, clients were still not looking to the W2K3 Server as the DNS server; they were looking at the ISP's DNS.

After lots of reading, I decided I ought to just uninstall AD and DNS and focus on other day-to-day issues since school started today. I uninstalled AD and DNS using the Manage Your Server wizard. I did NOT go into the command line and dump the AD meta data.

Now, here's the problem: I am trying to use simple filesharing from the server so we can start to archive instructional documents. The afternoon directly after uninstalling the AD and DNS, I had no problem connecting as a client to the shared folders. Then, I came in the next morning, and suddenly filesharing was no longer functioning. Odd. Since then, no clients have been able to connect to the shared folders on the server using either "My Network Places" or the map a directory function. I have checked the following settings:

1. Windows Firewall -- under "Filesharing" TCP ports 139 and 445 are open; UDP ports 137 and 138 are open; under "UNUP", TCP ports 2869 and UDP 1900 are open

2. I can successfully ping the server from a client.

3. In File Server Management, the drive that holds the shared folders is successfully shared.

4. The permissions on the shared directories are set to "everyone" for change and read.

5. I changed the name of the machine back to non-URL looking thing -- all caps instead of this.this.this.

6. I also created a generic user on the server and tried to map a directory and log on as this user. That didn't work either.

7. When I try to "Add A Network Place" from a client, I receive the message "The folder you entered does appear to be valid. Please choose another." Also, you cannot see the server or any of the folders in the "Browse" list.

8. The server and all of the clients have been configured to the same Workgroup.

I am guessing all of this I-don't-want-share business is the result of some DNS issue left over from the failed AD install, especially because filesharing was working before the AD install and I believe even during it. Any ideas you have either about how to get the AD running while maintaining the ISP DNS OR about how to just simple filesharing running would be EXTREMELY appreciated.

Thank you so much!

Lauren

11 replies

by churdoo

I don't think that your problem right now is related to remnants of DNS lurking since the AD install / uninstall. In your step 2, you state that you can ping the server from a client -- I presume by name instead of IP. If that's the case, then name resolution is working and so it's not a DNS problem.

Are the users getting an error when they try to list or map the shares? Are they getting "Access is Denied?" Are they being challenged with a "Connect as..." dialogue? Turn off the firewall completely for further testing; you can turn it back on later, but remove the question completely for now.

What username(s) are peeps logging into the workstations with? You need to create these usernames as local users on the server. I think that when you converted to AD, it wiped out the local SAM database, and then when you uninstalled AD, it placed an empty SAM database. Even with the Everyone object having permissions, you still need the usernames defined locally on the server.

I personally think that you should go back to AD, but it may be a larger project than you were expecting at the time. You can post back for more info if you want to plan the AD conversion later.

by taiclet

Churdoo,

Thank you so much for the information. You don't know how much I appreciate it, really. Now, onward and upward:

To clarify, I can ping the server by its IP address. I cannot ping the server by the new name of the server, which is (by way of example) SCHOOL. However, I CAN ping the server by way of the previous AD name, SCHOOL.tech.schoolname.org.

You are definitely correct about the SAM database. I knew what happened but didn't know what it was called.

I have started to rebuild the user names, and at your suggestion, I just added my client machine login as a user on the server. Then, I opened up the firewall completely and tried to connect from my client to the shared folder. I tried to connect using both the SCHOOL and the SCHOOL.tech.schoolname.org paths. Neither worked. Do I need to add the D$ directory somewhere in that share address? I have shared to Win2K3 servers before and did not have to do so, but maybe R2 is different?

Honestly, I would really like to reinstall AD as soon as possible, but I am quite confused about how to configure the AD DNS to forward to the DNS that is being used by our Cisco router. I do not feel confident enough that we are ready to host our DNS completely from the in-house Win2K3 machine. Is it possible to set up AD to use the DNS as defined by the Cisco router?

In the AD Round 1 installation, I tried the forwarding function in the DNS setup, with the DNS on the TCP/IP properties panel of the server defined to itself. However, when I then tried to add a client, the client responded (on the first few tries) that it could not locate the LDAP listing. I checked the LDAP listing, and it was present. I tried again with two sample clients, and both responded that they couldn't find the domain controller. Now I'm wondering if I missed the simple step of elevating the status of the server to domain controller. I thought that step would be completed by the AD install wizard, however.

Oddly enough, I came back to the machines that I had tried to install as clients 3 days after the initial AD installation (and before the un-installation), and those machines had picked up the address of the server as their domain. They just wouldn't pick them up immediately. I'm guessing that time delay had something to do with ARP tables? Anyway, despite the fact that those two clients had picked up the domain, no other clients would, so I uninstalled anyway.

As I'm sure you can tell by the description above, this Win2K3 soap opera has been going on for a good two weeks now. Today's the first moment I've had time/space to address it completely.

Thanks again,
Lauren

by churdoo

Well then, taking one step at a time, and I'm thinking that getting your clients at least back to the way they were before, is more pressing than jumping to AD at this point.

There clearly is something wrong with name resolution if you can't even ping the server by name. If your clients can't resolve the name of the server to an IP, then we can't even think about accessing a share in the form of \\servername\sharename.

However, you CAN test \\serverIP\sharename and see if that connects. Meaning, if your server has an IP of 192.168.50.11, then from a client, try to connect to \\192.168.50.11\sharename. If that connects, then your file sharing is OK, and you just need to fix name resolution of the server.

You are correct in that you do NOT have to put the d$ share in the UNC path; should just be \\servername\sharename or \\serverIP\sharename

Seems to me, that your server still thinks is has an FQDN of SCHOOL.tech.schoolname.org. So are you telling us that you've removed the DC role from the server, and have placed the server back into a WORKGROUP, using the same workgroup name as the clients. Confirm ALL of the TCP/IP properties on the server -- did you set the DNS server(s) back to what they were pre-AD (pre-AD sounds weird)? Are you using WINS in your org and did you check the WINS settings? Did you check if NETBIOS is enabled on the server?

I'll just briefly respond to a couple of points in your last post relative to moving forward with the AD implementation.

It is a good practice to name your AD domain name something like schoolname.LOCAL rather than using your public FQDN (SCHOOL.tech.schoolname.org). There's nothing stopping one from using their public domain name as their AD name, but as you can imagine there are considerations that need to be made for accessing public servers of the domain from internal clients. So make it easy on yourself and don't do it.

You were correct in defining DNS Forwarders in your first attempt, but missed a couple of other steps which we can talk about later.

You won't host your public DNS on the AD-controller (DC), so don't worry about that. DNS is used on the DC's to store AD-related information and to do name resolution for the organization, and is not necessarily intended to be used as your public DNS host.

by taiclet

The investigatory work continues on this end...

First off, yes, the IP pathway does work, which is great because it means I can stop panicking.

Second, you are correct; the server still thinks it has an FQDN of SCHOOL.tech.schoolname.org. Strangely enough, when I ping that FQDN, I receive the IP address of our webhosting company, which hosts schoolname.org for us. So far, I have not created the subdomain tech.schoolname.org on the end of the webhosting company. Anyway, I get the IP for the webhosting company both when I ping SCHOOL.tech.schoolname.org and tech.schoolname.org. Oddly enough, if I try in the Network Place Wizard to resolve to a path of \\SCHOOL.tech.schoolname.org\SHARE, it doesn't work.

Pre-AD, the server did not host DNS, and also it did not have DNS entered in the TCP/IP properties box. Right not, I have the IP addresses for the DNS as defined by our Cisco router plugged into the server's TCP/IP properties box because I'm guessing that if I delete it, I won't be able to path to the IP as I mentioned above.

I do not believe we are using WINS because I do not remember seeing any WINS settings pre-AD. WINS is actually a mystery to me.

NETBIOS was NOT enabled, so I went ahead and enabled on the TCP/IP properties panel yesterday, but that did not change my ability to resolve a path to SCHOOL only instead of the IP path.

Thank you for the information about creating a .local name. I did read that; however, it came just a few minutes too late. :-) Guess that's why I should have read the AD book BEFORE I tried an installation...

Moving forward, if you can direct me to any information on how to change the FQDN back to the NETBIOS name, I think that may help. Or maybe I should just change the FQDN to schoolname.local for now so it stops resolving to our webhosting company's IP address?

I have read about the ntdsutil CLI for deleting AD meta data after uninstall. I'm wondering if I should do that?

Thank you again for all of your help. K-12 education is difficult for IT because anyone who is ACTUALLY qualified enough to be setting up AD the right way is also probably smart enough to work somewhere that pays more than public schools. :-) Funny, in my previous job at a public school in a very large east coast city, the on-call tech support was just about the only part of the larger school system that was working; the teaching of the children was mostly a disaster. Now that I'm working at a small public charter school in a slightly smaller east coast city, it's the opposite scenario: On-call tech support is lacking/limited since we have limited funding, but the actual teaching of the kids is AMAZING. It's been an interesting flip-flop to watch, to say the least.

by swatts

Setting up a new domain is relatively straight forward in 2003 with all the wizards.

When you configure your first DC, verify the dns servers in the TCP/IP configuration point back to itself as it will act as the DNS server for the domain as well. You will then configure the fowarders in the DNS server to your ISP dns servers.

Once you get the first domain controller running, always have a 2nd DC running in your environment, just run dcpromo on the 2nd windows server and it will take care of the rest.

by churdoo

1) Go you the Server's System Properties / Computer Name tab / and change the computer name to SCHOOL (by way of your example, if not already) and in the same dialogue, select WORKGROUP and fill in the same workgroup name that the clients use.

2) Go to Services and see if DNS Server is running. If so, Stop and Disable the DNS Server service. (just for now, until AD attempt #2)

3) The TCP/IP Properties DNS server should point to the same DNS resolver as the rest of your network; Enable NETBIOS over TCP/IP on the server

4) If you're comfortable with it, run the AD metadata cleanup.

I'm glad your teaching experience at this school is better than before.

by smilingsheep

Right-click My Computer, select Properties. Select Computer Name tab, click Change button. Then, click the "More" button. Verify that the "Primary DNS suffix of this computer" field is blank. If there is .tech.schoolname.edu or similar in the box, the server will register that suffix after its name as the FQDN.

At least on Windows XP it does. I haven't managed servers for a few months so I'm a bit rusty.

by smilingsheep

Sluggish connection this am. Sorry about the duplicate entry.

by taiclet

1. I changed the computer name and workgroup last week after uninstalling AD.

2. DNS server is not running in services, but DNS client is. Should I stop that service.

3. TCP/IP points to same DNS as rest of network. NETBIOS has been enabled.

4. Have not run the AD metadata cleanup yet.

Oddly, today one of the client machines that I never tried to put on the AD domain propagated itself to that domain, causing loss of DNS resolution. I had to manually entered the IPs for our DNS on that machine. However, the two clients that I did try to put in the AD domain (which initially resisted and then magically joined) are still showing the domain AND still seeing the correct DNS, even though I did not manually enter the IP addresses.

by taiclet

OK, now all kinds of weird stuff is happening. I enabled WINS because it seemed to be the way to get some desktop clients to connect, and now IP sharing is no longer working. The only machines that can access the shares are those that are appending the DNS suffix school.schoolname.org and that have "joined" the domain, which to my knowledge shouldn't exist at this point. (These are machines which I tried to connect to AD initially.) I did not try CLI metadata dump.

At this point, I am considering two routes of action:
1. Reinstall AD and DNS since the school.tech.schoolname.org name seems to be forcing itself, and add all of the clients to the AD.

2. Do the metadata dump and see what happens.

I de-enabled WINS since IP sharing seemed to stop after I enabled it. Still IP sharing is not starting back up.

What a mess...

This discussion is closed to new replies.