Add options for running with no profile to jumplist & explorer

[kilasuit]

Summary of the new feature / enhancement

As a user (not always using Windows Terminal) I would find it beneficial to easily run PowerShell without a profile, choosing whether or not as admin from a right click on taskbar/start menu entry or within a explorer window

Proposed technical implementation details (optional)

additional entries added to the jumplist tasks that call PowerShell with the -noprofile flag
an open powershell here with no profile option in explorer

[SteveL-MSFT]

The only concern I have would be if we do this for everyone. I can see it being useful, but I would also guess that 90% of users wouldn't need it. It could be something we have in powershell.config.json to enable.

[iSazonov]

User can run pwsh -noprofile from current PowerShell session.

[dkaszews]

For a taskbar/desktop shortcut, you can just create a shortcut with the --noprofile flag. For shell context menu, you can also create "Open PowerShell here (without profile)" by editing registry.

90% of users wouldn't need it

It's also Windows-specific, Linux users (myself included) had to remind themselves what is this jumpmenu thing

[MartinGC94]

Why would it need to be hidden by default just because 90% of the users don't use it? I can't imagine those 90% would be negatively affected by it so why would they care if it's enabled by default?
I understand that cluttering up the jumplist could be annoying if you use it for other things but PowerShell doesn't have recent files or any other interesting tasks in the jumplist.

[kilasuit]

User can run pwsh -noprofile from current PowerShell session.

For a taskbar/desktop shortcut, you can just create a shortcut with the --noprofile flag.

True can do either of these, but both are slower for the user and ideally shouldn't need additional shortcut or direct registry editing

For shell context menu, you can also create "Open PowerShell here (without profile)" by editing registry.

This ideally should IMO be an additional tick box option in the installer (or perhaps a powershell.config.json option like Steve suggested if it could be more easily managed there)

This is definitely a nice to have, not a critical need

[kilasuit]

Coming back to this I think that this is really needed because if you are either

• Troubleshooting a script
• Trying to repro an issue in this repo
• Wanting a 100% clean session
• Wanting a 100% clean session in a specific location (new additional ask)

Having this as an option at install (on Windows, not sure about on other OSes) would be hugely beneficial and not need additional workarounds that a User may not be able to make (like registry changes) to achieve the same desired result.

[kilasuit]

I'd also like to see the same options for

• Run as Admin (No Profile)
• Run with Custom Profile
• Run as Admin (Custom Profile)

The last two would IMO allow you to specify a path to a custom profile that may be useful in helping troubleshoot profile issues or just to load different shaped and sized profiles depending on the task that you want to do as I personally feel that the one profile meets all needs isn't quite fit for purpose ( I recognise there are profiles for different hosts, different user, all hosts, all users, but there are times where you need to say be SharePoint Admin, Exchange Admin, Tenant 1 Admin, Tenant 2 Admin etc etc) as having an easy jumplist for those profiles would be useful.

Whilst I know this is predominantly a Windows thing, it would be good if possible this could in future become a Linux/Mac OS thing too, even if out of scope for this current ask.

[theJasonHelmick]

Hi @kilasuit - thank for the issue. The WG has reviewed this and have decided to decline the feature request. There are documented ways to add items to the explorer jump list if users desire -- and there is no equivalent for Unix platforms. You can also add Windows Terminal profiles to run with -noprofile. Thank you for the suggestion.

[kilasuit]

Hi @theJasonHelmick - I know that this issue & ensuing comments from us all would have been discussed if the WG had managed to meet last week as I was looking forward to showing why I think this is needed, based on how I troubleshoot issues whilst working on my main Windows 11 machine., especially as its not easy typing the right words with the right terminology for this ask when it's easy to get misunderstood , Not trying to be a pain but if we could spend just 5 mins on this week that would be great.

I also realised those points mentioned but considering that PowerShell 7.2 is supported all the way back to Server 2012R2, where Windows Terminal will never work, same with 2016 and IIRC 2019 (though I can't find a clear docs page for this and have raised this issue for making it clearer) we shouldn't forget that these systems are out there and could benefit from additional actions in the jumplist like those listed. Also everything I've read documentation wise doesn't account for new actions but instead point to adding new items like recent emails as opposed to creating a new email from the taskbar with a simple right click.

I like @SteveL-MSFT comment about putting this in PowerShell.config.json as way of configurability although the current code lives in here & I didn't think it would be much to amend this.

I firmly believe that we are yet to see lots of PowerShell 7 being installed across older windows server estates & whilst we'd love it if no one rdp'd to servers anymore, we've gotta be realistic that it aint happening anytime soon.

I am happy however if adequate documentation can be provided, because I could not find it in my searches, that helps me fill this need post-install, to take that bit of work on and release it as post-install enhancement script that implements this & publish it to the gallery & then support it myself as this would be an interesting challenge, if that would be more acceptable, but I'd prefer it be something that if possible be added in natively on windows to allow much quicker troubleshooting going forward.

In contrast we still have for WinPS the actions for also Opening In the ISE, and an additional one I'd like to see if possible (though deffo not needed) would be open Code/Code Insiders if detected it was installed for parity. But I'd also like to see the ISE Preview make a return for those machines that cant/won;t trust VSCode on them too.

but Yeah, can we go over this shortly this week please and after then i'll happily go with the overall direction of all of us we'll have come to an agreement as a collective. Also I did miss speaking to you all last week, was a shame but these things happen!

[kilasuit]

We did manage to get this discussed in the Interactive UX WG this evening (minus @theJasonHelmick sadly) and the following was decided after a good discussion between us all, plus we made some interesting findings along the way too!

Findings

1. This does only affect users on Windows. It would be great for similar functionality in other OSes but that's well outside the scope for this repo
2. It affects any instance opened in conhost, so not in Windows Terminal.
3. It only is beneficial for those that either can't use Windows Terminal, or are choosing not to perhaps for security reasons or incompatibly reasons (like older Windows 10 versions or on any version of Windows Server below 2022) or just because they have other productivity workflows.
4. There is this module in the Gallery that can amend Taskbar Jumplist settings which could be used here, or other methods could be used for this in a post install script.
5. We could not quickly decide how we'd look at adding this in powershell.config.json and such wouldn't investigate this as an option for this request.

Future steps

1. Collectively we agreed this to be an interesting need and a nice to have but not critical.
2. We also think that this generally makes more sense as a post install script that's released to the gallery for those that may want it. This as it's more generic than just PowerShell, as some of the suggestions for tasks could be useful for 5.1 too - this is a task for me to take on outside of this repo & then blog about in future.
3. Whilst we won't look to accept this in to the repo right now this was the consensus was that we did not think there was a big enough demand for it.
   1. However with experimentation & some data from a release of the above we may in future determine that some items listed in this issue may be beneficial to be built in still and can come back to this at a later date if needs.
   2. As such I will in my fork of this repo start a branch for experimentation of the options listed above that I think may be beneficial to be built in still for all users. If this could be you please use the 👀 reaction on this comment so can track it in future
4. As a combo of all of the above I am closing this as Resolution-WontFix for now as it's intended to be resolved by external means,
   1. We can in future decide to take in the experimentation that I am looking to do from item 3 above.

[microsoft-github-policy-service]

This issue has been marked as won't fix 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 won't fix and has not had any activity for 1 day. It has been closed for housekeeping purposes.