• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 749
  • Last Modified:

Network driver letter in a link substituted by UNC address.

Good morning.

We have an application that resides (executable, parameters, configuration) on a W2003 server shared directory accessible from all users.
On every PC we connected manually the shared directory assigning drive letter "T:".
We create a shortcut on every PC desktop to run the executable of the application
as per the following example:

T:\maindirectory\exedirectory\program.exe     param1 param2

Sometimes users call us telling that the program do not longer work (or, more precisely, do not print) and we noticed that it is because the link has been modified in

\\Servername\maindirectory\exedirectory\program.exe   param1 param2

Giving the way the software is designed, it is justified that, with this change, printing function stops to work but this is not the problem.
The problem is why this change in the link happens without any (apparent) external intervention.

It seems that it take place in Win7 and Vista clientsand not in Win XP clients.
All PC in a Win2003 domain.
Thanks in advance for your help.

1 Solution
So basicly the shortcut on desktop change only effect users with Win7 and Vista.
Is this shortcut added manually on installation or by loginscript/any other script?

tarrosAuthor Commented:
Manually for each PC with "reconnect at bootstrap" option.

Thanks and rgds.
is it possible that the desktop icons are loading before the logon script creates the T drive? Windows 7 and Vista are probably recreating the target directory and start in directory on the shortcuts to go straight for the UNC path rather than the drive letter.

not sure if you use kix scripts or are familiar with creating logon scripts but you could try something like the following to generate the shortcut when a user logs on:
If InGroup("GROUPT")
?"Group		: T drive mapped"
                Shell "$srtexe -f -n c:\docume~1\%username%\Desktop\SOMESHORTCUT -t T:\SOMESHARE\SOMEFOLDER\SOMESHORTCUT.lnk -d T:\SOMESHARE\SOMEFOLDER -i T:\SOMESHARE\SOMEFOLDER\SOMESHORTCUT.ico"

Open in new window

which will generate a shortcut if the T drive exists pointing the directory (-d) to the T drive location, and also the icon (-i) (change the desktop path to the one for windows 7 and vista)
Free Tool: Site Down Detector

Helpful to verify reports of your own downtime, or to double check a downed website you are trying to access.

One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.

Something in the app requires the drive letter to find its other files; otherwise, the UNC would be sufficient.  That is, this is an old application that doesn't understand how to employ a UNC path used to find its executable file and then to find its ancilliary files.  This old app (or possibly a batch file) needs the drive letter and relative path to find its other files.  

Why not define the shortcut to run a batch file that includes the mapping of the network share?  Add the 'net use' command to your script just before running the program that seems to require a fixed drive letter to find its ancilliary files, as in:

net use t: <UNCpath> [<password> /user:<accountname>] /persistent:yes
t:\<path>\app.exe <parms>
net use t: /delete

You didn't mention if logging was required so it's shown as an optional bracketed parameter.  I'm not sure if the /persistent:yes parameter is needed for your app but it doesn't hurt to use it if you later follow with deleting the mapping.  Understand that the host providing the share can dictate if idle connects get disconnected (so they have the resources to support more current connect requests) which means the drive letter won't be functional or there'll be a delay to reconnect.  If the app remains idle for long periods of time (i.e., doesn't access the shared resource and just uses the code it got loaded into memory) then the host of the shared resource would see the connection was idle.  Apps that can be referenced and run using a UNC doesn't have this problem.  It's a problem when using mapped drives.  Run 'net use /?' for help, or read:


Don't know what you mean by "manual" for assigning the drive letter.  Aren't you pushing via policy a login script that assigns the mapping to drive T: when users log onto the domain?  Aren't you pushing other mappings, like to a shared resource where users are to find batch files or other commonly accessible software?  You might not assign T: in the login script but the mapping to the common company resources might include common batch scripts so your batch file would be on that commonly mapped resource (so you don't have to go storing a copy on every employee's workstation).

I suspect what you are seeing is Windows' attempt to resolve a shortcut's target when it isn't known or no longer valid.  The drive letter isn't valid because the mapping isn't defined anymore so Windows finds (resolves) the resource by using the UNC to it.  In prior versions of Windows, I thought this auto-resolution only occurred when you tried to open or modify a shortcut (i.e., you had to go look at its properties).  Maybe Windows 7 (or even Vista) are proactive in fixing shortcuts that are no longer valid (because the drive mapping is no longer defined) or the users are using some tweaker, cleanup, or security product that tries to help by automatically fixing invalid shortcuts.  I've seen several cleaner or fix-up tools that go scanning shortcuts to "fix" them.  If t: is no longer a defined (mapped) drive then the shortcut isn't valid anymore under the current environment (and why the use of such cleanup/fix-it tools by uneducated users often leads to corruption of the registry or shortcuts).  I'm only guessing here (regarding users looking at the properties of shortcut, using cleanup/fix tools, or some pro-active Windows feature) because I primarily still use Windows XP (and have only used Vista at work when I had to and rarely spend time on 7).  It works on XP where you asked but is the problem is exhibited on Vista/7 where you didn't ask.

UNC resolution to a resource does not require a login.  A UNC path doesn't have a password parameter.  Permissions are used to decide which accounts can access the resource.  Mapped drives may require a login.  Note that 'net use /?' shows the password is optional because the resource may grant permissions to accounts in the domain or OU or the user must login to use that resource.

For shortcuts, UNCs are preferred to find the resource.  Use mapped resources only when forced to do so as a limitation for the install or use of an old app.  See if using a batch script to map the resource, run the app, and optionally delete the mapping gets a more stable solution for an old app that requires a drive letter be in its resolved path.
tarrosAuthor Commented:
is it possible that the desktop icons are loading before the logon script creates the T drive?"

No logon script used.
When we configure a PC we connect the shared directory to the network drive T: browsing
the network, pointinf a the appropiate directory and the assigning the appropratiate letter.

Vanguard LH.

Thanks for your long reply.
Are you telling that host decide to drop a network drive connection despite we create
with "reconnect at reboot"?
Back to your questions:

1) we need persistent connection
2) We do not use any login script
3) Every time we install a PC we create network disk and the we forget for
    the rest of PC life
4) User do not apply any fix or tool or whatever else.
5) For the structure of our software we need network drive defined
6) Login is not a problem because all users/server are in the same domain and
    every user logs at the beginning of the day.


but, the I'm not concerned if our our software works or not.
 if our software works or not, I told this fact only to specify that the user is not aware of the problem until he cannot print from the software.
Also, user do not run any fix or tweaker or whatever else, simply, sometimes, looking at the shortcut, the letter T: has been substituted by UNC name of the server
You are mapping a networked resource.  Mapping doesn't guarantee that you will actually get a connection.  Timeouts are involved; e.g., when you log into Windows, it attempts the mapping and connect but the connect may fail.  Servers get busy.  They may enforce a maximum number of concurrent connections that the number of your employees will exceed.  There may be licensing restrictions on the app that, say, limits the number of concurrent connects to a maximum that you have exceeded.  Even if the mapping succeeds doesn't mean the connection remains forever thereafter during your Windows session.  You can lose the connection to a mapped drive for the reasons already noted or simply networking issues.  For example, the server may disconnect connections that are idle after some expiration interval has elapsed.  Another possibility for disconnection is how the user has configured their own client host (see http://support.microsoft.com/kb/812933).

Sticking with just the mapping for now, does the problem still occur if you map the network drive (and ensure a successful connection) just before you run the remote app?  Have you tried replacing the shortcut calling the remote app (via drive letter) with a batch file that runs the 'net use' command to check if you really do have the connection?  If the connection failed, you probably get error output from the net command (followed by the error trying to access the app on an undefined drive assignment).

Are these users opening Windows Explorer to note if there is a red X icon on the D: drive mapping before they attempt to run that networked app?  If they don't want to be bothered to verify the mapping is still valid and there is actually an active connection then they're either stuck with finding out when they try to use the disconnected mapped drive or have to use something other than a direct link to the mapped app (like the suggestion of using a batch file that uses the 'net use' command).
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Free Tool: IP Lookup

Get more info about an IP address or domain name, such as organization, abuse contacts and geolocation.

One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now