Link to home
Start Free TrialLog in
Avatar of tarros
tarros

asked on

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.

Massimo.
Avatar of Kimmyel
Kimmyel
Flag of Sweden image

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?

Regards
Avatar of tarros
tarros

ASKER

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"
       If Exist ("T:\SOMESHARE\SOMEFOLDER\SOMESHORTCUT.lnk")  
                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"
       EndIf
EndIf

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)
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:

http://www.onlinetoolworks.com/help/SB32AdmnNetwork_Drive_Mappings_and_NET_U.htm

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.
Avatar of tarros

ASKER

zcrammond:
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.

Regards

Massimo.
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
ASKER CERTIFIED SOLUTION
Avatar of Vanguard_LH
Vanguard_LH
Flag of United States of America image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial