shortcuts : this is driving me insane...

[kennysarmy]

OK. I've done this a hundred times and never had a problem....with any other software....

 

1. Created an admin MSI install of the software In Print v2 by Widgit.

 

2. Test deployed the msi to a small group of computers in one GPO.

 

3. I have a common desktop for students which points back via a GPO to \\servername\netlogon\Pupils\StartMenu\

 

4. I test the software logged in as me from the pc's start menu and all works fine.

 

5. I copy the icons to run the software to the students desktop and try from another computer in the test GPO.

 

6. The icon immediately tries to point itself at the computer used to create the icon........arrghhhhhhh

 

 

Previously I've done exactly the same procedure with other software and the shortcut points at the C:\ drive and if the computer has the software installed away it goes...if not it just complains the shortcut is not valid...

 

WHY is it now not happy that even with the software installed and the shortcut pointing at the right location does it try and re-route itself back to the originating pc.

 

It happens from computer A to B and I've tried the other way around, ie using computer B to create the shortcuts - then when you launch from computer A it tries to connect to computer B to run the software.....

 

arrghhhhh

 

any ideas?

[jamin100]

re-create the shortcut in the common desktop folder.

File > New > Shortcut > Browse to application

 

Then go to another machine with the same software on and try loading the software with the new icon.

[kmount]

Suggests (and I could be wrong) that the shortcut was created FROM a different machine to the one you have it installed on.

 

IE, logged onto server/admin workstation creating shortcut but browsing via \\machine2\c$\Program Files\mysoftware.exe instead of doing it on the actual workstation with the software and using C:\Program Files\mysoftware.exe.

 

I've done this countless times because you can't "just pretend" to use C:\Program Files\mysoftware.exe if said file doesn't exist because windows thinks you're being daft.

 

I could be wrong, but that's how I've experienced it.

[kennysarmy]

re-create the shortcut in the common desktop folder.

File > New > Shortcut > Browse to application

 

Then go to another machine with the same software on and try loading the software with the new icon.

 

Yep tried that.

step 1 is fine - create the new shortcut in the common desktop folder and also make the icon read only.

 

step 2 go to the other machine and although the same software is present in the same location the icon looks like it's dead - like the software is not installed. Logged on as a student it says the location is unavailable...If I log on with admin rights and hover over the icon it is pointing correctly at C:\program files etc....but when i double click to run the program it is using the path to the original machine that created the shortcut...if i close the program the right click the shortcut icon and choose properties then find target it it changes the C:\ path to the route to original machine ie \\machine name\c$\program files....

 

[SYNACK]

It may be worth putting the link on the shared desktop as is then simply modifying the properties directly to point to the correct location if you have not done so already. This is how I usually get around this issue if it is being annoying like this.

 

You could also try applying this policy in GP:

 

User Configuration > Administrative Templates > Windows Components > Windows Explorer : Do not track Shell shortcuts during roaming

 

to switch of this rewriting behaviour entirely.

[kennysarmy]

It may be worth putting the link on the shared desktop as is then simply modifying the properties directly to point to the correct location if you have not done so already. This is how I usually get around this issue if it is being annoying like this.

 

You could also try applying this policy in GP:

 

User Configuration > Administrative Templates > Windows Components > Windows Explorer : Do not track Shell shortcuts during roaming

 

to switch of this rewriting behaviour entirely.

 

If I create the link on the shared desktop it ONLY works from the pc I create it from.....if I check or modify the path to the C:\program files....immediately I try it from another computer it alters it to the \\machine name\ path...

 

I don't understand it - I've got plenty apps that run fro C:\ eg. MS word...they have never complained or acted up like this can't think what has changed ...or is it to do with this specific application...

[kennysarmy]

well just tried creating a shortcut to notepad from machine A and accesssing the shortcut from B to do a find target and it works....fine...

 

so the issue is somehow with the exe for this software? you think?

[SYNACK]

@kennysarmy - try the policy setting as that should get rid of the issue. Windows handles the shortcuts so the software itself can't really have an impact on it.

[kennysarmy]

@kennysarmy - try the policy setting as that should get rid of the issue. Windows handles the shortcuts so the software itself can't really have an impact on it.

 

cheers - will set this up today and give it a go...

 

will report back...

[User3204]

We used to have this, with certain users that had access to the shared desktop, and they ended up dragging the shortcuts around with them, what I had to do was make the shortcut read-only.

 

I started doing this with just the properties tab, but I also have made it so that the folder is only writeable by certain users, and this is not a user that logs on.