2003 server combine folder views on share?

mord

Limp Gawd
Joined
Mar 8, 2005
Messages
377
Is there a way to make a share from a 2003 server contain the files from 2 different folders into one folder view? Or do this from a client end on win2K and XP machines.

Ideally I want to have a mapped net drive say G that when a client looks in it he sees the files from 2 different folders. Those two folders (f1 and f2) would contain identicaly named subfolders, but with different files in them. I want the end user to just see one set of folders with all of the files from f1, and f2. I can handle scripts to move files where they need to go at each end of day, so where new or modified files are placed doesn't matter except for file name conflicts.

While I don't really care for it, this is part of a backup solution I have been asked to plan out. We are looking at several different solutions and one of them requires segrigating our data based on last date modified between files that have not been accessed in the last 3 months from those more recent. While it would be easy enough to script out something to manage the file moves based on modified date, I need a way to keep the segrigation invisible to the end users.
 
I think what you are looking for is DFS, with it you can have multiple shares even on multiple servers show inside a dfs root. More info: http://en.wikipedia.org/wiki/Distributed_file_system


So what you could do is share these 2 folders, and then add them both to a DFS root, when your browse to that DFS root you will see both those folders inside.

Is that kind of what your looking for?
 
Yeah, I had just thought of DFS and was about to post on that :)

I have not used it myself but I am perusing through the MS white papers on it to see if it will meet our needs. Thanks for the linkage also.

Anyone know if DFS can merge 2 targets by top level share all the way down through sub-folders automaticly?

As I see it I would setup DFS to have 2 targets for one root. Those 2 targets will have 6-8 levels of subfolders in them. that would be the only root I need.
 
DFS does not "merge"

all it is, is a presentation layer.

word of advise. Do not use standalone DFS servers. they are headaches. Go domain based and be done with it.

the "root" folder (\\dfsname\root) resides on the domain controllers and the target folders (\\dfsname\root\target) are the pointers to the ultimate destination.

\\hardforum\home.......\\server1\home
\\hardforums\home\figgie.......\\server10\figgie$
\\hardforum\home\mord......\\server100\mord$
\\hardforum\apps\linux......\\server50\apps\linux

etc.

basically a neat way to show the users one way to reach thier data. that is the easy part. the hard part is arranging the data in a meanfull way.

btw to have mulitple roots you must apply the hotfix to windows 2003 standard or use windows 2003 enterprise server.

also an added bonus.. if you ever need to move data... just move the data to new location, point dfs to new location and you are done. No need for users to remap anything ;)
 
yah, not merge, bad wording on my part. I don't want the files actually moved. I just need multiple folders with the same name to be shown as one folder.

example

Server volume A has folder "data" with subfolder "user" and "aps"
Server volume B has folder "data" with subfolder "user" and "aps"

Volume A and B have the exact same folder structure, but totally different files in those folders.

I want the users to see only ONE "data" folder with only one "user" and "aps" subfolder and for those to contain all the files from the like named folders on volume A and B.
 
mord said:
yah, not merge, bad wording on my part. I don't want the files actually moved. I just need multiple folders with the same name to be shown as one folder.

example

Server volume A has folder "data" with subfolder "user" and "aps"
Server volume B has folder "data" with subfolder "user" and "aps"

Volume A and B have the exact same folder structure, but totally different files in those folders.

I want the users to see only ONE "data" folder with only one "user" and "aps" subfolder and for those to contain all the files from the like named folders on volume A and B.

oh no

that won't work

you would need two different pointers in DFS

ie

\\mord.com\data1\users....\\serverA\Data\Users
\\mord.com\data1\aps.......\\ServerA\Data\Aps
\\mord.com\data2\users....\\ServerB\Data\Users
\\mord.com\data2\aps.......\\serverB\Data\aps

of course you could always do

\\mord.com\apps\apps1.....\\ServerA\Data\Aps
\\mord.com\apps\apps2......\\ServerB\Data\Aps
\\Mord.com\Users\Users1...\\serverA\Data\Users
\\mord.com\Users\User2....\\serverB\Data\Users

multiple ways to arange this.
 
Another alternative would be to use linkd from the server resource kit and use junctions to present the folders together. Then share the directory with the junctions. No DFS required.

http://support.microsoft.com/kb/205524/en-us

Unless you are wanting to share locations from multiple servers in one place, DFS is overkill.
 
nessus said:
Another alternative would be to use linkd from the server resource kit and use junctions to present the folders together. Then share the directory with the junctions. No DFS required.

http://support.microsoft.com/kb/205524/en-us

Unless you are wanting to share locations from multiple servers in one place, DFS is overkill.


bad news


the ntfs junction points only work on local files. For remote files DFS is a must.
 
figgie said:
bad news


the ntfs junction points only work on local files. For remote files DFS is a must.

You might want to read up on the features of the NTFS file system, and learn a little more about how network redirectors work on MS operating systems before reaching the conclusion you stated above. Performing a test to validate your assumptions would be helpful as well.

Shares are local file system access, to the serving machine. The local network redirector on the serving machine does the transitioning through the local file sytem for the remote system. As long as the serving machine understands the file system structure beneath a share, remote systems will be able to access all of it.

I use junctions on production servers to aggregate folders across multiple SCSI arrays defined as separate logical drives into single locations to simplify pathing for SAMBA mount points all the time to make things easier on our Unix admins by providing a single mount point for each department for automated transfers of SAP extracts into multiple separate directories across that department's file storage. Saves them a lot of time when establishing new transfers.

See the first screenshot below of junctions working through a share from another machine. The serving machines name is Puppeteer. The accessing machines name is Ptaav (Yes I like Larry Niven SCI-FI and use names from his Known Space works for my naming convention at home). In the command window, the client machine's directory command sees the directories as junctions, and can still access the data past the junction as shown by the directory command.

The second screenshot is the junction definitions on the host server showing data from multiple drives being made available through a single share point.

junction.JPG

junction2.JPG
 
One disadvantage of junctions is that unlike a symlink, just deleting a junction actually deletes the real target as well, not just the reference to it. You must remember to delete a junction using a junction tool, not using "rd" at a command line or by just deleting it in Explorer.

Explorer also doesn't show any difference between a junction and the real type of object it represents, but you see it in a command window using "dir". Bad API decision on Microsoft's part.
 
nessus said:
You might want to read up on the features of the NTFS file system, and learn a little more about how network redirectors work on MS operating systems before reaching the conclusion you stated above. Performing a test to validate your assumptions would be helpful as well.

Shares are local file system access, to the serving machine. The local network redirector on the serving machine does the transitioning through the local file sytem for the remote system. As long as the serving machine understands the file system structure beneath a share, remote systems will be able to access all of it.

I use junctions on production servers to aggregate folders across multiple SCSI arrays defined as separate logical drives into single locations to simplify pathing for SAMBA mount points all the time to make things easier on our Unix admins by providing a single mount point for each department for automated transfers of SAP extracts into multiple separate directories across that department's file storage. Saves them a lot of time when establishing new transfers.

See the first screenshot below of junctions working through a share from another machine. The serving machines name is Puppeteer. The accessing machines name is Ptaav (Yes I like Larry Niven SCI-FI and use names from his Known Space works for my naming convention at home). In the command window, the client machine's directory command sees the directories as junctions, and can still access the data past the junction as shown by the directory command.

The second screenshot is the junction definitions on the host server showing data from multiple drives being made available through a single share point.

junction.JPG

junction2.JPG

very good

see that Y mapping... that lets it use it as a local drive (assigns a volume ID and a GUID).

I went through this excersise already. What you are doing works in a tiny environment. Enterprise level stuff, nope. We could not do it this way as we have a hell of alot more shares than what can be used with drive letters alone

again. you can not use NTFS junction point to a remote share without DFS or mapping it but then you are limited to the letter of the alphabet. With DFS I am not. ;)
 
figgie said:
you can not use NTFS junction point to a remote share without DFS or mapping it but then you are limited to the letter of the alphabet.;)

Never said you could. In regards to the second point in that sentence, if you just use shortcuts to UNCs you never run out of drive letters, although that is from out of left field.

From my first post:

nessus said:
Unless you are wanting to share locations from multiple servers in one place, DFS is overkill.

This was the original question that I answered.

"Is there a way to make a share from a 2003 server contain the files from 2 different folders into one folder view? "

Someone said the solution was DFS at a point in the thread before it was clarified that multiple servers were involved, on a single server it's not. My post made it very clear I was talking about a single server situation, not multiple servers.

nessus said:
Unless you are wanting to share locations from multiple servers in one place, DFS is overkill.

figgie said:
the ntfs junction points only work on local files. For remote files DFS is a must.

Saying this in response to my first post implies that junctions cannot be traversed remotely at all, even when they are both within a share from another computer.

I now assume from your further response that what you actually meant to say was that "junctions cannot be used to transfer from one server to another", not that junctions can't be used for remote files ("the ntfs junction points only work on local files"), which is what you actually stated and the part of your post with which I disagreed.
 
wow, awesome info guys.

nothing like a little "discussion" to bring out the flavor of a post :)

To clarify my original question, yes it is one server. Right now all the data I am working with for this project resides on 2 external SCSI RAID 5 array's that are directly attached to one server. Not iSCSI just plain old external SCSI on a HBA.
 
Back
Top