4

We use SCCM 2012 R2, server 2012 servers, and Windows 7 clients. Student machines are typically Win7-64.

I created a script to install Eclipse, basically, create a directory and copy the files (Eclipse has no installer and is 32 bit software). In my script, to make things nicer for the students, I want to put shortcuts on the desktop and in the Start Menu. The code is this:

REM Put icon on desktop
copy "Eclipse Mars (64).lnk" "C:\Users\Public\Desktop"
rename "C:\Users\Public\Desktop\Eclipse Mars (64).lnk" "C:\Users\Public\Desktop\Eclipse Mars.lnk"

However, when the link appears on the client desktop, the correct Target of "C:\Program Files (x86)\Eclipse\eclipse.exe" changes to "C:\Program Files\Eclipse\eclipse.exe" and hence doesn't work (same with Start In).

What is changing the shortcut contents to the wrong Program Files directory?

Lastly, while I'm mentioning Eclipse in this example, it happens with any 32 bit shortcuts scripted onto a 64 bit machine.

failure
  • 215
  • 1
  • 3
  • 12
  • If you want to use a batch file with sccm like this you would probably have to make an application not a package/program. Programs are always executed with a 32bit host which leads to your problem. There are a couple of workarounds. To figure out which one is best suited for you I'd need to know whether you would consider a different script language (vbs or powershell) and whether windows in your language has a junction to programfiles that has a different name than "program files" (basically if you have a 3rd program files folder with a little lock if you view all files in explorer) – Syberdoor Oct 18 '16 at 12:20
  • @Syberdoor: It seems you are offering alternate solutions, without even analyzing this specific issue. What is changing the target location inside the .lnk file after a simple copy operation? And why would this not happen with, say, VBScript or PowerShell? – IInspectable Oct 18 '16 at 22:23
  • @IInspectable Windows can change the target of a lnk if you copy it. I've seen this a couple of times, so I'd assume this is what happens here (probably it doesn't. instead the target is saved via environment variable but then simply expanded). I don't know how you come to the conclusion that I did not analyze this as the script is super simpel? There is one copy command which does not change files, end of analysis? Everything else is guesswork anyway. With Vbscript and powershell you can create the lnk instead of copying it, which is something different. You can use seperate paths per bitness – Syberdoor Oct 19 '16 at 07:50
  • @Syberdoor: *"Windows can change the target of a lnk if you copy it. I've seen this a couple of times"* - This is not a problem analysis. Why does it change the target? Under which conditions? How to prevent it? Answers to those questions constitute an analysis. While generating the .lnk file from scratch may be a pragmatic workaround, an explanation as to why the link target changes would be even more helpful. – IInspectable Oct 19 '16 at 10:11
  • 1
    This is wild speculation: Maybe the link target gets changed on copy, due to [Distributed Link Tracking and Object Identifiers](https://msdn.microsoft.com/en-us/library/windows/desktop/aa363997.aspx). While I've only heard that it works the other way around (i.e. a link can resolve a target, even when renamed or moved, see [IShellLink::Resolve](https://msdn.microsoft.com/en-us/library/windows/desktop/bb774952.aspx)), maybe the Shell also tries to adjust the target, when the link itself moves. Again, this is speculation only. – IInspectable Oct 19 '16 at 10:46
  • @IInspectable sure, it's always nice to get to the root of the problem. But the main reason people come here imo is to get help. Someone asks a question tagged with sccm and wants help, I have a lot of experience with how the sccm works and seen a lot of things so I think I can help. That's also why I left a comment asking for more detail and did not just write an answer. I don't know the reason but I have seen and countered the behaviour. Imo this is what people are looking for. The rest is bonus. – Syberdoor Oct 19 '16 at 10:55
  • Could it be because you are running the 32bit cmd.exe? Have you tried explicitly calling c:\windows\sysnative\cmd.exe? – langstrom Oct 27 '16 at 14:49

2 Answers2

0

I've done a bit of research, you should try this:

ren "Eclipsce Mars (64).lnk" eclm.tmp
copy "eclm.tmp" "C:\Users\Public\Desktop"
ren "C:\Users\Public\Desktop\eclm.tmp" "C:\Users\Public\Desktop\Eclipse Mars.lnk"
ren eclm.tmp "Eclipsce Mars (64).lnk"

What I've done:

  1. Renamed the original .lnk to eclm.tmp
  2. Copied eclm.tmp to Desktop
  3. Renamed Desktop\eclm.tmp to Eclipse Mars.lnk
  4. Renamed original .lnk back to normal.

This should Bypass Windows' tendency to change .lnk files' contents.

Let me know in the comments and the vote counter if this works!
~CSS

cascading-style
  • 488
  • 9
  • 23
0

You can create real Windows shortcuts using a simple VBS script that can be called from your main batch file.

Main batch file:

REM Put icon on desktop
call "Create Shortcut.vbs" "C:\Users\Public\Desktop\Eclipse Mars (64).lnk" "C:\Program Files (x86)\eclipse-mars\eclipse.exe" "C:\Program Files (x86)\eclipse-mars"

VBS "Create Shortcut.vbs":

' Check the number of parameters
If 3 <> WScript.Arguments.Count Then
    WScript.Echo "Please call this file using the following parameters:"
    WScript.Echo
    WScript.Echo "   LINK PATH   - Absolute path where the shortcut file will be created"
    WScript.Echo "   TARGET_PATH - Absolute path of the target program"
    WScript.Echo "   WORKING_DIR - Working directory used by this shortcut"
    WScript.Quit(1)
End If

strLinkPath   = WScript.Arguments(0)
strTargetPath = WScript.Arguments(1)
strWorkingDir = WScript.Arguments(2)

set oShell = WScript.CreateObject("WScript.Shell")

set oShellLink = oShell.CreateShortcut(strLinkPath)
oShellLink.TargetPath       = sTargetPath
oShellLink.WorkingDirectory = strWorkingDir
oShellLink.WindowStyle      = 1
oShellLink.Description      = ""
oShellLink.IconLocation     = strTargetPath
oShellLink.Save
JonathanDavidArndt
  • 2,518
  • 13
  • 37
  • 49