locked
Is there a way to set Target Type when creating a shortcut to network folder? RRS feed

  • Question

  • I have a script that creates a shortcut to a network drive folder that I am deploying through SCCM. The short cut gets created but with the target type set as "File" instead of "File Folder" and does not work. Here is the script:

    1   [void][System.Reflection.Assembly]::LoadWithPartialName("Microsoft.VisualBasic") 

    3   Remove-Item "C:\Users\*\desktop\OR Resources.lnk" -Force
    4   Copy-Item ".\icons\OR Resources.ico" "C:\Windows" -force


    7   $WshShell = New-Object -ComObject WScript.Shell

    9   $ORResources = $WshShell.CreateShortcut("c:\users\public\desktop\OR Resources.lnk")
    10  $ORResources.TargetPath = "\\fmdata01\sdrive\shared\OR_Resources\"
    11  $ORResources.IconLocation = "C:\Windows\OR Resources.ico"
    12  $ORResources.Save()

    Any suggestions would be very helpful. Thank you

    Friday, June 19, 2020 3:55 PM

Answers

  • Issue needs to be asked in SCCM forum since it is specific to SCCM.

    First recommendation is to remove the "\" at the end of the path.

    Also "TargetPath" refers to a file.  Accessing a folder may not work when this is deployed with SCCM which is why I suggest posting in SCCM forum.

    All examples and all documents specify that "TargetPath" is a file path and not a folder path.


    \_(ツ)_/

    • Marked as answer by Skooters Friday, June 19, 2020 8:16 PM
    Friday, June 19, 2020 8:11 PM

All replies

  • Hi Skooters,

    have you already tried something like this:

    $SourceFileLocation = "\\fmdata01\sdrive\shared\OR_Resources\"
    $ShortcutLocation = "c:\users\public\desktop\OR Resources.lnk"
    $WScriptShell = New-Object -ComObject WScript.Shell
    $Shortcut = $WScriptShell.CreateShortcut($ShortcutLocation)
    $Shortcut.TargetPath = $SourceFileLocation
    $Shortcut.Save()


    Friday, June 19, 2020 4:31 PM
  • So basically you are creating a variable and then setting parameters to those variables instead of setting them directly. Interesting. I will try this.
    Friday, June 19, 2020 7:32 PM
  • OK, It is working when I play it through PowerShell ISE. Now when I try to deploy the script using SCCM it creates the icon as a target type of file and not file folder.

    Friday, June 19, 2020 8:01 PM
  • Issue needs to be asked in SCCM forum since it is specific to SCCM.

    First recommendation is to remove the "\" at the end of the path.

    Also "TargetPath" refers to a file.  Accessing a folder may not work when this is deployed with SCCM which is why I suggest posting in SCCM forum.

    All examples and all documents specify that "TargetPath" is a file path and not a folder path.


    \_(ツ)_/

    • Marked as answer by Skooters Friday, June 19, 2020 8:16 PM
    Friday, June 19, 2020 8:11 PM
  • Thank you. I have taken this to the SCCM Forum. Thank you for your help.
    Friday, June 19, 2020 8:27 PM
  • Why not using pure Powershell? With New-Item -ItemType SymbolicLink you can create a link to a network share.

    Live long and prosper!

    (79,108,97,102|%{[char]$_})-join''

    Friday, June 19, 2020 9:23 PM
  • Why not using pure Powershell? With New-Item -ItemType SymbolicLink you can create a link to a network share.

    Live long and prosper!

    (79,108,97,102|%{[char]$_})-join''

    Yes but a SymbolicLink is not a shortcut and doesn't behave like a shortcut.  It all depends on what is intended.  It seems that the OP wants a shortcut that opens Explorer to a folder.  A SymbolicLink will not do that.


    \_(ツ)_/

    Friday, June 19, 2020 9:31 PM
  • It seems that the OP wants a shortcut that opens Explorer to a folder.  A SymbolicLink will not do that.

    What do you mean? Actually I'm using shortcuts like this for that particular purpose. Or did I get something wrong?

    Live long and prosper!

    (79,108,97,102|%{[char]$_})-join''

    Friday, June 19, 2020 10:32 PM
  • Are you saying you load your desktop with SymbolicLinks as shortcuts to open folders?

    Also you can copy a shortcut to a new location and it still works.  You cannot do the with a SymbolicLinks .

    Yes - some things work in similar ways but one is not a replacement for the other.  It all depends on your purpose.  Occam's Razor says to use the simplest solution first.


    \_(ツ)_/

    Friday, June 19, 2020 10:45 PM
  • Are you saying you load your desktop with SymbolicLinks as shortcuts to open folders?

    Not the desktop, but yes. I do not like drive letters for network shares at all. That's why I collect all links to the network shares I need in a particular folder.

    Also you can copy a shortcut to a new location and it still works. You cannot do the with a SymbolicLinks.

    Actually you can. It works at least on my environment I use at work. (Windows 10 1809)

    Occam's Razor says to use the simplest solution first.

    I definitely agree with that. ;-)


    Live long and prosper!

    (79,108,97,102|%{[char]$_})-join''

    Friday, June 19, 2020 11:11 PM
  • Yes - you can use it that way but it all depends on the purpose.  A link is a sledge hammer compared to a simple shortcut.

    The issue is - do you want teh shortcut to be a list of files in a foilder or just a file in a folder.  If you don't want the shortcut to change the behavior of copy and move then use s shortcut.  To the file system the lionk looks just like a file or folder where a shortcut looks like a "lnk" file.  Side effects are the whole game here.


    \_(ツ)_/

    Saturday, June 20, 2020 3:08 AM
  • Hmmmm ... I thought New-Item -ItemType SymbolicLink creates exactly this - a "lnk" file in the file system. At least it looks to me like this on my system. I cannot tell any difference between shortcuts I create with the GUI or with this Powershell cmdlet.  OK - there is one difference. I do not need Administrator privilege creating a shortcut on the GUI but I need it with Powershell.

    Live long and prosper!

    (79,108,97,102|%{[char]$_})-join''

    Saturday, June 20, 2020 8:41 AM
  • I think this will help to explain the difference.  It  is subtle but impacting under many circumstances.

    The choice is up to the user.  If it is what is needed and the collate5ral effects are not an issue then it is a good choice.  

    Always beware the small print.


    \_(ツ)_/

    Saturday, June 20, 2020 9:03 PM