Disable desktop shortcuts and explorer context menu with package preferences

[christianrondeau]

Use cases:

• When I install GitExtensions and Git. I want context menu for GitExtensions, but I don't want context menu for Git (a.k.a. "cheetah")
• I don't want VLC's context menu
• I want 7zip context menu
• I never want desktop shortcuts, but I do want Start Menu shortcuts

Here's the implementation I suggest:

• The name of this feature is "Preferences"
• The name of each "Preference" is always positive (e.g. explorercontextmenu)
• A global preference can be set "by default" for all packages: choco preferences disable desktopshortcuts explorercontextmenu *. The settings would be saved in "C:\ProgramData\chocolatey\config\chocolatey.config" under a <preferences> section
• Preferences can be set by package by prefixing -no: choco install mypackage -no-desktopshortcuts -no-contextmenu
  • When running choco upgrade, the last preferences will be used (unless preferences are provided again)
  • A per-package preference always takes precedence over the global preferences
  • When providing preferences to upgrade, they overwrite the previous package preference
  • The setting would be saved in "C:\ProgramData\chocolatey\lib-cfg\package-name\lib.config"; it would only contain a <preferences> section for now
• When a preference is specified, the package maintainers should:
  • Provide the corresponding argument to the installer command line, or;
  • Provide a PowerShell script that undoes whatever the installer did, or;
  • Ignore the preference, and chocolatey would report that this package does not support that preference
• Each package would be responsible for documenting what preferences they support
  • The Chocolatey guide would strongly suggest using only preferences from a global and standardized list to avoid variations on preferences naming
  • I suggest starting with explorercontextmenu and desktopshortcuts, as those are the two obvious and most visible contenders

Read about the whole discussion here: https://groups.google.com/forum/#!topic/chocolatey/wQmapfXr-rs

[pyhedgehog]

You want something like USE flags of Gentoo Portage. It's very useful system, but it requires carefully guided repository. As I see right now chocolatey provides much more freedom for package authors. It has some features and drawbacks...

[christianrondeau]

Thanks @pyhedgehog - that's exactly what I'd like to see. I'll bring that back in the discussion at https://groups.google.com/forum/#!topic/chocolatey/wQmapfXr-rs and potentially update that issue

[ghost]

At least *no desktop shortcuts should be an option. I don't need a programm on desk when i open it via file the assoc programm.

*Edit: of course no

[ferventcoder]

@xtf1 I'm a huge fan of no desktop shortcuts taking up my nice clean desktop. I just want to ensure we get this right.

[dhs-rec]

Yeah, after every choco upgrade run, I need to remove those desktop shortcuts. Would really be nice to have an option to suppress their creation in the first place.

[bcurran3]

Due to reasons mentioned such as the many different "standard" installers, I can see how this is a big PITA.

Thinking in Chocolatey baby steps, if a preference was created for not wanting shortcuts, it seems easy to stop it at the Chocolatey level by checking the preference and negating Install-ChocolateyShortcut when called.

I'll join the I-hate-a-million-shortcuts-popping-up-on-my-desktop club, but I find the topic a trivial matter. I'd argue it's easier to delete shortcuts I don't want than hunt down and create ones I do want.

I have a group policy that deletes all my normal program shortcuts that add an icon post installation and upgrade - works great! :)

Going back to the real problem of so many installers and so many possible switches and scenarios, it seems to me a possible solution would be to get a list of current icons on the desktop (current user and public) before an install of a package, then compare that to a new list post install of the package, and delete the delta .LNKs. IMHO this just feels strange being in Chocolatey core but could probably be implemented via an extension. Instead of messing with adding to the config/preferences/settings users could just install the extension if they don't want shortcuts. Then the various Chocolatey install functions could check for the extension and use it if installed. This makes it easy to opt-in and adds no overhead to packagers.

Honestly I believe that users who don't want icons should request the packagers of each relevant package for a /NOICON argument for the package if it's possible for the program package to support it.

[Absoblogginlutely]

+1 for this feature. It's nice to be able to roll out apps to users, but typically we don't want them getting the icon on their desktop> Getting a flood of calls to the helpdesk with "Whats this GhostScript icon on my computer - Have I been hacked" is not much fun. Yes group policy can work wonders, but for msp's that not very scalable across multiple companies.

[rluks]

possible solution would be to get a list of current icons on the desktop (current user and public) before an install of a package, then compare that to a new list post install of the package, and delete the delta .LNKs.

What if user changes their desktop shortcuts while installing the package? E.g. adding their own shortcut unrelated to the chocolatey packages. With this approach it would delete those too...

[FranklinYu]

This looks like a duplicate of #4?

@rluks That is a pretty short period though, for most users. And that behavior can be documented as well.

[tekook]

Any Update to this issue?

[bcurran3]

Just some additional thoughts on possible implementation...

Install-ChocolateyInstallPackage already can work some extra magic when filetype MSI is defined. I think the hump is in figuring out what installer the program is using when the filetype is simply defined as EXE. A new parameter of "installertype" could be implemented to define what brand installer is being used; i.e. https://en.wikipedia.org/wiki/List_of_installation_software. When the installertype is known then a standard list known options for that installer could be used. So if a Chocolatey user preference of NoDesktopIcons was set, Chocolatey could use the appropriate install parameter associated with the installer to tell it not to make desktop icons automagically.

This could then be expanded to include other common installer specific options.

Theoretically this could make packaging easier for maintainers as they wouldn't need to necessarily always figure out the silent install options, just figure out and define which installer is in use and let Chocolatey handle it from there.

Sounds feasible, right?

[ddcruver]

Brute force option, checking desktop before and after install runs, possibly asking the user to verify the deletion. Would have to check all the places that could show up on the users desktop.

[bcurran3]

I'm monitoring to see when/if this gets implemented in a new version of Chocolatey. Milestone keeps pushing forward, so far for 4 releases. I'd like to know this issue's (real) priority on the roadmap.

Sometime in the future I plan an upgrade to choco-upgrade-all-at which will kludge the ability to delete icon additions post install. Basically I'm going to have the task run a batch file that anyone can add pre or post processing into manually. I'll build in an option to either get a list of existing icons and delete the delta or simply moving existing icons to a temporary directory, delete the new icons, and move back the pre-existing icons. When I find the time...

[eyalroz]

Sorry for the slight spaminess, but I'm posting here also the explanation of how the two recently-mentioning issues relate, in my view.

There are (at least) four kinds of icons/shortcuts:

1. Desktop
2. Start Menu
3. Explorer Context Menu
4. Send To menu

and there are (at least) three policies w.r.t. adding these shortcuts:

1. Always add them
2. Never add them
3. Add them on installation, but not on update

and these policies can be set at:

1. Package scope
2. System scope (all packages chocolatey installs)

Now, here's what these issues ask for:

Issue	Kind of shortcut	Requested policy	Policy scope
#4 (this one)	1	2	2
#344	1	2	1
#344	1	3	1
#2016	2	3	2

I believe most users who asked for any of these four possibilities would find the others useful as well.

[ferventcoder]

Looks good to me.

[carsten-engelke]

Due to reasons mentioned such as the many different "standard" installers, I can see how this is a big PITA.

Thinking in Chocolatey baby steps, if a preference was created for not wanting shortcuts, it seems easy to stop it at the Chocolatey level by checking the preference and negating Install-ChocolateyShortcut when called.

I'll join the I-hate-a-million-shortcuts-popping-up-on-my-desktop club, but I find the topic a trivial matter. I'd argue it's easier to delete shortcuts I don't want than hunt down and create ones I do want.

I have a group policy that deletes all my normal program shortcuts that add an icon post installation and upgrade - works great! :)

Going back to the real problem of so many installers and so many possible switches and scenarios, it seems to me a possible solution would be to get a list of current icons on the desktop (current user and public) before an install of a package, then compare that to a new list post install of the package, and delete the delta .LNKs. IMHO this just feels strange being in Chocolatey core but could probably be implemented via an extension. Instead of messing with adding to the config/preferences/settings users could just install the extension if they don't want shortcuts. Then the various Chocolatey install functions could check for the extension and use it if installed. This makes it easy to opt-in and adds no overhead to packagers.

Honestly I believe that users who don't want icons should request the packagers of each relevant package for a /NOICON argument for the package if it's possible for the program package to support it.

While this is discussed here, can you provide details how to create this "group policy"?

[BossTownUSA]

While this is discussed here, can you provide details how to create this "group policy"?

https://www.tenforums.com/tutorials/104597-enable-disable-changing-desktop-icons-windows.html

I went to the bottom of the tutorial and used the disable icons via registry. Seems to be working.

[sduguay-apttech]

Hi,

I just signed up to comment in this thread. I'll join my voice to those already requesting the option to remove desktop icons at installation/upgrade.

We are in the process of migrating our customer's base to Microsoft Intune to manage their computers. Using registry workarounds is not a viable long term solution in our eyes and GPOs are already out of the equation due to hybrid domain join and the hefty cost of having to deploy Azure Active Directory Domain Services associated to pure Azure AD join devices. To top it off, we are moving our customer's documents to OneDrive for those with valid Microsoft 365 licenses resulting in useless shortcut creation every time a user will switch device if we do not clean up the desktop. I am surely not the only MSP guy out there running into this issue and I'm surely not the only MSP guy integrating Microsoft Intune and adding Chocolatey in their RMM stack in these Covid-19 times.

This leaves me with 2 options at the moment. Either I add more code in my PS chocolatey deployment script or I wrap a PS script in a W32 application to delete specific icons. I don't mind adding more code in my deployment script in the immediate future. Where I have an issue is that not all our deployment scripts are monolithic and they can vary from one customer to an another. I already know that in some upcoming projects some of them will requests shortcuts to be deleted while others will want to keep them. Let's just say that it would be a whole lot cleaner adding switches at the installation/upgrade process.

[eyalroz]

Indeed, as @sduguay-apttech , the deluge of desktop and menu icons forced upon us is one of the reasons it's problematic for me to recommend chocolatey to non-technical people. They'll complain to me "Why is my start menu being filled with the junk I sorted through and categorized/deleted?"

[dazzlr]

We have this problem at work and I have to delete the shortcuts after every weekly upgrade. It's very poor that the companies creating the installers still spam the user desktop this way. I used to do a lot of software repackaging (MSI/Installshield), and this was something we routinely suppressed in COTS packages for installation on the corporate desktop.

Can Chocolatey put pressure on the software companies instead of this being a Chocolatey problem? I would make it a dependency of being included in Chocolatey to not drop allusers shortcuts all over the place.

[kuro68k]

Try this software, it auto deletes icons on your desktop.

Tidy Desktop Monitor https://github.com/mkropat/TidyDesktopMonster

[eyalroz]

Can Chocolatey put pressure on the software companies instead of this being a Chocolatey problem?

Unlikely. Chocolatey as a project does not interact with the thousands (or tends of thousands) of upstream software producers and vendors.

I would make it a dependency of being included in Chocolatey to not drop allusers shortcuts all over the place.

Well, if you coupled that with a simple way for package maintainers to remove those shortcuts, that might be a relevant measure.

[IsaacGood]

Not a proper (or retroactive) solution, but some may find useful to auto delete icons like this script does: https://github.com/wh1te909/tacticalrmm/blob/develop/scripts_wip/Win_Chocolatey_Update_Apps.ps1 At beginning of chocolatey update script: $StartTime = Get-Date At the end after updates are done: $Desktops = "$env:PUBLIC\Desktop", "$env:USERPROFILE\Desktop" $Desktops | Get-ChildItem -Filter "*.lnk" -ErrorAction SilentlyContinue | Where-Object { $_.LastWriteTime -gt $StartTime } | Remove-Item

[JJenkx]

Not a proper (or retroactive) solution, but some may find useful

Thank you, I used this to make a powershell function. Right now it runs on every choco command. Maybe there is a way to only run on choco upgrade|install

Edit: I modified the function to run on "choco upgrade something"

# save this to where "echo $profile" shows the profile location. create the file if not there

function choco {
$CHOCOEXE=$(Get-Command choco.exe).Path
If ([bool]$CHOCOEXE){
    $CHOCOARG1=$Args[0]
    $CHOCOARG2=$Args[1]
    $ALLCHOCOARGS=$Args
    If ($CHOCOARG1 -eq "upgrade" -And [bool]$CHOCOARG2) {
        echo "`nGoing to remove any new shortcuts from desktop generated from now until upgrade finishes`n"
        $StartTime = Get-Date
        & $CHOCOEXE $ALLCHOCOARGS
        $Desktops = "$env:PUBLIC\Desktop", "$env:USERPROFILE\Desktop"
        $ICONSTOREMOVE=$($Desktops | Get-ChildItem -Filter "*.lnk" -ErrorAction SilentlyContinue | Where-Object { $_.LastWriteTime -gt $StartTime })
        echo "`nRemoving desktop icons:"
        echo $ICONSTOREMOVE
        $Desktops | Get-ChildItem -Filter "*.lnk" -ErrorAction SilentlyContinue | Where-Object { $_.LastWriteTime -gt $StartTime } | Remove-Item
    }else {
        & $CHOCOEXE $ALLCHOCOARGS
        }
}else {
    echo "`nUser defined function ""choco"" did not find choco.exe in path. Is choco installed?`n"
    }
}

[eyalroz]

I would like to ask chocolatey developers for an update regarding work on this issue, which is the most up-voted of all chocolatey issues. The second most-upvoted is its semi-dupe #4. It seems to be completely ignored - with no obvious reason why.

[pauby]

This functionality now exists using package hooks, specifically using this package which is currently in alpha (requesting feedback).

I'm going to go ahead and close this now, but we can always reopen if necessary.

[dhs-rec]

Installed the package, removed all shortcuts and finally ran a choco upgrade. It updated one package which again placed a new shortcut on the desktop. It wasn't removed...

[TheCakeIsNaOH]

@dhs-rec can you please create an issue over at the chocolatey-hooks repository with some more details https://github.com/chocolatey-community/chocolatey-hooks/issues

[eyalroz]

See my comment on the semi-dupe, here.