Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations derfloh on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

DFS empty on some PC's where rest can see contents

Status
Not open for further replies.

mdcr

IS-IT--Management
Joined
Oct 3, 2001
Messages
228
Location
US
On some of our W2K and XP machines on a 2000 domain, when a user clicks on a network folder that is redirected to another server share through DFS, users cannot see the contents; they only see the empty folder. If they go through Network Neighborhood and navigate to that second server (where the file actually resides), they can see the contents. I have searched for the cause of this error, but no reference material could be found. On other machines we can see the contents as if they were on the original server (the way DFS is supposed to work), any ideas? FYI-we have DFS just redirecting users to separate servers, not for redundancy. Thanks!
 
We are having the same problem. We can see the DFS share on Windows 95/98 machines, but not on any Windows 2000 or XP computers. We have just started using DFS. We want to move data to another server to free up space, and want this to be invisible to the users, no re-training, etc.
mdcr - did you ever figure out your problem, ours sounds like the same???
 
You must look under the DFS named shared resource.

Let's say your DFS is called : DFS

In your DC, you'll have \\DC\DFS

In that folder you'll see the shares for your DFS.

The original shares will still be visible like a regular network share also.

Then you map your stuff to \\DC\DFS\<sharename>




&quot;In space, nobody can hear you click...&quot;
 
BTW, DFS is not made to MOVE stuff.. it's made to replicate. It will attach users to the resource that is less used at the time.

You'll have some users connected to one DFS server and others to the second DFS (if on the same LAN).

I suggest you replicate what you need BEFORE attaching users to the new DFS.




&quot;In space, nobody can hear you click...&quot;
 
We are still having problems with that, we are having users log into different computers to see if the problem is with the users' accounts or the machines. That will tell us how to workaround this issue. If the user goes to Network Neighborhood, they can navigate to the proper folder, but the whole point is that they go to the old location (usually through a mapped drive) without seeing a difference. We do have the type of DFS that has the files on a separate server , not the active-directory integrated DFS where the files are on the original server and a second server for contingency purposes....I would think that would be a factor as well....
 
ReddLefty, we use DFS to move stuff because we don't have enough space on a particular server. How else would you organize, say, all of your client files when you get beyond 18Gb, 36Gb, or 80Gb of hard drive space? Yes, it is possible to upgrade that hard drive every time, but wouldn't spanning those client files across multiple hard drives work? And, getting back to our problem, why would this behavior be seen on some machines, but not all?
 
Mdcr,

DFS is a distribution file replication system. It's made to synchronize your files across multiple servers across branch offices, especially usefull when you have WANs. It CAN be used to move stuff, as you do, but that's not what it is designed for.

DFS was especially designed for large networks with WANs to replicate data across office branches instead of having users open them on the actual source location of the file.

A DFS share will attach to the Open, Shortest, Fastest Path it can find. If you have 2 servers in the same LAN, they will most likely share the DFS paths.. so you'll have people attached to both servers.

I tried to find a way to force people on the same server while still using the DFS paths, but I never managed and this was after playing with ADSI Edit and modifying the actual schema... and a few weeks of research.

If it's possible, maybe... but it's like trying to use a snowboard to go down a wood ramp... it will work.. but that's not what it was made for.

The best I could do, and it suited my purposes, was replicate server1 to server2 and attach people to server1 using the original maps (\\server1\<share>)

If server1 fails, just changing the script file and rebooting is all that is required for people to get up and running again. This is not the perfect solution, but it was good enough for my purposes.

Sorry I can't be of more help.




&quot;In space, nobody can hear you click...&quot;
 
Windows 9x clients can't use DFS unless they load a added component from Microsoft. AD Client (or something like that)

To browse to a DFS root, you would NOT need to put the servername in the path....as this would DEFEAT the purpose of DFS.

To browse a DFS root

\\domainname\dfsrootname

I think the problem is with your concept of DFS. I suggest going to the MS site and reading up on how to use DFS. Here is some information:


DFS has two parts to it.

ONE: DFS can help an organization create a hiearchy of shares. Meaning that you can have shares all over your network. DFS will help end users find network shares because they will no longer need to know SERVERNAMES.

TWO: DFS can replicate data. So, you can use DFS in your scenerio if you want. You will at least double your disk space

For example, if you have a server called SERVER1 with data contained in a shared folder called SHARE, you could replicated this data using DFS to another server.

If you were to do this, you would have an exact replica of the DATA on both servers. The replication will ask for a MASTER during the intitial setup; however, after the initial replication completes, the two SHARES will become equals. This means if data is saved to any of the shares, the data will be automatically replicated to the other share.

Here are some short comings:

- DFS can not warn end users of OPEN file locks. For example, say two users try to edit the same file. User A is on Server1 and Users B is editing on Server2. These users would not know that the other user is editing the same file. Therefore, who ever saves LAST will WIN. Therefore, it is recomended only to keep READ ONLY data in DFS replication data areas. What administrators normally due in a situation like yours is to limit access to one of the two servers. In this way, users can not UPDATE data in both places at once.

- If you have multiple sites, you must have a root replica in each site. If you don't, your XP/2K client may not get redirected properly. (Another feature of DFS is to redirect the clients automatically. This takes away the clients needs to understand server names. Because to the organization of shares unders DFS, the clients can point to a DFS root and &quot;see&quot; the hierarchy of shares. when the user tries to connect to a share, the DFS system points the client to the CLOSEST (or local site) share. If you don't have a root replica in each site, the clients will not get redirected properly.

-If you are replication large amounts of data (more than 10 GB's), you may have to repoint your STAGGING AREA folder to a larger disk. You may also have to increase the size of the staging area to accomidate this large data copy.

- You will be doubling your disk usage when you implement DFS between two servers. Beware of this issue as you will run out of disk space twice as quick.

- Only Windows 2000/XP clients can take advantage of the features of DFS (9x clients can download a tool however)

Otherwise, DFS is an awesome tool in Windows 2000.



Joseph L. Poandl
MCSE 2000

If your company is in need of experts to examine technical problems/solutions, please check out (Sales@njcomputernetworks.com)
 
Joseph caught a nice typo on my part.. I was supposed to write \\DOMAINNAME\DFS\<sharename> on that post way up there...

:(




&quot;In space, nobody can hear you click...&quot;
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top