Network Location or Drive Map?

U

USMCGrunt

2[H]4U
Joined
Mar 19, 2010
Messages
3,103
I'm working on a new network share design on my corporate network and I'm trying to determine if these shares should be mapped to users as Network Locations or Drive Maps. How should each of these be utilized and what's the best way to incorporate them?

From what little I can think of, you'd use a mapped drive if the location is going to have some sort of executable program on it. If it's just a file storage location, then a network location would be appropriate. Is that it or are there other considerations?
 
It's my opinion that you will want to hide the UNC as far from the user as possible. I would recommend a DFS server hosting a namespace, and from there you can decide if you want to use driver mappings. Here is why:

Lets say you have a server, server A. You create a share called data, and all the users in Marketing make these WONDERFUL excel spreadsheets that link to data in \\servera\data\marketing\letsscrewoverit.

You are going to replace that server; it's going to happen. So the day comes and you bring ServerB online and you recreate the file structure and you copy all the data over. You bring down ServerA and -- BAM. All those excel spreadhseets that link to data are broken.

To prevent this, you have a couple of options:
1. Mapped drives. Yes; it would work, but why use mapped drives if you don't have to. You have to worry about maintaining the mapping, and some users might map it as x, others as y. It can be a pita.

2. Use DFS. DFS would let you put a namespace in front that is friendly. So you can make \\mycompany\mydata\Marketing, and copy all the data over. In this example, Marketing could actually point to \\servera\data, and the user would never know it. This way, when server B comes online, you can just add it to the namespace and remove ServerA. Since the name the users access it by never changes, you don't have any problems.


You should also be aware that some programs can actually "see through" a mapped drive. For example, I support a program that access files based on a drive letter. It records the "job" in a database. Even though all references are pointing to a drive letter, the unc is recorded in the database. Since we upgrade our SAN every couple of years, it would be incredibly difficult to go in and change all those. So even though the backend servers are changing, DFS hides this from the user and the program and makes it easier.
 
I have a better idea: get proper tools for marketing and ditch Excels!
 
Demon10000 said:
It's my opinion that you will want to hide the UNC as far from the user as possible. I would recommend a DFS server hosting a namespace, and from there you can decide if you want to use driver mappings. Here is why:

Lets say you have a server, server A. You create a share called data, and all the users in Marketing make these WONDERFUL excel spreadsheets that link to data in \\servera\data\marketing\letsscrewoverit.

You are going to replace that server; it's going to happen. So the day comes and you bring ServerB online and you recreate the file structure and you copy all the data over. You bring down ServerA and -- BAM. All those excel spreadhseets that link to data are broken.

To prevent this, you have a couple of options:
1. Mapped drives. Yes; it would work, but why use mapped drives if you don't have to. You have to worry about maintaining the mapping, and some users might map it as x, others as y. It can be a pita.

2. Use DFS. DFS would let you put a namespace in front that is friendly. So you can make \\mycompany\mydata\Marketing, and copy all the data over. In this example, Marketing could actually point to \\servera\data, and the user would never know it. This way, when server B comes online, you can just add it to the namespace and remove ServerA. Since the name the users access it by never changes, you don't have any problems.


You should also be aware that some programs can actually "see through" a mapped drive. For example, I support a program that access files based on a drive letter. It records the "job" in a database. Even though all references are pointing to a drive letter, the unc is recorded in the database. Since we upgrade our SAN every couple of years, it would be incredibly difficult to go in and change all those. So even though the backend servers are changing, DFS hides this from the user and the program and makes it easier.
Click to expand...

Well, when I was thinking of mapping drives they were gonna be done through group policy so that would eliminate the users from screwing with it but I like the DFS idea. Time to go learn DFS lol.

B00nie said:
I have a better idea: get proper tools for marketing and ditch Excels!
Click to expand...

Small segment of the network with less than 100 users and, in his example, our marketing department consists of two users. I think the largest "department" is like....eight people.
 
USMCGrunt said:
Small segment of the network with less than 100 users and, in his example, our marketing department consists of two users. I think the largest "department" is like....eight people.
Click to expand...

There are cloud based CRM/ERP/Marketing solutions which are really low cost and low overhead. Well, at least where I come from. But this is off topic so sorry.
 
Even if you do decide to use mapped drives, I highly recommend using DFS as well and mapping the drives using the DFS path. That way if you ever need to move the share the drive mappings will continue to work with no changes because all you need to do is point DFS to the new location.

DFS also has a few other nice features such as replication which can come in handy in some situations.
 
wbo said:
Even if you do decide to use mapped drives, I highly recommend using DFS as well and mapping the drives using the DFS path. That way if you ever need to move the share the drive mappings will continue to work with no changes because all you need to do is point DFS to the new location.

DFS also has a few other nice features such as replication which can come in handy in some situations.
Click to expand...

I'm in the process of figuring out DFS.....YouTube videos, TechNet resources, and VMs...surprised how difficult it is to find a reliable resource that assumes zero DFS knowledge...
 
So, I think I've finally got this figured out and replication going with DFS but now my question is this....How do I find out the ACTUAL file location of the file that a user has opened/modified? If it's being replicated to Srv1 and Srv2 and I have a drive mapped to contoso.local\Share, how can I find out if they are pulling the file from Srv1 or 2?
 
Right click on it and look at the DFS tab. You'll see all the DFS referrals for that folder -- the one marked active is the one you're pulling from.

Remember -- you don't HAVE to use replication to use DFS. So it doesn't have to exist on multiple locations. You can use it to mask the original source path but still only have one location. That still gives you the flexibility to move the data around in the back end...
 
Demon10000 said:
Right click on it and look at the DFS tab. You'll see all the DFS referrals for that folder -- the one marked active is the one you're pulling from.

Remember -- you don't HAVE to use replication to use DFS. So it doesn't have to exist on multiple locations. You can use it to mask the original source path but still only have one location. That still gives you the flexibility to move the data around in the back end...
Click to expand...

Ok, So I created a text document and stuck it in my 'IT Share'. Waited for replication to hit so that it was on both servers and then went to \\domain\namespace\Folder and the file is there. I then right-clicked the file and went to 'properties', inside that window, I only have tabs for: General, Security, Details, Previous Version. Nothing refers to DFS and the location referenced on the General tab is \\domain\namespace\folder, that's it. What am I doing wrong?
 
Demon10000 said:
Go up a level and look at the folder, not the file.
Click to expand...

Ok, so when you make the request to open the folder, that's when the OS polls DFS and is given a physical path to a server? So how would you determine where your going if you open a file from within an Office product, such as those listed under the 'recently opened' list?
 
You must log in or register to reply here.
Back
Top