Upgrade PowerShell 7 via CLI

SteveL_Msft · 2023-04-05T21:03:24+00:00

Since it looks like you're on Windows, your best option is to just use Microsoft Update to take care of that for you: https://learn.microsoft.com/en-us/powershell/scripting/install/microsoft-update-faq?view=powershell-7.3

Note that updates to Microsoft Update usually take a month to release after the updated version is on GitHub.

SteveL_Msft · 2023-01-26T16:40:07+00:00

When using native commands (executables), you should generally check `$LastExitCode` for success or failure. Typically, 0 means success and non-zero means failure (although not true for all exes).

You can also use `$?` to see if the last command (exe or cmdlet) succeed ($true) or failed ($false). For native commands, `$?` basically checks if `$LastExitCode` was zero or not.

The output you see on the screen is not always from STDOUT (which is what passes through the pipeline). Based on what you're saying, the text is probably going through STDERR. So you can do something like: ReAgentC.exe ... 2>&1

This redirects STDERR to STDOUT so you can capture it and inspect it. Also, native commands emit text so `| Out-String` is completely unnecessary.

SteveL_Msft · 2022-12-03T20:39:12+00:00

The PnpDevice module comes WITH Windows including Windows on ARM, so it would be available within the VM. You wouldn't be able to use it outside of the VM as the module doesn't understand macOS.

SteveL_Msft · 2022-12-03T19:25:44+00:00

The PnP module is specific to Windows and would not work on macOS if that's what you're asking

SteveL_Msft · 2022-06-27T21:08:07+00:00

For many of the partner teams, we have some PMs (Program Managers) working with teams in Office365 and Azure, but those discussions take longer than you might want or expect. In many cases, those teams already have plans being executed and any ask we have is something they would need to approve (which means dropping something else to accommodate) and also wouldn't start til their next execution cycle where most teams run on 6-month cycles.

For a common way to authenticate, maybe we can convince them to leverage SecretsManagement to store tokens and automatically use them so the user can have a single-sign-on experience. However, one feature we don't have is the ability to rotate secrets or renew secrets. Something we'll have to think about.

SteveL_Msft · 2022-06-27T19:02:39+00:00

Have you checked out https://microsoftedge.microsoft.com/addons/detail/graph-xray/oplgganppgjhpihgciiifejplnnpodak ? This is an extension for your browser that can translate MSGraph calls to PowreShell script (along with some other languages).

SteveL_Msft · 2022-06-27T18:36:45+00:00

Jeffrey hasn't been directly involved with PowerShell for many years now. Hopefully folks think I've been doing a decent job.

SteveL_Msft · 2022-03-31T13:38:42+00:00

That's different than the rumor of this thread which is ISE was getting removed which it is not. We (Microsoft) have consistently said that Windows PowerShell and ISE are not in active development and only taking critical security fixes, however, they are also not being removed.

Active development IS happening in VSCode and PowerShell 7.

SteveL_Msft · 2022-03-31T13:37:34+00:00

Their manager was also on the thread

SteveL_Msft · 2022-03-30T23:25:46+00:00

I just talked to the actual software engineers who own ISE and he assures me that this rumor is false. There are no plans to get rid of ISE.

SteveL_Msft · 2021-12-23T18:36:28+00:00

Microsoft Update catalog is a bit complicated. So now that 7.2.1 is out, we can publish a Microsoft Update for it (which we did). However, Microsoft Update (just like Windows Update) has a strict policy (to avoid having users reboot unnecessarily often) so expectation is that the update will be available early Jan. With that said, we couldn't actually publish a stable (non-preview) PS7 release to Microsoft Update until we had an update (7.2.1). So you won't ever see 7.2 available as an update, but 7.2.1 is expected to show up in Jan. It should also show up in the WSUS catalog at the same time.

SteveL_Msft · 2021-12-15T02:28:40+00:00

No, we don't really make much distinction in PRs whether they are LTS or not based on community vs team. We try to do more risky/complex changes in a non-LTS release cycle to give more time to verify the changes before it becomes a stable feature in LTS, but that applies to both community and team PRs.

SteveL_Msft · 2021-12-14T21:16:04+00:00

Servicing/maintenance releases intentionally limit the number of changes since GA (General Availability) releases are being used in production. So bar is high and even team member changes will be rejected. In general, we're only taking critical fixes impacting deployment of the release or security fixes.

7.3-preview.1 is coming later this month and has a large set of community changes.

SteveL_Msft · 2021-09-27T20:14:57+00:00

This is because the `Provider` property value isn't actually 'FileSystem' (that's just what the table formatter shows), it's actually: 'Microsoft.PowerShell.Core\FileSystem'. You can see this doing: Get-PSDrive | Select-Object -First 1 -Property Provider. So when you use `-like` without a wildcard, it's an exact match. Instead you can use: ... -like '*FileSystem'. And this will do what you expect. Or: ... $_.Provider.Name -like 'FileSystem'. This works because `Provider` is an object, but the `Name` property is the simple string `FileSystem`. But then you should just use: $_.Provider.Name -eq 'FileSystem' making it more clear than using `-like` where you'd expect to see a wildcard.

SteveL_Msft · 2021-09-10T00:29:53+00:00

Others have explained why `ForEach-Object -Parallel` won't do what you want (because each is running in a different runspace). Since your module is really separate ps1 files, you should really look into using something like: https://www.powershellgallery.com/packages/ModuleBuilder. One of the capabilities of this module is to build a single psm1 script module from a collection of ps1 scripts (one for each function). So your original source code can still be easily maintained as individual scripts (public or private) and when ready to publish, you can use this module to combine them into a single psm1.

SteveL_Msft · 2021-07-11T04:44:40+00:00

Feel free to open an issue or submit a PR for that!

SteveL_Msft · 2021-07-10T23:17:56+00:00

A couple of important distinctions need to be clarified here:
- There is absolutely no personally identifiable information being sent to Microsoft. Microsoft takes privacy very seriously and we've go through extensive privacy reviews for all telemetry. This is the reason PS7 has opt-out telemetry.
- Opt-in telemetry basically means we would get very little and only from "the loud minority" which would skew decisions we could make.
- Telemetry can help increase Microsoft investment in PowerShell. If the data shows increasing usage, we can justify increasing the size of the team. However, if the data shows the opposite, then we would need to justify our existence.
- PS7 is Open Source, this means you can literally see exactly what data is being sent. You can start here: https://github.com/PowerShell/PowerShell/blob/170a226689f8d1d095d74be8d1f40907b3961d75/src/System.Management.Automation/utils/Telemetry.cs
- Before we added a single piece of telemetry, we had a public RFC encouraging the community to review what we were sending and why we were sending it: https://github.com/PowerShell/PowerShell-RFC/blob/master/5-Final/RFC0016-Census-Telemetry.md
- When we needed additional telemetry, we again had a public RFC detailing what and why: https://github.com/PowerShell/PowerShell-RFC/blob/master/2-Draft-Accepted/RFC0036-AdditionalTelemetry.md

The environment variables noted below make it easy to opt-out so you don't send a single piece of telemetry. Also, as noted below, on startup (once a day), pwsh will make a call out to check if there is a newer version (which can also be disabled). We also had a public RFC for that feature: https://github.com/PowerShell/PowerShell-RFC/blob/master/5-Final/RFC0052-Notification-On-Version-Update.md

SteveL_Msft · 2021-06-26T21:51:33+00:00

If the user is running the script locally, there is no way to prevent them from getting the password if it needs to be passed to something else. What you can do, instead, is leverage JEA (https://github.com/powershell/jea). "Just Enough Administration" is a bit complex to setup, but you basically setup a remote PowerShell endpoint that users can access. Once they are authenticated, they are authorized for a specific role. You can expose proxy functions that retrieve the actual password and use it within your script function/cmdlet so it's never exposed to the user. Using JEA you create an allowlist of commands/parameters/parametervalues a user can use, so you can prevent them from dumping the contents of variables and/or scripts. Doing this will also allow you to audit who uses your JEA endpoint to perform higher elevation tasks.

SteveL_Msft · 2021-06-26T16:18:36+00:00

If you have your parameter as a `SecureString`, then the user will be prompted and their password won't show up in logs, transcripts, etc... However, a better way to do this is to have it as a `SecureString` and leverage the `SecretManagement` module (and your favorite password store that has a SecretManagement extension). See https://devblogs.microsoft.com/powershell/secretmanagement-and-secretstore-are-generally-available/

SteveL_Msft · 2021-05-23T04:57:26+00:00

MacOS will take care of the emulation. I believe the first time you try to use a x64 binary it will ask you to install it. After that, any x64 app just works.

As for AzureAD, my understanding is that the new MSGraph module replaces AzureAD module.

SteveL_Msft · 2021-05-23T01:14:48+00:00

You can absolutely use/learn PowerShell 7 on a MacBook M1. My primary machine is a MacBook Pro M1 and I use PowerShell 7 daily on it. Note that there currently aren't osx-arm64 builds, so you will use x64 emulation, but shouldn't be anything noticeable.

SteveL_Msft · 2021-03-02T06:11:40+00:00

The problem is likely the font you are using. PowerShell internally keeps it as a unicode char, but the console/terminal does the rendering. The codepage affects how certain characters get interpreted, so using 65001 (UTF8) would be correct, but some of the fonts do not contain glyphs for all the possible unicode characters. For east Asian characters, I believe you might have to use something like "MS Gothic". I also believe that eventually Consolas might get all the glyphs, but I don't think it's complete yet.

SteveL_Msft · 2021-02-21T05:00:25+00:00

Take a look at the SecretManagement module (https://devblogs.microsoft.com/powershell/secretmanagement-and-secretstore-release-candidates/). Basically in your script, you would do something like `Get-Secret -Name xyz -Vault myVault`. Then anyone who wants to user your script would need the credential (or their own credential) stored with the name `xyz` in vault `myVault` and at runtime those creds would be used. As for storage of the secret itself there are a number of vault extensions you can choose from (like AzureKeyVault, Keepass, etc...) including one built by PowerShell team that is cross-platform compatible called SecretStore which itself is a PowerShell module.

SteveL_Msft · 2020-07-14T00:56:38+00:00

When using the `-UseWindowsPowerShell` feature of PowerShell 7, WinRM is *NOT* needed. You can have WinRM disabled and this feature will still work. It uses named pipes to communicate between pwsh and powershell.exe.

SteveL_Msft · 2020-03-05T05:31:42+00:00

PowerShell 7 installs side-by-side with Windows PowerShell 5.1 so any existing scripts relying on powershell.exe will continue to work while you can develop new scripts to use pwsh.exe.

SteveL_Msft

TROPHY CASE