Shortcuts now point to shares

[Tim Gildersleeve]

Yes it seems to be the Disable link file tracking - for some reason I have
always missed this in my policies.  The $ shares however I need because I
need to roll out remote updates of Sophos anti-virus.

> -----Original Message-----
> From:	Lubomir [SMTP:lubo at ru.acad.bg]
> Sent:	Wednesday, March 07, 2001 2:44 PM
> To:	samba-ntdom at samba.org
> Subject:	Re: Shortcuts now point to shares
> 
> I've had similar problems + driveleter for the shortcuts path changes
> to different leter and many drivemappings occured to de same sharing.
> I've found that these policy settings fixes completely the problem:
> in winnt.adm (I've got 2 versions - the bigger is the truth) find
> "Automatically create <drive letter>$ and Admin$ shares" - sure NO
> "Disable link file tracking" - sure YES
> 
> 
> Tim Gildersleeve wrote:
> 
> > Ive had a similar problem with a completely winnt network.  A group of
> > workstations have a centralised startmenu, and on occasions when
> choosing a
> > shortcut it has tried to open the application accross the network so
> instead
> > of running "C:\Program Files\App\App.exe"  it has been trying to run
> > "\\GRCD9\C$\Program Files\App\App.exe"  This is very wierd.  I got round
> > this by opening the affected shortcuts and editing them to point to the
> > right place.  But every now and then, they are changed again.  Oh, and
> in
> > this case, the users in question have only read access to the shortcuts.
> It
> > seems that winnt is changing them itself.  
> > 
> > So this doesnt seem to be just a samba thing.
> > 
> > Tim Gildersleeve
> > 
> > 
> >> -----Original Message-----
> >> From:	Jason Todd [SMTP:todd.4 at wright.edu]
> >> Sent:	Monday, March 05, 2001 3:40 PM
> >> To:	samba-ntdom at samba.org
> >> Subject:	Shortcuts now point to shares
> >> 
> >> Here's another good one by NT in my lab - Samba 2.0.7 on RedHat 7.0
> (linux
> >> 2.2.16-22smp) server, Windows NT 4.0 SP 6 workstations.
> >> 
> >> All of a sudden, many of my users' Start Menu and Desktop shortcuts
> don't
> >> work correctly anymore.  When selected, they prompt for a username and
> >> password for '\\WORKSTATION\ADMIN$' where WORKSTATION is some other
> >> computer in the lab.  Apparently the account must be a local account
> for
> >> WORKSTATION, but the only local account(s) on the machines are the
> default
> >> when NT is installed (Administrator et al).  I examined the LNK files
> in
> >> question, and each has the "local volume" AND "network share" bits set,
> >> meaning the target can be found on a local drive (normal) in addition
> to a
> >> network share on some other workstation (abnormal in these
> circumstances).
> >> It is apparently trying the network share first, though I have no idea
> >> why.  I was able to patch a screwed up LNK file by turning off the
> >> "network share" bit and it worked, so I'll probably have to write a
> small
> >> utility that strips that out of each and every shortcut in my users'
> >> profiles.  Or, does anyone have any better ideas?  I'm very interested
> in
> >> seeing if anyone else has experienced this.  The problem is just
> getting
> >> worse, as more and more shortcuts are continually being affected.  I
> can't
> >> tell if one machine in particular is screwing up the shortcuts.
> >> 
> >> P.S.  In the near future I'm going to turn off local caching of
> profiles,
> >> which may prevent this from happening again.  Prevention aside, I need
> a
> >> FIX first...
> >> 
> >> Jason Todd
> >> 
> >> ______________________________________________________________________
> >>  This message was made possible by Jason Todd and by viewers like you.
> >>  Senior Help Desk Assistant, Computing and Telecommunication Services
> >>  Wright State University
> >>  Reply to todd.4 at wright.edu or jasontodd at bigfoot.com
> >> 
> 
> Lubomir Velkov
> University Of Rousse
>