Message | 'Unable to modify the shortcut'

[Ricky-Tigg]

Prerequisites

• Write a descriptive title.
• Make sure you are able to repro it on the latest released version
• Search the existing issues.
• Refer to the FAQ.
• Refer to Differences between Windows PowerShell 5.1 and PowerShell.

Steps to reproduce

1. Right-click the title bar of PowerShell 7+;
2. Select Properties;
3. Make at least one setting change;
4. Click OK.

Expected behavior

Non-unfixed issue's behaviour hence no error revealing yet poor code.

Actual behavior

Change(s) made not persistent when new tool's sessions are started.

Error details

See section _Visuals_.

Environment data

Name                           Value                                                                                               ----                           -----                                                                                               PSVersion                      7.3.6                                                                                               PSEdition                      Core                                                                                                GitCommitId                    7.3.6                                                                                               OS                             Microsoft Windows 10.0.22000                                                                        Platform                       Win32NT                                                                                             PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0…}                                                                               PSRemotingProtocolVersion      2.3                                                                                                 SerializationVersion           1.1.0.1                                                                                             WSManStackVersion              3.0

Visuals

[mklement0]

It is indeed an annoying problem, and it has come up at least 3 times before:

• "Unable to modify the shortcut" #14978
• Cannot Change PowerShell 7 Properties With Non-Admin Account #13148
• Changing console window properties are not being saved #7825

Unfortunately, all these issues were closed; @iSazonov offered this resolution here:

PowerShell msi is installed on system, not user. It is how MSI works. The shortcut is protected by OS permissions.
You can create a custom shortcut and modify its properties.

Some background information and workarounds are here.

[Ricky-Tigg]

To be exact, This is how Microsoft wants MSI to work.

[mklement0]

@Ricky-Tigg, does that mean that now that you know the technical reason for the problem, you don't think there's a problem, after all?

[Ricky-Tigg]

"This is how Microsoft wants MSI to work." is solely related to the attitude of Microsoft, which is hardly embarrassed to demonstrate its inability to correct obvious software aberrations, by closing fully valid tickets one after the other.

[mklement0]

@Ricky-Tigg, I share your frustration with respect to this not getting fixed.

Let me provide some analysis that may point toward a solution:

• From MSI's perspective, the behavior makes sense:

  • The all-users PowerShell installation places a shortcut file (.lnk) in a shared location ($env:ALLUSERSPROFILE, typically C:\ProgramData)
  • Given that the installation is shared and that elevation was required to perform the installation, it makes sense to also require elevation to modify the shortcut file later.

• From the perspective of the Windows shell and its Properties dialog:

  • The UX, as shown in your initial post, is terrible:

    • (a) the error message is confusing and obscures the true problem.

    • (b) even though an interactive solution is possible - i.e., to ask for the necessary permissions to modify the shortcut file via a UAC dialog - it isn't offered

    • Fixing this problem requires a change to Windows itself.

• Separately, there's PowerShell's decision to use MSI in a manner that places the .lnk file in $env:ALLUSERSPROFILE

  • I don't know MSI well enough to know if there's an alternative approach that creates user-specific .lnk files instead, which would avoid the problem.

  • Notably, such an approach would require ensuring that such user-specific .lnk files are automatically created / copied to future user accounts on creation.

[jhoneill]

"This is how Microsoft wants MSI to work." is solely related to the attitude of Microsoft, which is hardly embarrassed to demonstrate its inability to correct obvious software aberrations, by closing fully valid tickets one after the other.

It is rather more complicated and nuanced.

1. This problem has been around since Vista where unless a process runs elevated it can't change "all users" shortcuts on the start menu.
2. It noticeably impacts anything which uses the legacy Windows console host (instead of Windows terminal), because way back changes to the console host settings were saved to the shortcut that started it.
3. A user has multiple choices, give themselves rights to the Program Data\Microsoft\Windows\Start Menu, start programs from a short cut elsewhere (IIRC pinned to the task bar, and on the desktop are both fine), switch to using Windows Terminal on Windows 10, or use the current shipping version of Windows which uses Windows Terminal by default. (Since I had to change my computer to be able to us Windows 11, I'm aware the last isn't universally applicable).
4. Microsoft has been very slow getting rid of the legacy console host. But it no longer ships with Windows It's unlikely the PowerShell .lnk file will change location, but if you're not in Windows 11 the best thing you can do is move to using Windows terminal and a whole bunch of clunky things go away when you. Gratifying though it might be to vent about generally perceived problems with "Microsoft", that's not a helpful way to get the PowerShell team to do anything differently.

[Ricky-Tigg]

And this discourse, which hardly seems determined to want to grow old. Isn't it all the same reassuring to know that there are things made in such a way that they cannot experience change? That said, it is futile to dwell on it, the name of the company having long since reached the status of pleonasm that we know so well. I even doubt that it will ever be worth putting it in writing, as it is not a secret to anyone.

[microsoft-github-policy-service]

This issue has been marked as answered and has not had any activity for 1 day. It has been closed for housekeeping purposes.

[microsoft-github-policy-service]

This issue has been marked as answered and has not had any activity for 1 day. It has been closed for housekeeping purposes.