Why Use UNC?

[dee]

I have read often that using UNC is preferable. Could someone clarify why?
Also, I had read somewhere that this adds to security because users can't see
actual drive letters which they would with mapped drives. Is this another
reason?

Thanks so much for any clarification.

 

[Rick Brandt]

I have read often that using UNC is preferable. Could someone
clarify why? Also, I had read somewhere that this adds to security
because users can't see actual drive letters which they would with
mapped drives. Is this another reason?

Thanks so much for any clarification.

You might map a share to drive "J" and another user might map the same share to
drive "K" while a dozen other users might not have that share mapped to a drive
at all. A UNC always works regardless of all of that (assuming the user has
permissions to the share).

Even if users didn't muck with their mapped drive settings you would have to set
up the desired mapped drive on every user's PC. With UNC there is no
requirement to do that.

 

[Pieter Wijnen]

Also, if using Windows 2000 server & Citrix or Terminal Services the drive
mapping can be (temporarily) lost when another user (the first one to log in
& map the drive) logs out.

Pieter

 

[Arvin Meyer [MVP]]

Before the use of Active Directory (AD) and more centralized administration
users more frequently used different mapping to a location on the server.
Now, that's less likely to happen on a well managed network. Most login
scripts nowadays push out the mappings. A user with local admin privileges
can still override them so UNC is still useful on less managed networks.

Server drives can be different that network mapped drives so it doesn't
really matter if an individual has UNC or not for the application he is
working on, but if he has permissions to wander around, knowing that S:\ is
a root drive for the folders in that application can lead him to look for
other things on the S:\ drive.

It's been my experience that on newer networks, drives are mapped more often
than not, but there are still quite a few UNC setups.

 

[David W. Fenton]

It's been my experience that on newer networks, drives are mapped
more often than not, but there are still quite a few UNC setups.

This seems strange to me, as I see UNC as a more "modern" approach
to accessing network resources than mapping drives, which I
associate with the horrendous old Novell Netware networks that used
to be ubiquitous.

To me, the ideal is the UNIX style of mounting resources, where you
don't give them drive letters, but you give them useful,
user-friendly names, and you mount your network resources according
to each user group's needs.

For the clients of mine where I'm the sysadmin, there are no mapped
drives, only UNC links and paths. With Win2K and WinXP, this makes
it very easy, because of the "smart" nature of My Network Places,
which automatically creates links to UNC paths that you use often.

For the clients where I'm not the sysadmin and mapped drives are
used, what I see all the time is people going to one mapped drive's
root and then navigating down through a ridiculously deep hierarchy
to the things they want, even when there are UNC shares that are not
drive mapped that could get them there directly.

Could drives be mapped intelligently? Yes, of course, within the
limits of the number of available drive letters.

Are they in practice? Not at all, in my experience.

 

[Tony Toews [MVP]]

A UNC always works regardless of all of that (assuming the user has
permissions to the share).

Unless of course the server gets reworked and it's name gets changed.

Tony

Even if users didn't muck with their mapped drive settings you would have to set
up the desired mapped drive on every user's PC. With UNC there is no
requirement to do that.

My relinking logic works as follows
- open a recordset against a table in the backend. If it works then
exit the relinking logic.
- read the backend location from an INI file on the client system.
If opening a table in that alleged backend works then relink all the
tables and exit the relinking logic.
- prompt the user for a location of the backend. Test and exit the
relinking logic.

So that easily handles the different driver letter situations. It's
more work of course from the developers viewpoint.

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/

 

[James A. Fortune]

I have read often that using UNC is preferable. Could someone clarify why?
Also, I had read somewhere that this adds to security because users can't see
actual drive letters which they would with mapped drives. Is this another
reason?

Thanks so much for any clarification.

I prefer mapped drives. Registry settings can be changed that hide some
mapped drives, yet allow access to data on the mapped drives so that
users can't go poking around. I haven't mentioned that before because
it's more secure if fewer people hear about it . I can take Access
files home and easily set them up to work as if they are on a network so
that I can be confident that changes made at home will work back at the
office. When servers change, a simple reassignment pushed out through a
login script works fine. I would like to know if there's a reason to
prefer UNC in addition to David's friendly name and letter limit
reasons. Also, maybe there's an easy way to set up a UNC path on my
computer at home without networking another computer, but I haven't
looked much into that possibility.

James A. Fortune
(e-mail address removed)

 

[Arvin Meyer [MVP]]

In the enterprise atmosphere I've been working on lately, NetBIOS is often
turned off and there are login script which map drives to specific places on
the server. For instance:

E:\CorporateData\ LocalData\ClosingDept\Database\Backend.mdb

may be seen in a mapping of:

S:\Database\

Users do not have permissions to map or even to explore closer to the root.

There are hidden shares that only IT or certain departments see. I haven't
administered a network in almost 3 1/2 years. All I can report on is what I
see in corporate IT setups.

 

[Rick Brandt]

In the enterprise atmosphere I've been working on lately, NetBIOS is often
turned off and there are login script which map drives to specific places on
the server. For instance:

E:\CorporateData\ LocalData\ClosingDept\Database\Backend.mdb

may be seen in a mapping of:

S:\Database\

Users do not have permissions to map or even to explore closer to the root.

There are hidden shares that only IT or certain departments see. I haven't
administered a network in almost 3 1/2 years. All I can report on is what I
see in corporate IT setups.

Our company strictly uses logon scripts to synchronize the clock and to push AV
updates. I know that there are corporate environments where the IT group rules
with complete control of such things, but I doubt that it is the norm until you
get into pretty large outfits.

 

[David W. Fenton]

In the enterprise atmosphere I've been working on lately, NetBIOS
is often turned off and there are login script which map drives to
specific places on the server. For instance:

E:\CorporateData\ LocalData\ClosingDept\Database\Backend.mdb

may be seen in a mapping of:

S:\Database\

If NetBIOS over TCP/IP is turned off, how is the server name mapped?
Obviously, it has to be done with WINS or DNS resolution of the
server name to an IP address. If that is set up for the mapped
drives, it will also work for plain old shares.

NetBIOS over TCP/IP being off really is not an issue, as SMB
networking only works in that environment if there's some form of
DNS/WINS doing the name-to-IP mapping. UNC will work just fine in
that environment, too.

Controlling access with UNC is a matter of creating the appropriate
non-root shares and then providing access to the appropriate users.
You can, of course, turn off LIST permission for the users you don't
want to even see the contents of the share in My Network Places. But
that issue is present even if you're mapping drives, as any share
that can be mapped can be viewed.