Mapping Shares to Drive Letters: Pros and Cons and Questions

I'm with you on the pros of drive mappings:

• Easy for users to understand
• Easy for admins to change paths without confusing users (i.e. drive letter remains the same)

I can remember back in the day I would call a batch file via GPO that manually removed and re-added the network shares via: 

net use P: "\\server\foldername\foldername"

Select allOpen in new window

Not sure if that's what you're looking for.

Andrew Porter:  I've done the same.
Here, the built-in Drive Mapping feature works fine it seems.  It can be set to do this in various ways.
It's a GPO Preference item in our case.  
The choices there are:
Update (seems to be the most common) says it will change)

Update

This Action modifies the settings of an existing mapped drive. It differs from the Replace action in that it only updates the settings defined within the preference item. All the other settings remain as they are. If a drive mapping does not exist, the Update Action will create the drive.

I guess one can use an empirical method to determine what this means!  It only updates the settings defined within the preference item.  All other settings remain as they are.  What is the difference between "settings defined within" and "other settings" [in the context of a drive mapping GPO preference item]?

One suggestion was to use Replace at the outset and shift to Update thereafter.  Seems sensible.

But, my question was about methods not using drive maps.... I wonder about using DNS CNAME aliases?  "aliases" was one of the things that was bouncing around in my head.

DEMAN-BARCELO (MVP) Thierry:  

Comment re: CNAME taken.  Thank you!  
Yes, I realize that the shares can be accessed using \\server\sharename or even \\server\sharename$.
With the $ suffix they must know what to enter as browsing won't help.
I've been trying to discourage using that format in favor of using the drive maps.

Let's say that we have a Drive Mapping GPO Preference Item:
Map N: to \\THISserver\THATshare$
And some people use N:\
Other people use \\THISserver\THATshare$
Now we change the share location to \\NEWserver\THATshare$:
If we change the drive map to Map N: to \\NEWserver\THATshare$ then we're done as long as the User's using N:\
Then, *we* have to make the needed change within the context of the whole change process.
Otherwise:
If the User is using \\THISserver\THATshare$, then it will be wrong after the change and will have to be edited at the local machine's level.  That's what I'm trying to avoid.  And, I think that's good practice.  Others may have different views.

DFS Namespace takes care of all issues with servers changing. For example, when I want to fail over access from ServerA to ServerB, I update DFS Namespace. I do not make DNS changes, registry changes, GPO changes, or drive mapping changes, or any changes to shortcuts or UNC paths.

kevinhsieh:  I understand completely.   And with my meager (but growing) knowledge cannot disagree.

We have 3 fileservers in DFSR.  
In order to avoid coordination / sync issues, I'm working to effectively have one server that will allow READ/WRITE by Users.  I believe this is an important objective.
Traffic / data rate isn't an issue.  So not spreading the users around the fileservers won't hurt.

Rather than to take advantage of DFS namespace client addressing, we'll simply target one fileserver for all fileshare accesses read and write.  This is a client-side addressing approach and nothing more.
Just like namespace addressing, this addressing is implemented with a GPO Preference Item for Drive Mapping.
That makes synchronization the same as if we didn't have DFSR.
Yet, Replication will happen so we have a couple of hot spares in case of a failure of the main fileserver.
Then, in case of a failure,, switching can happen with a modified GPO for the Drive Maps.

I asked this question to try to cover the question of what might one do in place of drive maps - which some consider to be archaic and undesirable.  Not that I'm planning to change - simply to understand better.

I know of 1 person on another forum that keeps pushing shortcuts to UNC paths. I don't get it. Dive mappings were around before UNC. Applications with with them. Users know how to use them. The only plug I could say for not using drive mappings, is that it would pretty much _force_ you to go to DFS Namespace, or failover to another server is going to be very painful.

I recommend DFS Namespace even for single server environments. As you grow your knowledge, I suggest you transition to them as the target for your drive mappings. Implementing DFS Namespace has saved me and my users so much time over the last 15 years. It keeps paying dividends, and is basically zero maintenance aside from add/move/change type stuff as you replace servers.

Modifying DFS Namespace is much easier than changing drive mappings, especially once you go beyond 1 or 2 GPO for drive mappings.

Using drive letters in place of UNC gives less problems, that's true.
But some softwares (as Excel sometimes, randomly) replace the drive letter by the UNC path.

So, it is only after migration/change of names/places that some users complain about some lost reference links.

Now, when using DFS, you have 2 ways using it.
Directly with their UNC, or with drive letters connected the DFS.

And the problem remains nearly the same. The interesting thing is that you can replicate and change the serveur/share used by DFS without changing the path used to access DFS. That is already a good point.

kevinhsieh:  as always, I'll consider what you've said caredully.  Thank you!

Let's see:
To do what I want to accomplish, the namespace would have one target per ... something.
Then the Replication Group would have 3 players.

DEMAN-BARCELO (MVP) Thierry: It sounds like there's some room for what I need to do.  Thanks.

I was going to research this further but the  phone kept ringing!
So, I'll just ask:
Here is what I need to do:
There is a small number of fileservers in a mesh configuration.
The original arrangement was to use plain DFSR.
However, synchronization was a  problem and we've decided to have *all* users READ/WRITE onto ONE of the few file servers while continuing to replicate (for standby redundancy).
Shares are a "$" hidden as had been recommended and I can see why.  (But this hiding is only good for browsing and not for manual addressing - or I've missed a step).
Using namespace addressing would be simpler and neater than the scheme I came up with which was to change the GPO and move the Drive Maps to another server and set of shares (in case of emergency).
Right now, I don't know how to do that.  i.e. keep a number of fileservers in DFSR but have DFSR only direct access to ONE of them.

"User" Shares with $ can be addressed directly, but not admin shares (with $ also).

Now, DFS has two functions:
- DFSN: The NameSpace (Just a dictionary of data). Always useful. (Create at least one root-DFS)
- DFSR: The Replication of data. Depending on the usage. R/W ou R only, with ordered accesses (more complicated).
Usage is very easy when modifications on a specific share are always done on the same server.

I have seen a lot of clients using DFSR to centralize data, then backup the centralized data. If DFSR replication is not controlled regularly, you can have a lot of differences between the servers. And it is more complicated if modifications are authorized on several servers. The locks on files are not synchronized between servers!

DEMAN-BARCELO Thierry:  

The locks on files are not synchronized between servers!

Yes, understood.  This is a rather fundamental limitation of DFSR.  I know of no good way around it.  Yet, that's what I'm working to do in a rather brute-force sort of way.

Usage is very easy when modifications on a specific share are always done on the same server.

Exactly.  But then the use of DFSR might well come into question.  What for?  Redundancy of ready shares.  And, so, the issue I'm trying to address is how to efficiently and gracefully switch the READ/WRITE focus to another server.
One way, that I'm on the path to complete is to change our drive map GPO targets.
Another way would be through DFSR name space.
But, as in my last reply:

Right now, I don't know how to do that.  i.e. keep a number of fileservers in DFSR but have DFSR only direct access to ONE of them.

How is that done?

The way to gracefully change access from one server to another is DFS Namespace.

kevinhsieh:  Yes, I understand.  Thank you for checking me on that.
My concern, since I've never done it, and am in the middle of trying it. is how one goes about:
keeping a number of fileservers in DFSR but have DFSR only direct access to ONE of them. 
Perhaps it seems trivial but right now it's a foreign concept to *me*.   I don't picture the dialog where that would be done.
Sorry to be so pedantic.